Skip to main content

​
Before you sign

Use this guide when you are preparing a private DerivaDEX request such as an order, modify, cancel, withdraw, or profile update. Make sure you already know:
  • which request variant you are signing
  • which wallet controls the target trader identity
  • which strategy the request should affect
  • whether you are also carrying a delegated session payload

​
Sign the exact request you intend to send

  1. Build the request payload first, including the trader identity, strategy identifier where applicable, action fields, nonce, client_timestamp_ms, and recv_window_ms.
  2. Build the EIP-712 domain with the correct chain_id and verifying_contract.
  3. Encode the typed-data struct for the specific DerivaDEX request family you are submitting.
  4. Sign with the wallet that controls the target trader identity, or with the authorized delegated-session path when that flow is intentionally in use.
  5. Recover the signer locally from the signature and confirm it matches the intended trader identity before you submit anything.
  6. Freeze the signed payload bytes after local verification. If you change any signed field, rebuild and re-sign instead of mutating the request in place.
  7. Pass the unchanged signed payload into the encryption/submission flow for POST /v2/request.

​
Validate the request before submission

  • Ensure nonce is unique for the signer and request intent.
  • Ensure client_timestamp_ms and recv_window_ms are fresh and still consistent with the exact payload you signed.
  • Ensure strategy, symbol, and amount/price fields match the target order intent.
  • Ensure delegated-session fields are present only when the chosen request path actually supports them.

​
Common signing mistakes

FailureTypical causeRepair
SignatureRecoveryMismatchwrong account signed, or the submitted payload differs from the payload that was signedsign with the correct wallet and verify exact payload bytes before encryption
IllegalNoncenonce collides with replay-window or duplicate-state handlinggenerate a fresh nonce and rebuild the request
ExpiredTimestamp / FutureTimestampreplay-window fields were stale or too far aheadrefresh the request window and re-sign
SessionUnauthorizeddelegated-session proof was missing, invalid, or inconsistent with the requestrepair or rotate the delegated-session payload before retrying

​
What to log for debugging

When signing failures happen, log enough to distinguish payload mistakes from runtime issues:
  • trader address you expected to sign
  • request family and symbol/strategy context
  • nonce
  • client_timestamp_ms
  • recv_window_ms
  • whether a delegated-session payload was attached
Do not log private keys, raw secrets, or anything that would let another party replay the request.

​
What to do next

After signing succeeds, the next job is normally confidentiality and submission, not more payload mutation.

​
Next routes

Last modified on April 13, 2026