Skip to content
DFUHL Docs
LearnStart here4 pages
How these docs workFoundationHow the site is organised by what you came to do, how every page runs from first principles to engineering detail, and where every fact comes from.Hyperliquid in five minutesFoundationHyperliquid is a set of financial primitives and protocols that combine into one financial system. Build a financial system from nothing, and each Hyperliquid protocol takes its place in it.The house of finance, layer by layerFoundationHyperliquid drawn as a house: one consensus, two engines joined by two bridges, an accounts layer, six financial pillars, a distribution layer that pays others to build, and Hyperliquid itself on top.Traditional finance, pillar by pillarFoundationEvery part of Hyperliquid has a traditional finance counterpart, and each analogy breaks in a specific place that shows what is actually new.
LearnFirst principles5 pages
Why Hyperliquid runs on its own chainFoundationHyperliquid built its own chain so that order books, margin and matching run fully on chain, in one consensus order, fast enough to trade on and with no off-chain book.One chain, two execution environmentsFoundationHyperCore holds the markets as native state and the HyperEVM runs contracts; one HyperBFT consensus orders both, joined by precompiles and CoreWriter.What an on-chain order book actually meansFoundationEvery order, cancel and fill is a transaction ordered by consensus and executed by every node, so the book is public chain state, not a private database.Ordering, finality and fairnessPractitionerHyperBFT gives every honest node one ordered list of committed rounds, a committed block is final, and each block runs cancels before GTC and IOC orders.HYPE: what the token doesFoundationHYPE pays HyperEVM gas, secures consensus, discounts fees, bonds deployers, backs borrowing, and is what the Assistance Fund converts fees into and burns.
LearnConsensus and validators4 pages
HyperBFTPractitionerHyperBFT is Hyperliquid's HotStuff-derived proof-of-stake consensus: stake-weighted validators commit rounds that every honest node executes in the same order.Validators and delegationPractitionerValidators run HyperBFT, ranked by stake; delegators choose them, pay commission, earn nothing while one is jailed and face no automatic slashing yet.Staking HYPE, rewards and the unstaking queueFoundationStaked HYPE is delegated to validators for compounding rewards and fee discounts; getting it back to spot takes a 7-day queue on mainnet.Running a nodeExpertA non-validating node follows consensus and writes every committed transaction, fill, order status, book change and HyperEVM block to local disk.
LearnHyperCore8 pages
HyperCore overviewFoundationHyperCore is where Hyperliquid's order books, margin, clearing and settlement run as native protocol state, applied by every validator in one order.The clearinghouse: one margin enginePractitionerHyperCore's clearinghouse holds balances and positions and checks margin on every trade; in standard mode each perp dex has its own balance and cross margin.The order book and matchingPractitionerEach HyperCore asset has one on-chain book matched in price-time priority, with cancels and post-only orders sequenced ahead of orders that take liquidity.Oracles, mark prices and robust price indicesPractitionerValidators publish perp oracle prices every 3 seconds; the mark price used for margin and liquidation is a median that no single book or venue can move.Quote assets: USDC, USDH, aligned and permissionlessPractitionerAny token can become a HyperCore quote asset if its issuer stakes 200k HYPE against a peg and liquidity standard; aligned issuers also share reserve yield.Vaults: HLP, protocol vaults, user vaultsFoundationA vault pools depositors' USDC into one HyperCore account run by one strategy; HLP is the protocol vault that makes markets and performs liquidations.Multi-sig accountsPractitionerHyperCore can make any account a native k-of-n multi-sig with no smart contract, but CoreWriter stops working for it and its HyperEVM side keeps the old key.API servers and how state reaches youPractitionerAPI servers follow a node, keep a local copy of HyperCore state, answer reads from it, and reply to a transaction only once it executes in a committed block.
LearnResearch5 pages
What one HyperEVM transaction can and cannot doExpertOne HyperEVM transaction can read HyperCore and emit a perp order and an outcome operation, but it only enqueues them, so the legs are not atomic.Options on the borrow rateExpertA research track priced the HyperCore USDC borrow rate with HIP-4 scalar bands, listed them on somebody else's perp, and found owning the perp does not pay.Composable creditExpertA research track tokenised HyperCore lending positions as HyperEVM ERC20s, proved a contract can supply on testnet, and found the vault must be a queue, not a wrapper.Collateral underwritingExpertA research track found the protocol refuses a deployer stake posted by somebody else, and rebuilt underwriting as two-of-two co-custody of the deployer's own bond.Where the chain and the docs disagreeExpertEvery place where measured behaviour on Hyperliquid contradicts the official docs: what the docs say, what was measured, the sample and the covering page.
LearnFor the press4 pages
Start here: press and analystsFoundationFor people writing about Hyperliquid: what it is, how to measure and name it correctly, and the stories behind the numbers.Measuring Hyperliquid: volume, open interest, usersFoundationPublic Hyperliquid figures disagree mostly because each counts the same fills differently; a number means something only with its rows and units.Common misconceptionsFoundationTwelve common claims about Hyperliquid that the official docs or on-chain measurement contradict, each with what is true and where it is explained.Naming and style guideFoundationWrite HyperCore, HyperEVM, HyperBFT, CoreWriter and HIP-1 to HIP-4 exactly, never shorten HyperCore to one word, and do not cite a HIP-5, because none exists.
LearnWhat Hyperliquid is and how it works
Start here
First principles
Consensus and validators
HyperCore
Research
For the press
TradeMarkets, margin and risk
Start here
Trading fundamentals
Perpetuals
Spot
Outcome markets
Accounts and credit
Advanced trading
Incentives
BuildApps, bots and contracts
Start here
Build on HyperCore
Build on the HyperEVM
DeployLaunch and run markets
Start here
The HIPs
Deploy markets
ReferenceEvery number, action and term
Look up
Protocol tables

