Order book reconstruction starts from a full snapshot of the book and applies every later change, or diff, in the order the venue published it [16, 19, 27]. The book at any moment is the last snapshot plus every diff after it. The work sits in three places: reading what a diff's size means, finding the first diff that follows the snapshot, and noticing when a diff goes missing.
One missed diff leaves the book wrong until it is resynchronized. CME Group's rule for its MDP 3.0 feed is direct: after a packet gap, "it should be assumed that all books maintained in the client system may no longer have the correct, latest state" [1]. Each venue sets its own rules for sequencing, batching and recovery.
This note reads the published rules of CME MDP 3.0, Nasdaq TotalView-ITCH, Binance, Coinbase, Kraken, Lighter and Hyperliquid as they stood on 24 October 2026, and turns them into one procedure with tests.
What a diff's size means
Coinbase, Binance and Lighter send the new total at a price level [16, 19, 28]. Coinbase defines its level2 size as "the updated size at the price level", and a size of "0" removes the level [19]. Binance Spot tells clients to "set the new quantity" and to remove a level whose quantity is zero [16]. Lighter's size "is its new total" [28]. Kraken removes a level on a quantity of 0 [22].
Order-level feeds can send amounts to subtract. In Nasdaq TotalView-ITCH, an execution or a partial cancel states the shares removed from an order, and repeated messages are cumulative [12].
CME's market-by-order Update carries the order's new displayed quantity: an order raised from 30 to 50 arrives as 50, with a new, lower priority [4]. Hyperliquid's node records an order update with both the old size, origSz, and the new one, newSz [32]. CME's market-by-price book addresses levels by position: an add shifts lower levels down, and the client deletes any level past the depth set in tag 264 [3]. CME's trade data block and ITCH's Trade Message, sent for non-displayable orders, do not change the book [3, 12].
Order book snapshot and delta alignment
Where the snapshot comes from a separate request, every documented procedure has the same shape: buffer the diffs, take the snapshot, drop the diffs the snapshot already contains, then apply the rest [7, 16, 19].
Binance Spot spells it out. Buffer the stream and note the first event's U. Fetch a snapshot of up to 5,000 levels per side. If its lastUpdateId is below that U, fetch again. Discard every event whose u is at or below lastUpdateId [16]. Coinbase's full channel discards queued messages with sequence numbers "before or equal to the snapshot sequence number" [19]. CME compares tag 369, LastMsgSeqNumProcessed, on each recovery snapshot with the incremental feed's packet numbers and drops cached packets below it [7]. Nasdaq's GLIMPSE, as specified for its BX market, ends each snapshot with a message naming the ITCH sequence number to start from [14].
Sequence gap detection
Each venue numbers updates its own way, and the gap test has to match.
| Feed | What is numbered | Gap test |
|---|---|---|
| CME MDP 3.0 | Each packet, per channel, reset weekly. Tag 83 RptSeq per instrument | A skipped packet number [2, 6] |
| Nasdaq ITCH over MoldUDP64 | The first message in each packet, later ones implied | Next expected number not received [13] |
| Binance Spot | First and last update ID per event, U and u |
U above the local update ID + 1 [16] |
| Binance USD-M Futures | Each event's pu, the previous event's u |
pu unequal to the previous u [17] |
| Coinbase full and level3 | Each message, per product | A jump of more than one [20] |
| Lighter | A nonce range per update, plus a server offset | begin_nonce unequal to the previous nonce [27, 28] |
| Kraken Spot book v2 | No sequence field listed | None. The checksum shows a wrong book [22, 23] |
| Hyperliquid l2Book | Nothing: every push is a snapshot | None needed [29] |
Three traps recur. Lighter's offset increases on each update, but it is "not guaranteed to be continuous" and can change sharply when a reconnect lands on a different server, so the nonce is the field to check [27, 28]. One Lighter update spans a range of nonces, so a test that expects +1 per message fails [27]. Some numbers skip by design. In NYSE Daily TAQ, Tape A and B sequence numbers equal the CTA block number times 100 plus the message ID, and they "do not increase continuously" [15]. CME's per-product historical files skip packet numbers that "were assigned to another product" [10]. A plain +1 test raises false alarms on both.
Silence needs a test as well. MoldUDP64 heartbeats carry the next expected sequence number, so a receiver can tell a quiet market from lost packets [13].
Batches, depth limits and snapshot-only feeds
A book read in the middle of a batch is not valid. CME requires every book update in the latest incremental message to be processed first, and one event can span several packets [1, 2, 5]. Kraken can send several updates to the same price level in one message, to be applied in order [23]. Coinbase's level2_batch channel and Lighter's order book channel send batches every 50 milliseconds [19, 27].
Depth limits leave parts of the book unknown. Binance warns that levels outside its 5,000-level snapshot stay unknown "unless they change" [16]. Kraken sends no zero-quantity update for a level that falls out of the subscribed depth, so the client truncates its book after each update [22, 24]. An unknown level and an empty level are different facts, and a rebuilt book should record which is which.
Some feeds send snapshots only. Hyperliquid's l2Book pushes 20 levels, or 5 in fast mode, "on each block that is at least 0.5 since last push", with no sequence field [29]. A history built from it has the cadence and depth of those pushes.
Order book checksum and other state checks
Among the feeds read, only Kraken documents a checksum. Each book message carries a CRC32 over the top 10 levels per side, whatever depth is subscribed [22]. The input is the asks and then the bids, with decimal points and leading zeros removed [22]. This note's own computation from the levels in Kraken's worked example gives the documented 3310070434 [22].
Other checks need no venue support. Kraken states that its level 3 book "will never be crossed" [25]. This note treats a rebuilt book whose best bid meets or passes its best ask in continuous trading as a failed check, to be compared against the source.
Building a market-by-order book
CME tells clients to sort orders by price and then by tag 37707, where a lower value means higher priority [4]. An ITCH Order Replace retires the old reference number and issues a new one "for all subsequent updates", and side and symbol carry over from the original Add Order [12]. Coinbase's full channel sends done and change messages for orders that never reached the book, and applying them makes the book incorrect [19].
Recovery and replaying historical order book data
Venues offer three ways back: a fresh snapshot, a replay of the missed messages, or a new subscription. CME recommends processing both of its redundant A and B feeds, then offers a snapshot loop for large recoveries and TCP replay for small ones, capped at 2,000 packets per request and 24 hours of history [1, 7, 8]. Binance says to discard the book and restart, and Lighter's guide resubscribes [16, 28]. In a CME channel reset the client empties the book and RptSeq restarts at 1, which a gap test must read as a reset [9].
Archives carry gaps too, and some list them. CME's packet capture dataset lists its known gaps by date [11]. Hyperliquid uploads its archive "approximately once a month" and states that "data may be missing" [30]. A published research dataset of order data from Hyperliquid's perpetual futures states its coverage by month: 744 hourly book-diff files for December 2025 with no gaps, and trade files missing 2, 10, 0 and 1 hours from October 2025 to January 2026 [33]. The note on datasets that state their limits sets out how scope and refresh can travel with every record.
Order book reconstruction tests
A rebuilt book should pass these tests:
- Every update passes the venue's continuity rule, with documented skips and resets handled [9, 10, 15].
- The first applied diff meets the venue's boundary rule [7, 14, 16].
- No check runs in the middle of a message, event or batch [1, 22].
- The checksum matches, where the venue sends one [22].
- The best bid stays below the best ask in continuous trading.
- The book is cut to its subscribed or published depth [3, 22].
- Every gap and resync is recorded with its time range.
Rillor's market data holds on-chain perpetual futures order books rebuilt from snapshots and book diffs. Book sequence numbers are checked on every rebuild, and gaps are written into the coverage notes for each instrument [34].
Read the full report
The full report sets out each venue's rules with exact field names, a cross-venue comparison table, a venue-neutral procedure in pseudocode with ten tests, and the complete source list.