Order book or pool-based: how perpetual DEXs differ

How an order book venue works

Market makers post bids and asks, takers cross the spread, and price is whatever the book says it is. This is the model every traditional exchange uses, and it produces the tightest pricing when there is real competition among makers.

The difficulty on-chain is throughput. Quotes change constantly, and a maker who cannot cancel quickly is exposed to being picked off. That is why venues committed to an order book usually run a dedicated chain, an off-chain matching engine with on-chain settlement, or a rollup tuned for the purpose — a general-purpose chain makes the economics impossible.

How a pool-based venue works

There is no book. Traders open positions against a shared liquidity pool at a price supplied by an oracle, and the pool takes the other side of every trade.

Execution is therefore always available at the oracle price with no slippage from position size, which is genuinely useful for large orders. The cost is that the pool is the counterparty: when traders win, liquidity providers lose, and the pool’s returns depend on traders losing more than they win over time.

What each design does well

Neither model is superior in general; they optimise for different things.

Order book, at its best

Competitive spreads, deep books on major pairs, maker rebates that attract professional liquidity, and order types that serious traders expect.

Order book, at its worst

Thin books on less popular markets, where the quoted spread is wide and a moderate order moves price significantly.

Pool-based, at its best

Guaranteed fills at a fair external price regardless of size, and a simple experience with no book to read.

Pool-based, at its worst

Complete dependence on the oracle, and liquidity provider returns that erode when traders are collectively profitable.

Where the risk actually sits

On an order book venue, the main risks are liquidity and infrastructure. A thin book means bad fills, and a matching layer that halts means positions cannot be managed.

On a pool-based venue, the main risk is pricing. Because the oracle sets the trade price, a manipulated or lagging oracle can be traded against directly, and several of the larger losses in this category have come from exactly that rather than from a flaw in the trading logic.

When comparing venues, this is a more useful question than fee schedules: what has to fail for the design to break, and how much is protecting it.