# Designing an On-Chain Data Dashboard: What to Show, What to Skip > A practical guide to designing on-chain data dashboards for DeFi protocols — which metrics matter, how to structure the data layer, and what most teams get wrong. - **Published:** 2026-05-21 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** on-chain-dashboard, blockchain-analytics, defi-metrics, data-visualization, product - **Canonical URL:** https://clixo.sh/blog/on-chain-data-dashboard-design-guide Most protocol dashboards are built reactively: someone asks "can we see TVL over time?" and a developer queries the subgraph, formats the result, and adds a line chart. Six months later, the dashboard has fourteen charts, loads slowly, and nobody looks at it except to screenshot the TVL chart for a tweet. A well-designed on-chain data dashboard is a product decision before it is an engineering decision. The data layer choices you make when building it will either support or constrain what you can show, how fast it loads, and how accurately it reflects chain state. ## Start With the Question, Not the Data The most common dashboard design mistake is starting from available data. The subgraph exposes swap entities, so you chart swaps. It exposes liquidity positions, so you chart those too. The result is a dashboard that displays everything and answers nothing. 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 is the correct architecture for any dashboard with meaningful traffic or complex aggregation requirements. **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. For a protocol beyond early access with real user traffic, option 2 is the right default. The infrastructure cost is low; the operational flexibility is high. ```mermaid flowchart LR A["Blockchain\nnodes"] --> B["Indexer\n(subgraph / custom)"] B --> C[("Analytics DB\nPostgres / TimescaleDB")] C --> D["Materialized views\n(pre-aggregated)"] D --> E["Dashboard API"] E --> F["Protocol dashboard\n(TVL, volume, APY)"] B -->|"early stage"| F ``` ## 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: Why Most Dashboards Are Slow Dashboard slowness is almost always a data layer problem, not a frontend problem. The common causes: **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. --- A good on-chain dashboard is an investment in protocol credibility and operational visibility. If you are building the analytics layer for a DeFi protocol and need help designing the data model, the pipeline, and the dashboard together, [Clixo](https://clixo.sh/#contact) builds full-stack on-chain analytics systems. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)