System Overview

Purpose

The Vol Dashboard is an internal trading analytics dashboard for crypto derivatives and related volatility products. It combines live Amberdata market data, persisted historical snapshot analytics, and synced Alpha trade rows so operators can monitor market conditions, review volatility signals, inspect data readiness, and measure Alpha trade behavior against the dashboard's available opportunity context.

The system is optimized for numeric correctness and operator transparency. Where an input is missing or not trustworthy, the dashboard should show blank or explicit error states rather than invented values.

For the full operator documentation map, see Vol Dashboard Documentation.

Strategic Direction

The current dashboard remains the measurement and market-context backbone. The next sponsor-facing direction is the Regime-Aware Trade Copilot Strategy, which turns the existing model, probability, trust, and trade-feed layers into a pre-trade and post-trade decision-support system.

The strategy is anchored on six pillars: reliable measurement, derivative identity and proxy mapping, regime detection by surface location, conditional distribution decisioning, trade restructuring evaluation, and transparent scenario tuning. The system should be able to say when a trade is dangerous for the current regime before it tries to recommend the best alternative.

Users

• Portfolio and trading operators who monitor volatility, flow, basis, and positioning.
• Engineers who maintain the dashboard, deployment process, and data integrations.
• Reviewers who need to verify whether displayed numbers are sourced and calculated correctly.

Runtime Architecture

Browser
  -> Next.js frontend on Cloud Run
  -> FastAPI backend on Cloud Run
  -> Amberdata APIs, Alpha API, Cloud SQL, Slack webhook

Key rules:

• Frontend uses fetchApi() for public backend GET routes.
• Frontend uses /api/admin-proxy for server-side admin POST routes.
• The browser never receives the Alpha API key or backend admin secret.
• Backend owns external API access, database access, validation, and calculations.
• Production deployment is Google Cloud Run only.

See Runtime Trust Boundaries.

Source Systems

Major Screens

The top navigation groups screens by operator question. Route names remain stable, even where the navigation label is more descriptive than the path.

See Screen To Data Source Map.

Model Explorer Decision Structure

Model Explorer is the front-door model read. It gives a reading order and preserves drill-down detail:

Data Flow Categories

1. Live Pass-Through Market Data

The frontend requests data from backend routes such as /api/dvol, /api/vol-surface, /api/decorated-trades, /api/funding-rates, and /api/option-chain. The backend calls Amberdata, normalizes or caps the payload where needed, and returns chart-ready JSON.

See Live Market Data Flow.

2. Persisted Snapshot Analytics

Scheduled or manual snapshots call Amberdata and store historical data in Postgres. The analytics modules read those tables to compute gamma regimes, spot-vol correlations, smile dynamics, conditional returns, probability densities, and alert signals.

See Persisted Snapshot Analytics Flow.

The Model Diagnostics page (/analytics) also has one live, point-in-time GEX read: Live GEX Magnet & Repeller Levels. That card uses the current Amberdata gamma-exposures-snapshots response, not stale persisted gex_snapshots, and displays source status, as-of time, age, row count, and strike count.

3. Alpha Trade Feed

The Alpha feed is synced into internal_trades through an operator-triggered workflow on /trades. The backend validates each source row, normalizes economics, upserts rows by source trade ID, and stores sync state by portfolio scope.

See Alpha Trade Feed Sync and Alpha Trade Sync.

4. Trade Performance Analytics

The Performance screen reads synced Alpha rows, trade-time dashboard context, execution benchmark rows, forward outcome marks, and derived lifecycle groupings. It scores opportunity alignment and exposes source-group quality. It displays execution quality and forward outcome P&L only for rows with sourced MSTR/COIN option benchmark quotes or forward marks, and it withholds realized P&L until authoritative accounting or validated lifecycle inputs are available.

See Trade Performance Analytics, Trade Performance Business Discussion Guide, and Opportunity Alignment Rules.

Current Alpha Production Scope

Production is currently configured for:

• ALPHA_TRADE_FEED_URL=https://api.bitwiseinvestments.com/api/v1/alpha/optionTrades/export
• ALPHA_TRADE_FEED_PORTFOLIOS=IMST,ICOI
• ALPHA_TRADE_FEED_INCLUDE_PENDING=false

The known verified full-scope sync diagnostic for this scope was:

Reliability And Accuracy Principles

• All Amberdata calls go through the backend.
• All Alpha calls go through the backend.
• Trade feed ingestion validates contracts before storage.
• Trade economics are explicit about units: price per contract, premium total USD, multiplier from source.
• Full-scope sync diagnostics are an ingestion guardrail for checking whether the selected Alpha feed scope is loaded into the dashboard cache.
• Missing valuation inputs should produce blank values, not guessed values.
• BTC proxy market context is acceptable as Alpha opportunity backdrop when labelled, but it must not be presented as MSTR/COIN execution-quality liquidity.

Known Boundaries

• Alpha sync is not streaming; it is operator-triggered.
• Alpha synced rows currently do not carry traded IV, execution-time bid/ask quotes, sourced post-trade marks, or authoritative realized P&L inside the source trade payload; execution benchmarks and forward marks are enriched separately.
• Trade P&L is only reliable when mark, spot, IV, multiplier, lifecycle, and source-quality assumptions are trustworthy.
• Performance currently answers opportunity alignment and source readiness. Execution quality and forward outcomes are explicit source-quality-gated states, BTC proxy liquidity is backdrop only, smile context is intentionally not sourced for current Alpha MSTR/COIN rows, and realized P&L remains a no-data state until sourced.
• The frontend volatility route redirects to /.
• Some historical analytics depend on sufficient snapshot history and may show no-data states until enough observations exist.
• Current strike-level magnet/repeller reads depend on live Amberdata GEX availability and should be treated as unavailable or stale when the panel says so.