Why Binance liquidation counts understate activity

A liquidation feed can show that liquidations occurred without reporting every order. Counting its messages as if they were a complete record understates activity, and summing the published notional does not recover the missing orders.

Binance’s changelog describes one selected liquidation order per symbol within a 1000ms window. It records a change from the latest order to the largest, effective 14 April 2026. That documents selection; it does not establish that the windows align with clock seconds.

Correction made 4 September 2026: our original illustration treated the feed as one publication per occupied clock second. Publication timing does not support that interpretation. The measurements below instead fit a rolling quiet period, which can leave some active seconds with no publication. This is an inferred model, not a documented exchange guarantee. The original illustration has been removed so it cannot be mistaken for the corrected mechanism.

What we observed

So we checked our own capture. On 2026-08-19 we recorded 47,363 liquidation events across the venue. Every single one sat alone in its symbol-second. Maximum: exactly one. Not “usually one”, not “one on average”. The ceiling is the rule, and the rule holds without exception.

Worth being clear who this affects, because it is not a crypto quirk. The rule is a property of the USD-M liquidation stream, and that stream carries every USDT-M perpetual on the venue, including the ones tracking Nvidia, Tesla, AMD, QQQ, gold, silver and oil. If you trade the gold perp or the Nvidia perp, your liquidation data is censored in exactly the same way.

That has two consequences, and they are not subtle.

A liquidation count is not a count of liquidations. It is a count of publications. When this post first ran we wrote that it is a count of seconds that contained at least one, and measurement since then says even that is too generous: some seconds hold liquidations and publish nothing at all. The correction is below, and it moves the number in the direction that hurts.

A liquidation notional is not total liquidation notional. It is the notional of the selected orders that the feed published.

Correction, 2026-09-04: the window is not a clock second

When this post ran on 2026-09-01 we read Binance’s documented “1000ms window” as a clock second: chop the hour into 3,600 slots, publish one order from every slot that had any. Under that reading a published count equals the number of occupied seconds exactly, which is why the sentence above said a count is a count of seconds.

We then measured the gaps between publications instead of the counts inside them, and the reading does not survive. In one hour of BTCUSDT there were 911 publications. The shortest gap between any two of them was 997 milliseconds. Not one of the 910 gaps was under 900 milliseconds, and across every clean month of our capture at most 0.1 percent of gaps are. A clock-second window cannot do that: it would routinely put one publication at the end of a second and the next at the start of the following one, milliseconds apart. Those pairs simply never occur.

What fits is a rolling dead time. After the feed publishes, it goes quiet for about a second. At the first liquidation after the quiet period it publishes again, and the clock restarts from that publication rather than from the top of the second.

The difference matters because of what it does to empty seconds. Under a clock-second window, every second holding a liquidation publishes one. Under a dead time, a second whose liquidations all fall inside the previous publication’s quiet period publishes nothing at all, and that second is indistinguishable from a second in which nothing happened.

We can put a number on it, because the Bybit liquidation dataset used in the published comparison contains 10,044,384 rows over 403 days and 744 symbols. Running both machines over that record:

• the clock-second window publishes 5,424,217 times and hides 46.0 percent of the rows;
• the rolling dead time publishes 4,854,970 times and hides 51.7 percent;
• 569,247 occupied seconds, 10.5 percent of them, publish nothing at all.

On the symbols people actually watch it is worse, because busy symbols spend more of their time inside a dead time: 16.0 percent of BTCUSDT’s occupied seconds are silent, and 15.8 percent of ETHUSDT’s. Roughly one occupied second in six leaves no trace. The result is not sensitive to the exact quiet period: at 900 milliseconds it is 8.9 percent, at 1,100 it is 11.8.

Two honest caveats. That comparison runs the proposed Binance-shaped operator over Bybit’s liquidation rows, so it says what the two machines do to a venue of this shape, not what Binance’s own hidden record contains. And the dead time is a model fitted to publication timing, not a documented rule; it is what the tape is consistent with and the clock-second reading is not.

The earlier Hyperliquid simulations below used the clock-second model. Keep those results separate from the rolling-dead-time simulation; neither is an estimate of how many orders Binance actually omitted.

What the rule costs, measured where we can check

You cannot measure this on Binance. The orders that were dropped are gone, and no amount of care recovers them. But there is one venue where the truth survives: Hyperliquid settles on chain, so its archive carries every liquidation order with an order id attached.

So we took Hyperliquid’s record, grouped fills into orders by coin and order id, applied the original clock-second selection model to it, and counted what was left. Two hours of 2026-08-19, core symbols:

