Hyperliquid combines an onchain order-book exchange with its own Layer 1 blockchain. To assess it, separate four questions that dashboards often blur: how orders are matched, what traders pay, where collected fees go, and whether validator economics support resilient consensus. This reference reflects official Hyperliquid documentation checked September 30, 2026; fee schedules and protocol parameters can change, so verify the live documentation before relying on exact terms.
| Question | What to inspect | Useful caution |
|---|---|---|
| Does the order book have depth? | Spread, cumulative size at several price levels, and estimated slippage for your order size. | Displayed depth can change or cancel before execution; a narrow spread at the top does not guarantee a large order can fill near mid-price. |
| What will a trade cost? | Maker or taker status, product-specific fee schedule, your current tier, rebates, and any builder or deployer fee. | Funding is a separate peer-to-peer payment on perpetuals, not a protocol fee under the documented model. |
| What does “revenue” mean? | Gross trading fees, fee allocations, maker rebates, HLP results, and token burns as separate line items. | Trading volume is not revenue, and HLP profit and token burns are not interchangeable with cash income to a token holder. |
| How secure is consensus? | Stake distribution across active validators, uptime or jailing, validator concentration, and the current withdrawal queue. | Staking has withdrawal delay and validator-performance risk; the staking docs currently say automatic slashing is not implemented. |
Hyperliquid’s HyperCore maintains spot and perpetual order books as part of chain state. Official documentation says orders use price-time priority, with prices and sizes constrained by each asset’s tick and lot sizes. For perpetuals, orders interact with a clearinghouse that performs margin checks when a new order is opened and again when a resting order matches. The system is built around HyperBFT consensus and a shared transaction order rather than a separate offchain order book.
One implementation detail matters when interpreting execution: the documented transaction ordering groups actions in a consensus batch. Actions that do not submit orders are processed first, then cancellations, then actions submitting GTC or IOC orders; actions within each group follow the proposer’s order. This is a protocol rule, not a promise that every trader gets identical latency or that cancellations always succeed before a competing trade under every circumstance. For a specific strategy, test order behavior against the order-book documentation and the live API, and account for latency, partial fills, and changing depth.
When evaluating liquidity, compare the best bid and ask, then examine cumulative depth at multiple distances from the mid-price. Estimate the average execution price for the size you intend to trade. A single “spread” number or order-book snapshot cannot show how the book behaves during volatility; track depth and slippage over time and across active and quiet periods. Hyperliquid’s official Info API documentation describes the market-data and order-book interfaces available for independent checks.
A maker order rests on the book and adds liquidity; a taker order executes against resting liquidity. Hyperliquid documents different fee schedules for spot and perpetual trading, with fee tiers determined from rolling 14-day volume and assessed at the end of each UTC day. Perp and spot volume contribute to one tier, while spot volume counts double for the volume calculation. Subaccount volume is aggregated with its master account; vault volume is treated separately. Maker rebates, where applicable, are paid to the trading wallet on each trade.
Do not quote one fee rate as universal. The applicable rate can depend on product, fee tier, maker or taker execution, staking discounts, referral terms, aligned quote assets, and HIP-3 market settings. HIP-3 markets can also have deployer-configured fee shares. The fee table and terms are living parameters: check the current Hyperliquid fee schedule before calculating a trade. For a realistic estimate, apply the current rate to expected filled notional on both entry and exit, then include funding and likely slippage separately.
Perpetual funding helps keep a contract price aligned with its underlying reference. Hyperliquid’s docs describe funding as paid by one side of the contract to the other; no protocol fee is collected on the payment. The payer can change with the rate’s sign, and the published rate is not a guaranteed yield. Include the expected holding period and possible rate changes when comparing a perp position with a spot position. See the current funding documentation.
Notional volume is trading activity, not revenue. A rough gross-fee estimate requires executed volume by product and fee class, multiplied by the actual rates after tiering. A better net estimate then accounts for maker rebates, referrals, builder fees, and market deployer shares where applicable. Data providers may use different scopes, time windows, and accounting treatments, so label any estimate with its source, period, and assumptions.
Hyperliquid’s current fee documentation says collected fees are directed to community-related destinations, including HLP, the Assistance Fund, and eligible deployers. The docs describe the Assistance Fund as converting trading fees to HYPE and burning that HYPE automatically. This token burn is a supply mechanism; it is not a cash dividend or a claim on protocol revenue for every HYPE holder. Do not equate the dollar value of burned tokens with distributable earnings.
HLP is a protocol vault that provides liquidity through market-making strategies, participates in liquidations, supplies USDC in Earn, and accrues a portion of trading fees. Community depositors share the vault’s profit and loss. Consequently, HLP performance reflects both earned fees and market-making, liquidation, and inventory outcomes; it can gain or lose value. Read the protocol vault documentation before treating HLP returns as a stable revenue stream. The documented HLP deposit lockup is four days after the most recent deposit; confirm the live rule before using the vault.
Hyperliquid uses HyperBFT, a proof-of-stake consensus protocol inspired by HotStuff. Validators produce blocks in proportion to their delegated HYPE stake. The official staking documentation says a validator needs 10,000 HYPE self-delegated to become active; it also describes one-day delegation lockup and a seven-day queue when transferring HYPE from staking back to the spot account. These figures are operational terms that can change. Check the current staking page and queue state before committing capital.
The same documentation defines a consensus quorum as validators holding more than two-thirds of total stake and says an honest quorum is required for consensus. This makes stake concentration and validator independence relevant metrics: a long list of validator addresses does not by itself prove that control, infrastructure, or operators are independent. Review the share held by the largest validators and any known common operators or hosting dependencies; public data may not fully identify beneficial control or shared infrastructure.
Liveness is a separate issue from malicious behavior. The docs say validators can vote to jail peers that fail latency or message-frequency requirements; a jailed validator stops participating and its delegators do not earn validator rewards while it is jailed. The staking page currently states that automatic slashing is not implemented and describes slashing as reserved for provable malicious behavior such as double-signing. This means “no automatic slashing” should not be read as “no risk”: delegators can still face missed rewards, price volatility in HYPE, concentration risk, operational failures, delayed access during the unstaking queue, and protocol or software risk. Verify the current rule and the validator’s recent performance rather than relying on a token’s advertised staking rate.
| Metric | Interpretation | Common trap |
|---|---|---|
| 24-hour notional volume | Recent trading turnover; useful for activity and fee estimation when broken down by product and rate. | It can spike during volatility or incentives. It does not show unique users, retained demand, or net revenue by itself. |
| Open interest | Outstanding perpetual exposure, typically reported in underlying units or a notional equivalent. | It is not exchange cash or collateral. Compare with liquidity, margin rules, and changes in the mark/reference price. |
| Spread and book depth | Near-term quoted liquidity and estimated execution capacity at a given snapshot. | Quotes can move or disappear; check several price bands and measure realized slippage for actual order sizes. |
| Funding rate | Current or historical payment direction and rate between long and short positions. | It is neither protocol income nor a guaranteed recurring return; it can switch sides and change quickly. |
| Fees, HLP PnL, and HYPE burns | Three different views of fee generation, vault performance, and token supply reduction. | Do not combine them into one “revenue” number without a defined accounting basis. |
| Validator stake and jailing | Consensus-weight concentration and validator liveness signals. | Address counts do not establish independent ownership, and an unstaking queue affects liquidity. |
The Info API exposes fields such as day notional volume, open interest, funding, mark price, oracle price, and impact prices. Use the perpetuals API reference to confirm field meanings and units. For historical analysis, account for data coverage: Hyperliquid says its public archive is updated approximately monthly, with no guarantee of timely or complete updates. Preserve your own time series if you need continuous book-depth or execution-quality comparisons; see the historical-data notes.
Learn how Filecoin’s FVM and FEVM relate to storage deals, when to use direct deals or managed tools, and which metrics reveal real network demand.
Understand how Lido’s stETH rewards accrue, what validator concentration means, and how to choose between the withdrawal queue and selling stETH.
Understand how Rocket Pool minipools pair operator and pooled ETH, why rETH can trade away from its protocol exchange rate, and how to assess operator rewards, costs, and risks.
Understand how USDS differs from DAI, when conversion matters, how sUSDS fits in, and which Sky governance changes users should verify in 2026.
How Jupiter routes Solana swaps, what fees users may pay, how JUP governance works, and which execution and aggregator risks matter in 2026.
Learn how Ondo’s OUSG and USDY tokenized Treasury products work, what OUSG’s published instant-redemption limits mean, and which issuer, liquidity, fund, and blockchain risks to check.
Compare JitoSOL, native SOL staking, and JTO governance while tracing MEV tips, protocol fees, buybacks, and the risks that affect realized returns.
Learn how Wormhole Guardians, VAAs, and token routes work, what to verify before bridging, and which warning signs call for a different route.
Learn how Pyth’s pull-oracle model delivers price updates on demand, what update fees cost as of September 2026, and how to protect smart contracts from stale or uncertain prices.
Learn how Injective’s on-chain order books work, what INJ burns actually signal, and how to assess liquidity, trading activity, and bridge dependencies.
