Developing a liquidation indicator: where the data stream breaks
Data on forced closures comes from the exchange via a separate channel that has its own market data delay — from fractions of a second to several seconds during peak load.
By the time an event reaches the calculation loop, the price has already covered most of the movement, and the indicator draws a spike where the market has long since priced it in.
The timestamp is set twice — on the source side and on the receiver side — and almost no one measures the discrepancy between them.
The second bottleneck is stitching events by time. The forced closure stream is collected from several places: the exchange feed, an aggregator, an in-house quote collector.
If they are merged by receipt time rather than by the exchange timestamp, the same spike is either smeared across several intervals or doubled. Deduplication by trade ID and a unified time scale are mandatory; otherwise the volume in the indicator stops matching reality.
The third and most costly gap is missing trades in the stream during hours of high volatility. The event frequency at such moments grows many times over, the source starts truncating the sample, the buffer overflows, and some forced closures simply never reach the indicator.
The result is an inversion: the signal shows damping where a cascade is underway, and a decision is made based on understated volume. This can only be caught by reconciliation with an independent source and real-time gap monitoring.
Therefore, developing a liquidation indicator begins not with drawing a chart but with assessing market data quality: stream completeness per day, duplicate share, timestamp discrepancy, behavior during a connection loss.
Without these measurements, visualization and alerts are built on numbers that cannot be trusted. We break down how this is addressed at each layer — from event ingestion to signal logic.
What a market data mart provides: measurable effect
Reaction speed is determined by how events enter the system. When liquidations arrive via stream subscription rather than timer-based polling, the path from trade to notification takes seconds — the trader has time to act on the cascade rather than read about it after the fact.
False triggers are the reason notifications are usually disabled. The rule is built not on a single trade but on a cluster: a threshold for total volume in a sliding window, deduplication of repeats, and anti-flood on sending. The share of false triggers drops severalfold, while significant spikes are not lost.
Trade history completeness relies on reconciliation: archived snapshots are loaded by backfill, and time gaps are found by a regular check. Writing is idempotent by event key — repeated delivery does not create duplicates, and restarting the collector does not leave gaps.
Resilience to connection loss is a separate layer. Reconnection uses a growing interval, the buffer holds unsent events, and after the channel is restored the system backfills the missed window and reconciles it with the source. Collection continues without manual intervention from an engineer.
Reduced manual reconciliation comes with a unified summary dashboard: aggregates by exchanges, instruments, and hourly intervals are collected automatically, the scheduled report is generated on a timetable, and discrepancies are raised as a separate event.
Methods of obtaining data: exchange stream, aggregator, own node
A liquidation indicator is built not on candles but on a stream of events: forced position closures, funding rate spikes, order book depth changes.
Sources differ in completeness, latency, and maintenance cost — there is no universal option; the choice depends on the task and on how critical a gap in the stream is.
| Option | When it fits | Limitations |
|---|---|---|
| Direct exchange stream | one or two venues, minimal latency and full event composition required | each venue has its own message schema and subscription limits; if the connection drops, events are lost and the segment must be backfilled from history |
| Market data aggregator | summary across dozens of venues in a unified format | latency is higher than exchange-native; history depth and update frequency depend on the subscription tier, and rare events are filtered out |
| Own node | events from the blockchain network are needed: liquidation transactions in protocols, fees | requires synchronization and maintenance, lags real time by several blocks, and does not see exchanges' internal liquidations |
In practice, the connection scheme is built on two sources: the primary channel provides minimal latency, and a backup data source takes over during a failure — the indicator keeps calculating, and the missed segment is backfilled from archived exports.
Events are normalized to a unified format (venue, instrument, side, volume, time) and deduplicated by trade ID; without this, after reconnection the liquidation counter doubles and the alert triggers falsely.
Implementation stages: from data audit to handover
Implementation begins not with visualization but with checking where liquidation data comes from. Venues provide it differently: some as a stream of events, others only as aggregated intervals with a delay.
Until it is clear what update frequency and history depth are available, any chart is built on guesses.
- Data source audit. For each venue we verify what is available: event stream, history backfill request, rate limits, gaps during certain hours. We record where data is complete and where the metric will have to be reconstructed indirectly.
- Data flow design. We build the path from source to chart: ingestion, normalization to a unified format, buffering, writing to time-series storage, calculation, delivery to the interface. The design immediately shows where to place a queue so that a liquidation spike does not bring down ingestion.
- Collection and storage setup. We bring up a receiver with auto-reconnect and duplicate filtering, and write to a time-series database with different retention policies: raw events separately, aggregates separately.
- Metric calculation. We calculate liquidation volume per interval, breakdown into longs and shorts, accumulation and smoothing, thresholds for signals. The formula lives in a separate module — it can be changed without rebuilding collection and the chart.
- Validation on historical data. We run the calculation over several months of real history and reconcile it with what the venues showed. We look at behavior during sharp moves — that is where gaps and double counting surface.
- Handover to operation. We provide the operating procedure: how to connect a new venue, what to do when the stream breaks, how to restart recalculation, where to monitor collection status. Plus degradation notifications.
Each stage ends with an artifact: a list of sources, a design, a configuration, a formula description, a reconciliation report, and an operating procedure.
Delivery package: configurations, designs, procedures
The client receives not only a working indicator but a package with which the internal team can maintain the solution without us. Below is exactly what is included in the delivery and in what form.
- Data collection configurations — list of sources, polling frequency, rules for matching trades across markets and time zones, thresholds at which a trade is considered a liquidation. Changed by editing a settings file, without rebuilding.
- Data flow design — the path from trade ingestion to metric calculation and chart rendering: where the buffer accumulates, where duplicates are filtered out, what happens when the channel breaks, and how the missed interval is restored.
- Access rules and roles — who sees only aggregates, who can change thresholds, who manages alert subscriptions; every threshold change is written to a log with author and time.
- Solution documentation — metric formulas, field dictionary, analysis of typical discrepancies with exchange data, instructions for local launch on a test dataset.
- Operating procedure — the order for updating sources, daily data completeness monitoring, on-duty actions when a liquidation spike is not confirmed by a market event.
- Alert settings — message texts, trigger thresholds, and quiet hours so the indicator does not burn out the team's attention.
The package is delivered in a shared repository together with change history — further enhancements can be carried out by your own team or with us.
Case study: eliminated signal delay and false triggers
Starting point
The trading team received a signal about a liquidation spike with a delay of tens of seconds — by that time the move had already played out, and entering on such a notification was late.
Data came from several sources, and it had to be reconciled manually: reconciliation took two to three hours a day, and discrepancies in spike volume still remained.
The trigger threshold was the same for all market regimes. In a calm market it caught noise — the share of false signals reached one third. When the connection dropped, the feed simply stopped: recovery required a manual restart and re-loading of history.
What was changed and what was achieved
Data ingestion and calculation were separated: the stream passes through a buffer with delivery confirmation, aggregation is calculated over time windows, and the threshold adapts to volatility over the last few hours.
Reconnection and backfilling of the missed segment are performed automatically, so a disconnection no longer means data loss.
Reconciliation with an independent source, CoinGlass, was switched to automatic mode: convergence is checked once a day, and discrepancies are visible immediately.
Signal delay decreased from tens of seconds to one or two, the share of false triggers fell from one third to a few percent, and recovery after a disconnection takes less than a minute and does not require a person. Manual reconciliation disappeared entirely.
The before-and-after metrics were taken on the same set of market events — the comparison is correct, not based on a "felt" impression.
How the liquidation stream differs from an estimated volume calculation
Confusion arises because both numbers describe the same phenomenon — forced position closure — but are obtained in different ways. The liquidation stream is actual exchange data: a record comes from the venue with the price, side, and notional of the closed position.
The calculated volume estimate is a reconstruction of the same events from indirect signs when there is no direct stream for the instrument.
The actual stream is almost never complete. A large position is rarely closed in a single execution — it exits in a series of trades, and part of the volume is absorbed through an insurance fund or auction, and such closures do not enter the stream.
Exchanges publish data with different levels of detail: some provide every event, others a summary per interval, and for some instruments there is no stream at all.
The calculation methodology relies on a combination of "a sharp price move plus a faster-than-usual drop in open interest": the difference is attributed to forced closures, and the candle's direction determines the side.
There is always an assumption inside — what share of the open interest reduction came specifically from liquidations and what share from manual position closing. Hence the discrepancy of severalfold: the estimate counts position notional, while the stream counts executed volume.
Discrepancies between sources are exacerbated by different aggregation windows and definitions of liquidation at each venue. Public aggregators such as CoinGlass combine heterogeneous data into a single figure, and it rarely matches what a trader sees in their exchange terminal.
In the indicator these layers are separated: the stream and the estimate run as separate series, each point has a source attribute, and where there is no stream, the value is marked as calculated.
Technical concerns: delays, gaps, resilience
Delay in the liquidation stream, a missed event, a discrepancy between sources — for public market data this is normal operation, not an emergency.
The question is whether the indicator notices it: a silently smoothed gap is more dangerous than an explicit error, because decisions are made based on it.
Therefore, completeness control is built into the pipeline itself — every event has a sequence number, and a numbering gap is recorded before the figure reaches the chart. Below are analyses of the questions that most often arise during acceptance.
What happens if some events did not arrive?
We backfill the unavailability window with a history request and filter out duplicates by trade ID. We mark the stitched segment on the chart with a separate label — the gap is visible rather than dissolving into the smoothed line.
Sources give different volumes — which one should be trusted?
We consider the source with the greatest completeness as the baseline, and the others work as reconciliation sources. A discrepancy above a specified threshold is highlighted as a separate event rather than silently averaged.
What happens during a connection loss?
Reconnection with a growing pause, event buffer on disk, calculation state is not reset. A disconnection alert goes to the same channel as trading signals — there are no silent failures.
The exchange changed the event format?
The schema is described by configuration, so a new format is connected by modifying the adapter without rebuilding the calculation logic. Before release we run a recorded event set and compare the resulting values with the reference.
Let's discuss the task: we'll assemble a design and work plan
To come back with an estimate and work plan rather than generalities, we need a brief input from you on the task. Below is what is sufficient to prepare; we will clarify the rest during the review.
- List of exchanges and trading pairs for which a liquidation indicator is needed, and the priority among them.
- Event definition: from what volume a position is considered liquidated and over what window data should be summed.
- History depth: for what period data should be loaded and whether backfilling of the missed segment is needed after a connection failure.
- Visualization format: volume clusters, heatmap, event feed — and on which screen this is viewed.
- Alert channels: messenger, email, sound in the terminal, or your own signal receiver; trigger rule and duplicate protection.
- Access: rights to read market data, in which environment the system operates, and where history is allowed to be stored.
- Load: how many users and how many events at peak the design must handle without losing snapshots.
Based on the review, we will return a solution design: data sources, processing layer, storage, interface, and alerts — plus work stages with an estimate and launch order.
The next step is simple: you describe the task and inputs, we review them and send a design with an estimate and plan. If data for some point is not yet available — just say so, and we will put together options.