Hyperliquid Liquidations Data Explained

Hyperliquid liquidations data is fill data with a liquidation marker attached. A Hyperliquid liquidation is a forced position close, and Hyperliquid records it as a fill. There is no separate liquidation log. The fill that closes the position carries an optional liquidation object holding liquidatedUser, markPx and a method of either market or backstop.

HyperCore, the exchange state machine, runs Hyperliquid’s perpetual and spot order books on-chain. Hyperliquid’s own documentation states that “Every order, cancel, trade, and liquidation happens transparently with one-block finality inherited from HyperBFT.” What the protocol does not publish is a market-wide liquidation feed. The fill and user-event subscriptions take one address at a time, and the historical fill requests are capped.

The record

Key takeaways

• Hyperliquid does not emit a separate liquidation log. It marks the fill that closes the position, and that marker carries the liquidated user, the mark price used to close, and the method.
• Hyperliquid’s documentation describes two paths and names them market and backstop. Those are the two documented values of the method field. The documentation names no numbered tier sequence and no auto-deleveraging step.
• For liquidatable positions larger than 100k USDC, only 20% goes to the book. During the 30-second cooldown that follows, market liquidation orders for that user are for the entire position.
• Size times price over marked fills is notional traded, not money lost. Collateral lost is the realised PnL on the liquidated side, and a backstop liquidation also withholds the maintenance margin.
• Hyperliquid’s fill and user-event subscriptions are per address. The fill requests return at most 2,000 fills, and only the 10,000 most recent are available. Market-wide history means an indexed dataset.
• Liquidation coverage sits with fills. SonarX indexes HyperCore liquidations alongside node fills, funding rates, positions, ledger updates, transfers, staking events and order book snapshots.

Liquidations data on Hyperliquid is fill data with a liquidation marker attached. Hyperliquid does not emit a separate liquidation log: it marks the fill that closes the position, and that marker carries the liquidated user, the mark price used to close, and the method, which is either market (closed into the order book) or backstop (taken over by the liquidator vault). Reading liquidation history therefore means reading marked rows out of the HyperCore fills dataset.

Definition

What is Hyperliquid liquidations data?

A fill is the record of a trade executing. A marked fill is the record of a position closed against its owner’s will.

The liquidation object is optional, so most fills are ordinary trades. When it is present, three fields describe the close.

• liquidatedUser is the address whose position was closed, and it too is optional.
• markPx is the mark price at the liquidation.
• method is market or backstop, the only two documented values.

That is the whole marker. It is also why the data does not arrive in the shape of a centralised venue’s liquidation feed: there is no global liquidation channel to subscribe to, and records are scoped to an account you name.

Mechanics

How a position gets liquidated on HyperCore

Hyperliquid’s liquidations documentation describes the mechanism in five steps.

• Account equity falls below the maintenance margin. Hyperliquid defines a liquidation event as the point where “the account equity falls below the maintenance margin”. The maintenance margin is half of the initial margin at max leverage, which varies from 3-40x, so Hyperliquid’s margining page puts it between 1.25% and 16.7% of notional, depending on the asset.
• The mark price decides, not the book price. Liquidations use the mark price, which “combines external CEX prices with Hyperliquid’s book state”. Hyperliquid gives the reason in its own words: “This makes liquidations more robust than using a single instantaneous book price.” On highly leveraged positions and in volatile markets, the two prices can differ significantly.
• Full-size market orders go to the book first. The positions “are first attempted to be entirely closed by sending market orders to the book”. The orders cover the full size of the position and may fill fully or partially. Most liquidations end here: Hyperliquid states that the majority go directly to the order book, where all users compete for the flow. If enough closes to meet the maintenance margin requirement, any remaining collateral stays with the trader, and there is no clearance fee.
• Above 100k USDC the first order is partial, and a cooldown follows. For liquidatable positions larger than 100k USDC (10k USDC on testnet), Hyperliquid sends only 20% of the position to the book as a market liquidation order. After a block in which any of a user’s positions is partially liquidated, a 30-second cooldown follows. During it, all market liquidation orders for that user are for the entire position.
• Below two-thirds of the maintenance margin, the liquidator vault takes over. If account equity drops below 2/3 of the maintenance margin without a successful liquidation through the book, a backstop liquidation happens through the liquidator vault.

