Order Book vs AMM for Perps

The essentials

This guide is general information and does not constitute investment advice. Leveraged trading can lead to the rapid loss of all the margin committed.

Reminder: what a perp DEX has to solve

A perpetual contract is a derivative with no expiry date, which tracks an asset's price through a funding mechanism. A perps platform has to answer three questions:

1. Who is on the other side of your trade? Another trader, a market maker or a pool.
2. How is the execution price set? By orders meeting, or by an external source.
3. Who pays when a trader wins? The losers, a pool, an insurance fund.

The answers differ across three main models.

Model 1: the order book (CLOB)

A CLOB (central limit order book) lists buy and sell orders at different prices. A market order consumes existing limit orders; limit orders wait. Traders are each other's counterparties, and market makers provide most of the liquidity by quoting prices on both sides.

Fully onchain CLOB

At Hyperliquid, the documentation describes an onchain order book: orders and cancellations are blockchain transactions, matched by price-time priority. An important detail: within a block, actions are sorted by category, first non-order actions, then cancellations, then new orders. This sorting favors market makers, who can pull an order that has gone bad before an aggressive order hits it. Margin requirements are checked when the order is placed and at the time of matching.

This model assumes a blockchain built to absorb a very large number of orders and cancellations, with fast blocks. That's why it's found mostly on specialized chains rather than on general-purpose networks.

Offchain book, onchain settlement

dYdX v4 illustrates a hybrid approach. According to its documentation, each node maintains an order book in memory, updated in real time; the block proposer produces matches from its local book, by price-time priority, then the network incorporates these results through consensus. Because messages don't arrive everywhere at the same time, nodes' books can temporarily diverge.

A practical consequence noted in the documentation: a cancellation isn't guaranteed to be instantaneous. For short-term orders, expiry at a given block number (good-til-block) is the only sure way to make an order unexecutable, hence the value of setting short expirations.

Other platforms keep a fully centralized matching engine and only settle balances onchain. Transparency and censorship resistance are then lower.

Strengths and weaknesses of the CLOB

• Price: formed by supply and demand, without directly depending on an oracle for execution (an oracle is still often used for the mark price, funding and liquidations).
• Limit orders: you can provide liquidity and set your price precisely.
• Price impact: depends on the book's depth. On an illiquid pair, a large market order can sweep through several price levels.
• Dependence on market makers: if they pull back in times of stress, the book empties and spreads widen.
• Latency: the fastest actors, or those best placed in the network, have an edge.

Model 2: the oracle pool (GMX-style model)

Here, there's no book. A liquidity pool, funded by liquidity providers (LPs), acts as the counterparty to all traders. The execution price comes from an oracle that aggregates prices from several marketplaces.

The GMX V2 documentation is explicit: the pool is the traders' counterparty; if traders win, their profit is paid from the pool's value. The pool token's price depends on the price of the assets it holds and on the net unrealized PnL (profit and loss) of open positions. In return, trading and swap fees increase the value of the pool token.

How execution works

• Two-step execution: you submit an order request, then "keepers" (bots in charge of execution) detect it and execute it at the oracle price. Network fees are charged, overestimated, then partly refunded.
• Synthetic price impact: since there's no book, the protocol simulates a price impact to discourage positions that unbalance the pool (too many longs compared with shorts, for example). The exact mechanics have evolved across versions: check the current documentation.
• Borrowing fees and funding: the dominant side pays borrowing fees, and funding adjusts gradually according to the long/short ratio.
• Open interest caps: available capacity shrinks as open positions grow. If winning positions become too large relative to the pool, auto-deleveraging (ADL) can close part of the profitable positions to preserve solvency.

Strengths and weaknesses

