前回の記事では、
「清算カスケードがいつ起きるかを予測する」のではなく、「ショックが入ったときに市場がどの程度壊れやすい状態なのかを観測できないか」
というテーマで、「清算脆弱性」の研究を始めたことを書きました。
-
-
🛠️開発記録#549(2026/8/7)清算カスケードの前兆は観測できるのか｜「清算脆弱性探知機」を作り始めた話
続きを見る
(ここでいう「伝播」は、清算そのものが市場間を移動するという意味ではなく、価格変化や強制フロー、流動性悪化が別venueへ波及し、そこで新たなポジション解消や清算につながる過程を指しています)
その後も観測を続けていたのですが、研究を進めるうちに一つ大きな問題が出てきました。
それは、
「そもそも一つの取引所だけを見ていて、清算の構造を十分に捉えられるのか」
という点です。
価格が動く。
板が薄くなる。
ポジションが解消される。
清算が発生する。
さらに別の市場へ価格変化が伝わる。
こうした流れを考えると、一つの取引所内部だけを見るより、
CEX、オンチェーンperp、DeFiを横断して観測した方が、市場で起きていることを捉えやすいのではないか
と考えるようになりました。
そこでこの2週間ほど、既存の観測機を組み直しながら、
CEXとHyperliquidを同時観測しつつ、既存のDeFi観測データも同じ研究基盤で扱える仕組み
を作っていました。
今回はその開発記録です。
なお、現時点で、
- 清算の伝播を発見した
- 清算を予測できるようになった
- 利益につながるシグナルが見つかった
という話ではありません。
ようやく、
「複数の市場を、比較可能な形で測れるところまで来た」
という段階です。
CEXとDEXを横断する研究自体は新しいものではない
最初に書いておくと、
CEXとDEXの価格形成を比較したり、HyperliquidとBinanceのlead-lagを調べたりする研究や分析自体は、すでに存在します。
例えばArrakis Financeは、Hyperliquid・Binance Futures・Lighterを対象として、複数のperp市場でvenue間のprice discoveryとlead-lagを分析しています。
また、Hyperliquidの清算イベントとraw order-book deltaを組み合わせ、強制売却前の板の撤退から清算カスケード、その後の流動性回復までを時系列で再構築した分析もあります。
参考１：Cross-venue lead-lag across 29 crypto perp markets, and a deeper look into PerpDEX architectures.
そのため今回の研究について、
「CEXとHyperliquidを一緒に見れば新しいことが分かる」
という部分そのものに、新規性があるとは考えていません。
今回私がやっているのはむしろ、
すでに存在する問題意識を、自分がこれまで作ってきた市場観測機へどう落とし込むか
という実装寄りの研究です。
実際に自分でやってみると、
「データを取れば分析できる」
ほど単純ではありませんでした。
既存のCEX botとDeFi botは、あえて一つに統合しなかった
これまでは、
- CEXを観測する仕組み
- DEX・DeFiを観測する仕組み
を、ほぼ別々のプロジェクトとして動かしていました。
最初は、
「今後DEXを主戦場にするなら、DeFi側のbotへCEX観測もまとめればよいのでは」
とも考えました。
ただ、監査してみると、それぞれかなり違う方向へ最適化されています。
CEX側には、
- 価格
- 板
- 約定
- Open Interest
- Funding
- Basis
などを継続的に取得・保存する仕組みがあります。
一方、DeFi側には、
- lending
- collateral
- liquidation candidate
- forced flow
- protocol固有の状態
などを見るためのロジックがあります。
これを一つの巨大botへ押し込むと、かえって扱いにくくなります。
そこで今回は、
既存CEX観測機 ─────┐
│
Hyperliquid ───────┼→ cross-venue研究基盤
│
既存DeFi観測機 ─────┘
という構造にしました。
各観測機は、それぞれの得意分野に特化した「センサー」として残します。
その上で、
観測されたデータだけを共通形式へ変換して、新しい研究基盤へ集める
という形です。
既存コードを全部統合したのではなく、
異なる観測機が同じ研究に参加できる共通規格を作った
という方が近いです。
Hyperliquidを新しい観測地点に加えた
今回、新しく直接観測を始めたのがHyperliquidです。
理由はいくつかありますが、研究上特に重要なのは、
perp市場としてCEXに近い構造を持ちながら、オンチェーン側の情報も観測しやすい
ことです。
現在はBTC・ETH・SOLについて、
- trades
- L2 order book
- mark price
- oracle price
- Open Interest
- Funding
- market context
などを取得しています。
新しい研究基盤では、
Hyperliquid ↓ WebSocket ↓ raw data保存 ↓ normalization ↓ 共通Event形式 ↓ replay / research
という経路を作りました。
特に今回は、分析前のraw dataを残すことを重視しています。
研究途中で、
「別の指標も見ればよかった」
となっても、元データが残っていれば後から再計算できるためです。
市場横断研究では「時計」が想像以上に重要だった
今回、一番時間を使ったのはここかもしれません。
CEXとHyperliquidを比較しようとすると、
「どちらが先に動いたのか」
を見ることになります。
するとtimestampが重要になります。
そこで、
- source timestamp
- receive timestamp
- event timestamp
- processing timestamp
- replay上のordering timestamp
をできるだけ分離して保存するようにしました。
途中、一つかなり気になる現象も見つかりました。
少数のテストデータでは、
source timestampとreceive timestampに約2秒の差
が出ていました。
最初は、
「CEX側の時計かデータ取得経路に、約2秒の系統的なズレがあるのでは」
と疑いました。
もしこれが本当なら、venue間の数秒単位の先行・遅行を調べる研究では致命的です。
例えば本当はHyperliquidが先に動いているのに、timestampのズレによってCEXが先に動いたように見える可能性があります。
そこで、少数サンプルで判断するのをやめて、既存CEXデータをかなり広く再確認しました。
結果、
- unique timestamp pair：約17万件
- 全体中央値：ほぼ0秒
- Binance：約-0.02秒
- Bybit：約+0.013秒
- OKX：約+0.013秒
となり、
固定的な約2秒のズレは実データでは確認されませんでした。
問題の約2秒差は、テスト用fixtureに入っていた特定サンプル由来でした。
つまり、
少数のテストデータを市場全体の性質として過大評価していた
ことになります。
この件はかなり良い教訓になりました。
異常値を見つけることと、
「市場にその異常が存在する」
ことは別です。
特に市場データでは、
少数サンプルで見つけた挙動を、必ず実データ側へ戻って検証する
必要があります。
Hyperliquid側のtimestamp品質も検証した
Hyperliquid側についてもtimestampを確認しました。
L2 order bookでは、source timestampからローカルで受信するまでの遅延が、今回の観測では中央値約0.13〜0.28秒でした。
具体的には、L2 order bookでは、私の環境で、
- latency中央値：約0.13〜0.28秒
- p99：おおむね0.3〜0.5秒前後
- negative latency：0
という結果になっています。
tradesも通常時は、
- 中央値：約0.1秒
- p95：約0.2秒
- p99：約0.2〜0.3秒
程度でした。
なお、これはデータ自体の更新間隔ではなく、source timestampから受信までの遅延です。
一方、接続直後だけ15秒以上前のtradeがまとまって送られてくるケースがありました。
最初は、
「Hyperliquidのtrade streamが数十秒遅れることがあるのか」
とも考えたのですが、raw messageまで戻って調べると、
接続直後のbatchに古いtradeが含まれている
ことが主な原因でした。
そのため現在は、
- 接続開始後10秒以内
- source時刻から一定以上古いtrade
については、精密な時間比較から除外するようにしています。
データそのものを削除するのではなく、
「精密な時間研究には使わない」という品質ラベルを付ける
形です。
一番速いデータに全体を合わせるのはやめた
Hyperliquidだけを見れば、100〜300ms程度まで観測できます。
では、
「CEXとの比較もsub-secondでやればいい」
かというと、そうはなりません。
現在利用しているCEX側の観測ラインは、
約10秒ごとに最新状態をsnapshotとして保存する
設計だからです。
Hyperliquidが300ms単位で見えていても、CEX側が10秒snapshotなら、
「HyperliquidがCEXより500ms先に動いた」
とは言えません。
そこで今回は、
比較するsourceの中で最も粗い時間解像度に合わせて、主張可能な時間軸を制限する
ことにしました。
現時点では、
Hyperliquid内部 trades ↔ l2Book → sub-second候補 CEX ↔ Hyperliquid → 10秒以上 DeFi historical → 状態・context確認用
という扱いです。
データが細かいから細かく分析するのではなく、
そのデータから本当に言える範囲だけを見る
というルールにしています。
本当に10秒で比較できるのかを実測した
とはいえ、
「CEXが10秒snapshotだから10秒で研究しよう」
と決めるだけでは雑です。
そこで実際にCEXとHyperliquidを同時に観測して、
- 10秒
- 20秒
- 30秒
- 60秒
のwindowを作り、どこまで安定してcoverageできるかを確認しました。
最初に15分間。
その後さらに15分×2回。
合計45分の同時観測を行いました。
CEX側のsnapshot intervalは、
中央値で約10.003〜10.004秒
とかなり安定していました。
そして3回すべてで、
10秒 window coverage 100% 20秒 window coverage 100% 30秒 window coverage 100% 60秒 window coverage 100%
となりました。
10秒windowの中にCEX snapshotが一件も入らないケースも、今回の3回ではありませんでした。
そのためPhase 1の横断研究については、
10秒を基本の時間解像度として使う
ところまで決めています。
もちろん、これは私の現在の観測システムについての結果です。
「暗号資産市場では10秒が最適」
という意味ではありません。
あくまで、
現在使っているCEX観測ラインとHyperliquidを比較するときに、研究上安全に使える下限を実測した
という話です。
「市場イベント候補」も機械的に拾えるようになった
観測基盤ができたので、次は研究対象となる時刻を選ぶ仕組みも作りました。
ただし、まだ「清算イベント」を検出しているわけではありません。
現在は単純に、
一定時間内に価格が大きく変化した区間
をCandidate Market Eventとして抽出しています。
CEXとHyperliquidは独立して判定します。
CEXで大きく動いた → CEX Candidate Hyperliquidで大きく動いた → Hyperliquid Candidate
です。
両方が近い時間に出ても、
「同じイベント」
とはまだ判断しません。
実際、45分の観測では、
1回目は大きなcandidateなし。
2回目と3回目では、CEX・Hyperliquidの両方から複数のcandidateが取得できました。
これで、
市場を観測 ↓ 変動区間を機械的に抽出 ↓ 研究対象時刻を固定
まで自動化できたことになります。
ただし、
Candidate ≠ 清算 ≠ 伝播 ≠ 脆弱性
です。
ここはかなり意識して分けています。
次はcandidate前後で「何が変化していたか」を見る
次の研究では、candidateをanchorとして、
T-60秒 T-30秒 T-10秒 T0 T+10秒 T+30秒 T+60秒
のように前後を切り出します。
その中で、
CEXなら、
- price
- Open Interest
- Funding
Hyperliquidなら、
- price
- Open Interest
- Funding
- spread
- bid / ask depth
- trade flow
などを並べます。
最初にやるのは、
何が起きていたのかを時系列で記述すること
です。
例えば、
「価格が動く前に板が薄くなっていた」
「価格変化と同時にOIが減少した」
「その後にtrade flowが偏った」
といった事実を並べます。
そこまで確認してから、
初めて、
これは市場間の伝播と呼べるのか
を考える予定です。
24時間の観測も開始した
短時間の同時観測試験が通ったため、現在は次の段階として、
24H bounded observation run
も開始しています。
これはまだ常時稼働への移行ではありません。
24時間限定で、
- 時間帯が変わってもCEXの10秒coverageが維持されるか
- Hyperliquid WebSocketが長時間安定するか
- reconnectやdata gapがどの程度発生するか
- tradeのprecision eligibilityが時間帯で変化するか
- candidateが一日にどの程度出るか
- raw / normalized dataがどの程度増えるか
を確認するための耐久観測です。
24時間経過後は自動停止させます。
その間は、すでに取得したcandidateを使ってevent study側の研究を進める予定です。
今回分かったこと
今回の開発を通して一番大きかったのは、
複数市場を見る場合、単にデータを集めるだけでは足りない
ということでした。
CEX、Hyperliquid、DeFiでは、
- timestampの意味
- データ更新頻度
- 観測可能な情報
- market structure
- データの信頼できる時間解像度
が違います。
それらを一つの表へ並べただけでは、比較したことにはなりません。
むしろ最初に、
このデータは何を表しているのか
何秒単位まで信用してよいのか
どこから先は推定なのか
を決める必要がありました。
その結果、現在は、
「一番細かいデータに研究を合わせる」のではなく、「比較対象の中で主張できる最も安全な時間解像度に合わせる」
という方針にしています。
ようやく「観測装置を作る」段階から抜けつつある
前回の記事を書いた時点では、
「清算脆弱性をどう観測するか」
という仮説を立てて、観測装置を作り始めたところでした。
今回は、
CEX ↕ Hyperliquid ↕ DeFi
を横断して扱う研究基盤を作り、
- raw dataを保存できる
- historical replayできる
- live dataとhistorical dataを同じ形式で扱える
- timestampの意味を監査できる
- 同じ時間帯を実際に観測できる
- 10秒を横断研究の基本解像度として使える
- 市場イベント候補を機械的に拾える
ところまで進みました。
ようやく、
「研究するための装置を作る」段階から、「その装置で市場を調べる」段階へ移りつつあります。
まだ清算の伝播を見つけたわけではありません。
むしろ、ここからが研究本体です。
次は実際の市場イベントを一つずつ切り出し、
価格、OI、Funding、注文フロー、板の流動性が、どの順序で変化していたのか
を確認します。
そこから、
「清算はどこから伝播するのか」
という今回の記事タイトルの問いに、少しずつ答えていきたいと思います。
それでは、また。