A crypto limit order's queue position can be estimated from Level 2 data, but an aggregated price-level total usually cannot identify the exact quantity ahead. A price-and-size trade print does not resolve where cancellations occurred within that queue. State the matching rule, arrival assumptions and cancellation model, test alternative histories, and use your own order and execution records to verify actual fills.
This AI-assisted educational article uses exchange documentation reviewed on October 23, 2026. The two queue histories below are original hypothetical examples, not observed orders, execution forecasts or evidence of a KLINEO queue-estimation feature.
Quantity at your price is not quantity ahead
Suppose the bid at your limit price displays 18 ABC. That total might contain older orders ahead of you, your own working quantity and later orders behind you. It does not reveal their individual ages or sequence.
The matching rule comes first. Coinbase Exchange documents price-time priority as orders reach its matching engine. Under that rule, eligible orders at a better price take precedence, then earlier orders at the same price. Your computer's submission timestamp does not establish when the engine received your order. See Coinbase Exchange's matching-engine rules.
“Position” also needs units. Being third among orders is different from having ten ABC ahead: the two preceding orders could be tiny or large. For a simple FIFO fill model, quantity ahead is usually the useful state. Other allocation rules require another model.
Do not confuse that state with the quantity available across several prices. The order-book depth worksheet estimates the effect of consuming visible liquidity. Queue estimation asks whether incoming flow will reach a particular passive order.
What each feed can establish
Coinbase Exchange's Level 2 snapshot contains price-and-size pairs; subsequent updates supply the new size at a price, rather than a signed quantity change. That representation is enough to maintain aggregate depth when processed correctly. It does not partition a level into individually ordered instructions. See the Level 2 channel specification.
| Observation | Useful evidence | Missing information |
|---|---|---|
| L2 size at your limit | Visible total at the observed update | Individual orders and their priority |
| Price-and-size trade | Executed volume at that price | Which remaining orders canceled |
| Your accepted order record | Identity, price, size and reported state | Every competing order ahead |
| Your execution record | What actually filled for your account | A forecast of the next fill |
| Complete order-level feed | Individual order events, within feed scope | Anything omitted by that feed or lost in collection |
Some trade feeds include maker identifiers; inspect the actual schema before calling a print anonymous. Coinbase's full channel supports reconstruction from an order-level snapshot and sequenced events, and its documentation distinguishes an order received for processing from one resting on the book. See Coinbase's full-channel reconstruction procedure.
More detailed data can reduce uncertainty. It does not excuse an incorrect snapshot join, a missing event or an unsupported assumption about hidden liquidity.
Same public totals, different fills
Consider one fictional ABC/USDT bid at 100 USDT. Assume ordinary FIFO matching, no hidden quantity, no self-trade prevention, no amendments and no other events. We know the initial ordering by construction; a live L2 collector normally would not.
Ten ABC are already resting. Your two-ABC buy joins behind them. Another six ABC then join behind you. The total at this price is 18 ABC, arranged as ten ahead, two yours and six behind.
Next, four ABC cancel without trading. Compare two possible histories:
| State | History A: four cancel ahead | History B: four cancel behind |
|---|---|---|
| Quantity ahead after cancellation | 6 ABC | 10 ABC |
| Your working quantity | 2 ABC | 2 ABC |
| Quantity behind | 6 ABC | 2 ABC |
| Public level total | 14 ABC | 14 ABC |
Now an incoming seller executes exactly seven ABC at this price, with no intervening events.
| Result after that trade | History A | History B |
|---|---|---|
| Earlier quantity consumed | 6 ABC | 7 ABC |
| Your fill | 1 ABC | 0 ABC |
| Quantity still ahead | 0 ABC | 3 ABC |
| Your remaining quantity | 1 ABC | 2 ABC |
| Quantity behind | 6 ABC | 2 ABC |
| Public level total | 7 ABC | 7 ABC |
In A, the seller consumes six ahead and one of yours. In B, seven trade against the ten ahead. Both histories produce the same aggregate path, 18 → 14 → 7 ABC, and the same seven-ABC trade print. Assigning every unexplained decrease to the front would predict A; assigning it to the back would predict B.
Your private execution report would distinguish the realized outcome once it arrives. The ambiguity concerns what the public observations alone establish, particularly when simulating a proposed order in historical data.
The example does not prove a general numerical bound under every market rule. Hidden replenishment, priority-changing modifications and bundled events can invalidate its assumptions. Its teaching point is narrower: even this clean aggregate path does not identify one passive fill.
An estimate should carry its assumptions
At submission, bracket when the order could have joined using exchange acknowledgments and appropriately synchronized market observations. Do not treat a snapshot taken before sending as the exact queue at acceptance. Competing orders may arrive while the request travels.
For a simple FIFO model, maintain separate quantities for ahead, your unfilled size and behind. Opposing executions consume ahead before your order. Later additions at the same price normally enter behind under the stated rule. An unexplained visible reduction requires an allocation assumption; it is not automatically a cancellation ahead.
Test at least two cancellation treatments while keeping the observed market path fixed. One can allocate eligible reductions ahead first, another behind first. A proportional allocation is another model, not evidence that a canceled unit had a particular location. Report sensitivity rather than hiding the choice inside a single fill percentage.
Avoid subtracting a trade twice: a depth update can already include its effect. Reconcile the book change with the trade feed under the venue's timing and message conventions before classifying the residual. When additions and removals are batched, a net change may conceal both.
Record when the model becomes unusable
| Check | Record before interpreting the estimate |
|---|---|
| Market identity | Venue, product, symbol and matching rule |
| Feed contract | Aggregation, update semantics and sequence handling |
| Acceptance interval | Evidence for when the order became resting |
| Initial state | Estimated ahead quantity and uncertainty |
| Reductions | Trade reconciliation and cancellation-allocation policy |
| Order changes | Whether the operation preserves or resets priority |
| Integrity break | Gap, stale snapshot or conflicting private state |
| Outcome | Distinct fills, remaining size and terminal status |
A gap should suspend confidence in the reconstructed queue until the documented recovery establishes a usable state. The WebSocket recovery guide covers that recovery boundary. Reconnecting alone does not reconstruct the missing order history.
Changing your own order can invalidate its modeled place. Use the queue-preserving amendment guide to check the exact venue operation; do not assume every reduction keeps priority or every unchanged identifier proves it.
Decide how long the intention remains valid
A small estimated queue is not a reason to leave an obsolete bid active. Define a review deadline and price-validity condition before relying on the estimate. Actual partial fills create real inventory; track those separately from the modeled remainder using the partial-fill ledger.
Waiting can have a financing cost if a separate margin arrangement has already created debt. The spot-margin borrow-interest guide explains why that liability needs its own accrual record; a passive order's lack of fills does not establish that no borrowing cost exists.
If the intention still holds but waiting ends, reassess the permitted execution price and remaining quantity. The market-order slippage-cap guide explains bounded aggressive execution and possible unfilled remainders. Canceling a passive order and crossing the spread is a new exposure decision with its own confirmation requirements.
Use queue estimates to describe uncertainty, compare execution policies and diagnose missed fills. Use authoritative private records to establish what the account actually acquired. A displayed total, a touched limit price and an estimated place in line answer different questions.