How a Perpetual Futures Exchange Is Actually Built

I've been trading perps for a while now. I wrote about what perpetual futures are and how funding rates work. But the whole time I had this nagging question I couldn't answer: how is this thing actually built?

Not what a perp does. How the machine works underneath. How does an order become a position? How does the system know when to liquidate you? Where does the mark price come from — like, at the protocol level? What happens in the two seconds between "my margin is getting low" and "my position is gone"?

I went looking for answers and ended up inside Hyperliquid's documentation, architecture wiki, and a pile of post-mortems. Hyperliquid is the case study because it's the one perps engine you can actually inspect — it's on-chain, it's the highest-volume DEX (as of March 2026), and its architecture is publicly documented. A CEX matching engine is a black box. Hyperliquid is the same machine with the panels off.

What I found: a perpetual futures exchange is five interlocking engines. Every exchange — CEX or DEX — has the same five. The differences are in where they run and who controls them. Let me walk you through each one.

Engine 1: The Matching Engine — Where Orders Become Trades

This is the heart. Every exchange starts here.

Hyperliquid runs a Central Limit Order Book (CLOB) — the same structure Binance, the NYSE, and every traditional exchange uses. Orders line up by price. Best prices execute first. Among equal prices, whoever arrived first fills first. Price-time priority. Nothing exotic.

What's architecturally different: the matching engine runs inside blockchain consensus. Every order, every cancel, every fill is a blockchain transaction that the validator set agrees on. One-block finality from HyperBFT (their custom BFT consensus, derived from HotStuff). Written in Rust, executing at the protocol level — not a smart contract sitting on top of a general-purpose chain.

This was the first thing that clicked for me. Hyperliquid didn't deploy on Ethereum or Arbitrum or Solana. They built an entire Layer 1 blockchain from scratch, specifically so the matching engine could be the protocol rather than compete for blockspace with every other dApp.

The performance numbers: 200,000 orders per second, ~200ms median latency, with a design target beyond 1 million ops/sec (as of March 2026). For context, Binance's matching engine handles 1.4 million orders per second at sub-millisecond latency with colocation. Hyperliquid is in the same order of magnitude on throughput but 2-3 orders of magnitude slower on latency. That's the tradeoff: you get transparency and self-custody, you give up speed.

Hyperliquid's own framing: "a system is only as decentralized as its most centralized component." An exchange with on-chain funds but off-chain matching is, they argue, really a centralized exchange with decentralized custody. Whether you buy that argument or not, it explains why they went all-in on putting the order book inside consensus.

Sources: Hyperliquid Docs, Hyperliquid - Why an onchain order book matters, HyperBFT Wiki

Engine 2: The Clearinghouse — Your Account's Referee

The clearinghouse is the part I didn't know existed as a separate system until I read the docs.

It tracks margin and position data for every address. It enforces leverage limits. It validates that you actually have enough collateral — and here's a detail that surprised me — it checks margin at two points: when your order is submitted AND immediately before execution.

Why twice? Because the price can move between those moments. You submit a limit order with sufficient margin, the market moves, and by the time your order matches, your margin is no longer adequate. The double-check prevents this race condition. Simple idea, critical for system integrity.

The clearinghouse handles margin modes too. Cross margin (the default) pools collateral across all your positions — more cushion but one bad trade drains everything. Isolated margin fences each position separately. There's also portfolio margin, which unifies spot and perp trading — you can borrow against spot holdings to margin perp positions, with continuous interest accrual. Capital efficiency that previously only existed on CEXs.

Contract specs are interesting in the details. All Hyperliquid perps are linear (USDT-denominated pricing, USDC collateral). This technically makes them quanto contracts — there's an implicit USDT/USDC basis risk that would matter in a stablecoin depeg. Maintenance margin is set at half of initial margin at max leverage, scaling up in tiers as position size grows. For BTC and ETH, the first tier threshold is around $100-150 million notional. For smaller assets, tiers kick in at $3-20 million.

