Bot CEX DEX 開発ログ

🛠️開発記録#552(2026/8/25)|CEX–DEX清算キャッチ研究:価格乖離の収束をOOSデータで検証した話

こんにちは、よだかです。

ここ最近進めているのが、CEXとDEXを横断した清算・デレバレッジ周辺の市場構造研究です。

もともとの発想はかなり単純でした。

レバレッジの高い市場で強制決済が起きたとき、一時的な需給の偏りや価格乖離が発生する。その歪みが別の取引所へ伝播する過程に、アルゴで拾える余地はないか。

いわゆる「清算キャッチ」に近い研究です。

関連記事
🛠️開発記録#550(2026/8/21)清算はどこから伝播するのか|CEX・Hyperliquid・DeFiの横断観測を始めた話

続きを見る

ただ、いきなり「清算を検出して売買する」ところから始めるのはかなり雑です。

まず必要だと考えたのは、

  • どこで価格が動いたのか
  • どこで板が薄くなったのか
  • 建玉がどう変化したのか
  • 注文フローがどこに集中したのか
  • 取引所間の価格差がどのように広がり、縮んだのか

を同じ時間軸で観測できる仕組みでした。

今回、その観測基盤から一歩進み、Developmentデータで見つけた現象を、未観測の24時間データでもう一度検証するところまで進めました。

CEXとHyperliquidを同じ時間軸で観測する

現在の研究では、主要な海外CEXのperpetual市場とHyperliquidを並べて見ています。

CEX側では主に、

  • 価格
  • スプレッド
  • funding
  • Open Interest
  • mark price
  • index price

などを取得。

Hyperliquid側では、

  • trades
  • L2 order book
  • aggressor side
  • spread
  • depth
  • market state

など、より細かな市場内部の情報を取得しています。

これらをそのまま比較するのではなく、まず24時間連続で観測し、20秒ごとの市場状態へ集約しました。

24時間なので、

86,400秒 ÷ 20秒 = 4,320 windows

です。

つまり、1日の市場を4,320個の「状態」に分解しています。

各20秒について、

  • CEX各venueの価格やOI
  • Hyperliquidの取引量
  • 板の厚さ
  • spread
  • CEXとHyperliquidの価格乖離
  • timestamp差
  • reconnectやlatencyなどのデータ品質

をまとめています。

この仕組みができたことで、

「価格が大きく動いた20秒」

「OIが急変した20秒」

「板が急に薄くなった20秒」

「取引所間の価格差が大きくなった20秒」

を機械的に抽出できるようになりました。

最初に強く残ったのは「清算」ではなく価格乖離

当初はOIや板の薄化、注文フローなどから、清算・強制デレバレッジに近い現象が前面に出てくると考えていました。

ところが初期分析で最も強く残ったのは、

Hyperliquidと主要CEXの価格乖離が大きくなった後、その乖離が縮小する

という現象でした。

研究上は一旦、

XVENUE_DIVERGENCE_REVERSION

という仮説名を付けました。

ただし、ここで「価格差が戻るならアービトラージできそう」と判断するのは早すぎます。

例えば、

  • CEX側の価格データが単に古いだけではないか
  • HyperliquidとCEXの観測時刻がずれているだけではないか
  • reconnect直後の異常値ではないか
  • 極端な価格差なら、そもそも自然に戻りやすいだけではないか

といった代替説明があります。

そこで、timestampのずれやデータ品質、価格乖離の大きさを揃えたbaselineなどを使って追加検証しました。

その結果、少なくともDevelopment期間では、単純な観測時刻のずれだけでは説明しにくい収束傾向が残りました。

さらに興味深かったのは、必ずしもHyperliquid側の価格がCEXへ戻っているわけではなかったことです。

むしろ一部では、

Hyperliquidが先に動き、その後CEX側が追いつく

ように見えるイベントも多く確認されました。

そのため、現在は単純な「平均回帰」よりも、

取引所間で一時的に価格発見の主導権が移動し、その後価格が同期している可能性

を疑っています。

Developmentデータだけでは信用しない

ここで問題になるのが、研究に使ったデータへ仮説を合わせすぎることです。

一つの24時間データを何度も眺めながら、

  • 閾値
  • 観測時間
  • 除外条件
  • 評価方法

を調整すれば、その24時間だけに非常によく合うルールはいくらでも作れます。(オーバーフィッティングは予防したい)

そこで今回は、最初の24時間をDevelopment datasetとして使い、その中で仮説を作った後、評価条件を固定しました。

固定したのは例えば、

  • 20秒の観測窓
  • 価格乖離の判定条件
  • イベントのまとめ方
  • 300秒後を主要評価地点とすること
  • データ品質の除外条件
  • 比較対象となるbaseline
  • 最低サンプル数
  • PASS / FAIL / 判定不能の基準

などです。

この仕様を xvenue_divergence_oos_v1 として保存し、内容のハッシュ値も記録しました。

