5. Microstructure Alpha July 13, 2026 9 min

5.46 An Open L4 Order Book: What Hyperliquid Data Unlocks

Hyperliquid runs fully on-chain, so a node captures every order event: wallet IDs, counterparty inventory, and the ~89% of orders that are rejected and invisible in LOBSTER-style data.

Academic microstructure research runs on a thin diet. Most papers you have read about limit order books were built on LOBSTER, a reconstruction of NASDAQ message data that is genuinely useful and also blind in specific ways: it shows you the orders that reached the book, not the ones that were rejected, and it never tells you who submitted them. Everything else is proprietary exchange data behind a negotiated contract you cannot share, which means nobody can check your results. Albers, Cucuringu, Howison, and Shestopaloff, out of Oxford, UCLA, and Queen Mary, went around the whole problem by running a non-validating node on Hyperliquid and dumping the raw blockchain into a structured research dataset. They put roughly 196 GB of it on Zenodo under an open license.

The reason this matters is not that crypto is exciting. It is that a fully on-chain exchange has no private ledger. Every order submission, cancellation, modification, fill, and rejection is a public blockchain event, timestamped to the nanosecond and permanently tagged to the wallet that sent it. That gives you the three things conventional feeds strip out: the identity of every actor, the counterparty on both sides of every trade with their inventory before it, and the roughly 89% of order events that get rejected and never appear in any normal dataset. This piece walks through what is actually in the data, does the arithmetic on why it is big, and then argues about how much of it is a real edge versus a well-marketed sample.

What "Level 4" actually means

Start with the taxonomy, because Hyperliquid's marketing muddies it. The standard market-data ladder goes: Level 1 is best bid and offer, Level 2 is aggregated depth per price level, Level 3 is individual order events (this is LOBSTER). Hyperliquid calls its node feed "Level 4," which is a coined term, not an industry standard. Strip the branding and it is Level 3 plus four additions: a pseudonymous wallet address on every action, the full order specification (type, time-in-force, limit price, size), every failed attempt, and the identity plus pre-trade inventory of both counterparties on each fill.

The node writes three streams. Order status records log every event in every order's life: accepted onto the book (open), filled, canceled, or rejected. Trade records log each fill with both wallet addresses, their positions before the trade, and order IDs that link back to the status stream. Raw book diffs log every visible change to the book as new, remove, or update. That third stream is the input to a reconstruction engine: fold the diffs forward in sequence and you rebuild the full book at any instant. The old article "Reconstructing the Order Book from Incremental Deltas" laid out that fold, and the old article "LOB Reconstruction Engine" built the state machine for it. Hyperliquid's book diff stream is exactly the delta feed those pieces assumed, handed to you with a wallet ID stapled to every delta, which is the part LOBSTER can never give you.

The 89% you never saw

Here is the headline unlock, and it is a real one. The order status stream captures every attempt, not just the survivors. In the December 2025 sample, roughly 89% of all order status records are rejections, the most common being badAloPxRejected, a post-only order that would have crossed the spread and so was bounced by the matching engine to protect its post-only guarantee. Conventional data records none of this. The accept rate is small.

$$ p_{\text{accept}} = \frac{N_{\text{book}}}{N_{\text{status}}} = 1 - p_{\text{reject}} $$

The accept probability is the count of events that reached the book divided by the count of all order status events, which is one minus the rejection rate. Work it with the paper's daily figure. The node logged about 880 million order status events per day across BTC, ETH, and SOL. With a 0.89 rejection rate, only 880 million times 0.11, or roughly 97 million events a day, actually landed on the book. The other 783 million, the ones a LOBSTER-style feed would silently drop, are the new material.

Of roughly 880 million daily order-status events across BTC, ETH, and SOL, only about 11% are accepted onto the book. Conventional Level 3 data captures that slice and drops the other 89% of rejected and failed attempts.

Why care about orders that never traded and never even rested? Because they are behavior. The companion papers by the same authors show that a small cohort uses rejected post-only orders to grab queue priority right after the spread widens, and that this rejected flow is significantly correlated with future returns, which is a direct shot at the textbook idea that only executed order flow has price impact. The old article "The MM Feature Catalog: Arrival, Cancellation, Update Rates" defined arrival, cancellation, and update rates as the core market-making features. This dataset lets you compute all three per wallet, and adds a fourth the catalog could not: rejection rate, the frequency and pattern of a trader's failed attempts, which is often a cleaner fingerprint of intent than what they managed to execute.

The plumbing: a node, 100 GB a day, and a 54-byte record

None of this is free to handle, and the size is the first reason most people will not replicate it. In native JSON each order status record runs about 300 to 450 bytes. Multiply that out.

$$ V_{\text{day}} = N_{\text{events}} \times b_{\text{record}} $$

Daily volume is the event count times the bytes per record. At 880 million events and 400 bytes, that is about 352 GB per day in raw JSON for three coins, which matches the paper's "exceeding 300 GB" and its note of roughly 100 GB per day of raw node logs before expansion. That is a firehose, and a month of it is unusable for most academic infrastructure. So they re-encoded.

$$ r = 1 - \frac{b_{\text{binary}}}{b_{\text{json}}} $$

