Perp DEX Design: Orderbook vs Pool Architecture

Hyperliquid processed billions of dollars in open interest on a fully onchain orderbook while GMX's liquidity pool absorbed trader losses on the other side of the same market. Both are "DeFi perps." They are not remotely similar in how they work — and the difference determines who takes the risk, how prices form, and what breaks under stress.

Two Ways to Match a Trade

Every perpetual futures venue solves the same problem: connect a trader who wants to go long with one who wants to go short, anchor that price near spot via a funding rate, and keep the whole thing running onchain. The matching layer is where the designs diverge.

CLOB venues (central-limit order book) match resting limit orders from makers against incoming market orders from takers. Price emerges from competitive quoting — no oracle price feed is needed for execution. Pool/AMM-oracle venues skip the order book entirely: traders open positions against a shared liquidity pool, with entry and exit priced by an external oracle feed.

That single architectural choice drives every downstream difference in fee structure, LP risk, latency requirements, and decentralisation trade-offs.

The Orderbook Family

A CLOB works like a traditional derivatives exchange: makers post limit orders and typically pay zero fees or receive a rebate; takers hit those orders and pay a small fee. The spread between best bid and offer is the market's real-time price discovery. Because traders are quoting against each other, no oracle is needed for trade execution.

The hard problem is latency. Ethereum L1 blocks are far too slow for market makers to update quotes without being picked off by faster participants. CLOB perp venues have therefore moved to purpose-built infrastructure: sovereign Layer 1s, Cosmos appchains, or ZK rollups with fast soft-finality.

Hyperliquid

Hyperliquid is a sovereign Layer 1 running HyperBFT consensus. Order matching, cancels, fills, and liquidations all execute onchain in its HyperCore layer — there is no offchain matching server. HyperEVM is a separate EVM-compatible layer for smart contracts, isolated from HyperCore so application execution does not compete with order matching.

The result is sub-second finality with fully onchain state. As of 2026, Hyperliquid commands roughly 73% of decentralised perp DEX volume, with multi-billion-dollar daily perp volume and open interest in the billions. That dominance reflects both the performance of purpose-built infrastructure and the network effects of deep liquidity attracting more liquidity.

The Hyperliquidity Provider (HLP) vault acts as a passive market maker and liquidation backstop; users deposit USDC and receive a share of fees and liquidation profits. The mechanics of HLP and liquidation insurance funds are covered in Part 4.

dYdX v4

dYdX v3 was a hybrid: fast, but centralised — an offchain orderbook operated by dYdX Trading Inc. with StarkEx ZK-rollup settlement. dYdX v4 eliminated the centralised operator by building a standalone sovereign blockchain on the Cosmos SDK with CometBFT consensus.

In v4, all validators collectively maintain the orderbook in memory and run deterministic matching. Orders are gossiped between validators and only committed onchain once matched, avoiding gas costs for placement and cancellations. A large share of trading fees is distributed to DYDX stakers in USDC, with the insurance fund and treasury receiving the remainder. By 2026, dYdX has expanded beyond perps into spot and other markets.

Lighter

Lighter takes a different path: an application-specific ZK rollup anchored to Ethereum rather than a standalone appchain. Matching, funding, risk checks, and liquidations are all encoded in ZK circuits; Ethereum verifies each proof before accepting state updates, making every trade cryptographically verifiable.

The trade-off is proving overhead and reliance on Ethereum for final settlement — slower than an appchain for latency — in exchange for a stronger trust guarantee than a standalone validator set.

Orderbook Strengths and Costs

The CLOB design's advantages are genuine price discovery through competitive quoting, tight spreads when market makers compete, and transparent onchain depth. There is no oracle dependency for execution.

The costs are real. There is a classic chicken-and-egg bootstrapping problem: without market makers, spreads widen and the venue becomes unusable. Ultra-low-latency infrastructure is non-negotiable, which means some degree of bespoke engineering. In periods of extreme volatility, market makers can pull quotes, liquidity thins, and spreads blow out.

The Pool / AMM-Oracle Family

In the pool model there is no order book. Traders open positions against a shared liquidity pool, and entry and exit prices come from an external oracle — so there is theoretically zero price impact at the oracle price. But the pool is the counterparty. When traders profit, pool value falls. When traders lose, pool value rises. Liquidity providers are the house, absorbing the aggregate directional PnL of the entire trader base.

