Using Hyperliquid Sub-Accounts for Strategy Isolation and Risk Control

Sub-accounts on Hyperliquid are not a convenience feature — they are a first-class risk primitive. If you are running more than one strategy on the exchange and they share a single margin pool, you have coupled your risk in a way that will eventually hurt you. Here is how to use sub-accounts properly, what the mechanics actually look like on-chain, and where the trade-offs bite.

What a Sub-Account Actually Is

Each Hyperliquid sub-account is a distinct EVM address derived from your master wallet. The derivation is deterministic: the master wallet signs a structured message that encodes the sub-account index, and the resulting key controls an independent perp account. The critical property is that cross-margin does not bleed across sub-accounts. A liquidation on sub-account 2 has zero effect on the USDC held in sub-account 1. The exchange enforces this at the protocol level, not just at the UI level.

You can create up to 15 sub-accounts per master wallet at the time of writing. Each holds its own USDC collateral balance, its own open positions, and its own maintenance margin requirement. Funding accrues independently. From the protocol's perspective, sub-accounts are peers — there is no privileged relationship between the master and its children except for the derivation path.

Depositing and Withdrawing Between Sub-Accounts

Moving capital between sub-accounts goes through the L1 bridge — it is not an instant internal transfer. Budget for the standard Arbitrum One settlement time, which in practice means a few seconds to a few minutes depending on L1 congestion. The operational implication: you cannot rebalance margin between strategies in real time during a fast-moving market. Pre-allocate conservatively.

The recommended pattern for multi-strategy deployments is to keep a small USDC reserve in the master account and never trade from it. Use it solely as a staging area for deposits into sub-accounts. When a strategy winds down or needs capital repatriation, withdraw from the sub-account to the master first, then decide where it goes. This keeps your accounting clean and avoids the situation where you're trying to trace which sub-account funded which withdrawal on-chain.

Strategy Isolation in Practice

The primary reason to isolate strategies into separate sub-accounts is drawdown containment. A mean-reversion strategy on ETH-PERP can run at a different leverage ceiling and different max drawdown threshold than a momentum strategy on SOL-PERP. If they share margin, a bad day on the momentum leg can reduce available margin for the mean-reversion leg and force you into position reductions you never intended. Separate sub-accounts make those interference pathways structurally impossible.

The secondary reason is PnL attribution. When you have distinct sub-accounts per strategy, your daily PnL reconciliation is trivial: query the account equity at open and close of each session, subtract funding payments, and you have clean strategy-level returns. No allocation math, no position-level attribution heuristics. This matters significantly when you are running automated bots that need performance data to tune parameters — noise in the attribution bleeds into noise in the feedback loop.

A practical allocation example for a three-strategy shop:

• Sub-account 0: Funding rate arbitrage — lower leverage (2–3×), stable equity curve, widest collateral allocation
• Sub-account 1: Directional momentum — higher leverage (5–8×), tighter position limits, smaller collateral share
• Sub-account 2: Market-making / delta-neutral — moderate leverage, capital sized to max expected inventory imbalance

The percentages depend on strategy Sharpe and correlation, but the structure forces you to make explicit capital allocation decisions rather than letting a shared margin pool make them implicitly during a drawdown.

Risk Controls at the Sub-Account Level

Each sub-account can have its own liquidation threshold monitored independently. In production, this means running a separate risk watcher process per sub-account rather than one aggregated margin monitor. The advantage is that alert thresholds are calibrated to each strategy's expected volatility — a 15% margin utilization spike means something very different for a funding arb book than for a leveraged directional book.

One common mistake: setting maintenance margin alerts relative to total portfolio equity rather than sub-account equity. When strategies are isolated, the relevant risk metric is always sub-account margin ratio, not aggregate. Aggregating masks localized stress exactly when you need visibility most.

Hyperliquid's API exposes sub-account state cleanly via the clearinghouseState endpoint — you pass the sub-account address, not the master wallet. Polling frequency of 500ms per sub-account is well within rate limits for typical multi-strategy deployments.

Operational Overhead and When It Is Not Worth It

Sub-accounts add key management surface area. Each sub-account address needs to be treated as a hot wallet with signing capability, which means your key storage and signing infrastructure must support multiple independent keys. If you are running on a single VPS with environment variables for keys, the overhead is low. If your signing infrastructure involves HSMs or threshold schemes, multiplying that across 5+ sub-accounts has real operational cost.

The break-even point is roughly two uncorrelated strategies with meaningful capital. Below that threshold, the operational overhead of separate key management, separate monitoring processes, and separate deposit flows outweighs the risk isolation benefit. A single strategy, or two highly correlated strategies, is fine in one account with careful position sizing.

For anything more complex — multiple timeframes, multiple asset classes, or mixed directional and delta-neutral books — the isolation is worth every bit of the overhead. The first time a liquidation on one book would have blown up another book without isolation, you will not question the architecture again.

---

If you want this infrastructure designed and running in production without building it from scratch, reach out to TierZero — this is exactly the kind of system we build and operate.