On-chain order book, off-chain matching with on-chain settlement, or a pooled counterparty. Three designs behind perpetual DEXs, and what each costs in latency, trust and liquidation risk.
Perpetual futures are now the majority of on-chain derivatives activity, and almost every architectural argument about them reduces to one question: where does the order book live? The answer determines the latency budget, the trust assumptions, the MEV surface and how a liquidation behaves when the market moves faster than the chain.
Matching happens in consensus. Every order, cancel and fill is a state transition the validator set agrees on, which makes the book verifiable by anyone and removes the operator as a trusted party. The cost is that throughput and latency become properties of the chain itself, which is why this design tends to arrive with its own L1 rather than as a contract on a general-purpose network.
Order processing, matching, risk checks and sequencing run off-chain; validation and final settlement happen on-chain. Traders keep self-custody and settlement is verifiable, but the sequencer decides ordering — so the fairness question moves from "can the operator take my funds" (no) to "can the operator order my fill unfavourably" (a design and governance problem).
There is no book. A liquidity pool takes the other side of every trade at an oracle price, and liquidity providers absorb trader PnL. Execution is trivially simple and there is no matching latency at all, but the pool now carries directional risk, and the oracle becomes the single most attackable component in the system.
A market maker quoting a perpetual needs to cancel faster than the market moves against them. If cancellation requires a block, the effective spread widens to cover the block time — every maker prices in the risk of being picked off during that window. This is the mechanism behind most liquidity differences between venues, and it is not something incentives can paper over: you can subsidise makers, but you cannot subsidise away a structural adverse-selection cost.
That is the real reason the off-chain matching design keeps reappearing. It is not a philosophical compromise; it is an admission that cancel latency and settlement finality have different requirements and do not have to run at the same speed.
A perpetual has no expiry, so nothing forces convergence with spot except the funding rate — a periodic payment between longs and shorts that makes holding the crowded side expensive. Get the funding formula wrong and the contract drifts from its index, which is a slow failure rather than a loud one. It shows up as basis that will not close and a market makers quietly leave.
Funding is usually derived from the premium of mark price over index price, but the details decide behaviour under stress: how often it accrues, whether it is clamped, and whether the mark price is the book mid or an oracle. Each choice trades responsiveness against manipulability.
Liquidation is the only subsystem that must work precisely when everything else is degraded — high volatility, congested blocks, wide spreads, oracle lag. The engine has to decide a position is underwater, find a counterparty, and close it before the loss exceeds the collateral. If it cannot, the shortfall lands on an insurance fund, and if that empties, on other traders through socialised loss or auto-deleveraging.
Three failure modes recur:
The pooled model is the fastest route to a working venue and the hardest to scale safely, because pool risk grows with volume while oracle risk stays constant. Off-chain matching is where most serious venues land, because it isolates the latency-critical path from the settlement-critical one. A fully on-chain book is the strongest trust story and demands the most infrastructure.
None of these is a default. The decision follows from what the venue is for: retail directional flow, professional market making, or long-tail markets nobody else lists.
Users state an outcome and solvers compete to deliver it. How intent-based DEX design moves execution risk off the user, and what it demands of settlement, MEV protection and solver incentives.
8 min readSampleERC-4337 introduced smart accounts; EIP-7702 lets an existing account behave like one. What gas sponsorship, batching and recovery mean for teams shipping crypto products to non-crypto users.
7 min readSampleMatching latency and custody are the real dividing lines between centralised and decentralised exchanges, not ideology. How each choice propagates through architecture, risk and compliance.
8 min readSampleBring the problem, the constraints and the deadline. We will come back with an architecture and an honest view of effort.