Designing an On-Chain Data Dashboard: What to Show, What to Skip
Plan a DeFi dashboard around stakeholder questions, metric freshness, indexing choices, query performance, and documented calculations.
An on-chain dashboard should answer defined questions about protocol activity, risk, or operations. Choose metrics and freshness requirements first, then select an indexing and aggregation design that can supply them.
Start With the Question, Not the Data
Available subgraph entities are a starting point, but do not determine which charts users need. Define the question before building the chart.
Start from the questions your stakeholders actually need to answer:
- Is the protocol growing? (Needs: unique user count, new depositors, week-over-week growth)
- Where is risk concentrated? (Needs: position size distribution, liquidation proximity)
- Which pools or markets are performing? (Needs: volume per pool, fee revenue, APY)
- Is the protocol functioning correctly? (Needs: revert rates, oracle deviation, liquidation lag)
Map each question to a specific metric. Only build the chart if you can define: what data feeds it, how frequently it updates, and who looks at it and why.
Designing the On-Chain Data Dashboard: Metric Taxonomy
Group your metrics by update frequency and importance:
Real-time (per block): current TVL, current utilization rates, recent transactions. These need low-latency data and should be cached aggressively — do not query your indexer on every page load.
Hourly/daily aggregates: volume, fees earned, new users, liquidations. These can come from pre-computed materialized views in your analytics database, refreshed on a schedule. They do not need to be live.
Historical trend lines: 7-day rolling volume, TVL since inception, cumulative fees. Compute these in advance and serve them as static or near-static datasets. A chart that covers 18 months of history does not need to re-query the chain on every render.
Separate these categories in your data architecture. Real-time and aggregate metrics have different freshness requirements, different query patterns, and different infrastructure needs.
The Data Layer for a Protocol Dashboard
Option 1: Query the subgraph directly. Suitable for early-stage dashboards. Works with no additional infrastructure. Limitations: GraphQL query latency can be high for complex queries, you are dependent on subgraph sync lag for freshness, and heavy queries affect other consumers of the same endpoint.
Option 2: Maintain a separate analytics database. Stream indexed events from your subgraph or indexer into a Postgres or TimescaleDB instance. Run pre-aggregated views. Serve the dashboard from your own API. This adds control over aggregations and caching, with another pipeline to operate.
Option 3: Use a third-party analytics platform. Dune Analytics is well-suited for community-facing dashboards where you want community contributions and public visibility. It is not appropriate for private operational dashboards or metrics requiring sub-minute freshness.
A separate analytics database is worth evaluating when direct indexer queries cannot meet the dashboard’s latency or aggregation needs.
What to Show on a DeFi Protocol Dashboard
For a lending protocol:
- Total supplied and total borrowed by asset
- Utilization rate per market (critical for risk monitoring)
- Top positions by size (useful for risk teams and community transparency)
- Historical liquidation volume
- Interest rate history per market
For a DEX:
- Volume by pool (24h, 7d)
- Liquidity depth per pool over time
- Fee revenue by pool and in aggregate
- Top traders by volume (if community-appropriate)
- Slippage distribution for recent swaps
For a yield protocol:
- Total value deposited per strategy
- APY by strategy (with methodology note — state how it is calculated)
- Depositor count and net flow (inflows minus outflows)
- Harvest events and compounding frequency
Avoid showing metrics you cannot explain. If someone asks "what does this number mean exactly?" and the answer requires a footnote, consider whether the metric belongs on a public dashboard.
Performance Checks
Measure query time, response size, and frontend rendering separately. Data-layer causes to check include:
Querying without caching: every dashboard page load fires a GraphQL query that scans thousands of entities. Add a server-side cache layer with a TTL appropriate for each metric's freshness requirement (30 seconds for near-real-time, 5 minutes for hourly aggregates).
On-demand aggregation: computing "total volume for the last 30 days" by summing swap entities at query time. Pre-compute this in a materialized view and refresh it on a schedule.
Fetching full entity history for a chart: loading 18 months of daily data points at render time. Pre-bucket this into daily aggregates in your database and serve it as a small, fixed-size array.
No pagination or result limits: a GraphQL query that returns all swaps for a pool with no first limit. Always paginate or limit event queries.
The Correctness Problem
On-chain dashboards are expected to be accurate. Users notice when TVL on your dashboard differs from TVL on DeFiLlama or Dune. Before launch:
- Verify your TVL calculation methodology is documented and defensible
- Cross-check key metrics against independent sources (block explorer data, alternative indexers)
- Make it clear on the dashboard what the data represents: is this "TVL as of last block" or "TVL as of 5 minutes ago"?
Transparency about methodology and data freshness is more credible than pretending the numbers are perfectly real-time.
For help with a protocol dashboard’s data model and query pipeline, contact LinkIT.