Instant blockchaindatashares
Indexed chain data arrives in your own Snowflake account as a set of secure views. There is no pipeline to run, no bucket to sync and no copy to keep current. You grant the share, point your queries at it, and the tables stay in step with the chain. The same views can be unloaded to your storage as files if a warehouse is not where your work happens.
Shared into your account
EthereumIn practice
Where teams run it
Teams query chains like Ethereum, Base, Solana and Hyperliquid through instant datashares for treasury reporting, cross-chain analytics and regulatory work: a historical share for the long view, a real-time share when the question is about the last few minutes, and file dumps when a warehouse is not where the work happens. Shares are built per chain, and coverage for every chain is listed on the chain coverage page.
Historical share
Full history in Snowflake
A historical share carries a chain from its first block to the latest block we have processed. Every chain in the same family reads the same way, so a query written against Ethereum runs against Base or Polygon with a schema swap and nothing else. Because it is a Snowflake share, storage stays on our side and you pay for the compute you use.
In the share:
- Blocks, transactions, receipts, logs and traces, normalized to one schema across chains.
- Native, ERC-20, ERC-721 and ERC-1155 transfers, plus contract creations.
- Decoded logs and traces on the chains where we decode contract activity.
- Reorg handling, gap detection and checksum validation applied before anything reaches a share.
- Trial and sample tiers of the same views, so you can test schemas before you commit.
Real-time share
Real-time shares
A real-time share is a second set of views over the live streaming tables, so rows land within seconds of the block rather than on the batch cycle. It sits alongside the historical share in the same account, which means one join across both.
Hyperliquid
BSC
Polygon
ArbitrumFile delivery
File dumps to your bucket
Not every team wants a warehouse in the path. Any dataset we publish as a datashare can instead be unloaded as files into storage you control, on a schedule you pick. It is the same data and the same views. Only the delivery changes.
How the dumps work:
- Written straight out of the same share views into an external stage that points at your S3 bucket.
- Parquet or JSON, with a configurable maximum file size and headers included.
- Hive-style partitions: year, month, day and hour directories, one tree per table.
- Stream-fresh mode runs inside the chain stream loop, so a dump is as current as the share it reads.
- Backfill mode walks any date range in minute, hour or day steps for a first load or a re-cut.
- Reorg corrections rewrite the affected hour partitions in place, removing the stale files first.
- Every file written is recorded with its folder, filename, block range, time range and reorg flag.
Reorgs are the part most file feeds get wrong. When a chain reorganizes, the affected files are corrected rather than left describing blocks that no longer exist, and a downstream loader can tell a correction from a new arrival.
Use cases
What teams build with it
- Cross-chain analytics and research without running an indexer.
- Forensics, audit trails and regulatory reporting against complete chain history.
- Index and benchmark construction from transfer and price history.
- Model training on normalized multi-chain data.
- Reconciliation between internal ledgers and on-chain settlement.
The rest of the platform
Other ways to get the data
Get started
Query a datashare this week
We index 130+ chains, and a trial runs on the same views as production. Start with a chain, or browse the dataset catalog first.