Research is a work in progress. Estimated release: 1 December 2026. Our goal is to make it a search engine for trading setups in recorded crypto markets.

← All readings
Browse related readings

Research Readings Liquidations

Liquidation bunching

Also shown as Cascade clustering

Summarizes uneven spacing between observed liquidation events. It is a smoothed timing estimator using up to 500 events, not a liquidation-volume total.

Live monitoring
Binance Futures only; depends on the full setup
Observed
read at the minute itself
Unit
Ratio
Valid range
0 to 1
How to read it, with examples

How to read it

The estimator transforms the variation in positive inter-event gaps and blends it into a state initialized at 0.8. More variable gaps push the estimate higher; regular spacing pushes it lower. It becomes present after 10 events, so early readings can still be dominated by initialization. A value of 0.5 is an index level, not 50% of liquidations in a cascade. Values stay below 1 by construction and hold through quiet periods.

Study whether liquidation timing is more clustered alongside the current 15-second intensity. A held high index and zero current intensity describe different aspects of the same history.

What it does not prove

It is not evidence that one liquidation caused another. It cannot establish a self-sustaining cascade, current activity or a future cascade probability.

More limits

Publication throttling distorts the timing it observes.

Use in Research

What this cannot see

Binance throttles liquidation publications, so these readings describe the observed feed and miss some liquidation records.

More on this limit

Count estimation is still under validation. It would require uncertainty, support and freshness checks, and would not recover hidden event times or validate a price-level heatmap or cascade forecast.

Technical details

Registry definition

Concentration of liquidation prints into a local cascade.

Engine note

This moment-based estimator is not a fitted Hawkes model.

Field ID

feature.cascade_clustering_index

Valid query operators

at least, at most, between

Window operators: lowest, highest, average, latest or change in, over a trailing window.

Editable query preset

Starting point only. Review and edit before running.

{
  "schema_version": "research_query.v2",
  "normalization_version": "archive_normalization.v1",
  "feature_version": "feature_defs.v1",
  "target": "record_occurrences",
  "where": {
    "all": [
      [
        "feature.cascade_clustering_index",
        "gte",
        0.5
      ],
      [
        "times.anchor_time",
        "gte",
        "2025-07-15T00:00:00.000Z"
      ]
    ]
  },
  "sort": [
    "times.anchor_time",
    "desc"
  ],
  "page": {
    "limit": 5,
    "cursor": null
  }
}

The search reports how often the record held this condition and what followed. It does not decide whether an idea works.

Related readings