Anatomy of a liquidation cascade
A 105-minute walk through a HYPE drawdown, read entirely from two feeds: the liquidation events stream and raw order-book deltas. Depth withdrew minutes before the first forced sale, the cascade fed itself for half an hour, and it stopped exactly where the surviving bids said it would.
HyperliquidRPC Research
Engineering & market structure
A liquidation cascade is the one market event you cannot study from a candle chart. The candle shows you that price fell; it does not show you the sequence: who pulled quotes, when the first margin engine fired, how forced flow consumed the book, and why it stopped. All of that lives in two places: the liquidation records in the events feed (victim wallet, size, price, mark price) and the raw book deltas (every add, modify, and remove on every order book).
This post reconstructs one HYPE perp episode from a morning in mid-May: a fall from $41.86 to $36.92 (11.8%) in 48 minutes, $30.9M of forced liquidations, and a partial recovery, all read from the archive at full resolution. The point is not the episode itself; it is the workflow. Every step below is a query you can run.
The setup: crowded and quiet
Cascades need fuel, and the fuel is visible in advance. In the sessions before the episode, funding on HYPE had been persistently positive (longs paying shorts) while open interest ground higher: a one-sided, levered crowd. The events feed records every per-user funding payment with its rate, so 'crowded' is not a vibe, it is a time series. None of this predicts the day; it prices the kindling.
Phase one: the book thins first
The most repeatable finding in this kind of forensics: depth leaves before price does. From 09:42, the book-delta feed shows bid-side liquidity within 50bps of mid draining: order removes outnumbering adds on the bid side block after block, with no corresponding trades. Resting bids were canceled, not consumed. By 09:48, near-mid bid depth was roughly 40% below its morning baseline while price had moved less than 1%.
This is invisible in L2 snapshots taken at intervals, and completely absent from the trade tape. It is only legible because the archive keeps every individual book delta (the same per-block diffs the live BOOK_UPDATES stream delivers), so you can replay the book's state change-by-change and attribute each change to a cancel, a modify, or a fill.
Phase two: the feedback loop
The first forced sale lands at 09:43: small, $0.2M in the 3-minute bucket. Each liquidation record names the victim, the size, the execution price, and the mark price at trigger. Sorting victims by entry leverage shows the engine working through the margin ladder in order: the most levered positions go first, their market-sells push mark price into the next tier, and that tier follows. From 09:54 to 10:12 the loop is self-sustaining, with six consecutive buckets above $1.5M of forced flow into a book already 40% thinner than baseline.
Two structural details stand out in the records. First, liquidations cluster at psychologically meaningless prices: they fire at margin thresholds, not round numbers, which is how you distinguish forced flow from stop-loss flow in the same window. Second, the victim set is small: a double-digit count of wallets accounts for the large majority of the $30.9M, and the three largest single liquidations land in the worst two buckets. Cascades are not death by a thousand cuts; they are a few large positions failing in sequence.
Phase three: where it stops, and why
The cascade ends at $36.92, and the book-delta history shows that this level was not magic; it was inventory. A band of large resting bids placed hours earlier sat just below $37; they were old orders (their placement events are in the same archive, timestamped), not reactive ones. Forced flow consumed into them, slowed, and the moment per-bucket liquidation notional dropped below fresh passive replenishment, the price snapped back 1.7% in nine minutes. Mean reversion after the last forced seller is one of the most consistent patterns the liquidation dataset exhibits.
By 10:30 the loop is dead: liquidation buckets at zero, bid-side adds outpacing removes, and the maker wallets that had withdrawn at 09:42 visibly re-quoting: the same wallet addresses, returning at wider spreads. Attribution makes the recovery as legible as the fall.
Reading it live
Everything above used the historical archive, but both inputs exist as real-time streams with the same schema: liquidations arrive on the EVENTS stream, deltas on BOOK_UPDATES. A risk system that joins the two (forced-flow rate against near-mid depth) sees the 09:42 withdrawal and the 09:43 first liquidation as they happen, with the victim's wallet on every record. The historical query that backtests the signal:
SELECT toStartOfInterval(ts, INTERVAL 3 MINUTE) AS bucket, sum(notional) AS liq_notional, count() AS liq_count, uniq(victim) AS walletsFROM liquidationsWHERE coin = 'HYPE' AND ts BETWEEN '2026-05-18 09:30:00' AND '2026-05-18 11:15:00'GROUP BY bucket ORDER BY bucket;Three takeaways travel beyond this episode. Depth withdrawal leads forced selling, so book deltas are a leading input and the trade tape a lagging one. Liquidation flow is concentrated in few wallets, so attribution matters more than aggregate volume. And cascade floors are made of stale resting orders, so the order-lifecycle archive, which knows how old every bid is, is where support levels stop being folklore.