Skip to main content

​
Migrate the client in a controlled cutover

  1. Inventory the assumptions your current CEX client makes about accounts, positions, order lifecycle, and retries.
  2. Map those assumptions onto DerivaDEX strategy, sequencing, and settlement concepts.
  3. Rebuild the client around REST bootstrap plus realtime continuation.
  4. Run one bounded testnet cutover before moving any larger workflow.
  5. Keep the first release narrow until lifecycle reconciliation is stable.

​
Start with the model differences

Before changing code, classify these differences:
  • DerivaDEX trades through strategy-scoped collateral rather than exchange-custodied balances
  • sequencing acknowledgement, execution outcomes, and later settlement-related effects are distinct stages
  • mark price, margin, and liquidation controls are first-class safety inputs
  • realtime feeds continue state, but REST still owns initial truth bootstrap
If the old client assumes those are one state or one account model, fix that assumption first.

​
Rebuild account and position ownership

For the first migration pass:
  1. identify which wallet and strategy own the DerivaDEX workflow,
  2. map your current account-level risk checks to strategy-level collateral and exposure checks,
  3. move all hard-coded balance assumptions behind one DerivaDEX strategy-state adapter.
Do not scatter exchange-specific account assumptions through the new client.

​
Separate submission from lifecycle tracking

Rebuild the order path into two stages:
  1. request creation, signing, encryption, and submission
  2. lifecycle tracking through REST snapshots plus realtime updates
If your old client treated an immediate acknowledgement as final state, fix that before you port strategy logic.

​
Map your market-data path to DerivaDEX rules

When moving the market-data path:
  1. choose the minimum realtime feeds you need,
  2. treat mark price as the risk and liquidation anchor,
  3. keep local order-book usage separate from account-state reconciliation,
  4. design the reconnect path around REST bootstrap rather than WebSocket-only continuity.

​
Rebuild retries around DerivaDEX failure classes

Do not port generic retry logic unchanged. On DerivaDEX:
  • replay-window and nonce defects usually require request rebuild
  • SafetyFailure means repair first, not retry unchanged
  • rate pressure and readiness faults need bounded retry
  • lifecycle gaps should trigger reconciliation, not speculative local state updates

​
Cut over in one bounded workflow first

For the first live migration path:
  1. one symbol,
  2. one strategy,
  3. one submission path,
  4. one lifecycle monitor,
  5. one reconciliation loop.
Only add more symbols, concurrency, or strategy logic after that path is stable.

​
Boundary rule

This guide explains how to migrate the workflow. It does not act as the canonical source of truth for vendor-specific exchange APIs or for DerivaDEX reference contracts.

​
Next routes

Last modified on April 13, 2026