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-ofWhich 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:
perp_market_details and the inner join drops nothing.