Onchain analytics data for your own warehouse
SQD sits at the extract-and-decode end of the analytics pipeline. It streams decoded events, transactions, and traces from one endpoint across 225+ networks, from genesis to head, and you model and serve them as SQL in the warehouse you already run. The Portal is not a SQL endpoint; the SQL is yours.
A dashboard is the end of a pipeline, and the chain is where it starts
Every chart is the end of a four-stage pipeline: extract the blocks and logs, decode the raw hex into named events, model it into tables shaped around your questions, and serve it from a warehouse a BI tool queries with SQL. The last two stages are ordinary SQL work; the first two are where the cost sits, paginating eth_getLogs against per-call block-range caps, standing up per-chain RPC, and reconciling decoded schemas across providers before a single row reaches the warehouse. All of it is public data already; the cost is in the extract and the decode.
Extract and decode here, model and serve in your warehouse
SQD owns the first two stages of that pipeline, extract and decode, and streams the result into the store you already run. The Portal is not a SQL endpoint; the SQL is yours.
The numbers are real and reproducible. One extract for USDC, USDT, and DAI transfers over a fixed 1,000-block window on Ethereum (18,000,000 to 18,001,000) returns 22,318 transfers worth about $542M. Same window, same totals on every run.
- USDC$318.8M
- USDT$203.4M
- DAI$19.5M
The extract is one filter on the Transfer topic across the three token contracts (multiple addresses in one filter is OR logic):
That streams raw logs as NDJSON; the amount is hex in data. Decode against the ERC-20 ABI (or let the Pipes SDK do it), load into ClickHouse, then it is a GROUP BY. The full extract-decode-rollup walkthrough is in the onchain analytics guide.
Reach the same data at the level your stack needs
The data layer itself
A streaming HTTP endpoint serving filtered logs, transactions, traces, and state diffs, with full history, in any language. You apply the contract ABI and aggregate the result. Teams run it in production as the data source, in place of RPC for history and bulk reads.
- - Any language or stack
- - Full history from genesis
- - You decode and aggregate
- - NDJSON over HTTP, no SDK required
Decode and load, built in
Sits on top of the same API in TypeScript: decodes logs into typed events and streams them into a target store, with progress tracking and reorg rollback handled for you. Built for a durable analytics pipeline rather than one-off queries.
- - ClickHouse, Postgres, Parquet/S3 targets
- - Custom-target API (BigQuery, Snowflake)
- - Decoding and typed events built in
- - Progress tracking and reorg rollback
Try the Portal API
Live queries against real blockchain data. Pick a network, choose a query, hit run.
The public endpoint is free for development. See plans for dedicated portals and higher limits.
Basebase-mainnet/streamBuilt for Analytics at scale
Single endpoint, 225+ networks
One POST to portal.sqd.dev returns logs, transactions, traces, and state diffs from any supported chain, with no per-chain RPC setup and no reconciliation across providers. Apply the contract ABI to decode, or let the Pipes SDK decode for you.
Full archival depth from genesis
Every block, transaction, and event log from block 0 to head, on every chain, through the same query as live data. Backfill a contract's full history in one streamed range request instead of paginating eth_getLogs against per-call block-range caps.
Real-time NDJSON streaming
Stream new blocks, events, and state changes as NDJSON over HTTP, the same query shape you use for history. No WebSocket to manage, no polling loop. Figures over unfinalized blocks are provisional until finality, as in any streaming pipeline.
Direct warehouse integration
Pipe decoded data into ClickHouse, Postgres, MongoDB, SQLite, or Parquet on S3 with the Pipes SDK, plus a custom-target API for BigQuery, Snowflake, and Databricks. Your BI tool then queries the resulting store with ordinary SQL.
What you would build yourself
The blocks, logs, and traces are public. What a provider saves you is the extract-and-decode pipeline in front of the warehouse, and it repeats for every chain.
- Historical backfill Yourself Paginate eth_getLogs against per-call block-range caps to pull a contract's full history.With SQD One streamed range request returns every block, transaction, and log from genesis to head.
- Cross-chain coverage Yourself Per-chain RPC setup and schema reconciliation across providers, one integration per network.With SQD One POST to portal.sqd.dev returns the same shape across 225+ networks.
- Decoding logs Yourself Raw logs arrive as hex topics and data that you decode against the ABI by hand.With SQD The Pipes SDK decodes logs into typed events and loads them into the target store.
- Where the SQL runs Yourself SQL-as-a-service runs on a hosted dataset, limited to its chains and its hosted-query rate limits.With SQD Decoded data lands in your own ClickHouse, BigQuery, or Postgres, queried with ordinary SQL.
See this on your own contracts
Tell us the chains and contracts you care about, and we will show you the query that returns them.
What teams build with SQD
- Ecosystem health dashboards with cross-chain comparisons
- Whale and smart-money tracking across DEXs and lending
- Gas and fee-market analytics
- Cross-chain activity benchmarking for L2 comparisons
- Institutional research on historical onchain datasets
- Internal tooling on decoded onchain feeds
Cryptographic proofs verify the onchain data you have, not whether it is complete. Why proof-based validation misses whole classes of logs, shown with Polygon state-sync, and how to query the full set.
Structural checks prove a dataset is well-formed, not complete. The reconciliation method that finds missing rows: count against an independent source, escalate granularity from days to the record. Worked live with Portal and Dune.
eth_getLogs is the standard way to read events, and the first wall teams hit. The block-range and result caps that force pagination, the archive requirement, and a real block where eth_getLogs omits logs the receipt returns.
The same JSON-shaped request reads EVM logs, Solana instructions, and Bitcoin inputs and outputs, with no schema, no deploy, and no sync wait.
One declarative query reads Solana program activity by program ID and discriminator, and surfaces the failed and uncommitted calls most tools drop.
How blockchain history feeds analytics dashboards. The data pipeline, the common metrics, and how this is done in tools like Dune and in-house BI.
Frequently asked questions
How do I query SQD data from a dashboard?
What's the difference between SQD and Dune?
Can I export to BigQuery or Snowflake?
Other ways teams use SQD
See all solutionsSwaps, liquidations, and the internal calls a log-only feed misses.
Pre-decoded onchain data for agents, over MCP or plain HTTP.
Address-keyed history: transfers, native and internal value, NFT moves.
Traces and state diffs, the execution footprint logs alone never show.
Mints, transfers, and marketplace sales, decoded from one log stream.
Your blockchain data infrastructure, handled.
Private Portal. Dedicated. Validated. Managed. Tell us what you're building, we'll show you what it looks like on SQD.
validated data
for Enterprise
serving data