An absolute order-book quantity replaces the stored size at a price; a quantity delta adds to or subtracts from it. A message named delta can still carry replacement sizes. Use the exact channel's quantity, zero-deletion and snapshot rules, because adding a replacement value can inflate the stored liquidity.
Suppose your local bid at one price contains 5 units and the next update contains 2. The correct result could be 2 or 7. Both calculations are simple. Choosing between them requires knowing what the received field represents.
That choice affects every later depth calculation. A book with inflated quantities can show a sensible spread while overstating how much size is available. The error often begins with treating the word “incremental” as an instruction to add.
A delta message can contain replacement sizes
There are two separate questions: which rows does the message contain, and what operation should each row perform? An incremental message can contain only changed prices while supplying the complete new quantity at each of those prices.
For a replacement quantity, set the stored size to the received size. For an additive quantity, add the received change to the stored size. “Absolute” here means the new total; it is not an instruction to take a mathematical absolute value and turn negative inputs positive.
The following primary documentation was checked on 28 October 2026. Each rule belongs to the stated channel.
| Documented channel | Meaning of a changed price's quantity | Zero handling |
|---|---|---|
| Binance Spot diff-depth | Set the new quantity; insert the price if absent | Remove the level |
| Bybit v5 public orderbook | A delta message updates an existing entry's value or inserts a new entry | Delete the entry |
| Coinbase Exchange level2 | The size is the updated total at the price | Remove the level |
Coinbase's documentation explicitly distinguishes its updated size from a quantity delta. Bybit uses delta as a message type while documenting insert, update and delete operations. Therefore, a shared parser that adds every value from a message named delta would misread these price-level updates.
Identify the representation first. Aggregated quantity at a price and remaining quantity on one identified order are different state objects. The Level 1, Level 2 and Level 3 comparison explains what each representation can reveal before an update rule is chosen.
Replay four received quantities under two contracts
This original hypothetical fixture tracks one bid at 100.00 quote units per base unit. Its starting quantity is 5.00 base units. A second bid at 99.00 holds 4.00 units and receives none of these updates. Every row below is assumed eligible and applied in the displayed order; message sequencing is deliberately outside this arithmetic comparison.
Contract A treats each received nonnegative quantity as a replacement total and deletes a level when that total is zero. Contract B is a deliberately hypothetical additive contract: received values are signed changes, zero is a no-op, and a resulting total of zero removes the level. In Contract B, an absent level starts at zero and a negative resulting total is rejected. These declared rules illustrate addition without attributing it to an exchange feed.
| Step | Received quantity | Contract A: stored replacement total | Contract B: stored total after addition |
|---|---|---|---|
| Starting snapshot | 5.00 | 5.00 | 5.00 |
| First update | 2.00 | 2.00 | 7.00 |
| Second update | 1.25 | 1.25 | 8.25 |
| Third update | 0.00 | Level removed | 8.25 |
| Fourth update | 3.00 | 3.00, reinserted | 11.25 |
The replacement path ends at 3.00. The additive path ends at 5.00 + 2.00 + 1.25 + 0.00 + 3.00 = 11.25. The final difference is 8.25 units, even though both consumers saw identical numbers.
The zero row is particularly revealing. Replacing a size with zero removes liquidity under Contract A. Adding zero changes nothing under Contract B. A rule that always interprets zero as a deletion would also misread the hypothetical additive contract.
To express the replacement path as signed changes instead, the messages would have to contain −3.00, −0.75, −1.25 and +3.00. Starting from 5.00, those changes produce 2.00, 1.25, zero and 3.00. Their sum is −2.00, which reconciles the starting and ending totals.
That conversion requires the correct previous total at every step. Converting a replacement update after losing its predecessor can manufacture a false increment. Preserve the raw field meaning when normalizing feeds, and record whether the normalized output is a total or a change.
Repeated arithmetic does not establish message eligibility
Replacement has a useful narrow property: immediately assigning the same value twice leaves the same result. Starting at 5.00, replacing with 2.00 twice leaves 2.00. Adding +2.00 twice produces 9.00 rather than the 7.00 obtained after one addition.
That property does not make every repeated or late replacement safe. If a later accepted update has already reduced the size from 2.00 to 1.25, replaying the older 2.00 restores stale liquidity. The assignment is mathematically valid and temporally wrong.
The venue's event-admission rules must run before its quantity mutation. Binance Spot's documented procedure uses its snapshot boundary and update identifiers to decide which diff-depth events can be applied and when a gap requires rebuilding. Those identifiers and comparisons belong to that protocol; the same arithmetic operation does not make them portable to another venue. See the official Binance procedure.
Keep a replay log capable of answering two questions separately: why was this event accepted, and how did each accepted row change the book? The WebSocket recovery guide covers continuity recovery. A consumer can pass every quantity example here and still need that recovery after missing messages.
A snapshot reset changes the meaning of absence
For Bybit v5's documented public orderbook stream, receiving a new snapshot requires resetting the local order book. Its documentation also says linear, inverse and spot Level 1 streams are snapshot-only, so an adapter must not assume every subscription alternates between snapshot and delta messages. See Bybit's snapshot processing rules.
Consider a second hypothetical fixture. After the replacement replay above, the retained bid side contains 3.00 units at 100.00 and an unchanged 4.00 units at 99.00. A new snapshot for the same subscription now describes its complete retained bid side as just 2.50 units at 98.50.
| Treatment of the new snapshot | Retained bid prices and sizes | Total retained quantity | Best retained bid |
|---|---|---|---|
| Replace the retained side | 98.50: 2.50 | 2.50 | 98.50 |
| Incorrectly merge into old state | 100.00: 3.00; 99.00: 4.00; 98.50: 2.50 | 9.50 | 100.00 |
The wrong merger leaves 7.00 units of ghost liquidity. It also preserves an obsolete best bid. Updating every row present in the snapshot is insufficient; resetting the covered state must remove old rows that are absent.
Absence in an ordinary incremental message means something different under the replacement contract described here. If the message changes only the bid at 100.00, the unchanged bid at 99.00 stays. Clearing the whole side for every incremental message would lose valid retained levels.
Scope matters in both directions. This fixture explicitly defines a complete retained-side snapshot. A top-depth snapshot describes its declared coverage; an omitted deeper price is not evidence that no such liquidity exists anywhere in the venue's book. Reset only the state that the snapshot authoritatively replaces.
An obsolete quote can also contribute to an apparently locked or crossed order book. That symptom helps direct an investigation, but it cannot by itself distinguish a reset defect from another data or market-state issue.
Give the adapter a small acceptance worksheet
Record the venue, product, symbol, channel and documented revision beside the mutation rule. Add the quantity unit: base units, contracts and quote value cannot be interchanged simply because they arrive in a field called size. Make the state key include the bid or ask side as well as the price.
Use the following checks on a local, invented fixture before relying on its derived depth. Expected results should be written down before the replay is run.
| Check | Observation to require |
|---|---|
| Existing level receives a smaller positive value | Replacement produces the smaller total; addition follows the declared signed-change rule |
| Zero arrives | The documented delete or no-op action occurs |
| Deleted price receives a positive replacement | The level is inserted again with that total |
| A new complete retained-state snapshot omits old rows | Those rows disappear from the covered state |
| An older event arrives after a newer accepted event | The channel's admission rule handles it before any quantity changes |
| The same numerical price has different decimal spellings | It identifies one level under the channel's price representation |
Use exact decimal handling appropriate to the protocol. A display formatter can round two distinct prices into one, while a raw text key can accidentally keep 100.0 and 100.00 as separate levels. Preserve any original representation needed for validation alongside the numerical identity used for state.
Where a channel supplies checksums, validate the resulting book using its prescribed representation. The order-book checksum guide covers that separate byte-level check. A checksum rule cannot be inferred from the replacement rule, and a correct reducer alone does not establish freshness or complete depth coverage.
Finally, avoid interpreting a size reduction as an execution report. A replacement from 5.00 to 2.00 establishes a 3.00 net reduction between those observations. It does not tell you how much was traded versus cancelled, or whether additions occurred between them. Subtracting public trade quantities again from an already updated total can count a reduction twice.
Keep one decisive acceptance record: the field's meaning, the starting state, accepted messages and expected final levels. For the replacement fixture here, the answer is 3.00 at 100.00 before the reset, then only 2.50 at 98.50 after it. If the replay produces 11.25 or retains the old best bid, resolve the mutation rule before consuming the book.