Level 3 Market Data in Crypto: Why Most Exchanges Still Withhold the Order Book’s Full Depth

Ariel Silahian

Ariel Silahian is a senior technology executive in institutional electronic trading, with 30+ years across the buy and sell side (New York, Miami, London, Hong Kong). He is the author of "C++ High Performance for Financial Systems" (Packt) and the creator of VisualHFT, the open-source microstructure analytics stack. He writes on exchange architecture, market microstructure, and execution quality, and advises a select number of trading firms on infrastructure decisions that move P&L. Talk architecture: https://hftadvisory.com

Table of Contents

• The Plumbing Already Exists
• What L2 Hides: The Queue-Position Problem
• What Order-Level Data Has Already Caught in TradFi
• The Honest Counterargument: Why Aggregation Persists
• Where This Leaves Crypto Desks
• A Venue Data-Capability Audit
• Conclusion

If you have searched for “level 3 market data crypto exchange” and landed on vendor marketing pages instead of an answer, that gap in the search results is itself informative. Level 1 gives you best bid and offer. Level 2 gives you the depth of the book, aggregated by price. Level 3, also called market by order data, gives you every individual order: its ID, its price, its size, its place in the queue, and its full lifecycle from add to cancel or fill. In equities and futures, L3 has been a commercial product for two decades. In crypto, it is nearly invisible.

I spent a week this month pulling the public API documentation for Binance, OKX, Kraken, and Coinbase, plus CME’s own market data FAQ, to answer a narrower question than “does the data exist”: does anyone build the pipe. What I found separates cleanly into three different problems that get treated as one: whether a matching engine is capable of producing order-level data, what it costs to package it for distribution, and whether demand for it has ever been tested in crypto at all. This article works through that separation, what queue-level data has already caught in traditional markets, and an honest look at the counterarguments for why most venues stop at L2 anyway.

One scoping note up front: this analysis applies to venues running a central limit order book (CLOB) with price-time priority, the design nearly all major centralized crypto exchanges use for spot and futures trading. It does not apply to AMM-based decentralized exchanges or batch-auction designs, where there is no order queue to log in the first place and the L3 concept simply does not exist.

The Plumbing Already Exists

Any matching engine enforcing price-time priority has to track individual orders internally, with IDs and timestamps, in order to decide who gets filled first when a price level has multiple resting orders. Tracking individual orders is a structural requirement of the matching algorithm itself, a byproduct of enforcing price-time priority, not a data product decision. Order-level data comes free with how a CLOB works, whether or not an exchange ever packages it to sell.

What differs is what each venue exposes publicly, and this is where the July 2026 comparison gets specific. Binance’s depth endpoint returns bids and asks strictly as price-quantity pairs, up to 5,000 levels, with no order identifiers at any depth. OKX’s order book adds one more field per level: the number of orders resting at that price. That is a count, not an identity. Neither venue lets an outside observer reconstruct a single order’s position in the queue.

Kraken and Coinbase sit on the other side of that line. Kraken’s level3 WebSocket channel exposes order ID, limit price, order quantity, and timestamp per order, but only through an authenticated channel gated by a token, not on the public book. Coinbase goes further: its exchange WebSocket documentation states plainly that “the full channel provides real-time updates on orders and trades” which “can be applied to a level3 order book snapshot to maintain an accurate and up-to-date copy of the exchange order book,” and it maintains a dedicated Level3 channel with its own schema. My read of this split: “most crypto exchanges don’t provide L3” is accurate, but “none do” is not. Two of the four venues I checked already expose order-level data, just with different access postures, one gated, one closer to open.

CME is the clearest illustration that this is old infrastructure pointed at a new symbol. CME’s own FAQ states that “cryptocurrency futures real-time market data is available on MDP Channel 326,” the same MDP 3.0 platform CME uses across its other futures products. My reading of that assignment, and it is a reading rather than a documented engineering statement from CME, is that nobody stood up new plumbing for Bitcoin futures. An existing, general-purpose market-data pipe absorbed a new symbol the way it absorbs any new contract.

What L2 Hides: The Queue-Position Problem

