How Hyperliquid Works: Architecture, Order Book, HyperEVM

If you’re building a perpetual DEX or doing some research on how modern perpetual DEXs work, this post is for you. Today we’re going to share our research on Hyperliquid from a technical perspective. We’ll cover its architecture, the HyperCore order book, HyperEVM, and the mechanisms that manage trading, liquidity, and smart contract interactions.

Make sure to follow us on X for more deep dives.

DEX Mechanics Background

Most DEXs on the market work like this: the market price of one asset relative to another is determined by a predefined curve, and liquidity comes from users, called liquidity providers. They supply funds but don’t set prices — pricing happens independently.

Other key features of typical DEXs include:

• Users retain full control over their funds, since most DEXs are built on smart contract systems.
• You don’t need a counterparty to trade — you can execute swaps without waiting for someone to match your order.

Independent pricing, no intermediaries, and self-custody — these are the core principles of decentralization and DeFi.

Now, Hyperliquid is a bit different. It’s often called a “CEX-like DEX.” At first glance, the UI looks and feels like a centralized exchange. It even operates like one in terms of trade execution. Yet, according to the documentation, it remains decentralized. To understand this apparent contradiction, we need to dig deeper into what Hyperliquid really is and how Hyperliquid works.

Hyperliquid Overview

The main feature Hyperliquid provides is its central limit order book (CLOB). Unlike other CEX-style exchanges, it is claimed to be fully on-chain. How did they achieve this? Hyperliquid built a custom blockchain and integrated the order book logic directly into it — creating, matching, and canceling orders all happens natively on-chain.

It’s important to keep in mind that Hyperliquid is not just a CEX-like DEX — it’s also a blockchain. Actually, two. Almost. First, let’s focus on the blockchain part of the protocol before we return to the order book.

Hyperliquid L1 Blockchain and HyperBFT Consensus

Hyperliquid runs its own L1 blockchain using a custom consensus called HyperBFT. The main goal of HyperBFT, as with any blockchain, is to ensure all network participants maintain the same state.

• Consensus happens through leader rotation across multiple rounds: a leader proposes a block, and validators reach agreement via several communication rounds.
• Voting weight is proportional to stake, including delegated deposits, following a familiar DPoS (Delegated Proof-of-Stake) model.
• This mechanism allows the network to continue operating even if some nodes fail or behave maliciously. HyperBFT provides Byzantine Fault Tolerance (BFT), meaning the blockchain can resist up to ⅓ of validators acting maliciously.

Hyperliquid Architecture: HyperCore and HyperEVM

What we’ve covered so far, might sound quite standard — until you learn that the Hyperliquid blockchain state is split into two parts: HyperCore and HyperEVM.

• This split creates two distinct execution environments while keeping them synchronized.
• Security for both environments is enforced by the same HyperBFT consensus, which makes the design particularly interesting.

Let’s take a closer look at the high-level diagram below.

‍

The diagram illustrates four Architecture layers (from bottom to top):

1. Frontend layer – the application interface.
2. Application logic layer – the internal logic driving trading and operations.
3. Execution environment layer – the HyperCore and HyperEVM execution environments.
4. Consensus layer – HyperBFT ensures state consistency.

Even though there are two execution environments, they both operate under the same consensus. According to the docs, this setup lets you access data stored in HyperCore directly from HyperEVM. It’s especially interesting when you look at exactly what data is available and what HyperCore and HyperEVM actually do. Let’s dive in.

Hyperliquid On-Chain Trading Engine – HyperCore

HyperCore is the most substantial and technically important part of the Hyperliquid protocol. In practice, this is the DEX itself — and at the same time, it is the Hyperliquid Layer 1 blockchain introduced earlier.

Conceptually, HyperCore is a high-performance trading engine implemented directly at the blockchain level. It is designed to provide a trading experience comparable to centralized exchanges, while keeping all core mechanics on-chain.

What Is Hyperliquid HyperCore

HyperCore is a fully on-chain central limit order book (CLOB).
It maintains the complete state of every order across all trading pairs and is fully responsible for:

• order creation
• order cancellation
• order matching
• trade execution

There is no hidden order book and no off-chain matching layer. Every order and every trade is reflected directly in the blockchain state.