The clearinghouse: one margin engine

Practitioner

HyperCore's clearinghouse holds balances and positions and checks margin on every trade; in standard mode each perp dex has its own balance and cross margin.

A leveraged position is a promise to pay, and the clearinghouse makes sure you can keep it. Perp books reference it inside HyperCore’s execution state, so margin check and match happen together, in consensus order.

Three margin numbers govern a position

Section titled “Three margin numbers govern a position”

Say you open 6,000 USDC of ETH perps, 2 ETH at a mark of 3,000, at 20x, the maximum.

  • Initial margin: 2 × 3,000 / 20 = 300 USDC.
  • Maintenance margin: half of that, 150 USDC. Below it, your cross account is liquidated at the mark price, not the last trade.
  • Before any transfer out: max(300, 0.1 × 6,000) = 600 USDC must stay.

Two ledgers per address

Section titled “Two ledgers per address”
  • Perps: balance and positions. Deposits credit cross margin first.
  • Spot: token balances and holds, including HIP-4 outcome positions (invisible to a perps clearinghouseState query).
  • Not collateral: staked HYPE (a separate staking balance) and vault equity. Each vault and sub-account is a separate clearinghouse account.

Each perp dex keeps its own ledger

Section titled “Each perp dex keeps its own ledger”

The clearinghouse is one design, not one pool of margin. Each HIP-3 perp dex has its own margining, order books and deployer settings; the validator-operated perps are the first dex. Account modes change how balances combine:

Mode Spot and perp balances Cross margin across perp dexes
Standard (also called manual) Separate perp and spot balances, and a separate balance per dex Only within one dex
Unified account One balance per asset, shared by spot and by every cross position collateralised in that asset Shared across dexes with the same collateral
Portfolio margin One portfolio across eligible assets (HYPE, BTC, USDC, USDT) Shared; see portfolio margin

In standard mode a profit on one dex does nothing for a loss on another, even in USDC: move collateral in first.

Margin is checked twice

Section titled “Margin is checked twice”

At placement, and again for the resting side at match, since the oracle price may have moved. A resting order that fails is cancelled as marginCanceled: acceptance does not guarantee a fill.

The numbers

Section titled “The numbers”
Quantity Rule
Initial margin position_size * mark_price / leverage
Maintenance margin half of the initial margin at maximum leverage
Margin required before any transfer out max(initial_margin_required, 0.1 * total_position_value)
Cross liquidation account value below maintenance margin times total open notional
User actions per day, unified and portfolio margin 50k
User actions per day, standard no cap
Portfolio margin eligible assets HYPE, BTC, USDC, USDT

Cross, isolated and unrealised profit

Section titled “Cross, isolated and unrealised profit”
  • Cross is the default and most capital-efficient. Isolated caps one position’s loss.
  • Strict isolated assets release margin only as the position closes; a HIP-3 dex may offer “no cross” (isolated, margin removable).
  • Unrealised profit on cross positions counts as initial margin for new positions; on an isolated position, only for that position.
  • Unified account shares margin across HIP-3 dexes with the same collateral.

Reading an account from code

Section titled “Reading an account from code”

clearinghouseState returns one perp dex’s view of an account: omit dex or pass "" for the first perp dex, else a HIP-3 dex name.

{ "type": "clearinghouseState", "user": "0x...", "dex": "" }

It returns assetPositions (each with szi, entryPx, leverage, liquidationPx, marginUsed, unrealizedPnl), marginSummary, crossMarginSummary, crossMaintenanceMarginUsed and withdrawable. Read liquidationPx; don’t recompute it.

Surface Use
spotClearinghouseState Spot balances and outcome tokens; under unified and portfolio margin, all balances and holds (per-dex perp states are then meaningless)
perpDexs Lists dexes; entry 0 is null, the first perp dex
sendAsset Moves value between ledgers: "" (first perp dex), "spot" or a HIP-3 dex name (transfers)
Precompiles 0x800 and 0x813 perp position, 0x801 spot balance, 0x803 withdrawable, 0x80F a dex’s margin summary

Mode rules that break transfers and fees

Section titled “Mode rules that break transfers and fees”
  • Under unified and portfolio margin, usdClassTransfer, spotSend and usdSend fail with “Action disabled when unified account is active”; use sendAsset.
  • A HyperCore to HyperEVM sendAsset must name "spot" as source; "" returns “Invalid token”.
  • Builder code addresses and market deployers must use standard mode, or builder fees do not accrue.
  • The discontinued DEX abstraction mode put USDC in perps and everything else in spot; the docs warn HIP-3 cross margin is unintuitive for accounts still in it.
  • Referral discounts do not apply to vaults or sub-accounts.

For tiers, see Margin. For choosing a mode, see Account modes.