Understanding Hyperliquid's Architecture: HyperBFT, HyperCore, and HyperEVM (Part 1)

Introduction

If you've been using Hyperliquid for a while as a developer or a trader, you’ve probably seen these three words everywhere: HyperBFT, HyperCore, and HyperEVM.

They appear in the documentation, in technical threads on X, in conversations between devs… and yet it's still very easy not to have a clear picture of what each one actually is or how they fit together.

And of course, Hyperliquid is growing fast. Everyone is talking about it, and you don't want to feel like you're missing something important.

You've probably opened the official docs at some point, looked at the famous Hyperliquid Stack diagram, and thought something like:

"Okay… I think I get it… but not entirely 🤔"

This is usually where the confusion starts. Not because the diagram is wrong, but because it mixes consensus, execution, and application concepts into a single image. If you don't already have the right mental model, it's very easy to get lost.

That's why I wrote this article. This is the first part of a two-part series, aimed at developers, technical traders, and founders who want to truly understand Hyperliquid.

→ In Part 1, we're going to build the correct mental map:

what each layer/component is,
why it exists,
and what responsibility it has.

→ Part 2 is where we'll get our hands dirty: how these layers actually communicate, what the limits are, and how you build on top without breaking anything.

With that said… let's get started 🦾.

1. Starting from the base: HyperBFT

The foundation of the entire stack is HyperBFT, Hyperliquid's native consensus algorithm.

Its job is very simple, but absolutely critical: making sure all nodes agree on which block comes next, what it contains, and when that block is final.

Without this, nothing built on top of the stack would be stable.

HyperBFT is inspired by HotStuff, a consensus algorithm designed for blockchains that need speed. The key idea behind HotStuff is achieving consensus without every validator constantly talking to every other validator (something that introduces a lot of latency in other systems).

Because of this, HotStuff (and by extension HyperBFT) provides:

