Comparing Order Books Across Venues: What a Snapshot Leaves Out

A snapshot is a point of view

The question “which venue has deeper liquidity” sounds like a fact about a market. In practice it is a fact about four endpoints. Each of the major venues publishes its book under its own rules about how many levels to return, how often the answer refreshes, whether orders at the same price are merged, and which orders are visible at all.

None of those rules is a defect. They are the terms of the data feed, and they are all documented. The mistake is comparing the numbers without comparing the terms.

Level caps are not comparable units

Start with the count.

A thousand levels on one venue and a thousand on another are not the same quantity. A level is a price point, and price points are spaced by the instrument’s tick size and by where resting orders happen to sit. On a book with a one-cent tick and dense quoting, 400 levels may cover a couple of basis points around the mid; on a thinner book the same 400 levels may reach far further. Comparing counts therefore compares tick structure, not liquidity.

The only stable comparison is notional within a fixed distance from the mid. Take the mid, define a band in basis points or in quote currency, and sum the resting size inside the band on each venue. That number is comparable because the unit is money rather than price points — provided the level cap is wide enough that the band does not run past the last returned level. This is the same reasoning behind spread, depth and slippage, applied across venues instead of within one.

Refresh, cache and the age of a number

The second difference is time, and it has two parts.

The snapshot may be served from a cache. OKX is unusually explicit: the books endpoint does not return data immediately but returns the latest data once the server-side cache has been updated, and the data is updated once every 50 milliseconds. That is a bounded staleness — the answer is up to roughly one refresh interval old, not arbitrarily old. Binance describes its depth response as coming from memory and carries a lastUpdateId so that a client can align it with a delta stream. Coinbase’s unauthenticated level2_batch channel batches updates every 50 milliseconds, for the same reasons of bandwidth rather than accuracy.

The snapshot is not a state, it is an instant. A REST snapshot followed by a stream of changes is the standard pattern, and the alignment rule is where most implementations fail: the snapshot must be discarded if a change arrives that it does not already contain. The mechanics of that reconciliation for one venue are set out in building a local order book from Binance depth streams; the same logic applies anywhere a snapshot and a delta feed are joined.

For a cross-venue comparison the practical rule follows. Sample on a common clock — a timestamp bucket of one second, say — and accept that each venue’s number inside that bucket is a slightly different instant. Publishing a comparison to more precision than the refresh interval is inventing it.

Aggregation: what a level contains

The third difference is what sits behind a price.

Coinbase Exchange documents the distinction directly. Its level2 channel sends bids and asks as [price, size] tuples describing the entire order book, aggregated by price; its level3 channel conveys per-order data, which is what the full channel uses to maintain a level-3 book. So on Coinbase, the aggregated view and the order-level view are separate products, and only one of them can tell you whether the top of book is a single large order or forty small ones.

Most venues return per-price levels by default. Binance’s depth response is an array of [price, quantity] pairs per side — size at a price, not a list of orders behind it. Bybit returns the same shape and describes it as a snapshot format. That aggregation is normally what a fill estimate wants: matching engines match against price levels, so the sum at a price is the quantity available at that price.

It stops being what you want when the question is about order fragmentation. A price level made of many small orders behaves differently under a cancelling wave than a level made of one large order, even though the depth chart is identical. Coinbase’s level 3 is the documented way to see the difference; elsewhere it is inferred, if it can be seen at all.

Exclusions: liquidity you cannot see

The fourth difference is the one most likely to change a conclusion.

Bybit’s orderbook documentation carries a note that reads almost like an afterthought: Retail Price Improvement orders will not be included in the response message and will not be visible over API. Those orders are real resting liquidity that can trade; they simply do not appear in the feed the comparison is built from. Bybit also publishes a separate RPI orderbook endpoint, which is the only way to see that side of the book.

Two venues can therefore show exactly equal depth at equal distance from the mid while one of them has materially more executable liquidity behind the number. A comparison that does not state whether RPI was included is comparing visibility, not liquidity.

Iceberg orders create the same gap everywhere. An iceberg displays a portion of its size and replenishes as it fills, so the visible depth understates the resting interest at that price. No venue’s public depth feed reveals the reserve; the effect is documented behaviour of the order type, described for one venue in iceberg, post-only and TWAP orders. The honest response is to say that depth is a measure of visible depth.

The cost of measuring

The last difference is arithmetic that affects how the comparison can be run at all.

Binance prices a depth request by the number of levels asked for: 5 weight for 1 to 100 levels, 25 for 101 to 500, 50 for 501 to 1000 and 250 for 1001 to 5000, against a per-IP budget it reports in response headers. OKX documents 40 book requests per 2 seconds per IP for its books endpoint. Bybit’s limits apply per endpoint and per category. A harness that polls all four venues every second at maximum depth is not measuring the same thing as one that polls them at modest depth — the first is spending most of its budget on a handful of requests, and will end up sampling unevenly.

Two consequences follow. First, choose the level count to cover the price band you intend to measure, not the maximum the endpoint allows; on Binance that decision moves the cost of a sample by a factor of fifty. Second, if the sample size per venue differs, say so — an average over a thousand snapshots from the cheap venue and twenty from the expensive one is not a like-for-like statistic. The budget arithmetic is the same subject as exchange API rate limits and order weights.

A method that survives the differences

The following sequence produces a comparison whose differences can be attributed to markets rather than endpoints.

1. Fix the measurement in money. Define the band in basis points from the mid, and sum resting notional inside it. Report the mid alongside, since a band is not a fixed price distance.
2. Check the cap against the band. If the last returned level is inside the band, the venue’s depth is truncated and the number is a floor, not a measurement. OKX’s 400-level cap is generous for a ±5 basis-point band on a liquid pair and thin for a wider one.
3. Record the aggregation. State whether levels are per price or per order, and say which Coinbase channel was used if Coinbase is in the set.
4. Record the exclusions. RPI on Bybit, reserve quantity on icebergs, and any venue-specific hidden order type. If a venue’s feed omits a category, say so next to its number.
5. Sample on a common clock and disclose the interval. One second buckets, with the staleness bound of each feed noted — 50 milliseconds for a cached books endpoint, one batch interval for a batched channel.
6. Budget per venue, not per harness. Choose level counts that cover the band, then compute the request cost per sample per venue before deciding the sampling frequency.
7. Report the median and the interquartile range, not the mean. Depth is heavy-tailed; a single large quote can move a mean for an hour. The distribution question is also what order book imbalance versus last price asks within a single venue, and the depth-versus-quote question is what market maker inventory, spreads and depth explains from the maker’s side.

Even done carefully, the four venues will not agree to the basis point. That is not a failure of the method; it is the method’s output. A comparison is trustworthy when its disagreements can be explained by the documented rules — a level cap truncating a tail, a cache lagging a fast move, RPI orders hiding size — and untrustworthy when the write-up attributes all of the gap to the market.

Risk note. Level caps, caching behaviour, aggregation rules, exclusions and rate-limit costs in this article were read from Binance’s Spot API documentation, OKX’s API documentation, Bybit’s V5 API documentation and Coinbase Exchange’s WebSocket channel documentation on 2026-10-30. Endpoint parameters change; the four sources of difference between a book and a snapshot do not. Nothing here is investment advice.