Skip to main content
The hyperliquid.perp_* tables cover Hyperliquid perpetual futures venue-wide: first-party markets, where coin is the bare symbol (BTC), and HIP-3 builder-deployed markets, where coin is dex:SYMBOL (xyz:TSLA), in one set of tables rather than one per dex. Hyperliquid spot and HIP-4 outcome markets are out of scope. This venue sits in the Perpetuals collection; every table is listed on All Tables.
Maintained by: Dune · Refresh: hourly (perp_oracle_prices daily) · Markets: 498 — 232 first-party and 266 HIP-3 across 10 builder dexes, of which 417 have traded · History: fills from 2025-07-27, open interest and funding from 2025-09-27 · Figures as of 2026-08-21; the registry is live, so counts are as-of

Which table answers which question

perp_market_metrics_daily

Market-level reporting. One row per market-day: candles, volume, fees, forced flow, end-of-day open interest and funding

perp_market_metrics_hourly

Intraday, same columns at hourly grain — funding’s native cadence, and the finest grain at which open interest is defined

perp_trades

Per fill. One row per leg with fees, realised PnL, position before the fill, and TWAP, liquidation and ADL detail

perp_accounts_daily

Per account. One row per trader-day: volume, PnL, fees, funding, end-of-day exposure and collateral flows, no market dimension

perp_positions_hourly

Per account per market. Signed position size, notional and settled funding at each hourly funding round

perp_market_details

Reference. One row per market: registry state, margin and leverage parameters, and the curated classification

perp_oracle_prices

Prices. Minute-cadence oracle, mark and mid prices with the signed mark-oracle spread

Dataset conventions

coin is the join key, market_symbol is not. Every market-grained table carries coin and joins to perp_market_details on it. market_symbol is coin with the dex: prefix stripped, so two dexes listing the same ticker collide — never join or group on it when HIP-3 markets are in scope. perp_dex is hyperliquid or the builder dex code, and perp_market_details.perp_dex_type (first_party / builder) is the cheap first-party-only or HIP-3-only filter. perp_accounts_daily is per trader and carries no market columns at all. Two history floors. Everything aggregated from fills — trades, candles, volume, counts, fees, forced flow — starts 2025-07-27. Open interest, open position counts and funding start 2025-09-27, because they come from the venue’s hourly funding events and cannot be reconstructed from fills, which record changes in a position and never the standing position of every account. Rows between the two floors carry flow columns with null stocks. perp_oracle_prices is the exception in both directions: first-party rows reach back to 2023-05-20 from Hyperliquid’s asset-contexts archive, HIP-3 rows start 2025-10-13. perp_trades holds both legs of every match. A market-level SUM(notional_usd) there is therefore ~2x exchange-reported volume: filter is_taker to count each match once, or take volume from the metrics tables, which are already taker-side and are the volume source of truth. At the account grain of perp_accounts_daily both legs is not a double count — each leg is one account’s own participation — which is why that table aggregates both and exposes taker_volume_usd separately for venue-level sums. Open interest is a stock, and published both-sides. Summing it across markets at one timestamp is valid, summing it across hours or days is not. The column semantics — longs plus shorts, and the pricing rule behind the gap to the Hyperliquid UI — are on perp_market_metrics_hourly. Bound the partition columns on every query. They are the only columns that prune, and nothing prunes within a partition — a coin filter still reads the whole partition, and perp_trades alone adds roughly 8.75M legs a day. Every fact table carries both block_date and block_month, but only the partitioned one prunes, so filtering block_month on a block_date-partitioned table reads every day in the month. perp_positions_hourly is the one table with a second partition key. trader_prefix — the first byte of the account address as two lowercase hex characters — splits each month into 256 buckets, and a single-account query has to state it alongside trader, because Trino derives no partition value from the address predicate on its own. Its page has the query shape. The canonical market-level query is a metrics table joined to the dimension on coin:
Delisted markets stay tombstoned in the registry, so every coin that has ever traded has a row in perp_market_details and the inner join drops nothing.