Skip to main content
All mutating operations (orders, cancellations, setup, withdrawals) follow the same create → sign → execute pattern: createAction returns an actions[] array — each entry carrying its action type, a human-readable description, and the typedData to sign. Every typedData is signed (by the USER wallet or the AGENT, depending on the signing mode), and the signed array is submitted back to executeAction. This mirrors the Performing Trading Actions schema on the overview page.

​
1. Create

Call the create endpoint (/createAction) with your parameters. The backend returns an actions[] array, where each action contains:
  • action — The action type (e.g., placeOrder, updateLeverage, placeTriggerOrder, cancelOrder, modifyOrder)
  • typedData — EIP-712 typed data to sign (for Eip712ActionStep — the variant used by Hyperliquid and other EVM dexes)
Other actions return a different ActionStep variant — a WasmBlobActionStep carrying wasmSignParams, or an EvmTxActionStep carrying txParams. The SDK selects the correct variant from the action’s signingMethod (advertised on GET /providers).

​
2. Sign

Sign each typedData payload. Who signs depends on the action category:
  • Trading actions (placeOrder, cancelOrder, modifyOrder, placeTriggerOrder, updatePositionMargin, updateLeverage) — signed by the SDK-managed agent (or, on Lighter, by the registered API key). The user’s wallet is not involved.
  • Setup actions (approveAgent, approveBuilderFee, approveReadOnlyToken, the L1 half of registerApiKey, deposit) — signed by the user’s L1 wallet. These are one-time per account.
  • Options actions (accountMode, accountType) — post-setup tuning; never gate trading. accountMode accepts either USER or AGENT signers — the backend dispatches to the appropriate typed-data builder based on which key signs.
  • Withdrawals and sendAsset — the signer depends on the provider’s signing model (user’s L1 wallet on some providers, the SDK-managed signer on others). See each provider’s section.
The SDK’s high-level methods (placeOrder, cancelOrders, modifyOrders, …) handle trade signing automatically. The setup helpers (checkSetup, executeProviderSetup) coordinate user-wallet signing for setup actions.

​
3. Execute

Send the actions[] array to the execute endpoint (POST /executeAction). Each element is an object containing the action type, the original typedData, and the signature. 
// Each signed action has this shape:
{ action: 'placeOrder', typedData: { ... }, signature: '0x...' }
A single create call can return multiple actions. For example, placing an order with TP/SL and a leverage change produces updateLeverage, placeOrder, and placeTriggerOrder actions — all must be signed and submitted together. Similarly, modifyOrder with multiple modifications produces one modifyOrder action per order being modified.