An explanatory guide to HyperCore, HyperEVM, perpetual futures, HYPE, liquidity, and the main risks
Information basis: documentation and public ecosystem data reviewed on 12 November 2026. Market and protocol metrics change continuously; numerical figures below are dated snapshots, not forecasts or trading recommendations.
What is Hyperliquid?
Hyperliquid is a Layer 1 blockchain designed around an on-chain financial marketplace. Its best-known product is a decentralized exchange for perpetual futures, but the network also supports spot markets, a general-purpose Ethereum-compatible environment called HyperEVM, and additional financial applications.
The central design idea is to put the exchange’s core state directly on the blockchain. Hyperliquid’s official documentation says that orders, cancellations, trades, and liquidations in HyperCore are recorded transparently and receive one-block finality through its HyperBFT consensus system.
This makes Hyperliquid different from a conventional centralized exchange. A centralized exchange normally keeps its matching engine, balances, liquidations, and internal ledger on private servers. Hyperliquid attempts to make these functions verifiable through the network’s state while still delivering an exchange-like order-book experience.
It is important not to interpret “on-chain” as “risk-free” or “fully decentralized in every respect.” The system still depends on validators, software implementation, market-making liquidity, oracles, governance decisions, and the security of bridges and wallets.
The two main layers: HyperCore and HyperEVM
Hyperliquid’s execution is divided into two broad components.
HyperCore: the trading engine on the L1
HyperCore contains the native spot and perpetual-futures order books. It is not simply a smart contract deployed on a general-purpose chain. It is part of the specialized execution environment of the Hyperliquid L1.
The official documentation describes HyperCore as supporting fully on-chain perpetual futures and spot order books. It also states that the software is optimized for high throughput and currently supports approximately 200,000 orders per second, with performance subject to future software changes.
The practical consequence is that users interact with a blockchain whose main design priority is trading performance. The protocol can maintain an order-book model rather than relying only on automated market makers. Traders can submit limit orders, take liquidity with marketable orders, cancel orders, and see trades settle through the network.
HyperEVM: the smart-contract environment
HyperEVM is the general-purpose smart-contract layer. It is compatible with the Ethereum Virtual Machine, allowing developers to build or port applications using familiar EVM tools and contract patterns.
HyperEVM blocks are executed as part of Hyperliquid’s broader execution and inherit security from HyperBFT consensus. HYPE is the native gas token on HyperEVM. The official documentation identifies mainnet chain ID 999 and the JSON-RPC endpoint https://rpc.hyperliquid.xyz/evm.
HyperEVM makes HyperCore’s liquidity and financial primitives available to external builders. For example, a developer can create an application that uses a Hyperliquid market, builds a lending interface, or combines smart-contract logic with exchange liquidity. The exact applications available at any moment depend on deployed contracts and their security quality.
A key operational distinction is that HyperCore and HyperEVM are related but not identical account environments. Moving assets between them uses the protocol’s native transfer mechanism. Users should check the current official instructions before transferring funds because sending assets to the wrong network or address can cause loss.
How a perpetual trade works
A perpetual future is a derivative contract with no expiry date. Instead of settling on a fixed date, it uses funding payments to help keep the contract price near the underlying asset’s spot price.
A simplified trade follows this sequence:
1.The trader deposits collateral. Hyperliquid’s main crypto perpetuals use USDC as collateral. The contract is generally linear and references an oracle price denominated in USDT, with special conventions described in the contract specifications.
2.The trader chooses a market and margin mode. The trader can normally use cross margin or isolated margin, subject to asset-specific rules and the selected market’s maximum leverage.
3.The trader submits an order. A limit order may add liquidity to the book. A marketable order consumes available liquidity. The order, cancellation, and resulting trade are processed by HyperCore.
4.The position records exposure. A long position benefits when the referenced asset rises; a short position benefits when it falls, before fees, funding, and execution effects.
5.The position is marked and funded. Unrealized profit and loss is calculated using the protocol’s marking logic. Funding is periodically transferred between longs and shorts.
6.The position is closed or liquidated. The trader can close voluntarily. If account equity falls below required maintenance margin, the liquidation process begins.
This is a leveraged derivatives system, not a simple purchase of the underlying asset. A trader can lose collateral quickly, especially when leverage is high or the market is thin.
Cross margin and isolated margin
Under cross margin, eligible positions share collateral. This can use capital more efficiently because unrealized profit in one position may help support another position. The trade-off is that a severe loss can affect more of the account’s cross-margin collateral.
Under isolated margin, collateral is assigned to a particular position. A liquidation of that isolated position does not normally affect other isolated positions or cross positions. Isolated margin can therefore limit the collateral exposed to one trade, although it does not remove price, funding, liquidity, or execution risk.
Funding: why longs and shorts pay each other
Funding is a peer-to-peer payment between opposing sides of a perpetual contract. It is not, in the normal mechanism, a fee collected by Hyperliquid.
When the perpetual contract trades above the relevant spot oracle price, the funding rate is generally positive and longs pay shorts. When the contract trades below the oracle price, the rate can become negative and shorts pay longs.
Hyperliquid calculates the rate from a premium component and an interest-rate component. The premium is based on the difference between executable impact prices in the order book and the oracle price. The documentation says the premium is sampled every five seconds and averaged over an hour, while funding is paid hourly at one-eighth of the computed eight-hour rate.
For a position, the simplified funding payment is:
Plain Text
position size × oracle price × funding rate
A position that appears profitable from price movement can still lose money if funding payments accumulate against it. Conversely, funding can contribute to returns for the side receiving the payment, but the rate is variable and can change quickly during crowded markets.
Oracles and mark price
Perpetual markets need more than the last traded price. If liquidations used only one small trade on the order book, a temporary price move could trigger unnecessary liquidations. Hyperliquid therefore uses a mark-price system for liquidation purposes.
Its documentation explains that liquidation mark prices combine external centralized-exchange prices with Hyperliquid’s book state. The spot oracle is calculated by validators using a weighted median of centralized-exchange spot prices, with weights related to exchange liquidity.
This design can make liquidation pricing more robust than relying on one instantaneous trade. It does not eliminate oracle risk. Problems can still arise from exchange outages, abnormal prices, stale data, implementation errors, or extreme market conditions.
Liquidations and the HLP liquidator vault
A liquidation begins when a trader’s account equity falls below the applicable maintenance-margin requirement. Hyperliquid first attempts to close the position through market orders sent to the order book. The position may be closed completely or partially.
If the account falls further and the order-book liquidation does not restore the required margin, a backstop liquidation can occur through the liquidator vault. The official documentation says this vault is a component strategy of HLP, Hyperliquid’s liquidity-provider and strategy system.
For large positions, Hyperliquid can use partial liquidation rules rather than immediately sending the full position to the book. The goal is to reduce market impact and give the position an opportunity to return to a safer margin level.
A liquidation is not the same as a normal stop-loss. It is a forced risk-control process that occurs after the account has already reached a dangerous state. Traders may also lose remaining maintenance margin during a backstop liquidation because the vault needs a buffer to make the process viable on average.
Auto-deleveraging as a final safeguard
If a user account becomes underwater, the protocol has an auto-deleveraging mechanism. The documentation states that profitable traders on the opposite side can be ranked according to unrealized profit and leverage, and positions may be closed against the underwater position to preserve platform solvency.
Auto-deleveraging is a tail-risk mechanism. It means that even a trader who used correct collateral and did not personally become insolvent could, in an extreme event, have a position reduced by the platform’s solvency rules.
Fees and where the money goes
Hyperliquid uses different fee schedules for perpetuals and spot markets. Fees depend partly on rolling 14-day volume. The official schedule reviewed for this article lists a base perpetual taker fee of 0.045% and a base perpetual maker fee of 0.015%, with lower rates available at higher volume tiers. Exact fees can also depend on referrals, staking, market type, quote-asset alignment, and other rules.
A maker provides liquidity, typically through an order that rests on the book. A taker removes liquidity by matching against existing orders. A maker can receive a rebate in some tiers, while a taker normally pays a positive fee.
According to the official fee documentation, protocol fees are directed to community-related destinations including HLP, the assistance fund, and deployers of certain markets. The assistance fund converts trading fees to HYPE through L1 execution and burns the HYPE it receives, permanently removing those tokens under the stated mechanism.
This fee model is economically important because trading activity can create demand for the protocol’s services and can route value toward liquidity providers, market deployers, or token-related mechanisms. It does not guarantee that HYPE’s market price will rise. Revenue can fall if volume, fees, market share, or trader activity decline.
What is HYPE?
HYPE is Hyperliquid’s native token. Its functions include paying gas on HyperEVM and participating in staking-related mechanisms. The fee documentation also describes staking tiers that can affect trading fees, while the HyperEVM documentation identifies HYPE as the network’s gas token.
HYPE is also part of the protocol’s economic design because the assistance fund can convert fees into HYPE and burn the acquired tokens. The relationship between protocol revenue, token purchases, burns, circulating supply, and market price depends on actual governance and execution rules at each point in time.
As a dated independent snapshot, DeFiLlama reported on its Hyperliquid page that the token had a maximum supply of 1 billion HYPE and approximately 222.45 million circulating tokens at the page’s reported observation point. The same page showed substantial perpetual volume and open interest, but these figures are volatile and should not be treated as current live data without checking the source again.
Token holders should distinguish three separate questions:
•Utility: What can HYPE be used for, such as gas or staking?
•Value capture: What protocol cash flows or burns, if any, are linked to HYPE?
•Market risk: How might supply changes, unlocks, liquidity, leverage, sentiment, or competition affect the token’s price?
A token can have real utility while still being highly volatile or overvalued relative to current usage.
Why Hyperliquid uses an order book instead of only an AMM
Many decentralized exchanges use automated market makers. An AMM quotes prices from liquidity pools according to a mathematical curve. Hyperliquid’s core exchange uses native order books, which are familiar to professional traders and can support limit orders, maker-taker pricing, and more direct control of execution.
The advantage is potentially tighter and more expressive market structure when liquidity is strong. The disadvantages include dependence on active market makers, more complex matching-engine logic, and the possibility that liquidity becomes thin during stress.
The order book is only as good as the liquidity available at the time a trader needs to enter or exit. A displayed mid-price is not a guarantee that a large order can be executed near that price.
HIP-1, HIP-2, and HIP-3: extending the market system
Hyperliquid Improvement Proposals, or HIPs, define additional protocol functionality.
HIP-1 defines a capped-supply fungible token standard and supports on-chain spot order books between HIP-1 tokens.
HIP-2, also known as Hyperliquidity, describes an on-chain strategy integrated into block-transition logic. It is intended to help bootstrap liquidity through protocol-level behavior rather than relying only on conventional automated market-making infrastructure.
HIP-3 allows builder-deployed perpetual markets. This expands permissionless market creation, but it also introduces additional risks. A new market may have limited liquidity, unusual funding behavior, weak oracle design, or a deployer with incentives that differ from traders’ interests. The fee documentation includes special rules for HIP-3 markets, including deployer fee shares and an optional growth mode.
Permissionless market creation can increase experimentation and asset coverage. It can also increase the number of markets that require independent due diligence.
What happens when a user trades?
A simplified end-to-end example makes the architecture easier to understand.
Suppose a trader deposits USDC and opens a 5x BTC perpetual long:
1.The trader selects the BTC perpetual market and cross or isolated margin.
2.The trader submits a limit or marketable order through the interface.
3.HyperCore matches the order with available liquidity and records the trade.
4.The position’s notional value and margin are tracked on-chain.
5.The position’s unrealized profit or loss changes as the mark price changes.
6.Each hourly funding interval transfers a funding payment between longs and shorts.
7.If equity falls below maintenance margin, HyperCore attempts liquidation through the order book.
8.If the account becomes more deeply under-margined and normal liquidation is insufficient, the HLP liquidator vault can act as a backstop.
9.When the trader closes the position, the final result reflects price movement, trading fees, funding, slippage, and any liquidation effects.
The exchange interface may feel similar to a centralized exchange, but the settlement and risk process are tied to the blockchain’s execution rules.
Main strengths
Hyperliquid’s main strengths are its specialization, transparent on-chain exchange state, familiar order-book model, integrated perpetual and spot markets, and a path for smart-contract builders through HyperEVM.
The system also attempts to align community economics with trading activity. Its documentation describes fee routing to community mechanisms, HLP, deployers, and the assistance fund rather than treating all fees as a private operator stream.
For developers, the combination of a fast trading-specific L1 and an EVM environment can be attractive. Applications can potentially combine smart contracts with native exchange liquidity instead of building an entirely separate market infrastructure.
Main risks and limitations
Leverage and liquidation risk
Perpetual futures can produce losses much larger than a trader expects from a small price move. Funding, mark prices, maintenance margin, partial liquidation, backstop liquidation, and auto-deleveraging all matter.
Smart-contract and protocol risk
HyperEVM applications are not automatically safe because they run on Hyperliquid. Each application can contain bugs, flawed economic assumptions, privileged administration, oracle weaknesses, or bridge risks.
Validator and consensus risk
Hyperliquid relies on its validator set and HyperBFT implementation. Outages, software defects, censorship concerns, validator concentration, or consensus failures could affect trading and settlement.
Liquidity and market-structure risk
A high reported volume figure does not mean every asset has deep liquidity. Smaller or newer markets can have wide spreads, slippage, volatile funding, and difficult exits.
Oracle risk
Perpetuals and liquidations depend on price references. External exchange outages, abnormal prices, or implementation problems can affect marks, funding, and liquidation outcomes.
Token and supply risk
HYPE’s utility and protocol-linked mechanisms do not remove market risk. Supply changes, unlocks, burns, market concentration, and shifts in protocol activity can all affect valuation.
Regulatory and operational risk
Derivatives, leveraged trading, token issuance, and decentralized financial services can be treated differently across jurisdictions. Users may also face restrictions, tax obligations, or limited legal recourse depending on where they live.
How to evaluate Hyperliquid responsibly
A useful evaluation should separate the technology from the token price. For the technology, examine finality, validator design, uptime, order-book liquidity, API reliability, oracle behavior, and the security of major applications.
For the trading product, examine the exact market, collateral, maximum leverage, margin mode, funding history, depth at the intended order size, liquidation formula, and the rules for backstop liquidation and auto-deleveraging.
For HYPE, examine actual token supply and unlock data, the current relationship between protocol fees and token mechanisms, the concentration of holdings, staking participation, and whether protocol activity is diversified or overly dependent on speculative leverage.
Finally, use only funds that can withstand a total loss when interacting with leveraged crypto markets. This is a risk-management principle, not a prediction about Hyperliquid’s future.
Conclusion
Hyperliquid is best understood as a trading-focused blockchain with two connected environments. HyperCore provides native on-chain spot and perpetual order books, while HyperEVM provides a general-purpose EVM platform that can use the network’s financial primitives.
Its operating model combines order-book matching, oracle-based marking, hourly peer-to-peer funding, cross or isolated margin, market-based liquidations, HLP backstops, and protocol-level fee routing. HYPE functions as the native gas token and participates in the network’s staking and economic mechanisms.
The core trade-off is clear: Hyperliquid aims to provide centralized-exchange-like performance and functionality with more transparent blockchain settlement. In return, users must understand both sides of the system—derivatives risk and blockchain risk. The fact that trades are on-chain improves verifiability, but it does not eliminate leverage losses, liquidity shocks, oracle failures, smart-contract bugs, or token volatility.