One constraint I found notable: orders cannot rest further than 1% from the oracle price. This limits the ability to place destabilizing orders far from fair value — a guardrail that only makes sense once you understand the pricing engine.

Sources: Hyperliquid Docs - Clearinghouse, Hyperliquid Docs - Margining, Hyperliquid Docs - Margin Tiers

Engine 3: The Oracle and Mark Price — Where Truth Comes From

This is the engine that blew my mind a little when I saw how many layers it has.

I wrote about mark price in my perps overview — it's the price used for liquidations, margining, unrealized PnL. Not the last traded price, but a manipulation-resistant estimate of fair value. What I didn't know then was how deep the anti-manipulation design goes.

Layer 1: The oracle. Every 3 seconds, each Hyperliquid validator publishes a spot price for every listed asset. That price is itself a weighted median across 8 exchanges: Binance (weight 3), OKX (2), Bybit (2), Kraken (1), Kucoin (1), Gate.io (1), MEXC (1), and Hyperliquid (1).

Layer 2: Validator consensus. The clearinghouse takes all the validator-submitted prices and computes a stake-weighted median. So you have a median of medians: each validator takes a weighted median of exchanges, then the protocol takes a weighted median of validators. Two layers of robustness before you even get to the mark price.

Layer 3: The mark price itself. This is the final output, and it's the median of three independent inputs:

1. Oracle price + a 150-second EMA of the basis (Hyperliquid mid price minus oracle)
2. The median of best bid, best ask, and last trade on Hyperliquid's own book
3. The median of perpetual mid-prices from Binance, OKX, Bybit, Gate.io, and MEXC

Mark price = the median of those three.

I kept staring at this design. To manipulate the mark price, you'd need to simultaneously manipulate external spot prices across multiple CEXs, external perp prices across multiple CEXs, AND the Hyperliquid order book — all at the same time, sustained long enough to overcome the 150-second EMA smoothing. That's an extremely high bar.

There's also an interesting special case: Hyperps. These are oracle-free perpetuals for tokens that don't have established spot markets yet (pre-launch tokens). They use an 8-hour EMA of their own mark prices as the reference instead of an external oracle. The mark price is capped at 3x this EMA to prevent runaway pricing. Once the underlying launches on major exchanges, they convert to standard perps with the full oracle stack.

Sources: Hyperliquid Docs - Oracle, Hyperliquid Docs - Robust Price Indices, Hyperliquid Docs - Hyperps

Engine 4: The Liquidation Waterfall — Three Stages of Increasing Severity

This is the risk engine. Everything above exists to support this system's ability to close dangerous positions before they become someone else's problem.

I covered liquidation basics before — margin drops below maintenance, exchange steps in. But the how is a three-stage waterfall, and each stage has different implications for different participants.

Stage 1: Market liquidation. When equity drops below maintenance margin, the clearinghouse sends market orders to the book to close the position. For positions above $100K notional, only 20% is liquidated initially — to avoid slamming the order book with a massive sell. Then a 30-second cooldown. If margin requirements are met after the partial fill, remaining collateral stays with the trader. If not, subsequent orders target the full remaining position.

This partial liquidation design is a tradeoff I didn't appreciate at first. It protects the order book from shock, but it means your position might not be fully closed in one shot. You could get partially liquidated, watch the price continue moving against you, and then get hit again.

Stage 2: Backstop (HLP). If equity drops below 2/3 of maintenance margin without a successful book liquidation — the order book was too thin, or the move too fast — the HLP liquidator vault takes over the position. HLP (Hyperliquidity Provider) is a community-owned vault. Anyone can deposit and share in PnL. It runs market-making strategies, earns trading fees, and serves as the backstop for liquidations.

Critical detail: during backstop liquidation, the maintenance margin is NOT returned to the trader. It becomes HLP's profit buffer for absorbing the risk. HLP then gradually unwinds the inherited position.

