HyperCore is the native, non-EVM execution and state layer of the Hyperliquid L1 blockchain, serving as the core engine for the protocol's primary trading functions. It is responsible for managing the decentralized perpetuals exchange's on-chain order matching engine, margin system, spot asset balances, vault strategies, and staking mechanisms. HyperCore operates in a dual-environment architecture alongside HyperEVM, a general-purpose, EVM-compatible layer for smart contracts, enabling a high degree of composability between decentralized finance (DeFi) applications and the exchange's core infrastructure. ^{[1] [2]}​

Overview

HyperCore is the foundational state machine and logic layer of the Hyperliquid protocol. A central design principle of HyperCore is full decentralization; it does not utilize off-chain order books, instead relying on its consensus mechanism to establish a single, canonical ordering of all transactions and platform activities, including order matching. This on-chain approach is engineered to deliver high performance to support both retail and automated trading strategies. ^[2]

The Hyperliquid chain's state is divided into two distinct but deeply integrated components. HyperCore is the specialized environment that executes the core trading logic with a focus on speed and efficiency for financial transactions. Its counterpart, HyperEVM, is a fully EVM-compatible environment that runs Solidity smart contracts, allowing developers to deploy a wide range of DeFi applications directly on the Hyperliquid network. This dual-environment architecture creates a hybrid system that combines the performance of a traditional order book with the flexible composability of decentralized applications. Key functionalities managed by HyperCore include the perpetuals order book, spot balances, vault management, and staking delegations. The deep integration between the two layers allows smart contracts on HyperEVM to read data from and send instructions to HyperCore, enabling the development of advanced on-chain products that can interact directly with the exchange's core state. ^{[1] [2]}

Architecture and Technology

The architecture of Hyperliquid is designed around the interplay of its consensus mechanism and its dual-execution environments, with HyperCore at the center of its trading operations.

Consensus Mechanism: HyperBFT

HyperCore is secured by a proprietary consensus algorithm named HyperBFT, which is a variant of the HotStuff consensus model. It operates on a Proof-of-Stake (PoS) basis, where validators are selected to produce blocks in proportion to the quantity of native tokens staked to them. The HyperBFT algorithm is specifically optimized to minimize end-to-end latency, which is defined as the total time from when a user submits a request to when a committed response is received. This focus on latency reduction is critical for supporting high-frequency trading and providing a responsive user experience. ^[2]

Dual-Environment Execution

The Hyperliquid L1 features a dual-environment architecture that separates specialized trading functions from general-purpose 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.

The integration between these two environments allows applications on HyperEVM to programmatically access and interact with the trading and account data managed by HyperCore, creating a unified platform for both trading and broader DeFi activities. ^{[1] [2]}

Performance

HyperCore was engineered to achieve performance metrics comparable to both centralized and decentralized exchanges, focusing on low latency and high throughput.

Latency

The platform's end-to-end latency, when accessed from a geographically co-located client, exhibits the following performance characteristics:

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

This level of low latency is sufficient for the deployment of many automated and high-frequency trading strategies with minimal modifications from other cryptocurrency venues. For retail users, it translates to an "instant feedback" experience when interacting with the trading user interface. ^[2]

Throughput

HyperCore is designed to handle a high volume of transactions. The mainnet has demonstrated a capacity of approximately 200,000 orders per second. According to the project's documentation, the primary constraint on throughput is the execution logic itself, rather than the underlying consensus and networking stack. The HyperBFT consensus layer is reportedly capable of scaling to support millions of orders per second, with ongoing plans to further optimize the execution logic as demand grows. ^[2]

Interaction Between HyperCore and HyperEVM

The interaction model between HyperCore and HyperEVM is a defining feature of the Hyperliquid architecture, enabling smart contracts to communicate with the core exchange logic through a secure and standardized interface.

Overview of Integration

On March 25, 2025, Hyperliquid announced a significant technical update that enabled direct linking and seamless transfer of tokens between HyperCore and HyperEVM. This integration was designed to improve capital efficiency, enhance DeFi composability, and reduce security risks by eliminating the need for third-party bridges, which are frequent targets of exploits. The process was likened to making an instant, free transfer between a checking account (HyperEVM) and a brokerage account (HyperCore) within the same financial institution. Interactions are facilitated exclusively through a set of precompiled contracts, which are hardcoded contracts at fixed addresses that provide a secure and efficient Application Binary Interface (ABI) to the HyperCore state machine. ^{[2] [3]}

Reading State from HyperCore

Smart contracts on HyperEVM can query real-time data from HyperCore using a set of dedicated read precompiles. This allows decentralized applications to access critical protocol information directly within their 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. ^[1]

Writing Actions to HyperCore

To execute state changes on HyperCore, such as placing an order or transferring funds, HyperEVM contracts must interact with the CoreWriter system contract.

• 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.
• Developer Resource: The contract's interface is described in the CoreWriter.sol file. ^[1]

Token Transfers and Linking

The native integration for asset transfers between HyperCore and HyperEVM aims to provide a secure and user-friendly alternative to external bridges.

Core Spot and EVM Spot Tokens

The system distinguishes between two representations of a token within the ecosystem:

• 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. ^[3]

The Linking Process

For a token to be transferable between the two environments, it must be officially linked by its creator, known as the "spot deployer." The process involves several steps to ensure consistency and security:

1. Initiation: The spot deployer begins the process.
2. 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.
3. 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.
4. 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.
5. 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.

