L4 order-book data from HyperCore: every order status including cancels and rejects, per-order book deltas, and the oracle and mark price pushes behind them.
Hyperliquid order book data from the HyperCore L1, not HyperEVM. The order_statuses table keeps every order through its lifecycle: open, canceled, filled, triggered and the *Rejected states, with time in force, reduce-only, trigger conditions and TP/SL child brackets. The book_diffs table is L4, one row per new, update or remove of a single order with its owner, order id, price and size, so the book can be rebuilt at any block rather than at snapshot boundaries. The oracle_updates table records each mark, oracle and external perp price push per coin.
Hyperliquid's own S3 archive publishes L2 snapshots and asset contexts and nothing else. Rejects and cancels are invisible in any trades-only dataset, and they are most of the signal in microstructure work. Money and sizes are decimal strings, addresses are 0x-prefixed hex, and Order.Timestamp is epoch milliseconds while Block_Time and status Time are epoch nanoseconds.
One row per order status change: open, canceled, filled, triggered and every *Rejected state, with time in force, reduce-only, trigger and TP/SL bracket fields. Time is epoch nanoseconds.
hyperliquid/order_statuses<start_block>_<end_block>.parquet200 blocks per fileL4 order-book deltas: one row per new, update or remove of a single order, with owner, order id, price and size.
hyperliquid/book_diffs<start_block>_<end_block>.parquet200 blocks per fileOne row per oracle push: the mark, oracle and external perp price inputs and results for every coin the validator set or a HIP-3 deployer priced.
hyperliquid/oracle_updates<start_block>_<end_block>.parquet200 blocks per fileorder_statuses25 columnsOne row per order status change: open, canceled, filled, triggered and every *Rejected state, with time in force, reduce-only, trigger and TP/SL bracket fields. Time is epoch nanoseconds.book_diffs12 columnsL4 order-book deltas: one row per new, update or remove of a single order, with owner, order id, price and size.oracle_updates11 columnsOne row per oracle push: the mark, oracle and external perp price inputs and results for every coin the validator set or a HIP-3 deployer priced.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.
Parquet files, delivered as signed download links by email after payment, in this layout:
# order_statuses — 200 blocks per file hyperliquid/order_statuses<start_block>_<end_block>.parquet # book_diffs — 200 blocks per file hyperliquid/book_diffs<start_block>_<end_block>.parquet # oracle_updates — 200 blocks per file hyperliquid/oracle_updates<start_block>_<end_block>.parquet
Three Parquet tables from HyperCore: order_statuses, book_diffs and oracle_updates, with 48 documented columns. Every row carries Block_Number and Block_Time, so the tables join on block with each other and with the Hyperliquid Trades and Ledger datasets.
Large, and driven by quoting activity. In a measured 1,000-block slice (about 73 seconds) we counted 142,955 order statuses, 89,241 book diffs and 24 oracle updates. Scaled to a day that is roughly 170 million order statuses and 105 million book diffs; exact row counts and sizes come with the delivery manifest, and these figures are estimates.
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_diffs row names the order and the address behind it, and every open, cancel and reject is in order_statuses.
Replay book_diffs in Block_Number order per Coin: Kind new adds an order at Px with Sz, update replaces OrigSz with NewSz, remove deletes it. Aggregate by Px for an L2 view at any block, or keep order ids for queue position.
In the Hyperliquid Trades dataset. A filled status here tells you an order completed; the match price, counterparty, fee and PnL are in the fills table there, joined on Block_Number and Oid.
30 days. HyperCore history is kept as a rolling 30-day window, so a purchase covers the 30 days up to yesterday 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 the Time column on statuses and events are epoch nanoseconds; Fill.Time and Order.Timestamp are epoch milliseconds. Divide by 1e9 or 1e3 respectively when converting to timestamps.
The node emitted a field that the schema does not model yet, and we kept it rather than dropping it. Extra is empty on nearly every row. When a new field appears it lands there first, so nothing is silently lost between schema versions.
With DuckDB: SELECT * FROM read_parquet('fills/*.parquet'). With pandas: pd.read_parquet('fills/'). Parse Px, Sz, 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 flat Parquet files under a stable S3 layout, one prefix per table and one file per 200-block range, with a JSON manifest listing every file and its sha256. Signed HTTPS links are emailed once the files are prepared. Refreshed daily with T+1 latency; a purchase made today includes everything up to yesterday.
Yes. Every table links to a public sample Parquet file from a real 1,000-block slice, and the sample repository on GitHub shows the first records of each table as readable JSON. No email address required.
Every Pons launch, bonding-curve trade and graduation on Robinhood Chain, decoded from the chain and priced in USD.
HyperCore fills, order statuses, L4 book diffs, oracle pushes, ledger events, TWAPs and CoreWriter actions, block by block, as Parquet.
Every HyperCore fill from both sides of the match, with realized PnL, fees, taker flag and liquidation details, plus TWAP order statuses.
Tell us the chain, tables and date range.