Ринок ф'ючерсів — зона підвищеного ризику: за останні роки сумарний обсяг ліквідацій на централізованих біржах перевищив $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 бірж
| Біржа | WebSocket | REST історія | Обмеження |
|---|---|---|---|
| Binance | !forceOrder@arr |
остання година | Нема глибокої історії |
| OKX | liquidation-orders |
3 місяці | Різні імена полів |
| Bybit | liquidation.{symbol} |
recent-trade | Тільки як трейди |
| Bitmex | liquidation |
з 2014 | Застарілий API |
| Deribit | liquidations.{instrument} |
повна | Тільки BTC/ETH |
| GMX v2 | on-chain event | вся історія | Arbitrum RPC |
Чому 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 — цінові рівні з концентрацією ліквідацій (рівні підтримки/опору).
Порівняння метрик:
| Метрика | Опис | Інтерпретація |
|---|---|---|
| Cumulative liquidation volume | Обсяг ліквідацій за період | >3σ від ковзного середнього → каскад |
| Long/Short ratio | Частка ліквідацій лонгів vs шортів | >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) Детальніше про механізм перепідключення
Колектор використовує експоненційний backoff з початковою затримкою 1 секунда та максимальною 30 секунд. При кожному розриві затримка подвоюється. Після успішного підключення скидається. Це запобігає перевантаженню сервера та гарантує стабільне з'єднання.Як ми будуємо систему збору ліквідацій: покроково
- Аналіз вимог та вибір бірж.
- Розробка WebSocket-колекторів з нормалізацією.
- Проектування схеми TimescaleDB та індексів.
- Налаштування continuous aggregates для аналітики.
- Інтеграція дашборда Grafana.
- Навантажувальне тестування та моніторинг.
- Документація та навчання.
Інвестиції в таку систему обговорюються індивідуально — ми адаптуємо рішення під масштаб вашого проекту. Замовте розробку системи збору ліквідацій — отримайте консультацію інженера та план реалізації.
Обмеження та 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% стабільного потоку даних. Оцінимо ваш проект та запропонуємо оптимальне рішення — зв'яжіться для консультації.