How to Monitor Liquidation Data for ETHUSDT Futures?

Understanding Liquidation Data Sources

1. Exchange-native liquidation endpoints provide raw, unfiltered records of forced position closures. OKX exposes /api/v5/public/liquidation-orders with fields including instId, side, fillPx, fillSz, and ts.

2. Binance delivers liquidation events via WebSocket stream !forceOrder@arr, broadcasting real-time fills across all symbols with millisecond precision.

3. Bybit publishes historical liquidations through REST /v5/position/liq-record, supporting pagination and time-range filtering up to 90 days.

4. Deribit’s public/get_last_trades_by_instrument includes a liquidation flag in each trade object, enabling post-hoc identification without dedicated endpoints.

5. Third-party aggregators like Coinglass and Glassnode offer normalized liquidation feeds but introduce latency and may omit partial fills or off-exchange settlements.

Data Structure and Field Interpretation

1. instId identifies the instrument—ETH-USDT-SWAP for OKX, ETHUSDT for Binance—requiring symbol mapping logic before aggregation.

2. side indicates whether the liquidated position was long or short, directly signaling directional pressure on price action.

3. fillPx reflects the execution price, often clustered near key support/resistance zones where margin calls cascade.

4. fillSz denotes contract size in base units; multiplying by mark price yields notional value, critical for assessing systemic risk exposure.

5. ts is a Unix timestamp in milliseconds; alignment across exchanges demands timezone-aware parsing and deduplication logic.

Real-Time Ingestion Architecture

1. WebSocket connections must implement heartbeat monitoring and automatic reconnection to prevent missed events during network flaps.

2. Each message payload requires immediate schema validation—missing fillPx or malformed ts triggers discard-and-log rather than crash.

3. Deduplication relies on exchange-specific unique IDs: OKX uses ordId, Binance uses tradeId, requiring per-source ID hashing before storage.

4. Local buffering with Redis Streams enables backpressure handling when downstream databases lag during volatility spikes.

5. Timestamp synchronization across sources uses NTP-aligned system clocks—not exchange-provided timestamps—to avoid skew from server clock drift.

Historical Backfill Strategies

1. REST-based backfill starts from latest known timestamp and walks backward in 100-record chunks to avoid rate-limit triggers.

2. OKX enforces a 20-request/2-second limit on public endpoints; batching by instrument reduces total request count by 60%.

3. Binance restricts historical force-order queries to the last 7 days via REST; older data requires archival log parsing or third-party archives.

4. Bybit allows date-range queries but returns only 50 records per page—pagination logic must track cursor tokens, not just offset integers.

5. Missing intervals are flagged with checksummed gap reports, triggering manual verification against on-chain settlement logs where available.

Common Questions and Answers

Q: Can I rely solely on WebSocket for complete liquidation coverage?WebSocket streams do not guarantee delivery order or zero packet loss. A hybrid approach combining WebSocket ingestion with periodic REST reconciliation is mandatory for production-grade accuracy.

Q: Why do liquidation prices differ between exchanges for the same ETHUSDT timestamp?Divergence arises from differing mark price methodologies, funding rate accrual timing, and isolated order book depth—no universal “true” liquidation price exists across venues.

Q: Is there an open-source parser for OKX liquidation WebSockets?Yes—the okx-liquidation-parser npm package handles message deserialization, field normalization, and error recovery for all public OKX streams.

Q: How often do exchanges purge historical liquidation records?OKX retains public liquidation data for 30 days. Binance retains 7 days via REST. Bybit maintains 90 days. These windows are fixed and non-negotiable.