The question this page answers
This page explains why DerivaDEX is neither a pure on-chain exchange nor a pure off-chain exchange. The platform assigns off-chain request handling and on-chain checkpoint anchoring to different layers because they solve different problems.What each layer is doing
The public model is easiest to read as a split of responsibilities:- the off-chain layer handles request admission, sequencing, matching, and fast state transitions,
- the on-chain layer anchors later settlement, checkpoint evidence, and durable public verification.
Why not keep everything on-chain
A fully on-chain derivatives venue pushes every stage of order handling through blockchain timing and gas costs. For DerivaDEX, that would weaken the parts of the venue that need the tightest control:- request handling would inherit slower confirmation cadence,
- market microstructure would be shaped by gas and visible pre-trade intent,
- high-frequency strategies would spend more effort managing chain friction than market logic.
Why not keep everything off-chain
A purely off-chain venue has the opposite problem: it can be fast, but the public assurance story becomes weaker if settlement and later verification depend only on operator promises. DerivaDEX keeps the on-chain checkpoint layer because:- public readers need later state anchoring,
- settlement-sensitive actions need a durable reference point,
- governance and trust claims are stronger when important state transitions are eventually anchored outside the immediate runtime.
How the two layers stay aligned
The system contract is not “same layer, same time.” It is “different layer, different job”:- a request is admitted and sequenced,
- matching and account effects occur in the fast path,
- updates are emitted through the public account and order surfaces,
- later checkpoint processes anchor that evolving state.
What this tradeoff buys
The hybrid approach gives DerivaDEX a specific bundle of properties:- low-latency order handling compared with pure on-chain execution,
- stronger auditability than a venue that never anchors state outside its own runtime,
- better market-structure control for derivatives workflows that depend on sequencing, risk checks, and bounded execution guards.
What this tradeoff costs
The design also imposes discipline:- builders must separate fast acknowledgement from later finality,
- operators must respect the sequencing and checkpoint contracts,
- readers must not confuse on-chain anchoring with instant on-chain execution of every trading step.
Why this matters for different readers
- traders care because execution timing and liquidation safety depend on the fast path,
- builders care because transport, reconciliation, and finality are different concerns,
- governance and compliance readers care because the public assurance story depends on the checkpoint layer, not just on runtime claims.
Sources
- How DerivaDEX Works for the high-level hybrid overview
- Request Lifecycle: Sequencing, Execution, and Finality for the lifecycle split
- Consensus, Checkpointing, and Finality for the cluster-versus-settlement distinction
- Smart Contract Architecture and Upgrade Boundaries for the contract-layer boundary