• For the trader: execution at the oracle price, without having to cross a book; useful on markets where no market maker would be present.
• For the LP: they collect fees but carry the traders' PnL. If traders win collectively, the pool loses. GMX's documentation also lists smart contract risks and, for bridged tokens, dependence on the bridge's security. Withdrawals can be limited when part of the assets is reserved for open positions.
• Oracle risk: if the oracle price is lagging, manipulable or wrong, traders can exploit the gap at the pool's expense. This is the structural weakness of the model, hence the importance of source quality, update frequency and safeguards (delays, price gaps, caps).
• Caps: the maximum position size is limited by the pool's size.

Model 3: the vAMM, a historical chapter

The vAMM (virtual AMM) was popularized by Perpetual Protocol v1. It uses the constant-product formula of spot AMMs (x × y = k), but with virtual reserves: no asset is actually traded, positions are settled in USDC and the formula is used only to compute the price.

The analysis published by Deribit Insights in 2021 highlights its limits:

• in a vAMM, net open interest determines how far the price is from the opening price; the further the price strays from its initial level, the more open interest it takes to keep it there;
• when longs and shorts are imbalanced, funding flows don't balance out and the insurance fund has to pay (or receive) the difference;
• arbitrageurs could extract value during volatility, and the insurance fund had to be topped up in May 2021.

These difficulties partly explain the sector's shift toward fast order books and oracle pools. The vAMM remains useful for understanding why a formula alone isn't enough to price a derivative correctly.

Summary table

A concrete example

You want to open a long with a notional value (total position value) of 50,000 dollars on a mid-sized asset. Illustrative scenario, with no real platform figures.

On an order book. You check the depth: within 0.1% of the mid price, there are only 30,000 dollars of offers. A 50,000-dollar market order will therefore sweep through several levels, and your average price will be worse than the displayed price. Alternative: place a limit order and accept that it won't be filled immediately, or split your entry. You know your price, but not your fill rate.

On an oracle pool. You're filled at the oracle price, plus a synthetic impact that depends on the imbalance between longs and shorts. If the market is already overwhelmingly long, you'll pay more in impact and borrowing fees. You don't cross a book, but you depend on the keeper and the oracle at execution time. If the open interest cap is reached, the position can't be opened.

On the LP side. If you were providing this pool's liquidity, your long would be on the other side of you. In a sharp rally, the value of your share would drop by the amount of traders' unrealized gains, fees aside.

Checklist before choosing where to trade

• What is the counterparty: book, pool, hybrid?
• Where do the execution price, the mark price and the liquidation price come from?
• What is the real depth on your pair, at the size you're aiming for?
• Are there open interest caps or an ADL mechanism?
• How are cancellations handled (delays, expiry)?
• What fees: trading, borrowing, funding, keepers' network fees?
• What is the level of centralization (sequencer, validators, admin keys)?

Mistakes to avoid

• Assuming "DEX" means the same risks everywhere: an oracle pool and an onchain book don't expose you to the same failures.
• Becoming an LP in a perps pool the way you'd deposit in a spot pool: you are the counterparty to leveraged traders, not just a liquidity provider.
• Ignoring depth: low displayed volume can hide a very thin book away from the main spread.
• Forgetting ADL: on some models, a winning position can be partially closed without your intervention.
• Believing a cancellation is instantaneous: on hybrid books, an order can be filled after your cancellation request.
• Neglecting oracle risk on illiquid assets, whose reference price is easier to move.

Key takeaways

• A CLOB puts traders face to face; liquidity depends on market makers and book depth.
• An onchain book puts orders and cancellations in blocks; a hybrid book matches offchain and settles through consensus.
• In an oracle pool, LPs are the counterparty to all traders and the price comes from an external source.
• Oracle risk and traders' PnL are the two main dangers of pools; latency and volatile liquidity those of order books.
• The vAMM showed that a formula without real liquidity creates imbalances that are costly for the insurance fund.
• Before trading, identify the counterparty, the price source, the caps and the real fees.

Sources

• Hyperliquid Docs — Order book
• dYdX Docs — Limit Order Book and Matching
• GMX Docs — Providing Liquidity (V2)
• GMX Docs — Trading (V2)
• Deribit Insights — The Quest for Perp AMMs (Sobrado, Al-Kamil, 2021)