Every HyperCore fill from both sides of the match, with realized PnL, fees, taker flag and liquidation details, plus TWAP order statuses.
Hyperliquid trades from the HyperCore L1 order-book exchange, not HyperEVM. The fills table carries one row per counterparty per match with Px, Sz, Dir, ClosedPnl, Fee, StartPosition and a Crossed flag for the taker, so maker and taker attribution and per-wallet realized PnL come straight out of the file. Liquidations carry the liquidated user, mark price and method. The twap_statuses table records each TWAP order as it activates, fills and finishes.
A match appears twice, once per side, keyed by (Block_Number, Coin, Tid); Hash is not a join key because one L1 transaction spans many matches and TWAP trades carry 32 zero bytes. Money and sizes are decimal strings, addresses are 0x-prefixed hex, and Fill.Time is epoch milliseconds while Block_Time is epoch nanoseconds.
One row per counterparty per match: price, size, direction, realized PnL, fees, taker flag and liquidation details. A match appears twice, keyed by (Block_Number, Coin, Tid). Time is epoch milliseconds.
hyperliquid/fills<start_block>_<end_block>.parquet200 blocks per fileOne row per TWAP order status change: activated, finished, terminated or error, with size executed so far and notional.
hyperliquid/twap_statuses<start_block>_<end_block>.parquet200 blocks per filefills25 columnsOne row per counterparty per match: price, size, direction, realized PnL, fees, taker flag and liquidation details. A match appears twice, keyed by (Block_Number, Coin, Tid). Time is epoch milliseconds.twap_statuses18 columnsOne row per TWAP order status change: activated, finished, terminated or error, with size executed so far and notional.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:
# fills — 200 blocks per file hyperliquid/fills<start_block>_<end_block>.parquet # twap_statuses — 200 blocks per file hyperliquid/twap_statuses<start_block>_<end_block>.parquet
Two Parquet tables from HyperCore: fills and twap_statuses, with 43 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 Ledger datasets.
In a measured 1,000-block slice (about 73 seconds) we counted 1,552 fills and 3 TWAP statuses. Scaled to a day that is roughly 1.8 million fill rows; exact row counts and sizes come with the delivery manifest, and these figures are estimates.
Filter fills on User, then sum ClosedPnl and Fee. Each match appears twice, once per counterparty, so filtering by one User never double counts. Crossed tells you whether that side was the taker, and StartPosition is the signed position before the fill (negative is short).
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 stream. Filter on the prefix to separate them.
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 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 bonding-curve trade, token creation, migration and pool on Pump.fun, plus per-token OHLCV, decoded and USD-priced.
Every Pons launch, bonding-curve trade and graduation on Robinhood Chain, decoded from the chain and priced in USD.
Every swap and liquidity change on Raydium's concentrated liquidity pools, decoded and USD-priced at block time.
Tell us the chain, tables and date range.