The platform model in one view
DerivaDEX is a hybrid derivatives exchange. It keeps custody and later settlement anchoring on Ethereum while moving sequencing, matching, and most live trading-state transitions into a faster off-chain path. That split exists because the system is solving several different problems at once:- protecting trader custody
- admitting and sequencing requests with low latency
- applying deterministic matching and risk rules
- publishing account and order outcomes fast enough for trading clients
- anchoring later settlement-sensitive state outside the immediate operator runtime
The system layers and their jobs
| Layer | Primary job | What public docs expose |
|---|---|---|
| Wallet and smart contracts | Hold user-controlled collateral and execute on-chain actions such as deposits, withdrawals, and governance interactions | Smart Contract Addresses and Core Contract Reference |
| Request admission | Verify signatures, replay-window fields, and request validity before sequencing | Request Signing Reference, REST Authentication |
| Confidential submission | Keep signed request bytes private until the operator can process them | Request Encryption Reference |
| Matching and risk engine | Apply deterministic price-time matching, solvency checks, liquidation rules, and ADL fallback | Trading Safeties and Guards, Margin Requirements |
| Public data surfaces | Expose snapshots, market data, and ordered account updates over REST and realtime | REST API, Realtime API, Order and Account Event Reference |
| Checkpoint and settlement layer | Anchor evolving state later through checkpointed commitments on Ethereum | Consensus, Checkpointing, and Finality |
What happens to one request
Read the lifecycle as six separate steps:- A trader prepares a request that identifies the trader, strategy, intent, nonce, and replay-window fields.
- The trader signs that request with EIP-712 semantics and, for private write paths, encrypts the signed payload for operator submission.
- The operator validates admission requirements such as signer identity, supported market, tick size, notional limits, collateral sufficiency, and replay-window freshness.
- If admitted, the request enters sequencing and then matching, where price-time priority, solvency constraints, self-trade prevention, liquidation handling, and ADL fallback determine the live outcome.
- The result becomes visible through REST snapshots and realtime event streams such as
ORDER_UPDATE,STRATEGY_UPDATE, andTRADER_UPDATE. - Later, the evolving exchange state is anchored through checkpointed settlement processes on Ethereum.
Why the architecture is split this way
DerivaDEX does not keep everything on-chain because perpetual trading depends on fast sequencing, frequent state changes, and bounded market microstructure. Pushing every step through blockchain timing would make execution quality, gas exposure, and visible pre-trade intent dominate the trading experience. It also does not keep everything off-chain because custody, later settlement truth, and governance-sensitive accountability would then rest too heavily on operator promises. The on-chain checkpoint layer is what keeps the public assurance story tied to Ethereum rather than to a private runtime alone. So the system deliberately separates:- fast-path trading mechanics
- public data visibility
- later settlement anchoring
What users get from this model
| Reader | Main benefit | Main discipline required |
|---|---|---|
| Traders | Low-latency order handling without per-trade gas costs | Understand that mark price, margin, liquidation, and settlement timing are not the same thing |
| Builders | Deterministic request and event semantics across REST and realtime | Separate sequencing receipts, execution outcomes, and later finality in client logic |
| Governance and compliance readers | Public safety controls plus an explicit settlement anchor outside the immediate operator runtime | Read explanation and reference together instead of looking for one monolithic policy page |
What this page does not claim
This page explains the operating model. It does not replace:- exact request schemas or transport fields
- exact error and retry behavior
- exact matching, margin, liquidation, or ADL constants
- legal, licensing, or private compliance guidance
Sources
- Request Signing Reference for request-admission and replay-window terminology
- Request Encryption Reference for encrypted-submission scope and wire-format summary
- Trading Safeties and Guards for sequencing, matching, liquidation, ADL, and system-guarantee facts
- Margin Requirements for solvency and threshold terminology used in the platform model
- Order and Account Event Reference for the public execution-outcome and reconciliation vocabulary
- Ethereum Whitepaper for the settlement-chain model behind checkpoint anchoring
- Intel SGX Developer Guide for trusted-execution terminology