Design a Crypto Derivatives DEX (Futures/Options)

Problem statement

Design a decentralized exchange where users trade crypto derivatives — perpetual futures as the primary instrument and cash-settled European options as the secondary instrument — without custoding funds to a company. Traders post collateral into smart-contract vaults, open leveraged positions up to a defined multiple, pay or receive a funding rate that pins the perpetual price to spot, and can be liquidated by anyone running a keeper when their margin falls below the maintenance threshold. Prices come from oracle feeds, not from a single venue, because a DEX has no authoritative last-trade price of its own underlying.

This is not a spot-swap problem scaled up. A spot AMM only needs reserves and a pricing curve. A derivatives venue needs four coupled subsystems that must agree at all times: (1) a position and margin ledger that computes equity, margin ratio, and PnL for every account on every price tick; (2) an oracle pipeline that produces a manipulation-resistant index price and a mark price used for liquidation and funding; (3) a liquidation engine that removes insolvent positions atomically and socializes any residual loss through an insurance fund and auto-deleveraging; and (4) a trading mechanism — central limit order book, virtual AMM, or counterparty pool — that discovers price and allocates liquidity.

Why the problem is distinctive

In equities or fiat futures, a clearinghouse guarantees settlement and regulators enforce margin. Here the smart contract is the clearinghouse, the oracle is the price authority, and anonymous keepers are the risk desk. Every one of those substitutions creates an attack surface: oracle manipulation (the Mango Markets incident moved a margin price with a borrowed pool), keeper starvation during volatility spikes, insurance-fund insolvency cascading into auto-deleveraging of profitable traders, and matching-engine front-running when order flow is visible before execution.

The attached brief requires smart contracts for positions, margin and PnL; oracle mark prices; a liquidation engine; and an advanced matching or AMM approach. It also demands security, scalability, reliability with no stuck or partial liquidations, and a compliance story for cross-jurisdiction volume.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. dYdX ran a zk-rollup hybrid order book (StarkEx) whose aggregator-reported daily volume reached high single-digit billions of dollars at the 2021 peak, then relaunched as its own Cosmos SDK appchain (dYdX v4) with fully on-chain matching. Hyperliquid reports an autonomous L1 with sub-second consensus and six-figure order throughput claims. GMX popularized the counterparty-pool model with peak TVL around 1.5 billion dollars and hundreds of billions of cumulative notional. Deribit, a centralized venue, still clears the large majority of crypto options volume, which is why decentralized options remain the harder half of this question. These are cited company or aggregator figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 2,000,000 registered wallets, 150,000 daily active traders, 40,000 concurrent WebSocket sessions at peak, 12,000 order messages per second sustained peak, 40 perpetual markets and 120 option series, and 3 billion dollars of daily notional. Unless a number is tied to a citation it is a stated design assumption, target, or budget.

The four architectural planes

1. Trading plane: order intake, matching or pool execution, fills, and market-data fan-out.
2. Risk plane: margin ledger, margin ratios, funding accrual, liquidation eligibility, insurance fund, auto-deleveraging.
3. Oracle plane: venue price ingestion, index aggregation, mark-price derivation, staleness and deviation guards.
4. Settlement plane: collateral vaults, on-chain state commits, event logs, reconciliation, and withdrawal finality.

A strong interview answer keeps these planes separate, states which parts are on-chain versus off-chain, and never lets a stale oracle price become a liquidation trigger.