Hyperliquid Trades

Three Parquet tables from HyperCore: trades, perp_liquidations and twaps, with 128 documented columns. Every row carries Block_Number and Block_Time, so the tables join on block with each other and with the Hyperliquid Order Book and Funding datasets.

For the 30 days to 30 September 2026 our live tables held 345 million trade rows, 555,000 liquidation rows and 213,000 TWAP status rows, about 11.5 million, 18,500 and 7,200 a day. That is roughly 18 to 21 GB of compressed Parquet. One 1,000-block pack from 29 September held 11,082 trade rows. Volume moves with market activity; we send exact row counts and sizes with the delivery, and these figures are estimates.

Filter trades and perp_liquidations on the account address, then sum Position_RealizedPnl and subtract Fees_Fee. Each match appears twice, once per side, so filtering by one address never double counts. Liquidation fills are only in perp_liquidations, so leave that table out and a liquidated account's PnL is incomplete.

Plain perps such as HYPE, HIP-3 perps with a dex prefix such as xyz:DRAM, spot pairs by index such as @107, and outcome tokens such as #1890, all in the same table. The Market_Kind column says which (perp, hip3, spot or outcome), so there is no prefix to parse.

Each liquidation match has two rows in perp_liquidations, one for the liquidated account and one for the counterparty, and Liquidation_LiquidatedUser names the liquidated account on both. Those fills are not repeated in trades. The perp_liquidations table has no public sample file; its columns are documented here from the export schema.

In the Hyperliquid Order Book dataset. This product holds matches only; opens, cancels, rejects and L4 book deltas are sold separately because they are about a hundred times larger.

30 days. HyperCore history is kept as a rolling 30-day window, so a purchase covers the 30 days up to the day before we prepare the files, and there is no longer window to buy. For a continuous feed beyond that, ask about the live stream.

Because the node emits them that way and we keep the values as emitted. Block_Time and Twap_Interval_EventTime are epoch nanoseconds; Trade_Execution_EventTime, Liquidation_Execution_EventTime and Twap_Interval_StartTime are epoch milliseconds. Divide by 1e9 or 1e3 respectively when converting to timestamps.

Position_Size, Position_EntryPrice and Position_Funding, Trade_MarkPx, Trade_Position_Closed and Liquidation_Liquidator are never filled; they are part of the shared Hyperliquid schema. Signer, vault, leverage and maximum leverage fields are filled when the source data carries them and can be empty.

With DuckDB: SELECT * FROM read_parquet('trades/*.parquet'). With pandas: pd.read_parquet('trades/'). Parse Trade_Execution_Price, Trade_Execution_Size, Trade_Fees_Fee and the other money columns with Decimal rather than float; they are stored as decimal strings on purpose.

Yes. These field definitions are the ones Bitquery's Hyperliquid Kafka topics use, so a backtest reading this archive and a production consumer reading the live stream decode with the same code.

As Parquet files exactly as our parser writes them, one folder per table, each file covering a run of consecutive blocks. We prepare the files within 7 business days of purchase, covering the 30 days up to the day before. You choose at checkout where to collect them: a Requester Pays S3 bucket, downloaded with your own AWS account, or a Cloudflare R2 bucket with a read-only API key and no egress fees. Files stay available for 7 days from delivery.

Yes. The trades and twaps tables link to public sample Parquet files from a real 1,000-block pack of 29 September 2026, with every column the export writes: 100 trade rows and the 7 TWAP status rows in that pack. The sample repository on GitHub shows the first records as readable JSON. No email address required.