Level 1, Level 2 and Level 3 Crypto Market Data

Level 1 crypto market data usually shows the best bid and ask, Level 2 groups visible orders into quantities at each price, and Level 3 identifies individual visible orders. These labels describe different representations of a book, not guaranteed depth, freshness or completeness. Check the venue's schema: aggregation loses order identity and queue detail, while even an order-level feed can exclude hidden quantity and cover only a limited number of prices.

The useful question is which information must survive for the task you want to perform. A spread display, a visible execution-cost calculation and an investigation of one resting order need different fields. More detailed data helps only when it preserves the facts that question requires.

Read the schema before the label

This article uses the common crypto distinction below. A provider's actual field definitions take precedence over the label on its subscription page.

For a concrete implementation, Coinbase Exchange's REST product-book reference currently describes level 1 as best bid and ask, level 2 as the full aggregated book, and level 3 as the full non-aggregated book. The endpoint can also carry auction information. Its aggregated size already sums orders at that price; multiplying that size by its order count would overstate quantity. See the Coinbase Exchange product-book specification, reviewed on 28 October 2026.

An order count does not reverse aggregation. Knowing that two orders sum to eight units does not reveal whether their sizes are three and five, one and seven, or four and four. Nor does two orders mean two owners: an order identifier is not a participant identity.

Collapse eight orders into three views

Consider an original hypothetical continuous XYZ/USD market. Prices are USD per XYZ and quantities are XYZ. The table deliberately supplies priority within each price: smaller priority numbers arrived earlier. Assume price-time matching, no hidden quantity, no fees, no amendments, no self-trade prevention effects and no competing events during each calculation.

Price-time priority is an explicit example assumption, rather than a property established by the words Level 3. Coinbase Exchange documents that matching rule by engine receipt in its matching-engine description.

The order-level view has eight distinct objects. A1 and A2 share a price but remain separate instructions. In this constructed queue, A1 precedes A2. A real feed needs sufficient priority information and the venue's ordering rules before a reader can make that inference; an arbitrary list order or an order ID's spelling is insufficient.

To produce Level 2, group by side and price, sum quantities and sort bids downward and asks upward. Our projection also retains an order count, a field that must be checked rather than assumed on every L2 feed.

Eight orders have become six price levels. The bid side still totals 19 XYZ and the ask side 14 XYZ, but B1, B2, A1 and A2 can no longer be recovered individually from these aggregates.

To produce Level 1, retain only the best bid, 100.00 for 8 XYZ, and best ask, 100.10 for 6 XYZ. Their spread is 0.10 USD and midpoint is 100.05 USD. The other four prices disappear. A ticker may include a last trade or other fields, but those additional fields are separate from this two-sided quote projection.

Which calculations survive aggregation?

All three views retain enough information to calculate this spread. L1 is therefore sufficient for that narrow arithmetic question, provided both sides are valid observations of the intended market.

Now consider a hypothetical aggressive purchase of eight XYZ against the unchanged visible asks. Six XYZ cost 600.60 USD at 100.10, and the remaining two cost 200.40 USD at 100.20. Total cost is 801.00 USD; dividing by eight gives an average price of 100.125 USD before fees.

Pricing all eight at the best ask would give 800.80 USD, understating this fixture's visible cost by 0.20 USD. L1 reveals that six are displayed at the best ask, but lacks the next price required to finish the calculation. L2 supplies the necessary price and quantity. L3 also supplies them, yet individual order identities add nothing to this particular cost calculation.

L3 answers a different question: which visible instructions would this constructed FIFO purchase consume? It would consume A1's two, A2's four and two from A3, leaving three on A3. L2 can identify the consumed price levels without identifying those orders.

These are static-book calculations under declared assumptions, not execution forecasts. The market can change before an instruction reaches the engine. For passive orders, aggregation also prevents a simple depth total from establishing quantity ahead; the queue-estimation guide examines that separate modeling problem.

Unchanged totals can hide a different book

Return to the initial state before the hypothetical purchase. Instead, let A1 cancel its two XYZ, then let a new order A5 join with two XYZ at 100.10. No trade occurs. A2 remains resting throughout.

The initial and final Level 1 quote are identical. Initial and final Level 2 snapshots are also identical, including our optional count. Nevertheless, an older order disappeared, a new identity arrived and A2 now precedes A5.

Under the example's FIFO assumptions, visible quantity ahead of A2 at 100.10 falls from two XYZ to zero. The unchanged L2 endpoint totals therefore conceal a queue change that matters to that resting order.

An L2 stream delivering each intermediate change could show the size path from six to four to six. It still lacks the constituent identities. A collector saving only the endpoints loses even that path. Consequently, aggregation and sampling are separate sources of information loss: retaining more frequent L2 observations does not manufacture an order ID.

Likewise, two L3 snapshots can expose changed identities without recording every intervening event. A final book is a state; a history records how that state arose. Choose and retain the form the investigation needs.

Level 3 still has a visibility boundary

Individual orders do not imply access to every instruction in a matching system. Kraken Spot WebSocket v2's L3 reference describes resting visible orders and excludes in-flight orders, unmatched market orders, untriggered stop-loss and take-profit orders, and hidden iceberg quantity. It supplies order identifiers, remaining visible quantities and insertion or amendment timestamps. See Kraken's L3 channel specification.

That specification also makes subscription depth a number of price levels. A depth-limited order-level view can therefore contain less distant price information than a fuller aggregated view. Granularity and depth are different dimensions; neither automatically dominates the other for every question. The depth-truncation guide explains how a boundary affects what can be inferred beyond the supplied levels.

Do not treat an absent order as evidence that nobody intends to trade there. The feed describes its documented visible scope. It also does not reveal a participant's motive or prove that displayed quantity will remain available.

Updates and integrity need their own checks

A correct representation can become an incorrect local book through bad reconstruction. Coinbase Exchange's full-channel procedure joins buffered events to a sequenced REST snapshot and discards queued events through the snapshot's sequence. It also distinguishes an order received for processing from one resting on the book. Treating every received order as a new resting entry would inflate local depth. These are specific lifecycle rules in the Coinbase Exchange WebSocket channel documentation, not rules to transfer unchanged to another venue.

At the aggregate layer, Coinbase's L2 update size replaces the size at that price; it is not a signed change. The same channel reference documents that behavior. A mistaken addition can make an L2 collector look deeper than the market. The absolute-versus-delta quantity guide separates those update contracts.

Verify continuity, scope and observation time before interpreting derived values. A successful order-book checksum can support agreement within its defined coverage, while leaving questions of freshness and deeper levels unresolved. Detailed data with an unresolved collection gap should not silently retain the same confidence label as a verified state.

Match the question to the fields

Use this worksheet before collecting a feed or interpreting an existing archive. The required fields determine the suitable representation.

Record venue, product, channel version, aggregation unit, depth limit, update semantics, timestamps and recovery rule alongside the data. Then write one sentence stating what the observations establish. If the required fact was discarded during aggregation or collection, preserve that uncertainty in the result instead of filling it with an assumption.