At the time of the March 2025 announcement, technical documentation acknowledged risks associated with this process, including the potential for users to interact with unverified contracts and the risk of supply mismatches if not managed correctly by the deployer. ^[3]

Special Case: HYPE Token

The HYPE token, which serves as the native gas token for the HyperEVM layer, follows a unique and simplified transfer process that does not require the formal linking procedure.

• 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.
• HyperEVM to HyperCore: To move HYPE back to the trading layer, a user sends it to the designated system address 0x222 on HyperEVM. An event log generated by this transaction instantly credits the user's balance on HyperCore. ^[3]

Technical Specifications

Interactions with HyperCore from HyperEVM are governed by specific data encoding standards and a defined set of actions and precompiled contracts.

Action Encoding

Actions sent to the CoreWriter contract must follow a specific byte-encoded format to be correctly interpreted and executed by HyperCore.

• Byte 1: Encoding Version. This is an 8-bit integer that allows for future backward-compatible upgrades to the action format. Version 1 is the current standard.
• Bytes 2-4: Action ID. This is a three-byte, big-endian unsigned integer that identifies the specific action to be performed (e.g., place order, deposit vault).
• Remaining Bytes: Action Data. This field contains the raw, ABI-encoded parameters for the specified action. ^[1]

HyperCore Actions from HyperEVM

The following is a list of actions that can be triggered on HyperCore from a HyperEVM smart contract by sending the corresponding encoded data to the CoreWriter contract.

• Action ID 1: Limit order
  • Parameters: (uint32 asset, bool isBuy, uint64 limitPx, uint64 sz, bool reduceOnly, uint8 encodedTif, uint128 cloid)
  • Notes: encodedTif specifies the Time-in-Force: 1 for Alo (All-or-None), 2 for Gtc (Good-til-Canceled), 3 for Ioc (Immediate-or-Cancel). A cloid (client-side order ID) of 0 indicates none is provided.
• Action ID 2: Vault transfer
  • Parameters: (address vault, bool isDeposit, uint64 usd)
  • Notes: Transfers USD collateral to or from a specified vault strategy.
• Action ID 3: Token delegate
  • Parameters: (address validator, uint64 wei, bool isUndelegate)
  • Notes: Delegates or undelegates native tokens to a validator for staking.
• Action ID 4: Staking deposit
  • Parameters: (uint64 wei)
  • Notes: Deposits collateral into the staking contract.
• Action ID 5: Staking withdraw
  • Parameters: (uint64 wei)
  • Notes: Withdraws collateral from the staking contract.
• Action ID 6: Spot send
  • Parameters: (address destination, uint64 token, uint64 wei)
  • Notes: Sends a spot token to another Hyperliquid address.
• Action ID 7: USD class transfer
  • Parameters: (uint64 ntl, bool toPerp)
  • Notes: Transfers USD value between a user's perpetuals margin account and their spot balance.
• Action ID 8: Finalize EVM Contract
  • Parameters: (uint64 token, uint8 encodedFinalizeEvmContractVariant, uint64 createNonce)
  • Notes: Used internally during the creation process of certain contracts.
• Action ID 9: Add API wallet
  • Parameters: (address apiWalletAddress, string apiWalletName)
  • Notes: Manages API wallets. An empty name designates the wallet as the main agent.
• Action ID 10: Cancel order by oid
  • Parameters: (uint32 asset, uint64 oid)
  • Notes: Cancels a specific order using its unique Order ID (oid).
• Action ID 11: Cancel order by cloid
  • Parameters: (uint32 asset, uint128 cloid)
  • Notes: Cancels a specific order using its client-side Order ID (cloid).
• Action ID 12: Approve builder fee
  • Parameters: (uint64 maxFeeRate, address builderAddress)
  • Notes: Approves a maximum fee rate (in decibps, or 1/1000 of a basis point) for a transaction builder.
• Action ID 13: Send asset
  • Parameters: (address destination, address subAccount, uint32 source_dex, uint32 destination_dex, uint64 token, uint64 wei)
  • Notes: An advanced asset transfer with options for specifying sub-accounts and dex routing.
• Action ID 14: Reflect EVM supply change
  • Parameters: (uint64 token, uint64 wei, bool is_mint)
  • Notes: For aligned quote tokens, this action reflects a supply change (mint/burn) from the EVM layer onto the HyperCore state.
• Action ID 15: Borrow/Lend Operation (Testnet-only)
  • Parameters: (uint8 encodedOperation, uint64 token, uint64 wei)
  • Notes: encodedOperation of 0 for Supply and 1 for Withdraw. Used for interacting with a testnet-only borrow/lend protocol.

A comprehensive list of these actions and their technical specifications are available for developers in the Hyperliquid documentation. ^[1]

System Precompiled Contracts

In addition to the CoreWriter, several other precompiled contracts at fixed addresses provide direct access to HyperCore modules from HyperEVM.

• Clearinghouse (0x0...0001): The primary contract for user-level trading interactions, such as depositing and withdrawing funds, and placing or canceling orders.
• Oracle (0x0...0002): Used to query asset price information from HyperCore's native oracle module.
• Vaults (0x0...0003): Provides an interface for interacting with Hyperliquid's native vault strategies.

These precompiles provide a standardized and gas-efficient method for developers on HyperEVM to build applications that are deeply integrated with the core exchange functionality. ^[2]