On-Chain Dashboards
On-chain dashboards transform blockchain data into metrics such as active addresses, flows, fees, supply cohorts, TVL and protocol revenue. Their convenience is powerful, but every metr
Reading progress — saved on this device
Learning objectives
- Trace a dashboard metric back to its definition and underlying chain data.
- Distinguish addresses, entities, transactions, volume, fees and revenue.
- Cross-check material conclusions across queries or providers.
What it is and why it matters
Dashboards sit above raw explorers and data warehouses. They group transactions, label contracts and calculate business-style metrics. This saves enormous time but increases model risk because the researcher may not see the transformation steps.
Metric definitions should be read before values. “Active users” might mean unique sending addresses, addresses calling a specific contract, or labelled entities. “DEX volume” might include routed trades, self-swaps or aggregator paths differently.
Entity resolution is particularly difficult. One exchange can operate thousands of addresses while one person can operate hundreds of wallets. Address counts therefore measure addresses unless a defensible clustering method converts them into entities.
Time windows and chain reorganisations matter. Daily metrics require timezone boundaries; near-real-time dashboards may revise recent history when indexers catch up or labels improve. Reproducibility benefits from query versioning and snapshots.
Operational framework
| Check | Purpose | What to verify |
|---|---|---|
| Definition | Determines economic meaning | Read inclusion/exclusion logic before interpreting the number. |
| Source tables | Shows data lineage | Identify chain, contracts, labels and indexer tables used. |
| Entity method | Controls user counts | Check whether the metric counts addresses or clustered entities. |
| Revision risk | Affects reproducibility | Record query/version/date and expect recent data to update. |
Evidence, data quality and limitations
Provider disagreement is useful information. If two dashboards produce different fee or TVL numbers, compare definitions rather than averaging them blindly. The difference may reveal whether incentives, bridged assets or duplicated positions are included.
Public query dashboards can improve auditability because SQL or transformation logic is visible. Proprietary dashboards may still be high quality, but the analyst should record the provider’s methodology documentation and data timestamp.
Worked example and thought exercise
Dashboard A reports 500,000 monthly active wallets; Dashboard B reports 180,000. A defines active as any token transfer, while B counts addresses that directly interacted with the protocol’s core contracts. The numbers answer different questions.
A protocol shows £50m gross fees and £45m token incentives. Calling £50m “revenue” without distinguishing the economic recipient can materially overstate value capture.
Thought exercise: Why is disagreement between two dashboards often a reason to investigate definitions rather than choose the larger number?
Common mistakes and practical workflow
- Calling wallet counts “users” without qualification.
- Using a metric whose SQL or methodology is unknown for a material conclusion.
- Comparing revenue figures built from different definitions.
- Ignoring data revisions and indexer lag.
Practical workflow
- Write the research question before choosing a metric.
- Read the metric definition, chain scope and time window.
- Inspect query logic or methodology where available.
- Cross-check surprising results with raw transactions or a second provider.
- Record the query/provider version and timestamp used in the research note.
Knowledge checkpoint
- Why are wallets not equivalent to users?
- What is data lineage?
- How can provider disagreement improve research?
- Why should query versions be recorded?
FAQs
❓ Are on-chain dashboards primary sources?
They are derived from primary chain data; the transformation logic should still be evaluated.
❓ What is TVL?
A derived estimate of assets locked or supplied to protocols, with methodology that can vary by provider.
❓ Why can recent dashboard data change?
Indexers, labels, reorg handling and late data can revise recent history.
❓ Is visible SQL always correct?
No, but transparency makes assumptions easier to inspect and reproduce.
Summary
On-chain dashboards are research accelerators, not substitutes for methodology. Strong analysis begins with definitions, traces data lineage, distinguishes addresses from entities and cross-checks important conclusions against raw or independent data.
Want this in a personalised order?
Take the crypto assessment and get a custom path of 10 modules matched to what you already know. Free, no card required.
Build my path →