Key takeaways
The 2026 crypto data stack is best understood as six layers: ingestion, decoding and normalization, indexing, storage, query and analytics, and application and activation.
Decoding turns raw bytes into typed events and calls, while indexing organizes them into reusable models. ABI history, entity labels, freshness, and reorg handling determine whether the data can be trusted.
Lean ETL, indexing engines, and data lake ELT serve different workloads. Choose the architecture according to how often questions change, the latency required, and how much infrastructure the team can operate.
Evaluate total cost across historical backfills, continuous ingestion, storage, compute, observability, replay, and engineering time, not only vendor pricing.
Offchain campaign and product events cannot be reconstructed from blockchain history, so capture them before they are needed.
Identity resolution links sessions, user IDs, and connected wallets; wallet intelligence enriches those profiles with multichain holdings, DeFi positions, labels, lifecycle, and attribution context.
Agentic analytics is moving crypto data from passive dashboards toward systems that can query, validate, visualize, and act. Reliable agents require documented schemas, permissions, citations, and auditability.
Most production stacks are hybrid, combining managed standard datasets with proprietary transforms and identity joins.
The hard part of blockchain analytics is not reading blocks. It is turning execution data into stable, documented, decision-ready models.
The crypto data and analytics landscape in 2026 is best understood as a six-layer pipeline: ingestion, decoding and normalization, indexing, storage, query and analytics, and application and activation. Finalized blockchain history is publicly verifiable, but useful analytics still depends on coverage, freshness, decoding quality, entity labels, and the ability to join onchain activity with offchain context such as sessions, campaign parameters, and wallet connections.
This guide maps the onchain analytics stack layer by layer, compares common pipeline architectures, and gives product and data teams a practical build-versus-buy framework.
What is the crypto data stack?
The crypto data stack is the infrastructure that converts raw blockchain execution data into structured datasets and product decisions. In this guide, we use a six-layer model. The boundaries are conceptual: many vendors span several layers, and a production system may combine layers in one service.
Raw records describe execution rather than business intent. Logs, traces, calldata, and state changes show what the virtual machine processed. They do not automatically tell an analyst that a wallet swapped through an aggregator, arrived from a campaign, or became a retained user. (decentralised.co)
Answering a question such as “How much of this week’s volume came from wallets acquired through a specific campaign?” requires both blockchain data engineering and offchain product telemetry.
The six layers of the onchain analytics stack
Layer | What it does | Representative tooling |
|---|---|---|
1. Ingestion | Syncs blocks, transactions, receipts, logs, traces, and selected state; manages finality and reorgs | Formo, Geth, Reth, Erigon, Alchemy, QuickNode, Helius, Blockjoy |
2. Decoding and normalization | Maps signatures and ABIs to typed events and calls; normalizes token standards and metadata | Formo, The Graph subgraphs, Ponder, Envio, Subsquid, custom decoders |
3. Indexing | Builds query-oriented entities such as transfers, swaps, balances, positions, and protocol actions | Formo, The Graph, Goldsky, Ponder, Subsquid, Allium |
4. Storage and warehousing | Persists historical and streaming data in partitioned, query-efficient formats | Formo, ClickHouse, BigQuery, Snowflake, Databricks, S3 and Parquet |
5. Query and analytics | Exposes models through SQL, APIs, notebooks, and semantic layers | Formo, Dune, Allium, Flipside, dbt, warehouse data shares |
6. Application and activation | Turns data into dashboards, alerts, attribution, wallet profiles, research, and agent workflows | Formo, Nansen, Arkham, Token Terminal, DefiLlama, MCP servers |
Each layer should publish clear schemas, ownership, freshness expectations, and reorg behavior. Skipping those contracts usually shifts cost into debugging, warehouse compute, or incorrect metrics. (allium.so)
Why is raw blockchain data difficult to analyze?
Raw blockchain data is difficult to analyze because it is encoded for execution, distributed across data types, and largely unlabeled. Four constraints account for much of the work.
Encoding and semantics. Event logs expose topics and data, while calls expose selectors and calldata. A signature hash can help classify an event, but an ABI or equivalent type information is needed to decode parameters reliably. Proxy upgrades and overloaded or reused signatures add more room for silent errors.
Identity and metadata. An address is not a customer record. Token decimals, symbols, contract types, proxy implementations, entity labels, and public identity links live in external or derived datasets and require ongoing maintenance.
Decoded data is not the same as indexed data. Decoding translates bytes into functions, events, and parameters. Indexing organizes those decoded records into reusable entities and metrics. ABI availability, proxy history, and version tracking therefore affect both coverage and confidence. (tiders.org)
Data volume. Retaining blocks, receipts, logs, traces, and state across high-throughput chains quickly creates warehouse-scale datasets. Multi-chain support multiplies storage, backfill, reconciliation, and quality-control work.
Freshness and finality. Low-latency applications want new data quickly, while analytics systems also need reorg corrections and stable historical models. Dune’s current documentation, for example, distinguishes raw data that typically arrives within minutes of finality, decoded data that commonly follows in 15 to 60 seconds, and curated tables that generally refresh hourly. That is a reminder to evaluate freshness table by table, not provider by provider. (docs.dune.com)
How do you evaluate crypto data quality?
A crypto dataset should be evaluated on more than row count or chain coverage. The useful test is whether a team can explain where each metric came from, how recently it was updated, and how errors are detected and repaired. (allium.so)
Coverage: supported chains, protocols, data types, historical ranges, and edge cases.
Correctness: ABI and proxy-version tracking, token decimals, duplicate handling, label accuracy, and reconciliation against canonical chain results.
Freshness and finality: latency by table, confirmation policy, reorg corrections, and the timestamp of the latest complete block.
Lineage and methodology: documented raw sources, transformations, entity definitions, label provenance, and price construction.
Repairability: idempotent backfills, versioned schemas, quality tests, and a clear process for correcting historical records.
What must be normalized across chains?
A multi-chain model needs explicit chain identifiers, address formats, block and event ordering, timestamps, token decimals, canonical asset identifiers, finality status, and raw as well as normalized amounts. It should also document how wrapped assets, bridges, protocol-specific position types, and missing prices are represented so cross-chain totals do not hide incompatible assumptions. (tiders.org)
What does crypto data engineering cost in 2026?
There is no universal 2026 price for a blockchain data pipeline. Chain throughput, retained data types, history depth, request patterns, latency, and reliability requirements determine the bill. Compare the complete workload across these cost areas:
Cost area | What creates cost | How to evaluate it |
|---|---|---|
Historical backfill | Blocks, receipts, logs, traces, state, and history depth | Scope by chain, block range, data types, compression, and retries |
Continuous ingestion | Request volume, streams or webhooks, confirmation policy, redundancy, and egress | Estimate average and burst volume, delivery guarantees, retention, and replay needs |
Self-hosted nodes and indexers | Hardware, storage, client upgrades, monitoring, reorg recovery, and on-call | Use fully loaded infrastructure and engineering cost, not the server bill alone |
Warehouse and compute | Retention, transforms, scans, concurrency, materialization, and egress | Test representative queries and model monthly storage and compute budgets |
Request current, workload-specific quotes and include engineering, observability, replay, data-quality testing, and incident recovery in the comparison. A lower infrastructure bill can still produce a higher total cost if the team must operate every layer itself.
The structural tradeoff still holds: owning raw data tends to scale with chain count and throughput, while consuming curated data tends to scale with the rows, requests, or compute a team actually uses.
Post-execution transforms
Most blockchain analytics pipelines transform committed outputs after canonical execution. They consume blocks, receipts, logs, traces, state diffs, and indexed entities without requiring a modified execution environment.
A post-execution transform consumes committed blockchain output such as blocks, receipts, logs, call traces, and state diffs. This is the default for most analytics pipelines.
Contract-focused indexers: Ponder and Envio let teams define event handlers and enrich indexed records before writing to a database. They fit bounded contract sets and application-specific models.
Managed streams and functions: QuickNode Streams and Functions can deliver selected blockchain data through server-side transformations without requiring a team to operate the full ingestion stack.
Bulk extraction: Cryo exports many raw EVM datasets to Parquet for local analysis with tools such as DuckDB. It is better suited to research and one-off extraction than a continuously operated product pipeline.
Cloud SQL platforms: Dune, Allium, and Flipside remove most warehouse operations. Freshness varies by dataset and product: Dune documents a staged model from raw to decoded to curated data, while Allium’s real-time API documents p50 freshness of roughly 3 to 5 seconds. (allium.so)
Warehouse delivery: Goldsky pipelines can filter and transform streaming blockchain data and sink it into PostgreSQL, ClickHouse, Kafka, S3-compatible files, and other destinations. (docs.goldsky.com)
Post-execution does not mean “block-level only.” Call traces, custom tracers, and state-diff APIs can expose transaction-level and sometimes instruction-level behavior. The limitation is that the chain only preserves the outputs and state required by the protocol; reconstructing a business metric that was never emitted may require expensive replay logic or protocol-specific interpretation.
What belongs in the offchain data layer?
The offchain side of a crypto data stack includes product and session telemetry, market and reference data, identity and social data, and risk or compliance labels. These sources add intent, acquisition context, price denominators, and entity meaning that chain state does not provide by itself.
Price enrichment needs an explicit methodology because no single exchange or liquidity pool is a canonical source of truth. USD-denominated metrics should state venue coverage, time weighting, liquidity filters, outlier handling, and what happens when a token has no reliable price. (tiders.org)
What tools track both onchain and offchain conversions for Web3 apps?
Tools that track both onchain and offchain conversions combine product analytics telemetry with blockchain reconciliation. They capture page views, sessions, referrers, UTM parameters, wallet events, and product actions, then join those records to confirmed contract activity. Formo, Spindl, Addressable, Cookie3, and some custom warehouse stacks serve parts of this workflow, but their scope and attribution methods differ.
Evaluate these products on five questions:
Can they link pre-wallet anonymous behavior to a wallet after connection or signed authentication?
Do they verify transactions and contract events onchain rather than trusting browser callbacks?
Can they model multi-step funnels, retention cohorts, revenue, and wallet-level segments?
Do they expose the joined data through exports, SQL, APIs, or agent interfaces?
How do they handle multiple wallets, shared devices, bot traffic, reorgs, and attribution windows?
The right product is the one whose identity model and event contract match the decisions your team needs to make, not the one with the longest feature list.
How do DeFi teams unify offchain and onchain data?
DeFi teams unify offchain campaigns with onchain revenue by creating an identity bridge between an anonymous session and a connected or authenticated wallet, then reconciling downstream transactions against canonical chain data. A reliable sequence looks like this:
Capture the landing page, referrer, UTM parameters, ad or partner identifiers.
Store product events under a durable anonymous session identifier.
On wallet connection or signed authentication, associate that session with the wallet while preserving the original acquisition touchpoints.
Ingest and decode relevant contract activity, including transaction status and reorg corrections.
Apply a declared attribution model, such as first touch, last touch, or a documented multi-touch rule.
Compute wallet-level revenue, activation, repeat activity, and retention cohorts from the joined event history.
The wallet connection event is a common bridge, not a perfect universal identity key. Users can connect multiple wallets, switch devices, use smart accounts, or share addresses across automated systems. Teams should document these edge cases and avoid presenting probabilistic identity resolution as deterministic fact.
This layer cannot be recreated later from blockchain history. A chain can show that a transaction happened; it cannot recover the campaign click, rejected signature prompt, abandoned onboarding session, or other product context that was never recorded. See Formo’s guide to unifying onchain and offchain data.
How does identity resolution work in crypto analytics?
Identity resolution connects anonymous sessions, authenticated user IDs, connected addresses, and linked wallets into a durable profile. The goal is not to claim that every address belongs to one person. It is to preserve relationships the product can verify and record the provenance of each link.
A defensible identity model timestamps every association, keeps original events immutable, supports one user with multiple wallets and devices, distinguishes explicit links from heuristics, and can merge or split profiles when evidence changes. Attribution rules should run on top of that identity graph rather than replacing it.
Formo documents attribution and identity as connected but distinct functions. (docs.formo.so) Read the guide to turning wallet addresses into user profiles.
What is wallet intelligence?
Wallet intelligence enriches an address with context that is useful for analysis and activation: token balances, DeFi positions, chain distribution, net worth, transaction history, protocol usage, labels, public identities, lifecycle stage, and activity inside the product.
Product analytics explains what a wallet did in your app. Attribution explains how it arrived. Wallet intelligence explains who the wallet appears to be and what it does across the supported onchain ecosystem. Joining the three enables segments such as high-value new users, lending users at risk of churn, or wallets acquired by a specific campaign. (docs.formo.so) Read What Is Wallet Intelligence?
How does DeFi portfolio data fit into wallet intelligence?
DeFi portfolio data is a current view of a wallet’s token balances and protocol positions by chain, asset, and application, usually enriched with USD values. A useful record includes the source, chain, protocol, asset identifier, quantity, valuation method, and refresh timestamp.
Portfolio data helps teams identify high-value users, understand protocol overlap, measure portfolio concentration, and segment wallets by holdings or app usage. It should not be treated as realized revenue or permanent identity because positions, prices, and ownership can change. (docs.formo.so) Read the wallet profiles growth playbook.
What role do ERC-8021 builder codes play?
ERC-8021 is a draft transaction-attribution standard that appends structured attribution data to transaction calldata. Base’s 2026 builder-code initiative uses the standard to help applications prove which transactions they originated and receive credit for their impact. (blog.base.org) (ethereum-magicians.org)
When a builder code is present and correctly propagated, it can turn some interface-level attribution from inference into an explicit onchain signal. It does not replace offchain product analytics: the code does not contain the full pre-transaction journey, campaign history, or funnel drop-off data.
Treat builder codes as one input to an attribution model. Verify adoption across wallets, routers, smart accounts, and relayers before assuming complete coverage.
How the market segments by buyer
Crypto data products segment more cleanly by buyer and decision than by technical layer. The same underlying chain data can power very different products.
Buyer | Typical requirements | Common buying pattern |
|---|---|---|
Financial institutions | Historical depth, market microstructure, compliance, reconciliation, SLAs | Enterprise contracts and data licenses |
Protocol and product teams | Funnels, retention, contract usage, attribution, wallet segmentation | SaaS tiers with usage-based expansion |
Developers and infrastructure teams | Multi-chain reads, low latency, stable schemas, reorg handling, uptime | Request, credit, or throughput-based pricing |
Researchers and publications | Curated datasets, reproducibility, citations, embeddable outputs | Free, discounted, or sponsored access |
Traders and retail users | Aggregated intelligence, alerts, watchlists, accessible interfaces | Freemium or subscription products |
This buyer lens explains why two vendors using similar data can differ dramatically in latency, interface, support, price, and acceptable error rates.
Agentic analytics is reshaping the 2026 crypto data landscape
Agentic analytics is the defining shift in crypto data in 2026. The interface is moving from dashboards and hand-written SQL toward agents that can interpret a question, inspect schemas, run queries, validate results, and trigger a follow-up action. Read Formo’s guide to agentic analytics for onchain growth. (read.cryptodatabytes.com)
From answers to actions. A useful analytics agent is not only a chatbot over a warehouse. It can investigate a retention drop, compare cohorts, create a chart, update a segment, or configure an alert through approved tools. This turns analytics from a reporting destination into an operational loop.
Semantic quality becomes infrastructure. Agents make query syntax cheaper, but they do not repair ambiguous event names, missing lineage, stale labels, or weak identity resolution. Documented schemas, stable metrics, freshness metadata, and attribution rules determine whether an answer is trustworthy.
Machine-readable access becomes a product surface. SQL endpoints, APIs, and MCP servers let agents discover data and capabilities programmatically. Structured inputs, deterministic outputs, citations, and project-scoped permissions matter as much as dashboard usability.
Human control remains necessary. High-impact actions should use explicit permissions, confirmations for destructive operations, auditability, and reversible workflows. The strongest platforms connect analysis to activation while keeping the boundary between a recommendation and an executed change visible.
Three architecture patterns for crypto data pipelines
The six layers can be assembled in three common patterns. Most production systems combine them, but naming the pattern makes cost, flexibility, and operational ownership easier to compare. (tiders.org)
Pattern and flow | Best for | Main tradeoff |
|---|---|---|
Lean ETL: extract and transform only required fields before loading | Bounded contracts and known metrics | Efficient, but less flexible when questions change |
Indexing engine: event handlers materialize reusable entities | Application-facing queries that repeat | Framework constraints and slower backfill iteration |
Data lake ELT: load broad raw and decoded data, then model it in a warehouse | Cross-chain research and evolving questions | Higher storage, compute, and operational cost |
A hybrid is common: use focused pipelines for product-critical metrics and a broader warehouse for exploration, reconciliation, and agentic analysis.
Build vs. buy: how should a team decide?
Build when the data or latency is a product differentiator. Buy when the dataset is standard and operational breadth matters more than custom control. Read the full Build vs Buy Analytics for DeFi Apps decision framework.
Prefer buying when… | Prefer building when… |
|---|---|
The same normalized dataset is needed across many chains | The transform encodes proprietary protocol or product logic |
Seconds-to-minutes latency is acceptable | Millisecond or execution-path latency is a core requirement |
The team lacks dedicated data-platform operations | The team can own nodes, replay, reorgs, quality tests, and on-call |
Query volume is variable or still being validated | Predictable scale makes vendor unit economics unfavorable |
Fast coverage and stable schemas create more value than control | A missing dataset or identity join is itself the competitive advantage |
The safest sequence is to prototype the question on a cloud SQL or managed data platform, validate that the resulting model changes a real decision, and only then decide whether to own the pipeline. Most production stacks are hybrid rather than purely built or bought.
Reference architecture for analytics in crypto
A typical 2026 blockchain data pipeline has two inputs that meet in an identity and attribution layer:
Onchain path: nodes or RPC → backfill and streaming ingestion → decoding → indexed entities → warehouse or query platform.
Offchain path: sessions, referrers, campaign parameters, product events, wallet connections, and signed authentication.
Join layer: identity resolution, attribution rules, governance, transaction reconciliation.
Consumption layer: SQL, APIs, MCP, dashboards, alerts, wallet profiles, and activation workflows.
The offchain path deserves early attention because it cannot be backfilled from the chain. Define event names, identifiers, attribution windows, privacy rules, and warehouse ownership before campaign data begins to matter.
Where Formo fits
Formo spans all six layers of this model. It ingests SDK, API, and smart-contract events; decodes and normalizes onchain activity; indexes analytical models; stores them in a managed warehouse; exposes them through query interfaces; and activates them in product, growth, and data workflows. (docs.formo.so)
Across the six layers, Formo manages contract and product event ingestion; ABI and transaction decoding; indexed event, session, source, revenue, identity, and wallet-profile models; and a managed analytics warehouse. Teams can access the data through analytics dashboards, wallet profiles, SQL and data access, and MCP. Formo also supports funnels, segments, alerts, exports, and agent workflows.
For implementation details, see Formo’s documentation for contract event ingestion and decoding, the data catalog and warehouse, MCP and agent tooling, and alerting workflows.
FAQs
What is a crypto data stack?
A crypto data stack is the infrastructure that converts raw blockchain execution data into queryable, decision-ready models. A practical six-layer view includes ingestion, decoding and normalization, indexing, storage, query and analytics, and application and activation.
What is the difference between blockchain indexing and querying?
Blockchain indexing organizes raw chain data into entities and tables optimized for retrieval. Querying reads and analyzes those models. Without indexing, many analytical questions would require repeatedly scanning blocks, logs, traces, or state.
Do I need to run my own node for onchain analytics?
No. Most teams use RPC providers, indexers, or curated data platforms. Running a node provides control and can improve unit economics at sufficient scale, but it adds client upgrades, storage, monitoring, reorg handling, redundancy, and incident response.
How much does it cost to backfill a blockchain?
Backfill cost depends on the chain, block range, throughput, and whether the job includes receipts, logs, traces, state, decoding, storage, and retries. Compare current workload-specific quotes and include engineering, observability, replay, and quality-control costs.
How do DeFi teams unify offchain campaign activity with onchain revenue and retention data?
They capture campaign and product events with a stable session or user ID, bind that ID to a wallet at connect or sign-in, verify contract events onchain, and model revenue and retention by wallet cohort in a shared warehouse or attribution platform. Define attribution windows, reorg handling, and privacy rules before launch.
What is offchain-to-onchain attribution?
Offchain-to-onchain attribution joins pre-transaction behavior, such as sessions, referrers, and campaign parameters, to a connected or authenticated wallet and then reconciles confirmed onchain outcomes. It measures which channels acquire wallets, where users abandon funnels, and how cohorts retain or generate revenue.
What tools track both onchain and offchain conversions?
Formo, Spindl, Addressable, Cookie3, and custom warehouse stacks can track parts of the onchain and offchain journey. Compare them by identity model, contract-event verification, attribution rules, funnel and retention support, data access, privacy controls, and reorg handling.
Can AI query blockchain data directly?
Yes. With structured APIs, SQL, and MCP servers, an agent can inspect schemas, generate and run a query, explain the result, and create a chart or alert when permissions allow. Accuracy still depends on schemas, labels, lineage, freshness, and guardrails.
Why is onchain data alone insufficient for product analytics?
Onchain data records submitted and confirmed activity. It does not contain unconverted sessions, referrers, campaign parameters, rejected prompts, or funnel abandonment. Those events exist only in offchain telemetry and cannot be reconstructed after the fact.
What are the main crypto data pipeline architecture patterns?
Three common patterns are lean ETL, indexing engines, and data lake ELT. Lean ETL is efficient for known metrics, indexing engines serve repeated application queries, and data lake ELT provides the most flexibility for cross-chain exploration. Many production teams combine them.
How do you evaluate crypto data quality?
Evaluate coverage, correctness, freshness and finality, lineage and methodology, and repairability. For multi-chain data, also verify asset mapping, token decimals, event ordering, wrapped assets, bridge treatment, and price rules.
What is identity resolution in crypto analytics?
Identity resolution links sessions, user IDs, connected addresses, and related wallets into a durable profile. Strong systems record how and when each link formed, distinguish explicit links from heuristics, and support profile merges or splits when evidence changes.
What is wallet intelligence?
Wallet intelligence enriches wallet addresses with context such as balances, DeFi positions, net worth, protocol usage, labels, public identities, lifecycle, and product activity. It complements product analytics and attribution by explaining who a wallet appears to be and what it does onchain.
What is DeFi portfolio data?
DeFi portfolio data is a current view of a wallet’s token balances and protocol positions across supported chains, usually enriched with USD values and refresh timestamps. It is useful for segmentation and portfolio analysis, but it should not be treated as realized revenue or permanent identity.
What is ERC-8021?
ERC-8021 is a draft transaction-attribution standard based on structured calldata suffixes. Builder codes can make an application’s role in originating a transaction explicit when the code is propagated, but they do not replace offchain campaign and product telemetry.