Hyperliquid publishes the liquidation price instead of leaving it to be inferred.

liq_price = price - side * margin_available / position_size / (1 - l * side)

In it, l = 1 / MAINTENANCE_LEVERAGE and side = 1 for long and -1 for short. Margin available is account value minus maintenance margin required for a cross position, isolated margin minus maintenance margin required for an isolated one.

Every step above settles on HyperCore in the same block as the trade that caused it. That makes a liquidation a record you can query rather than an inference from price action.

Two methods

Market and backstop are the two liquidation methods

The two paths above are the method field’s two values, and the names are the protocol’s own.

A market liquidation crosses the public order book. The orders cover the position’s full size, and the liquidated user keeps any remaining margin once the requirement is met.

A backstop liquidation moves the position instead of trading it into the book. The liquidator vault, “a component strategy of HLP”, can take over positions below 2/3 of the maintenance margin. For a cross position, all of the trader’s cross positions and cross margin transfer to the liquidator, and a trader with no isolated positions ends up with zero account equity. For an isolated position, only that position and its isolated margin transfer. The maintenance margin is not returned to the user. Hyperliquid attributes that to the vault needing a buffer to make backstop liquidations profitable on average.

Those are the two documented paths. Hyperliquid’s liquidations page describes no numbered tier sequence, no auto-deleveraging step and no insurance fund.

The marker

How Hyperliquid marks a liquidation on the fill

Hyperliquid marks both paths on the fill, and the method field tells them apart.

A fill record is WsFill, streamed by the userFills subscription and returned by the userFills and userFillsByTime info requests. Its fields cover the market, the price and size, the side and timestamp, the position held before the fill, the realised PnL on the closed portion, the identifiers, the taker flag and the fees. One more field is the marker: liquidation, typed FillLiquidation, optional.

Hyperliquid’s WebSocket subscriptions page defines those types, and it annotates dir as used for frontend display, so dir is a label rather than a protocol enum.

Other surfaces

Where else a liquidation record appears

Further surfaces carry part of the same event, and one of them is not history at all.

The user-event payload. The userEvents subscription delivers WsUserEvent, a union with a liquidation variant called WsLiquidation. It carries five fields in snake_case: lid, liquidator, liquidated_user, liquidated_ntl_pos and liquidated_account_value. The documentation gives their names and types and no prose descriptions. The casing also differs from the fill-level marker: the two are not the same object.

Ledger updates. Hyperliquid’s subscription table describes userNonFundingLedgerUpdates as “Ledger updates not including funding payments: withdrawals, deposits, transfers, and liquidations”.

Clearinghouse state, which is risk rather than history. The perpetuals clearinghouseState request returns a per-position liquidationPx. liquidationPx is the price at which the position would be liquidated, a forward-looking estimate and not a record of an event. It locates exposure sitting near its liquidation price.

The protocol side, per address and capped. Both the fill and the user-event subscriptions require an explicit address, so there is no venue-wide subscription to make. The WebSocket limits cap a client at “10 unique users across user-specific websocket subscriptions”. History carries two documented caps: Hyperliquid’s info endpoint documentation states that userFills “Returns at most 2000 most recent fills”, and that userFillsByTime “Returns at most 2000 fills per response and only the 10000 most recent fills are available”. Both caps are per address. Venue-wide liquidation history comes from an indexed dataset rather than per-wallet API calls.

Method

How to identify and measure a liquidation

Wherever the rows come from, the tests are the same, and they run on fields rather than prices.

Identify. A fill is a liquidation fill when the liquidation object is present on it. No filter on price, size or direction substitutes for that presence test. The method field then splits the row into a market or a backstop liquidation, and the liquidated user, itself optional, names the account whose position was closed.

Measure gross liquidated notional. Size times price, summed over marked fills: the documentation annotates sz as size and px as price. That number is notional traded, not money lost: the size of the positions that were closed, valued at the prices they closed at.

Measure collateral lost. The closest single field is closedPnl, read on the liquidated side: realised PnL on the portion of the position that fill closed. That is the closed portion, not the account’s total loss. And in a backstop liquidation the maintenance margin is not returned to the user, which no field on a single fill shows. A collateral-loss figure that ignores the withheld margin understates the backstop case.

