Skip to main content

Generate and use a session key

Use this when you want to sign requests from a key that is not your funded trader wallet, such as a trading process that should never hold the funded wallet’s key. A session key is a separate wallet the trader authorizes to sign a bounded set of trading actions until a chosen expiry. The trader wallet signs that authorization once; the session key then signs each request, so the funded wallet stays out of the per-request loop. You need the trader wallet key that controls the account, a separate session key wallet, an expiry as a Unix timestamp, and the set of actions the session key may take. Two keys play two roles. The trader wallet authorizes the session key once by signing a delegated-session payload. The session key signs each request it is scoped for, and that authorization travels inside the request as the sessionKeySignature. Signed Private Requests covers where that field sits in request content. Use the network values you are authorizing for:

Follow the session-key procedure

  1. Obtain the trader wallet key material. This is the funded account that authorizes the session and that the operator already recognizes.
  2. Generate a separate session key wallet. This key signs trading requests and never holds collateral.
  3. Choose an expiry as a Unix timestamp in seconds. The operator rejects the session key once that time passes.
  4. Choose the action scope: the actions the session key is allowed to sign. Scope codes are 0 unrestricted, 1 order, 2 modify-order, 3 cancel-order, 4 cancel-all.
  5. Sign the delegated-session payload — the expiry, the action scope, and the session public key — with the trader wallet to produce the sessionKeySignature.
  6. Include the sessionKeySignature in each request, and sign the request hash with the session key instead of the trader wallet.
  7. Recover both signers locally before submission.
A session key authorizes only the actions in its scope, and only until its expiry. To revoke one earlier, add it to the trader’s delegated-session deny list through a profile update; see Signed Private Requests.

Worked example

This example authorizes a session key for Order and CancelOrder, then signs an order with it. The sample keys and expiry are fixed only so the result is reproducible. In production, load your own trader and session wallets and set the expiry relative to the current time.

Example: authorize the session key

Authorizing session keys can be implemented in two ways here:
  • Direct implementation builds and signs the delegated-session payload directly.
  • DDX client library shows the shortest path if you already use ddx-python.
Both approaches produce the same sessionKeySignature for the same input.

Direct implementation

The domain helpers are the same ones used in How to Sign DerivaDEX Requests with EIP-712. The session-key payload adds its own struct hash on top:
Assemble the payload, sign it with the trader wallet, and encode the result. The encoded aclScope carries the action names, not the numeric codes:
For this input, the target result is:

DDX client library

If you already use ddx-python, one call signs and encodes the same payload and returns the session signer address alongside it:
session_key_signature matches the direct result above, and session_signer_address matches session_account.address.

Use the session key in a request

Build the request as you would in How to Sign DerivaDEX Requests with EIP-712, with two changes: set session_key_signature on the request, and sign the request hash with the session key rather than the trader wallet.
The order hash is the same OrderParams hash from the EIP-712 signing guide, because the sessionKeySignature rides in the request content rather than being folded into OrderParams. For these order fields that hash is 0x8d5950c5691e5c4054c537f8a7b14e33dee9222f34e98fe8120624d636e37ba5. For live submission with a session key tied to a funded trader wallet, hand the session account to the client as the local signer:

Check your result before you submit

  1. Recover the request signer from the order signature and confirm it is the session key, not the trader wallet.
  2. Recover the trader signer from the sessionKeySignature payload and confirm it is the trader wallet that authorized the session.
  3. Confirm the requested action is within the session key’s scope and that the expiry is still in the future.
A decode failure, an expired payload, or an action outside the scope returns SignedRequestAuthenticationFailed. A denied session signer returns Forbidden. See Error Reference for the exact rejection path.

Appendix

The sessionKeySignature is a CBOR-encoded map with a one-byte version prefix:

Continue with submission

Once the session key has signed the request hash and the sessionKeySignature is in the request content, encrypt and submit the request the same way as any signed request. Use How to Encrypt Requests for the Operator for encryption and submission to POST /v2/request. If the operator rejects a session-key request after local recovery matches, use Error Reference for the failure code.
Last modified on June 22, 2026