Stage 3: Auto-deleveraging (ADL). The last resort. When an account goes genuinely insolvent — negative value — meaning both market liquidation and HLP backstop failed to prevent it, the system forcibly closes positions of profitable traders on the opposite side. The ranking formula: (mark_price / entry_price) * (notional_position / account_value). Traders with the highest combination of unrealized profit and leverage get hit first. Positions are closed at the previous mark price.

One invariant the docs emphasize: "A user who has no open positions will not socialize any losses of the platform." If you're sitting in cash, ADL can't touch you. But if you're holding a winning trade, you're in the queue.

Each stage shifts risk to a different group. Stage 1: the trader bears it. Stage 2: HLP depositors bear it. Stage 3: all open-position holders bear it. Understanding this waterfall is understanding who actually backstops the system.

Sources: Hyperliquid Docs - Liquidations, Hyperliquid Docs - Auto-deleveraging, Hyperliquid Docs - Protocol Vaults

Engine 5: The Funding Rate — The Anchor That Holds It Together

I wrote a whole piece on funding rates, so I won't rehash the conceptual framework. But seeing how Hyperliquid implements it at the protocol level added a layer I didn't have before.

The formula is the same as every CEX:

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

But the implementation choices create a meaningfully different instrument.

Sampling: every 5 seconds. The premium index is computed every 5 seconds and averaged over the hour. Compare this to CEX 8-hour windows where sampling frequency varies. Hyperliquid captures market microstructure at a much higher resolution.

Settlement: every hour. Each payment is 1/8 of the 8-hour rate. More frequent settlement means less opportunity for the "funding window gaming" I described in the funding rate article — where traders adjust positions right before timestamps to optimize payments.

The 4% hourly cap. This is where it gets interesting. Hyperliquid calls this "much less aggressive capping than CEX counterparts." Most CEXs only clamp the interest rate component, leaving the premium uncapped. Hyperliquid's hard cap means that in extreme conditions, the anchoring mechanism has a ceiling. If the market is so skewed that funding should be above 4%/hour to pull price back to spot, the cap prevents it. The anchor can temporarily break.

Payment basis: oracle price. Funding is calculated as position_size * oracle_price * funding_rate. Uses oracle price, not mark price, for the notional conversion. A subtle but important distinction — it ties funding to the external consensus price rather than the exchange's own mark.

Interest rate: 0.01% per 8 hours. Same as BitMEX's original design. This gives shorts a baseline income of roughly 11.6% APR. It's the "floor" from my funding rate framework — the reason funding clusters slightly positive in calm markets.

Sources: Hyperliquid Docs - Funding

The Stress Test: What JELLY Broke

Theory is one thing. I wanted to see what happens when the machine is pushed to failure. The JELLY incident in March 2025 is the most instructive case because it stress-tested every engine simultaneously.

Here's what happened.

An attacker deposited roughly $7 million across three accounts on Hyperliquid. They opened a $4.1 million short position and approximately $4 million in longs on JELLYJELLY — an illiquid meme token with about $25 million market cap.

Then they pumped JELLY's price 429% on external DEXs where liquidity was thin.

Now trace how each engine responded:

Engine 3 (Oracle/Mark Price): The oracle correctly reflected the external price surge. The mark price — designed to resist manipulation — followed, because the manipulation was happening on the actual spot markets the oracle was watching. The anti-manipulation design protects against fake prices. It can't protect against someone genuinely moving the underlying market.

Engine 4 (Liquidation Waterfall): The short position triggered Stage 1 liquidation. But JELLY's order book was too thin to absorb the position — the market liquidation didn't fully clear. It cascaded to Stage 2: HLP's backstop vault inherited the short. Now HLP was sitting on a $12 million unrealized loss on a position too large to unwind in JELLY's thin order book.

Engine 2 (Clearinghouse): The position was valid when opened. The OI caps allowed it. The margin was sufficient. Every check passed. The issue wasn't that the clearinghouse failed — it's that the parameters (how much open interest to allow on an illiquid asset) weren't calibrated to the actual market.

