HyperCore: An Overview

HyperCore serves as the native, non-EVM execution and state layer for the Hyperliquid L1 blockchain, forming the protocol's principal trading engine. It oversees the on-chain order matching system for perpetuals, the margin framework, spot asset balances, vault logic, and staking operations. HyperCore runs in tandem with HyperEVM, a fully EVM-compatible layer for Solidity smart contracts, allowing tight composability between DeFi applications and the exchange's core infrastructure.

Overview

HyperCore is the principal state machine and logic tier of the Hyperliquid protocol. A fundamental design aim is full on-chain decentralization: rather than relying on off-chain order books, the platform uses its consensus layer to produce a single, canonical ordering of all transactions and marketplace events, including the matching of orders. This approach is built to deliver the performance required by both retail participants and automated traders.

The Hyperliquid chain's state is split into two closely integrated components. HyperCore is a specialized runtime focused on executing core trading logic with an emphasis on efficiency and low-latency financial operations. Its counterpart, HyperEVM, provides a standard EVM environment for deploying Solidity contracts, enabling developers to create diverse DeFi services on the same network. This dual-environment model merges an order-book-style execution environment with the composability of decentralized applications. HyperCore manages the perpetuals order book, spot balances, vault administration, and staking delegations, while HyperEVM contracts can read from and send instructions to HyperCore to build advanced on-chain products that interact directly with exchange state.

Architecture and Technology

The Hyperliquid architecture centers on the interaction between its consensus protocol and the two execution environments, with HyperCore handling the trading workload.

Consensus Mechanism: HyperBFT

HyperCore is secured by a bespoke consensus algorithm called HyperBFT, which is a variant of the HotStuff family. It runs as a Proof-of-Stake (PoS) system in which validator block production rights are allocated in proportion to the native token stake delegated to them. HyperBFT is tuned to reduce end-to-end latency—the interval from a user's request submission to receipt of a committed response—because minimizing this latency is essential for supporting high-frequency trading and providing responsive UX.

Dual-Environment Execution

The Hyperliquid L1 exposes two execution environments that separate specialized trading responsibilities from general-purpose smart contract computation:

• HyperCore: This is the high-performance state machine optimized for the exchange's core operations. It handles all critical financial activities, such as order matching, margin calculations, and account state management for the perpetuals and spot markets.
• HyperEVM: This is a fully EVM-compatible environment that supports the deployment and execution of Solidity smart contracts. It allows developers to build DeFi applications, structured products, yield aggregators, and other on-chain services within the Hyperliquid ecosystem.

Performance

HyperCore is engineered to reach performance targets that compare with both centralized exchanges and other decentralized matching systems, emphasizing low latency and substantial throughput.

Latency

When accessed from a client located in the same geography as the network, the system's end-to-end latency exhibits the following characteristics:

This degree of latency reduction is sufficient for many algorithmic and high-frequency trading strategies with limited modification from other crypto venues, and for retail traders it produces an "instant feedback" interaction in trading interfaces.

Throughput

• Median Latency: 0.2 seconds
• 99th Percentile Latency: 0.9 seconds

Interaction Between HyperCore and HyperEVM

The integration model that connects HyperCore and HyperEVM is a core differentiator of the Hyperliquid design, permitting smart contracts to interface with the exchange core through a controlled and secure mechanism.

Overview of Integration

On March 25, 2025, Hyperliquid rolled out a technical upgrade that enabled direct linking and instantaneous token transfers between HyperCore and HyperEVM. The goal of this integration was to raise capital efficiency, expand DeFi composability, and lower security exposure by removing reliance on external bridges, which are frequent exploit vectors. The feature was described as akin to an instant, cost-free move between a checking account (HyperEVM) and a brokerage account (HyperCore) within the same institution. All interactions are mediated through a collection of precompiled contracts—hardcoded contracts at fixed addresses—that present a secure and efficient ABI to the HyperCore state machine.

Reading State from HyperCore

Contracts on HyperEVM can obtain live protocol data from HyperCore via dedicated read precompiles, enabling decentralized applications to use up-to-date exchange state inside on-chain logic.

• Precompile Address Range: The read precompiles start at the address `0x0000000000000000000000000000000000000800`.
• Functionality: These precompiles enable contracts to query data such as perpetuals positions, spot balances, vault equity, staking delegations, oracle prices, and the L1 block number.
• Data Consistency: The values returned are guaranteed to match the latest HyperCore state at the moment the HyperEVM block is constructed.
• Gas Cost: A call to a read precompile costs `2000 + 65 * (input_len + output_len)` gas.
• Error Handling: Calls with invalid inputs, such as querying a non-existent asset, will return an error and consume all gas allocated to the call frame.
• Developer Resource: The complete functionality of these read precompiles is detailed in the `L1Read.sol` interface file.
• Contract Address: The `CoreWriter` contract is located at the fixed address `0x3333333333333333333333333333333333333333`.
• Mechanism: A smart contract calls the `sendRawAction(bytes memory data)` function on the `CoreWriter`. The `CoreWriter` contract then emits a log containing the encoded action data. This log is subsequently processed by the HyperCore layer, which then executes the requested action.
• Gas Cost: A base call to this contract burns approximately 25,000 gas, with a typical basic call costing around 47,000 gas total.
• Latency Prevention: To prevent users from gaining a latency advantage by bypassing the standard L1 mempool, `order` and `vault transfer` actions submitted through the `CoreWriter` are intentionally delayed on-chain for a few seconds. These delayed actions will appear twice on the L1 explorer: first as an "enqueuing" transaction, and later as the final "HyperCore execution" transaction.

Token Transfers and Linking

Native linking for asset movement between HyperCore and HyperEVM is intended to provide a safer, more convenient substitute for off-chain bridges.

Core Spot and EVM Spot Tokens

Within the ecosystem, tokens are represented in two forms:

The Linking Process

To enable transfers between the two runtimes, a token's creator—the "spot deployer"—must explicitly link the Core spot asset and the corresponding EVM token. The procedure enforces steps to guarantee supply parity and ownership verification:

• Core spot tokens: These are tokens native to HyperCore, used directly for trading on the exchange.
• EVM spot tokens: These are the linked counterparts of Core spot tokens on the HyperEVM layer, represented as standard ERC-20 contracts.
• Initiation: The spot deployer begins the process.
• Supply Reconciliation: The deployer must ensure that the token's total supply is identical on both HyperCore and the proposed ERC-20 contract on HyperEVM.
• Proposal Transaction: The deployer sends a `spot deploy action` to HyperCore, proposing the specific ERC-20 contract on HyperEVM to be paired with their Core spot token.
• Ownership Verification: The deployer must prove ownership of the EVM contract. The method depends on the deployer's account type:
• Externally Owned Account (EOA): The individual must confirm the link by sending a transaction with a specific, designated nonce.
• Contract-based Deployer (e.g., a multisig wallet): The first storage slot (`slot 0`) of the deploying contract on HyperEVM must contain the address of the HyperCore deployer.
• Finalization: A final `finalize` action is executed, which locks in the link and officially establishes the connection between the Core spot asset and the EVM spot token. After this, transfers can be made via a `spotSend` on HyperCore or a standard ERC-20 transfer on HyperEVM.
• HyperCore to HyperEVM: When HYPE is sent from HyperCore using a `spotSend` action, it automatically becomes available as native gas on the destination address on HyperEVM.