Skip to content
Financial Context Wiki

Crypto order book

An order book is a venue-specific view of resting bids and asks; using it safely requires coherent market-data reconstruction, exact matching rules, depth-aware execution math, and fill and settlement reconciliation.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

An order book is a venue- and product-specific state or market-data view of resting buy orders, sell orders, or aggregated price levels. The highest displayed bid and lowest displayed ask form the best bid and best ask; their difference is the spread. This visible state is executable interest at an instant, not a forecast, a commitment to remain, or a complete map of hidden, iceberg, RFQ, OTC and other-venue liquidity.

Market-data level matters. Level 1 shows the top of book, Level 2 aggregates quantity by price, and Level 3 can expose individual orders and queue detail where the venue provides it. A Level 2 size can represent several orders and cannot reveal an account’s queue position. A reliable local book must combine a coherent snapshot with continuous, correctly ordered incremental events and stop when sequence or checksum continuity fails.

Matching rules are venue-specific. Some continuous books use price-time priority; other products can use pro-rata allocation, auctions, hidden-order rules, self-trade prevention or chain-specific block ordering. Market orders trade against available prices rather than a guaranteed last price. Limit orders can take liquidity immediately and leave a resting remainder. Cancellation is a racing request until acknowledged, so fills, fees, remaining quantity, balances and settlement must be reconciled from authoritative events.

Average fill
$100.09
Average slippage
0.09%
Unfilled quantity
0

Outputs are educational approximations. They exclude venue rules, taxes, latency, oracle behavior, and other protocol-specific parameters unless shown.

How it works

  1. Pin the venue and legal entity, product and session, base/quote direction, spot or derivative contract, tick size, lot size, minimum notional, fee tier, book level, custody or settlement model, and clock.
  2. Build a coherent local view: subscribe and buffer events, obtain the documented snapshot, apply only compatible ordered updates, distinguish absolute size from delta, validate sequence or checksum, and resnapshot on any gap.
  3. Read the exact matching rules for priority, auctions, self-trade prevention, amendments, cancellation, hidden or iceberg orders, and onchain or within-block ordering. Do not infer queue position from an aggregated level.
  4. Specify side, base quantity or quote budget, limit or market behavior, stop trigger, time in force such as GTC, IOC or FOK, post-only or reduce-only flags, protection bands and worst acceptable price.
  5. Sweep the executable side level by level to estimate fill quantity, notional, VWAP, spread and slippage against a named benchmark. Add maker or taker fees per fill and stress latency, disappearing or hidden depth and partial execution.
  6. Submit with an idempotent client identifier and consume private acknowledgements, rejects and fills. Treat amend, cancel and replace as racing until the engine or chain confirms them; reconcile actual remaining quantity, inventory, cash and fees.
  7. Compare the public book, private order state, fills and settlement ledger. For a CEX, separate matching from custody and withdrawal; for onchain or hybrid books, separate submission, ordering, execution, settlement, reorg and finality, then pause and resync on incoherent state.

Maker and taker describe each fill’s liquidity role, not a permanent account or order label. A marketable limit order can take several levels and later rest as maker. Stop orders are generally absent from the visible book until a venue-defined trigger creates another order, and the trigger price is not an execution guarantee. Time-in-force, post-only, market-protection and modification behavior must be verified for the exact venue and product.

Worked examples

  • Spread and quote identity. The best bid is 99.90 and best ask is 100.10, so midpoint = (99.90 + 100.10) / 2 = 100.00, absolute spread is 0.20, and midpoint-relative spread is 0.20 / 100.00 = 0.20% = 20 bps. A last trade at 99.70 does not by itself change those current executable quotes.
  • Depth sweep and fees. The asks are 2 @ 100.00, 3 @ 100.20, and 5 @ 100.50. A market buy of 8 costs 200.00 + 300.60 + 301.50 = 802.10, so VWAP = 802.10 / 8 = 100.2625. Slippage versus best ask is 0.2625% = 26.25 bps. With a 20 bps taker fee, fee is 1.6042, total cash outflow is 803.7042, and all-in unit cost is 100.463025.
  • Marketable limit remainder. A buy limit for 8 @ 100.20 against the same asks fills 2 @ 100.00 and 3 @ 100.20, costing 500.60 at VWAP 100.12, with 3 unfilled. Under IOC the remainder cancels; under GTC it may rest at 100.20. A 20 bps taker fee on the filled notional is 1.0012, so current cash outflow is 501.6012 before any later maker fill.
  • Sequence and cancel races. A local snapshot at sequence = 100 shows 4 @ 100.10. Event 101 changes it to 1, but the next received event is 103; missing 102 makes the book unknown, so 103 cannot safely repair it and a fresh snapshot is required. Separately, a sell order of 10 receives fills of 2 and 1 before cancel acknowledgement: final filled quantity is 3 and canceled remainder is 7, not zero filled.

Risks

  • Wrong venue, legal entity, product, contract, session, or environment.
  • Reversed base/quote direction or inconsistent quantity and notional units.
  • Tick size, lot size, minimum notional, decimal, or price-band rule is wrong.
  • Snapshot is stale, incomplete, from the wrong session, or incompatible with buffered events.
  • Sequence gap, duplicate, out-of-order event, or checksum failure is ignored.
  • Absolute replacement size is applied as a delta, or zero-size deletion is mishandled.
  • Level 2 aggregation is mistaken for Level 3 order identity or queue position.
  • Hidden, iceberg, RFQ, dark, OTC, internalized, or other-venue liquidity is omitted.
  • Price-time, pro-rata, auction, self-trade prevention, amend, or replenishment rules are assumed incorrectly.
  • Market, limit, stop, protection-band, post-only, reduce-only, GTC, IOC, or FOK semantics are misunderstood.
  • Market order is partially filled, rejected, or executes far from last, midpoint, or best price.
  • Cancel, amend, or replace races with fills and causes unintended residual inventory or overfill.
  • Duplicate submission, lost acknowledgement, client-ID collision, or order-ID mismatch breaks idempotency.
  • Maker/taker role, tier, rebate, per-fill fee, funding, or settlement charge is misaccounted.
  • Displayed spread or depth disappears during network, processing, queue, or block latency.
  • Buy or sell walls are canceled, spoofed, layered, replenished, or misread across fragmented venues.
  • Slippage benchmark, side, spread, VWAP, fees, FX conversion, or all-in cost is calculated incorrectly.
  • Halt, auction, limit-only mode, maintenance, outage, rate limit, or market-status transition changes behavior.
  • CEX custody, ledger, asset segregation, withdrawal, insolvency, or API integrity fails independently of matching.
  • Onchain or hybrid flow adds allowance, nonce, gas, sequencer, MEV, contract, reorg, finality and indexer risks, and final reconciliation fails.

Common misconceptions

  • “A large buy wall guarantees a price rise.” Displayed orders can be legitimate, canceled, moved, hidden behind other flow, or intended to mislead.
  • “A market order fills at the last, midpoint, or best price.” It consumes available opposing liquidity and can partially fill or traverse many levels.
  • “A limit order is always maker and has no cost.” A marketable portion can be taker, a remainder can wait or never fill, and fees, opportunity cost and information leakage remain.
  • “High historical volume guarantees deep executable liquidity at any size.” Volume records past turnover; current depth, latency, hidden flow and price impact determine execution.
  • “An onchain order book is fully visible, instantly final and trust-free.” Ordering, offchain signed orders, sequencers, contracts, indexers, settlement and finality can remain separate dependencies.

Sources

Navigation

Search the wiki...