Engine 1 (Matching): Working as designed. Orders matched, trades settled, everything was transparent and on-chain. The problem was upstream of the matching engine.

The intervention: Validators coordinated in approximately 2 minutes. They delisted JELLY and settled all positions at $0.0095 — the attacker's entry price, not the $0.50 market price. The attacker managed to withdraw $6.26 million of their $7.17 million deposit before the freeze.

This is the part that crystallized something for me. The five engines worked. Each one did exactly what it was designed to do. The failure was in the parameters and assumptions — OI caps not proportional to market liquidity, no cap on backstop vault exposure to a single asset, and no automated circuit breaker for when HLP losses hit a threshold.

And the fix required centralized emergency governance. In a system that markets itself on decentralization, the fastest available response was a handful of validators making a judgment call in two minutes.

Post-JELLY, Hyperliquid implemented: dynamic OI caps that adjust to market conditions, tighter allocation limits on the liquidator vault, automatic liquidation triggers at loss thresholds, and an on-chain validator voting system for delistings. The 2-minute phone call became a protocol-level mechanism.

Sources: Halborn - JELLY Hack Explained, CryptoPotato - Post-JELLY Updates, CoinDesk - JELLY Delisting

The Same Machine, Different Rooms

Here's what I keep coming back to after this whole exercise.

Every perps exchange — Binance, Bybit, Hyperliquid, dYdX — has the same five engines. The same CLOB matching. The same margin math. The same funding formula. The same liquidation logic. The mechanical guts are nearly identical.

The difference is entirely in where the machine runs.

A CEX runs the machine on a private server where the operator has full control. You trust the operator. A DEX like Hyperliquid runs the same machine inside consensus where the validator set must agree on every state transition. You trust the code — mostly.

I say "mostly" because the JELLY incident showed the boundary. Automated on-chain systems worked perfectly within their design parameters. When those parameters were wrong, humans had to intervene. And human intervention in a "decentralized" system raises the question the whole architecture is trying to answer.

Hyperliquid's bet: the performance gap will narrow (200K to 1M+ ops/sec is on the roadmap), while the trust advantage of on-chain execution is permanent. Whether that bet pays off depends on whether the edge cases — the JELLYs — can be handled by protocol mechanisms rather than phone calls.

What I Came Away With

I started wanting to know how a perps exchange is built. What I found is that it's five systems with deep interdependencies. The matching engine is nothing without the clearinghouse validating margin. The clearinghouse is nothing without the oracle providing a manipulation-resistant price. The liquidation engine is nothing without the insurance fund backstopping failures. And the funding rate is the thread that pulls the whole thing back toward reality.

The most interesting insight: the same concepts from my first two articles — margin, mark price, funding, liquidation, insurance, ADL — are not just features listed on an exchange's landing page. They're five tightly coupled engines where every design choice in one affects the behavior of the others. OI caps (risk engine) determine whether the liquidation waterfall can function. Oracle design determines whether the mark price is trustworthy. Funding frequency determines how tightly the perp tracks spot.

And the JELLY incident is the proof. One attack exploited the gap between the oracle's honesty (it faithfully reported a real price move), the OI caps' looseness (they allowed an oversized position on an illiquid asset), and the liquidation waterfall's assumption (that HLP could absorb what the book couldn't). Five engines, one seam.

The machines are the same on every exchange. The trust model is what differs. And the trust model is, ultimately, the product.

If you want to see what happens when this architecture gets opened up — when anyone can deploy their own markets on top of these five engines — I wrote about HIP-3, Hyperliquid's permissionless market creation upgrade. And if you want to see how the funding engine creates a real trading strategy (and where that strategy breaks), the cash-and-carry trade piece picks up from Engine 5. From there, Ethena turned the delta-neutral strategy into a stablecoin, Pendle tokenizes the yield into fixed income, and Boros makes funding rates themselves tradeable.

That's what I know. Hoping it saves you a few rabbit holes.