Each action — placing an order, canceling it, or executing a trade — is a blockchain transaction. The entire trading lifecycle is part of the canonical chain state.

How Hyperliquid Implements a Fully On-Chain Order Book

A key design choice in HyperCore is that order matching logic is embedded directly into the consensus process.

Hyperliquid Order matching logic

Orders are matched strictly according to price-time priority:

• orders with better prices are executed first
• among orders at the same price, earlier orders take precedence

This deterministic matching rule is critical in a blockchain setting. All validators must independently arrive at the exact same result when processing the same set of orders. By enforcing a single canonical matching outcome, HyperCore guarantees state consistency across the network.

Hyperliquid Sub-Second Finality and Throughput

Latency and throughput are especially important for trading systems. Even small delays directly affect execution quality and user experience.

At first glance, an on-chain order book raises obvious concerns:
blockchains are known for slow confirmations and limited throughput. After all, we know how long it can sometimes take for a transaction to be confirmed…

HyperCore is designed specifically to address this.

How Hyperliquid Order Latency Is Managed in on chain CLOB

HyperCore is implemented using a Rust-based virtual machine optimized for trading logic. Combined with the custom HyperBFT consensus, this allows the system to reach:

• sub-second order finality, with an average of ~0.2 seconds observed during testing
• throughput of up to 200,000 orders per second, with room for further optimization

These performance characteristics are possible because order matching and related operations are native HyperCore operations, not expensive EVM calls.

Why HyperCore Is Not an EVM DEX

An important distinction is that HyperCore does not rely on the EVM for its core trading logic. Matching orders inside the EVM would introduce unnecessary overhead and limit performance.

Instead, HyperCore defines its own execution environment tailored specifically for trading. This is what allows Hyperliquid to combine:

• deterministic on-chain execution
• CEX-like performance characteristics

In the next section, this separation becomes even more important when we look at how HyperCore interacts with HyperEVM.

How Hyperliquid HyperCore Works

To understand how Hyperliquid works, we need to go deeper into HyperCore.At this stage, the order-matching logic is only part of the picture. HyperCore also defines what can be traded and how different market types behave. To do that, let’s look at the next diagram.

‍

Hyperliquid Trading Interface and System Architecture

The upper part of the diagram represents the user-facing interface.

From a trader’s perspective, it looks exactly like a centralized exchange UI. Order forms, charts, positions, and balances all behave as expected.

Rather than treating this as just a frontend, it’s useful to read the interface as a map of Hyperliquid’s features. Each visible action in the UI corresponds to concrete logic implemented inside HyperCore.

This makes the diagram a good entry point for understanding how the protocol is structured internally.

Spot and Perpetual Markets in Hyperliquid

Up to this point, we focused mainly on spot trading.
The diagram makes it clear that Hyperliquid also supports perpetual futures, or perps.

The difference matters:

• Spot trades exchange one asset for another immediately
• Perpetuals represent leveraged positions that stay open indefinitely

Because of this, perpetual markets require a different settlement and collateral model.

How Perpetual Positions Are Collateralized on Hyperliquid

All perpetual positions on Hyperliquid are collateralized in USDC.
This applies across markets and simplifies accounting inside HyperCore.

Using a single collateral asset provides:

• Consistent margin calculations
• Clear liquidation thresholds
• Standardized risk parameters across markets

This design choice reduces complexity at the execution layer and makes state transitions easier.

Leverage Mechanics in Hyperliquid Perpetual Markets

A defining feature of the perpetual market is leverage.Traders can open positions larger than their deposited collateral by borrowing against it.

In Hyperliquid, maximum leverage depends on order size and order type.

For market orders:

• ~$15M notional → leverage ≥ x25
• ~$5M notional → leverage x20–25
• ~$2M notional → leverage x10–20
• ~$500K notional → lower leverage tiers

For limit orders:

• Maximum leverage is capped at x10

This structure increases flexibility for traders while limiting systemic risk.

Risk and Liquidation Considerations

Higher leverage expands trading possibilities, but it also increases liquidation risk.
Because all positions are tracked on-chain inside HyperCore, margin requirements and liquidation logic are enforced deterministically.

