Why Two Order Books Differ: Snapshot and Update Checklist
Check the snapshot, update sequence, replacement quantities and integrity evidence before treating a saved order book as current.
Check when and how the snapshot was captured
An order book is a recorded state that changes over time. Two views can differ because they cover different moments, depths or update histories. Before interpreting the difference as a market opportunity, identify the venue, instrument, subscribed depth and observation time of each view. A screen that lacks those details cannot establish which state was current when a particular order was handled.
Separate event sequence from local receipt time
A snapshot supplies a starting state, while later updates describe changes under the venue's protocol. Their sequence matters as well as the time your device received them. Retain snapshot and update identifiers where the source provides them. The goal is to recognize whether an observation has a documented continuous history; a local receipt timestamp alone cannot reconstruct a missing update.
Interpret a level update using the source schema
Quantity fields need their schema. Coinbase level2 updates provide a new complete size for a level rather than an amount to add to the old size. Binance also documents level replacement and removal at zero. Keep the documented meaning next to a saved quantity so that an interpretation does not silently multiply changes or leave a removed level in a reconstructed record.
Record any gap or integrity failure
A gap or integrity failure changes what the observation can establish. Binance documents rebuilding after a sequence gap, while Kraken documents its own message ordering and checksum procedure. Record the failure rather than inventing an unseen level or update. This checklist describes the evidence to retain; it does not implement a feed, verify a live book or calculate an expected execution price.
Keep stale state visible instead of inventing continuity
Use the worksheet to label the snapshot, update range, quantity meaning and integrity state. The hypothetical sequence makes a missing event visible, without prescribing a universal synchronization algorithm. Record rebuilt, stale or unknown when those descriptions fit the available evidence. A later intact snapshot may support a later observation, but it should not overwrite the history of an earlier gap.
Documented venue distinctions
These statements apply to the named provider and documented product. They do not imply identical rules elsewhere.
- Binance describes a venue-specific snapshot, buffered-update and gap-recovery procedure; quantities replace levels and zero removes a level. Official reference.
- Coinbase level2 sends a snapshot followed by updates with the new full level size, rather than a quantity increment. Official reference.
- Kraken v2 specifies message update ordering, deletion and a checksum over the top ten levels. Official reference.
Hypothetical case
Hypothetical Binance snapshot ID 100 is followed by a buffered update range 99–102 and then 103–104. A later event starting at 106 indicates missing continuity after 104. The checklist flags the gap rather than fabricating a missing update.
Six questions for your record
- What venue, instrument and subscribed depth are recorded?
- What snapshot identifier and capture time exist?
- What sequence fields belong to each update?
- Does quantity mean replacement or increment here?
- Was a gap or checksum failure recorded?
- Is the state current, rebuilt, stale or unknown?
Keep your own record
The CSV contains column headings only. The TXT contains the review questions and blank note spaces. Keep original evidence separately, preserve identifiers as text and leave missing facts unknown. Neither file sends data or performs an account check.