Hyperliquid vaults, wired end to end

How a USDC deposit becomes exchange-side exposure: the two execution engines, the bridge between them, and where the P&L settles. Every number below comes from the official docs.

Depositor USDC in, shares of P&L out HLP protocol vault · 0% fee User vault leader-run · 10% of profit order books · matching margin engine oracle liquidation engine ~200k orders / s · one-block finality HyperCore native L1 exchange engine Tokenized vault ERC-4626 · custom accounting Solidity contracts · own state blocks: 1 s / 3M · 1 min / 30M gas HyperEVM smart-contract layer CoreWriter 0x3333…3333 sendRawAction · delayed ~ s precompiles 0x…0800+ read Core state HyperBFT consensus HotStuff-derived · ~0.07 s finality · tolerates ≤ ⅓ malicious validators
USDC enters vaults on either engine, but every order still executes on HyperCore's books — the EVM side reaches them only through the bridge.

Where HLP's yield comes from

The protocol vault is a market-making and liquidation machine. It is community-owned: depositors share the raw P&L with no profit cut.

Market making bids & asks across every book Liquidations absorbs positions at distressed prices Fees & USDC Earn share of trading fees · supplies Earn HLP equity community-owned Depositors pro-rata P&L · 0% fee 4-day lock-up
The same machine is the risk: HLP is the counterparty to every trader on the venue.

How a user vault splits profit

Anyone can run one. The leader trades, depositors ride along, and the split is fixed by the protocol — worked through with real numbers:

Deposit 100 you own 10% of 1,000 Equity 1,000 → 2,000 your share is now 200 You keep 190 principal 100 + 90% of the 100 profit Leader takes 10 10% of profit · only above high-water mark
Guardrails: the leader must keep at least 5% of the vault as their own capital; deposits unlock after 24 hours; no entry, exit, or management fees.

The bridge, step by step

A tokenized vault on HyperEVM doesn't trade "in" the EVM — it asks HyperCore to trade. That request is a log, not a call, and the gap between the two matters.

Vault contract HyperEVM CoreWriter 0x3333…3333 Action queue on-chain delay HyperCore books · margin sendRawAction(bytes) ~47k gas · just emits a log enqueue action the EVM tx has already succeeded — not atomic execute a few seconds later orders & vault transfers · shown twice in explorer every block, in order: 1 · L1 block 2 · EVM block 3 · EVM → Core transfers 4 · CoreWriter actions

e.g. ID 1 limit order — price and size scaled ×10⁸  ·  ID 7 USDC transfer between the contract and its Core account

Reading Core state from Solidity

The reverse direction needs no bridge delay: read precompiles expose HyperCore state directly, guaranteed consistent with the moment the EVM block was built.

0x…0800Positionsize, entry notional, leverage, isolated margin
0x…0801Spot balancetotal, hold, entry notional
0x…0802Vault equitya vault's current holdings
⋮
0x…0807Oracle priceraw uint64 · scale by 10^(6−szDecimals) for perps
⋮
0x…080eBest bid / offertop of book, both sides
0x…080fMargin summaryaccount value, margin used, net position

Cost: 2000 + 65 × (input + output bytes) gas. Invalid input burns everything passed to the call frame — validate before you query.

The three vault types, side by side

HLPprotocol
User vaultleader-run
TokenizedHyperEVM
settles on
HyperCore, native
HyperCore, native
EVM ↔ Core bridge
fee
0%
10% of profit
set by builder
lock-up
4 days
24 hours
set by builder
constraint
community-owned
leader holds ≥ 5%
ERC-4626 interface

Failure modes worth memorizing

You are the counterparty

Every vault takes the other side of the venue's traders. March 2025: a trader manipulated price into a concentrated position and dumped it on HLP for a ~$4M loss. Leverage was capped afterward — 40× BTC, 25× ETH.

The bridge is not atomic

A CoreWriter call succeeds when the log is emitted, not when the action lands. Deposits, share mints, and trades from an EVM vault are eventually consistent — they can fail after the transaction that requested them has already confirmed.