Action envelope, and the protocol re-verifies the signature before applying it. Four methods cover the distinct destinations:
private/transfer_spot
Move collateral between two subaccounts you own.
private/transfer_spot_external
Send collateral to a subaccount owned by a different wallet, bounded by your recipient allow-list.
private/withdraw
Withdraw collateral on-chain to an L1 recipient address.
private/transfer_positions
Move open positions between subaccounts, booked as an RFQ trade.
nonce, signer, signature, and signature_expiry_sec built exactly as described in Action signing. The action module for each flow is filled in by the server and does not appear on the wire — it is part of the signed struct hash and must match the deployment’s module address in Action signing.
Amounts, prices, and fees are human decimals on the wire — decimal strings (e.g.
"100.5") or JSON numbers. The
exception is private/withdraw, whose on-chain amount uses the asset’s native ERC-20 decimals (see below).Transfer collateral between your subaccounts
private/transfer_spot moves a spot balance from one of your subaccounts to another subaccount you own (existing, or a new one created in the same call). Positions are not moved by this method — use private/transfer_positions for that.
Required scope: transfer:existing_subaccount or transfer:new_subaccount (see Access scopes).
Transfer collateral to another wallet
private/transfer_spot_external sends collateral to a subaccount owned by a different wallet. The destination owner must be on the sender’s whitelisted-recipient allow-list, and the signing key needs transfer:different_owner_subaccount.
The parameters mirror private/transfer_spot, with one addition and one change in meaning:
Owner (wallet) of the destination account — must be whitelisted.
Recipient’s existing destination subaccount.
0 ⇒ create a new subaccount for the recipient.Manager id for the new subaccount when
to_subaccount_id == 0.subaccount_id, asset_name, sub_id, amount, max_fee_usd, nonce, signer, signature, signature_expiry_sec) are as in private/transfer_spot, and the response returns op_uuid and operation_id.
Managing the recipient allow-list
External transfers can only reach wallets you have explicitly whitelisted. Manage the list withprivate/update_whitelisted_recipients, itself a signed action requiring the admin scope.
The action carries an add set and a remove set; the new allow-list is (current ∪ add) \ remove. Removals are applied after additions.
Wallet whose allow-list is being updated; becomes the action owner.
Recipient wallet addresses to add.
Recipient wallet addresses to remove.
Strictly-increasing anti-replay nonce.
Address that produced
signature.0x-prefixed 65-byte EIP-712 signature over the update action.
Unix seconds after which the signed action is rejected.
Withdraw collateral on-chain
private/withdraw removes collateral from a subaccount and settles it to an Ethereum L1 recipient. It is a signed action requiring the withdraw scope.
Subaccount the collateral is withdrawn from.
Collateral asset to withdraw.
Amount in the asset’s native ERC-20 decimals.
Whether to force the withdrawal into a settlement batch.
Maximum sequencer fee, in USD, the signer authorizes.
Strictly-increasing anti-replay nonce.
Address that produced
signature.0x-prefixed 65-byte EIP-712 signature over the withdraw action.
Unix seconds after which the signed action is rejected.
The withdraw request does not carry an explicit L1 recipient field; the on-chain recipient in the signed action is
resolved server-side (e.g. from the wallet’s registered L1 address). Confirm the recipient resolution for your target
deployment against the API Reference tab before mainnet use.
Transfer positions between subaccounts
private/transfer_positions moves open positions from one subaccount to another. It is booked as an RFQ-module trade: both sides sign a transfer quote over the same legs, and the transfer clears at the agreed prices. The signing key needs a transfer:* scope covering the destination (transfer:existing_subaccount, transfer:new_subaccount, or transfer:different_owner_subaccount).
The request carries a maker_params and a taker_params object — each a signed transfer quote — plus wallet:
Wallet initiating the position transfer.
Maker-side signed transfer quote:
direction, legs, max_fee, subaccount_id, and the nonce / signer /
signature / signature_expiry_sec signing fields.Taker-side signed transfer quote over the same
legs, with its own max_fee and signing fields.max_fee. The response returns the resulting maker_quote and taker_quote.
The
legs fields for a transfer quote follow the RFQ leg shape; confirm the precise per-leg parameters against the
the API Reference tab. See RFQ for the underlying quote-signing mechanics.