There is no discretionary intervention. Once conditions are met, state transitions follow predefined rules validated by the network.

This ties the perpetual trading model directly back into HyperCore’s execution guarantees.

How margin management works in Hyperliquid

To correctly manage margin, prevent undercollateralized trades, and execute liquidations, Hyperliquid relies on a dedicated component called the clearinghouse.
If you look at the diagram, it sits directly below the main trading interface and acts as the core accounting layer for both perpetual and spot markets.

Hyperliquid supports two margin modes for perpetuals:

• Isolated margin: margin is limited to a single position
• Cross margin: a shared margin pool across all open perpetual positions

The clearinghouse is responsible for enforcing both models consistently.

What the Clearinghouse Does in Hyperliquid

The clearinghouse functions as the central risk and accounting engine of Hyperliquid.
Every critical operation, from deposits to liquidations, passes through this component.

Below is a breakdown of its responsibilities.

Balance and Position Management

The clearinghouse tracks all user balances and open positions.

This includes:

• User deposits and withdrawals
• Margin balances
• Open positions across perpetual and spot markets

State changes are validated centrally to ensure positions always remain properly collateralized.

Leverage and Margin Enforcement

The clearinghouse enforces leverage limits and margin requirements.

It validates margin sufficiency twice:

1. When an order is submitted
2. Immediately before execution

It also manages:

• Initial margin: required to open a position
• Maintenance margin: minimum collateral needed to keep a position open

This double-check mechanism prevents undercollateralized execution.

Liquidation Logic

Liquidations are fully handled by the clearinghouse.

It continuously monitors account equity.

When a trader’s balance drops below the maintenance threshold, the clearinghouse initiates liquidation to prevent insolvency.

There is no manual intervention. Liquidations follow deterministic rules enforced at the protocol level.

Funding Rate Calculation

The clearinghouse calculates the funding rate for perpetual markets. The goal is to keep perpetual prices aligned with the underlying spot price.

Funding transfers value between long and short positions to correct market imbalance.

We will analyze the funding mechanism in detail later, since it plays a critical role in how Hyperliquid perpetuals behave.

Oracle Integration and Price Formation

Price accuracy in Hyperliquid is enforced directly at the blockchain level.
The clearinghouse integrates with an oracle system where prices are computed by validators.

Each validator submits an asset price calculated as a weighted average of spot prices from major exchanges:

• Binance (weight 3)
• OKX (weight 2)
• Bybit (weight 2)
• Kraken (weight 1)
• KuCoin (weight 1)
• Gate IO (weight 1)
• MEXC (weight 1)
• Hyperliquid (weight 1)

The final price used by the clearinghouse is then computed as a weighted average across all validators.
Validator weight depends on their own stake plus delegated deposits.

This design embeds price discovery directly into consensus, rather than relying on an external oracle provider.

Why the Clearinghouse Is Central to How Hyperliquid Works

In practice, the clearinghouse is the enforcement layer of the entire protocol.

It connects:

• User actions from the interface
• Market execution logic
• Margin safety and liquidation guarantees
• Oracle-driven price accuracy

Understanding Funding Rate for Perpetuals

Above, we mentioned the concept of funding rate. Let’s explain what it is.

What is funding rate

Funding rate is a mechanism that keeps perpetual prices close to the underlying spot market. It ensures that Hyperliquid’s perpetuals remain fairly priced and balances incentives between long and short traders.

How Funding Rate Works

The mechanism operates as follows:

• Perp price above spot: long holders pay short holders.
• Perp price below spot: short holders pay long holders.
• The amount exchanged between parties is called the funding rate.

This system incentivizes traders to take positions that stabilize the perp price relative to the spot market.

Hyperliquid Funding Rate Formula

Funding rate is calculated using the formula:

Funding Rate = Average Premium Index(P) + clamp(Interest Rate - Premium Index(P), -0.0005, 0.0005)

Where:

• Premium Index (P): the difference between the impact price (how the price moves due to trades) and the oracle price.
• Interest Rate: fixed at 0.01%.
• Clamp: limits sharp deviations between the Interest Rate and Premium Index to the range [-0.0005, 0.0005], preventing sudden spikes.

Hyperliquid Funding Rate Payment Frequency and Market Effect

