> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dune.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Hyperliquid Perpetuals
> Venue-wide curated tables for Hyperliquid perpetual futures, covering first-party and HIP-3 builder-deployed markets in one dataset
export const PremiumDatasetAccessCard = ({href = "https://dune.com/enterprise#contact-form", note = null}) =>
Querying this dataset requires an entitlement on your workspace. See access tiers, or contact the Dune team to enable access.
{note && <>
{note}}
;
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](/data-catalog/curated/perpetuals/overview); every table is listed on [All Tables](/data-catalog/curated/perpetuals/all-tables-overview).
**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
Market-level reporting. One row per market-day: candles, volume, fees, forced flow, end-of-day open interest and funding
Intraday, same columns at hourly grain — funding's native cadence, and the finest grain at which open interest is defined
Per fill. One row per leg with fees, realised PnL, position before the fill, and TWAP, liquidation and ADL detail
Per account. One row per trader-day: volume, PnL, fees, funding, end-of-day exposure and collateral flows, no market dimension
Per account per market. Signed position size, notional and settled funding at each hourly funding round
Reference. One row per market: registry state, margin and leverage parameters, and the curated classification
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`](/data-catalog/curated/perpetuals/hyperliquid/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.
| Table | Partition columns |
| ---------------------------- | ------------------------------------------------------ |
| `perp_trades` | `block_date` |
| `perp_accounts_daily` | `block_date` |
| `perp_positions_hourly` | `block_month`, `trader_prefix` |
| `perp_market_metrics_hourly` | `block_month` |
| `perp_market_metrics_daily` | `block_month` |
| `perp_oracle_prices` | `block_month` |
| `perp_market_details` | none — an unpartitioned view over the current registry |
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](/data-catalog/curated/perpetuals/hyperliquid/perp-positions-hourly) has the query shape.
The canonical market-level query is a metrics table joined to the dimension on `coin`:
```sql theme={null}
SELECT
m.block_date,
d.market_category,
SUM(m.volume_usd) AS volume_usd,
SUM(m.fee_usd) AS fee_usd,
SUM(m.open_interest_usd) AS open_interest_usd_eod
FROM hyperliquid.perp_market_metrics_daily AS m
JOIN hyperliquid.perp_market_details AS d
ON d.coin = m.coin
WHERE m.block_month >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '30' DAY)
AND m.block_date >= CURRENT_DATE - INTERVAL '30' DAY
AND m.block_date < CURRENT_DATE
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC
```
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.