How I Built a Real-Time Bitcoin Liquidation Heatmap From Scratch

Every liquidation heatmap I found was lying to me.

Not intentionally. They were just slow. Two-minute update intervals in a market where $500M gets liquidated in 30 seconds. By the time the map refreshed, the move was already over. The data was a postmortem, not a tool.

So I built one that updates every 12 seconds, pulling from four exchanges simultaneously. Here is exactly how.

Architecture: Four Exchanges, One Map

Binance  ─┐
Bybit    ─┤──▶ Aggregation Layer ──▶ Normalization ──▶ Canvas Render
OKX      ─┤         (merge)            (weight)          (draw)
Aster    ─┘

Each exchange exposes liquidation and order book data through WebSocket feeds and REST endpoints. I poll all four in parallel on a 12-second interval, merge the results into a single dataset, normalize across exchanges, and paint it onto a canvas element.

Why 12 seconds? It is the shortest interval I could sustain across all four APIs without getting rate-limited. Binance is the bottleneck.

The Hard Part: Cross-Exchange Normalization

Binance reports 10x the volume of Aster. If you just sum raw liquidation values, the heatmap becomes a Binance map with noise from three other sources.

The fix is proportional weighting based on open interest, not raw volume.

function normalizeExchangeData(exchanges) {
  const totalOI = exchanges.reduce((sum, ex) => sum + ex.openInterest, 0);

  return exchanges.flatMap(ex => {
    const weight = ex.openInterest / totalOI;
    return ex.liquidations.map(liq => ({
      price: liq.price,
      intensity: liq.volume * weight,
      side: liq.side
    }));
  });
}

The weight factor is recalculated every cycle because open interest shifts constantly. Get this wrong and your heatmap lies to you.

Rendering: Why Canvas, Not DOM

First version used DOM elements. Colored divs positioned absolutely across a grid. Desktop worked fine. Mobile caught fire.

Hundreds of elements being repositioned every 12 seconds turned mid-range phones into space heaters. Layout thrashing killed the frame budget.

Canvas fixed everything. One element, one rendering context. The draw cycle clears and repaints from the normalized dataset. On a modern phone: under 8ms per frame.

Key optimization: bucket liquidation data into price bands before rendering. A 500-pixel-tall canvas does not need 10,000 individual data points. It needs 200 aggregated price bands. Bin first, draw second.

What the Map Reveals Right Now

BTC at $69,163 today. Down 2.26%. Fear and Greed at 10 — extreme fear. Here is what the map shows:

Below current price: Dense liquidation cluster between $67,800 and $68,200. Leveraged longs from the past week stacked here. If price dips into this range, expect a cascade — forced selling triggers more liquidations triggers more selling.

Above current price: Short liquidations clustered around $71,500. That is where the current batch of shorts would get squeezed.

The gap between these two zones is where price is consolidating. When it breaks toward either side, the liquidation cascade will accelerate the move far beyond what organic volume would produce.

This is what a heatmap is actually for. Not predicting direction — mapping where the landmines are buried.

What I Learned

WebSocket connections are fragile. Exchanges drop connections silently. You need automatic reconnection with exponential backoff, plus data freshness checks. If an exchange has not sent new data in 30 seconds, I drop and reconnect.

Mobile is the real benchmark. If it stutters on a three-year-old Android, it does not ship. Pre-allocate typed arrays. Zero allocations in the hot path.

Four sources beat one, but only with proper normalization. A naive merge misleads worse than a single exchange. The normalization layer is not optional — it is the product.

The heatmap runs live at bitcoinkevin.com/en/bitcoin-liquidation-map-live/. If you are building anything with real-time financial data, these aggregation and normalization patterns apply well beyond crypto.