Liquidation Cascades on Hyperliquid: Reading the Domino Order Before the Move

Every meaningful price move on a perp DEX leaves a trail of forced selling or forced buying behind it. The mechanics are simple: traders post margin, leverage their position, and if price moves against them past a threshold, the exchange closes their position at market. On Hyperliquid, this happens transparently on-chain, in a way that every other trader can see in real time.

The opportunity isn't watching liquidations after the fact. It's mapping the liquidation surface ahead of time — which prices, if reached, would trigger meaningful forced-flow — and using that map to anticipate the next leg of the move. Most traders see the cascade as it's happening and react. The traders with structural edge see the cascade coming before it fires.

This article walks through how to read Hyperliquid's liquidation surface programmatically, what makes a cascade-prone setup, and how to combine cohort positioning with liquidation density to find the trades that pay before the dominoes fall.

What a liquidation cascade actually is

A liquidation is the forced close of a leveraged position when the position's margin equity falls below the maintenance margin requirement. On Hyperliquid, this is computed continuously against mark price. When a long position's mark-price-driven equity falls below threshold, the long is closed at market — which itself is a sell into the order book.

A cascade is when that sell flow knocks price down enough to trigger the next set of liquidations sitting slightly lower in price. Those liquidations sell into a now-weaker book, knocking price down further, triggering the next tier. The whole sequence can fire in seconds to minutes.

For shorts, the mechanics invert. A rising mark price triggers short liquidations (which become market buys), which lift price, which triggers the next short liquidation tier up. Short squeezes are the same cascade mechanic, opposite direction.

The structural question for traders: how many positions are sitting at each price level, and how thinly stacked are they? That answer is the liquidation surface.

Reading the liquidation surface via the API

HyperTracker exposes the liquidation surface as a density curve — at each price level below current mark, how much long open interest gets liquidated; at each level above, how much short OI gets liquidated.

liq = api.get("/liquidations/surface/BTC")
# Returns:
# {
#   "asset": "BTC",
#   "current_mark": 81_240,
#   "long_liquidations": [
#     {"price": 80_500, "notional": 18_400_000, "wallet_count": 142},
#     {"price": 79_800, "notional": 42_700_000, "wallet_count": 287},
#     {"price": 78_500, "notional": 91_200_000, "wallet_count": 618},
#     ...
#   ],
#   "short_liquidations": [
#     {"price": 82_000, "notional": 12_600_000, ...},
#     ...
#   ],
#   "timestamp": "2026-06-10T..."
# }

The price levels in the response are tier boundaries, not exact liquidation prices. Each tier represents a price band where the listed notional would be force-sold if mark reaches that band. The wallet count tells you how concentrated the liquidations are — 287 wallets at a single tier means the cascade trigger involves many small positions rather than one whale.

What makes a cascade-prone setup

Three structural features predict whether the next liquidation tier will trigger a cascade or just absorb cleanly:

Density gradient. When successive liquidation tiers are close together in price (every 0.5-1%) and each tier is similar or larger in size than the one before, you have a cascade structure. Price walking through one tier creates the conditions for the next. Sparse tiers (large price gaps between them) typically absorb without cascading because the order book has room to rebalance.

Book depth at the trigger level. A liquidation tier sitting above thin book depth will cascade because the forced sell has nothing to absorb it. The same liquidation sitting above a deep book usually fills without major price impact.

Cohort composition of the at-risk positions. This is the underrated factor. Liquidations from Money Printer wallets are usually one-off slips, not regime changes. Liquidations from Exit Liquidity and Full Rekt cohorts often come in waves because those wallets tend to use similar leverage and similar entries — they're effectively the same trade duplicated across many addresses.

Combine the three: dense gradient + thin book + low-PnL cohort concentration = high cascade probability. Any one of those alone is weaker signal.

The cohort attribution layer

The HyperTracker API breaks down liquidations not just by price tier but by which cohort is at risk in each tier:

