크로스 익스체인지 청산

데이터 출처

3 거래소의 WebSocket 피드, 자산별로 정규화된 Redis 스트림. 모든 실행된 청산 출력이 테이프에 들어옵니다 — open interest로 청산 압력을 추정하지 않고, 손절 존을 추론하지 않으며, 출력을 합성하지 않습니다.

• Binance. wss://fstream.binance.com/market/ws/<symbol>@forceOrder — 심볼별 공개 스트림. 옛 경로 /ws/는 Binance가 조용히 throttle. /market/ws/가 실제 활성 경로.
• Bybit. wss://stream.bybit.com/v5/public/linear의 allLiquidation.<SYMBOL> 토픽.
• OKX. wss://ws.okx.com:8443/ws/v5/public의 liquidation-orders 채널, instType SWAP.

단일 Rust 바이너리 mt-liqd(세 청산 거래소의 일곱 자산을 한 프로세스에서 처리)가 이벤트를 자산별 Redis Stream prod:liq:<asset>:events에 기록. 상한 MAXLEN ≈ 10 000(약 4시간 캐스케이드 밀집 데이터, 한산한 날엔 24시간 전체). 백엔드는 REST와 WebSocket 두 표면 모두 단일 자산 스트림에서 읽음. 별도 pubsub 채널 없음 — 스트림 자체가 브로드캐스트 표면.

이벤트 스키마

이벤트별 필드는 세 출처에서 동일. 두 타임스탬프는 의도적으로 구분:

• ts_ms — 거래소가 찍은 거래 타임스탬프. 거래소 간 출력 시간 비교에는 이 필드 사용.
• producer_ts_ms — mt-liqd 바이너리가 쓸 때의 wall clock. producer_ts_ms − ts_ms는 가시적 피드 지연과 우리와 거래소 간 clock skew. p50/p99 보고용 200 이벤트 롤링 링 버퍼에 샘플링됨.
• exchange ∈ {binance, bybit, okx}.
• side ∈ {long, short} — 아래 의미론 참조.
• qty — 기초 자산 단위 (BTC, ETH …).
• price — 해당 출력에 대한 거래소의 기준 가격(호가 통화). Binance는 forceOrder 가격, Bybit과 OKX는 파산 가격(bankruptcy price).
• usd = 기초 자산 수량 × 그 기준 가격. 체결 명목가가 아니라 추정치로 보세요. Bybit과 OKX가 청산 시 게시하는 파산 가격은 포지션 증거금이 소진되는 수준이지 청산 주문이 실제로 체결된 가격이 아니기 때문. 자산 간 비교는 USD로. BTC와 DOGE 사이 원시 qty 비교는 무의미.

사이드 의미론

청산 스트림은 거래소의 청산 주문 관점에서 사이드를 인코딩하는데, 트레이더의 포지션과 반대. 우리는 실패한 포지션 방향으로 정규화:

• side: "long" — 롱 포지션이 강제 청산(가격이 청산 수준 아래로 이동). Binance에서는 SELL forceOrder, Bybit에서는 side: "Buy"인 포지션이 청산, OKX에서는 posSide: "long".
• side: "short" — 숏 포지션이 강제 청산(가격 상승). Binance에서는 BUY forceOrder, Bybit에서는 side: "Sell"인 포지션, OKX에서는 posSide: "short".

Bybit 특유의 주의: allLiquidation.S 필드는 청산 주문 쪽이 아니라 포지션 쪽 — 즉 S: "Buy"는 롱이 청산됐다는 뜻으로 Binance의 forceOrder 관례와 반대. mt-liqd가 이에 맞춰 매핑.

테이프 색상은 이를 따름: 빨강 점 = 롱이 날아감(가격 하락), 초록 점 = 숏이 날아감(가격 상승).

크기 스케일링

viewBox-px의 점 반지름은 clamp(√(usd / $10 000) × 2, 4, 22). sqrt가 면적별 선형 스케일링을 억제하여 $1 M 이벤트가 $100 K 이벤트의 약 ~3.16배로 보이게 함 — 10배가 아님 — 그리고 단일 캐스케이드 출력이 주변 모든 것을 가리지 않음. 하한 clamp는 $10 K 미만의 작은 이벤트에 가독 hit 영역 유지. 상한 clamp는 가장 큰 캐스케이드가 패널을 벗어나지 않게 함.

