tickfoundry
capture livesign inget the data →
§hyperliquid

Hyperliquid, tick by tick.
Every book change and every fill, for every coin, since January 2025.

Hyperliquid's order books, rebuilt from the chain's own order-event stream rather than sampled from a websocket: top of book on every change, the 25-level book on every change with resting-order counts per level, and every fill with the taker's wallet, fee and realized PnL.

844 coins — every perp, spot pair and HIP-3 market the venue has listed, 594 days from 2025-01-25, 6.0 TB of parquet. Sold per day with a coin filter.

pull the free sample day →schemapricing

What is on disk today

594 days, 2025-01-252026-09-10, 6.0 TB across three tables and 234 perpetuals, 326 spot, 284 hip-3 (builder dexes). New days are added daily.

Top of book (every change)hl_l1

Best bid and ask with sizes and the spread, one row per block in which the top of book changed, replayed from the chain's own order events — not sampled from a websocket. No consecutive duplicates.

~1.0 GB · all coins · 594 days · 393 GB on disk
Order book — 25 levels, every changehl_l2

The 25-level book on both sides — price, size and the number of resting orders at each level — one row per block in which any of it changed. Wide columns (bid_px_1 … ask_n_25), unused levels null. This is the table the venue's own websocket cannot give you: Hyperliquid pushes l2Book snapshots only, throttled to seconds.

~16 GB · all coins · 594 days · 5.6 TB on disk
Trades (fills)hl_trades

Every fill the chain executed: price, size, taker side, order id, the taker's wallet, fee and fee token, closed PnL and start position, and the settlement transaction hash. From 2025-03-22 straight from the node's fills tape; before that synthesized from the taker's own fill status (see caveats).

~350 MB · all coins · 593 days · 107 GB on disk

Why replay the chain instead of recording the websocket

Hyperliquid's public websocket pushes l2Book as a snapshot, throttled to a few seconds, and has no delta channel. A recording of it is a series of photographs — you can see the book at 12:00:05 and 12:00:10 but not the forty blocks in between, and every fill that crossed the spread inside that window is invisible in the book. The chain, by contrast, publishes every order event it executed. Replaying those events reproduces the book after every block, which is the finest resolution the venue itself has.

It also reaches back further than any recording: the archive starts 2025-01-25, so the history exists for coins and months nobody was recording at the time. And because the fills tape carries the taker's wallet, order id, fee and realized PnL, the trades table supports flow analysis a price/size tape cannot.

The honest cost is that a reconstruction can drift from what the matching engine held, so every coin-day carries a scorecard against the venue's own published snapshots, and the caveats below say where it is weaker (synthesized fills before 2025-03-22, unseeded spot books on the first day).

≈ $10,000 to build yourself

Building this yourself — pulling the chain's order-event archive out of requester-pays S3 and replaying it into books — runs to around $10,000 in egress and compute. A month of a plan is a rounding error on that.

Coins

Every coin the venue has listed since 2025-01-25, with its first day on disk; each has its own page with coverage and sizes. Perps are named the venue's way (BTC, kPEPE), spot pairs by index (@107), HIP-3 markets as dex:coin (xyz:CL, km:GOLD).

What you should know before buying

  • One row per block, not per message. Blocks land about every 70 ms; l1 and l2 have a row for every block in which they changed, trades one row per fill. msg_seq is the block height.
  • A day is block-aligned, not midnight-aligned. Each day runs from a few minutes after 00:00 UTC to a few minutes after the next midnight; filter on ts_src_ms for strict UTC days.
  • Fills before 2025-03-22 are synthesized. No fills tape exists upstream before 2025-03-22, so taker fills in that era are derived from each taker order's own filled size and average price against the resting book (source_event_type = l3_taker_status). price, size, side, oid and user are set; transaction_hash, tid, dir, fee, fee_token, closed_pnl and start_position are null. Resting orders that expired or were cancelled without an event can linger in the book until the order-id-gap inference catches them.
  • Spot books start unseeded. The archive has no snapshot before its first day, so resting spot depth is thinner than steady state for the first day or two.
  • A 924-block hole on 2025-07-19. Heights 668379075 onward, roughly the last minutes of one source object: the object is truncated in Hyperliquid's own bucket. Every coin is affected for that interval; nothing else that day.
  • Placeholder rows. A coin listed on the venue but with no book that day ships as one all-null row and an empty trades file, so the coin set is the venue's listing.

The Polymarket side of the catalog shares the same delivery path and the same block-time convention on its on-chain fills, so a Hyperliquid perp and the Polymarket market that references it can be lined up on a common UTC clock with an as-of join.

Pricing

Explorer and Premium are bought for one venue — Hyperliquid or Polymarket — and the other can be added for $50/mo at the same depth and limits. Professional includes both.

Free

2026-08-12, any coins, up to 1.0 GB, full fidelity. Costs no claims.

Explorer · Hyperliquid

$89/mo · every coin, full 25-level books · 150 downloads a day · REST API.

Premium · Hyperliquid

$199/mo · unlimited downloads · SFTP · add Polymarket (markets, perps, feeds, on-chain) for $50/mo.

start Premium for Hyperliquid →start Explorer for Hyperliquidbrowse the catalog

Questions

Where does Hyperliquid historical order-book data come from?

From the chain itself. Hyperliquid publishes its complete order-event stream (replica_cmds: every order placement, modify, cancel and fill the chain executed) and its fills tape. We replay that stream block by block into a top-of-book table, a 25-level book table and a trades table per coin per day. Nothing is sampled from a websocket: the venue's own l2Book feed is snapshot-only and throttled to seconds, which is exactly why a websocket recording cannot give you every book change.

How far back does it go?

2025-01-25, the first day of the chain's public archive, for every coin listed then; each coin's own first day is shown on its page and returned by the API. Spot pairs and HIP-3 builder dexes are chained from their real launch days (xyz 2025-10-13, km 2026-01-12, para 2026-04-01 and so on). New days are added daily.

Is the L2 book full depth?

25 levels a side on every plan — price, size and the number of resting orders at each level, as wide columns (bid_px_1 … ask_n_25), one row per block in which anything in those 25 levels changed. There is no tiering of book depth on Hyperliquid data: Explorer and Premium differ in download and API limits, not in what is inside the file.

How good is the reconstruction?

Every coin-day ships its own scorecard: the share of Hyperliquid's own published book snapshots (roughly every 5 seconds) whose best bid, best ask, top-5 and top-20 levels our replayed book matched exactly at that instant. On BTC for 2026-09-10 the top-of-book price agreement was 99.6% across 16,051 snapshots, and the caveats section says where the numbers are weaker and why.

How is it sold?

Per day with a coin filter — pick a range, the tables you want and the coins you want, and the bundle keeps a table-first tree so one read_parquet reads a whole table. Included with an Explorer or Premium plan bought for Hyperliquid; $50 a month as an add-on on a plan bought for Polymarket; and any free account can pull the fixed sample day (2026-08-12, any coins, up to 1.0 GB) without spending a claim.

What format does it arrive in?

Parquet, one file per table per coin per day, a per-coin quality JSON, and a README that states the schemas and the coverage caveats for your exact range. Delivery is a signed download link, the REST API, or SFTP on Premium.

For crypto perps across venues, see perps tick data; for the price feeds and Polymarket's crypto markets, see crypto tick data.