Hyperliquid works as one consensus engine writing one ordered list of transactions, and HyperBFT, a proof-of-stake design inspired by HotStuff, is that engine. The same list runs in two environments that share one state: HyperCore for onchain books, and HyperEVM for contracts that pay gas in HYPE. Hyperliquid is a purpose-built layer 1.
A committed round is the unit of progress: a validator proposes a batch, and others vote until a quorum, more than two thirds of stake, commits it. HyperCore then applies book actions from that batch, and HyperEVM applies contract calls from the same order. Suppose you place a small BTC perpetual on the book, then send 5 HYPE from spot to HyperEVM so a later contract call can pay gas. The fill and the gas send share one chain, and they still settle as two bills. What Hyperliquid is is the definition, and the wiring is the round, then the two environments.
How Hyperliquid works
Hyperliquid is one chain with two execution environments under one consensus. HyperBFT commits an ordered list, HyperCore runs perpetual and spot books on that list, and HyperEVM runs general-purpose contracts on the same list, with HYPE as gas. Shared state means those environments read one committed history and one validator set.
| Part | Job on this chain |
|---|---|
| HyperBFT | Commits one ordered list of transactions |
| HyperCore | Runs onchain perpetual and spot books |
| HyperEVM | Runs general-purpose contracts, with HYPE as gas |
The round comes first, and the two environments read it without voting again.
How HyperBFT writes one ordered list
HyperBFT is the engine that decides the order: validators with delegated HYPE stake propose and vote, and a committed round is a signed bundle of transactions that execution reads. HyperCore and HyperEVM take their actions from the same list.
The docs put the chain in one sentence first. Hyperliquid is a layer one blockchain written and optimized from first principles. It uses a custom consensus algorithm called HyperBFT, inspired by HotStuff and its successors. State execution then splits into two broad components: HyperCore and the HyperEVM. HyperCore includes fully onchain perpetual futures and spot order books. Every order, cancel, trade, and liquidation happens transparently with one-block finality inherited from HyperBFT (source: Hyperliquid Docs, About Hyperliquid). Throughput numbers on that page move as the software changes, and they belong in a later book guide, not as a constant here.
HotStuff is the family HyperBFT points at. "We present HotStuff, a leader-based Byzantine fault-tolerant replication protocol for the partially synchronous model." (source: Yin et al., HotStuff on arXiv) Hyperliquid wrote its own variant and its own networking layer. Treat inspired-by as a claim the project makes about its design, not as an independent audit of the code.
Stake is how a validator gets to speak. Hyperliquid only supports delegated proof of stake. Rounds are the discrete bundles: each one is a batch of transactions plus signatures from a quorum of validators. A quorum is a set with more than two thirds of stake. Jailing is the liveness tool. There is currently no automatic slashing implemented. Jailing differs from slashing, which is reserved for provably malicious behavior such as double-signing blocks at the same round (source: Hyperliquid Docs on staking). A jailed validator stops producing rewards, and on today's staking page it does not auto-burn delegator HYPE. Live latency figures stay with how HyperBFT consensus works. How Ethereum's proof of stake works is the other design.
How Ethereum works is a useful contrast for the same job: order transactions, then execute them. Ethereum separates consensus and execution in its own way. Hyperliquid's split is HyperCore and HyperEVM under one HyperBFT list.
How HyperCore runs the onchain books
HyperCore is the onchain trading environment, and it holds margin and matching state on the chain. Cancels, trades, and liquidations are the same class of action as the order itself.
The generic picture of bids and asks is in how an order book works. The architecture question only needs where that book sits.
HyperCore keeps the book onchain, and validators still produce blocks in proportion to staked HYPE. The design goal is one consistent order of transactions under HyperBFT. Latency figures on that overview page are live measurements for a co-located client, and they move.
Matching is ordinary exchange logic sitting in unusual places. Each asset has a book, filled in price-time priority. The mempool even sorts cancels ahead of new GTC and IOC orders inside a batch. That sort is a book detail. Matching internals are in how HyperCore works. Fills, cancels, and liquidations are in how the Hyperliquid book works.
Trading on the book is billed apart from an EVM send. The gas is only for depositing, and trading on Hyperliquid is gas-free (source: Hyperliquid Docs, How to start trading). That onboarding note also tells a wallet user to sign a gas-less Enable Trading message. That is the fact. Signed transactions can still carry other costs: deposit gas still lives on the source chain, HyperEVM gas still lives in HYPE, and those are three separate bills.
Builder-deployed perps still sit on this book. HIP-3 inherits HyperCore's high-performance margining and order books. The staking requirement for mainnet will be 500k HYPE, and that requirement is expected to decrease over time as the infrastructure matures (source: Hyperliquid Docs, HIP-3). That staking requirement is a holder fact, and a deployer runbook sits elsewhere. The rest of that product is in HIP-3 builder-deployed perps. HIP-4 outcome markets are a different product on the same books. Permissionless HIP-4 deployer actions stay a testnet API in the docs index.
BloFin lists HYPEUSDT at 75x, and HYPE/USDT spot is live. HYPERUSDT is Hyperlane, a different ticker. The architecture described here is the chain.
Suppose you placed that BTC perpetual. The order already lives as a HyperCore action in the committed list, and it does not wait on a later EVM call.
How HyperEVM runs contracts
HyperEVM is the contract side of the same chain: Solidity apps live here, the book lives on HyperCore, HYPE is gas, and chain ID 999 is the RPC face wallets add.
The landing page states the split in one line. The HyperEVM is secured by the same HyperBFT consensus as HyperCore, which is why a contract can talk to spot and perp books without leaving the chain. The same page is explicit about transfers. There is no bridging risk between HyperCore and HyperEVM as one unified state (source: Hyperliquid Docs, HyperEVM). The HyperEVM is still described as alpha, so treat that as the project's own rollout label, not a safety rating.
Wallet docs list chain ID 999, HYPE as the currency symbol, and an EVM version described as Cancun without blobs. Dual blocks are named there too: fast small blocks and slow big blocks. Sending from HyperEVM back to spot costs HYPE gas, and sending onto HyperEVM from spot costs HYPE gas on HyperCore. Precompiles, dual-block gas limits, and CoreWriter are in how the HyperEVM works. How Ethereum smart contracts work is the account-and-map version of the same job.
Suppose you sent 5 HYPE onto HyperEVM: a swap contract can run, and if it needs a price or a fill, that is a HyperCore read or write.
How shared state works on one layer 1
Shared state means one committed list and one validator set. Balances can still sit in more than one place. You can have USDC on HyperCore perps, HYPE on HyperCore spot, and HYPE on HyperEVM at the same time. Moving HYPE between Core and EVM is a system transfer on this chain.
A rollup is a different claim. A rollup posts data to another chain for settlement. Ethereum.org's layer-2 page uses a data test: if data is stored somewhere else, the project is independent rather than a direct Ethereum extension (source: ethereum.org, Layer 2). Hyperliquid stores its own chain, and it does not post HyperCore books to Ethereum for settlement. Why Ethereum uses layer-2s is that other design. Both facts can be true at once: HyperEVM looks like Ethereum, and Hyperliquid is still its own L1.
HYPE is the awkward asset in the transfer. It is native gas on HyperEVM, so it does not land as a normal ERC-20. The system address for that move is 0x2222222222222222222222222222222222222222. Other spot tokens each have their own system address. Send the wrong asset to the HYPE address and the docs say it can be lost. Routes in from Bitcoin, Ethereum, Solana, and the rest, plus what each route trusts, sit in Hyperliquid deposits and bridges. BloFin deposit click paths stay on the product side of that line.
The book feels like a centralized exchange and the EVM feels like Ethereum, and the wiring is one consensus, two environments, shared state. That is the product.
What one-block finality means
One-block finality is a HyperBFT inheritance. Once a round commits, the docs treat the orders, cancels, trades, and liquidations in that block as final.
Suppose you just filled that BTC perpetual. You do not wait on a Bitcoin-style pile of extra blocks for the protocol to call the fill done.
A CEX showing the withdrawal in the destination account is a different sentence, because venues add their own checks. A shop that ships on first sighting is taking a policy risk. Explorers show height, and height increments on rounds that carry at least one transaction. Empty rounds can exist, and a pending label in a wallet is often that the app has not seen the block yet.
Small EVM blocks are fast and large EVM blocks are slower, and both still sit under the same consensus. A contract deployment that asked for a large block can look late while your book fill already landed. That delay is block type.
What can still go wrong
A sound consensus design leaves ordinary risks in place. You can still send coins to the wrong environment, pick a validator you have not researched, or treat an audit-page list as a complete catalog.
The HyperEVM launched with lower throughput on purpose because it shares state with HyperCore. Gas can spike when demand beats that cap. Apps on it are early, so read the contract and start small.
Deposits split in a way wallets hide. Some centralized exchanges send and receive HYPE on HyperCore spot and not on HyperEVM. Suppose you watch MetaMask on chain ID 999 and it is empty: the coins may sit on Core. The reverse happens too. An EVM send can miss the hop back to spot.
Validators are a trust choice. The staking docs tell delegators to pick validators they actually trust. A dashboard alert is not a full risk catalog.
The project's audit page lists a Zellic review of the legacy bridge contract, and notes that Circle's contracts are audited independently. That list is not a complete risk catalog. Crypto security basics is the generic hygiene. Bridge trust assumptions stay with the deposits guide.
If you are moving size, watch the explorer for the environment you actually used, Core or EVM, before you treat the payment as done.
How the parts fit together
HyperBFT commits one list, HyperCore reads book actions off that list, and HyperEVM reads contract calls off the same list. Balances can sit in more than one place, and a Core to EVM transfer is still this chain. A book fill can be gas-free while a contract call burns HYPE.
You do not need to memorize dual-block gas limits, HIP-3 stake math, or every system address. You need the order: consensus, then the book, then the EVM, then the transfer that looks like a bridge and is a system transfer.
If you want the book, start with HyperCore, and if you want a contract, start with HyperEVM and keep gas in HYPE.
Frequently asked questions
Why does my wallet show chain ID 999?
Because 999 is the HyperEVM JSON-RPC face, not a second consensus set. Wallets that speak EVM need a chain ID, an RPC URL, and a gas token. HyperCore books do not show up as that network. Adding 999 does not import Core balances into the wallet. You are setting a custom RPC, not electing a second validator set.
Is the first HyperCore deposit really free?
No. New HyperCore accounts pay a one-time activation of 1 quote token. "New HyperCore accounts require 1 quote token (e.g., 1 USDC, 1 USDT) of fees for the first transaction which has the new account as destination address." (source: Hyperliquid Docs, Activation gas fee) After that, book trades are the gas-free path the onboarding page describes. Source-chain gas for the deposit is separate.
Do HyperEVM priority fees go to validators?
No. Developer docs say EIP-1559 is on, base fees are burned, and priority fees are burned too. Unlike most other EVM chains, priority fees are also burned because the HyperEVM uses HyperBFT consensus (source: Hyperliquid Docs, HyperEVM for developers). That is a HyperEVM rule, not a HyperCore trading fee.
If a contract places a book order, does it jump the mempool?
No. A system contract can send HyperCore actions from HyperEVM, including orders. Docs delay those order actions and vault transfers onchain for a few seconds so the EVM path cannot skip the L1 mempool. To prevent any potential latency advantages for using HyperEVM to bypass the L1 mempool, order actions and vault transfers sent from CoreWriter are delayed onchain for a few seconds. These onchain-delayed actions appear twice in the L1 explorer: first as an enqueuing and second as a HyperCore execution (source: Hyperliquid Docs, Interacting with HyperCore). That delay is a fairness rule. Encoding and precompile internals still sit with the HyperEVM guide.
Is an HIP-4 market the same product as an HIP-3 perp?
No. HIP-3 is builder-deployed perps on HyperCore's books and margining. HIP-4 is a different primitive, a general-purpose tool useful for applications such as prediction markets and bounded options-like instruments (source: Hyperliquid Docs, HIP-4). HIP-4 deployer endpoints in the docs index are still a testnet API. A live outcome market is not a permissionless mainnet deploy button. Keep the 500k HYPE HIP-3 staking requirement on the perp product, not on this primitive.
Why did a Core-to-EVM token send burn 200k gas?
Because that send is an EVM bill, not a book fee. A transfer from HyperCore to HyperEVM costs 200k gas at the base gas price of the next HyperEVM block (source: Hyperliquid Docs, HyperCore to HyperEVM transfers). The reverse costs similar gas to sending the token to any HyperEVM address that already has a balance. Those 200k units are gas, not orders per second. Book trades stay the gas-free path described in onboarding.
Why can a contract deploy look slower than a fill?
HyperEVM splits throughput into fast small blocks and slower large blocks. Fast block duration is set to 1 seconds with a 3M gas limit. Slow block duration is set to 1 minute with a 30M gas limit. The initial configuration is set conservatively, and throughput is expected to increase over successive technical upgrades (source: Hyperliquid Docs, Dual-block architecture). A big contract can wait on the slow block while a book fill already committed. That is two block types.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on About Hyperliquid, HyperCore, HyperEVM, staking, HIP-3, and onboarding, plus ethereum.org's layer-2 page and the HotStuff paper. Protocol facts independently verified against cited sources current as of August 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, validator and bridge risk, smart-contract exploits in HyperEVM apps, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, or participate in any project. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.