How perpetual DEXs work

What "decentralised" actually changes

The trading experience on a perpetual DEX looks much like a centralised exchange: pick a market, choose leverage, open a position. The difference is where the collateral lives and who can move it.

On a centralised venue, deposits become a liability on the exchange balance sheet. Users hold a claim, not the asset. On a perpetual DEX, collateral sits in a smart contract whose rules are public and cannot be changed by a support team. That removes the counterparty risk that has repeatedly cost users money on centralised venues, and replaces it with smart contract risk and oracle risk instead.

It is a trade of one risk for another rather than the removal of risk.

Two designs for matching trades

Perpetual DEXs differ most in how they determine price and fill orders, and this is the distinction that matters most when comparing them.

Central limit order book

Bids and asks are matched the way a traditional exchange matches them. This gives tight spreads and familiar order types, but the book has to live somewhere fast enough to be usable, which is why several venues run their own chain or an off-chain matching layer with on-chain settlement.

Pool-based or oracle-priced

Traders transact against a liquidity pool at a price supplied by an oracle rather than against other traders. There is no book to fill, so execution does not depend on someone taking the other side, but liquidity providers absorb trader profit and loss and pricing depends entirely on the oracle.

Margin and leverage

Collateral deposited into the protocol backs positions. Initial margin is what is required to open a position; maintenance margin is the lower threshold below which the position is liquidated. Leverage is simply position size divided by margin.

Margin is either isolated, where each position has its own collateral and can be liquidated without touching the rest of the account, or cross, where the whole balance backs every position. Cross margin is more capital-efficient and more dangerous: one bad position can consume collateral supporting the others.

Oracles and the mark price

Liquidations cannot be triggered off the venue price alone, because a thin book can be pushed far from the real market by one large order. Protocols therefore compute a mark price — usually an index of external spot prices, sometimes blended with the venue price — and use it for margin calculations.

This makes the oracle a critical dependency. A manipulated or stale oracle can liquidate solvent positions or fail to liquidate insolvent ones, and most serious incidents at perpetual DEXs have involved pricing rather than the trading logic itself.

Liquidation and the backstop

When margin falls below maintenance, the position is closed by the protocol. Depending on the design this is done by permissionless liquidators competing for a fee, or by an internal mechanism that absorbs the position.

If a position is closed at a worse price than its remaining collateral covers, the shortfall has to be absorbed somewhere. Protocols maintain an insurance fund for this, and when that is exhausted the loss is socialised among profitable traders or liquidity providers. How a venue handles that shortfall is one of the more important things to understand about it and one of the least advertised.