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% стабильного потока данных. Оценим ваш проект и предложим оптимальное решение — свяжитесь для консультации.