low latency,
high throughput,
BFT security,
and fast finality (once a block is finalized, it won't be reverted, goodbye reorgs 👋🏻).

Hyperliquid took this model, optimized it, and built HyperBFT: a version tailored to support very high execution throughput in a reliable and deterministic way.

2. Hyperliquid has two engines, not one

It's no coincidence that above HyperBFT you see two distinct blocks: HyperCore and HyperEVM. That's already an important clue, Hyperliquid does not execute everything in a single engine, like most blockchains do.

In a traditional EVM-based chain, everything runs in the same place: smart contracts, financial logic, and state updates.

That model works well for general-purpose applications. But as soon as you try to run a serious exchange inside it, two problems show up immediately: latency and gas contention.

Running an on-chain CLOB with the latency and consistency requirements Hyperliquid has, inside a traditional EVM, is like trying to race in Formula 1 with a street car. It might start, but it won't win 🥵.

Hyperliquid chose a different path and split its system into two distinct engines, each with a very clear purpose, while still living inside the same L1:

HyperCore: the pure financial engine
HyperEVM: the smart contract environment

HyperCore is where real trading happens. It's designed exclusively to run a high-speed exchange in a deterministic and node-consistent way.

HyperEVM came later to solve a different problem: allowing builders to create arbitrary logic with smart contracts without ever touching the financial core.

Thanks to this separation of responsabilities, it's possible to build around Hyperliquid without putting the order book, liquidations, or critical system state at risk.

This design decision also explains why Hyperliquid can maintain low latency without compromising the coherence or security of its financial state.

Even though HyperCore and HyperEVM are separated, they share the same consensus (HyperBFT) and the same blocks, while maintaining completely independent state.

How Blocks Work in Hyperliquid

Although the official documentation does not describe this in a single, explicit section, the following execution model can be inferred from how Hyperliquid structures its L1 and HyperEVM execution.

Hyperliquid has a single L1 block sequence finalized by HyperBFT. All core financial state transitions (HyperCore) are anchored to this L1 block stream.

On top of this L1 timeline, HyperEVM execution is scheduled using two types of EVM execution blocks:

Small EVM blocks, produced frequently (currently every second), intended for regular transactions and lightweight contract interactions.
Large EVM blocks, produced at a slower cadence (currently every minute), designed to include larger transactions such as contract deployments or more complex logic.

Not every L1 block produces an EVM block. However, when an EVM block is produced (small or large), it is derived from and finalized under the same L1 block ordering and consensus.

This design allows Hyperliquid to decouple block speed from block size for HyperEVM execution, while keeping a single, coherent L1 state and consensus.

The key example: a trade

To make this concrete, let's think about something very specific: a trade.

A user submits an order, and that order enters block N of Hyperliquid.
At this point, HyperCore is responsible for all financial execution.
This is where everything financial happens: the order enters the order book, gets matched, executed, balances and positions are updated, and if risk conditions require it, a liquidation is triggered.
Once HyperCore has processed the block, the financial state associated with block N is final and deterministic.
If that L1 block includes HyperEVM execution (small or big EVM block), smart contracts can observe that finalized trade and execute logic on top of it.

There are no parallel blocks. No asynchronous execution. No such thing as "the contract executed before the trade was final."

Everything moves block by block, in the same order, under the same consensus.

3. HyperCore: the financial engine optimized for trading

At this point, it should be clear that HyperCore is "where real trading happens."

But it's important to understand that HyperCore is not just another module or a giant smart contract. It's the financial state machine of the L1.

This is where everything lives that, if it breaks… we’re all going to feel it 🥲.

In the Hyperliquid Stack diagram shown earlier, you'll see five columns inside HyperCore: Spot, Perps, Oracles, Vaults, and Governance.

But to understand those properly, we first need to look at two key internal components: Matching engine and Clearinghouse.

3.1 Matching engine and Clearinghouse

The matching engine is the component that decides which orders match, at what price, with what priority, and in what exact sequence.

Every exchange has one and Hyperliquid is no exception. But there's a crucial difference: it's not designed to maximize volume or favor the fastest trader.

It's designed to protect the retail user experience.

To achieve that, the L1 itself enforces strict execution ordering rules. For example, cancellations and post-only orders are prioritized over taker orders. This avoids a classic problem: executing against an order that no longer wanted to be filled.

The result is a healthier market: less toxic flow, tighter spreads, and fairer execution.

These kinds of rules cannot be implemented with a simple smart contract. They require the matching engine to live inside the L1's financial engine, with execution order enforced by consensus.

The clearinghouse, on the other hand, is responsible for updating all financial state after each trade: positions, balances, PnL, margin, and risk.

If margin becomes insufficient, the liquidation is triggered directly from HyperCore.

3.2 What you see in the Hyperliquid Stack... and what it actually means

Spot

The Spot column represents a traditional spot market like you'd see on a CEX. It includes an on-chain order book, the matching engine that executes orders, and the clearinghouse that adjusts balances after each trade.

It's a full spot exchange but executed inside the L1, without opaque components.

Perps

The Perps column uses the same engine as Spot, with an additional layer of financial logic: positions, margin, risk, and liquidations. It also has its own order book, just like Spot.

Oracles

The diagram shows "Oracles" in plural for a reason. Hyperliquid doesn't rely on a single external feed or an EVM-deployed oracle contract.

Price logic lives directly inside HyperCore and is part of the L1 state. Its role is to maintain coherent price references for each asset.

All nodes use these references to calculate PnL, evaluate risk, decide liquidations, and ensure everyone executes the exact same state.

Based on these price references, the system can determine whether a position is healthy or about to be liquidated.

Vaults

Hyperliquid has two distinct types of vaults.

On one side, there are protocol vaults, the most important being the Hyperliquidity Provider (HLP). HLP is a protocol-native vault that acts as a system-level economic actor: it provides liquidity via protocol-defined market-making strategies, participates in liquidation processes managed by HyperCore, supplies USDC to the Earn mechanisms, and accrues a portion of trading fees.

On the other side, there are user vaults, which allow traders to create vaults where other users can deposit capital and gain exposure to their strategies. Even though they are user-created, they are not contracts or DeFi products deployed on the EVM, they are a native exchange feature, managed directly by HyperCore.

Governance

Governance is also not a contract and does not live in HyperEVM.

It's part of the L1 state because it controls parameters that directly affect the financial engine: risk rules, market activation, leverage limits, internal adjustments, and more.

These are the rules of the exchange, embedded inside HyperCore to ensure all nodes apply exactly the same logic, avoid inconsistent states, and keep execution fully deterministic.

For example, if the protocol activates a new market or updates a risk parameter, that change must apply simultaneously across all nodes. That's why governance lives inside HyperCore and not in a smart contract.

3.3 HyperCore in one sentence

If we had to summarize HyperCore in a single sentence, it would be this:

HyperCore is the financial engine of the Hyperliquid L1.

This is where everything that truly matters in an exchange lives: the order book, matching, positions, risk, PnL, liquidations, and internal protocol rules.

It's fast, deterministic, and consistent across nodes.

It does not execute smart contracts, it does not compete for gas, and it does not rely on external bots to function correctly.

Its state is fully transparent, anyone can inspect order books, trades, liquidations, or positions. But its implementation is private: you can verify what it does, but not how it's written internally.

In short: HyperCore is what makes Hyperliquid a real exchange… fully on-chain.

4. HyperEVM: the permissionless smart contract environment

If HyperCore is the financial engine, HyperEVM is the creative space.

It's a general-purpose, permissionless virtual machine where builders can deploy smart contracts to build logic around the exchange without touching the financial core.

So if you know Solidity, you'll feel right at home 😌.

4.1 The HyperEVM columns: what they represent (and what they don't)

In the Hyperliquid Stack diagram shown earlier, you'll see five columns inside HyperEVM: Borrowing & Lending, Auctions, Native Stablecoins, Bridges, and "And more applications". Unlike the columns in HyperCore, these do not represent protocol components. Instead, they describe types of applications that can be built on HyperEVM.

Borrowing & Lending

This does not mean HyperEVM includes a native DeFi lending market.

By default, HyperEVM does not ship with lending protocols, liquidity pools, or interest systems. It simply provides the environment for builders to deploy them using smart contracts.

HyperCore does include internal borrowing and supply primitives used exclusively for its margin system (currently in testnet), but this is not a traditional DeFi lending market.

The HyperEVM layer is where full lending protocols can be deployed: money markets, lending pools, yield strategies, or more complex credit products using assets from HyperCore.

Auctions

What this column indicates is that HyperEVM is where arbitrary auction mechanisms can be built using smart contracts, outside the protocol's native financial engine.

Hyperliquid does use native auctions for very specific cases, for example HIP-1 and HIP-3 token deployment,but those mechanisms are part of HyperCore's internal logic and are not exposed as general, reusable primitives.

Native Stablecoins

This column indicates that HyperEVM is where permissionless stablecoins can be built.

For example, collateralized/over-collateralized stablecoins, or hybrid models using multiple assets.

The key point is that even if a stablecoin is deployed on HyperEVM, it does not automatically become part of the protocol core. It cannot be used directly for margining, risk calculation, or liquidations.

All of that remains the exclusive responsibility of HyperCore.

Bridges

This column is often misinterpreted. Hyperliquid already has a critical L1 bridge that connects it to the outside world.

This column refers to the fact that HyperEVM also allows builders to create additional bridges and connectivity systems.

And more applications

Personally, this column could just as well be called "The sky's the limit".

It's a clear statement of intent: the Hyperliquid team can't predict what will be built on top, but they've designed the protocol to make it possible.

HyperEVM isn't designed for a closed set of use cases. It's an environment where applications that don't even exist yet can emerge.

And yes, many of the most interesting things we'll see built on Hyperliquid in the future will probably live in this column.

Closing

Up to this point, we've built the correct mental map of the Hyperliquid stack 🧠.

You now know what HyperBFT is, why Hyperliquid separates HyperCore and HyperEVM, and what responsibility each layer has. And just as importantly, you also know what each layer is not.

HyperCore is the financial heart: strict, deterministic, and obsessed with coherence.
HyperEVM is the creative space: permissionless, flexible, and designed so builders can experiment without putting the exchange at risk.

But understanding the architecture isn't enough if you want to build on top.

In Part 2, we'll go deeper: how HyperCore and HyperEVM actually communicate, what a smart contract can and cannot do, and why Hyperliquid has made such unusual, but very intentional, design decisions.

If Part 1 gave you the map, Part 2 will show you how to move through the terrain 😏.

References & Further Reading

Hyperliquid Documentation
https://hyperliquid.gitbook.io/hyperliquid-docs

HyperCore Overview
https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore

HyperEVM Overview
https://hyperliquid.gitbook.io/hyperliquid-docs/hyperevm

Thinking of building on Hyperliquid or launching a DeFi project?

Zealynx specializes in smart contract audits and blockchain security assessments. If you want to make sure your integration is secure and future-proof, reach out for a friendly chat or connect on Twitter with us @sudosuberenu and @TheBlockChainer.

FAQ

1. Is Hyperliquid a CEX or a DEX?

Hyperliquid is a fully on-chain DEX (decentralized exchange). Unlike CEXs where custody, order matching, and settlement happen on private servers, Hyperliquid runs everything on its own L1 blockchain. You retain custody of your funds, and every order and trade is transparently recorded on-chain. It combines the speed and UX of a CEX with the transparency and self-custody of a DEX.

2. Is Hyperliquid an L1 or L2?

Hyperliquid is a purpose-built Layer 1 blockchain. It runs its own consensus mechanism (HyperBFT) and does not settle to Ethereum or any other chain. This design gives Hyperliquid full control over block production, execution speed, and transaction ordering—enabling the sub-second finality required for a competitive exchange.

3. What is the difference between HyperCore and HyperEVM?

HyperCore is the native financial engine where all trading happens—order books, matching, positions, margin, and liquidations. It's not a smart contract; it's built directly into the L1 for speed and determinism. HyperEVM is a separate, permissionless EVM environment where developers can deploy Solidity contracts. Both share the same consensus and block sequence but maintain independent state.

4. How fast is Hyperliquid?

Hyperliquid achieves sub-second block times with instant finality—once a block is finalized, it cannot be reverted. There are no reorgs or confirmation waits. The HyperBFT consensus enables this speed while the dual-engine architecture ensures trading operations in HyperCore don't compete with smart contract execution for block space.

5. What is a CLOB and why does Hyperliquid use one?

A CLOB (Central Limit Order Book) matches buy and sell orders by price and time priority—the same model used by traditional stock exchanges and CEXs. Hyperliquid uses a fully on-chain CLOB instead of an AMM because it offers tighter spreads, better price discovery, and familiar trading mechanics (limit orders, stop-losses, etc.) for serious traders.

6. Can I build DeFi apps on Hyperliquid?

Yes. HyperEVM is a permissionless EVM where anyone can deploy Solidity smart contracts without approval. You can build lending protocols, stablecoins, vaults, or any DeFi application. Your contracts can observe HyperCore's trading state (prices, positions, balances) but cannot directly modify the financial engine—this separation protects exchange stability while enabling innovation.

Glossary

Term	Definition
HyperBFT	Hyperliquid's HotStuff-inspired BFT consensus layer that finalizes the L1 block sequence with fast finality and no reorgs.
HyperCore	Hyperliquid's native financial execution engine running spot, perps, risk, and liquidations outside the EVM for deterministic, low-latency trading.
HyperEVM	Permissionless EVM environment on Hyperliquid for smart contracts that observe and extend HyperCore state without affecting the financial core.
Small EVM Block	High-frequency HyperEVM execution block (~1s cadence) for regular transactions and lightweight contract calls.
Large EVM Block	Lower-frequency HyperEVM execution block (~1min cadence) intended for heavier transactions like contract deployments.
Clearinghouse	Exchange component that updates balances, positions, margin, and PnL after trades and triggers liquidations when risk thresholds are breached.
Hyperliquidity Provider (HLP)	Protocol-native vault providing liquidity via market-making strategies, participating in liquidations and Earn mechanisms as a system-level actor.

View complete glossary →

Understanding Hyperliquid's Architecture: HyperBFT, HyperCore, and HyperEVM (Part 1)

Introduction

1. Starting from the base: HyperBFT