How Hyperliquid's Oracle Pricing Triggers Liquidations

A position on Hyperliquid doesn't get liquidated because of what you paid for it. It gets liquidated because of where the mark price sits relative to your maintenance margin, and that mark price is not the last traded price on the order book — it's a blended figure built from validator-submitted oracle data and order book impact prices, recomputed every few seconds. If you're running a bot that sizes positions or manages risk on Hyperliquid without modeling that number directly, you're flying blind on the one variable that actually decides when you get closed out.

Oracle price vs. mark price vs. last price

Three numbers matter on any Hyperliquid perp, and traders conflate them constantly.

• Last price — the price of the most recent fill on HyperCore's own order book. Cheap to move on a thin book with a single market order.
• Oracle price — an external reference built from a basket of centralized exchanges (Binance, OKX, Bybit, and others), submitted independently by each validator and then reduced to a median. This runs on roughly a 3-second cadence and is the anchor that keeps the perp tethered to the broader market.
• Mark price — the number actually used for margin calculations, PnL display, and liquidations. Hyperliquid computes it as a median of three inputs: the oracle price and two prices derived from the order book's impact bid and impact ask (the price you'd get filling a fixed notional against depth on each side).

That three-way median is the whole point. A single actor can't crash your liquidation price by hitting a thin local book, because two of the three median inputs are order-book-derived and get outvoted by the oracle when they diverge too far from it. It also means the oracle price alone won't liquidate you if the order book is quoting sanely — you need mark price, which sits between the two, to actually cross your threshold. This is the piece of HyperCore's design worth understanding before you build anything that touches margin; the split between the on-chain order book engine and the EVM environment is covered in more depth in our breakdown of HyperCore's dual architecture.

Funding rides on the same feed

Funding on Hyperliquid is calculated hourly (paid in small increments, generally every hour) from the premium between mark price and the oracle-derived index, clamped to a cap. If you're running anything in the funding arbitrage space, the same oracle infrastructure that drives your liquidation risk is also the input to the funding you're farming — they're not independent risk factors, they move together during volatility.

Worked example: finding your liquidation price

Take a straightforward isolated-margin long: 5 ETH at an entry (mark) price of $3,200, using 10x leverage.

Notional            = 5 ETH * $3,200      = $16,000
Initial margin       = notional / leverage = $16,000 / 10 = $1,600
Maintenance margin rate (10x tier)          = ~3%
Maintenance margin   = notional * 0.03      = $480

Liquidation triggers when your account equity on that position drops to the maintenance margin level — meaning you can absorb a loss equal to initial margin minus maintenance margin before you're closed:

Max tolerable loss = $1,600 - $480 = $1,120
Price move to lose that on 5 ETH = $1,120 / 5 = $224
Liquidation price = $3,200 - $224 = $2,976

That's a 7% adverse move against a 10x position — tighter than most people intuit, and it's measured against mark price, not the price you see scroll by in the trade tape. Cross-margin accounts change this math because equity is pooled across every open position, so a loss on one leg eats into the maintenance buffer of another. If you're running multiple correlated positions, model the account-level margin ratio, not just the per-position liquidation price — treating each leg independently will make your risk look better than it is.

Why liquidations cascade

Hyperliquid's liquidation engine hands distressed positions to a backstop, historically the HLP vault, which then has to unwind the position on the open market. On a deep book that's a non-event. On a thin one, that unwind itself moves the price, which can push mark price further against the next nearest liquidation cluster, which triggers another forced close, which moves the book again. That's the cascade mechanism, and it's roughly what played out in the JELLYJELLY situation in March 2025, where a large, illiquid position pushed mark price in a way that stressed the backstop vault directly.

The lesson for bot builders isn't "avoid Hyperliquid" — it's that liquidity depth at your strike matters as much as your own leverage. A market with GMX-style pooled liquidity behaves very differently under stress than an order-book venue; we compare the two liquidity models directly in our GMX v2 vs. Hyperliquid piece, and it's worth reading before you assume order-book depth on Hyperliquid mirrors what you'd see on a comparable dYdX v4 market, which we also break down in our dYdX v4 architecture comparison.

Modeling this in a bot instead of reacting to it

You don't have to hand-roll the liquidation formula in production — the clearinghouseState endpoint on Hyperliquid's info API returns a liquidationPx field per position already computed server-side. But pulling that number on a timer isn't the same as modeling it:

import requests

resp = requests.post("https://api.hyperliquid.xyz/info", json={
    "type": "metaAndAssetCtxs"
})
ctxs = resp.json()[1]
mark_px = float(ctxs[asset_index]["markPx"])
oracle_px = float(ctxs[asset_index]["oraclePx"])

# distance-to-liq as a fraction of mark price
buffer_pct = abs(mark_px - liquidation_px) / mark_px
if buffer_pct < 0.04:
    reduce_position()

The useful work is in the buffer logic: recompute distance-to-liquidation on every mark price tick (not on your own trade events, which lag), widen your buffer when the spread between oracle price and mark price grows (that spread widening is itself a signal that the book is thinning), and treat cross-margin accounts as a portfolio problem rather than N independent positions. This is precisely the kind of monitoring layer we build into every Hyperliquid liquidation bot we ship — pulling mark and oracle price on the same cadence the protocol does, tracking maintenance tiers per asset, and cutting exposure before the forced-close engine does it for you. It's also table stakes for any Hyperliquid perps bot running meaningful size, and worth surfacing on a live trading dashboard so a human can see the buffer shrinking in real time, not just after a fill notification.

If your current setup only checks liquidation risk after a trade executes, you're already behind the mark price update that caused it — talk to us about building liquidation-threshold monitoring into your Hyperliquid bot.