Hyperliquid Sub-Account Portfolio Hedging Strategy for Funds

Hyperliquid lets you spin up sub-accounts under a single master wallet, and each one gets its own isolated margin, its own position ledger, and its own set of API credentials. For a fund running three or four uncorrelated strategy books, that isolation is the whole point — a blowup in your momentum book can't liquidate your market-making inventory — but it also creates a problem most desks discover the hard way: you can be flat at the master level and dangerously long at the venue level, or the reverse. This piece is about running each book in its own sub-account and then netting the aggregate delta at the master layer, so your true exposure is a number you decide on rather than one you find out about.

Why sub-accounts, and where the naive setup breaks

The appeal is clean books. Sub-account A runs a BTC/ETH basis book. Sub-account B runs funding-rate carry across the top ten perps. Sub-account C is a discretionary override you keep for manual hedges. Each has isolated margin, so a margin call in B never touches A's collateral, and PnL attribution is trivial — no untangling which fill belonged to which alpha.

The break happens the moment two books take the same directional view. B goes short ETH to collect funding. A goes long ETH-PERP against spot for the basis. At the sub-account level both positions are individually correct. At the master level you're carrying near-zero net ETH, but paying two sets of taker fees, posting margin twice, and exposed to the funding you collect on one leg and pay on the other. Nobody planned that net position. It emerged.

So the discipline is simple to state and annoying to build: let each sub-account trade its own book freely, compute master-level net delta continuously, and decide deliberately how much of it to hedge.

The architecture: isolated books, one netting brain

The setup that has held up for us looks like this:

• N strategy sub-accounts, each with its own process and its own API wallet, trading only its mandate.
• One hedge sub-account whose only job is to hold the offsetting position the netting engine tells it to hold.
• One netting service that polls every sub-account's state, aggregates delta per asset, and rebalances the hedge account.

Hyperliquid's clearinghouseState endpoint returns positions per address, and each sub-account is addressable. You poll all of them, convert every position to a common numeraire (USD notional, signed), and sum by coin. That aggregate is the only number that matters for firm-level risk.

A worked example. Say the netting loop pulls this at a given tick:

sub-A (basis):    ETH  +$420,000   BTC  +$180,000
sub-B (carry):    ETH  -$310,000   SOL  -$95,000
sub-C (manual):   ETH  -$40,000
------------------------------------------------
net ETH  = +$70,000
net BTC  = +$180,000
net SOL  = -$95,000

Your firm is net long $70k ETH and $180k BTC despite three books that each feel hedged. If your mandate says stay inside ±$50k net per asset, the hedge account needs to short roughly $20k of ETH and $130k of BTC, and it can leave SOL alone. That is the entire job of the netting brain: turn a pile of independent books into three numbers and act on the ones that breach a band.

The netting loop, concretely

Here is the core of the aggregation, trimmed to the shape that matters:

import math

BANDS = {"ETH": 50_000, "BTC": 100_000, "SOL": 75_000}

def net_by_coin(sub_states):
    net = {}
    for st in sub_states:
        for p in st["assetPositions"]:
            pos = p["position"]
            coin = pos["coin"]
            notional = float(pos["positionValue"]) * (
                1 if float(pos["szi"]) > 0 else -1
            )
            net[coin] = net.get(coin, 0.0) + notional
    return net

def hedge_orders(net, hedge_now):
    orders = []
    for coin, exposure in net.items():
        band = BANDS.get(coin, 50_000)
        if abs(exposure) <= band:
            continue
        # hedge back to the band edge, not to zero
        target = math.copysign(band, exposure)
        delta = target - exposure          # what the hedge acct must add
        current = hedge_now.get(coin, 0.0)
        orders.append((coin, delta - current))
    return orders

Two decisions in that snippet earn their keep. First, hedge to the band edge, not to flat. Chasing zero net churns fees and fights your own alpha every time a book breathes. Second, positionValue and the sign of szi come straight off Hyperliquid's state — don't recompute notional from mark price yourself, because you'll drift out of sync with what the exchange thinks during fast moves.

The rebalance itself goes through the hedge account's API wallet as reduce-only or plain IOC orders. Keep the hedge account on cross margin even though your strategy accounts are isolated. The hedge book carries offsetting exposure against the whole firm; isolated margin there just invites a needless liquidation on a single leg while the other legs are deep in profit in accounts it can't reach.

Gotchas that cost real money

Polling lag is exposure. Hyperliquid's WebSocket pushes webData2 and fills faster than REST polling, and during a 3% candle the difference between a 5-second poll and a live feed is the difference between hedging the move and hedging its echo. Subscribe to fills per sub-account and keep the netting state event-driven; poll REST only as a reconciliation backstop every 30 seconds.

Funding is netted per account, not per firm. Each sub-account pays or receives funding on its own positions. When A is long ETH and B is short ETH, you receive on one and pay on the other, and unless the rates are identical (they are, on the same perp, same interval) you're roughly flat on funding but still double-paying the fee drag from holding both. Model the fee drag explicitly; it's the tax on running redundant legs, and it's the argument for occasionally internalizing an offset rather than hedging it externally.

API wallet scoping. Each sub-account needs its own agent wallet with trade permission, and Hyperliquid agent wallets expire. Rotate them on a schedule and alert loudly on a 401 from any leg — a silently dead hedge wallet means your netting brain thinks it's hedged when it isn't. This is exactly the class of failure worth a second set of eyes; a proper independent audit of the execution and risk paths catches the dead-wallet-looks-alive bug before it costs a drawdown.

Withdrawal and transfer settlement. Moving USDC between sub-accounts is instant on Hyperliquid, but the accounting isn't atomic with your position state. If you rebalance collateral to feed a hungry book mid-hedge, snapshot before and after or your net-delta math will briefly double-count.

When to net internally vs. hedge externally

If two books persistently offset — a basis long that's structurally opposite a carry short — you have a choice. You can hold both and pay the fee drag, or you can size the smaller book down and let the netting account carry the residual. The right answer depends on whether the two alphas decorrelate under stress. If they blow out together (they often do when funding spikes), the "hedge" was illusory and you want them genuinely independent. If they're stable offsets, internalizing saves fees. This is a modeling question before it's an engineering one, and it's worth pressure-testing in a dedicated strategy consultation before you wire the accounts together in a way that's painful to unwind.

The netting brain also wants a face. Per-account books mean nothing to a risk manager watching a dozen addresses; a consolidated exposure dashboard that rolls sub-account state into firm-level net delta, per-coin bands, and live funding drag is what turns this architecture from a script into something a desk can run at 3am.

The same "isolate the book, net the exposure" pattern shows up across venues. The rebalancing cadence maps closely to what we described for a Meteora DLMM fee-farming auto-rebalance bot, and the event-driven fill handling is the same discipline behind JIT liquidity provision on Solana. If your hedge account leans on conditional entries rather than continuous rebalancing, the mechanics in our writeup on recurring and trigger orders via Jupiter carry over almost directly.

Build the netting service first, run it in read-only observe mode for a week against your live sub-accounts, and only then let it place a single order — you'll learn more about your true firm-level exposure in that week than in any backtest. If you'd rather have the isolated-book-with-master-netting engine built and battle-tested for you, that's exactly what our Hyperliquid perps bot work covers.