liq_by_cohort = api.get("/liquidations/surface/BTC?breakdown=cohort")
# Returns the same surface, but each tier includes per-cohort breakdown:
# {
#   "price": 78_500,
#   "notional": 91_200_000,
#   "by_cohort": {
#     "money_printer": 4_100_000,
#     "smart_money": 8_900_000,
#     "consistent_grinder": 12_400_000,
#     "humble_earner": 18_700_000,
#     "exit_liquidity": 27_300_000,
#     "semi_rekt": 11_800_000,
#     "full_rekt": 7_900_000,
#     "giga_rekt": 100_000
#   }
# }

The pattern that creates the cleanest cascade trades:

• Tier dominated by low-PnL cohorts (Exit Liquidity / Semi-Rekt / Full Rekt): likely to fire when reached. These wallets historically don't manage leverage well and don't add margin to defend positions.
• Tier dominated by high-PnL cohorts (Money Printer / Smart Money): more likely to be defended. These wallets often add margin or close manually before liquidation. The tier may not fire even when price approaches.

A liquidation surface that's 80% low-PnL cohorts on the long side, with cascade-friendly density structure, is a setup. Position short with stops above current mark, target the tiers in sequence.

Trading the cascade

The execution mechanics matter as much as the read. A few practical principles:

Pre-positioned vs. reactive. Pre-positioning before the cascade fires is higher EV but requires conviction. You're shorting into a market that hasn't yet broken. Reactive entry (waiting for the first tier to fire, then chasing) is safer but you're getting worse fills as the move accelerates.

Position sizing relative to cascade depth. If the surface suggests three cascade tiers each 1.5-2% apart, your target is the third tier — 4-6% from entry. Size accordingly, with stops 0.5-1% above your entry. This is asymmetric: the risk side is small because you're entering near the trigger; the reward side is multi-tier.

Closing into the cascade, not after. The biggest mistake is holding through the cascade and hoping for a larger move. Most cascades exhaust themselves within minutes once the last meaningful tier fires. Close at the third or fourth tier — the further you ride, the lower the marginal probability of another leg.

Where this fails

Two failure modes worth naming.

Defended cascades. Sometimes the wallets at the cascade tiers add margin or sell hedges to avoid liquidation. This typically happens when the cohort composition skews high-PnL — those wallets are sophisticated enough to actively manage positions. If your surface read showed mostly Money Printer / Smart Money exposure, expect this. If it showed Exit Liquidity dominance, expect the cascade to fire as mapped.

External liquidity injections. A CEX-driven move (large coordinated buying or selling on Binance, OKX) can push Hyperliquid price into a cascade zone without the Hyperliquid book itself showing cascade-prone structure. These cascades feel like they "came from nowhere" but they came from elsewhere on the cross-venue spread.

API access

The liquidation surface endpoint is available on Pulse tier ($179/mo). Cohort-attributed liquidation breakdown is on Surge ($499/mo) and above. WebSocket subscriptions push updated surface data every 30 seconds for active strategies.

# Subscribe to liquidation surface updates
async def watch_liquidations():
    async with websockets.connect("wss://api.hypertracker.cmm.app/ws") as ws:
        await ws.send(json.dumps({"subscribe": "liquidation_surface", "asset": "BTC"}))
        async for msg in ws:
            event = json.loads(msg)
            # Check for cascade-prone updates
            if has_cascade_structure(event):
                alert("BTC cascade setup forming")

Get cohort-attributed liquidation surface data →

The bigger framing

Liquidations are public information on Hyperliquid. The liquidation surface is computable from public data. The cohort attribution is the only piece that requires a layer most traders don't have. That gap is where the edge lives — anyone can see that liquidations are coming, but the wallets who can attribute them by cohort know which ones will fire and which ones will be defended.

The cascade is going to happen. The question is whether you read the surface ahead of time or react to the move after it starts.