출처 검증 리서치: Binance Local Order BOOK

Related on NexuAlpha: OKX order book checksum deprecation: seqId and prevSeqId.

Decision outcome: Use either feed only after the client can bootstrap from a snapshot, apply deltas in order, detect a sequence break (Binance update IDs; OKX seqId and prevSeqId, not the deprecated OKX checksum), rebuild the book, and prevent stale depth from reaching an execution strategy.

Evidence snapshot. This article was researched at 2026-09-20T20:37:33.123Z using Binance Developers, OKX API Docs. A local queue, old generated draft, search snippet, social repost, price chart or AI summary was not treated as proof. Those surfaces can suggest a question, but every material claim below maps to the public source list for this article. Correction, October 11, 2026: the first version of this article described OKX depth validation as checksum-based; the OKX passages now follow OKX's API changelog entry of June 23, 2026 and its checksum-deprecation notice.

Verified facts. Claim c1: Binance Spot WebSocket documentation describes diff depth streams used to locally manage an order book. Claim c2: Binance Futures documentation describes buffering stream events, obtaining a depth snapshot, matching update IDs and reinitializing when continuity breaks. Claim c3: OKX API documentation exposes order-book market-data WebSocket channels; since June 23, 2026 the checksum field on books, books-l2-tbt and books50-l2-tbt is fixed to 0, and OKX says to use seqId and prevSeqId to verify data continuity. Claim c4: A working WebSocket connection alone does not prove that a local book is current, gap-free or safe for automated execution. These facts are deliberately narrow. They do not prove personal eligibility, future availability, execution quality, legal status beyond the cited wording, tax treatment, account approval, customer support outcome, redemption success, price direction, liquidity depth or platform solvency.

What changed at OKX. OKX's API changelog entry dated 2026-06-23 says the checksum field was deprecated in both snapshot and incremental updates on the books, books-l2-tbt and books50-l2-tbt channels; the field is still present, but its value is fixed to 0 and must no longer be used for integrity verification. OKX's order book documentation says the prevSeqId of a new message matches the seqId of the previous message, snapshot messages carry a prevSeqId of -1, a keep-alive message with empty asks and bids repeats the last seqId, and maintenance can reset the sequence so that one incremental message arrives with a seqId smaller than its prevSeqId. The books5 and bbo-tbt channels never carried a checksum and are not affected. A client that still compares the checksum should move its gap test to seqId and prevSeqId and resubscribe for a fresh snapshot whenever the chain breaks.

How Binance's procedure works. Binance's Spot WebSocket documentation lists the steps under "How to manage a local order book correctly": open a diff depth stream and buffer its events, noting the first update ID (U) received; fetch a depth snapshot from the REST depth endpoint; if the snapshot's lastUpdateId is strictly lower than that first U, fetch the snapshot again; discard buffered events whose last update ID (u) is at or below lastUpdateId; set the local book to the snapshot; then apply the buffered events and every later event in order. An event whose last update ID is lower than the local book's update ID is ignored. If an event's first update ID is greater than the local book's update ID plus one, events were missed, and Binance says to discard the local book and restart from the beginning. For each price level, a quantity of zero removes the level and any other quantity replaces it, and the book's update ID becomes the event's last update ID. Binance also notes that a REST snapshot carries at most 5,000 levels per side, so levels outside the initial snapshot stay unknown until they change. Binance's futures guide follows the same buffer, snapshot and update-ID matching pattern and reinitializes when continuity breaks.

Decision discipline for Binance local order book vs OKX checksum depth controls. The useful answer is not a universal winner. It is a source-bound scorecard: which official source answers the immediate question, which control is blank, which blank changes user risk, which test is reversible and which condition reopens the decision. An honest blank is safer than an invented advantage.

FAQ. What is the short answer? Both venues need snapshot-plus-delta reconstruction with a continuity test: Binance uses update IDs, and OKX uses seqId and prevSeqId because its order-book checksum has been fixed to 0 since June 23, 2026. What should be verified first? Verify the official source and the exact control surface. What should not be inferred? Do not infer eligibility, future support, legal treatment, tax treatment, recovery, execution quality, liquidity, redemption, consumer protection or account approval. When should the user stop? Stop when source, object, user state, permission, route, issuer, jurisdiction or failure handling is unclear.