Hyperliquid runs two chains. HyperCore is the exchange itself: the matching engine, the perpetual markets and the spot order books, keyed chain_id = 'hypercore'. HyperEVM is its general-purpose EVM chain, keyed chain_id = 'hyperevm', and it has its own section at HyperEVM. This section covers HyperCore.
The chain’s own record sits in the hypercore dataset: one row per block, fill, order, book change and funding settlement. Everything above that sits in the catalog, where the HyperCore rows are selected with chain_id = 'hypercore'.
The section mirrors the catalog itself: the core entities, then the market verticals with data on HyperCore.
Layers
| Layer | Since | What it holds |
|---|
| Raw | 2025-03 | Blocks and the exchange streams beneath them: fills, orders, book changes, funding and TWAPs. |
| Projects | 2025-05 | Daily Notional volume, Fees and Revenue for each tracked project, broken out to HyperCore. |
| Apps | 2025-05 | Daily Notional volume, Trading volume, Fees and Revenue for each tracked app, broken out to HyperCore. |
| Perpetuals | 2025-05 | Perpetual markets and the spot and outcome-market order books, with their volume, open interest, funding and fees. |
Filtering
chain_id reads hypercore wherever a catalog table has a chain, so the same filter selects HyperCore everywhere. Some shapes ask for something else. Project and app totals span every chain a project runs on, so one chain’s share reads from metrics_project_chains and metrics_app_chains. The perpetual position and trader tables key on the market alone, so the chain comes from dimensions.perp_markets, as the query below does.
Every table splits by day: the raw and event tables on block_timestamp, the daily tables on timestamp. Bound that column in every query; without a bound the query reads the whole table.
