Liquidation Hunting on Hyperliquid: How Bots Profit from Cascades

Liquidation hunting on Hyperliquid is one of the cleaner edge cases in on-chain perps: the protocol publishes real-time margin data, the liquidation triggers are deterministic, and the resulting forced market orders create predictable price dislocations that a fast bot can trade against. This post covers the actual mechanics — what the liquidation engine does, where the data lives, how to model at-risk positions, and what can go wrong at each step.

How Hyperliquid's Liquidation Engine Works

Hyperliquid runs a central limit order book on its own app-chain (HyperEVM + HyperCore). Every perpetual position carries a maintenance margin requirement — currently around 0.5–1% of notional, depending on the asset and tier. When unrealized losses push a position's margin ratio below that threshold, the engine marks it for liquidation.

The liquidation itself is not instantaneous. The protocol first attempts to close the position at the mark price. If the position is large enough that it cannot clear without moving the market, the engine transfers it to the insurance fund and uses the backstop liquidity mechanism. For most retail-sized positions — say, under $500k notional — the engine sends a market order directly to the book.

Key numbers to keep in mind:

• Mark price is a weighted average of oracle and last traded price, updating every ~200ms
• Maintenance margin for BTC-PERP is 0.5%; for mid-cap perps it runs 1–2%
• Liquidation penalty is 5% of position value taken from the trader; part of that flows to the liquidator

The liquidator receives the difference between the bankruptcy price and the price at which the position actually closes. On a 20x leveraged position, a 0.5% move against a trader can trigger liquidation with the bankruptcy price sitting 4–5% below current market — that spread is the liquidation bot's gross edge.

Reading the Liquidations Feed

Hyperliquid exposes two data streams you need to monitor simultaneously:

WebSocket allMids — gives you mark prices across all assets, refreshed every ~200ms. You need this to compute real-time margin ratios.

REST clearinghouseState + WebSocket user subscriptions — the protocol does not publish a single global "at-risk positions" feed. Instead you reconstruct it: pull open interest per asset from /info (the openInterest field per coin), then use the metaAndAssetCtxs endpoint to get funding, mark price, and oracle price together. From those, you can estimate where the aggregate liquidation cluster sits for each asset.

For actually watching individual accounts, you subscribe to the webData2 channel with a specific address. Bots that operate as liquidators often scrape a list of large open positions from on-chain data providers — Hyperliquid's own leaderboard and third-party dashboards like HyperDash expose top positions with leverage ratios. You build a watchlist and poll or subscribe.

The liquidation event itself appears in the trades stream as a trade with side matching the direction that closes the position, with a liquidation field set to true. At that point, the opportunity has already partially closed — the fast edge is anticipating the liquidation, not reacting to the event.

The Two Strategies: Front-Running vs. Taking the Fill

There are two distinct approaches, and they have very different risk profiles.

Front-running the cascade — you model which positions are approaching their maintenance margin threshold, estimate the mark price move that triggers them, and open a position in the same direction before the engine fires. If your model is right and the cascade materializes, you ride the forced selling into your TP. The edge is real but fragile: you are carrying a directional position, you can be wrong about timing, and if the mark price recovers before the cascade you get stopped out. This is the approach the Liquidation Hunter service is built around — margin monitoring, trigger modeling, latency-tuned entry.

Taking the liquidation fill — on smaller positions, a bot can register as a liquidity provider and passively offer the other side of the forced market order. The spread between the order price and the bankruptcy price is the locked-in gross PnL. The risk here is adverse selection: you will be the liquidity of last resort, meaning you get filled when the market is moving against you. Your position needs to be unwound quickly, and the unwind cost can eat the liquidation premium if volatility spikes.

In practice, most production liquidation bots blend both: they anticipate and take a small directional pre-position, then partially take the liquidation fill, then exit both legs quickly.

Position Sizing and the Cascade Amplification Problem

This is where most writeups skip the important part. Liquidation cascades self-amplify because the forced closing of one position moves the mark price, which pushes other positions closer to their own maintenance thresholds. If you model each position in isolation you will underestimate the size of the move.

A robust cascade model needs:

• Clustered liquidation prices — group open positions by their estimated liquidation price bands (±0.5% buckets) to find where the largest forced-sell clusters sit
• Cross-asset correlation — a BTC cascade that dumps price 3% drags ETH and SOL positions toward their own thresholds through oracle correlation
• Insurance fund depth — if the insurance fund is thin, large positions go to backstop and the market impact is larger than expected

You can compute rough liquidation clusters from the openInterest and markPx data. A simple heuristic: if aggregate open interest on the long side is $200M in BTC-PERP and average leverage is 10x, a 1% adverse move forces roughly $20M of exits. Model the order book depth at that price level against that notional and you get an estimated slippage — that slippage is your max TP for the pre-position leg.

Execution Requirements

The Hyperliquid API uses EIP-712 signed orders. There is no on-chain simulation like EVM — your order is accepted or rejected by the validator in round-trip time from your server to the Hyperliquid API endpoint. Latency matters but it is measured in tens of milliseconds, not microseconds the way Solana Jito bundle strategies are. A VPS in a US East data center (the current closest to Hyperliquid's primary validators) gives you acceptable round-trips.

What matters more than raw latency is cancel-and-replace speed. If your pre-position is open and the anticipated liquidation does not materialize — the mark price stabilizes — you need to cancel before you carry a losing directional position through the recovery. Build your bot to cancel aggressively, not to hold and hope.

For a detailed comparison of how this execution model sits relative to market-making on the same venue, see Market-Making Bot — Hyperliquid, which runs the same EIP-712 infrastructure but with a very different risk posture.

Legal and Risk Considerations

Liquidation hunting is legal and explicitly permitted by Hyperliquid's design — the liquidation premium exists to incentivize liquidators. That said:

• Front-running via oracle manipulation is not. If you attempt to move the oracle price to trigger liquidations artificially, that is market manipulation under most regulatory frameworks.
• Position limits matter. If your liquidation-taking fills land you with a large directional perp position that you cannot unwind cleanly, you are exposed to gap risk. Hard position limits and a kill-switch that fires when unwind cost exceeds a threshold are non-negotiable in a production system.
• Hyperliquid can and does delist assets or suspend trading. Your bot needs to handle unexpected halt events without leaving open positions orphaned.

The Perps Trading Bot and the liquidation hunter are both signal-driven execution engines at the core — the difference is the signal source and the aggressiveness of the exit logic. If you are also running a funding-rate arbitrage strategy on the same account, be careful about how the two interact: a large directional position from a liquidation fill can blow out a delta-neutral funding leg before you have time to flatten.

---

If you want a production liquidation-hunting bot built for Hyperliquid — monitoring logic, cascade modeling, latency-tuned execution and kill-switches included — get in touch and we will scope it from a clean slate.