Skip to main content

Sign DerivaDEX requests with EIP-712

Use this when you need a clear implementation of the signing flow DerivaDEX expects. The examples use Python because the procedure is easiest to read there, but the same steps apply in any language that can build the same bytes and hashes. You need the chainId, the DerivaDEX verifying smart contract address, the exact request you plan to send, and the wallet key that controls the trader account. Use the network values you are signing for: After the signature is correct, move to How to Encrypt Requests for the Operator.

Follow the signing procedure

  1. Define the EIP-191 prefix.
  1. Build the EIP-712 domain separator from the chainId and the DerivaDEX verifying smart contract address. Use the same domain values for every request:
  2. Choose the request type you are signing, then build its message hash with the exact field order DerivaDEX expects.
  3. Compute the final digest as keccak256(EIP191_HEADER + domain_separator + message_struct_hash).
  4. Sign that digest with the trader wallet.
  5. Recover the signer locally before submission and confirm that it matches the trader wallet you expect.

Worked examples

Start with the helper functions that stay the same across request types. Each request type can be implemented in two ways here:
  • Direct implementation shows the hashing steps directly.
  • DDX client library shows the shortest path if you already use the library.
Both approaches should produce the same EIP-712 hash for the same input.

Example: sign an order request

This example follows the steps above for OrderParams.

Direct implementation

Example input:
For this input, the target result is:

DDX client library

If you already use ddx-python, this is the shortest path through the same procedure:
For this input, the DDX client library should return the same result as the native example above:

Sign the hash and recover the signer

Once the EIP-712 hash is correct, signing it is the short final step. This example uses a generated wallet only to show the mechanics:
The recovered address should match the wallet address that signed the hash. In production, use the trader wallet that is meant to authorize the request, not a generated example wallet. Use Signed Private Requests for the field tables behind cancel, cancel-all, profile-update, and withdraw request content.

Check your result before you submit

  1. Recover the signing address from the signature and digest.
  2. Confirm that it matches the trader wallet you expect to authorize the request.
If the recovered address is wrong, stop there. The operator will reject a signature that does not authorize the submitted request with SignedRequestAuthenticationFailed.

Appendix

Use this section when you need the exact field rules behind the steps and examples. Profile updates need three extra rules:

Continue with submission

After the signature is correct, fetch the operator key, encrypt the signed JSON, and submit the bytes to POST /v2/request. Use How to Encrypt Requests for the Operator for that step. If the request still fails after local recovery matches the trader wallet, use Error Reference for the exact rejection path.
Last modified on June 22, 2026