WebSocket-колектори та on-chain парсинг: дані ліквідацій з бірж

Ринок ф'ючерсів — зона підвищеного ризику: за останні роки сумарний обсяг ліквідацій на централізованих біржах перевищив $100 млрд. Кожна ліквідація — це не просто втрата позиції, а сигнал ринку. Різке зростання ліквідацій лонгів вказує на паніку та потенційне продовження падіння. Каскад ліквідацій шортів може спровокувати short squeeze. Проблема в тому, що кожна біржа віддає дані по-своєму: різний формат, різна історична глибина, різні затримки. API можуть деградувати під навантаженням, що критично для алготрейдингу. Трейдери часто стикаються з ситуацією, коли ліквідації на Bybit приходять із затримкою 2–3 секунди, а на Binance — без затримки. Такий рознобій ламає розрахунок дельти ліквідацій і призводить до хибних сигналів. Без нормалізованого потоку ви ризикуєте приймати рішення на основі зашумлених даних. Ми вирішили це завдання: розробили колектори, які підключаються до WebSocket і REST API 5+ бірж, нормалізують потік в єдиний інтерфейс і пишуть у TimescaleDB. Результат — консистентний потік даних ліквідацій для ваших стратегій. Слід зазначити, що своєчасне виявлення каскадів ліквідацій дозволяє запобігти збиткам, порівнянним з річним бюджетом трейдингу.

Згідно з Wikipedia, ліквідація — це примусове закриття позиції при нестачі маржі.

Які біржі віддають ліквідації в реальному часі?

Централізовані:

Binance — WebSocket endpoint wss://fstream.binance.com/ws/!forceOrder@arr стримить ліквідації по всіх ф'ючерсних парах. Формат події:

{
  "e": "forceOrder",
  "E": 1704067200000,
  "o": {
    "s": "BTCUSDT",
    "S": "SELL", // SELL = long liquidation
    "o": "LIMIT",
    "f": "IOC",
    "q": "0.014", // quantity
    "p": "41850.00", // price
    "ap": "41800.00", // average price
    "X": "FILLED",
    "l": "0.014",
    "z": "0.014",
    "T": 1704067200000
  }
}

Історичні дані — тільки за останню годину через REST (/fapi/v1/forceOrders). Для повної історії потрібно безперервно писати з моменту запуску.

OKX — WebSocket channel liquidation-orders, REST історія 3 місяці (/api/v5/public/liquidation-orders). Bybit — topic liquidation.{symbol}, дані через /v5/market/recent-trade. Bitmex — найстаріше джерело (дані з моменту запуску). Deribit — опціони та ф'ючерси BTC/ETH.

Децентралізовані:

GMX v2 — подія PositionLiquidated на Arbitrum, парсинг через The Graph або пряму підписку. dYdX v4 — Cosmos RPC. Hyperliquid — власний L1 з повною історією. Aave v3 та Compound v3 — lending ліквідації через LiquidationCall / AbsorbCollateral. Вони не perps, але доповнюють картину.

Як нормувати дані з різних бірж?

Критична єдина структура. Ми використовуємо інтерфейс:

interface LiquidationEvent {
  exchange: string;
  symbol: string;
  side: 'long' | 'short';
  price: number;
  quantity: number;
  quantity_usd: number;
  timestamp: number;
  raw: Record<string, unknown>;
}

Приклад реалізації колектора для Binance:

import WebSocket from 'ws';

class BinanceLiquidationCollector {
  private ws: WebSocket;
  private reconnectDelay = 1000;

  async connect(onEvent: (event: LiquidationEvent) => Promise<void>) {
    this.ws = new WebSocket('wss://fstream.binance.com/ws/!forceOrder@arr');

    this.ws.on('message', async (data) => {
      const raw = JSON.parse(data.toString());
      const event = this.normalize(raw);
      await onEvent(event);
    });

    this.ws.on('close', () => {
      setTimeout(() => {
        this.reconnectDelay = Math.min(this.reconnectDelay * 2, 30000);
        this.connect(onEvent);
      }, this.reconnectDelay);
    });

    this.ws.on('open', () => {
      this.reconnectDelay = 1000;
    });
  }

