Why we don't publish liquidation totals
Almost every crypto data site publishes a "total liquidated" figure. We do not, because the feeds those numbers are built from are throttled, and the resulting understatement is largest at exactly the moments the number is most quoted.
The mechanism
Binance's liquidation stream !forceOrder@arr does not emit every liquidation. Its
description says the stream pushes a snapshot: for each symbol, one liquidation
order within 1000ms, and "if no liquidation happens in the interval of 1000ms, no stream will
be pushed". Which order survives has not been stated consistently. The description read
"only the latest one liquidation order within 1000ms will be pushed" until 10 April 2026,
when Binance's change log records "latest" being changed to "largest";
the description Binance ships in its own client libraries was back to "latest" by July 2026 and
still read that way when checked on 16 September 2026.
One message per symbol per second is ample when the market is quiet and one liquidation arrives every few minutes. During a cascade, when dozens or hundreds of positions are closed per second on a single symbol, all but one of them in each second are discarded — the most recent or the largest, depending on which wording holds. Neither rule rescues the sum: keeping the largest shrinks the shortfall, it does not remove it. A sum over that stream is therefore not a total. It is a sample, and the sampling rate falls as the event gets larger.
The measured scale
Vetle Lunde of K33 Research put it plainly in August 2024: liquidation data from exchanges is "bogus and a vast underrepresentation of actual liquidation volumes in the market".
In October 2025 Hyperliquid's founder described the same throttling and estimated the understatement at up to roughly 100x during peaks. The crash of 10 October 2025 is the clearest illustration: headline coverage reported roughly $19 billion liquidated market-wide, while Hyperliquid alone — which publishes complete records because it settles on-chain — accounted for $10.31 billion of it. One venue cannot be 54% of a market it is not 54% of. The market-wide figure was too low, not Hyperliquid's too high.
Why we don't simply use a better source
The obvious answer is to take liquidations from a venue that publishes them completely. Hyperliquid settles on-chain, so in principle every liquidation is a public event. In practice its public API exposes no market-wide liquidation feed: liquidation events are delivered only inside a per-address subscription, which requires knowing in advance which address was liquidated. Reconstructing the market-wide series means indexing every block, which is a permanent piece of infrastructure rather than a page.
So the choice is between publishing a number we know is wrong, publishing one we cannot produce, or publishing neither and saying why. We publish neither and say why.
What we do publish
Liquidation price — where a given position would be closed — is fully
computable, because the maintenance-margin tiers are published. That is a different quantity
from liquidation events, and it is genuinely useful: the
entry × (1 − 1/leverage) formula in circulation on most calculators ignores
the tiers entirely, and it can miss in either direction. It ignores maintenance margin, which
closes a position while some of its margin is still left, and that alone brings liquidation
nearer to entry than the formula says. It ignores the tier's leverage cap, and a position capped
below the leverage asked for carries more margin, which moves liquidation further away. Which of
the two wins depends on the contract, the leverage and the position size; on a contract with more
than one tier, the cap steps down and the maintenance requirement steps up each time the size
crosses a boundary.
Every contract page prints both results, the gap between them and which of the two leaves more room →
What would change this
A verified extraction path that yields market-wide liquidation events within the cost constraints of this site, or funding sufficient to run a block indexer. Until one of those exists, this page is the answer rather than a placeholder for a section.