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

Measuring Hyperliquid: volume, open interest, users

Foundation

Public Hyperliquid figures disagree mostly because each counts the same fills differently; a number means something only with its rows and units.

Two dashboards can report one market’s volume over the same days, differ by tens of per cent, and both be right. They add up different rows. Before you quote a figure, know which rows it counts.

One trade writes two rows

Section titled “One trade writes two rows”

Every match writes two fills of equal notional sharing one tid: the taker’s (crossed: true) and the resting maker’s.

Say one trade of 1,000 USDC matches. Sum both rows → 2,000. Halve the sum → 1,000. Count each tid once → 1,000. Now say your archive kept only the taker row: halving gives 500, while counting each tid once, from whichever row exists, still gives 1,000.

One match one tid, notional N Taker row crossed: true, notional N Maker row crossed: false, notional N Sum every row: 2N the raw fill sum Halve the sum: N right only if both rows were recorded Count each tid once: N still right when one row is missing
Every match is recorded twice. Summing doubles it, halving assumes both records survived, counting trade ids does not.

Where most trades kept only one row, halving undercounts them by half. Check how many trades in your window have both rows.

Some fills are not trades

Section titled “Some fills are not trades”

On outcome books only Buy and Sell fills are matches. The rest cross no book:

  • Settlement fills: one per holder at settlement, paid from the collateral pot. The losing side’s has notional 0 and none carries a builder code; report them apart from trading.
  • Conversion fills: split, merge, negate and merge question, priced at 1/n. One dataset counts them as trading volume, another excludes them.

Six lenses on the same fills

Section titled “Six lenses on the same fills”

A lens is a rule for which fill rows to add:

Lens What it adds up What it answers
matched One notional per tid, attributed through the taker’s builder code How much money changed hands
routed Both rows of every trade whose taker used a builder code How much two-sided flow an app’s takers started
tagged Every row carrying builder code X, taker or maker How much flow carried an app’s code
buy_side Rows where the fill side is B Volume by the buyer’s record only
hm_headline All trading fill rows, divided by 2 The halving convention several public trackers use; network level only
hl_official Rows that paid a fee, plus winning-side settlement Hyperliquid’s own rule for outcome volume

At network level, tagged is effectively the raw sum of non-settlement fills. Officially, per the fee docs, outcome trades pay only when closing or settling and only fee-paying volume counts: minting and a match between two opening orders count nothing, however large, though row-counting lenses include them.

Open interest

Section titled “Open interest”

openInterest in asset contexts is in base units (coins or contracts), not dollars: multiply by markPx. An outcome’s open interest is each side’s circulatingSupply, and the sides need not match, so name the side or give both.

Addresses are not people

Section titled “Addresses are not people”

One person can run a master account, sub-accounts and vaults (each its own clearinghouse account) and API wallets (which only sign; querying one returns an empty result), and a HyperEVM contract can hold a HyperCore account. Address counts overstate people; signer counts count keys.

The numbers

Section titled “The numbers”
Measurement Value
Halved fill sum vs one count per trade, same outcome archive about $29.27M vs about $46M
Archived trades with only one of their two rows about 67%
Trades with both rows in one node-fill archive, 2 to 15 May 33.3% of 874k
Conversion fills (split, merge, negate) among outcome fills about 1 in 5
Inflation from mixing trading and settlement volume about $20M
Network tagged plus settlement vs the official statistics page within about 4%
Outcome pairs whose Yes and No supply differed 89 of 192
Fills per userFillsByTime response at most 2,000; only the 10,000 most recent are available

Computing each lens from fills

Section titled “Computing each lens from fills”

Every fill carries what a lens needs: tid, crossed (true for the taker), side (B buy, A sell), fee, the optional builderFee, and dir, which names conversions (Split Outcome, Merge Outcome, Negate Outcome, Merge Question) and Settlement.

matched     = sum of notional, one row per distinct tid
tagged(X)   = sum of notional over rows where builder = X
hm_headline = (sum of notional over all Buy and Sell rows) / 2
hl_official = sum of notional over rows with fee > 0
            + sum of notional over Settlement rows with notional > 0
  • Deduplicate on tid, never on hash: an order’s partial fills share a hash.
  • No public stream carries all fills. Per-user history comes from userFills and userFillsByTime; the public trades WebSocket channel names both counterparties as [buyer, seller].
  • Network-wide history is node fill data, node_fills_by_block, published by a non-validating node with the requester paying for transfer.

Checklist for stating a number

Section titled “Checklist for stating a number”
  1. Lens: rows, trades, halved rows or fee-paying rows.
  2. Exclusions: settlement; split, merge and negate conversions.
  3. Scope: validator-operated perps, HIP-3 perp dexes, spot, outcome markets, or all.
  4. Window: exact start and end, not “recently”.
  5. Open interest units: base units or dollars at mark; for an outcome, which side.
  6. Users: addresses that traded, held funds or signed.
  7. Source and gaps: API caps, archive completeness.
  8. Never compare numbers built with different lenses.

For where fills and archives come from, see Data: historical, node and explorer. For other claims to check before print, see Common misconceptions.