The reason this distinction matters economically, not just architecturally, comes down to queue position. At a busy price level, an L2 feed tells you the total resting size. It does not tell you whether your order is first in line or fiftieth. Two desks can see an identical L2 snapshot, one bidding at the front of the queue and one at the back, with no visible difference between them until fills start arriving, and by then the advantage or disadvantage has already been priced in.

Moallemi and Yuan’s Columbia Business School working paper on queue position valuation puts a number on that blindness: they find that “for some large tick-size stocks, queue value can be of the same order of magnitude as the bid-ask spread.” Translated into P&L terms, that means the value of where you sit in the queue, on those names, can rival the value of the entire spread you are trying to capture. An L2-only view structurally cannot see that value because it aggregates away the exact information the calculation needs: individual order identity and position, tracked through the FIFO queue over time.

That scoping matters as much as the number itself. The paper’s finding is anchored to large tick-size US equities with their own tick regime and maker-taker fee structure. Crypto trades on different tick sizes, different fee schedules, and different queue mechanics venue to venue. Carrying that finding into crypto is, in my estimate, a hypothesis worth testing, not a result that already applies. Nobody has published the crypto-native version of this measurement, which is itself the gap this article keeps circling back to.

What Order-Level Data Has Already Caught in TradFi

Order-level data is a pricing question and a surveillance question, and on the surveillance side, TradFi has case law.

The CFTC’s case against Navinder Singh Sarao is the clearest example. The CFTC’s own release describes “a dynamic layering program that routinely placed 4 to 6 exceptionally large sell orders into the E-mini S&P order book, each one price point from the next,” and the agency’s language is explicit that Sarao “admits to contributing to extreme order book imbalance and causing and creating artificial prices on multiple days, including May 6, 2010.” The court ordered him “to pay more than $38 million in monetary sanctions for price manipulation and spoofing.” What made that case provable was order-level data: the intent behind spoofing lives in the lifecycle of individual orders, placed and pulled in a pattern, which an aggregated L2 feed structurally cannot show. L2 sees size appear and disappear at a price. Only order-level data sees that it was the same handful of orders doing it, repeatedly, in a recognizable rhythm.

A second data point, with a caveat I want to state plainly: the US Treasury’s Office of Financial Research published a 2014 working paper testing indicators built from raw order-flow data against real CME E-mini and NYMEX WTI events, including the May 2010 event referenced above. Their order-level indicator signaled elevated risk “more than a minute in advance of the worst phase” of the events studied, while VPIN, which the paper notes requires only Level 2 data, responded far less. One caveat worth stating clearly: the OFR paper defines its own six-level data taxonomy, where its “Level 3” means aggregated depth snapshots and its “Level 4” is the raw anonymized order flow that maps to what the industry calls L3 or MBO today. I am translating their numbering into industry terms here; the paper’s own labels do not match industry convention, and conflating them without saying so would be a mistake.

The Honest Counterargument: Why Aggregation Persists

None of this means aggregation is a mistake. There is a real counterargument for stopping at L2, and it deserves a fair hearing rather than a strawman.

The strongest one, in my view, comes from Zhang, Lim, and Zohren’s 2021 paper on deep learning applied to market-by-order data. Their finding, in their own words: “while MBO-driven and LOB-driven models individually provide similar performance, ensembles of the two can lead to improvements in forecasting accuracy, indicating that MBO data is additive to LOB-based features.” That is a meaningfully different claim than “L3 replaces L2.” Order-level data adds incremental predictive value on top of an aggregated book. It is not a strict substitute, and a desk that has never touched order-level data is not automatically flying blind.

There is also a real cost to disseminating it, and I want to reason through that rather than assert it. Order-level dissemination needs deterministic sequencing and gap-recovery logic, because a client that misses one order-add message in the stream has a permanently wrong local book unless it can request a resync. Fan-out bandwidth scales with order-event rate, which runs an order of magnitude above trade rate on an active book, since most orders are added, modified, or cancelled without ever trading. And, in my estimate the more binding constraint in practice, most trading teams do not have the infrastructure to consume and reconstruct an order-level feed even if it were offered, so building the pipe risks a product nobody outside the largest desks can use. Add information-leakage concerns, since order-level data can expose a market maker’s own quoting pattern to competitors watching the tape, and you have a defensible case for stopping at L2.

