For the complete documentation index, see llms.txt. This page is also available as Markdown.

Signatures

EIP-712 and EIP-191 signature specifications for gasless trading operations.

⚠️ SDK Coming Soon

We are developing an official SDK that will simplify signature creation and payload encoding. The manual signature construction detailed below will remain supported but is intended primarily for advanced integrations. Stay tuned for SDK updates!

All trading operations require cryptographic signatures using Ethereum's EIP-712 (structured data) or EIP-191 (simple message) standards.

Signature Standards

Operation
Standard
Struct
Domain

Place/Replace Order

EIP-712

Order

Vault

Cancel Order

EIP-712

OrderCancel

Vault

Deposits (Permit)

EIP-712

Permit (ERC-2612)

Token

Deposits (Vault)

EIP-712

Deposit

Vault

Withdrawals

EIP-712

Withdrawal

Vault

Leverage Updates

EIP-712

LeverageUpdate

Vault

Margin Transfers

EIP-712

MarginTransfer

Vault

Authentication

EIP-191

SimpleSignaturePayload

N/A

Mass Cancel

EIP-191

SimpleSignaturePayload

N/A


EIP-712 Domains

EIP-712 signatures require environment-specific domain configurations. See Getting Started - Chain Configuration for vault and token domain parameters.


V2 Signature Format

Payload Encoding

All payloads are now encoded with a type discriminator byte before being signed:

Type Discriminators:

  • 0 = PlaceOrder (Order struct)

  • 1 = OrderCancel

  • 2 = SimpleSignature

  • 3 = Withdrawal

  • 4 = LeverageUpdate

  • 5 = Permit (Deposit - Token domain)

  • 6 = Liquidation (system use)

  • 7 = Deposit (Deposit - Vault domain)

  • 8 = MarginTransfer

Encoding Example (TypeScript/ethers.js):

Important: You sign the original struct using EIP-712, but send the encoded payload with type byte in the request.

Request Format

All signed operations use a standard wrapper format:

Example (Order):


Operations

Orders

Struct:

Field Specifications:

  • account: Wallet address

  • market: Numeric instrument ID (e.g., 8 for NVDA)

  • size: Order quantity with sign indicating direction

    • Managed SL/TP orders (closePosition: true): Always 0 - server manages quantity based on position

    • Unmanaged SL/TP orders (closePosition: false): Signed quantity (positive for Buy, negative for Sell)

    • Regular orders: Signed quantity (positive for Buy, negative for Sell)

    • Scaled by instrument's quantity_precision

  • limitPrice:

    • All order types sign their execution-bound limit price in 18 decimals — including StopLoss and TakeProfit, which sign the limitPrice from the request (the trigger stays in stopPrice and is not part of the signature).

    • A signed limitPrice of 0 or U256::MAX (an unbounded order) is rejected at placement.

  • nonce: Millisecond timestamp (e.g., Date.now())

  • deadline: Unix timestamp in seconds (not milliseconds). Recommended: 30+ days for resting orders

  • flags: Encoded flags (see Flags section below)

Order Flags

The flags field encodes order metadata as a U256 bitmask:

Bit Layout:

  • Bit 0: Margin mode (0 = Cross, 1 = Isolated). Must match the request's marginMode; isolated orders draw on the market's isolated margin.

  • Bit 1: Reduce-only (0 = false, 1 = true)

  • Bit 2: Managed SL/TP (0 = unmanaged, 1 = managed)

  • Bits 3-7: Order type (5 bits = 32 types max)

    • 0 = Limit

    • 3 = StopLimit

    • 7 = StopLoss

    • 8 = TakeProfit

    • All other values are reserved for internal use and rejected at placement.

Encoding Example:

Examples

Limit Buy:

Immediate Sell (crossing Limit IOC):

Managed Stop-Loss (Long Position, closePosition=true):

Unmanaged Stop-Loss (Long Position, closePosition=false, 10 BTC):


Cancel Order

Struct:

Field Specifications:

  • account: Wallet address

  • market: Numeric instrument ID

  • orderId: The identifier the signature authorizes cancellation of. Please sign the same identifier sent in the cancel request — either the exchange order_id or your traderOrderId.

  • nonce: Millisecond timestamp

  • deadline: Unix timestamp in seconds. Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Order ownership is validated before cancellation.

Example

Deposits

Deposits require two signatures:

  1. Permit signature (ERC-2612, Token domain) - Approves token transfer

  2. Deposit signature (Vault domain) - Authorizes vault deposit

Permit (ERC-2612)

Struct:

Field Specifications:

  • owner: Wallet address

  • spender: Vault contract address

  • value: Amount in token base units (6 decimals for USDC, e.g., "1000500000" for 1000.50)

  • nonce: Token contract nonce (fetch from tokenContract.nonces(walletAddress))

  • deadline: Unix timestamp (seconds). Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Validation Rules:

  • value > 0

  • spender must equal vault contract address

  • deadline at least 1 hour in the future