The size reduction is one minus the binary record size over the JSON record size. Packing each record into a fixed 54-byte binary layout (wallet addresses mapped to 32-bit integer IDs, categorical fields to small integer codes, prices and sizes to fixed-point integers) gives one minus 54 over 400, or 0.865, an 86.5% cut, squarely in the paper's stated 85 to 88% range. That is what drops a 352 GB day to about 47 GB, and what let the whole sample fit under Zenodo's 200 GB ceiling. The re-encoding was not a nicety; it was the difference between a public dataset and a private one.

The released archives, about 196 GB total. For every coin, the rejected-order archive is roughly two to three times the size of the accepted-order archive, so the invisible flow is literally the bigger half of the file.

The archive breakdown makes the point physical: for BTC the accepted-order file is 19 GB and the rejected-order file is 46 GB. The stuff no other dataset carries is the larger share of the download.

What it costs to play, and why HFT lives here

The fee schedule explains why a cancel-heavy, rejection-heavy market exists at all. Hyperliquid charges maker-taker fees with a baseline of 1.5 basis points for makers and 4.5 for takers, and the most active makers get down to a 0.3 basis point rebate against 1.44 for takers. Compare the two ways to turn a position around.

$$ C_{\text{taker}} = 2 \times f_{\text{taker}}, \qquad C_{\text{maker}} = 2 \times f_{\text{maker}} $$

A round trip costs twice the per-side fee. Crossing the spread both ways at the baseline taker rate costs 2 times 4.5, or 9 basis points, before you have earned a single tick. Providing both ways as a top-tier maker earns 2 times 0.3, or 0.6 basis points of rebate, a swing of nearly 10 basis points purely from resting instead of crossing. That is the entire economic case for quoting rather than taking, and it is the same logic the maker-side execution pieces in this pillar rest on. The other half of the case is structural: order submissions and cancellations on Hyperliquid are gasless. On any normal blockchain a per-message network fee would make the high cancel-to-trade ratios of market making ruinous. Remove that fee and the 89% rejection rate stops being a bug and becomes the expected texture of a viable HFT venue.

What the data does not settle

Now the skepticism, because the paper is careful and the resharers usually will not be. First, the decentralization is thin. Hyperliquid's active validator set is 21 nodes chosen by stake, which is closer to a consortium than to Bitcoin's thousands of participants. The openness that makes this data exist is a property of 21 operators agreeing to run the chain, not a law of nature.

Second, the intra-block ordering is less exploitable than it looks. Within each 100 to 200 millisecond block the engine processes passive orders first, cancellations second, and takers last, which sounds like a clean edge for maker cancellation. But which block your message lands in is set by a pseudorandomly selected proposer with its own local view, so two messages sent together can land blocks apart, and a cancellation meant to pull a stale quote can arrive too late or, by luck, too early. The hierarchy is real; your ability to trade on it is bounded by routing randomness the paper is explicit about.

Third, know what the sample is before you generalize from it. The public release is one month of order status and book diffs (December 2025) for three perpetual contracts, plus four months of trades, all from a single venue, all crypto perps, all pseudonymous rather than identified. One wallet is not one human; a single desk can spin up unlimited wallets, and fee tiers even push them to consolidate, so wallet-level population studies inherit an identity-resolution problem the data cannot close on its own. The full firehose, reconstructed snapshots, and the raw replica command logs are only available on request, so the open 196 GB is a generous sample, not the whole thing. The unlock is genuine: rejected orders and counterparty inventory at nanosecond resolution are new, open, and checkable. Just do not confuse an open window into one young exchange with a general law of how markets work.

KEY POINTS

Hyperliquid is a fully on-chain limit-order-book exchange, so its entire message history is a public blockchain feed. A non-validating node (16 vCPU, 64 GB RAM, a binary, three logging flags) captures every order event with no special access.
"Level 4" is Hyperliquid's coined label, not a standard. In practice it is Level 3 plus a pseudonymous wallet ID on every action, full order parameters, every failed attempt, and both counterparties' identities and pre-trade inventory on each fill, all at nanosecond precision.
The real unlock is rejected orders. About 89% of the roughly 880 million daily order-status events (BTC, ETH, SOL) are rejections, so only about 97 million a day reach the book. Conventional data drops the other 783 million.
Rejected flow is not noise. The authors' companion work shows traders use rejected post-only orders to grab queue priority after spread widening, and that this never-executed flow predicts future returns, challenging the idea that only filled orders have price impact.
The engineering is the barrier: raw JSON runs over 300 GB per day. A fixed 54-byte binary record cuts size by about 86.5% (one minus 54 over 400), which is what let 196 GB fit on Zenodo.
Fees explain the venue: a baseline taker round trip costs 9 basis points while a top-tier maker earns a 0.6 basis point rebate, and order submission and cancellation are gasless, which is why cancel-heavy, rejection-heavy market making is structurally viable here.
Be skeptical of scope. Only 21 validators, intra-block priority bounded by routing randomness, one month, three coins, one venue, crypto perps, and pseudonymous wallets that do not map cleanly to traders. It is an open sample of one young exchange, not a general market law.

References

A note on AI. The ideas, research, analysis, and conclusions in this article are my own. I use AI tools to help with editing and wordsmithing, because English is not my first language, and I am not shy about that. AI-generated ideas and AI-assisted writing are not the same thing: the first is empty slop from a generic prompt, the second is a tool for communicating years of real research more clearly. Judge the work by its substance, not by whether software helped polish the prose.