Key Takeaways
- What it is: The tradeoffs among self-hosted nodes, block explorers, provider APIs, SQL warehouses, curated datasets, and commercial metric platforms.
- How it is built: Each source applies a distinct ingestion, normalization, labeling, pricing, and revision process before exposing data.
- Core expression: Research reliability = source coverage × definition clarity × reproducibility × freshness × revision transparency.
- Best use: Select the source according to the question: nodes for primary verification, explorers for investigation, warehouses for custom queries, curated platforms for cross-chain consistency, and specialist providers for entity-adjusted metrics.
- Main limitation: Free tiers may delay or limit records; commercial formulas may be proprietary; chain reorganizations can revise recent data; provider coverage differs; historical backfills can change results.
- Practical rule: Before trusting a headline number, confirm which data source produced it, whether recent blocks could still be revised by a reorg, and whether the underlying formula is open enough to verify independently.
Who This Guide Is For
Every on-chain number reaches you through a supply chain, and most disagreements between charts are explained by where in that chain each one was produced. This page is about that chain: node, indexer, API, warehouse, and dashboard.
Read it before choosing a data source for a project, and before trying to reconcile two figures that should match. Its companion pages cover adjacent questions: what the discipline can establish at all, and what specifically goes wrong with numbers once you have them.
Educational content. Not individualized financial advice.
What Does On-Chain Data Sources Measure?
This page is not about a metric. It is about provenance: which system produced a number, what that system could see, and what it had to assume.
The distinction that matters most is between data the chain contains and data someone attached to it. Block headers, transactions, and state are contained. Entity labels, USD prices, protocol categories, and contract names are attached. Contained data is reproducible by anyone with a node. Attached data is a private dataset belonging to whoever built it, and it is where providers differ most.
Plain-language definition
An on-chain data source is whatever system read the blockchain, transformed what it found, and handed you a number. The transformation is the part worth knowing about.
The five layers
- Node. Validates and stores the chain. The ground truth.
- Indexer. Reorganizes chain data into queryable structures.
- Enrichment. Attaches labels, prices, and categories that are not on the chain.
- API or warehouse. Serves the enriched data.
- Dashboard. Presents a specific transformation as a chart.
Each layer can introduce error the layer above cannot detect, and only the first is verifiable without trusting someone.
How Is On-Chain Data Constructed?
Full node versus archive node
A full node validates every block and holds current state, but prunes historical intermediate states. It can tell you what happened in any block and what the state is now. It cannot tell you what an account balance was at block 12,000,000 without replaying from genesis.
An archive node retains every historical state and can answer point-in-time questions directly. It costs substantially more in storage. Any metric requiring historical balances, which includes most supply and holder metrics, requires archive access somewhere in its lineage.
Indexers
Chain data is stored for validation, not for querying. Answering a question like all transfers of a token in March requires reorganizing it into tables or a graph. Indexers do this and introduce two failure modes: indexing lag, where recent blocks are not yet queryable, and decoding errors, where contract events are misinterpreted because the interface definition was wrong or absent.
Enrichment
Labels and prices originate off chain. An exchange wallet label is somebody's inference, usually from a mix of public disclosure, deposit-address clustering, and manual research. It can be wrong, it is rarely audited, and it changes retroactively when the provider improves it. Price data comes from markets and inherits their liquidity, gaps, and outages.
Access patterns
- RPC. Direct node queries. Precise, slow for aggregate questions, and rate limited by whoever hosts the node.
- Indexed query interfaces. Good for entity-scoped questions such as one protocol's events.
- SQL warehouses. Good for aggregate questions across the whole chain, and the usual home for community-written queries whose assumptions are visible.
- Metric APIs. Precomputed series. Convenient, and the transformation is someone else's.
Formula and Measurement Logic
There is no formula here. The equivalent artifact is a provenance record, and it should accompany any number you publish.
Provenance = chain + block range + node type + indexer + enrichment sources + query + retrieval timestamp
The retrieval timestamp is not optional bookkeeping. Because upstream layers revise, the same query run twice can return different answers, so a figure without a retrieval date cannot be reproduced even by the person who produced it.
| Layer | Answers well | Cannot answer | Trust required |
|---|---|---|---|
| Full node | What is in a block; current state | Historical state; aggregates | None |
| Archive node | Point-in-time state | Aggregates without an index | None |
| Indexer | Filtered queries over decoded data | Anything not decoded correctly | Decoding correctness |
| Enrichment | Entity and price questions | Anything the labels miss | Label and price accuracy |
| Metric API | Ready-made series | Variants outside the published set | The full transformation |
How Should On-Chain Data Sources Be Interpreted?
Match the layer to the claim. The rule is that the strength of a conclusion should not exceed the verifiability of the layer it came from.
- Claims about what happened. A transaction occurred, a contract was called, a balance changed. Verifiable at node level by anyone. These are the strongest claims available and should be sourced accordingly.
- Claims about who did it. An exchange received a deposit, a whale accumulated. These depend entirely on labels, which are private inferences. State the label provider and treat the claim as conditional on it.
- Claims about value. Anything denominated in currency depends on a price feed and its timestamp convention. For illiquid assets the price may not be realizable at size.
- Claims about categories. DeFi volume, gaming activity, and similar aggregates depend on somebody's classification of contracts into buckets. That taxonomy is editorial and rarely published in full.
When two sources disagree, the productive move is to identify which layer they diverge at rather than to decide which is right. Two indexers reading the same node will agree on transfers and can disagree completely on exchange flows, because the difference lives in the label set and nowhere else.
Step-by-Step Workflow
- Identify which layer produced the number you have.
- Determine whether the claim requires historical state, and if so confirm archive access exists in the lineage.
- Separate the contained part of the claim from the attached part.
- Record the label provider and its most recent update for any entity-based claim.
- Record the price feed and timestamp convention for any currency-denominated claim.
- Record the retrieval timestamp, since upstream layers revise.
- Reproduce a bounded sample at a lower layer before publishing a strong conclusion.
Worked Hypothetical Scenario
Three sources report exchange inflows for the same day.
| Source | Reported inflow | Layer |
|---|---|---|
| Provider A | 18,400 BTC | Metric API, own label set |
| Provider B | 11,900 BTC | Metric API, own label set |
| Own query | 12,050 BTC | SQL warehouse, public label list |
The instinct is to average them or pick the one that fits the argument. Both are wrong, because the spread is 55 percent and an average of three differently-specified quantities is not a better estimate of any of them.
Descend a layer instead. Pull the underlying transfer list from each and compare address sets. In practice the answer is usually that one provider's label set includes addresses the others classify differently, most often a custodian that is not an exchange, or deposit addresses attributed to an exchange before they have been confirmed as such.
Note what all three agree on: the transfers themselves. Every source reads the same blocks and none of them disagree about what moved. The entire 6,500 BTC spread is manufactured at the enrichment layer, from a dataset that is not on the chain, is not audited, and can change retroactively. That is the finding, and it is more useful than any of the three numbers.
What Can Make the Interpretation Wrong?
- Treating a metric API figure as chain data. It is a transformation of chain data by someone else, and the transformation is where the disagreement lives.
- Averaging disagreeing providers. They are computing differently specified quantities, so an average is not a better estimate of any of them.
- Assuming labels are stable. Label sets are revised, and revisions apply retroactively, so a chart can change shape in the past.
- Missing indexing lag. Recent blocks may not be queryable yet, so a query run too soon reports a partial period as a decline.
- Silent decoding failures. An indexer without a correct interface definition can miscount or omit events entirely, and the query returns a clean-looking result.
- Full-node limits on historical questions. Point-in-time balance questions need archive state, and asking them of a pruned node produces errors rather than obviously wrong answers.
- No retrieval timestamp. Without it, a figure cannot be reproduced, because upstream layers revise.
Cross-Network and Provider Comparison
Data availability differs enough by chain that the same analysis is easy on one and impractical on another.
Bitcoin's data model is small and stable. The UTXO set is well understood, tooling is mature, and running a full node is within reach of ordinary hardware, so independent verification is genuinely available to individuals. There is little to decode because there is little contract execution.
Ethereum and similar account chains require contract decoding for most interesting questions, which means an interface definition for every contract of interest. Where that definition is absent or wrong, activity is invisible or miscounted, and this is the single largest gap in account-chain data quality. Archive nodes are expensive, so most analysts depend on hosted providers for historical state.
High-throughput chains produce data volumes that make independent indexing costly, which concentrates the analyst population onto a small number of providers and reduces the practical ability to cross-check.
Rollups add a settlement question: data may be available on the rollup, on the base layer in compressed form, or through the sequencer, and which of these a source reads determines what it can see and how quickly.
Advanced Analytical Methods
Running your own node
The only way to remove trust from the base layer. It resolves nothing about labels or prices, which remain external, but it makes the contained portion of any claim independently verifiable.
Cross-layer reconciliation
Reproducing a provider's series for a bounded window from a lower layer quantifies the gap. Doing this once for any series you rely on regularly is worth more than comparing several providers against each other.
Label set diffing
Where providers publish address lists, comparing them directly identifies exactly which entities drive a disagreement. This converts an unresolvable difference of opinion into a specific, checkable list of addresses.
Query version control
Storing the query text, the block range, and the retrieval timestamp together makes a figure reproducible. Without all three, a number cannot be recovered once upstream data has been revised.
Provider redundancy for critical series
Where a conclusion matters, computing it from two independent lineages and treating the spread as an error bar is more honest than reporting a single figure to four significant digits.
Practical Checklist
- I know which layer produced this number.
- I confirmed archive access exists if the claim needs historical state.
- I separated the contained part of the claim from the attached part.
- I recorded the label provider and its last update.
- I recorded the price feed and timestamp convention.
- I recorded the retrieval timestamp.
- I checked for indexing lag before reading a recent period.
- I reproduced a bounded sample at a lower layer.
- I did not average disagreeing providers.
Frequently Asked Questions
What is the difference between a full node and an archive node?
A full node validates every block and holds current state but prunes historical intermediate states, so it can tell you what happened in any block and what state is now. An archive node retains every historical state and can answer point-in-time questions directly, at substantially higher storage cost. Most supply and holder metrics need archive access somewhere in their lineage.
Why do two providers report different exchange flows from the same chain?
Because the transfers are contained in the chain and the entity labels are not. Both providers read identical blocks and agree about what moved. The disagreement is manufactured at the enrichment layer by different address attributions, which are private inferences that are rarely audited and can change retroactively.
Should disagreeing data providers be averaged?
No. They are computing differently specified quantities, so an average is not a better estimate of any of them. The productive move is to descend a layer, compare the underlying transfer lists or address sets, and identify exactly where the specifications diverge.
What is indexing lag and why does it matter?
Chain data is stored for validation rather than querying, so an indexer must reorganize it into queryable structures. Recent blocks may not be queryable yet, which means a query run too soon reports a partial period. The characteristic symptom is an apparent decline in the most recent data.
Why can a growing protocol show almost no on-chain activity?
Contract activity is only visible if the interface definition is known to the indexer. A newly deployed contract with no published interface is invisible until someone adds it. When the definition is added, the historical series is rewritten upward with no change in real activity.
Why does a figure need a retrieval timestamp?
Because upstream layers revise. Label sets are improved retroactively, ingestion gaps are backfilled, and decoders are corrected. The same query run twice can return different answers, so a figure without a retrieval date cannot be reproduced even by the person who produced it.
What can be verified without trusting anyone?
Only what the chain contains: block headers, transactions, and state. Anyone running a node can verify these independently. Entity labels, currency prices, protocol categories, and contract names are attached rather than contained, and every claim resting on them is conditional on somebody private dataset.
What is the difference between an RPC endpoint and an indexed dataset?
An RPC endpoint answers point queries against a node: the balance of an address, the contents of a block, the result of a contract call. It is authoritative and slow for anything requiring a scan, because it was not designed to answer questions across millions of blocks. An indexed dataset is a transformation of the same data into a form that supports querying across history, built by someone who made decisions about schema and coverage. Analysis needs the second; verification uses the first.
Why do rate limits shape which analyses are practical?
Because many legitimate questions require far more requests than a provider will serve. Reconstructing the balance history of a large address set, or tracing the sources of every deposit to an exchange, can mean millions of calls. Rate limits push analysts toward indexed products, whose definitions they must then accept, or toward sampling, which introduces its own bias. The constraint is worth stating in a methodology note, because it explains why an analysis covers the scope it does.
References
These sources should be reviewed during editorial verification. They support data structures and methods, not the hypothetical conclusion. Provider formulas, chain rules, and APIs can change; confirm current documentation before publication.
- Bitcoin Developer Guide: Block Chain: Bitcoin ledger, blocks, proof of work, and transaction history.
- Bitcoin Developer Guide: Transactions: UTXO transaction construction and spending.
- Ethereum.org: Technical Introduction: Accounts, execution, proof of stake, and smart contracts.
- Ethereum.org: Transactions: Ethereum transaction fields and execution.
- Coin Metrics: Network Data Glossary: Cross-network address, account, ledger, and UTXO definitions.
- Coin Metrics: Getting Started With Data: Network, market, index, and reference data.
- Dune: Data Explorer and Raw Tables: Blocks, transactions, logs, traces, and decoded data.
- Dune: Address Labels: Address labeling and entity context.