nexuss
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.
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.