A missing order-book level is not evidence of zero liquidity when the feed or snapshot has a depth limit. It may lie outside the observed range and remain unknown until the venue publishes it. Track the book's coverage boundary as well as quantities; continuous updates and a familiar row count do not prove that all prices relevant to an order are visible.
The dangerous case can look healthy. Messages keep arriving, quantities change and the local table contains as many rows as the original snapshot. Yet an unchanged price level may never have entered that table. A depth calculation can silently turn a limit on observation into a statement about the market.
The distinction matters before estimating available size, calculating imbalance or calling the lowest stored ask the best ask. The following hypothetical ledger makes the missing information explicit. It is a teaching construction, with no live market capture or execution result.
Give absence a reason
An order-book collector needs more than a mapping from price to quantity. It needs a reason for treating an absent price as empty.
For Binance Spot's documented diff-depth procedure, an update sets a level's quantity, inserting a previously unknown price when necessary; a zero quantity removes that level. These instructions describe an explicit state change. They do not turn every price missing from the initial snapshot into zero. See the Binance Spot local-book procedure.
| What the consumer knows | Meaning at that observation | Suitable treatment |
|---|---|---|
| Current positive quantity in valid scope | Displayed quantity was observed | Use with its observation and validity conditions |
| Explicit zero update | That displayed level was removed | Remove it under the channel's rules |
| Price omitted by the depth limit, with no later valid update | Quantity was not established | Preserve as unknown |
| An update gap or invalid initialization | Maintained state is unverified | Recover before relying on derived values |
These distinctions apply within the public feed's representation. The Level 1, Level 2 and Level 3 comparison explains a separate question: what each record represents. A more detailed record type does not, by itself, establish unlimited price coverage.
Three observed rows can still miss an intervening price
Consider a fictional asset quoted in USDT. Quantities below are base-asset units at each price, not cumulative units. The complete teaching ledger initially contains five ask levels. The consumer receives only the lowest three.
| Ask price, USDT | Units at price | Included in initial view? |
|---|---|---|
| 100 | 2 | Yes |
| 101 | 3 | Yes |
| 102 | 4 | Yes |
| 103 | 5 | No |
| 104 | 6 | No |
The three-level window keeps the arithmetic readable; it is not a claim about an exchange's subscription options. Assume a snapshot followed by continuous, ordered, full-range quantity-change deltas. An unchanged level outside the initial view is not repeated. Ignore executions, latency and other market changes beyond the events listed.
The initial view establishes the ask book through price 102. It says nothing about higher asks. Now apply three events to both the full teaching ledger and the consumer's partial copy.
| Stage | Quantity changes delivered | Consumer's positive asks, price × units | True best ask in teaching ledger |
|---|---|---|---|
| T0 | Initial view | 100 × 2; 101 × 3; 102 × 4 | 100 |
| T1 | Set 100 to zero | 101 × 3; 102 × 4 | 101 |
| T2 | Set 104 to 7 | 101 × 3; 102 × 4; 104 × 7 | 101 |
| T3 | Set 101 and 102 to zero | 104 × 7 | 103 |
At T1 the consumer has two rows. The unseen level at 103 has not changed, so this model provides no message containing its five units.
At T2 the update at 104 brings the row count back to three. That does not restore the top three asks. The actual three lowest prices are 101, 102 and 103; the collector instead holds 101, 102 and 104. Sorting the stored prices correctly cannot recover an omitted price.
A quantity sum needs a coverage label
At T2, suppose a report asks for displayed ask quantity within 3% above the best ask of 101. The upper price is 101 × 1.03 = 104.03 USDT.
The partial copy sums 3 + 4 + 7 = 14 units. The full teaching ledger contains 3 + 4 + 5 + 7 = 19 units in that band. Calling 14 the complete total understates this constructed book by five units, or 5 ÷ 19 × 100 = 26.32%, rounded.
A real consumer would not know that the correct total is 19. That number belongs to the deliberately complete teaching ledger. It can report 14 observed units with incomplete coverage, subject to the example's continuity assumptions. It cannot infer the missing quantity or its percentage from the partial data alone.
A narrower request has a different answer. At T2, quantity at or below 102 is seven units, and that region remains within the original supported view. One collector can therefore support a complete narrow sum and an incomplete wider sum at the same moment.
The slippage and order-book depth worksheet uses visible quantities to estimate fills. Apply a coverage check before that arithmetic. A model that runs out of observed rows has reached its evidence boundary; it has not established that the venue runs out of liquidity there.
The missing level can become the best ask
At T3, both remaining prices inside the initial boundary disappear. The lowest stored ask becomes 104. The actual best ask is the unchanged, unseen 103.
There was no missing delta in this construction. Every listed event arrived and was applied correctly. The collector still cannot certify a best ask from its remaining row. Treating transport continuity as proof of complete top-of-book coverage would produce a false quote.
The appropriate state is that the supported initial ask range is empty and the best ask is unestablished by this copy. A fresh snapshot, correctly joined to subsequent updates, can establish a new bounded view. Merely waiting for another unrelated change does not guarantee that 103 will be reported.
Venue rules decide which levels belong in the cache
The example illustrates a documented limitation of snapshot-plus-delta reconstruction. As reviewed on 28 October 2026, Binance Spot's REST order-book endpoint returns at most 5,000 levels per side; its REST market reference specifies the limit. Binance's stream documentation warns that quantities outside the initial snapshot remain unknown unless those levels change. More starting levels extend the observed range without making it unlimited.
Do not transfer cache rules between channels. Kraken Spot WebSocket v2's L2 book reference offers subscription depths of 10, 25, 100, 500 and 1,000 levels per side. Its maintenance guide requires truncating the local book to the subscribed depth after updates: levels leaving scope do not receive explicit zero-quantity removals.
Consequently, retaining every historical Kraken level as if it remained current would violate that channel's maintenance contract. Falling outside a maintained window is different from receiving an explicit removal at a price. Both may remove a local row, but they justify different claims about liquidity beyond the window.
Kraken's guide also limits its checksum to the top ten price levels on each side regardless of subscription depth. A passing comparison does not certify an unobserved outer region. The order-book checksum guide develops that validation boundary without confusing byte agreement with complete depth.
Attach a coverage record to each calculation
For the snapshot-plus-full-range-delta model used above, preserve the original outer ask price as a conservative coverage boundary. An isolated update at a higher ask establishes that row's quantity; it does not establish all intervening rows. The bid-side reasoning reverses direction: the initial lowest included bid marks the outer boundary on that side.
This is an inference from the example's information model, not a universal replacement for a venue's feed specification. A stream maintaining a moving subscribed-depth window needs its own scope rules.
| Record | What to capture | Decision it supports |
|---|---|---|
| Identity | Venue, product, symbol and channel | Prevent mixing incompatible books |
| Initialization | Snapshot identifier, requested depth and returned rows | Define the starting evidence |
| Coverage | Outer observed boundary on each side and scope rule | Decide which requested price range is supported |
| Continuity | Last accepted update and validation state | Distinguish bounded data from broken reconstruction |
| Timing | Observation and local receipt times | Apply the consumer's freshness policy |
| Query | Side, price interval and completeness status | Keep a sum from implying wider coverage |
Do not move the coverage boundary outward just because the largest stored price increased. At T2, that would incorrectly certify the missing 103 level. Likewise, a dashboard should distinguish an incomplete sum from a complete zero and an invalid calculation.
Retain native price-level resolution when establishing these boundaries. Price-level grouping can combine several prices into display buckets. Counting those buckets does not reveal how many native levels were observed or whether the requested price interval was fully covered.
Replay the boundary before trusting the number
Use the four-stage ledger as a small validation exercise for a collector or data review:
- Initialize the partial copy with only 100, 101 and 102. Confirm that 103 and 104 are unknown, rather than initialized to zero.
- Apply T1 and T2. Require three stored rows while still flagging the interval through 104.03 as incomplete. Check the observed sum of 14 and complete sum of seven through 102.
- Apply T3. Require the collector to withhold a certified best ask from this copy, even though it retains the observed quantity at 104.
- Separately introduce a sequence gap. Mark reconstruction invalid and follow the venue's recovery procedure. Do not describe that state merely as truncated depth.
- Reinitialize from a supported fresh snapshot and join updates according to the channel contract. Replace the old coverage record with the newly established one.
Binance's documented synchronization procedure requires rebuilding when a forward update-ID gap is detected. Its initialization also buffers stream events around snapshot acquisition. The WebSocket recovery guide addresses that sequencing task. Fetching a snapshot without joining it correctly can replace a coverage problem with a continuity problem.
For each downstream depth figure, write the side, price interval, observation time and whether coverage is complete. If the requested interval extends beyond the supported view, return an explicitly incomplete observation or obtain suitable fresh data before answering. Keep unknown liquidity unknown all the way to the decision that consumes it.