Indexed EthereumBlockchain Data
Ethereum is the proof-of-stake Layer 1 that most of DeFi settles on, running the EVM against an account model where every twenty-byte address carries a balance, a nonce and, for contracts, code.
How to query Ethereum data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Ethereum blockchain data with plain SQL from a live database inside your own Snowflake account, populated with the indexed chain dataset. There is no pipeline to build and no second copy to store. The same dataset ships as file dumps to your own object storage for lakes and warehouses that are not Snowflake.
- Full history as a Snowflake data-share
- File dumps to S3 or your own object storage
- Real-time delivery, current to chain tip
Used for:
- Analytics teams already on Snowflake that want Ethereum data beside their existing tables
- Fund accounting and treasury reporting that reconciles against a fixed history
- Cross-chain questions answered in one SQL statement instead of one query per chain
- Loading Ethereum history into BigQuery, Databricks, Redshift or a Spark lake
- Replacing a self-hosted indexer and the engineering time that keeps it running
- Serving one governed dataset to several desks without copying it per team
Kafka Streaming
Available todayEvent stream
Consume Ethereum activity as a continuous stream of normalized records, produced as the chain is indexed instead of polled for.
Used for:
- Trading and execution systems that act on Ethereum activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Ethereum wallet or protocol activity
- Feeding a stream processor that already reads from Kafka
- Keeping an internal store hot without waiting for a batch window
- Event-driven services that would otherwise poll on a timer
Curated Datasets
Available todayPurpose-built tables
Protocol-level Ethereum datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- DeFi
- Staking
- Tokens and payments
Used for:
- Position-level Ethereum lending, swap and liquidity analysis
- Reward, delegation and validator reporting without rebuilding the model
- Token distribution, holder and payment-flow reporting
- Risk and exposure work that needs protocol state, not raw logs
- Skipping the decoding layer an in-house team would have to maintain
- Extending an existing Ethereum share with a modelled slice
Balances
Available todayTables and REST
Read what a Ethereum address held, either as it stands now or exactly as it stood at a past block or timestamp.
- Point-in-time balance tables, as at any block or timestamp
- Real-time balances API for latest and historical balances
- Batch API for wallets, tokens and balances in bulk
Used for:
- Reconstructing Ethereum portfolios and NAV as at a reporting date
- Audit and reconciliation work that has to be repeatable months later
- Wallet and portfolio products that render Ethereum balances on page load
- Compliance checks that read one Ethereum address at one block height
- Refreshing holdings for a whole book of accounts on a schedule
- Tax and cost-basis workflows that need holdings at each event
Realtime API
Available todayREST over the indexed dataset
Query indexed Ethereum records over REST, reading the same dataset the share reads, with no warehouse in the path.
Used for:
- Applications that need one answer rather than a table scan
- Customer-facing screens where query latency is visible to a user
- Services that have no data warehouse and do not want to run one
- Prototyping against production data before committing to a share
- Backend checks that run per request instead of per batch
- Teams that want indexed Ethereum data behind their own API layer
Ethereum data: frequently asked questions
What is Ethereum?
Ethereum has produced blocks continuously since its genesis block on 30 July 2015. Since the Merge in September 2022 it has run on proof of stake under Gasper, which pairs Casper FFG for finality with LMD-GHOST for fork choice: validators propose one block per twelve-second slot, thirty-two slots make an epoch, and a block is finalized once two consecutive epochs are justified, roughly thirteen minutes after it is produced. Consensus itself lives on a separate chain, indexed as Ethereum Beacon Chain. Execution happens in the Ethereum Virtual Machine against an account model rather than a UTXO set, so every twenty-byte address carries a balance, a nonce and, for contracts, code and storage. The native asset is ETH, divisible to eighteen decimals and metered in gwei. Two later changes shape the data: EIP-1559 in August 2021 burned the base fee instead of paying it to the block proposer, and the Dencun upgrade of March 2024 moved rollup data into blobs that the consensus layer stores apart from calldata.
Ethereum data on SonarX
SonarX indexes Ethereum end to end: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so an Ethereum query and a Base query take the same shape and can be joined without a translation layer.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. Point-in-time balance tables, the real-time balances API and the batch wallets, tokens and balances API are all available for Ethereum. Kafka streaming carries the same records as a live topic today.
How SonarX indexes Ethereum
Two properties make Ethereum harder than its size suggests. Since the Merge it is effectively two chains: withdrawals and validator rewards are recorded on the consensus layer, so a complete ETH flow for a staking address is not visible from execution data alone. And much of what analysts want is not in the block. Internal transfers exist only in traces, which have to be produced by re-executing each transaction, and a decoded log is only as reliable as the ABI resolution behind it, which for proxy contracts means following the implementation, not the emitting address. Blob data adds a deadline: consensus clients prune blobs after roughly eighteen days, so those records are captured as they arrive or not at all.
What teams build with Ethereum data
Three workloads account for most Ethereum requests SonarX receives. Portfolio reconstruction and fund accounting need a wallet’s holdings as at a specific block or timestamp, reconciled against transfers rather than inferred from a current snapshot, which is what point-in-time balances exist for. Position-level DeFi analytics need decoded logs and traces together, because a lending position is a sequence of events and the true cost of a swap is only visible once internal transfers are attached to it. Rollup cost accounting is the newer one: since Dencun, an L2’s operating cost is a blob-fee series on Ethereum, which makes L1 data the ledger for L2 economics.
Transaction monitoring, treasury reporting and token distribution work sit on the same indexed tables. SonarX maintains the data; the analysis stays yours.
Getting Ethereum data from SonarX
Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Ethereum history and the balance APIs are available now, so a first delivery is provisioning rather than engineering. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.
Is there an Ethereum data API?
Yes. Real-time and batch APIs over indexed Ethereum data are available today, covering historical and latest balances and wallet, token and balance lookups in bulk. They read from the same indexed dataset as the Snowflake share and the file delivery, so an API answer and a warehouse query agree.
How do I get Ethereum data into Snowflake?
SonarX provisions a data-share into your own Snowflake account. The share appears as a database you query with SQL, so there is no pipeline to build and no second copy to store, and it stays current as SonarX advances the indexing pipeline.
How far back does Ethereum coverage go?
The historical data-share and file delivery cover Ethereum's full recorded history, from the 2015 genesis block forward, and are available today. Real-time delivery keeps the same dataset current to chain tip.
How are Ethereum reorgs handled in the data?
Head reorgs are shallow on Ethereum but real, and the indexed dataset is corrected rather than appended to when one happens. Records from an orphaned block are withdrawn and the canonical chain is rewritten, so a query run twice does not return two different histories for the same block height.
Are Ethereum smart contract event logs decoded?
Yes. Logs are decoded against contract ABIs so readable event fields can be queried directly, without maintaining an ABI registry and a decoding layer in-house. Proxy contracts are resolved to the implementation that defines the event rather than the address that emitted it.
Can I get point-in-time Ethereum balances?
Yes. Point-in-time balance tables and the balances API are both available for Ethereum, which is what portfolio reconstruction, fund accounting and audit workflows need when they have to state a wallet's holdings as at a specific block or timestamp.
Is this Ethereum mainnet, the Beacon Chain or Ethereum Classic?
This page covers Ethereum mainnet execution data. Consensus-layer data, including validators, attestations and withdrawals, is a separate dataset covered on the Ethereum Beacon Chain page, and Ethereum Classic, the chain that kept proof of work after the 2016 fork, has its own page.
How do I start with Ethereum data?
Tell SonarX the delivery target, the history depth and the refresh cadence you need, and the share is scoped against that. There is no self-serve signup: every engagement is provisioned, so the first conversation is about scope rather than credentials.