Short answer: An L4 order book is the full book with every individual order identified and tracked from placement to cancellation or fill, whereas L2 shows only aggregated size per price level. On Hyperliquid you rebuild it by replaying the order and fill events from raw node data in the exact sequence the chain processed them; the hard parts are ordering, missing events and state drift.
Most order book data people work with is L2 — aggregated size at each price level, no visibility into individual orders. L4 goes further: every individual order, tracked from placement to cancellation or fill, with its own identity through the book’s lifetime.
What L4 gives you that L2 can’t
With L2 you can see that there’s 40 BTC of bids at a price level. With L4 you can see that it’s composed of, say, 12 separate resting orders, when each was placed, and which ones get pulled the instant price approaches — a pattern L2 aggregation hides completely. This level of granularity is what real market microstructure research and serious execution algorithms are built on.
Why reconstruction is non-trivial
Hyperliquid’s raw stream gives you the primitives — order events, not a pre-built order-by-order book state. Reconstructing a correct, gap-free L4 book means tracking every add/modify/cancel/fill event in the right sequence, handling the stream’s actual event ordering correctly (see our post on HyperBFT consensus for why naive timestamp sort isn’t always safe), and reconciling against periodic snapshots to catch any drift.
L1, L2 and L4 at a glance
| Level | What you see | What you cannot see |
|---|---|---|
| L1 | Best bid and ask | Everything behind the top of book |
| L2 | Aggregated size at each price level | Which orders make up that size |
| L4 (as used here) | Each individual order with its own identity over its lifetime | Nothing in the book; only intent not yet placed |
What you can compute only with L4
Queue position and fill probability for a resting limit order, order lifetimes and cancel-to-trade ratios, cancellation patterns that look like spoofing, and realistic slippage when your own order would have consumed several levels. These are exactly the inputs that make execution backtests honest.
A minimal replay loop
The skeleton below is simplified: real node data has more event types and ordering rules, but the structure is the same.
book = {} # order_id -> (side, price, size)
def apply(event):
t = event["type"]
if t == "place":
book[event["oid"]] = (event["side"], event["px"], event["sz"])
elif t == "cancel":
book.pop(event["oid"], None)
elif t == "fill":
side, px, sz = book[event["oid"]]
remaining = sz - event["sz"]
if remaining > 0:
book[event["oid"]] = (side, px, remaining)
else:
del book[event["oid"]]Validate the result: aggregate your rebuilt orders by price and compare them with an independent L2 snapshot at regular checkpoints. A mismatch means an event was missed, duplicated or applied out of order.
Skip the plumbing
If you would rather not maintain this pipeline yourself, L4 Order Book Reconstruction packages the state machine core ($29): you bring the order-status stream from your own non-validating node; S3 download and LZ4 decompression are not included. For what to do with the book once you have it, see real-time order book imbalance and the HyperBFT backtest ordering engine.
FAQ
What is an L4 order book?
An L4 order book tracks every individual order from placement to cancellation or fill, each with its own identity, instead of only the aggregated size at each price level that L2 shows.
What is the difference between L2 and L4 order book data?
L2 tells you there is, for example, 40 BTC of bids at a price. L4 tells you which individual orders make up that 40 BTC, in what order they arrived and which ones were later cancelled or filled.
Why is reconstructing an L4 book from Hyperliquid node data hard?
Events must be applied in the exact order the chain processed them, missing or duplicated events silently corrupt the book, and small errors accumulate over time. You need checks that compare the rebuilt book with independent snapshots.
What can I do with L4 data that I cannot do with L2?
Estimate queue position and fill probability for limit orders, measure order lifetimes and cancel-to-trade ratios, spot spoofing-like behavior, and simulate slippage and fills far more realistically in backtests.
Summary
L4 reconstruction unlocks a level of order book detail L2 snapshots simply don’t contain — but building it correctly means handling event ordering and stream reconciliation with real care, not just replaying events in the sequence they happened to arrive.