• On Hyperliquid, funding is paid every hour.
• This maintains a continuous link between perp and spot prices and prevents significant divergence.
• The mechanism encourages traders to take positions (long or short) that help balance the perp price with the underlying asset.

Funding Rate as a System Correction Tool

Funding rate acts as a corrective instrument in Hyperliquid:

• Keeps perp quotes close to fair value
• Balances the interests of long and short holders
• Maintains market stability while preserving alignment with spot prices

Hyperliquid Order Types and Placement Options

Let’s get back to the UI diagram. It seems the only thing we have not mentioned yet is the types of orders Hyperliquid supports.

Order Types Supported on Hyperliquid

Hyperliquid supports a range of orders, all processed on-chain by the HyperCore engine:

• Market Order: executes immediately at the current market price.
• Limit Order: executes at a specified price or better.
• Stop Market Order: a market order triggered when the price reaches a stop level, used for limiting losses or taking profits.
• Stop Limit Order: a limit order activated at a selected stop price.
• TWAP (Time-Weighted Average Price): splits a large order into smaller sub-orders executed over intervals to minimize market impact.
• Scale Orders: places multiple limit orders within a chosen price range to capture volatility efficiently.

Order Placement Options on Hyperliquid

Users can further customize order behavior using these options:

• Reduce Only: ensures the order only reduces an existing position rather than opening a new one in the opposite direction.
• Good Til Cancel (GTC): the order stays in the book until executed or manually canceled.
• Post Only (ALO): adds the order to the book without immediate execution.
• Immediate or Cancel (IOC): cancels the order if it cannot be executed immediately.
• Take Profit (TP): triggers a market or limit order to close a position at a specified profit level.
• Stop Loss (SL): triggers a market or limit order to close a position when a specified loss threshold is reached.

On-Chain Orders Processing within HyperCore

As we already mentioned, all of these order types and options are handled on-chain by HyperCore. This means:

• Every order, modification, and execution is recorded in the blockchain state.
• Users get the familiar CEX trading functionality while maintaining the transparency, determinism, and auditability of a fully on-chain DEX.

From HyperCore to HyperEVM

We’ve gone through HyperCore and seen that it acts as a high-performance, on-chain order book for trading and tracking asset prices.

Now, let’s look at HyperEVM. The official documentation describes it not as a separate blockchain, but as an extension of the Hyperliquid L1 blockchain, secured by the same HyperBFT consensus.

For developers, HyperEVM provides a familiar EVM environment. This means you can write and deploy smart contracts just like on Ethereum, while still using the same blockchain that powers HyperCore.

How Hyperliquid HyperEVM works

HyperEVM uses the Cancun hard fork, ensuring full compatibility with existing Ethereum tools and development practices. In particular, EIP-1559 is enabled in HyperEVM.

• Base fees are burned in the standard way, reducing the total supply.
• Unlike most other EVM chains, priority fees are also burned, thanks to HyperEVM’s HyperBFT consensus. These burned priority fees are sent to the zero address.

HyperEVM Block Structure:

HyperEVM has a unique block architecture, split into small and large blocks:

• Small blocks
  
  • Up to 2 million gas
  • Processed every second
  • Ideal for fast transactions and quick order confirmations
• Large blocks
  
  • Up to 30 million gas
  • Processed roughly every minute
  • Suited for complex contract execution without congesting the network

This structure allows users and developers to choose the priority for their operations: traders can rely on small blocks for near-instant order execution, while developers can deploy large contracts efficiently.

How HyperEVM Works with HyperCore Data

‍

‍

One of the most notable features of HyperEVM is how it interacts with HyperCore. Through HyperEVM, developers can access key on-chain data from HyperCore, including:

• Asset prices
• Open orders and trade history
• User balances and validator deposits
• Blockchain metadata, such as block numbers

But the integration goes beyond reading data. HyperEVM can also write data to HyperCore, allowing smart contracts to:

• Manage orders directly
• Execute trades on-chain
• Interact with the trading engine in real-time

This means smart contracts can function as active market participants, performing structured and predictable operations while retaining the security guarantees of HyperCore.

For developers, this opens a wide range of possibilities for building decentralized applications that directly leverage liquidity and order book data, bridging trading functionality with smart contracts.