r = clamp(sqrt(usd / 10_000) * 2, 4, 22)   // viewBox-px

# 참고 값(크기 범례)
$10 K   → r ≈ 4
$100 K  → r ≈ 6.3
$1 M    → r = 20
$10 M+  → r = 22 (clamped)

적응 렌더링

원시 산점도는 ~15분 체제까지만 스케일링됨. 그 이상에서는 1초 내 수백 개의 작은 출력이 균일한 빛으로 뭉쳐 캐스케이드 구조가 사라짐. 우리는 윈도우에 따라 렌더 모드를 전환:

• ≤ 15분. 원시 산점 — 이벤트당 원 1개. 가장 큰 점을 마지막에 그려 캐스케이드가 잡티 위로 가독.
• 1시간–4시간. (시간, 사이드)별 1분 버킷. 비어 있지 않은 버킷당 원 1개, Σ usd로 크기, 버킷 내 거래량 가중 가격에 그려짐. 원 안의 작은 N× 배지는 그 버킷이 합친 기저 이벤트 수.
• 24시간. 5분 버킷으로 같은 로직.

Hit 테스트, top-N 주석, 툴팁은 렌더링된(버킷화된) 이벤트에 대해 실행. 클러스터 탐지, 누적 패널, 속도 서브 패널은 원시 이벤트를 스캔 — 이 신호는 호버 대상이 아닌 이벤트당 밀도와 사이드 흐름에 관한 것이기 때문.

클러스터 탐지

가격 클러스터 대역은 활성 윈도우의 원시 이벤트에서 탐지:

reference_price = 현재 mid (최신 이벤트 가격)
bin_width       = reference_price * 0.001    // 0.1 %
이벤트를 round((price - reference) / bin_width)로 빈

각 빈에 대해:
  if Σ usd ≥ 윈도우 총액의 15 % AND distinct events ≥ 3:
    클러스터로 표시
    cluster_price = 빈 가격의 거래량 가중 평균

Σ usd로 상위 3개 클러스터 보유

각 클러스터는 점선 수평선과 배지 $X cluster · N× @ price를 받음. 거래량 가중 평균(빈의 명목 중간점이 아닌)이 선을 달러가 실제로 집중된 깊이에 위치시킴.

캐스케이드 알림 임계값

별도 데몬 mt-cascade가 같은 스트림을 읽고 윈도우가 기준을 넘으면 알림을 게시. 30초마다 자산별 직전 5분 윈도우를 다시 읽고, 윈도우 합계가 임계값에 도달하고 AND 최소 두 거래소가 기여했을 때 캐스케이드로 판정. 임계값은 7일 룩백 동안 비어 있지 않은 시계 정렬 5분 청산 버킷의 트레일링 p99이며, 5분마다 재계산되고 $50 M로 하한 설정. 그런 버킷이 100개 쌓이기 전까지는 $50 M 기본값이 대신 적용. 탐지 시 데몬은 90초 기다렸다가 게시 직전에 윈도우를 다시 읽으므로, 게시되는 숫자는 첫 트리거가 아니라 안정된 피크. 이후 해당 자산은 30분 동안 침묵. 하한은 2026-08-18에 $1 M에서 $50 M으로 상향: 적응형 p99가 현재 국면을 따라가는 것이 원래 의도이지만, 한산한 한 주가 BTC 실효 기준을 약 $2 M까지 끌어내려 평범한 흐름이 캐스케이드로 게시되고 있었음.

발동 조건  최근 300 s 의 Σ usd ≥ max(p99(5분 버킷, 7일), $50M)
     AND  서로 다른 거래소 ≥ 2
     AND  최근 1800 s 내 해당 자산 알림 없음

Top-N 인라인 주석

윈도우의 가장 큰 점 중 최대 3개가 인라인 $amount · time · venue|N× 라벨을 받아 시선이 즉시 가장 큰 캐스케이드로 향함. $50 K 하한이 잡티에 라벨링하는 것을 방지. 라벨 앵커는 점이 차트 왼쪽 절반인지 오른쪽 절반인지에 따라 뒤집혀 텍스트가 오른쪽 축이나 왼쪽 가장자리를 넘지 않음.

청산 속도 서브 패널

누적 패널 아래에 미러된 바 차트가 시간 버킷당 Σ usd를 사이드별로 분할 표시: 숏은 베이스라인 위로(초록), 롱은 아래로(빨강). 버킷 크기는 산점도의 적응 임계값을 따름(≤ 15m에서 30s, 1–4h에서 1min, 24h에서 5min)으로 막대가 위의 점과 시각적으로 정렬됨.

