Skip to main content
All mutating operations — trading, withdrawals, leverage changes, position margin, account setup — flow through the same two service functions: createAction and executeAction. For trading actions, the Trading pages document the convenience wrappers (placeOrder, cancelOrders, etc.) that handle createAction, agent-signing, and executeAction automatically. Those wrappers are the supported public surface for trade dispatch — createAction/executeAction are documented here for completeness and for action types that don’t have a dedicated wrapper. Withdrawals and account setup use the same authorization model, but the SDK exposes higher-level helpers (withdraw, checkSetup / executeProviderSetupAction) that should be preferred. Session-only actions execute directly through the provider plugin and intentionally skip executeAction.

Pattern

  1. Create — call createAction() with the action type and params. Returns one or more ActionStep payloads. Each step’s shape depends on the action’s signingMethod: EIP-712 typed data, a WASM-signer blob, an EVM transaction, an HMAC request, a SIWE challenge, or a client-only session marker.
  2. Authorize — let the provider plugin sign or execute each step according to ProviderAction.signers and signingMethod. USER means a user-owned authorization path (usually the wallet, or a client-held provider session for session steps); SDK means the provider plugin completes the step internally. Use executeProviderSetupAction for setup steps instead of embedding scheme-specific logic.
  3. Execute — call executeAction() with signed EIP-712, WASM, EVM, HMAC, or SIWE payloads. A session step is completed client-side by the plugin and produces no signed step to submit.

createAction

Build action payloads for signing.

Parameters

Returns

CreateActionResponse{ actions: ActionStep[] }. ActionStep is a discriminated union by structural shape — the SDK dispatches to the correct signer based on which key is present. The variant that comes back is determined by the action’s signingMethod on the provider descriptor (see SigningMethod). Eip712ActionStep — EIP-712 typed-data flow (Hyperliquid; most actions): WasmBlobActionStep — WASM signer flow (Lighter): EvmTxActionStep — on-chain EVM transaction (e.g. Lighter deposit): HmacActionStep — provider request signed SDK-side with a client-held API key: SiweActionStep — ERC-4361 login challenge: SessionActionStep — provider-session request completed client-side. createDepositAddress carries a public { network: 'ethereum', symbol: 'USDC', depositDestination: { wallet: 'margin' } } policy marker; other session actions use an empty marker. Session steps are not sent to executeAction.
A single createAction call may return multiple actions. For example, placeOrder with a leverage param different from the current setting returns both an updateLeverage and a placeOrder step.

EvmCall

The txParams on the EVM-transaction step variants is an EvmCall:

executeAction

Submit signed action payloads.

Parameters

SignedActionStep is a discriminated union that mirrors ActionStep — each variant carries the original payload plus its signed artefact. Eip712SignedActionStep: WasmBlobSignedActionStep: EvmTxSignedActionStep:

Returns

ExecuteActionResponse{ results: ActionResult[] }: Each ActionResult:

Action Types

All action types from the provider’s setup, options, and actions arrays can be used with createAction/executeAction: For parameter schemas per action type, see Actions API. For the high-level convenience wrappers that handle agent signing automatically, see SDK / Trading. API Reference: POST /createAction, POST /executeAction