Sequence number (gap detection in market data)
A sequence number is the counter a market data feed attaches to each message or packet so that the receiver can prove it missed nothing. A jump in the sequence means lost data, and the only safe response is to recover: request a replay or rebuild the book from a snapshot, rather than keep applying updates to a book that is no longer true.
Senzoukria · Glossary · Updated September 2026
Definition
Feeds that send incremental changes depend on every change arriving in order. Each packet or message therefore carries a number that increases by a known step. The receiver compares each new number with the last one: equal plus one is fine, lower is a duplicate, higher is a gap. Exchange feeds such as CME's MDP 3.0 number their packets and publish each channel on two redundant feeds so a packet lost on one can be taken from the other.
Worked example: detecting a gap
Packets 1041 and 1042 arrive, then 1045. Packets 1043 and 1044, two packets, are missing. Any book update they carried is unknown, so the book held after 1045 cannot be trusted until recovery.
Worked example: stitching a snapshot to a stream
Binance sends depth updates carrying a first id U and a last id u, and a separate snapshot carrying lastUpdateId. On Spot, with a snapshot at L = 500: discard buffered events whose u is at most 500; the first event kept must satisfy U <= 501 <= u, for example U = 498 and u = 503; each following event must start at the previous u + 1, here U = 504. USD-M futures use a different chaining rule, a pu field that must equal the previous u, and applying one market's rule to the other either loops on resynchronisation or lets a gap through.
In Senzoukria
The Binance book synchroniser applies those procedures as a separate, tested module, with the Spot and USD-M rules kept distinct, and resynchronises from a new snapshot when a gap is detected instead of patching. Its source explains why: a wrong stitch raises no error, it produces a normal-looking book with levels that no longer exist, the worst possible defect on a liquidity heatmap. For CME data the exchange-level recovery is handled by the vendor. On a Databento live trades session interrupted by a disconnection, the application reopens it from the last received trade's timestamp plus one nanosecond, so the trades in between are replayed rather than lost; the MBP-10 book is not replayed.
Common mistakes
- Continuing to apply updates after a gap because the book still looks plausible.
- Using timestamps instead of sequence numbers to detect loss.
- Applying one venue's stitching rule to another venue or market.
Related
In the same section
- Session range
- Self-match prevention
- Session review
- Security definition
- Session volume profile
- Scripting
- Sharpe ratio
- Scaling plan
This page in other languages
Frequently asked questions
- What should a platform do after a sequence gap?
- Stop trusting the book, recover through a replay or a fresh snapshot, and only then resume applying updates. Drawing the stale book in the meantime shows liquidity that may no longer exist.
- Do trade feeds have sequence gaps too?
- Yes. A gap in trades means missing prints, which would understate volume and distort delta at the affected prices. Recovery by replay, where the source offers it, restores them.