A crypto liquidation heatmap plots price against time to show concentrations of potential forced closures. Some estimate levels from market data and leverage assumptions; others use visible account states. Bright bands show conditional exposure, not resting orders or proof of completed trades. Before using one, identify its methodology, covered markets and timestamp, then distinguish it from a feed of reported liquidation events.
Read the axes, then read the methodology
In the common layout, time runs horizontally and price vertically. A colored band represents the provider's measure of liquidation exposure at a price or price interval. The color scale tells you how that exposure compares with other displayed values. A brighter band does not, by itself, supply a probability that price will visit it.
Start with the chart's legend and settings. Record the instrument, selected exchanges, aggregation window and model version where available. A BTC-wide aggregate and a single BTCUSDT perpetual are different research objects, even when both pictures say “Bitcoin.”
CoinGlass describes its aggregated Model1 heatmap as calculating levels from market data and liquidation leverage levels. That description gives no basis for treating the values as a list of orders waiting to execute. CoinGlass Model1 API documentation.
Its explanatory guide also says the heatmap does not specify the actual future number of liquidations or their exact closing prices, and that the displayed scale should be interpreted relatively. Treating a yellow region as a guaranteed dollar amount of selling would exceed that description. CoinGlass's heatmap explanation.
That distinction leaves a useful role for the picture: it can identify a conditional concentration worth investigating. It cannot decide entry, position size or exit conditions on its own.
Identify which kind of evidence the picture contains
Several different datasets can appear as colored price bands. Their visual resemblance does not make their meanings interchangeable.
| Display or dataset | What the underlying observation means | What it cannot establish alone |
|---|---|---|
| Modeled liquidation levels | Estimated potential exposure under the provider's assumptions | Exact account triggers, future forced volume or fill prices |
| Account-state liquidation levels | Levels reported or calculated from a set of visible account states | That those accounts will keep the same collateral and exposure |
| Reported liquidation events | Venue messages describing liquidation activity that occurred | Complete market totals without checking stream coverage |
| Order-book liquidity | Displayed bids and asks at the observation time | Account liquidation thresholds or guaranteed available depth |
Avoid saying that every heatmap is necessarily modeled from aggregate data. CoinMarketCap, for example, describes its Hyperliquid heatmap as recording on-chain open-position liquidation levels roughly every five minutes. It explicitly distinguishes those levels from orders resting on a book. This is a provider-specific description, not an independent audit of its collection. CoinMarketCap's heatmap methodology.
Even a level taken from visible account state remains conditional on that state. It is not an executed trade. Likewise, an order-book heatmap records a separate object: submitted liquidity. The order-book depth guide explains why a displayed price and the executable cost of a particular quantity need separate checks.
Why a plausible band can fail to match actual liquidations
Aggregate market statistics cannot reveal every account's collateral, entry history and risk treatment. If a model allocates exposure across assumed leverage levels, a different allocation can produce different risk bands from the same starting observations. An attractive rendering does not remove those assumptions.
Open interest is especially easy to overinterpret. It measures outstanding contracts under a specified counting convention; it is not a list of individual account leverage settings. Flat open interest can also conceal opening and closing activity that offsets. Our open interest versus volume ledger demonstrates that ambiguity without inventing account identities.
Account risk is not always reducible to one fixed price either. Bybit's position documentation describes the cross-margin liquidation-price field as estimated because unified-mode risk is controlled at account level; the field is empty for portfolio margin. Applying a single isolated-position formula universally would miss this distinction. Bybit position field definitions.
An existing position might close voluntarily, change size or receive margin before a candidate band is reached. A later snapshot can therefore describe a different situation from the one originally pictured. Keep the observation time attached to the claim.
Finally, reaching a plotted trade-price level is not sufficient proof that an account's liquidation condition was reached. The relevant risk reference and margin mechanism matter. The mark-price and liquidation timeline explains why a last-trade chart and a liquidation trigger can tell different stories.
Observed liquidation feeds need their own checks
Event data provides stronger evidence that something happened, but its field definitions and collection rules still matter.
Bybit documents its allLiquidation.{symbol} stream as pushing all liquidations for the covered USDT, USDC and inverse contracts, at a 500 ms frequency. Its S field describes position side: Buy means a long was liquidated. Its v is executed size, while p is bankruptcy price. Do not silently relabel p as the average execution price. Bybit All Liquidation documentation.
Binance's documented USDⓈ-M liquidation-order snapshot stream applies a different rule: for each symbol, it sends only the latest liquidation order within a 1,000 ms interval. Latest does not mean largest. Its payload also separates original quantity, average price, last filled quantity and accumulated filled quantity. Those fields have different jobs. Binance Liquidation Order Streams.
A downstream collector can introduce additional gaps through disconnections or incomplete subscriptions. A venue's documented coverage is not proof that a particular dashboard received every eligible message. A blank interval could mean no event, or missing observation; preserve that uncertainty when collection health is unknown.
A one-second example: selection changes the reported total
The following is an invented teaching scenario, not captured exchange data. Assume three distinct, fully filled liquidation orders for the same hypothetical linear BTCUSDT contract occur within one defined 1,000 ms selection interval. Quantities are BTC, average execution prices are USDT per BTC, and all three liquidate long exposure.
For this exercise, notional equals executed quantity multiplied by average execution price. There are no partial-fill updates or duplicate messages.
| Order time within the interval | Executed quantity | Average execution price | Executed notional | Retained by a latest-only snapshot |
|---|---|---|---|---|
| 100 ms | 2 BTC | 60,000 USDT | 120,000 USDT | No |
| 400 ms | 3 BTC | 59,950 USDT | 179,850 USDT | No |
| 800 ms | 1 BTC | 59,900 USDT | 59,900 USDT | Yes |
The complete constructed ledger totals 120,000 + 179,850 + 59,900 = 359,750 USDT. The latest-only observation contains 59,900 USDT, about 59,900 ÷ 359,750 × 100 = 16.65% of that ledger. It retains the smallest of these three events because that event was last.
This example illustrates the documented selection rule, not an estimate of Binance's real reporting fraction. Another interval could retain a much larger share. Multiplying every public observation by three would not reconstruct the missing quantity.
Now suppose a heatmap saved before the interval showed a bright concentration near 60,000. Neither the 359,750 ledger nor the 59,900 snapshot automatically measures that band's accuracy. First establish what the band represented, which venues it covered, whether its price reference matches, and the horizon over which the claim was meant to apply.
If the band is relative intensity, dividing an event total by its color value has no valid interpretation as a percentage forecast error. If the event dataset is sampled, calling its total the complete outcome adds a second mismatch.
Use a worksheet before calling a heatmap accurate
Save the original map before the price move. A chart retrieved afterward may not preserve what was knowable at the decision time. If historical revisions or reconstruction rules are undocumented, record that limitation instead of assuming the current historical display is an untouched forecast archive.
| Validation item | Record before evaluating the claim | What makes the comparison unresolved |
|---|---|---|
| Origin | Provider, source dataset, model or account-state method | Methodology is unspecified |
| Scope | Venue list, exact contracts, long/short convention | Aggregate map compared with one venue's event feed |
| Timing | Map observation time, evaluation horizon, event and arrival times | Snapshot was saved after the outcome or collection gaps are unknown |
| Price and size | Price reference, band boundaries, quantity units and valuation method | Bankruptcy price treated as a fill price, or contracts treated as coins |
| Outcome | Predefined event measure and feed selection rules | Reported snapshots treated as every liquidation |
| Comparison | Fixed baseline and all eligible observations | Only memorable successful bands are selected |
A practical research question might be: “Across every saved hourly snapshot, did the predefined bright price band contain more subsequent reported liquidation notional than an equally wide comparison band?” Specify what happens when price never reaches either band. Keep the same market coverage, horizon and missing-data policy throughout.
That tests a narrower association than “price hunts liquidity.” It does not establish who caused a move, a profitable execution rule or a transferable edge. Trading performance would require a separate cost-aware execution study.
If AI summarizes the chart, require it to preserve these distinctions in the output: estimated level, observed account state or reported event. The AI crypto sentiment analysis guide applies the same source-first discipline to another kind of market inference. Combining two summaries does not create two independent confirmations when both inherit the same raw evidence.
For public account or chain data, also keep the unit of observation explicit. The active addresses versus users guide explains why a visible identifier should not casually become a count of independent people. A cluster of accounts is not automatically a cluster of unrelated traders.
Before citing a bright band, write one sentence naming its source, market scope, timestamp and conditional meaning. Then write a separate sentence stating what the liquidation feed actually reported and what it may have missed. If those two sentences cannot be completed, keep the conclusion open.