Hyperliquid data from the HyperCore L1 order-book exchange, not HyperEVM: seven event tables recorded per block and joined on Block_Number. The trades table carries one row per side of each match with realized PnL, fees and a taker flag, so maker and taker attribution and per-wallet realized PnL come straight out of the file, and liquidation fills sit in perp_liquidations. The order_updates table keeps every order that never traded, including cancels and rejects, and book_updates holds per-order L4 deltas rather than L2 snapshots, so the book can be rebuilt at any block.
Hyperliquid's own S3 archive publishes L2 snapshots and asset contexts and nothing else. This dataset is the shape a quant or data engineer needs for execution analysis: money and sizes are decimal strings, addresses and hashes are 0x-prefixed hex, and Block_Time is epoch nanoseconds while Trade_Execution_EventTime and Order_PlacedTime are epoch milliseconds. Key matches on (Block_Number, Trade_Market_CoinRaw, Trade_Execution_Tid); the hash is not a join key because one L1 transaction spans many matches.
Use cases
Order-book microstructure research at L4: queue position, order lifetime, cancel and reject rates
Per-wallet realized PnL, fees and liquidation history from both sides of every fill
Backtests that decode with the same schema as Bitquery's live Hyperliquid stream
Funding, oracle and mark-price studies across plain perps, HIP-3 markets and spot
7 tables
258 columns · free sample for each table
trades
48 columns
One row per side of each match, liquidations excepted: price, size, direction, taker flag, fees, realized PnL and TWAP link. A match appears twice, keyed by (Block_Number, Trade_Market_CoinRaw, Trade_Execution_Tid).
hyperliquid/trades<start_block>_<end_block>.parquet200 blocks per file
One row per side of each liquidation match, with the same execution, fee and position fields as trades plus the liquidated account, mark price and method.
hyperliquid/perp_liquidations<start_block>_<end_block>.parquet200 blocks per file
One row per order status change: open, canceled, filled, triggered and every *Rejected state, with time in force, reduce-only and trigger fields. Order_EventTime is epoch nanoseconds.
hyperliquid/order_updates<start_block>_<end_block>.parquet200 blocks per file
trades48 columnsOne row per side of each match, liquidations excepted: price, size, direction, taker flag, fees, realized PnL and TWAP link. A match appears twice, keyed by (Block_Number, Trade_Market_CoinRaw, Trade_Execution_Tid).
perp_liquidations48 columnsOne row per side of each liquidation match, with the same execution, fee and position fields as trades plus the liquidated account, mark price and method.
Liquidation_Execution_SizeStringExecuted size in base units, decimal string
Liquidation_Execution_OidUInt64Order id of this side's order
Liquidation_Execution_CloidStringClient order id, 0x-prefixed hex; empty when the trader set none
Liquidation_Execution_TidUInt64Trade id; with Block_Number and the market it keys a match, once per side
Liquidation_Execution_HashStringL1 transaction hash, 0x-prefixed hex; not a join key, one transaction spans many matches and TWAP fills carry 32 zero bytes
Liquidation_Execution_EventTimeInt64Fill time, epoch milliseconds
Liquidation_Fees5
Liquidation_Fees_FeeStringFee paid, decimal string; negative when the maker received a rebate
Liquidation_Fees_FeeTokenStringToken the fee was paid in, usually USDC
Liquidation_Fees_BuilderFeeStringBuilder fee charged on the fill, decimal string; empty when none
Liquidation_Fees_DeployerFeeStringHIP-3 deployer fee on the fill, decimal string; empty when none
Liquidation_Fees_PriorityGasStringPriority gas paid, decimal string; empty when none
Liquidation_Position9
Liquidation_Position_SideStringLong or Short: the position this fill changed; empty for spot and outcome fills
Liquidation_Position_SizeStringNot filled in this table, always empty; part of the shared Hyperliquid schema
Liquidation_Position_SizeBeforeStringSigned position before the fill, in base units, decimal string; negative is short
Liquidation_Position_EntryPriceStringNot filled in this table, always empty; part of the shared Hyperliquid schema
Liquidation_Position_RealizedPnlStringRealized PnL of this fill in USDC, decimal string
Liquidation_Position_FundingStringNot filled in this table, always empty; part of the shared Hyperliquid schema
Liquidation_Position_LeverageUInt32Account's margin multiple on this market (20 means 20x) when known; 0 otherwise, can be empty
Liquidation_Position_IsCrossBool1 when the account uses cross margin on this market, when known; can be empty
Liquidation_Position_ClosedBool1 when the node reported a starting position; best effort, confirm with Position_SizeBefore and Execution_Size
Liquidation4
Liquidation_MarkPxStringMark price the liquidation used, decimal string
Liquidation_MethodStringLiquidation method as the node reports it, such as market
Liquidation_LiquidatorStringNot filled in this table, always empty; part of the shared Hyperliquid schema
Liquidation_LiquidatedUserStringAddress of the liquidated account, 0x-prefixed hex; the same on both sides of the match
Indexing3
Indexing_TimeInt64When our pipeline indexed the block, epoch nanoseconds; pipeline bookkeeping
Indexing_OnTreeBool1 when the block was on our block tree at indexing time; pipeline bookkeeping
Indexing_OnTrunkBool1 when the block was on the finalized chain at indexing time; pipeline bookkeeping
Recording2
Recording_TimeUInt32When the row was written, epoch seconds; pipeline bookkeeping
Recording_HashUInt64Row hash used to drop duplicates; pipeline bookkeeping
twaps32 columnsOne row per TWAP order status change: activated, finished, terminated or error, with total size, executed size and notional.
order_updates51 columnsOne row per order status change: open, canceled, filled, triggered and every *Rejected state, with time in force, reduce-only and trigger fields. Order_EventTime is epoch nanoseconds.
ColumnTypeDescription
Block3
Block_NumberUInt64HyperCore block number; the join key across all seven tables
Block_TimeInt64Block time, epoch nanoseconds
Block_DateDateUTC date of the block; pipeline bookkeeping, handy for partitioning
price_updates20 columnsOne row per coin and price kind in each oracle push: the resulting mark, oracle and external perp prices, and the inputs behind them.
ColumnTypeDescription
Block_NumberUInt64HyperCore block number; the join key across all seven tables
Block_TimeInt64Block time, epoch nanoseconds
PriceUpdate_UpdateClassStringUpdate class as the node emits it, such as Normal or Fallback
PriceUpdate_Market_CoinRawStringMarket as the node names it: plain perp (HYPE), HIP-3 perp (xyz:DRAM), spot (@107) or outcome token (#1890)
PriceUpdate_KindStringWhich price this row is: mark, oracle or extPerp for the resulting prices; markInput, spotInput or extPerpInput for the inputs behind them
PriceUpdate_PriceStringPrice, decimal string
PriceUpdate_DailyPxStringDaily reference price for resulting prices, decimal string; empty on input rows
PriceUpdate_UpdateTimeInt64Last update time the node reports for resulting prices; 0 on input rows
perp_fundings23 columnsOne row per account and market at each hourly funding settlement: the rate, the signed position size it applied to, and the USDC paid or received.
Funding_Trader_SignerStringAlways empty in this table: funding is settled by the chain, not signed by the account; part of the shared Hyperliquid schema
Funding_Trader_VaultStringAlways empty in this table: funding is settled by the chain, not signed by the account; part of the shared Hyperliquid schema
Funding_Trader_BroadcasterStringAlways empty in this table: funding is settled by the chain, not signed by the account; part of the shared Hyperliquid schema
Funding_Trader_SignedAtInt64Always empty in this table: funding is settled by the chain, not signed by the account; part of the shared Hyperliquid schema
Funding_Market_SymbolStringReadable market name: HYPE, or DRAM for xyz:DRAM
Funding_Market_KindStringperp or hip3
Funding_Market_ProtocolStringhypercore for plain perps; the deploying dex (such as xyz) for HIP-3 markets
Funding_Market_CoinRawStringMarket as the node names it: plain perp (HYPE) or HIP-3 perp (xyz:DRAM)
Funding_Market_IsPerpBoolAlways 1; funding applies to plain perps and HIP-3 perps
Funding_Market_MaxLeverageUInt32Maximum margin multiple on the market (40 means 40x); 0 when unknown, can be empty
Funding_AmountStringUSDC received for this settlement, decimal string; negative when the account paid
Funding_RateStringHourly funding rate for the market, decimal string; positive means longs pay shorts
Funding_SizeStringSigned position size the funding applied to, in base units, decimal string; negative for a short
Indexing3
Indexing_TimeInt64When our pipeline indexed the block, epoch nanoseconds; pipeline bookkeeping
Indexing_OnTreeBool1 when the block was on our block tree at indexing time; pipeline bookkeeping
Indexing_OnTrunkBool1 when the block was on the finalized chain at indexing time; pipeline bookkeeping
Recording2
Recording_TimeUInt32When the row was written, epoch seconds; pipeline bookkeeping
Recording_HashUInt64Row hash used to drop duplicates; pipeline bookkeeping
Send this dataset’s full schema to an assistant and ask it anything. It reads the plain-text brief ↗ first, so the answer comes from the real column list rather than a guess.
Opens a new chat with the question filled in. Nothing about you is sent to Bitquery, and the assistant sees only the public brief.
Delivery
Parquet files in a Requester Pays S3 bucket or a Cloudflare R2 bucket, chosen at checkout. On S3 you download with your own AWS account and AWS bills the transfer; on R2 you download with a read-only API key and pay no egress. Layout:
# trades: 200 blocks per file
hyperliquid/trades<start_block>_<end_block>.parquet# perp_liquidations: 200 blocks per file
hyperliquid/perp_liquidations<start_block>_<end_block>.parquet# twaps: 200 blocks per file
hyperliquid/twaps<start_block>_<end_block>.parquet# order_updates: 200 blocks per file
hyperliquid/order_updates<start_block>_<end_block>.parquet# book_updates: 200 blocks per file
hyperliquid/book_updates<start_block>_<end_block>.parquet# price_updates: 200 blocks per file
hyperliquid/price_updates<start_block>_<end_block>.parquet# perp_fundings: 200 blocks per file
hyperliquid/perp_fundings<start_block>_<end_block>.parquet
Download a free sampleNo email needed.
Pay nowName, work email and licence check.
Pay the invoiceBy card or bank transfer.
Download from S3 or R2The team prepares the export and emails the bucket path, plus a read-only API key for R2 orders.
Seven Parquet tables from HyperCore: trades, perp_liquidations, twaps, order_updates, book_updates, price_updates and perp_fundings, with 258 documented columns. Every row carries Block_Number and Block_Time, so the tables join on block without a separate blocks table. HyperEVM transactions and contract events are not part of this bundle.
How big is it?
Large, and driven by book activity. In a measured hour of HyperCore on 29 September 2026 (50,417 blocks) we counted 76.6 million order statuses, 56.0 million book diffs and 613,682 fills, about 1.5 million, 1.1 million and 12,000 per 1,000 blocks. Scaled to a day that is roughly 1.8 billion order statuses, 1.3 billion book diffs and 15 million fills. Volume moves with market activity; exact row counts and sizes come with the delivery manifest, and these figures are estimates.
How is this different from Hyperliquid's free S3 archive?
Hyperliquid's archive holds L2 book snapshots and asset contexts, uploaded roughly monthly, and states that no other historical data is provided that way. This dataset is L4: each book_updates row names the order and the address behind it, and fills, rejects, cancels and funding payments are all included.
How do I compute a wallet's realized PnL?
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.
Which markets are covered?
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.
Why are there two time units?
Because the node emits them that way and we keep the values as emitted. Block_Time, Order_EventTime and Twap_Interval_EventTime are epoch nanoseconds; Trade_Execution_EventTime and Order_PlacedTime are epoch milliseconds. Divide by 1e9 or 1e3 respectively when converting to timestamps.
Why are some columns empty?
Some columns belong to the shared Hyperliquid schema and are never filled in a given table, and signer, vault and leverage fields are filled only when the source data carries them. Each column description says when it can be empty.
How do I load a file?
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.
Does this match the live stream?
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.
Can I buy just part of it?
Yes. The same tables are sold as three smaller datasets: Hyperliquid Trades (trades, liquidations and TWAP statuses), Hyperliquid Order Book (order updates, L4 book updates and price updates) and Hyperliquid Funding (hourly funding payments). This bundle is all seven tables in one purchase.
How far back does it go?
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.
How is the data delivered, and how current is it?
As flat Parquet files under a stable layout, one prefix per table and one file per 200-block range, with a JSON manifest listing every file and its sha256. 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.
Can I try before I buy?
Yes. Every table except perp_liquidations links to a public sample Parquet file of real data with every column the export writes. The sample repository on GitHub shows the first records of each table as readable JSON. No email address required.