Skip to main content
POST
Sub-account management uses the unified POST /order endpoint. Send a transaction with a single createSubAccount, renameSubAccount, or removeSubAccount action. Conceptual background lives on the Sub-Accounts page.
Sub-accounts are off-curve accounts. Their pubkeys are derived from the master and have no private key. Only the parent master can manage them.

Transaction Envelope

The account and signer must both be the master account that owns (or will own) the sub-account.

Create Sub-Account (createSubAccount)

Create a named sub-account under the signing master. Optionally seed it with margin in the same atomic action. Minimal (no initial margin):
With initial margin transfer:
When both marginSymbol and marginAmount are provided, the protocol creates the sub-account and transfers margin from the master atomically. The master’s withdrawable balance is checked before the transfer.
The newly generated sub-account pubkey is returned in the createSubAccount status row (see Response), so clients can use it immediately without waiting for an account refresh.

Remove Sub-Account (removeSubAccount)

Remove a sub-account and sweep any remaining margin back to the master. The sub-account must have no open positions and no open orders.
The same action also removes auto-created isolated accounts once they are flat (no open positions / orders).

Rename Sub-Account (renameSubAccount)

Update the display name of an existing sub-account owned by the signing master. The pubkey is unchanged, so cached references and isolated-account links keep working.
The signing master can also rename its sub-accounts via an authorized agent wallet, following the same envelope rules as other account-management actions.

Constraints


Response

Same OrderResponse envelope as other actions. Sub-account actions emit dedicated status rows:
The newly generated sub-account pubkey is returned in the createSubAccount status, so clients can use it immediately without waiting for an account refresh.

Listing Sub-Accounts

A master account’s fullAccount snapshot includes a subAccounts array of {pubkey, name?} rows. See Query Account for the full response shape.

Trading From a Sub-Account

Sub-accounts can submit any signed action (orders, modify, cancel, on-fill, conditional baskets, transfers, agent wallets, user settings) the same way a master does. There is no separate endpoint and no special action variant. To act on a sub-account, just set the transaction account field to the sub-account’s pubkey while the master signs:
Notes:
  • Margin, positions, open orders, fills, and risk for that transaction are evaluated on the sub-account’s balance sheet, not the master’s.
  • All conditional and on-fill follow-ups attached to a sub-account order stay on that sub-account.
  • Any other signer (not the master, not the sub-account itself, and not an authorized agent on either) returns unauthorized signer.
  • To route a sub-account order into a per-instrument isolated account attached to that sub-account, set i = true on the order action. The isolated-account pubkey is never set as account.

Before You Start

See Transaction Signing for how to sign requests.Nonce: use a unique value (e.g. timestamp in nanoseconds): BigInt(Date.now()) * 1_000_000n.

Body

application/json

Transaction with a single sub-account action

actions
(createSubAccount · object | renameSubAccount · object | removeSubAccount · object)[]
required

Must contain exactly one createSubAccount, renameSubAccount, or removeSubAccount action

nonce
integer<int64>
required
account
string
required

Master account public key (base58)

signer
string
required

Signer public key (base58)

signature
string
required

Ed25519 signature (base58)

Response

200 - application/json

Sub-account action accepted

status
enum<string>
Available options:
ok,
error
response
object