CLOB vs AMM vs Hybrid Models — Exchange Architecture Deep Dive
TL;DR
- Central Limit Order Book (CLOB) — the gold standard for price discovery and capital efficiency. Every order is explicit, matching is price-time priority, and spreads tighten with competition. Used by every major CEX and increasingly by on-chain protocols (Hyperliquid, dYdX v4)
- Automated Market Maker (AMM) — permissionless liquidity via smart contracts using mathematical pricing formulas (x·y=k). No order management needed, anyone can provide liquidity, but capital efficiency is poor and MEV extraction costs users 0.5–2% per trade
- Hybrid models — protocols like Vertex (CLOB + on-chain AMM fallback) and Drift (vAMM + DLOB + JIT auctions) combine both approaches to bootstrap liquidity while retaining order book precision
- RFQ networks — Paradigm processes ~$1B/day in institutional crypto derivatives by letting traders request quotes from competing dealers rather than posting to a public book. Optimal for large blocks and complex structures
- DEX to CEX spot ratio hit an all-time high of 37.4% in June 2025, up from 6% in 2021. DEX perps ratio reached 11.7% — Hyperliquid alone matched Coinbase's derivatives volume
- Impermanent loss is the hidden cost of AMM liquidity provision — a 2x price move in either direction costs LPs ~5.7% vs holding. Concentrated liquidity (Uniswap v3/v4) amplifies both fees earned and IL
- MEV extraction from AMMs totaled ~$562M in 2025, with sandwich attacks alone accounting for $290M (51.6%). CLOBs largely eliminate sandwich attacks through deterministic matching
- The convergence thesis — Uniswap v4 hooks allow building CLOB-like features (limit orders, dynamic fees) on AMM infrastructure. Meanwhile, on-chain CLOBs (Hyperliquid, dYdX) are proving that order books can work on-chain. The lines are blurring
- Backpack runs a CLOB — the right architecture for a regulated exchange serving institutional and retail traders who need precise order types, deterministic execution, and capital-efficient markets
New to these concepts? See the Glossary for definitions of every term used in this doc. For Backpack's specific matching engine implementation, see Engine & Matching System.
Table of Contents
- The Three Architectures at a Glance
- Central Limit Order Books (CLOBs)
- Automated Market Makers (AMMs)
- Hybrid Models
- RFQ Networks
- Side-by-Side Comparison
- When to Use Which Model
- Why Backpack Runs a CLOB
- The Convergence Thesis
1. The Three Architectures at a Glance
Every exchange — centralized or decentralized — must answer one fundamental question: how do you match a buyer with a seller and at what price?
There are three primary approaches, plus a fourth for specialized use cases:
┌───────────────────────────────────────────────────────────────────────┐
│ EXCHANGE ARCHITECTURES │
├──────────────┬──────────────┬──────────────┬─────────────────────────┤
│ CLOB │ AMM │ Hybrid │ RFQ │
├──────────────┼──────────────┼──────────────┼─────────────────────────┤
│ Buyers and │ Traders │ Combines │ Trader requests │
│ sellers │ trade │ order book │ quotes from │
│ post │ against a │ with AMM │ dealers, picks │
│ explicit │ liquidity │ liquidity │ the best one │
│ orders at │ pool via │ as backstop │ │
│ specific │ math │ or primary │ │
│ prices │ formula │ source │ │
├──────────────┼──────────────┼──────────────┼─────────────────────────┤
│ Binance │ Uniswap │ Vertex │ Paradigm │
│ Backpack │ Curve │ Drift │ Wintermute OTC │
│ NYSE │ Balancer │ Hyperliquid*│ Deribit Block RFQ │
│ Hyperliquid │ PancakeSwap │ │ Backpack Convert/RFQ │
│ dYdX v4 │ │ │ │
└──────────────┴──────────────┴──────────────┴─────────────────────────┘
* Hyperliquid is a pure CLOB but is listed under hybrid context
because it also integrates vault-based liquidity strategies.Each model makes different trade-offs across price discovery, capital efficiency, permissionlessness, latency, and MEV exposure. The rest of this doc dives deep into each.
2. Central Limit Order Books (CLOBs)
How a CLOB Works
A CLOB is a data structure that collects all outstanding buy orders (bids) and sell orders (asks) for an asset, organized by price and time. When a new order arrives, the matching engine checks if it can be filled against existing resting orders.
CLOB Order Book
┌─────────────────────┐
Bids (Buy) │ Best Bid/Ask │ Asks (Sell)
│ = Spread │
┌────────────┐ │ │ ┌────────────┐
│ 100 @ $99 │◄───│ $99 | $101 │───►│ 150 @ $101 │
│ 250 @ $98 │ │ spread = $2 │ │ 200 @ $102 │
│ 500 @ $97 │ │ │ │ 300 @ $103 │
│ 800 @ $96 │ │ │ │ 100 @ $104 │
└────────────┘ └─────────────────────┘ └────────────┘
Incoming market buy order for 200 units:
1. Fill 150 @ $101 (exhaust first ask level)
2. Fill 50 @ $102 (partially fill second level)
3. Average execution price: $101.25Price-Time Priority (FIFO)
The most common matching algorithm. Two rules:
- Price priority — better-priced orders match first. For bids, higher price = better. For asks, lower price = better.
- Time priority — at the same price, the order that arrived first gets filled first. This is why it is called First-In-First-Out.
This is the algorithm Backpack uses. It rewards aggressive pricing and early participation.
The Matching Engine
The matching engine is the core of any CLOB. It receives orders, validates them, and executes the matching logic. In high-performance implementations:
Order Flow Through a Matching Engine:
Trader A (Limit Buy $100) ─┐
Trader B (Market Sell) ─┤
Trader C (Cancel Order #7) ─┼──► Sequencer ──► Matching ──► Events
Trader D (Limit Sell $101) ─┤ (FIFO Engine - Fills
Trader E (Market Buy) ─┘ queue) (single - Placements
thread) - Cancels
- Depth updatesKey properties:
- Deterministic — same inputs always produce same outputs
- Sequential — orders are processed one at a time (no parallel matching)
- Latency-sensitive — microsecond differences matter for competitive markets
Backpack's engine uses BTreeMap data structures for O(log n) order book operations, processes commands via Redis Streams, and shards by market for horizontal scaling. See Engine & Matching System for the full technical breakdown.
CLOB Advantages
| Advantage | Why It Matters |
|---|---|
| Price discovery | The best bid and best ask represent the market's real-time consensus on fair value. No formula approximation — it is the actual willingness to trade |
| Capital efficiency | Market makers deploy capital only at prices they choose. A maker quoting $100–$101 ties up capital for just that $1 range, not a full 0-to-infinity curve |
| Order type richness | Limit, market, stop-loss, stop-limit, trailing stop, iceberg, post-only, IOC, FOK, reduce-only — all possible on a CLOB. AMMs support swaps only |
| Transparency | Every order, cancel, and fill is visible. Participants can see depth, spreads, and recent trades to inform decisions |
| No impermanent loss | Makers choose their prices explicitly. If the market moves away, their orders simply don't fill — they don't lose money by having their position rebalanced against them |
| Deterministic execution | Price-time priority is simple and verifiable. You know exactly where your order sits in the queue |
CLOB Disadvantages
| Disadvantage | Why It Matters |
|---|---|
| Cold start problem | An empty order book has no liquidity. New markets need market makers willing to quote from day one, which requires incentives or partnerships |
| Market maker dependency | Liquidity quality depends on professional market makers. If they pull quotes (during volatility or system issues), spreads blow out |
| Complexity for users | Retail users must understand order types, slippage, partial fills, and order management. AMMs hide this complexity behind a simple swap interface |
| On-chain cost | Every order placement and cancellation is a state change. On high-gas chains like Ethereum L1, this makes on-chain CLOBs impractical — a single market maker might submit thousands of order updates per minute |
| Latency arms race | In TradFi, co-location and HFT create an uneven playing field. Crypto CLOBs face similar dynamics with faster API connections and optimized infrastructure |
3. Automated Market Makers (AMMs)
The Core Idea
An AMM replaces the order book and human market makers with a smart contract that holds reserves of two (or more) tokens and uses a mathematical formula to determine the price. Anyone can trade against the pool, and anyone can deposit tokens to provide liquidity.
Traditional Market Making vs. AMM:
CLOB: AMM:
┌─────────┐ places ┌──────┐ ┌─────────┐ deposits ┌──────────┐
│ Market │──orders───►│ Order │ │Liquidity│──tokens───►│ Liquidity│
│ Maker │◄──fills────│ Book │ │Provider │◄──LP tokens─│ Pool │
└─────────┘ └──────┘ └─────────┘ └──────────┘
▲ ▲
│ │
┌─────────┐ places │ ┌─────────┐ swaps │
│ Trader │──orders────┘ │ Trader │──against─────┘
└─────────┘ └─────────┘
Price set by formula,
Price set by supply not by human quotes
and demand of ordersConstant Product Formula (x · y = k)
The most widely used AMM formula, introduced by Uniswap:
x · y = k
Where:
x = reserve of Token A in the pool
y = reserve of Token B in the pool
k = constant (invariant) that must be maintained after every tradeExample: ETH/USDC pool
Initial state:
x = 100 ETH
y = 300,000 USDC
k = 100 × 300,000 = 30,000,000
Implied price: 300,000 / 100 = $3,000 per ETH
Trader buys 1 ETH:
New x = 99 ETH
New y = k / x = 30,000,000 / 99 = 303,030.30 USDC
Trader pays: 303,030.30 - 300,000 = 3,030.30 USDC for 1 ETH
Effective price: $3,030.30 (0.1% more than spot)
Trader buys 10 ETH:
New x = 90 ETH
New y = 30,000,000 / 90 = 333,333.33 USDC
Trader pays: 333,333.33 - 300,000 = 33,333.33 USDC for 10 ETH
Effective price: $3,333.33 per ETH (11.1% slippage!)The key insight: larger trades move the price more. The curve gets steeper as you trade more, creating "slippage" that increases with trade size. This is both a feature (it prevents pool drain) and a bug (large orders get terrible prices).
Price Impact Curve (Constant Product):
Price
($)
│
│ ╱
│ ╱
│ ╱
│ ╱
│ ╱
│ ╱
│ ╱
│ ╱╱
│ ╱╱╱
│ ╱╱╱╱
│╱╱╱╱
└──────────────────────────────────────────
Trade Size ──►
Small trades: minimal price impact
Large trades: severe price impact (slippage)Concentrated Liquidity (Uniswap v3/v4)
Standard x·y=k spreads liquidity across the entire price range from 0 to infinity. This is wildly capital-inefficient — most of the liquidity sits at prices that will never be reached.
Uniswap v3 (launched May 2021) introduced concentrated liquidity: LPs choose a specific price range to provide liquidity within. This can provide up to 4,000x capital efficiency improvement compared to v2.
Uniswap v2 (Full Range): Uniswap v3 (Concentrated):
Liquidity Liquidity
│ │
│ ████████████████████ │
│ ████████████████████ │ ████████
│ ████████████████████ │ ████████
│ ████████████████████ │ ███████████████
│ ████████████████████ │ ██████████████████████
└────────────────────── └──────────────────────────
$0 Price $∞ $2,800 $3,000 $3,200
▲
Liquidity spread across │
entire 0→∞ range Liquidity concentrated
(most of it wasted) around current priceTechnical implementation: The price space is divided into discrete ticks, spaced so each tick represents a 0.01% price change (1 basis point). LPs deposit liquidity across a range of ticks. When the price moves outside an LP's range, their position becomes inactive (earns no fees) and holds 100% of one asset.
Uniswap v4 (launched January 2025) refined this further with:
- Singleton architecture — all pools in one contract, reducing gas for pool creation by 99%
- Hooks — custom smart contracts that extend pool behavior (limit orders, dynamic fees, custom oracles)
- Flash accounting — internal balance tracking minimizes token transfers
- Native ETH support — no more wrapping to WETH
As of late 2025, Uniswap v3 has processed over $1.2 trillion in cumulative trading volume across Ethereum, Polygon, and Arbitrum, with ~$3.8B TVL.
Impermanent Loss
The fundamental cost of providing liquidity to an AMM. When the price of assets in the pool diverges from when you deposited, you end up with less value than if you had simply held the tokens.
Impermanent Loss Formula (50/50 pool):
IL = 2√(p) / (1 + p) - 1
Where p = price ratio change (new price / original price)
Price Change │ Impermanent Loss
────────────────┼──────────────────
1.25x (25% up) │ 0.6%
1.50x (50% up) │ 2.0%
2.00x (2x) │ 5.7%
3.00x (3x) │ 13.4%
5.00x (5x) │ 25.5%
0.50x (50% drop)│ 5.7%
0.20x (80% drop)│ 25.5%Why "impermanent"? If the price returns to the original ratio, the loss reverses. In practice, for volatile pairs, the loss is almost always permanent because prices rarely return to exactly where they started.
With concentrated liquidity, IL is amplified. A tighter range means more capital efficiency and more fees, but the position gets fully converted to the losing asset faster when price moves.
AMM Advantages
| Advantage | Why It Matters |
|---|---|
| Permissionless liquidity | Anyone can become a liquidity provider by depositing tokens. No application, no minimum capital, no market-making expertise needed |
| No order management | LPs deposit and earn fees passively. No need to constantly update quotes, manage inventory, or respond to market movements (especially in v2 full-range positions) |
| Guaranteed liquidity | The pool always has liquidity at some price. There is no empty order book or "no market maker available" situation |
| Simple UX | Users see one button: "Swap." No order types, no partial fills, no complexity. This drove DeFi adoption |
| Composability | LP tokens can be used as collateral in other protocols, creating capital efficiency through DeFi composability (lending, leveraged LP, etc.) |
| Long-tail assets | Any token with a smart contract can have a market. No listing process, no market maker agreements |
AMM Disadvantages
| Disadvantage | Why It Matters |
|---|---|
| Capital inefficiency | Even with concentrated liquidity, capital is deployed along a curve, not at specific price points. V2 pools waste ~99.5% of their liquidity |
| Impermanent loss | LPs are systematically short volatility. Academic research shows most Uniswap v3 LPs lose money after accounting for IL |
| MEV / toxic flow | Public mempools allow sandwich attacks and frontrunning. In 2025, sandwich attacks extracted $290M from AMM traders. Average user pays a 0.5–2% invisible MEV tax |
| Poor price discovery | AMM prices are derivative — they follow external price feeds and arbitrageurs. The AMM does not discover price; it mirrors it, usually with a lag |
| No advanced order types | No stop-losses, no limit orders (natively), no iceberg orders, no post-only. The only primitive is "swap X for Y at whatever price the formula gives" |
| Adverse selection | Informed traders (arbitrageurs) systematically extract value from uninformed LPs. The pool always trades at stale prices until arbed back to fair value |
The MEV Problem
MEV (Maximal Extractable Value) is a tax on AMM users. Because transactions are visible in the mempool before execution, sophisticated actors can:
Sandwich Attack on an AMM:
Time ──►
1. Victim submits: "Swap 10 ETH for USDC"
(visible in mempool)
2. Attacker frontruns: Buys ETH, pushing price up
┌──────────────────┐
│ Attacker buys │ Price: $3,000 → $3,050
│ 5 ETH @ $3,000 │
└──────────────────┘
3. Victim's trade executes at worse price
┌──────────────────┐
│ Victim sells │ Gets $3,050 instead of $3,000
│ 10 ETH @ ~$3,050 │ (actually gets less USDC)
└──────────────────┘
4. Attacker backruns: Sells ETH at inflated price
┌──────────────────┐
│ Attacker sells │ Price: $3,050 → $3,000
│ 5 ETH @ ~$3,050 │ Profit: ~$250
└──────────────────┘
Victim paid ~$250 more than fair price.
Attacker pocketed ~$250 minus gas.2025 MEV statistics:
- Total MEV extracted: ~$562M
- Sandwich attacks: $290M (51.6%)
- Arbitrage: ~$196M (35%)
- Liquidations: ~$76M
- On Solana specifically, sandwich bots extracted $370–500M over 16 months
CLOBs largely eliminate sandwich attacks because matching is deterministic (price-time priority) and there is no mempool manipulation — orders are processed by the matching engine in sequence.
4. Hybrid Models
Hybrid models attempt to capture the best of both worlds: the capital efficiency and order type richness of CLOBs with the permissionless, always-on liquidity of AMMs.
dYdX v4 — Sovereign CLOB Chain
dYdX migrated from a StarkEx-based L2 (v3) to its own sovereign blockchain built on the Cosmos SDK (v4), making the entire exchange — order book, matching engine, and settlement — decentralized.
dYdX v4 Architecture:
┌──────────────────────────────────────────────────┐
│ dYdX Chain │
│ (Cosmos SDK + CometBFT) │
├──────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌───────────────────┐ │
│ │ Off-Chain │ │ On-Chain │ │
│ │ Order Book │ │ Settlement │ │
│ │ │ │ │ │
│ │ Maintained by │───►│ Only matched │ │
│ │ all validators │ │ trades go │ │
│ │ in memory │ │ on-chain │ │
│ └─────────────────┘ └───────────────────┘ │
│ │
│ Key: Order book is off-chain (in validator │
│ memory), only fills are committed to the chain. │
│ This dramatically reduces on-chain throughput │
│ requirements. │
└──────────────────────────────────────────────────┘
Performance:
- Throughput: ~10,000 TPS (order operations)
- H1 2025 volume: $316B
- Open interest: ~$175M
- ~60 active validatorsKey design decision: The order book lives in validator memory, not on-chain state. Only matched trades are committed as on-chain transactions. This avoids the gas cost of every placement and cancellation while still achieving decentralization — all validators maintain identical copies of the book via consensus.
Hyperliquid — Custom L1 CLOB
Hyperliquid took a different approach: build a custom L1 blockchain (HyperBFT consensus) with the order book as a first-class on-chain primitive.
Hyperliquid Architecture:
┌─────────────────────────────────────────────────┐
│ HyperL1 (Custom Chain) │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌────────────────────┐ │
│ │ HyperCore │ │ HyperEVM │ │
│ │ (Native │ │ (General purpose │ │
│ │ CLOB) │ │ smart contracts) │ │
│ │ │ │ │ │
│ │ Every order │ │ DeFi composability │ │
│ │ is on-chain │ │ with the order │ │
│ │ │ │ book │ │
│ └──────────────┘ └────────────────────┘ │
│ │
│ Performance: │
│ - Finality: ~200ms │
│ - Throughput: 200,000 orders/sec │
│ - Daily volume: ~$8.9B │
│ - Market share: >75% of on-chain perps │
└─────────────────────────────────────────────────┘Hyperliquid is notable for proving that a fully on-chain CLOB can achieve CEX-grade performance. Its 200ms finality and 200K orders/second throughput eliminate the common objection that "order books can't work on-chain."
Vertex — True Hybrid (CLOB + AMM)
Vertex Protocol (on Arbitrum) ran a genuine hybrid where an off-chain CLOB sequencer and an on-chain AMM operated in parallel, with unified liquidity.
Vertex Hybrid Architecture:
┌─────────────────────────────────────────────────┐
│ Vertex Protocol │
├───────────────────────┬─────────────────────────┤
│ Off-Chain Sequencer │ On-Chain AMM │
│ (CLOB) │ (Constant Product) │
│ │ │
│ - 15K TPS │ - xy=k formula │
│ - 5-15ms latency │ - Always available │
│ - Limit orders │ - Fallback if │
│ - Price-time │ sequencer is down │
│ priority │ │
├───────────────────────┴─────────────────────────┤
│ Unified Liquidity │
│ AMM liquidity supplements the order book. │
│ Traders get the best price from either source. │
│ If sequencer goes down, AMM is the backstop. │
└─────────────────────────────────────────────────┘Key innovation: The AMM served as a fallback — if the off-chain sequencer went down, users could always trade against the on-chain AMM. This addressed the centralization concern of off-chain order books while maintaining CEX-like performance for normal operations.
Note: Vertex ceased trading operations in August 2025.
Drift — vAMM + DLOB + JIT Auctions
Drift Protocol on Solana uses a three-layered liquidity architecture — arguably the most creative hybrid design in crypto.
Drift's Three-Layer Liquidity System:
Incoming Order
│
▼
┌──────────────────────────────────────┐
│ Layer 1: JIT (Just-in-Time) Auction │
│ │
│ Market makers compete in a ~5-second │
│ Dutch auction to fill the order at │
│ the best price. Winner takes the │
│ fill. │
└───────────────┬──────────────────────┘
│ Unfilled portion
▼
┌──────────────────────────────────────┐
│ Layer 2: DLOB (Decentralized LOB) │
│ │
│ Off-chain limit order book │
│ maintained by Keeper bots who earn │
│ fees for matching orders. Similar │
│ to a CLOB but decentralized. │
└───────────────┬──────────────────────┘
│ Still unfilled
▼
┌──────────────────────────────────────┐
│ Layer 3: vAMM (Virtual AMM) │
│ │
│ Backstop liquidity. Oracle-pegged │
│ curve ensures there is always a │
│ price. Re-pegs periodically to │
│ avoid drift from fair value. │
└──────────────────────────────────────┘
Result: Every order gets filled, but the best
prices come from layers 1 and 2.
Drift v3 (Dec 2025): 85% of market orders fill
within a single 400ms Solana slot.
Open interest: ~$533MOpenBook — Community CLOB on Solana
After FTX's collapse killed the original Serum DEX in November 2022, the Solana community forked it into OpenBook — a fully on-chain, community-governed CLOB.
- OpenBook v2 rebuilt from scratch (not Serum code)
- Fully on-chain order book using Solana's high throughput (~400ms slots)
- Integrated with Jupiter, Mango Markets, and Raydium as a liquidity source
- DAO-governed with no central team controlling the protocol
- Permissionless market creation — anyone can create a market for any SPL token
OpenBook demonstrates that on-chain CLOBs are viable on high-throughput chains, though it operates at lower volumes than centralized alternatives due to the inherent latency and UX challenges.
5. RFQ Networks
What is RFQ?
Request for Quote is a trading model where the trader asks dealers for a price rather than trading against a public order book or pool. It is the dominant model for institutional OTC trading, options, and large block trades.
RFQ Flow:
┌──────────┐ ┌──────────────┐
│ │ "I want to buy │ Dealer A │
│ │ 500 BTC" │ (Wintermute) │
│ │─────────────────────►│ Quote: $97,450│
│ │ └──────────────┘
│ │
│ Trader │ ┌──────────────┐
│ │─────────────────────►│ Dealer B │
│ │ │ (Jump) │
│ │ │ Quote: $97,420│
│ │ └──────────────┘
│ │
│ │ ┌──────────────┐
│ │─────────────────────►│ Dealer C │
│ │ │ (Galaxy) │
│ │ │ Quote: $97,440│
│ │ └──────────────┘
│ │
│ │ Accepts Dealer B's quote ($97,420)
│ │═══════════════════════════════════════► Trade executes
└──────────┘Paradigm — The Institutional RFQ Platform
Paradigm is the dominant crypto RFQ network, processing $800M–$1B in daily institutional derivatives volume. Key features:
- Multi-Dealer RFQ (MDRFQ) — request quotes from multiple dealers simultaneously, disclosed or anonymous. 68.9% of RFQs use this feature, with 74.5% executed anonymously
- Multi-leg structures — combine options, futures, and spot in a single RFQ with up to 20 legs
- Exchange integration — trades settle directly on connected exchanges (Deribit, Bit.com, CME)
- Block trades — privately negotiated principal-to-principal trades exceeding minimum size thresholds
Deribit also launched its own Block RFQ system in March 2025, allowing multiple liquidity providers to offer partial quotes rather than requiring all-or-nothing fills.
When RFQ Makes Sense
| Use Case | Why RFQ Wins |
|---|---|
| Large blocks | A 500 BTC order on a CLOB would eat through the book and suffer massive slippage. RFQ lets you get a single price for the whole block |
| Options and structured products | Complex multi-leg strategies (straddles, butterflies, collars) don't fit neatly into a single order book. RFQ lets you quote the entire structure as a package |
| Illiquid assets | For assets without deep order book liquidity, dealers can warehouse risk and provide a quote where no public market exists |
| Privacy | Institutional traders don't want to signal their intent to the market. RFQ is inherently private — only the dealers you choose see your interest |
Backpack's RFQ system serves this same function for Convert operations — see Backpack Convert/RFQ for how market makers compete to quote the best price for simple token swaps.
6. Side-by-Side Comparison
Performance and Architecture
| Dimension | CLOB | AMM (Uniswap v3) | Hybrid (Drift) | RFQ (Paradigm) |
|---|---|---|---|---|
| Price discovery | Excellent — real supply/demand | Poor — follows oracles/arbs | Good — JIT + DLOB | N/A — dealer quotes |
| Capital efficiency | Very high — deploy at specific prices | Medium — concentrated ranges | High — three liquidity layers | Very high — full notional |
| Latency | Sub-ms (CEX), 200ms (Hyperliquid) | 12s (Ethereum), ~400ms (Solana) | ~400ms (Solana) | Seconds to minutes |
| Throughput | 100K+ orders/sec (CEX) | ~15 TPS (Ethereum L1) | ~1,000 TPS (Solana) | Low (not throughput-sensitive) |
| MEV exposure | Low (deterministic matching) | Very high ($562M in 2025) | Medium (JIT reduces it) | None (private negotiation) |
| Permissionlessness | Low (CEX), Medium (on-chain) | Very high | Medium–High | Low (dealer relationships) |
| Cold start | Hard — needs market makers | Easy — anyone can create a pool | Medium — needs keeper bots | Hard — needs dealer network |
Capital Efficiency Deep Dive
Capital Required to Provide $1M of Effective Liquidity
at ±2% Around Spot Price:
CLOB (limit orders at specific prices):
████ $1M ← Deploy exactly what you need
Uniswap v3 (concentrated ±2%):
████████ ~$2M ← ~2x for concentrated range
Uniswap v2 (full range):
████████████████████████████████████████████ ~$50M+
← Capital spread 0→∞
RFQ (dealer quote):
████ $1M ← Dealer warehouses the riskTrade-off Summary
Permissionless Capital Efficient
▲ ▲
│ │
│ AMM │ CLOB
│ ● │ ●
│ │
│ Hybrid │ RFQ
│ ● │ ●
│ │
│ RFQ │ AMM
│ ● │ ●
│ CLOB │
│ ● │
└──────────────────────► └──────────────────────►
Less Less
Permissionless Capital Efficient7. When to Use Which Model
By Market Type
| Market Type | Best Model | Why |
|---|---|---|
| Major spot pairs (BTC/USD, ETH/USD) | CLOB | Deep liquidity exists, tight spreads matter, institutional flow demands order types |
| Perpetual futures | CLOB | Funding rates, liquidation engines, and cross-margin all require deterministic matching and order type support |
| Long-tail spot tokens | AMM | No market maker will quote an obscure token. Permissionless pool creation is the only way to bootstrap liquidity |
| Stablecoin swaps | AMM (Curve/StableSwap) | Specialized bonding curves (StableSwap) optimized for assets that trade near parity. Minimal IL |
| Options & structured products | RFQ | Multi-leg structures, large notional, need for privacy and custom pricing |
| Large block trades | RFQ | Minimize market impact, get a single guaranteed price for the full size |
By Participant Type
| Participant | Best Model | Why |
|---|---|---|
| Retail trader | AMM (simple swaps) or CEX CLOB | AMMs have the simplest UX. CEX CLOBs offer more features with a managed interface |
| Professional trader | CLOB | Needs limit orders, stop-losses, order management, and execution control |
| Market maker | CLOB | Needs to place and cancel orders rapidly, manage inventory, and quote two-sided markets |
| Passive LP | AMM | Deposit and earn fees without active management (though returns may underperform holding) |
| Institution | CLOB + RFQ | CLOB for flow execution, RFQ for large blocks and complex strategies |
| DeFi protocol | AMM | Composability with other protocols, permissionless integration, LP tokens as collateral |
By Volume Regime
| Volume Level | Best Model | Why |
|---|---|---|
| High volume, tight spreads | CLOB | Market makers compete aggressively; CLOB's price-time priority rewards the best prices |
| Medium volume | Hybrid | CLOB handles the bulk flow; AMM or vAMM provides backstop liquidity when the book thins out |
| Low volume / new market | AMM | Permissionless pool creation bootstraps initial liquidity. CLOB would have an empty book |
8. Why Backpack Runs a CLOB
Backpack operates as a regulated exchange (licensed by the Virtual Assets Regulatory Authority in Dubai) serving both retail and institutional users. A CLOB is the right architecture for this context:
Regulatory Alignment
Regulated exchanges require auditability, transparency, and fairness. A CLOB's price-time priority matching is deterministic and verifiable — regulators can inspect every order, fill, and cancellation. AMM mechanics (particularly MEV extraction and impermanent loss) are harder to reconcile with investor protection standards.
Institutional Requirements
Professional traders and market makers need:
- Order types — limit, market, stop-loss, stop-limit, post-only, reduce-only, IOC, FOK (see Order Types)
- Cross-margin — unified collateral across positions (see Collateral and Portfolio Margin)
- Deterministic execution — know exactly where your order sits and when it will fill
- Low latency — competitive market making requires sub-millisecond response times
AMMs cannot provide any of these.
Capital Efficiency
Backpack's matching engine processes orders with O(log n) complexity using BTreeMap data structures, shards by market for horizontal scaling, and maintains deterministic state across multiple nodes via gossip protocol. This architecture delivers:
- Precise capital deployment (makers quote exactly the prices they want)
- Zero impermanent loss (makers control their exposure)
- No MEV extraction (deterministic matching, no mempool manipulation)
The Full Stack
Backpack's CLOB integrates with its broader infrastructure:
Backpack Exchange Architecture:
┌─────────────────────────────────────────────────┐
│ CLOB Engine │
│ (Price-Time Priority, BTreeMap, Market Shards) │
├──────────┬──────────┬──────────┬────────────────┤
│ Order │ Risk │ Margin │ Liquidation │
│ Types │ Engine │ System │ Engine │
├──────────┴──────────┴──────────┴────────────────┤
│ Settlement & Clearing │
├─────────────────────────────────────────────────┤
│ Custody & Key Management │
├─────────────────────────────────────────────────┤
│ RFQ/Convert (for simple swaps) │
└─────────────────────────────────────────────────┘
The CLOB is the core. Everything else builds on top of it.For detailed implementation, see:
- Engine & Matching System — how orders are matched
- Order Flow — how orders travel through the system
- Order Types — all supported order types
- RFQ Guide — how Convert uses RFQ as a complement to the CLOB
9. The Convergence Thesis
Are CLOBs and AMMs Converging?
The most interesting trend in exchange design is the gradual convergence of the two models. Each side is adopting features of the other.
AMMs Becoming More Like CLOBs
Uniswap v3 concentrated liquidity already resembles a discretized order book — LPs effectively place "limit orders" at specific price ranges. The tighter the range, the more it behaves like a resting limit order.
Uniswap v4 hooks take this further. Developers can now build:
- Limit orders on top of AMM pools
- Dynamic fees that adjust based on volatility or time of day
- Custom pricing curves that mimic order book behavior
- TWAP execution engines within the AMM framework
The AMM → CLOB Spectrum:
Pure AMM Pure CLOB
(Uniswap v2) (Binance)
│ │
│ Uniswap v3 Uniswap v4 On-chain CLOB │
│ (concentrated) (hooks) (Hyperliquid) │
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
───●───────●────────────────●────────────────────●────────●───
│ │
Full-range Concentrated Explicit
liquidity ranges with orders at
(x·y=k) custom logic exact pricesCLOBs Becoming More Permissionless
On the other side, on-chain CLOBs are becoming more AMM-like in their openness:
- Hyperliquid allows anyone to create markets and participate as a maker
- dYdX v4 is fully decentralized with validator-maintained order books
- OpenBook v2 is community-governed with permissionless market creation
The distinction between "AMM" and "CLOB" becomes blurred when:
- A CLOB runs on-chain and anyone can participate as a maker
- An AMM uses concentrated liquidity at specific price points
- Hooks allow arbitrary logic to be attached to AMM operations
Where This Is Heading
2020: Clear separation
┌────────────────┐ ┌────────────────┐
│ CEX: CLOB │ │ DEX: AMM │
│ (centralized) │ │ (on-chain) │
└────────────────┘ └────────────────┘
2025: Blurring boundaries
┌────────────────────────────────────────┐
│ On-chain CLOBs │ AMMs with hooks │
│ (Hyperliquid, │ (Uniswap v4, │
│ dYdX v4) │ custom curves) │
│ │ │
│ ◄── converging ──► │
└────────────────────────────────────────┘
Future: Modular liquidity
┌────────────────────────────────────────┐
│ Unified liquidity layer │
│ │
│ CLOB matching for liquid pairs │
│ AMM pools for long-tail bootstrapping │
│ RFQ for institutional blocks │
│ JIT auctions for best execution │
│ │
│ All composable, all on-chain │
└────────────────────────────────────────┘The likely end state is not "AMM wins" or "CLOB wins" but modular liquidity infrastructure where different models coexist and route orders to the best venue:
- Liquid pairs → CLOB matching for tightest spreads
- Long-tail pairs → AMM pools for bootstrapped liquidity
- Large institutional orders → RFQ for minimal market impact
- Price-sensitive orders → JIT auctions for competitive execution
The exchange of the future will not ask "CLOB or AMM?" — it will use both, routing dynamically based on the asset, the order size, and the participant.
DEX vs CEX: The Volume Landscape (2025)
For context on where these models operate today:
| Metric | 2021 | 2025 |
|---|---|---|
| DEX-to-CEX spot ratio | 6.0% | 21.2% (peak: 37.4% in June 2025) |
| DEX-to-CEX perps ratio | ~1% | 11.7% (Nov 2025) |
| DEX spot volume ATH | — | $419.8B (Oct 2025) |
| DEX perps volume ATH | — | $903.6B (Oct 2025) |
| Top DEX by perps volume | — | Hyperliquid ($2.74T cumulative in 2025) |
| Top DEX by spot volume | — | Uniswap ($1.2T+ cumulative on v3) |
The trend is clear: DEX market share is growing structurally, driven by on-chain CLOBs for derivatives and concentrated liquidity AMMs for spot. But CEXs still handle the majority of volume, and CLOBs remain the dominant model for both.
Further Reading
- Engine & Matching System — how Backpack's CLOB matching engine works
- Order Types — every order type supported on Backpack's CLOB
- Order Flow — how orders travel from submission to execution
- Market Making — how market makers operate on CLOBs
- RFQ Guide — how Backpack's Convert/RFQ system complements the CLOB
- Dark Pools — hidden liquidity venues and how they relate to public order books
- Fee Structures — maker/taker fee models on CLOBs