The question this page answers
This page explains what “performance” means for a DerivaDEX strategy builder. It is not a benchmark sheet. It is a design reading of why the platform separates acknowledgement, execution, streaming state, and final settlement the way it does.Performance is not one number
For a strategy builder, the useful latency questions are different:- how quickly do I know my request was admitted to the system,
- how quickly do I observe execution outcomes,
- how quickly do I detect drift between my local state and exchange state,
- how long until final settlement-related effects matter?
Why acknowledgements and execution are separated
DerivaDEX separates sequencing acceptance from later execution outcomes because strategy code needs a fast admission signal without pretending that admission already means fill, cancel, or final settlement. That separation is performance-critical:- the fast path can acknowledge accepted work,
- the slower path can continue matching, risk checks, and downstream state updates,
- clients can build around those two timescales instead of blocking everything on the slowest one.
Why realtime streaming still needs REST bootstrap
Realtime feeds extend state. They are not a complete recovery surface by themselves. The performance reason for pairing WebSocket updates with REST bootstrap is simple: reconnects, dropped frames, and local process restarts are normal. A fast strategy is not one that ignores those cases. A fast strategy is one that restores a trustworthy state view quickly when they happen.Why low-latency systems still need guardrails
DerivaDEX does not trade safety for speed by removing constraints. Instead, it keeps performance and control aligned:- low-latency request handling still passes through validation and solvency checks,
- realtime flows still require explicit correlation and reconciliation,
- monitoring remains part of the runtime contract, not post-hoc observability decoration.
What strategy builders should optimize first
The first performance wins usually come from design hygiene, not clever math:- reduce unnecessary feed subscriptions,
- keep one clear state owner in your process,
- separate signal calculation from order submission,
- record enough metadata to reconcile quickly after disconnects,
- instrument the delay between data receipt, signal generation, submission, and observed execution outcome.
What this page does not claim
This page does not publish a guaranteed end-to-end latency target, and it should not be read as one. The public contract is about the platform’s latency-sensitive structure and the client responsibilities that follow from it.Sources
- What Is DerivaDEX? for the public low-latency platform framing
- Request Lifecycle: Sequencing, Execution, and Finality for the multi-stage state model
- Realtime Connection Model for the current public stream-control contract
- How to Monitor Trading Activity Reliably for the practical reconciliation posture