What that case does not explain is the asymmetry with TradFi’s own packaging history. CME formally supports Market By Order Full Depth, Market By Order Limited Depth, and Market By Price as three distinct product lines on the same MDP 3.0 platform, meaning CME treats order-level and price-level data as separate purpose-built products, not a single feed with a tier gate. NYSE’s own account of OpenBook is worth reading closely here too: introduced in 2002 at “a fixed access fee of $5,000 per month plus a variable fee based on the number of subscribers,” with the access fee unchanged “since inception of the product” and the professional subscriber fee changed only once in two decades. These are dated, TradFi-specific, scale-illustration figures from a market roughly two orders of magnitude larger than any single crypto venue, not a current benchmark and not a crypto forecast. But they show that the industry solved packaging and pricing depth data twenty years ago, at a fee structure stable enough to survive two decades unchanged. The cost argument in crypto explains why it is harder to do casually. It does not explain why almost nobody has tried.

Where This Leaves Crypto Desks

Here is the honest state of the evidence: I ran two research passes looking for a study that measures L3-derived queue value against an L2 proxy specifically in crypto markets, and found none. My read is that this looks more like a chicken-and-egg problem than proof the value does not exist in crypto: the absence of order-level data in most venues’ public catalogs is exactly what would prevent the study that could demonstrate its value from ever being written. There is no archive to test the hypothesis on. I should also be honest that data availability is not the only plausible explanation. Academic incentives favor problems with existing datasets, and licensing friction with the two venues that do expose order-level data adds its own barrier, independent of whether the underlying signal is valuable.

There is one forward-looking signal worth flagging from the regulatory side, even though it comes from TradFi rather than crypto. ESMA’s own site confirms that the “RTS on RCB entered into force on 23 November 2025,” with a transition period for existing market data providers running “until 22 August 2026.” Reasonable Commercial Basis rules are, at their core, regulators deciding how market data can be priced and justified. That fight is already underway in traditional markets. Crypto has not had its version of that conversation yet, largely because so little order-level data is on offer to argue about.

A Venue Data-Capability Audit

For a desk that wants to know where it actually stands rather than assume, here is a checklist worth running against every venue you trade, position by position rather than platform-wide:

1. What does the public book actually return? Confirm directly against the current API docs, not institutional memory, whether you are getting price-quantity pairs, an order count per level, or genuine order-level fields. Docs change; re-check per venue per quarter.
2. Is order-level data available at any tier, gated or not? Kraken and Coinbase both expose it through defined channels. If your venue does, are you actually consuming that channel, or defaulting to the public L2 feed out of habit?
3. Can you measure your own queue position today? Not “could you theoretically.” Do your systems currently reconstruct where your resting orders sit relative to others at the same price, or is that number simply unknown to you right now?
4. What does your execution analytics stack assume about depth composition? If your fill-probability or markout models treat a price level’s size as homogeneous, they are implicitly assuming queue position does not matter. That assumption may be fine. It should be a decision, not a default nobody made on purpose.
5. What would order-level data change about your fill models if you had it? Before requesting or building access to order-level data, write down the specific model input it would change. If the honest answer is “nothing we currently measure,” the packaging gap in the industry is not costing you anything yet, and that is a legitimate answer too.

Conclusion

I have not closed the loop on the question this whole piece turns on: whether queue-position value in crypto order books is large enough, on the venues and instruments any given desk actually trades, to justify building or requesting order-level data access. The Moallemi and Yuan finding is a TradFi number on a different tick regime. The Zhang, Lim, and Zohren result says order-level data is additive, not a replacement, which caps how large the gain can plausibly be. Nobody has run the crypto-native version of either study, and the reason nobody has run it may be the same reason the study would matter: there is no archive to run it on.

A concrete way to close that gap without waiting for someone else to publish it: for any venue that already exposes an order-level channel, log both the L2 snapshot and the order-level stream in parallel for a stress window, reconstruct queue position from the order-level feed, then check whether a fill-probability model built on the L2 view alone systematically misprices orders sitting deep in a queue relative to ones sitting at the front. If it does not, the packaging gap is mostly an academic curiosity for that desk. If it does, that mispricing is a number worth having before deciding whether the industry’s stop-at-L2 default deserves to keep being the default.

This article was originally shared as a LinkedIn post. View the original post