The three clocks you must keep separate
DerivaDEX request handling has three distinct stages, and most client confusion comes from collapsing them into one:| Stage | What it means | What it does not mean |
|---|---|---|
| Sequencing acceptance | The platform accepted the request for ordered processing after admission checks | The order filled, the strategy reconciled, or settlement is final |
| Execution outcomes | Matching, cancellation, rejection, liquidation, and account-update effects occurred in live exchange state | A later checkpoint already anchored those effects on Ethereum |
| Finality and checkpointing | Settlement-sensitive state progressed through the later anchoring path | Every earlier trading event happened on-chain in real time |
Stage 1: sequencing admission
The first clock is request admission and sequencing. This is where the system validates signature recovery, replay-window freshness, duplicate/nonce policy, supported market, tick-size and notional rules, and collateral or solvency prerequisites. If the request passes those checks, it can be acknowledged and sequenced. That acknowledgement matters because it tells you the request crossed the platform’s admission boundary. It does not yet tell you what the trading result will be.Stage 2: execution outcomes
The second clock is the execution path inside the exchange state. That is where one request can turn into:- one or more
ORDER_UPDATEevents - strategy-level balance or funding changes through
STRATEGY_UPDATE - trader-level balance or profile changes through
TRADER_UPDATE - partial fills, terminal fills, cancels, rejects, liquidation effects, or ADL-related resolution
Stage 3: checkpointing and finality
The third clock is later settlement anchoring. This is where evolving off-chain state is tied back to Ethereum through checkpointed commitments and related finality progression. That later stage matters for settlement-sensitive meanings such as withdrawal eligibility and durable public verification. It is intentionally later than live execution, because DerivaDEX is not modeling each trade as an immediate on-chain transaction.Why client bugs happen here
Treating these stages as one state causes predictable mistakes:| Mistake | Why it is wrong | Safer model |
|---|---|---|
| Mark an order filled when the request is merely accepted | Sequencing only says the request entered ordered processing | Wait for execution-domain events |
| Rebuild state only from WebSocket arrival time | One connection’s arrival timing is not the authority | Use the documented ordering fields and reconciliation rules |
| Treat finality as immediate after execution | Finality-sensitive actions depend on later checkpoint progression | Keep settlement logic separate from fill logic |
| Ignore strategy and trader updates when reading order outcomes | Order effects can propagate into balance, fee, and liquidation state | Reconcile across ORDER_UPDATE, STRATEGY_UPDATE, and TRADER_UPDATE together |
Sources
- Request Signing Reference for sequencing-admission and replay-window terminology
- Realtime Connection Model for REST bootstrap, reconnect, and update-stream expectations
- Realtime Source Artifacts for canonical AsyncAPI ownership
- Order and Account Event Reference for the public reference summary of execution outcomes, liquidation-related account effects, and finalization terminology
- Ethereum Whitepaper for the blockchain-finality backdrop
Why the distinction matters by reader
- Builders need this distinction to avoid incorrect order-state machines.
- Traders need it to understand why receipts, fills, and withdrawal readiness are different checkpoints in one broader lifecycle.
- Operators and governance readers need it to reason about cluster durability versus later settlement anchoring.