Oracle dependency is the model's core vulnerability. A manipulated or stale price feed can allow an attacker to open large profitable positions against the pool at a price the market has already moved past. Capacity is also structurally limited: per-market open-interest caps prevent positions too large for the pool to absorb, and borrow fees plus skew fees discourage imbalanced books.

GMX

GMX v1 used GLP — a single multi-asset basket of BTC, ETH, and stablecoins — that provided liquidity for every market at once. Traders entered at oracle prices with zero price impact and GLP holders earned most protocol fees. The weakness was directional risk in trending markets: a sustained BTC bull run meant GLP holders were collectively short the very asset backing their pool.

GMX v2 addressed this with isolated GM pools, one per trading pair. LPs now choose their market exposure rather than inheriting it across all pairs. v2 also added funding fees that pay the underrepresented side to encourage balance. GMX v2 remains relevant in 2026 but operates at a fraction of Hyperliquid's scale: around $201 million TVL and roughly $73 million daily volume as of May 2026.

Gains Network (gTrade)

gTrade is a synthetic perp DEX: no real asset backs the positions. Trades settle against a gToken vault (gUSDC and others) that is the sole counterparty. The synthetic design allows unusually wide market coverage — crypto, forex, stocks, indices — because only enough capital to cover aggregate net loss is required, not real asset reserves.

Oracle pricing plus a spread above it compensates vault depositors for absorbing trader PnL. Gains Network TVL fell to around $14.4 million with roughly $726 million in 30-day volume as of May 2026, down sharply from prior peaks — an illustration of the headwinds pool-model DEXs face competing against fast orderbook venues.

Risks to Understand Before You Participate

The two architectures carry distinct risk profiles.

LP warning: Pool-model vault depositors do not earn a spread — they earn the losses of traders who lose. In sustained directional markets, that is a losing position. Understand this before depositing.

For CLOB participants, the main non-obvious risk is composability and systemic risk: smart contract vulnerabilities on the underlying chain or in cross-margin collateral flows can propagate across the stack in ways individual position sizing does not protect against.

Oracle risk is not exclusive to pool models either. Even CLOB venues use oracle feeds for funding-rate calculations and sometimes for liquidation triggers — a tampered feed can force liquidations that would not otherwise occur.

Choosing Between Them

Active traders generally benefit from CLOB venues: tighter spreads, transparent depth visible in the order book, and trading against professional counterparties who are themselves hedging. The infrastructure complexity is the protocol's problem, not the trader's.

Passive liquidity providers face a harder choice. Pool models offer yield without active quoting — but that yield is funded by trader losses. What DeFi actually is includes the reality that passive yield always has a source; in pool perp DEXs, that source is the trader base going net negative. Periods where traders win consistently erode the vault.

For the ecosystem as a whole, the bifurcation has infrastructure implications: CLOB growth requires specialised, high-throughput chains that make partial decentralisation trade-offs; pool models run on commodity chains but concentrate trust in oracle integrity.

Decentralised perps represent roughly 10% of total perp market volume (CEX plus DEX) as of early 2026, with orderbook venues capturing the bulk of DEX volume growth. The architecture that wins the remaining 90% will likely be determined by which design can match CEX performance without sacrificing the transparency that makes onchain trading meaningful.

Part 3 covers the Solana perps stack — Drift and Jupiter, which blend elements of both models on a high-throughput chain.

Key Takeaways

• Onchain perp DEXs split into two families: CLOB venues where traders match against each other, and pool/oracle venues where traders face a shared liquidity vault priced by an external feed.
• Hyperliquid's purpose-built HyperBFT L1 enables fully onchain order matching with sub-second finality and commands roughly 73% of decentralised perp DEX volume in 2026.
• Pool-model LPs are the counterparty to all traders in their market: they earn when traders lose and lose when traders win — passive yield has a directional cost that is hard to hedge.
• Oracle dependency is the pool model's structural vulnerability; a manipulated or stale feed can directly drain LP capital.
• CLOB venues generate genuine price discovery; pool venues are oracle-takers and contribute nothing to spot price formation.