Two layers, one exchange
DerivaDEX runs in two layers that stay in sync with each other. Ethereum holds collateral and anchors settlement. When you deposit USDC, the transfer is to an audited Ethereum smart contract that you can inspect directly. Withdrawals are Ethereum transactions. Governance votes are Ethereum transactions. The contract also serves as the registry for which operators are allowed to run the exchange and how much bond each of them has posted. A network of operators handles sequencing, matching, and risk. Orders, cancels, and other trade-path requests are sent to this network rather than to Ethereum. The operator network decides the order in which requests are processed, applies the matching engine, computes the mark prices that drive margin, updates margin and liquidation state, and emits the real-time feeds that trading clients watch. None of this writes to Ethereum at per-request cadence. The two layers are tied together by periodic checkpoints: approximately every ten minutes, the operators publish a hash of the exchange’s current state back to Ethereum. Those checkpoints are what make a withdrawal possible, and what let anyone verify independently that the operator network is telling the truth about balances. This is a different shape from most exchanges. A centralized exchange runs one database. An AMM runs entirely on-chain. An optimistic rollup runs off-chain and accepts rollbacks if challenged. DerivaDEX runs off-chain, but with two properties that keep the operator network honest: the code they run is attested by hardware, and the state they claim is periodically committed to Ethereum.What makes the operator network trustworthy
A network of machines running your order book is only as good as the trust you can place in those machines. DerivaDEX layers three mechanisms to earn that trust. Trusted execution environments. Every operator runs inside an Intel SGX enclave: a region of memory that the host operating system, the cloud provider, and even the operator running the node cannot read or tamper with. The enclave will only accept the specific build of code that governance has approved. Crucially, the enclave generates its own signing keys at startup, and those keys never leave it. What comes out of an enclave is signed by the exchange; what went into matching is the exact code the DAO agreed to run. Remote attestation on Ethereum. Before an operator can join the network, it has to prove to the Ethereum contract that its enclave is running the approved code, on approved hardware, from an approved manufacturer. The proof is a signed report from Intel’s Trust Authority service, verified on-chain and recorded in the operator registry. An operator that cannot produce a valid attestation cannot sign a receipt that anyone else will accept. Bonded registration. Operators post a DDX bond to participate, visible on-chain. The DAO can slash that bond if the operator misbehaves. The hardware and attestation already make successful cheating extremely difficult on their own; the bond adds an economic cost on top, turning “almost impossible” into “not worth trying.” Taken together, the operators are trustworthy for a specific reason: the hardware, the attestation chain, and the economic cost of cheating all line up in the same direction.Confidential requests and fair sequencing
One of the less obvious properties a derivatives exchange has to protect is the order in which requests are seen. If an operator could read your order before sequencing it, they could insert their own order first, or leak its contents to someone who would. This is the same failure mode that produces sandwich attacks and MEV extraction on public blockchains. DerivaDEX sidesteps this by encrypting every trade-path request before it leaves the client. The encryption is keyed to the sequencer’s public key, which is generated inside the enclave and attested on-chain. The untrusted parts of the operator stack (the web server, the database, the operating system) can see that a request has arrived, but cannot read its contents. Decryption only happens inside the enclave, and only after the request has been assigned its place in the sequence. The result is that ordering is determined before intent is known to anyone who could act on it. A malicious operator cannot front-run your order because they cannot see your order.What happens to one request
With the layers and the trust model in place, a single order traces a specific path. Each step crosses a different trust boundary: the client encrypts and signs the intent, the sequencer assigns it a place in the ordering, the matcher turns it into state changes, and Ethereum eventually anchors the result.- The trader prepares a request that names the trader, the strategy, the intent (place, cancel, deposit, withdraw), a nonce, and a replay-window timestamp. They sign it with EIP-712, an Ethereum standard that lets the wallet display the request’s named fields rather than a raw hex blob.
- The trader encrypts the signed bytes with the sequencer’s public key and sends the encrypted payload to the operator network over HTTP.
- Inside the enclave, the sequencer decrypts the request, validates its signature and its replay-window fields, and increments the global request index by one. It signs a receipt containing that index and returns it to the trader. At this point the request has a committed place in the sequence but has not yet been matched.
- The receipt is replicated across the operator network using Raft, a consensus protocol that keeps a cluster of machines in agreement on a shared log even if some of them fail. Once the receipt is replicated, no single operator can later claim the request was not received.
- The matching engine, also inside an enclave, processes the request against the book, applies margin and liquidation rules, and produces a list of state updates such as fills, margin changes, and order-book mutations.
- The state updates publish to realtime subscribers on the
ORDER_UPDATE,STRATEGY_UPDATE, andTRADER_UPDATEstreams within milliseconds of execution. - Roughly every ten minutes, the operators compute the hash of the entire exchange state, sign it, and publish it to the Ethereum checkpoint contract.
Checkpoints and withdrawals
A withdrawal is the one operation where the two-layer model is most visible to a trader. You cannot simply pull funds out of the exchange, because those funds live in the Ethereum smart contract, not on the operator network. The operator network has to tell the Ethereum contract that you are owed the funds, and the contract has to verify that claim. The mechanism is the same checkpoint that runs every ten minutes. Each checkpoint contains the root of a Sparse Merkle Tree: a commitment to the full exchange state — balances, open orders, strategies, positions, and everything else — compressed into a single hash, with the property that any individual entry can be proven to have a specific value (or to not exist at all) using a short proof against that root. To withdraw, the trader signs an intent that lands in one checkpoint, and then presents a Merkle proof against the following checkpoint showing that the withdrawal is valid against the state the operators themselves committed to. The contract checks the proof and, if it holds, releases the funds. This is what “settlement anchor” means concretely. The Ethereum contract does not rely on the operators’ word; it verifies a cryptographic commitment whose root the operators have agreed on and signed. If the operators ever disagreed with the on-chain state, they could not produce checkpoints that the contract would accept, and withdrawals would pause until the disagreement was resolved. The two layers, the attested operators, the encrypted requests, and the ten-minute checkpoint are one mechanism seen from four angles: a way to run an order book off-chain without asking anyone to trust that the off-chain part is being run honestly.How this connects to the rest of the docs
This page describes the operating model: how DerivaDEX runs, not why it was built this way. For the design rationale, including a deeper comparison against AMMs, optimistic rollups, ZK rollups, and centralized venues, see Why DerivaDEX Is Architected Differently. For specific mechanisms, the docs go into detail.- Trading Safeties and Guards enumerates the validation rules applied during admission and matching.
- Margin Requirements specifies the risk parameters used by the engine.
- Order and Account Event Reference describes the realtime events emitted when state changes.
- How to Sign DerivaDEX Requests with EIP-712 and How to Encrypt Requests for the Operator are the integration paths a client uses to hit the flow described above.
- Token Economy and Incentive Design explains how DDX coordinates governance, operator bonds, and trading incentives across the two layers.