Grain

Split market from backstop before you aggregate

A market liquidation crosses the public book, so it consumes resting depth and prints as taker flow like any other market order. A backstop liquidation transfers the position and its margin to the liquidator vault, so the exposure changes hands without passing through the book. Pooled, they misstate market impact, because only the market rows consumed depth.

The outcome for the trader differs too. In the market case any remaining collateral stays with the trader. In the backstop case the maintenance margin is not returned. One value-liquidated series over both is measuring two economics at once.

The partial rule gives a second reason to hold the grain. A single liquidatable position over 100k USDC can produce several marked fills, in several blocks, with a 30-second cooldown between the partial order and the full-size orders that follow. So a count of marked fills is not a count of liquidation events. An event count groups the account, the market and the time first, and keeps the method as a dimension.

Datasets

Which datasets contain Hyperliquid liquidations?

Three kinds of surface carry the rows, and they differ in reach rather than in fields.

Hyperliquid’s own endpoints

The marker and the payload above are the protocol’s own surfaces. The documented fill requests take a user address, plus startTime and endTime on the by-time variant. They answer per-address questions well: what happened to this account, in this window. Venue-wide questions meet the caps above.

A node you run yourself

Hyperliquid’s node documentation leaves the detail to a public repository, which documents a non-validating mode. That mode can write fills, trades and events to disk for anyone who runs the node themselves. The raw stream comes with the work of operating the node.

Indexed HyperCore datasets

SonarX indexes Hyperliquid as two datasets on one consensus and one block height: HyperCore, and HyperEVM, the EVM execution layer on the same chain. The published HyperCore list names Liquidations as “liquidation events with mark price, method, and affected user”. It sits alongside node fills, funding rates, open interest and perp positions, ledger updates, transfers, staking events and order book snapshots. Both surfaces went live together, as the Hyperliquid coverage announcement records, and the Hyperliquid chain page describes indexed Hyperliquid blockchain data end to end. Hyperliquid’s builder tools documentation lists SonarX under Indexing.

L2 summary order book snapshots are free under CC0 1.0, at the top 20 price levels on each side every 20 blocks, and the snapshots release post covers what they hold.

Available history lands as a Snowflake datashare or as files into your own bucket, and real time arrives through Kafka Streaming.

Fields

Hyperliquid fill fields SonarX indexes

Liquidation rows are fills rows, so a liquidation’s fields are the fill record’s fields. The Hyperliquid liquidations data page and the Hyperliquid fills data page sit under the Hyperliquid chain page, with the full dataset list in the SonarX documentation.

Hyperliquid’s dir field carries display strings such as Open Long, Close Long, Open Short, Close Short, Long > Short, Short > Long, Buy and Sell. The documentation annotates it as used for frontend display and does not enumerate the values, so read them as labels rather than a protocol enum.

Funding sits in its own dataset. An hourly funding payment is not a liquidation, but it moves the account value a liquidation is measured against.

Scope

What is not a HyperCore liquidation

Three adjacent mechanisms answer to the same word and none of them is the marker above.

• Spot borrow liquidations under portfolio margin. Portfolio margin unifies a user’s spot and perps trading, and an account becomes liquidatable when portfolio_margin_ratio > 0.95. None of the perp parameters above applies to it, and which side liquidates first depends on the order of oracle price updates. This page does not cover it.
• Lending-protocol liquidations on HyperEVM. A liquidation inside a lending contract on HyperEVM is a contract event decoded from logs, with its own definition and its own fields. It shares a block height with HyperCore.
• HIP-3 builder-deployed markets. These are perps on HyperCore and they liquidate by the mechanics above, but the deployer is responsible for “market definition, including the oracle definition and contract specifications” and for “setting oracle prices, leverage limits”. A cross-market liquidation study holds the markets apart instead of pooling them.

Nothing here is trading advice, and none of the mechanics above is written as guidance about how to hold a position. Hyperliquid’s documentation publishes no market-wide liquidation total, count or historical series, and this page publishes none either.

Protocol mechanics are cited to Hyperliquid’s documentation (liquidations, margining, info endpoint, WebSocket subscriptions) as read on September 10, 2026. Dataset descriptions follow the SonarX documentation. Last reviewed September 10, 2026.