Hyperliquid (HYPE) Price

HYPE is the native token of Hyperliquid Layer 1: it is used to pay Gas on HyperEVM and can participate in HyperBFT consensus through delegation; in specific HyperCore functions, staked HYPE can also determine fee discounts or serve as collateral for market deployment. It is not a wrapped token of an external asset. Hyperliquid separates execution into HyperCore and HyperEVM, but both are secured by the same HyperBFT consensus. HyperCore hosts native financial functions such as on-chain spot and perpetual order books; HyperEVM provides an EVM-compatible smart-contract execution environment. Therefore, holding HYPE does not automatically grant proceeds from an application; its specific use depends on which side the balance is on and whether the user uses it for Gas, delegation, or protocol-defined staking scenarios.

HyperCore and HyperEVM are not two separate chains, but two types of execution state on the same Hyperliquid chain. HyperCore directly provides functions such as perpetual contracts and spot order books; HyperEVM lets developers deploy and call EVM smart contracts. The two sides share the security provided by HyperBFT consensus, but users must still distinguish which side their assets are on when operating them. This distinction affects HYPE usability: on HyperCore, HYPE can be in a spot balance or a staking balance; on HyperEVM, HYPE is the native Gas balance required to execute contract transactions. If assets remain in HyperCore, they cannot directly pay Gas for HyperEVM transactions; conversely, HYPE on the EVM side cannot directly be used for HyperCore spot or staking operations and must first be transferred between the two sides.

On HyperEVM, HYPE is the native Gas token; when submitting a transfer or smart-contract call, users pay in HYPE for the Gas consumed by execution. Fees usually consist of a base fee and a priority fee: the base fee adjusts with supply and demand for block space, while the priority fee expresses willingness to have a transaction processed sooner, so the final cost may rise during congestion. HyperEVM has enabled EIP-1559, and both its base fee and priority fee are burned: the base fee is removed from the total EVM supply, while the priority fee is sent to the zero address's EVM balance. The amount burned depends on actual on-chain Gas use and fee levels; it is not a fixed percentage, nor does it mean every HyperCore trading fee is burned in the same way.

The way ordinary holders participate in network security is to move HYPE from a HyperCore spot balance to a staking balance and then delegate it to one or more validators; Hyperliquid uses delegated proof of stake and does not offer a separate staking mode in which ordinary users produce blocks directly themselves. Active validators produce blocks. Their rewards are proportional to the total delegated stake they receive and, after the validator's set commission is deducted, are reflected to delegators. To become an active validator, a validator must self-delegate at least 10,000 HYPE, and that self-delegation requirement is locked for 1 year. If self-delegation falls below 10,000 HYPE, the validator enters a “cancel-delegation-only” state and can no longer accept new delegations. The validator set and consensus stake adjust every 100,000 rounds, approximately 90 minutes on mainnet; consensus relies on an honest quorum holding more than two-thirds of network stake, so delegators are in practice choosing validators that participate in this security assumption.

HYPE staking rewards come from the “future emissions reserve,” rather than distributing a fixed proportion of every transaction fee directly to stakers. A validator's reward is related to its total delegated stake, and a delegator's share is also affected by that validator's commission. Rewards accrue every minute, are distributed daily, and are automatically re-delegated to the same validator, so the balance continues to participate in subsequent rewards on a compounding basis. Official documentation states that the annualized reward rate is inversely proportional to the square root of total HYPE staked across the network: the more total HYPE is staked, the lower the reward rate corresponding to the same unit of stake. The documentation gives an illustrative scale of about 2.37% annualized when total staking is 400 million HYPE; this is only an example at that total staking level, not a guarantee of returns at any point in time. Each staking epoch calculates rewards based on the delegator's lowest staked balance during that epoch; an epoch is 100,000 rounds.

After delegation, HYPE delegated to the same validator has a 1-day lockup period; once it ends, some or all of it can be undelegated, and the undelegated balance immediately returns to the staking balance. That does not mean it can immediately be used for spot trading or withdrawal. To return to a HyperCore spot balance, the user must also initiate a transfer from the staking balance to the spot balance and enter a 7-day unstaking queue; each address can have at most 5 pending transfers. This waiting period prevents large exits from immediately leaving the staking state associated with consensus security. Current documentation states that there is no automatic slashing mechanism; however, if a validator is jailed by a validator-quorum vote because it does not participate in consensus frequently enough or with sufficient latency, it no longer participates in consensus and its delegators do not earn rewards.

HYPE can be transferred between HyperCore and HyperEVM, but it is displayed differently on each side: on HyperCore it is a native spot asset; after transfer to HyperEVM it becomes the address's native HYPE balance, rather than an ERC-20 contract token. HYPE can be moved from HyperCore to HyperEVM through the frontend transfer function or by sending it to the dedicated system address 0x2222222222222222222222222222222222222222; to return from EVM, send a transaction with HYPE value to that address. This is a dedicated address only for HYPE. Other spot assets each have different system addresses, and sending other assets to the above HYPE address may result in loss of assets. Returning from EVM to HyperCore requires HYPE Gas on the EVM side; moving from HyperCore to EVM also incurs a HYPE cost. Therefore, before operating on EVM for the first time, in addition to the assets to be used, make sure HYPE remains on the EVM side for Gas.

Not all HyperCore trading fees go to one company. Official fee documentation says fees flow to community-related uses, including HLP, the Assistance Fund, and eligible deployers; the portion entering the Assistance Fund is automatically converted into HYPE as part of L1 execution, and HYPE in the Assistance Fund is then burned, permanently removing it from circulating supply and total supply. This mechanism links part of trading activity to HYPE purchases and burns, but the amount burned still depends on actual fees and allocation paths. For traders, fee rates themselves also depend on weighted trading volume over the previous 14 days and order role; spot and perpetual volume are combined to calculate tiers, with spot volume counted at double weight. There are also staking fee discounts: staking more than 10, 100, 1,000, 10,000, 100,000, or 500,000 HYPE corresponds to discount tiers of 5%, 10%, 15%, 20%, 30%, and 40%. The discount changes eligible trading fees, not staking rewards, and does not guarantee that it covers price or liquidity risk during staking.

HIP-3 allows eligible deployers to permissionlessly deploy perpetual-contract markets on HyperCore; deployers are responsible for defining the market, oracle, and contract specifications, and for setting oracle prices, maximum leverage, and settlement when necessary. Therefore, operational parameters of HIP-3 markets are not all decided by the Hyperliquid protocol in place of deployers. The mainnet specification lists a requirement to stake 500,000 HYPE, which a deployer must maintain for at least 183 days after market deployment; any amount above the latest requirement may be undelegated. If malicious market operation occurs, validators may slash the deployer's stake through a stake-weighted vote; even if the deployer has initiated a 7-day unstaking transfer, that stake in the queue can still be slashed. Slashed HYPE is burned rather than distributed to affected users. Thus, in this scenario HYPE is an economic constraint for market deployment; HIP-3 markets themselves should not be mistaken for markets automatically operated or guaranteed by HYPE holders.