• In a burst hour, 223 liquidation orders occupied 111 symbol-seconds. Half of them never appear.
• In a quiet hour, 72 orders occupied 18 symbol-seconds. Three quarters of them never appear.

In that clock-second simulation, notional loss is smaller: between 6 and 15 percent lost, because liquidation sizes are heavy-tailed and the biggest order in a second usually dominates that second. Count and notional are censored to completely different degrees by the same rule, which is why treating them as two views of one quantity is a mistake.

We got this wrong ourselves first, and the correction is worth stating because it cuts the number down rather than up. Our earlier estimates compared Hyperliquid FILLS against a Binance ORDER stream. That is a unit mismatch, and it inflated apparent censoring by tens of percentage points. Order against order is the only honest comparison, and it produces smaller, more defensible numbers than the ones we started with.

The rule changed in April, so history is not one dataset

Binance’s changelog entry of 2026-04-10, effective 2026-04-14, changed the published order from the LATEST in the window to the LARGEST in the window.

That sounds like a detail. It is the difference between a roughly arbitrary sample and an order statistic. Under the old rule, notional censoring ran between 46 and 94 percent on the same measurement above. Under the new rule it is 6 to 15. Same feed, same field name, same column in your database, and a number whose meaning moved by a factor of five on a Tuesday in April.

Any chart that spans 2026-04-14 is plotting two different quantities with one axis.

Buying a copy of the same feed does not restore missing orders

The source matters. An archive of this public stream retains the same publication limits.

GET /fapi/v1/allForceOrders, the market-wide liquidation endpoint that older guides still recommend for backfill, is no longer maintained and no longer accepts requests.

GET /fapi/v1/forceOrders is private, returns only the calling account’s own liquidations, and has been capped at 90 days since 2026-04-06.

Vendor history sourced from the same public stream retains its omissions. The 1000ms snapshot is applied at Binance’s publication layer, not in transport, so purchased liquidation history carries identical censoring. You would be paying for the same missing orders, with a receipt.

The censoring is permanent. It has to be modelled or acknowledged, and it cannot be undone.

What is still honest to measure

Plenty, as long as you stop calling the count a count.

This section used to say that occupancy is immune to the censoring. It is not, and that was the most useful-sounding wrong thing in this post. The argument was that while the feed destroys how many liquidations happened, it still tells you truthfully which seconds had at least one, so saturation and run lengths could be read straight off the tape without a model. That is only true under the clock-second reading. Under a dead time, one occupied second in ten is silent, and the silent ones cluster precisely in the busy stretches where a run of occupied seconds is what you were trying to measure.

What survives is weaker and still useful. Publication timing is real: a publication means at least one liquidation happened at that moment, so the feed locates cascades in time and on the price axis reliably. Gaps between publications are real. What you cannot do is treat the count of publications as the count of active seconds, or a run of publications as a run of occupied seconds, because the feed’s own quiet period sits between them.

The useful reframing: the feed is not a measurement of liquidation volume, and it is not a one bit per second sensor either. It is an event-triggered sensor with a refractory period, like a Geiger counter with dead time. Read it as a detector and it is informative about when and where. Read it as a total, or even as a census of active seconds, and it undercounts exactly when it matters.

What we are doing about it, and what we will not say yet

As of the 4 September correction, we were researching a reconstruction: a model that estimates the true liquidation record from the censored one, with a stated uncertainty rather than a point estimate.

The success criterion is registered in advance and it does not involve Binance. We take a venue that publishes every liquidation, deliberately censor a copy of its record with Binance’s exact rule, run the model on the mutilated copy, and score the answer against the truth we still hold. The protocol is frozen by hash before the run, it carries pass or fail thresholds written down beforehand, and if it misses them the run refuses and the refusal gets published.

The laboratory has changed since this post first ran. It was Hyperliquid, which settles on chain and carries an order id on every liquidation. It is now Bybit, which publishes every liquidation on its own feed and whose history is purchasable, so instead of two hours we work from 10,044,384 rows over 403 days and 744 symbols, on USDT-settled perpetuals with the same symbols and the same order-based semantics as the venue we are trying to reconstruct. Hyperliquid stays available as an out-of-sample check.

The correction above is why that record matters more than it looks. Rebuilding the censoring machine correctly is most of the problem, and you cannot check whether you rebuilt it correctly against a feed that has already thrown the evidence away.

The reconstruction described here is research in progress, not a validated replacement for observed data. Read published-feed counts as observed activity, and check the feed and measurement period before comparing them.

For the product-level definitions, see how liquidation data is measured.