Wrapping up

Hyperliquid combines traditional exchange mechanisms with on-chain smart contract functionality, forming an integrated financial system. The combination of HyperCore and HyperEVM allows developers and users to:

• Directly interact with the order book and liquidity from smart contracts
• Access and update trading data, including balances, open orders, and validator deposits
• Build decentralized applications that operate within the constraints of the HyperCore trading engine

This integration provides a consistent environment where trading logic and market operations remain deterministic while enabling experimentation with smart contracts.

Overall, Hyperliquid illustrates a model where on-chain markets and programmable financial logic coexist. The architecture supports transparent trading, predictable risk management, and interaction with liquidity, offering a structured framework for future developments in DeFi protocols.

About Rock’n’Block

Rock’n’Block is a Web3-native development studio focused on building production-grade blockchain infrastructure and decentralized applications. We work with founders to deliver high-performance systems, scalable user experiences, and reliable solutions in competitive crypto markets.

Follow us on X for more technical insights and deep dives

What We Do

• Custom Layer-1 Chains & DeFi Protocols – we build blockchain networks from the ground up, including consensus mechanisms, tokenomics, and governance models.
• Decentralized Perpetual Exchanges – Design and deploy sophisticated perpetual DEXes with on-chain order books, margining, funding rate mechanisms, and oracle integration. Learn more through our perpetual dex development services for a detailed overview.
• Blockchain Data & Analytics – Index and stream real-time and historical blockchain data for trading, analytics, and protocol monitoring.
• Cross-Chain Financial Infrastructure – Integrate smart contracts, payment rails, and chain-agnostic tools to support flexible financial workflows.

Our team brings nearly a decade of hands-on blockchain experience, supporting products with 71M+ DeFi users, protocols exceeding $2.5B in total market capitalization, and assisting partners in raising $167M.

Key Takeaways

• How Hyperliquid Works: Hyperliquid operates as a CEX-like DEX built on its own L1 blockchain. Its architecture separates trading logic (HyperCore) from smart contract execution (HyperEVM) while maintaining a unified HyperBFT consensus.
• Hyperliquid Matching Engine: Orders are matched on-chain using deterministic price-time priority rules. This ensures consistent outcomes across validators without off-chain execution.
• Hyperliquid Order Latency: HyperCore leverages a Rust-based VM and HyperBFT consensus to deliver sub-second order finality (~0.2s average) and high throughput (up to 200,000 orders/sec), keeping latency low even for complex on-chain trades.
• Hyperliquid Funding Rate: Funding rates are calculated hourly using the formula:
  Funding Rate = Average Premium Index (P) + clamp(Interest Rate – P, -0.0005, 0.0005). This aligns perpetual prices with the underlying spot market and balances incentives between long and short traders.
• Hyperliquid Perpetual Futures: All perpetual positions are collateralized in USDC. Maximum leverage depends on order size and type (market vs. limit), with isolated and cross-margin modes enforced deterministically by the clearinghouse.
• Hyperliquid Leverage Limits: Market order leverage ranges from ~x10 to ≥x25 depending on notional size, while limit orders are capped at x10. This ensures flexibility while controlling systemic risk.
• Hyperliquid Latency & Technical Architecture: The separation of HyperCore and HyperEVM allows both high-performance trading and programmable smart contracts without sacrificing determinism or security.
• Integration of HyperCore & HyperEVM: Smart contracts on HyperEVM can read and write market data from HyperCore, manage orders, execute trades, and participate directly in the on-chain market.
• Hyperliquid Explained: The combination of a CEX-like interface, fully on-chain order book, predictable funding rate, and programmable smart contracts illustrates a model where on-chain markets and DeFi logic coexist seamlessly.
• Hyperliquid technical architecture
  The protocol is structured in layers:‍
  
  • Frontend Layer – UI for trading and account management.‍
    
  • Application Logic Layer – business logic for trading, margining, and funding.‍
  • Execution Environment Layer – HyperCore (trading engine) and HyperEVM (smart contracts).‍
  • Consensus Layer – HyperBFT ensures all state changes are consistent across validators.‍
    

We ♥️ Development

‍

‍