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

One chain, two execution environments

Foundation

HyperCore holds the markets as native state and the HyperEVM runs contracts; one HyperBFT consensus orders both, joined by precompiles and CoreWriter.

Hyperliquid runs two execution environments on one chain.

  • HyperCore is the engine: order books, margin, matching and balances, written into the protocol.
  • The HyperEVM is a general-purpose Ethereum-style contract platform on the Cancun rules without blobs, with HYPE as gas.

One HyperBFT consensus orders both into what the docs call one state: no second ledger, so no bridging risk.

Say your contract reads a perp position through a precompile, then places an order through CoreWriter. The read returns inside the transaction. The order executes 0.35 to 0.51 s after the HyperEVM block (measured on mainnet, n=52).

Two bridges, one in each direction

Section titled “Two bridges, one in each direction”
HyperCore order books, margin balances, positions NATIVE STATE HyperEVM contracts, HYPE gas 1 s and 60 s blocks GENERAL PURPOSE read precompiles, 0x800 onward state as of HyperEVM block build CoreWriter, 0x3333...3333 runs after the HyperEVM block a refusal never reverts the sender HyperBFT one consensus, one ordering, one state
Reads return inside the transaction but reflect the moment the HyperEVM block was built. Writes land later and report nothing back.
Crossing Mechanism Carries
Read, HyperCore to contract precompiles: addresses that behave like contracts, from 0x0000000000000000000000000000000000000800 perp positions, spot balances, vault equity, staking delegations, oracle, mark and spot prices, the L1 block number, lending state, outcome status, as of the latest HyperCore state when the HyperEVM block is built
Write, contract to HyperCore CoreWriter: sendRawAction(bytes) on 0x3333333333333333333333333333333333333333, emitting a log orders, cancels, transfers, vault deposits, staking, lending, account mode changes, outcome operations, executed after the HyperEVM block as the contract’s own HyperCore account
Move, either way transfers, separate from both bridges: send a linked token to its system address, 0x20 then the big-endian token index (HYPE: 0x2222222222222222222222222222222222222222) the token, credited on the other side

A refusal is silent: the transaction succeeds, the log is emitted, gas is spent and the money stays put. Within a block: L1 block built, HyperEVM block built, HyperEVM to HyperCore transfers, then CoreWriter actions (execution order).

The numbers

Section titled “The numbers”

Measured values are from mainnet unless stated.

Crossing Direction When it lands Cost
Precompile read HyperCore to contract state as of HyperEVM block construction 2000 + 65 * (input_len + output_len) gas
CoreWriter order (action 1) contract to HyperCore 0.35 to 0.51 s after the HyperEVM block, measured, n=52 about 25,000 gas burned; about 47,000 for a basic call
CoreWriter spot send, USD class transfer, send asset (6, 7, 13) contract to HyperCore 0.006 to 0.46 s, measured, n=6 each as above
CoreWriter outcome split and merge (17) contract to HyperCore same block, 0.01 to 0.68 s, measured on testnet, n=6 as above
CoreWriter vault transfer (2) contract to HyperCore 4.05 to 4.10 s, measured, n=6 as above
Asset transfer HyperEVM to HyperCore same L1 block, right after the HyperEVM block similar to an ordinary token transfer
Asset transfer HyperCore to HyperEVM queued to the next HyperEVM block 200,000 gas at that block’s base fee, charged on HyperCore
Small HyperEVM block not applicable every 1 s 3M gas limit
Big HyperEVM block not applicable every 60 s 30M gas limit

Where the chain and the docs disagree

Section titled “Where the chain and the docs disagree”

Moving your tokens between the two

Section titled “Moving your tokens between the two”
  • A token sits in a HyperCore spot balance (trades on the books) or a HyperEVM balance (used by contracts). Moving it is a transfer, not a trade.
  • Anything on the HyperEVM, including moving back, needs HYPE there for gas. The HyperCore to HyperEVM leg is charged on HyperCore: in HYPE per the FAQ, or in the token sent when HYPE runs short (measured on testnet).

Three ways a crossing fails

Section titled “Three ways a crossing fails”
  • No history. Precompiles answer only at the latest block. Any explicit block number fails, including the current head.
  • You can never move 100 per cent to the HyperEVM. The 200,000 gas comes out of the HyperCore balance. On testnet, 99 of 100 USDC cost 0.000588 USDC; all 100 was rejected with “Insufficient USDC or HYPE balance for token transfer gas”.
  • Rounding is rejected, not burned. Where the HyperEVM has fewer decimals, as for USDC (8 on HyperCore, 6 on the HyperEVM), a HyperCore to HyperEVM amount not a multiple of 10^|evmExtraWeiDecimals| wei is rejected (5 of 5 cases), silently if sent from a contract. Floor first.

Writing a contract that crosses over

Section titled “Writing a contract that crosses over”
  • Read with a precompile, act through CoreWriter, verify with a precompile in a later block. Nothing is atomic across the two: see patterns and what one HyperEVM transaction can and cannot do.
  • The contract must be an activated HyperCore account before the HyperEVM block is built. Funding it by transfer in the same block still gets the action rejected.

The CoreWriter payload is a four-byte header plus the ABI-encoded fields:

byte 0      encoding version, 0x01
bytes 1-3   action id, big-endian (7 = USD class transfer)
bytes 4..   abi.encode(fields), no function selector

For each side in depth, see the HyperEVM and HyperCore; for silent failures at the boundary, see Footguns, measured.