Skip to content
TradePerpetuals9 pages
What a perpetual future isFoundationA perpetual future is a contract on an asset's price that never expires, kept close to that price by an hourly payment between longs and shorts.Contract specificationsPractitionerEvery Hyperliquid perp is a linear contract on 1 unit of its asset, defined by size decimals, maximum leverage, a margin table and a margin mode.FundingPractitionerFunding is an hourly payment between longs and shorts, set by how far the perp trades from the oracle price, that ties a contract with no expiry to its index.Margin: cross, isolated and margin tiersPractitionerMargin is the collateral behind a perp: initial margin to open, maintenance margin to stay open, shared in cross mode or ring-fenced in isolated mode.Leverage and liquidationPractitionerBelow maintenance margin, positions go to the order book as market orders; below two thirds of it, the liquidator vault takes them over.Auto-deleveragingExpertWhen an account goes below zero, auto-deleveraging closes the most profitable, most leveraged opposing positions at the previous mark price, leaving no bad debt.Hyperps and index perpetualsPractitionerHyperps fund against a moving average of their own mark price until spot trading exists; index perps track a formula the validators publish.AMM-priced perpetualsExpertSome perps price off a Uniswap V2 or V3 pool instead of exchange spot prices, and are isolated only, with margin locked in until the position closes.DelistingPractitionerWhen validators vote to delist a perp, positions settle at the 1-hour time-weighted oracle price before the vote and no new orders are accepted.

Sub-accounts

Practitioner

A sub-account is a separate HyperCore account with its own address, balances, margin and rate limits, signed for by a master account whose fee tier it shares.

A sub-account separates your strategies without splitting your fee tier or adding a key. On one address, two strategies share collateral, liquidation risk, a rate limit and a nonce set. A second wallet separates them but splits your fee-tier volume and adds a key to guard.

Say your master and one sub-account each trade 5M USDC of perps. Your fee tier sees 10M, and both pay at that tier. Each keeps its own address rate limit: 10,000 + 5,000,000 = 5,010,000 requests.

One master key signs for every sub-account

Section titled “One master key signs for every sub-account”

A sub-account has its own address and no private key. The master, or an API wallet the master approved, signs for it by naming it in the request.

  • Separate state: balances, positions, margin and liquidation. Under portfolio margin it’s its own portfolio, and it has its own account mode.
  • Transfers between master and sub-account name the sub-account and appear in the ledger as subAccountTransfer.
Item Value
Unlock $100,000 of volume
Sub-accounts at unlock up to 10
Each further sub-account 1 per additional $100M of volume
Maximum 50
API wallets start at 3 per master, plus 2 per sub-account (see API wallets for the conflicting figures)
Fee tier the master’s; sub-account volume counts toward it (fees)
Referral discount none: the clearinghouse treats sub-accounts as independent accounts (referrals)
Address-based rate limit separate: each counts as its own user, with a buffer of 10,000 requests plus 1 per 1 USDC traded (rate limits)

The docs give two conflicting API wallet allowances, and a live account has held 14.

What a sub-account separates, and what it doesn’t

Section titled “What a sub-account separates, and what it doesn’t”

Strategies. A sub-account’s liquidation can’t touch the master or a sibling. Unlike isolated margin, the whole balance is separate, not one position’s margin.

Modes. Market-make in standard mode, with no daily action cap, beside a unified or portfolio margin account for discretionary trades.

Books. Fills, funding and PnL history live per address.

Not separated: the fee tier, by design, and the master key. Losing that key loses every sub-account. Vault volume, by contrast, counts separately from the master for fee tiers.

  • Signing: master key or approved API wallet, with vaultAddress set to the sub-account (the field vaults also use). userSetAbstraction takes a sub-account as user (nonces and agents).
  • Nonces are per signer, not per account. One API wallet for several sub-accounts shares one nonce set and parallel processes collide; the docs recommend one API wallet per sub-account.
  • Reading: query the sub-account’s own address. An API wallet’s address returns an empty result.
  • Creating: createSubAccount returns the new address as data.
Request Returns
{"type": "subAccounts", "user": master} each sub-account’s name, subAccountUser, master, clearinghouseState and spotState
{"type": "userRole", "user": address} {"role": "subAccount", "data": {"master": "0x..."}} for a sub-account
{"type": "sendAsset", "hyperliquidChain": "Mainnet", "signatureChainId": "0xa4b1", "destination": "0x...", "sourceDex": "", "destinationDex": "spot", "token": "USDC:0x<32 hex token id>", "amount": "100", "fromSubAccount": "0x...", "nonce": 1760000000000}

fromSubAccount is the sub-account address, or an empty string from the master. usdClassTransfer appends subaccount:<address> to the amount, but it’s disabled on unified and portfolio margin accounts: use sendAsset with fromSubAccount. CoreWriter action 13 (send asset) has a subAccount field; a non-zero value sends from that sub-account.

For moving value between accounts, see Transfers and withdrawals; for the keys that sign, see API wallets and agents.