Crypto liquidation data: audit what an event measures

Reconcile liquidation sides, price bases, quantities, replayed observations and coverage limits using original event ledgers and explained exercises.

Course outline

1. 1

   Normalize liquidation side labels before comparing venues

   Distinguish the liquidated position from its closing order. Reconcile opposite provider conventions before adding long and short liquidation quantities.

   7 min

   In short: A liquidation labelled Buy can mean a liquidated long (position side) or a buy order closing a short (closing-order side). A long is reduced by selling, a short by buying. Map each feed to liquidated position side before adding long and short quantities, and keep unknown labels unclassified.

2. 2

   Reconcile liquidation prices and sizes before calculating notional

   Separate order value, executed notional and bankruptcy price. A 990-unit order valuation is not 606 units of executed value, and neither is a loss.

   8 min

   In short: For a linear instrument, average fill price × accumulated filled quantity gives executed value, order price × original quantity gives an order valuation, and bankruptcy price × size gives a reference valuation. In the example these are 606, 990 and 588 USDT; none measures a trader's loss.

3. 3

   Separate liquidation messages, event rows, quantity and accounts

   Count batched liquidation observations with an explicit denominator. Three messages can hold six events, and event totals cannot count the people liquidated.

   7 min

   In short: Message count, event-row count, quantity and unique accounts are different measures. Three messages can hold six liquidation rows totalling 41 base units, and rebatching changes the message count without changing quantity. Public rows carry no account identifiers, so event totals cannot count liquidated accounts or people.

4. 4

   Remove a proven liquidation replay without deleting genuine observations

   Distinguish a duplicated local record from equal-valued public events. Use provenance to correct a replay without deleting genuine liquidation observations.

   8 min

   In short: Remove a duplicate liquidation record only when provenance proves it, such as the same stored envelope processed twice. Rows with identical timestamp, side, size and price can be distinct events. In the example, 20 processed units become 15 after one proven replay, and two equal later rows stay unresolved.

5. 5

   Bound liquidation-feed coverage without inventing a market total

   Separate provider selection, collector gaps and result truncation. Test when an observed sum is a lower bound and why a multiplier cannot fix coverage.

   8 min

   In short: Liquidation feeds can miss events through provider selection, collector gaps or query truncation, so a chart total covers only the observations received. A verified, non-overlapping sum is a lower bound, but no multiplier recovers the market total, and an empty interval during a disconnect is not zero liquidations.

Open full-size diagram

1. Normalize liquidation side labels before comparing venues
2. Reconcile liquidation prices and sizes before calculating notional
3. Separate liquidation messages, event rows, quantity and accounts
4. Remove a proven liquidation replay without deleting genuine observations
5. Bound liquidation-feed coverage without inventing a market total

Educational material. Examples do not establish a profitable strategy. Trading costs, gaps and liquidation can produce losses beyond a planned stop.