How to Handle Order Sequencing vs Execution

​

Model three states instead of one

1. Treat request receipt as sequencing confirmation only.
2. Persist receipt identifiers, trader/strategy context, timestamps, and nonce immediately.
3. Track execution outcomes separately from sequencing receipts. Use ORDER_UPDATE, STRATEGY_UPDATE, and TRADER_UPDATE as the execution-state surfaces.
4. Treat checkpoint/finality progression as a third concern that matters later for settlement-sensitive behavior, not for immediate fill handling.

​

Run one client loop for receipts and another for outcomes

1. When a request is submitted, create a local record in a “submitted” or “awaiting sequencing” state.
2. When the request is acknowledged, move it to a sequenced/accepted state without assuming fill success.
3. Subscribe to the relevant realtime feeds and apply ordered updates as the authority for live execution outcomes.
4. Move the request to terminal status only when the update stream shows a terminal result such as full fill, cancellation, rejection, liquidation, or ADL-resolved closure.
5. After reconnects or uncertainty, reconcile the affected order and strategy state from REST plus the update-history surfaces before resuming normal live processing.

​

Guardrails that prevent bad state machines

• Never mark an order as filled only because the request was accepted.
• Keep idempotent update handlers keyed by stable order identity and lifecycle correlation fields.
• Distinguish rejection-at-admission from rejection-inside-lifecycle updates.
• Apply feed ordering according to the documented ordinal semantics, not local wall-clock arrival order.
• Reconcile strategy and trader updates alongside order updates when the request can affect balances, fees, liquidation state, or DDX balances.

​

What to do when something goes wrong

​

Next routes

• How to Track an Order Through Its Lifecycle
• Request Lifecycle: Sequencing, Execution, and Finality
• Realtime Connection Model
• Order and Account Event Reference