The Architecture of Hybrid Perpetual DEXs:
Off-Chain Matching vs. On-Chain Settlement

Decentralized perpetual exchanges do not all work the same way. The most capable platforms run on a hybrid execution model: orders are matched at speed by an off-chain engine, but funds never leave the blockchain. This split between execution and custody defines how such systems hold up under stress, who actually controls user funds, and how fast a forced liquidation can execute.

What Perpetual Contracts Actually Do

A perpetual contract tracks the price of an underlying asset — Bitcoin, Ether, or any listed token — with no expiry date. Traders hold long or short positions indefinitely, paying or receiving a periodic funding rate that keeps the contract price close to the corresponding spot market. Longs pay shorts when the contract trades at a premium; the flow reverses when it trades at a discount.

This mechanism removes the need for physical delivery or quarterly rollovers. The contract continues until the trader closes it or gets liquidated. That simplicity pushed perpetuals to the top of crypto derivatives by trading volume.

Futures contracts on early fully on-chain DEXs ran into a hard limit quickly. Every order submission, modification, or cancellation needed a separate blockchain transaction. On Ethereum mainnet, that means waiting several seconds per action and paying a gas fee regardless of whether the order fills or not — even an immediately cancelled limit order costs money.

Market makers — who post and retract hundreds of quotes per second — found those conditions unusable. Without their participation, bid-ask spreads widen dramatically. A venue with wide spreads and slow execution loses traders to competitors. The on-chain throughput ceiling was not something smart contract optimization alone could fix.

Trading Futures on a Hybrid Platform

Trading Futures on a hybrid platform starts with a signed order. The user’s wallet signs the trade parameters — asset, size, direction, price limit — and sends that signed message to an off-chain order book engine. The engine stores the message in memory, matches it against resting counterparty orders, and executes fills at sub-millisecond speeds without touching a smart contract at this stage.

The signature is the security anchor. The matching engine cannot change what the user agreed to. If it tried to fill an order at a worse price, the settlement contract’s signature check would reject the transaction outright. The matching engine controls execution speed, but it cannot steal funds or alter trade terms unilaterally.

What Happens at Settlement

When a position opens, closes, or gets partially reduced, the resulting change in fund ownership goes on-chain through a smart contract. That contract holds all user collateral in custody. The matching engine has no withdrawal access — it can only submit valid, signed trade records for the contract to process.

Settlement contracts enforce every position rule in code: maximum leverage, maintenance margin thresholds, liquidation eligibility. The code is public, and anyone can verify under what conditions a position gets force-closed and how collateral gets distributed afterward. This transparency is the property that distinguishes a true DEX from a centralized platform with decentralized branding.

Many platforms batch multiple settlement operations into a single on-chain transaction — processing 50 – 200 position updates at once rather than one by one — to reduce gas costs per user.

Margin Accounting and Liquidation

Hybrid platforms implement margin accounting inside the settlement contract. In cross-margin mode, a trader’s entire balance backs all open positions collectively. In isolated mode, each position has its own fixed collateral cap — losses on one trade cannot drain the funds reserved for another.

When a position’s margin ratio falls below the maintenance threshold, a keeper bot — an off-chain monitoring service — submits a liquidation transaction to the settlement contract. The contract validates the request and closes the position. Any remaining collateral after the liquidation fee returns to the trader. If the position went into negative equity before the keeper caught it, an insurance fund covers the shortfall.

AMM Pricing vs Order Book Depth

The alternative to an off-chain order book is an automated market maker. AMM-based perpetual platforms price trades algorithmically using pool composition or external oracle feeds. Liquidity providers deposit assets into pools; traders swap against those pools at prices determined by a formula.

AMMs handle any trade size without requiring active market makers. The cost is price impact: a 500,000 USDC trade on a pool-based platform shifts the execution price noticeably. On an order book DEX, the same trade fills against multiple resting limit orders at different price levels, producing less slippage when the book has sufficient depth. Which model suits a given use case depends on expected trade size and available market maker participation.

The Trust Assumption in Off-Chain Matching

Off-chain matching creates a trust assumption absent from fully on-chain systems. In principle, a matching engine can reorder transactions or prioritize specific users. The strongest countermeasure is a ZK-proof-based settlement layer: the engine generates a cryptographic proof that each batch of trades was executed correctly, and the settlement contract verifies that proof before accepting the state update.

ZK-proof generation adds latency — typically 1 – 10 seconds per batch — but makes execution tampering detectable by anyone who can read the proof. Platforms without ZK proofs typically publish signed order logs and periodic on-chain checkpoints as a lighter-weight alternative.

Liquidation Cascades Under Stress

Sharp price moves can trigger many liquidations near-simultaneously. Each forced closure adds directional pressure to the market, which pushes price further and activates more liquidations in a chain. This cascade dynamic affects both centralized exchanges and DEXs.

Tiered liquidation is the standard mitigation. Rather than closing a full position the moment it crosses the maintenance threshold, the engine reduces it by a fixed percentage first — typically 25 – 40% — to restore the margin ratio. Full closure only follows if partial reduction is insufficient. This staged approach limits the volume of forced selling at any single price level.

The Backend Services Layer

A production hybrid perpetual DEX backend consists of several loosely coupled services running in parallel. The order gateway accepts signed WebSocket messages from user wallets and routes them to the matching engine. The matching engine maintains an in-memory order book, executes fills, and streams events to downstream consumers.

The position manager tracks open positions, calculates margin ratios in real time, and applies funding accruals. A keeper service monitors position health and submits on-chain transactions for liquidations, funding payments, and state checkpoints.

The settlement contract ties all these services together as the authoritative record of fund ownership. Any service can fail and restart — positions and balances reconstruct from on-chain state, not from service memory. Decoupling execution speed from fund custody is what allows the system to process trades quickly without requiring users to trust any single off-chain component.