Hyperliquid Liquidation Radar: Scored Liquidation Feed avatar

Hyperliquid Liquidation Radar: Scored Liquidation Feed

Pricing

from $10.00 / 1,000 liquidation events

Go to Apify Store
Hyperliquid Liquidation Radar: Scored Liquidation Feed

Hyperliquid Liquidation Radar: Scored Liquidation Feed

A scored, deduplicated feed of forced-liquidation events on Hyperliquid perps: coin, side liquidated, total notional, mark price, liquidated wallet, and a cascade flag, with open-interest and funding context. Aggregated per liquidation (not per fill) and billed only for new events. No API key.

Pricing

from $10.00 / 1,000 liquidation events

Rating

0.0

(0)

Developer

Larry Johnson

Larry Johnson

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Share

Hyperliquid Liquidation Radar

A scored, deduplicated feed of forced liquidations on Hyperliquid perps. For each liquidation you get the coin, which side blew up (long or short), the total notional, the average fill price, the exchange mark price, the liquidated wallet, a cascade flag, and the coin's open interest and funding context. This is the data perp traders look at right after price itself, because a wave of liquidations is where the violent moves come from.

What makes this one honest

Two things most liquidation tools get wrong:

  1. One liquidation is not one fill. When a position is force closed it usually executes as many separate fills against many maker orders. A single liquidated BTC short can be a dozen fills sharing the same instant. This actor aggregates every fill of one liquidation into a single event with the true total notional, so you are not looking at a single blowup shattered into twelve confusing rows, and you are not billed twelve times for it.

  2. Coverage is stated plainly. Hyperliquid does not publish a global liquidation endpoint. The only place a liquidation appears is as a field on a per wallet fill. So this actor seeds a wallet set from recent trades and the live trade tape, finds who got liquidated, then reads each liquidated wallet's own fills to reconstruct the full event. Coverage equals the wallets seen in the window, and it compounds because the actor remembers the liquidator wallets it finds and polls them first next run. This is a near real time enriched feed, not a guaranteed capture of every single liquidation on the venue. We would rather tell you that than pretend.

Input

{
"topCoins": 30,
"listenSeconds": 60,
"minNotionalUsd": 1000,
"lookbackMinutes": 60
}
  • topCoins: how many of the highest volume perps to seed from. Default 30.
  • listenSeconds: seconds to live stream the trade tape to widen the active wallet set (0 = REST only). Default 60.
  • minNotionalUsd: only return liquidations at or above this total size. Default 1000.
  • lookbackMinutes: only return liquidations from the last N minutes. Default 60. This is what keeps the feed recent instead of dumping old history. For continuous coverage, schedule the run every few minutes with a window slightly larger than the gap between runs.
  • maxSeedWallets, maxEnrich, maxResults: caps that trade coverage for run time. Defaults are sensible.
  • dedupAcrossRuns: remember events (and liquidator wallets) so the same liquidation is never returned or billed twice and coverage compounds. Default true.

Output

One record per liquidation event:

{
"coin": "BTC",
"liquidatedSide": "SHORT",
"notionalUsd": 184320.5,
"totalSize": 1.62,
"avgPx": 113778.1,
"markPx": 113800.0,
"fillCount": 12,
"method": "market",
"score": 80,
"cascade": true,
"cascadeCount": 4,
"pctOfOpenInterest": 0.41,
"coinOpenInterestUsd": 44900000,
"coinFundingAprPct": 11.2,
"liquidatedUser": "0x66815db1...",
"eventTimeMs": 1781473250300
}
  • liquidatedSide is the side that was force closed (a long liquidation is a forced sell, a short liquidation is a forced buy).
  • score (0 to 100) weights notional size, share of the coin's open interest, whether it is part of a cascade, and whether the coin is thinly traded.
  • cascade is true when several liquidations of the same coin and side land inside a short window, which is the signature of a chain reaction.
  • liquidatedUser is the actual on chain wallet, so you can verify any event yourself.

Billing

You pay per new liquidation event. The dedup key is the atomic (coin, liquidatedUser, time), so the same liquidation is never billed twice across scheduled runs, even though it is discovered from several wallets at once. Error rows are always delivered and never billed. If our data sources are unreachable the run fails loudly rather than returning an empty result that looks like "no liquidations."

Use it from an AI agent

The same feed runs as a tool an AI agent can call to watch for liquidation pressure on a coin before it acts. Pair it with the Hyperliquid Whale Tracker for the full picture of large flow plus forced flow.