そして、その後に新しく24時間分の市場データを取得しました。

この新しいデータは、仮説作りには一度も使っていません。

いわゆる Out-of-Sample(OOS) のデータです。

未観測の24時間でも収束傾向は残った

OOSでは、仮説や閾値を一切変更せず、Development期間で固定した評価方法をそのまま適用しました。

結果は、

  • 独立したclustered market event:297件
  • strict-clean event:72件
  • 300秒後に乖離が縮小した割合:約77.8%
  • 同程度の価格乖離を持つbaseline:約46.1%
  • candidate側の価格乖離縮小幅中央値:約+1.45bps
  • baseline側:約-0.16bps

となりました。

評価結果は、

PASS_TO_MORE_OOS

です。

意味としては、

別期間でも仮説と同じ方向の現象が確認されたので、さらに未観測データで検証する価値がある

というものです。

大事なのは、

edge_confirmed = False

のままであることです。

77.8%という数字は「トレード勝率」ではありません。

あくまで、

事前に定義した極端な価格乖離イベントのうち、300秒後に絶対価格乖離が縮小していた割合

です。

どちらの取引所で売買すればよいのか、手数料やslippageを差し引いて利益になるのか、といったことは未検証です。

「市場現象」と「トレードエッジ」は分けて考える

現時点で強く意識しているのが、この区別です。

市場に再現可能な現象が存在することと、その現象から利益を得られることは別です。

現在確認できているのは、

CEXとHyperliquidの間で大きな価格乖離が発生した後、通常時より価格が同期しやすい現象がある可能性

まで。

ここから実際のトレードエッジにするには、

  • どちらのvenueが先に動くのか
  • どの程度の時間差があるのか
  • entry可能な価格が残っているのか
  • maker / taker fee
  • spread
  • slippage
  • latency
  • 約定可能サイズ
  • exit条件

まで調べる必要があります。

例えば研究上8〜10bps程度の価格差が存在していても、往復の取引コストがそれ以上なら、実際のedgeにはなりません。

なので今は「戦略が完成した」のではなく、

再現性を持って検証できる市場現象を一つ見つけた

という段階です。

観測系は研究と切り離して継続稼働へ

今回もう一つ進めたのが、データ収集と研究ロジックの分離です。

ここ数日は、

24時間データを取る
→ 分析する
→ 次のデータを取る

という流れでした。

今後は、

市場データは24時間単位で継続的に蓄積し、その横で確定済みデータを使って研究を進める

という運用へ移します。

観測自体はほぼ常時行いますが、1本の無限プロセスにはせず、24時間ごとの独立runとして保存します。

こうすることで、

  • 各runのデータ品質
  • reconnect
  • timestamp
  • duplicate
  • hypothesis version
  • Development / OOSの区別

を明確に管理できます。

現在は2本目のOOS runも並行して取得しています。

同じ xvenue_divergence_oos_v1 を変更せず、今後も同じEvaluatorで評価します。

清算キャッチ研究としては、ここからが本題

もともとの目的は、CEX–DEX間での清算や強制デレバレッジに伴う価格歪みを拾うことでした。

今回見つかった価格同期化現象は、その途中に存在する可能性があります。

現時点では、次のような流れを疑っています。

レバレッジの蓄積
→ 何らかのshock
→ ポジション解消・forced flow
→ 板への負荷
→ liquidity withdrawal
→ price displacement
→ cross-venue divergence
→ 他venueへのprice discovery / synchronization

ただし、これはまだ仮説です。

今後は、

  • OIの変化
  • trade intensity
  • forced flowのサイズ
  • L2 liquidity
  • book withdrawal
  • spread expansion

などをイベント前後で並べ、

なぜ価格乖離が発生し、なぜその後収束するのか

を分解していきます。

特に気になっているのが、

flow size / available liquidity

です。

単純に大きな注文が重要なのではなく、

その瞬間の板が、流れてきた注文をどの程度吸収できるか

によって、

  • 一つのvenue内で吸収される
  • 他venueへ価格変化が伝播する

というモードが変わるのではないかと考えています。

現時点での結論

今回の研究で確認できたのは、

CEX–Hyperliquid間の大きな価格乖離後には、通常時よりも価格が再同期しやすい現象が存在する可能性があり、その傾向は仮説作成に使っていない別24時間でも再現した

というところまでです。

一方、

  • これが清算によって発生しているのか
  • どちらのvenueが価格発見を主導しているのか
  • 実際にトレードできるedgeなのか

はまだ分かっていません。

なので、この段階ではbotを作りません。

まず市場構造を理解する。

その後に予測可能性を調べる。

さらにその後で、手数料・slippage・latencyを含めて実際に取れるかを検証する。

今回の研究は、ようやくそのラインに乗ってきました。

次は、price discoveryとforced flow、そしてL2 liquidityの関係をもう少し深く掘っていきます。

それでは、また。

-Bot, CEX, DEX, 開発ログ