  private normalize(raw: any): LiquidationEvent {
    return {
      exchange: 'binance',
      symbol: raw.o.s,
      side: raw.o.S === 'SELL' ? 'long' : 'short',
      price: parseFloat(raw.o.ap),
      quantity: parseFloat(raw.o.q),
      quantity_usd: parseFloat(raw.o.ap) * parseFloat(raw.o.q),
      timestamp: raw.E,
      raw,
    };
  }
}

Для кожної біржі — своя реалізація з нормалізацією side, price, quantity. Помилки в side — часта проблема: на Binance SELL = long liquidation, на інших може бути навпаки. Верифікуємо логіку на тестових даних.

Порівняння API бірж

Чому TimescaleDB для зберігання ліквідацій?

TimescaleDB — вибір №1 для time-series. Гіпертаблиця:

CREATE TABLE liquidations (
    time TIMESTAMPTZ NOT NULL,
    exchange TEXT NOT NULL,
    symbol TEXT NOT NULL,
    base_asset TEXT NOT NULL,
    side TEXT NOT NULL,
    price NUMERIC(20, 8),
    quantity NUMERIC(20, 8),
    quantity_usd NUMERIC(20, 2),
    raw JSONB
);

SELECT create_hypertable('liquidations', 'time');

CREATE INDEX ON liquidations (base_asset, time DESC);

CREATE MATERIALIZED VIEW liquidations_1m
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 minute', time) AS bucket,
    base_asset,
    exchange,
    SUM(CASE WHEN side = 'long' THEN quantity_usd ELSE 0 END) AS long_liq_usd,
    SUM(CASE WHEN side = 'short' THEN quantity_usd ELSE 0 END) AS short_liq_usd,
    COUNT(*) AS count
FROM liquidations
GROUP BY bucket, base_asset, exchange;

TimescaleDB обробляє запити в 10 разів швидше PostgreSQL для такого типу даних.

Метрики та індикатори

• Cumulative liquidation volume — сума за період. Різке зростання > 3σ від ковзного середнього — сигнал каскаду.
• Long/Short ratio ліквідацій — якщо 80%+ однієї сторони — направлений сигнал.
• Liquidation clusters — цінові рівні з концентрацією ліквідацій (рівні підтримки/опору).

Порівняння метрик:

import pandas as pd
import numpy as np

def detect_liquidation_cascade(df: pd.DataFrame, window_minutes: int = 5, std_multiplier: float = 3.0) -> pd.Series:
    rolling = df.set_index('time')['quantity_usd'].rolling(f'{window_minutes}T')
    mean = rolling.mean()
    std = rolling.std()
    current = df.set_index('time')['quantity_usd']
    return current > (mean + std_multiplier * std)

Як ми будуємо систему збору ліквідацій: покроково

1. Аналіз вимог та вибір бірж.
2. Розробка WebSocket-колекторів з нормалізацією.
3. Проектування схеми TimescaleDB та індексів.
4. Налаштування continuous aggregates для аналітики.
5. Інтеграція дашборда Grafana.
6. Навантажувальне тестування та моніторинг.
7. Документація та навчання.

Інвестиції в таку систему обговорюються індивідуально — ми адаптуємо рішення під масштаб вашого проекту. Замовте розробку системи збору ліквідацій — отримайте консультацію інженера та план реалізації.

Обмеження та edge cases

Біржі не завжди віддають всі дані: агрегують дрібні ліквідації, вводять затримки. Історичні дані можуть ревізуватися. WebSocket message lag: при високому навантаженні затримка 1–5 секунд — саме коли дані найбільш важливі. Timestamp в raw — час ліквідації, не доставки. Cross-exchange deduplication: одна позиція може бути розбита на кілька ордерів.

Що входить в роботу

• Код колекторів для 5+ бірж (централізовані + DeFi) з автоматичним перепідключенням та backoff.
• Нормалізація в єдиний інтерфейс та запис у TimescaleDB з continuous aggregates.
• Документація архітектури та API для інтеграції.
• Дашборд у Grafana з heatmap ліквідацій та детектором каскадів.
• Навчання вашої команди роботі з системою.
• Підтримка 1 місяць після запуску.

Наш досвід та гарантії

5+ років розробки блокчейн-рішень, 30+ проектів з high-load парсингу біржових даних. Гарантуємо uptime колекторів 99.9% стабільного потоку даних. Оцінимо ваш проект та запропонуємо оптимальне рішення — зв'яжіться для консультації.