The nonce must be fetched from the token contract, not generated as a timestamp. See Nonce & Rate Limits.

Deposit (Vault Authorization)

Struct:

Field Specifications:

  • account: Wallet address

  • amount: Must match Permit.value

  • market: Instrument ID of the isolated market for isolated margin; 0 for cross margin

  • flags: Margin mode flags (bit 0: 0 = Cross, 1 = Isolated)

  • nonce: Millisecond timestamp (different from Permit nonce)

  • deadline: Unix timestamp (seconds). Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Validation Rules:

  • amount must equal Permit.value

  • market and flags bit 0 must agree with the request's instrument/marginMode: market: 0 + bit 0 = 0 for cross, market = instrument ID + bit 0 = 1 for isolated

Example

Withdrawals

Struct:

Field Specifications:

  • owner: Wallet address (note: owner, not account)

  • amount: Amount in token base units (6 decimals for USDC, e.g., "500250000" for 500.25)

  • market: Instrument ID of the isolated market for isolated margin; 0 for cross margin

  • flags: Margin mode flags (bit 0: 0 = Cross, 1 = Isolated)

  • nonce: Millisecond timestamp

  • deadline: Unix timestamp (seconds). Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Validation Rules:

  • amount > 0

  • market and flags bit 0 must agree with the request's instrument/marginMode: market: 0 + bit 0 = 0 for cross, market = instrument ID + bit 0 = 1 for isolated

  • deadline at least 1 hour in the future

Example

Leverage Updates

Struct:

Field Specifications:

  • account: Wallet address

  • market: Numeric instrument ID

  • leverage: Desired leverage × 100

  • flags: Margin mode flags (bit 0: 0 = Cross, 1 = Isolated) — selects which mode's leverage to update

  • nonce: Millisecond timestamp

  • deadline: Unix timestamp (seconds). Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Leverage Encoding:

Desired Leverage

leverage Value

1x

100

5x

500

10x

1000

20x

2000

100x

10000

Validation Rules:

  • leverage ≥ 100

  • leverageinstrument.max_leverage × 100

  • market must be valid instrument ID

  • flags bit 0 must match the request's marginMode

  • deadline at least 1 hour in the future

Example

Margin Transfers

Move collateral between cross margin and a market's isolated margin. Signed over the Vault domain, payload type 0x08.

Struct:

Field Specifications:

  • owner: Wallet address

  • amount: Amount in token base units (6 decimals for USDC)

  • market: Instrument ID of the isolated market being funded or drained (both directions)

  • flags: Bit 0 carries the source account's margin mode — the account being debited: 0 for cross → isolated, 1 for isolated → cross. Must agree with the request's direction.

  • nonce: Millisecond timestamp

  • deadline: Unix timestamp (seconds). Must be at least 1 hour in the future (server minimum); recommended: 2 hours

Validation Rules:

  • amount > 0

  • market must match the request's instrument

  • flags bit 0 must match the source side of the request's direction

  • deadline at least 1 hour in the future

Example

EIP-191 Operations

EIP-191 uses simple personal message signing (personal_sign).

Message Format

Message construction:

Example:

Note: The deadline is part of the struct but not part of the signed message string.

Authentication

Used for WebSocket connection authentication.

Example

Mass Cancel

Cancels all orders, optionally filtered by instrument.

Example

Signature Validation Errors

Error
Description

SignatureError

Malformed signature bytes

IncorrectAddress

Recovered signer doesn't match claimed address

DeadlineExpired

Signature deadline expired

DeadlineTooSoon

Deadline below the server minimum: 1 hour for collateral ops, cancels, and IOC/FOK orders; 25 hours for DAY; 7 days for GTC/GTD

InstrumentNotFound

Unknown instrument symbol

InstrumentMismatch

Signed market ID doesn't match requested instrument

AmountMismatch

Signed amount doesn't match request

OrderSizeMismatch

Signed size doesn't match requested quantity

PriceMismatch

Signed price doesn't match request

OrderIdMismatch

Signed order ID doesn't match request

LeverageMismatch

Signed leverage doesn't match request

MarginModeMismatch

Signed margin mode doesn't match request

FlagMismatch

Signed flags don't match request

OrderTypeMismatch

Signed order type doesn't match request

ZeroAmount

Amount must be greater than zero

WrongSpender

Permit spender doesn't match vault address

LeverageBelowMinimum

Leverage must be ≥ 100

LeverageExceedsMaximum

Leverage exceeds instrument maximum

VaultAddressNotConfigured

Vault address not configured

TokenAddressNotConfigured

Token address not configured

DecodeError

Failed to decode payload

For complete error code reference, see Error Codes.

Last updated