What Is Hyperliquid? How HyperCore, HyperEVM, and HyperBFT Work

Beginner | 6 min | Last verified 2026-09-07

Learn how Hyperliquid works as a layer one blockchain, how HyperCore handles native markets, how HyperEVM adds smart contracts, and how HyperBFT secures both.

Hyperliquid is a layer one blockchain designed around financial markets. Its native trading system supports spot and perpetual markets, while its smart contract environment lets developers build applications on the same blockchain.

The architecture differs from the common model where a decentralized exchange is deployed as smart contracts on a general purpose chain. Hyperliquid divides execution between HyperCore, its native financial engine, and HyperEVM, its Ethereum compatible smart contract environment. HyperBFT provides consensus for both.

HyperCore handles native financial markets

HyperCore contains Hyperliquid's margin, matching engine, and other native financial state. Orders, cancellations, trades, and liquidations are processed onchain rather than being matched by an offchain order book.

According to Hyperliquid's protocol documentation, mainnet supports about 200,000 orders per second. For a geographically colocated client, documented end to end latency is about 0.2 seconds at the median and 0.9 seconds at the 99th percentile. These figures describe protocol capacity and committed response latency rather than a guarantee of the latency every user will experience.

This design gives traders an order book interface while keeping the underlying execution in blockchain state. The order book lesson explains price time priority, bids, asks, and how orders reach the matching engine. The trade lifecycle lesson follows an order from submission through execution and settlement.

HyperEVM adds general purpose smart contracts

HyperEVM consists of EVM blocks produced as part of Hyperliquid's execution and secured by HyperBFT. Mainnet uses chain ID 999, HYPE is its native gas asset, and the environment uses the Cancun hard fork without blobs.

Developers can use familiar Ethereum tooling while building applications that interact with Hyperliquid's financial state. Read precompiles expose selected HyperCore information to contracts, including perpetual positions, spot balances, vault equity, staking delegations, and oracle prices.

The connection also works in the other direction. Hyperliquid provides a system contract called CoreWriter at 0x3333333333333333333333333333333333333333. Contracts can use it to submit supported actions to HyperCore, including limit orders, transfers, staking operations, and order cancellations.

That connection matters because a lending application on HyperEVM can, for example, read a HyperCore oracle price as an input to its risk logic instead of maintaining an entirely separate market data system. For the implementation details, continue with how HyperEVM interacts with HyperCore.

HyperBFT orders and finalizes state

A financial system needs a single agreed sequence of transactions. Two orders that compete for the same liquidity cannot both be treated as arriving first.

HyperBFT is Hyperliquid's proof of stake consensus mechanism, inspired by HotStuff. Validators produce blocks in proportion to stake delegated to them. Once consensus commits a block, HyperCore and HyperEVM operate from the resulting ordered state.

This distinction is useful when learning the system. HyperBFT decides the canonical ordering of state transitions, HyperCore executes native financial logic, and HyperEVM executes general purpose smart contracts. The dedicated HyperBFT lesson covers validators, quorums, rounds, and finality in more detail.

How HyperCore and HyperEVM fit together

HyperCore and HyperEVM are components of one Hyperliquid blockchain rather than independent networks connected by an external bridge. Both inherit security from HyperBFT.

Spot assets can move between Core spot balances and their linked EVM representation. HYPE is a special case because it becomes the native gas balance on HyperEVM. Hyperliquid uses the system address 0x2222222222222222222222222222222222222222 for HYPE transfers between the two environments.

The shared architecture also creates timing rules. Core to EVM transfers wait for the next HyperEVM block. EVM to Core transfers are processed in the same L1 block immediately after the EVM block is built. Developers building across both environments therefore need to understand execution order rather than treating the two sides as synchronously interchangeable.

What users can do on Hyperliquid

The architecture supports several distinct activities:

• Trade native markets. Traders can use HyperCore's spot and perpetual order books and manage margin positions.
• Build applications. Developers can deploy Solidity contracts on HyperEVM and use JSON RPC tooling familiar from Ethereum.
• Connect contracts to market state. Applications can read selected HyperCore state through precompiles and send supported actions through CoreWriter.
• Stake HYPE. HYPE can be delegated to validators through HyperCore. Validator rewards depend on delegated stake, and staking participates in the security model behind HyperBFT.
• Integrate programmatically. Trading systems can use HyperCore's REST and WebSocket interfaces rather than relying on the frontend.

These activities share one underlying blockchain but involve different execution paths. A trader learning leverage should continue to leverage, margin, long, and short positions, while a developer should continue through HyperCore and HyperEVM.

A useful model for Hyperliquid

Think of Hyperliquid as one blockchain with three responsibilities. HyperBFT establishes transaction order and consensus. HyperCore executes the chain's native financial markets. HyperEVM executes general purpose smart contracts and provides a programmable path into parts of HyperCore state.

Keeping those responsibilities separate makes the rest of the Academy easier to navigate. The next foundation lessons examine each component independently before moving into order books, perpetual futures, margin, liquidation, APIs, and application development.