The question this page answers
This page explains why DerivaDEX needs both an operator-cluster consensus layer and a later checkpoint/finality layer. They solve different problems, and confusing them leads to incorrect expectations about receipts, settlement, and recovery.Why one layer is not enough
A fast trading venue needs durable agreement on request ordering before it can safely continue. A self-custodied venue also needs later settlement anchoring that is not just an internal database promise. Those are related needs, but they are not identical:- cluster-level consensus gives durable agreement inside the trading system,
- checkpointing and settlement finality anchor that evolving state outside the immediate operator runtime.
The operator-cluster role
The operator side needs a shared request history so the live system can keep sequencing and execution coherent across participating nodes. That is why public node documentation exposes Raft-related runtime constants and why request handling is described as durable before later lifecycle stages complete. The cluster layer is about keeping the exchange’s working history consistent enough to continue operating.The checkpointing role
Checkpointing solves a different problem: it ties the evolving off-chain trading state back to the settlement chain through signed state commitments and quorum-based submission logic. That later layer matters because DerivaDEX is not meant to ask users to trust only a transient operator process for settlement truth.Why builders should keep the distinction clear
For builders, the practical consequence is simple:- a receipt means the request crossed the platform’s sequencing boundary,
- execution updates describe what happened in the exchange state,
- checkpoint and finality progression matter later for settlement-sensitive outcomes such as withdrawal eligibility.
Why operators care about both layers
Operators care because the failure modes differ:- cluster-consensus trouble affects request durability and live coordination,
- checkpoint trouble affects later anchoring and settlement progression.
The tradeoff
This split introduces more conceptual overhead, but it removes a deeper contradiction. A platform that wants low-latency trading and externally anchored settlement should not pretend those are the same clock. DerivaDEX keeps them separate so clients can reason about each clock honestly.Sources
- How DerivaDEX Works for the hybrid-model overview
- Request Lifecycle: Sequencing, Execution, and Finality for the public lifecycle split
- Node Operations Reference for the public Raft and readiness constants
- Glossary for checkpoint and finality terminology