Crypto Data & Analytics Landscape: Data Stacks, Providers, and Attribution (2026)
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.
Use the Web3 data tools directory to compare providers across those layers.
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 |
What can each data tier answer?
Data tiers differ in the questions they support, and the jump in analytical value from raw to decoded is larger than the jump in engineering effort.
Tier | Questions it answers | Example metrics |
|---|---|---|
Raw | Network-level behavior, without protocol semantics | TPS, gas per transaction, mean block time, new accounts, daily unique signers |
Decoded | Protocol behavior and most application analytics | TVL, active users, deposits, liquidations, bridge flows, volume, revenue |
Transformed | Reusable business-level models stored to avoid recomputation | Swap-level datasets, protocol TVL series, curated trade tables |
Aggregated | Ecosystem totals across protocols and chains | Total DEX volume, DeFi TVL, sector-level user counts |
Raw data supports network monitoring but almost no product analytics. Decoding is therefore not an implementation detail: it is where chain activity becomes interpretable in the terms a product team uses.
Why do ecosystem aggregates have no shortcut?
Ecosystem metrics are built rather than queried. A metric is computed for one protocol, aggregated across protocols within a chain, and then aggregated across chains. Each step requires protocol-level models with compatible definitions, which is why cross-protocol and cross-chain aggregates are expensive and often worth buying.
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.
What are the three core raw datasets?
Most EVM analytics is built from three raw datasets, and knowing which one a metric depends on predicts much of its cost and latency:
Blocks and transactions. Top-level records containing sender, recipient, value, gas, and input data. They are the cheapest to acquire and are sufficient for many volume and activity metrics.
Logs and receipts. Events emitted during execution, tied to their transactions. This is where most protocol-level semantics live.
Traces. Full internal call paths for each transaction. They are the most expensive to acquire and store, and are needed for internal value movement, deployment, and multi-hop routing.
State and storage diffs form a fourth category for balance and position reconstruction. Cost and latency rise steeply across these categories, so scoping a pipeline to the narrowest sufficient dataset is usually the largest available cost lever.
Why does decoding depend on offchain data?
Smart contracts are stored onchain as EVM opcodes. Solidity compiles to those opcodes, but nodes retain no knowledge of the original source, so function names, parameter names, and output meanings are not present onchain. Recovering them requires an ABI generated at compile time and published offchain, commonly through a verification service or by the deploying team.
Where no ABI is published, activity remains visible but is not reliably interpretable. A pipeline that is otherwise self-hosted still inherits this offchain coverage dependency.
Approach | How it works | Tradeoff |
|---|---|---|
Manual ABI retrieval | Decode against an exact ABI match fetched or submitted for a contract | High confidence within coverage; fails silently by omission |
Algorithmic decoding | Match signatures against a broader ABI corpus, using shared contract code | Broader exploratory coverage; occasional signature mismatch |
Neither method is strictly better. The relevant evaluation question is which method a provider uses, because it predicts how the dataset fails.
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.
Decoding depends on ABIs published offchain, so even a self-hosted pipeline inherits a third-party coverage dependency.
Providers decode either by exact ABI match or algorithmic signature matching: the first fails by omission, the second by occasional mislabeling.
Blocks and transactions, logs and receipts, and traces have sharply different cost and latency profiles; use the narrowest sufficient dataset.
Backfill and frontfill are separate cost curves: history depth drives the first, ongoing throughput drives the second, and both multiply by chain count.
As block times compress, head lag, checkpointing, idempotent writes, and replay tooling become first-class reliability concerns.
The read path often depends on a small number of hosted providers, so fallback configuration and migration cost are availability questions.
Teams outgrow subgraphs when iteration reprocessing is too slow, enrichment is constrained, or GraphQL handles aggregation poorly.
Post-execution transforms cover most analytics needs, while re-execution can recover values computed during execution but never emitted.
View-function data is a clear build-versus-buy boundary because its indexing trigger encodes product-specific logic.
Account abstraction, intents, solvers, and cross-chain flows separate the transaction sender from the user, so attribution must decode rather than assume.
A wallet address is permanent, public, and shared across applications; joining it to other identifiers has materially different consequences from web2 tracking.
Outsourcing ranges from node access to finished metrics. Most application teams should buy raw delivery and own decoding and transformation onward.
Ecosystem aggregates are built protocol by protocol and chain by chain, making them strong candidates for buying.
Agents transact without sessions or referrers, so attribution that lives in calldata or authenticated API calls survives better than attribution that lives in a browser session.
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.
What do backfills and frontfills cost?
A backfill downloads historical data; a frontfill continuously keeps a pipeline current. Backfill is driven by history depth and chain size, while frontfill scales with ongoing throughput. Published January 2025 reference points are order-of-magnitude anchors rather than current quotes:
Item | Reported figure (January 2025) |
|---|---|
Base backfill: blocks and receipts | Roughly $10,000 undiscounted |
Base backfill: traces and logs | Roughly $4,000 after typical discounts |
Continuous frontfill | Roughly $2,000 per month |
Self-hosted Reth node on managed infrastructure | Roughly $650 per month |
Warehouse, transforms, and query | Roughly $4,000–$10,000 per month per chain |
Treat these as dated anchors, not quotes. The structural lesson is that a self-hosted node can be cheaper on invoices while shifting the difference into client upgrades, monitoring, replay, and on-call. See the 2025 Crypto Data Engineering Guide for the reference figures.
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.
How does faster block production change pipeline design?
As blocks arrive in the low hundreds of milliseconds and preconfirmations push effective latency lower, block-by-block batch assumptions become fragile. A transform or scheduled job that misses its window can fall behind faster than it can recover.
Batch work needs idempotent writes, checkpointing, and replay tooling so recovery does not compete indefinitely with the incoming stream.
Freshness and finality should be modeled separately: some surfaces can read pre-finality data, while analytical models need reorg-corrected history.
Head lag should be reported and alerted like an error rate. A pipeline can be technically healthy while silently drifting hours behind the chain tip.
What are the dependency risks in the read path?
Contract logic is permissionless and verifiable, but the application read path often runs through a small number of hosted providers. A fallback RPC, an inspectable indexer, and a credible migration path are availability controls rather than ideological choices.
Is there a fallback RPC, or does one provider outage take the application offline while the chain remains healthy?
Could the indexer be replaced in days, or is product-specific logic trapped inside a vendor framework?
Is the read path inspectable and self-hostable enough to audit, fork, or operate independently?
Does the frontend have a second distribution path, such as IPFS or Arweave, in addition to one host and DNS record?
Hosted services are often the right adoption choice at low volume. The risk is aggregate concentration, so provider redundancy belongs in the same operational category as backups.
Post-execution transforms
What are re-execution transforms?
A re-execution transform replays historical blocks in a modified execution environment to produce data the protocol never emitted. Post-execution transforms consume committed outputs; re-execution regenerates execution with added instrumentation.
Shadow events: emit values computed during execution but never logged, such as swap-time liquidity or liquidation health factors.
Execution hooks: capture storage writes, call traces, or pre- and post-state at transaction or instruction granularity.
Rewritten reads: replace view functions in a forked environment to batch or reshape reads without deploying a new contract.
Use post-execution when the data exists in logs, traces, or state diffs. Consider re-execution only when a value was computed in memory and discarded, or when reconstructing it afterward would require expensive protocol-specific logic. Representative tools include Shadow, Sim, ghostlogs, and TEVM.
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.
Why did teams move beyond subgraphs?
Subgraphs made declarative onchain indexing accessible: a manifest declares contracts and events, a schema defines entities, and mappings transform incoming records. Three limitations drove the emergence of newer indexers:
Backfill cost on iteration. Mapping changes generally require reprocessing history, which is slow and expensive on high-throughput chains.
Constrained enrichment. Mapping environments restrict standard libraries, arbitrary reads, and external enrichment.
Query model. GraphQL handles entity retrieval well but aggregation poorly, pushing analytical work downstream.
Ponder and Envio preserve the handler model while allowing standard libraries and owned databases; Goldsky and Subsquid emphasize pipeline delivery into external destinations. In production, teams commonly combine a managed standard dataset, a focused indexer for product-critical models, and direct extraction for one-off research.
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.
Why are view functions hard to index?
A view function reads and transforms state without modifying it. Nodes can execute these calls for free, but standard nodes generally answer against the latest state, not a historical series.
Historical outputs require an archive node or a sync from genesis with calls captured at the required points in time.
Outputs can be computed rather than stored. For a rebasing token, indexing every balance output can create billions of rows; indexing the underlying amount scale and rebase index stores the inputs instead.
There is no universal indexing cadence. A product may need a value every block, after a transfer, on a call trace, or on a schedule.
View-function data is therefore a clear build-versus-buy boundary: the indexing trigger encodes product-specific logic that a general provider cannot anticipate.
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.
What are the measurement layers, and what can each one not do?
Compare related analytics approaches in Formo’s comparison guides and explore crypto product analytics.
Category | Answers | Structural limit |
|---|---|---|
Web analytics | Who arrived, from where, and on what | Stops at the page; no wallet or transaction |
Product analytics | What users did in the app and where they dropped | Session-scoped; cannot verify settlement |
Onchain analytics | What addresses did onchain and at what volume | Starts at the transaction; no acquisition context |
Attribution | Which channel or partner produced a wallet or fee | Depends on the identity join beneath it |
Wallet intelligence | What an address appears to do across the ecosystem | Describes the address, not its product relationship |
The key gap is between product analytics and onchain analytics. Product analytics ends at the signature prompt; onchain analytics begins at the confirmed transaction. Neither owns the join, which is why teams can run both tools and still fail to answer which campaign produced revenue.
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.
Where does offchain-to-onchain attribution break?
See Formo’s builder-code tools and the guide to onchain attribution systems.
Attribution breaks wherever the address submitting a transaction is not the address representing the user. Account abstraction, intents, cross-chain flows, and embedded wallets make this common rather than exceptional.
Account abstraction: under ERC-4337, the top-level sender can be a bundler. Decode the user operation to recover the smart account.
Intents and solvers: the executing address belongs to a solver and a settlement transaction may batch several users.
Cross-chain flows: origin and destination records are disconnected without an explicit correlation identifier.
Embedded and in-app wallets: the browser session may never expose a referrer, landing page, or connection event.
The durable response is to decode rather than assume: store user account, solver, router, and settlement path separately; propagate correlation IDs across chains; use calldata-level attribution such as ERC-8021 where applicable; and report unattributed coverage instead of silently redistributing it.
What data leaves the client when a user connects a wallet?
A wallet address is permanent, public, and shared across applications. Joining it to an IP address, email, or device fingerprint in a third-party system can deanonymize the address retroactively and permanently.
Teams can audit this directly: record browser network traffic, compare origins before and after connection, identify which requests include the address, and repeat after signing. Keep identity joins first-party where possible, aggregate when individual identity is unnecessary, and audit connect-time payloads when analytics or screening scripts change.
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.
What can be outsourced, and at which layer?
Service type | What it removes | What you still own |
|---|---|---|
Node as a service | Running and maintaining clients per chain | Request pipelines, decoding, transformation, storage |
Raw stream | Request pipelines and bulk delivery | Decoding, transformation, storage |
Decoded stream | ABI maintenance and decoding | Transformation, storage, metric definitions |
Indexed data API | The pipeline through finished metrics | Only the questions and definitions you need |
Outsource undifferentiated operational work and own the layers where product meaning lives. For most application teams that means buying node access and raw delivery while keeping decoding, transformation, and metric definitions portable.
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 |
The data lake workflow is explore, filter, and model: explore broad datasets to identify relevant contracts and events, filter unified schemas to the scope that keeps compute manageable, then model reusable protocol and business tables from raw, decoded, offchain, and custom sources. Online SQL platforms are managed interfaces onto this architecture; evaluate whether submitted queries become part of the platform’s reusable asset base when query logic is proprietary.
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.
Frequently asked questions
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.
Why can’t all blockchain data be decoded?
Contracts are stored as opcodes, and nodes do not retain the original Solidity source. Decoding requires an ABI published offchain; where none exists, activity is visible but not reliably interpretable.
What is the difference between manual and algorithmic decoding?
Manual retrieval uses an exact ABI match and fails by omission outside its coverage. Algorithmic decoding matches signatures against a broader ABI corpus and offers more coverage with a risk of mismatch.
What is the difference between a backfill and a frontfill?
A backfill downloads historical blocks as a one-time cost. A frontfill continuously syncs the chain tip and scales with ongoing throughput.
How do faster block times affect data pipelines?
Batch assumptions become fragile. Idempotent writes, checkpoints, replay tooling, and head-lag alerts become design requirements.
Why do teams migrate away from subgraphs?
History reprocessing is slow, enrichment is constrained, and GraphQL handles aggregation poorly. Newer indexers relax one or more of those constraints.
What is the difference between post-execution and re-execution transforms?
Post-execution consumes committed outputs; re-execution replays blocks in an instrumented environment to generate values the protocol never emitted.
Why is indexing view functions difficult?
Standard nodes serve the latest state, outputs may be computed rather than stored, and each product must choose its own indexing trigger.
How does account abstraction affect analytics and attribution?
The transaction sender can be a bundler rather than the user, so systems must decode user operations to recover the smart account.
Why do intents and solvers break onchain attribution?
The executing address belongs to the solver, and a settlement may batch multiple users. Attribution must distinguish solver execution from user intent.
What parts of a data pipeline can be outsourced?
Node access, raw streams, decoded streams, and indexed APIs are progressively more complete outsourcing levels. Most teams buy raw delivery and own decoding onward.
Why is ecosystem-level data such as total DEX volume expensive?
It is built protocol by protocol, then chain by chain, with consistent definitions at every step; there is no shortcut to the aggregate.
Can you measure users when the user is an AI agent?
Partially. Browser funnel signals disappear, but transaction activity and authenticated API access remain measurable. Attribution should move into calldata or authenticated requests.