피드 상태

자산-거래소별 상태 해시 prod:liq:status:<asset>:<exchange>가 5초마다 새로고침, TTL 60초. 백엔드가 이를 세 상태로 변환:

• ok — 데몬 생존(상태 해시가 30초 이내에 새로고침) AND 최근 2분 이내에 이벤트 도착.
• stale — 데몬 생존, 그러나 그 거래소가 ≥ 2분 동안 침묵. 실제로 한산한 거래소이거나 vocal 피드일 수 있음. FE는 앰버로 렌더링.
• missing — 데몬 사망(상태 해시 만료 또는 결코 쓰여진 적 없음). 빨강 렌더링.

상태 툴팁의 지연 p50 / p99 숫자는 mt-liqd 바이너리의 producer_ts_ms − ts_ms 200 이벤트 롤링 링 버퍼에서 샘플링됨.

빈 시간 대역

윈도우의 청산이 전혀 없는 연속 구간에 미묘한 배경색 부여. 그렇지 않으면 24시간 뷰가 6시간 로컬 데이터만 가질 때 “그 기간에 캐스케이드 없음”이 아닌 깨진 렌더러처럼 읽힘. 임계값 gap ≥ 윈도우의 5 % — 24시간 뷰의 조용한 30분을 표시하기에 충분히 짧고, 조용한 초들 사이에 차트를 마이크로 대역으로 줄무늬로 그리지 않기에 충분히 큼.

캐싱

• WebSocket. 실시간, 캐시 없음. 꼬리는 Redis Streams의 XREAD BLOCK이 구동 — WS 작업이 폴링 없이 새 항목 도착까지 차단 대기.
• /api/liquidations/recent. 5초 공용 캐시 — 새로고침 폭풍을 흡수하면서 테이프가 stale되지 않게 충분.
• /api/liquidations/health. 3초 공용 캐시. 실시간으로 보이게 충분히 짧고, 새로고침 폭풍이 요청당 18개 HGETALL fan-out을 하지 않게 충분히 김.

한계

• 거래소 자가 보고. 각 거래소가 무엇이 청산 출력인지 결정. 드문 스푸프된 출력(cancel-replace 깜빡임, 두 번 계산된 부분 체결)이 끼어들 수 있음. 크로스 익스체인지 중복 제거는 시도하지 않음 — 세 거래소에 걸친 단일 트레이더의 캐스케이드는 설계상 세 이벤트.
• 스트림 깊이. MAXLEN ≈ 10 000 항목/자산 스트림. 바쁜 날 단일 자산이 ~4시간에 스트림을 채울 수 있음. 한산한 날엔 같은 버퍼가 24시간 전체를 덮음. 24시간 위젯 윈도우는 하드 상한 — 더 긴 리플레이 표면 없음.
• Mark 가격은 최신 청산 가격, 연속 mid가 아님.수평 mark 선과 가격 추적은 청산 출력에서 파생. 데이터가 희소할 때 추적은 톱니 모양. 연속 mid 피드로는 매끄러워짐. 추적을 정확한 mid 히스토리로 읽지 마세요 — “출력이 어디서 발생했나?”로 읽으세요.
• 크로스 익스체인지 시간 skew는 실재. Binance는 1초 단위로 스탬프, Bybit과 OKX는 더 세밀. 시계가 표류. ts_ms는 거래소 간 정렬에 사용. producer_ts_ms는 정렬 키가 아니라 지연 측정으로만 유용.
• OKX 무료 티어 커버리지. liquidation-orders 채널은 공개(무인증) WS에서 사용 가능하지만 최저 VIP 티어에서 OKX의 청산 firehose는 동기화된 캐스케이드 동안 지연될 수 있음. 그 윈도우에서 상태 pill이 stale로 뒤집힘.

버전

방법론 버전 v1.1.0 · 업데이트 2026-09-02. v1.1.0 2026-09-02: USD 명목가를 각 거래소의 기준 가격으로 계산한 추정치로 표기(2026-08-04), 캐스케이드 알림 임계값 문서화 및 그 하한을 $50 M으로 상향(2026-08-18). 중요 변경(새 거래소, 공식 조정, 임계값 변경)은 버전을 올리고 위의 구조화 데이터의 dateModified를 갱신.