Back to Library

Order Book

Matches buy and sell orders for an asset pair based on price-time priority.

Order books function by maintaining two parallel lists: a bid side for buy orders sorted by descending price and an ask side for sell orders sorted by ascending price. When orders are submitted, they are either matched immediately against existing compatible orders or added to the appropriate list for future matching. The mechanism enforces price-time priority, meaning orders at better prices are matched first, and among orders at the same price, older orders take precedence. Trade execution occurs when bid and ask prices overlap, with the matching engine pairing compatible orders and settling the resulting trades. The mechanism supports multiple order types, including market orders (executed immediately at best available price), limit orders (executed only at specified price or better), and sometimes more complex variants like stop-loss or fill-or-kill orders.

The concept of order books dates back to traditional financial markets but was first implemented onchain by EtherDelta in 2016. However, EtherDelta’s fully on-chain model suffered from the inherent limitations of blockchains—every order placement, modification, and cancellation required an on-chain transaction, making trading slow, expensive, and inefficient. In 2017, 0x Protocol introduced a hybrid model to address these issues. Instead of processing orders entirely on-chain, 0x allowed users to sign orders off-chain and settle them on-chain, significantly reducing gas costs and improving efficiency. However, because 0x relied on third-party relayers rather than a shared order book, liquidity was fragmented. In 2019, dYdX advanced the hybrid approach by introducing a centralized off-chain order book with on-chain settlement, improving speed and liquidity while maintaining trustless execution. This model provided a much more seamless trading experience compared to previous solutions. Unlike Ethereum, which was not designed for high-frequency trading, Solana was built specifically to support applications requiring concurrency, like order books. This architecture has enabled the development of fully on-chain central limit order books (CLOBs), with Serum (2020) being one of the most notable examples. Solana’s ability to handle parallel processing allows it to run high-performance order book exchanges that would be impractical on Ethereum.

Advantages

  • Price Discovery: Enables efficient price discovery through visible order depth and continuous matching of buyer and seller preferences.
  • Price Precision: Allows traders to specify exact prices and quantities rather than accepting automated pricing.
  • Capital Efficiency: Orders can be placed without requiring pre-funded liquidity pools, reducing capital lockup. Only the sold asset to be locked, unlike AMMs which need both assets.

Limitations & Risks

  • Liquidity Fragmentation: Order books typically require significant volume to maintain tight spreads, making it challenging to support many trading pairs.
  • Infrastructure Requirements: Order books require high throughput and low latency to handle order updates and matching efficiently.
  • Front-running Vulnerability: Order submission latency can expose traders to front-running by miners or other participants.

Design Considerations

  • Price-Time Priority: Design the matching system to prioritize trades based on price and submission time. Implement deterministic ordering to prevent manipulations like timestamp gaming or block reorg exploitation. Use off-chain sequencing or Fair Sequencing Services (FSS) to mitigate miner extractable value (MEV) risks.
  • Matching Logic: Define order behavior, supporting types like immediate-or-cancel (IOC) for rapid execution, good-till-canceled (GTC) for persistent orders, and fill-or-kill (FoK) or partial fills for flexibility and liquidity.
  • Fee Structure: Use a maker-taker model, offering lower fees or rebates to makers and higher fees for takers. Regularly adjust fees for competitiveness and sustainability, adding dynamic elements based on activity or order size.

Resources

Examples

dYdX Offchain Order Book

Users submit orders directly to validators, who store these orders in an in-memory order book that is not committed to the blockchain consensus. Validators gossip these orders among themselves to ensure all have an updated view of the order book. When a validator is selected as the proposer in the consensus process, it matches compatible orders and includes the resulting trades in the following proposed block. This approach allows for high-speed order matching and execution while maintaining decentralization, as all components, including the order book and matching engine, operate without centralized control.

Serum Onchain Central Limit Order Book (CLOB)

Users place orders with specific prices and sizes, similar to traditional centralized exchanges, but in a fully decentralized and non-custodial environment. The order book and matching engine operate entirely onchain, leveraging Solana’s high throughput and low latency to ensure efficient order matching and execution. To optimize for Solana's account size limitations, Serum implements a cranking mechanism where separate transactions handle order matching, event processing, and garbage collection of filled orders.