Lesson 6 — Dune dashboards and SQL literacy: reading analytics skeptically
Dune is the public-square of on-chain analytics. Today: how to read a dashboard for what it shows, what it hides, and which parameters are doing the work.
Dune Analytics is where most public on-chain dashboards live. The platform is genuinely valuable — you can run SQL queries against decoded blockchain data and visualize the results — but every dashboard is built by someone with a point of view, and the parameter choices decide what the visualization shows. Reading dashboards skeptically means understanding the queries underneath, not just the charts on top.
**What Dune is.** Dune Analytics ingests data from major chains (Ethereum, Optimism, Arbitrum, Polygon, BNB Chain, Solana, others), decodes it using contract ABIs, and exposes the result as SQL-queryable tables. Users write queries, save them, and combine them into dashboards. The platform has a free tier with rate limits and paid tiers with more compute. The data is the same data you could query yourself by running a node and decoding logs — Dune just makes the decoding pre-done and the query interface accessible.
**The schema you're querying.** Dune exposes tables like `ethereum.transactions`, `ethereum.logs`, `ethereum.traces`, plus chain-specific decoded tables (`uniswap_v3_ethereum.Pool_evt_Swap`, `aave_v3_ethereum.Pool_evt_Supply`, etc.). Each decoded table is generated from a contract's ABI: every event becomes a table, every function call becomes a table. The decoding pipeline is maintained by Dune's team and the community; mistakes in decoding occasionally produce wrong data, but the open-source nature of the queries means errors get caught and fixed publicly.
**Reading a dashboard for parameter choices.** Every dashboard is shaped by a few key parameter decisions. (1) Time window — '24 hour volume' looks very different from '30-day volume' for the same protocol. (2) Filters — does the query exclude specific addresses (e.g., known wash-traders) or include everything? (3) Joins — combining transactions with token-price data introduces dependencies on a separate price oracle, which can be a few percent off. (4) Aggregations — sum, count, median, percentile all tell different stories about the same data. A dashboard that prominently displays '24-hour volume: $50M' might be using a definition of 'volume' that includes wash trades, or excluding them; the only way to know is to read the underlying query.
**Click through to the query.** Every chart on Dune has a 'Query' link below it. Clicking shows the SQL. Even non-SQL-literate users can usually read the FROM, WHERE, and GROUP BY clauses to understand what data is included and how it's aggregated. The most useful single check on any 'official' dashboard is to read the query for the most-prominent number and ask: would I have made the same parameter choices? Choices that minimize the displayed number (excluding wash-trade addresses, narrowing the time window, filtering to specific user types) are common in marketing dashboards; choices that maximize the number are common in dashboards built by holders trying to support a narrative.
**The trust hierarchy.** Not all dashboards are equal. (1) Dashboards built by the protocol's own analytics team — usually reliable for the underlying data but biased toward favourable framing. (2) Dashboards built by independent on-chain analysts with public reputations (e.g., hildobby, hagaetc, kingosmus on Dune) — usually careful about parameter choices, with documentation explaining them. (3) Dashboards built by anonymous users with no track record — can be excellent or terrible; check the query before trusting the numbers. (4) Dashboards built by the protocol's competitors or detractors — bias in the opposite direction. The healthy approach: cross-reference numbers across multiple dashboards from different perspectives.
**Common manipulation patterns in dashboards.** Three to watch for. (1) **Cherry-picked time windows** — a chart starting at a deliberately-chosen low point makes growth look explosive. Look for dashboards that show data across multiple zoom levels so you can verify the long-term picture. (2) **Volume that includes self-trading** — a token's '24-hour volume' on a DEX can include wash trades by insider wallets. Volume excluding known wash-trader addresses (when possible) is the honest number. (3) **TVL inflation via double-counting** — a protocol that allows recursive deposits (lend, borrow, lend again) can show TVL that's 3–5× the actual underlying capital. DeFiLlama's TVL methodology explicitly excludes most double-counting; protocol-built dashboards often don't.
**Beyond Dune.** Other public on-chain analytics platforms worth knowing: **Flipside Crypto** (similar SQL model, different chain coverage), **Allium** (more focused on institutional analytics), **Footprint Analytics** (visualization-heavy alternative), **Token Terminal** (focuses on protocol financials — revenue, fees, P/E-equivalent metrics). For Solana-specific work, **TopLedger** and **Helius** offer indexed Solana data. Each platform has its own coverage gaps and decoding quality; serious research often uses two or three in combination.
Example
Compare two Dune dashboards on the same DEX's 24-hour volume. Dashboard A (built by the DEX's team): '24-hour volume: $120M'. Click through to the query — it sums every Swap event on the protocol contracts with no exclusions. Dashboard B (built by an independent analyst): '24-hour volume (excluding wash-trader addresses): $42M'. Same data source, different methodology. The independent dashboard excludes 47 addresses that have been algorithmically identified as wash-trading based on their swap patterns (sub-second round-trips, identical sizes, paired addresses). The 'real' volume — by the more honest definition — is about a third of the protocol's marketed number. Neither dashboard is technically wrong; the parameter choice is doing the work. Knowing which definition to trust for which purpose is the literacy that makes the dashboards genuinely useful.
Common mistakes
- Reading the chart without reading the query. The chart is the conclusion; the query is the evidence.
- Treating one dashboard as authoritative. Cross-referencing across multiple analysts with different incentives is the discipline.
- Believing 'volume' is a uniformly-defined number. Different methodologies produce different numbers from the same data.
- Trusting time windows uncritically. A 24-hour window starting at a deliberate low gives different conclusions than a 7-day window.
- Ignoring the difference between official and independent dashboards. Both have value; both have biases.
- Forgetting that Dune itself depends on decoding correctness. When the decoding pipeline lags or breaks, downstream queries return stale or wrong data.
Check your understanding
A protocol's official Dune dashboard prominently displays '7-day volume: $2.5B'. The query, when you click through, sums every Swap event with no exclusions. An independent analyst's dashboard on the same data shows '$680M, excluding 23 wash-trader addresses identified by sub-second round-trip patterns.' What is the appropriate response?
Key terms covered
Sources & further reading
- Primary
- Primary
- Primary
- Primary
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.