Hyperliquid Vaults: Building a Copy-Trading Strategy Vault

A Hyperliquid vault is just a sub-account with a leader address, a shared PnL curve, and a rule that depositors get a slice of the equity proportional to what they put in. That's the whole abstraction. Once you internalize that, "vault development" stops being mysterious and becomes a fairly ordinary exercise: run your strategy on the vault address instead of your personal one, and the protocol handles accounting for everyone who follows you. The interesting parts are the mechanics around that shared curve — how the 10% profit share is computed, when depositors can leave, and what happens to your fills when the vault's balance is 3x what your backtest assumed.

This walks through the parts that actually bite you when you go from a private bot to a public vault other people trust with real money.

What a vault is, mechanically

When you create a vault on Hyperliquid you get a new address that holds its own margin and positions. You (the leader) must keep at least 5% of the vault's equity in it at all times — this is the skin-in-the-game rule, and it's enforced. You can't withdraw below that floor while the vault is public.

Depositors send USDC in and receive an internal share balance. There are no ERC-20 vault tokens here; the shares are tracked in the L1 state, not as a transferable token. Every deposit and withdrawal is priced off the vault's current equity, so a depositor who joins after a 40% drawdown buys in cheaper and rides the recovery — which matters more than people expect when you model returns.

Three constraints shape everything downstream:

• 1-day lockup. Deposits are locked for 24 hours before they can be withdrawn. This kills the "deposit right before a known catalyst, yank it after" gaming.
• Profit share is 10%, fixed, on the leader's take. The leader earns 10% of depositor profits. Not 10% of AUM, not a management fee — a performance fee, high-watermarked per depositor.
• The leader can't cherry-pick. Every position the vault holds is shared pro-rata. You cannot run a good book on the vault and a hedge on your personal account and call it strategy.

The profit-share math, because people get it wrong

The 10% is high-watermarked per depositor, computed at withdrawal. It is not a running fee skimmed daily. Concretely: a depositor who deposits 10,000 USDC and withdraws when their share is worth 13,000 has 3,000 of profit; the leader receives 300, the depositor keeps 12,700. If that same depositor had first dropped to 8,000 and climbed back to 13,000, the fee is still on 3,000 — the high-watermark is the deposit basis, and losses recovered aren't taxed twice.

The gotcha: because the watermark is per-depositor and priced at their entry equity, the fee you actually collect depends on when people joined relative to your equity curve. Model it as a stream, not a lump sum. A rough sketch of how I compute expected leader revenue when sizing a vault:

def leader_fee(deposit_basis, exit_equity_share, rate=0.10):
    profit = max(0.0, exit_equity_share - deposit_basis)
    return profit * rate

# Depositor cohort simulation
cohorts = [(10_000, 13_000), (25_000, 24_000), (5_000, 7_500)]
total_fee = sum(leader_fee(b, e) for b, e in cohorts)
# -> 300 + 0 + 250 = 550 USDC to the leader
# the underwater cohort (25k -> 24k) pays nothing

Note the middle cohort pays zero. Underwater depositors never contribute fees, and if they leave at a loss your 5% stake ate that loss alongside them. Your revenue is convex on performance and brutally sensitive to drawdowns — one ugly month can zero out a quarter of fee income because everyone's watermark resets relative to their own basis.

Wiring your bot to the vault address

If you already have a working strategy, the migration is small but not zero. The Hyperliquid Python and Rust SDKs let you specify a vaultAddress field on order actions so the exchange routes the fill to the vault's margin instead of the signing wallet. The signing key stays your leader key; the vaultAddress tells the L1 whose book to touch.

# hyperliquid-python-sdk
from hyperliquid.exchange import Exchange

exchange = Exchange(wallet, base_url, vault_address=VAULT_ADDR)
exchange.order("ETH", is_buy=True, sz=2.5, limit_px=3200,
               order_type={"limit": {"tif": "Gtc"}})

That single vault_address argument is the difference between trading your own account and trading the vault. If you're standing up the API plumbing from scratch, the tradeoffs between the two SDKs are worth reading first — I laid them out in our Python vs Rust guide for Hyperliquid API bots, and for a public vault the Rust path's lower tail latency starts to matter once AUM grows.

The subtle failure mode: your position sizing must be a function of vault equity, not a hardcoded notional. If your bot places 2.5 ETH orders because that's what you tested with 50k, it will place 2.5 ETH orders when the vault holds 2M, which is meaningless risk relative to AUM. Every size call should read live vault equity and scale. Pull equity from the clearinghouseState for the vault address on each rebalance and size off that.

Which strategies actually work in a vault

Not everything ports cleanly, because the vault shares one position book and depositors watch a public equity curve.

• Market making works well — it produces a steady, explainable curve depositors tolerate, and Hyperliquid's maker rebates flow to the vault. If you're building this, our Hyperliquid market maker service covers inventory-skew and quote-laddering for exactly this shared-book constraint.
• Directional perps are fine but the drawdowns are public and fee-punishing per the math above. A disciplined perps bot strategy with hard risk limits beats a discretionary one here.
• Funding-rate arb is the cleanest fit: low drawdown, high explainability, and depositors love a curve that grinds up. The mechanics of running it across venues are in our funding arbitrage between Hyperliquid and CEXes writeup, and we build the delta-neutral version as a funding arb service.

One strategy I'd steer people away from as a public vault is anything that carries hidden tail risk — thin-liquidity liquidation hunting, for instance. It backtests beautifully and then one gap-down hands your depositors a 30% loss they didn't sign up for. If you want that exposure, run it on your own account, not a vault where 200 strangers share the book.

Deploy checklist

Before you flip a vault public:

1. Fund the 5% leader stake and confirm it's above the floor after your first positions open.
2. Size every order off live vault equity, tested at 10x and 0.1x your seed AUM.
3. Add a kill switch that flattens the vault book on a max-drawdown breach — depositors can't, so you must.
4. Publish a plain-English strategy description. The HLP-style vaults that attract deposits are the ones people understand; if the curve is a black box, TVL stays flat. Our breakdown of how HLP-style vault strategies are built is a good template for what to disclose.
5. Instrument it. You want per-cohort PnL, current watermark distribution, and live drawdown on one screen.

That last point is where most solo operators lose the plot — they run the vault blind and only notice a problem when a depositor complains. If you'd rather see the whole book, the fee accrual, and every depositor's watermark in one place, that's exactly what we build with a trading dashboard.