Reconstructing L3 queues and fill probability on Hyperliquid

Why queue position matters

An L2 book tells you there are 14.2 BTC bid at a price. It does not tell you whether that is one order or ninety, how long each has been there, or where a new order would sit. For anyone who quotes, those details decide almost everything: how likely a resting order is to fill, how long it will wait, and how much the price tends to move against it once it does fill.

On a venue with price-time priority, each level is a first-in, first-out queue. If you can see every order event, you can rebuild the queues exactly and answer those questions directly from data. This note describes how we do that on Hyperliquid and what a month of reconstructed queues shows.

Inputs

We run non-validating Hyperliquid nodes in Tokyo and Ireland and read their order-status and raw book-diff output alongside the public WebSocket feed. Every order event carries a block height, its index within the block, an order id and the user address that placed it. The address is what makes L4 possible on this venue. For queue reconstruction we only need the first three.

The study covers June 1 to June 30, 2026, for the BTC, ETH and SOL perpetuals.

The last column is the share of added orders that were cancelled without receiving any fill. Most displayed liquidity on these books is placed and pulled by automated quoting, and only a few percent of orders ever trade.

Reconstruction rules

Each price level is an ordered list keyed by block height and then index within the block. The events map onto it as follows:

Rule 04 was not in our first version, which treated every modify as a cancel and re-add. The fill check below is what showed us it was wrong.

Validation

Against L2 snapshots

Once a second, we compared the top 20 levels on each side of our reconstructed book with the public L2 snapshot for the same block. June produced 2.59 billion level comparisons, and 99.986% matched in size exactly. Of the mismatches, 91% fell within 3 seconds of a node restart or a recorded gap. The rest were small differences at levels 15 to 20, where snapshot aggregation timing differs slightly from ours.

Against fills

Matching level sizes does not prove the order inside a level is right. A stronger check uses fills: on every maker fill, the venue tells us which order was filled, and our queue should predict it as the order at the front. In the first version the prediction was correct for 97.9% of fills. Almost all the misses involved orders that had reduced their size through a modify and that our rules had sent to the back of the queue. The venue had kept them in place. After changing the rule, the match rate was 99.71%.

The remaining 0.29% are mostly fills at levels where several orders arrived in the same block and our within-block ordering disagrees with the venue's. We have not found a rule that resolves them. They are flagged in the data so that anyone measuring queue position can exclude them.

Queue position and fill probability

For every order that joined the best bid or ask, we recorded the size ahead of it at the moment it joined, in multiples of the symbol's median trade size for June ($1,840 for BTC, $1,120 for ETH and $620 for SOL). The outcome is whether the order received any fill within 10 seconds.

Most orders are cancelled long before 10 seconds, so a raw fill rate would mostly measure how impatient quoting algorithms are. We treat a cancel as censoring and estimate the fill probability with a Kaplan-Meier estimator, which answers a cleaner question: the chance of a fill within 10 seconds for an order that stays in the book.

Probability of any fill within 10 s for an order resting at the best price, by size ahead at join in multiples of median trade size. June 2026.

FILL PROBABILITY WITHIN 10 SFDC HYPERLIQUID CAPTURE

The curve is steep. With less than one median trade ahead, an order at the best BTC price fills within 10 seconds more often than not. With more than ten ahead the chance drops below 7%. SOL fills more readily at every position because its queues turn over faster relative to their size.

Where in the queue fills hurt

Fill probability is half the picture. We also measured the 1-second markout on maker fills, from the maker's side, split by the queue position the order had when it joined. Orders that joined with less than one median trade ahead had an average 1-second markout of −0.21 bp on BTC. Orders that joined with more than ten ahead and were later filled averaged −0.58 bp.

The mechanism is intuitive once the queues are visible. An order near the front gets filled by routine small flow. An order far back only fills when an aggressor takes out most of the level, and those sweeps tend to come just before the price moves through it. The orders that are hardest to fill are also the ones that fare worst when they do. The same split holds on ETH and SOL, with gaps of 0.31 bp and 0.44 bp.

From this study to the data

The reconstruction described here is the code that produces our book_l3 table for Hyperliquid, and adding the user address to each event produces book_l4. Two extended fields come straight out of it. QUEUE publishes queue ahead and order age at the best levels, with a fill-probability estimate from the model above refit monthly. CXL/FILL reports how much displayed size at each level is cancelled for every unit that trades. Both were used in our study of extended fields and short-horizon direction.

Limitations

• The Kaplan-Meier estimate assumes that cancels are unrelated to an imminent fill. That is not quite true: quoting algorithms pull orders when they expect the price to move through them. The estimates above are therefore somewhat optimistic for orders that would have been cancelled.
• Queue position at join assumes the order lands in the block it was sent for. A participant with higher latency to the venue will usually join further back than the book suggests.
• One month of data on one venue. Other venues that publish order-level data have their own priority and modify rules, and the rules above will not carry over unchanged.
• The 0.29% of fills with ambiguous within-block ordering are excluded from the fill-probability estimates.

The event types and their fields are documented in order book depth.