Track whale positions and liquidation clusters on Hyperliquid
What whale and liquidation data Hyperliquid exposes, how to read where forced selling stacks up, and how to turn it into alerts an agent can watch in real time.
Hyperliquid is an on-chain perps venue, which means its order flow is not a black box the way a centralized exchange is. You can see large accounts open, add, and get liquidated. If you want to track hyperliquid whale positions, you are not scraping leaks or paying for a private feed: the public info API exposes per-address positions, per-account fills, the trade tape and open interest, and from that you can build a real picture of where size sits and where it breaks. This post covers what is actually available, how to read liquidation clusters, how to combine that with open interest near the cap, and how to hand the whole thing to an agent so it watches for you.
What whale data Hyperliquid exposes
Three kinds of data matter here, and they come from different places. Everything below is one HTTP call: the Hyperliquid info API is a single POST https://api.hyperliquid.xyz/info with a JSON body whose type field selects the query. One warning before you start: every numeric field comes back as a string ("0.0000125", "117234.0"), so parseFloat before any arithmetic or you will silently concatenate.
Positions: per-address open positions, including size, entry, leverage, and unrealized PnL. {"type":"clearinghouseState","user":"0x..."} returns assetPositions plus margin summary for one address. That is the raw material for hyperliquid whale positions tracking. The hard part is not fetching one address, it is knowing which addresses are worth watching. Note for anyone wiring PredMCP: get_whale_positions is the Polymarket tool (it hits data-api.polymarket.com/positions?user=…), not the Hyperliquid one. On Hyperliquid you go through clearinghouseState yourself, or use the trade-side tools below.
Trades: fills stream out per market. {"type":"recentTrades","coin":"BTC"} gives the public tape for one asset, {"type":"userFills","user":"0x..."} gives one account’s fills. Large prints tell you when size is entering or exiting. A single 4M USD market buy on a thin book is a different signal from the same notional split over an hour. This is what get_whale_trades wraps: it filters the tape by notional threshold, and it is the public Hyperliquid whale tool.
Labels: raw addresses are noise until you attach meaning to them. Is this account a known market maker, a CEX hot wallet, a suspected fund, or an unlabeled wallet? Labeling is what turns “an address did X” into “an account whose flow is mechanical did X”, which mostly tells you when to ignore a print. That is the honest framing: a label lowers the signal value of market-maker and exchange flow, it does not certify anyone as a genius. This is also the layer that takes the most work to maintain, because labels rot: addresses change behavior and a stale label is worse than no label.
None of this requires special access. All of it requires plumbing: address resolution, dedup, and a store that lets you ask “show me this account’s history” without re-crawling every time.
Reading liquidation clusters: where forced selling is stacked
A liquidation cluster is a price zone where a lot of leveraged positions get force-closed if price reaches it. It is a map of where the market has stored fuel. When price enters a dense cluster, liquidations trigger more liquidations, and you get the fast candle everyone screenshots.
There are two ways to build the map. The exact way is to enumerate accounts and read liquidation price per position (clearinghouseState per address), then bucket by price level. That is expensive: there is no “give me every open position” endpoint, so you are maintaining an address universe and crawling it.
The tractable way is to estimate. Long liquidations sit around mark * (1 - 1/leverage), short liquidations around mark * (1 + 1/leverage), so you take the standard leverage tiers traders actually use, project both sides off the mark price from {"type":"metaAndAssetCtxs"}, and then annotate each level with the resting liquidity sitting next to it from {"type":"l2Book","coin":"BTC","nSigFigs":4}. You get zones, not a per-account census: a level where a common leverage tier breaks and the book is thin is where a move accelerates. The zones that matter are the ones close to current price, because those are reachable in a single move.
Reading it is about asymmetry. If the 20x and 25x long levels sit a few percent below spot with almost no resting bid between here and there, while the short side above is far away or well defended, the path of least resistance is down: a small push flushes the longs, and the flush feeds itself. That is not a prediction, it is a read on where the market is fragile.
Combining OI near cap with liquidation maps
Liquidation clusters tell you where positions break. Open interest near the cap tells you how crowded and constrained the market already is. Put them together and you get a risk read that neither gives alone.
Hyperliquid publishes this directly: {"type":"perpsAtOpenInterestCap"} returns the list of perps currently sitting at their open interest cap, and metaAndAssetCtxs gives you openInterest and markPx per asset so you can size it in USD. That list is exactly what get_oi_near_cap returns, cap status per perp plus the notional behind it.
When an asset is capped, new size cannot come in to absorb a move: opening longs is blocked until OI comes down. Pair a capped asset with an estimated liquidation zone just below price and thin resting depth into it, and you have a setup where a flush has fuel and no counterweight. That is the difference between a wick and a cascade.
This is also where a single-venue view lies to you. A cluster on Hyperliquid does not exist in isolation: funding and positioning on other venues shape whether that fuel actually ignites. We wrote up why that matters in cross-venue divergence: the same asset can look calm on one book and primed on another, and the divergence is often the signal.
Turning it into alerts an agent can watch
Staring at a liquidation map all day is not a strategy. The point of structured data is that a program watches it and pings you on state changes, not on every tick.
Useful alert conditions are concrete:
- a print above X notional hits the tape on asset A (get_whale_trades)
- cumulative whale buy/sell imbalance on asset A flips direction over 24h (get_whale_flow)
- an estimated liquidation level lands within Y% of spot with thin book into it
- asset A appears in get_oi_near_cap AND the zone below is closing in
- the counterparty address is unlabeled, i.e. not market-maker or CEX flow (get_whale_label)Each of these is a boolean over data you already have. An agent evaluates them on a loop, keeps state so it only fires on transitions, and hands you the context (which account, which level, how much) instead of a bare “alert.”
From monitoring to execution: notes from running a liquidator
We run a liquidation bot on HyperEVM with the studio’s own capital, so the monitoring above is not academic for us. A few engineering notes.
Reading the map is easy. Acting on it is where you get punished. The cluster you can see, the bot next to you can see too, so the edge is in latency, gas handling, and not blowing up when a block goes sideways. State has to survive restarts, RPC has to be an archive node you trust, and every assumption about “this event means X” needs a fallback for when the chain disagrees. We wrote the hard version of this in a liquidation bot that survives its first bad block: the first time your read of the data and the actual on-chain state diverge, naive code loses money.
The lesson that carries back to monitoring: treat the data as a live system that will lie to you at the worst moment, not a clean CSV. Dedup fills, sanity-check liquidation prices against current mark, and never trust a single reading to trigger real size.
One MCP call vs building the whole pipeline
Everything above (address resolution, labels, fill dedup, cluster estimation, cap status, cross-venue context) is plumbing plus ongoing maintenance as labels drift and APIs change. The info API is free and public, so the cost is not access, it is the pipeline around it.
Or it is one call. PredMCP wraps this into tools any agent can hit: get_whale_trades and get_oi_near_cap on the public side, get_whale_flow, get_whale_label and get_liquidation_clusters on the signal side, plus get_whale_positions if the account you care about is on Polymarket rather than Hyperliquid. 47 tools total, live on predmcp.com, free in early access, 100 calls per day per key, no card. The method is written above so you can rebuild it against the raw info API if you want; the signal tools themselves are not part of the published code.
Build the pipeline if the pipeline is your product. If you just want an agent watching where forced selling is stacked on Hyperliquid, point it at the endpoint and spend your time on the strategy instead.