清算カスケードを取引シグナルとして読む:強制され、事前に告知されたフロー
市場のフローの大半は、約定するまで秘密のままだ。裁量の売り手は、自分が売ると決めた時に売る。その意図を知るのは、事後にテープを見てからだ。レバレッジ清算は例外であり、その規模は極めて大きい。清算は強制される——ポジション保有者には、それが起きるかどうかについて何の決定権もない——そして事前に告知される——発動する正確な価格は、オンチェーンでは完全に公開され、オフチェーンでは統計的に推定可能なパラメータの決定論的な関数である。レバレッジのかかったロングはすべて、計算しようと思う人には伝わる価格に置かれた、常設の成行売り注文なのだ。
この見方に立つと、全体の構図が変わる。AaveとCompoundの清算メカニズムに関する関連記事は、清算を清算人の側から扱っている——不良債権を返済してボーナスを受け取る役を勝ち取るためのインフラ競争だ。この記事では、同じ対象をトレーダーの側から見る。問いは「どうすれば清算に勝てるか」ではなく、「他の全員の清算価格を集計すれば、将来の強制フローの地図になる。その地図に対して取引できる」というものだ。ここではその地図を2種類作る——オンチェーンの正確なものと、CEXのパーペチュアル向けの曖昧なものだ。そして清算の連鎖がいつ自己強化的になるのかを定量化し、そこから生じるフローが価格に与える影響を慎重に述べる。
オンチェーンの清算デプスチャート
マネーマーケットでは、ポジションの清算価格は推定するものではない。導出するものだ。メカニズム入門記事で扱ったヘルスファクターを思い出そう。ポジションは次の条件で清算可能になる。
ここで、 は担保量、 はそのオラクル価格、 は清算閾値、 は負債の価値である。ここでは再導出せず、逆に解く。よくあるケースとして、単一のボラティリティの高い担保 (例えばWETH)でステーブル負債 (USDC)を調達するとしよう。 と置き、担保価格について解けば、ポジションのトリガー価格が得られる。
この1つの数値が、借り手が告知したものだ。「オラクル上でWETHが に触れれば、このポジションは強制的な供給になる」と告げている。そして、その供給量も把握できる。トリガー時には、清算人が の負債を返済し、 相当の担保を差し押さえる。したがって、ポジションが発動するとおおよそ
の担保価値が市場に出る(またはヘッジされる)。
メカニズム入門記事に出てきた具体的なポジションを考えよう。3,000ドルで10 WETHを預け、20,000 USDCを借り、清算閾値は 、ボーナスは5%だ。トリガーは であり、クローズファクターが50%なら、その価格に 相当のWETH強制供給が置かれる。借り手1人につき、チャート上のバーが1本だ。プロトコル内のすべての借り手についてこれを行い、結果を ごとに区分すれば、ヒストグラムが得られる。価格の関数として表した強制売りの想定元本だ。これがオンチェーンの清算デプスチャートである——DEXネイティブなオーダーブックのいとこだが、「注文」は非自発的で、その価格は提示されるのではなく計算される。

これを空想にしないためには、3つの正直な注意点がある。
- 複数資産ポジションには単一のトリガー価格がない。 ボラティリティの高い担保が2つ、負債が2つあるポジションは、1点ではなく価格空間上の曲面で清算される。実務上は、他のすべてのオラクル価格を現在値に固定し、主要な変動担保の軸に沿ってトリガーを計算する。これは1つの資産だけが動く場合には正しいが、相関したバスケットが動く場合には正しくない——そしてこれは重要だ。相関した暴落こそ、多数のトリガーが一緒に動く場面だからである。単一資産の は一次近似の限界値として扱い、保証とは考えないこと。
- 強制売り 1つの取引所での市場ダンプ。 有能な清算人は、差し押さえた担保を最も薄い流動性プールへ盲目的に成行売りしない。DEXとCEXをまたいでルーティングし、担保をすぐに現金化する代わりに保有したままパーペチュアルでデルタヘッジすることも多い(メカニズム入門記事が詳しく扱うエグジットスワップ問題だ)。したがって は価格に影響するフローの上限であり、点推定ではない。その一部は現物市場に一度も触れないヘッジへ流れる。
- トリガーは市場ではなくオラクルとともに動く。 AaveとCompoundでは、オラクルが を超えた時にポジションが清算可能になり、オラクルは偏差とハートビートに基づく頻度で更新されるため、市場に遅れる。したがってデプスチャートは、次のオラクル送信を条件として、強制フローが適格になる場所の地図である——入門記事が詳しく説明している微妙な点だ。
マネーマーケットのチャートとCEXヒートマップの間には、3つ目の情報源がある。パーペチュアルDEXだ。Hyperliquid、GMX、dYdX v4は中央集権型取引所のようにレバレッジ付きパーペチュアルを運用しながら、ポジション状態をオンチェーン、または照会可能なクリアリングハウスに保持している。つまり清算価格はCEXパーペチュアルと同じ分離マージンの式に従うが、集計OIから推定するのではなく、実際のポジション(サイズ、担保、エントリー)から計算される。Hyperliquidのクリアリングハウス状態は各アカウントのマージンとマーク価格を公開し、GMXのポジションはオンチェーンにあり、キーパーがオラクル由来の価格で清算する。実務上の帰結はこうだ。パーペチュアルDEXでは、CEX型のレバレッジとオンチェーン型の精度を持つ清算マップを作れる。これはヒートマップの推測よりも、Aaveチャートの正確さにずっと近い。ポジションを公開している取引所なら、推測する必要はない。
注意点を踏まえても、オンチェーンチャートは市場のどこにでも存在する中で最も透明な強制フローの地図である。レバレッジ分布を仮定する必要がなく、隠れたサイズもなく、すべての入力を状態から読み取れる。
CEX清算ヒートマップ
中央集権型のパーペチュアル取引所は、正反対の状況をもたらす——はるかに大きなオープンインタレストがある一方で、オンチェーンチャートを正確にするポジション単位の詳細はほとんどない。個別ポジションを読み取ることはできない。読み取れるのは、集計されたオープンインタレストと取引量だ。清算ヒートマップは、こうした集計値に仮定を加えてデプスチャートを再構築しようとしたときに得られるものだ。そして、その仮定が全体を支えている。
ポジションごとの計算は単純だ。価格 、レバレッジ 、維持証拠金率 でエントリーした、分離マージンの線形(USDT決済)ロングでは、エクイティが維持証拠金要件まで低下したときに清算が発動する。
対称的に である。エントリーを に固定し、 としてレバレッジ階層を見ていこう。
| レバレッジ | エントリーから下の距離 | |
|---|---|---|
| 5× | $2,415 | −19.5% |
| 10× | $2,715 | −9.5% |
| 25× | $2,895 | −3.5% |
| 50× | $2,955 | −1.5% |
| 100× | $2,985 | −0.5% |
この列の形こそが、ヒートマップが直近価格のすぐ下で明るくなる理由のすべてだ。高レバレッジのポジションはエントリーのすぐ近くで清算されるため、最近取引された場所にはどこでも、50〜100倍のトリガーがエントリーから数分の1パーセントの距離に密集する。ヒートマップの構築者は次のように進める。最近の取引量をポジションが開かれた場所(その )の代理変数として扱い、その取引量を仮定したレバレッジ階層——5倍、10倍、25倍、50倍、100倍と、いくつかの仮定した重み——に分配し、各部分をその へ射影する。そして、その価格で清算される推定レバレッジ想定元本に応じて価格軸を色付けする。明るい帯は、推定清算ゾーンが密集している場所だ。

これが曖昧な図であり、オンチェーンチャートの双子ではない理由を明確にしておこう。
- レバレッジ分布は未知だ。 ヒートマップ全体は、取引量と仮定したレバレッジヒストグラムの畳み込みである。異なる仮定は明るい帯を別の場所へ移す。同じ市場について同じ日に、評判のよい2つのデータ提供者が目に見えて異なるヒートマップを公開することがある。そして、両方とも各自の事前分布に照らせば「正しい」。
- クロスマージンはポジションごとの式を壊す。 上の は分離マージンの結果だ。クロスマージンのポジションはアカウント全体のエクイティによって清算されるため、実効トリガーはトレーダーの他のポジション、未実現PnL、値動きの途中で追加する担保に左右される。これらはどれも観測できない。クロスマージンのサイズは推定器から見れば実質的に不可視だ。
- 隠れたサイズと動的なサイズ。 オープンインタレストはネットとグロスを合わせた集計値であり、OIと個々のエントリーの対応はわからない。トレーダーは継続的に追加し、減らし、ヘッジする。段階的な維持証拠金( はポジション想定元本とともに上昇する)は、同じレバレッジでも、大きなポジションのトリガーを小さなポジションに対してずらす。
- 清算は分割され、一瞬ではない。 取引所は大きなポジションを段階的に清算し、残余リスクを保険基金と自動デレバレッジへ回す。そのため、位置を正しく特定したクラスターであっても、1つの約定として一気に投げ売りされるわけではない。
ヒートマップは、台帳ではなく、強制フローが集中していそうな場所についての事前分布として扱うのが正しい。次のパイプライン節に出てくる実際の清算約定(forceOrderストリーム)で、確認または反証するものだ。これは本当に有用で、本当に不正確である。その逆だと装うことが、見ているはずのクラスターに自分が轢かれる原因になる。そもそもなぜパーペチュアルにこれほど多くのレバレッジが積み上がるのか、そしてなぜファンディングコストがポジションをトリガーへ押し続けるのかについては、取引所間のファンディングレート裁定を参照してほしい。
カスケードの動態を定量化する
単一の清算はデータポイントだ。カスケードはフィードバックループであり、書き下せる閾値がある。ループは機械的だ。強制売りが板に当たる → 価格インパクトが市場を動かす → その値動きで次のポジション群がトリガーを超える → それらが清算される → 強制売りが増える → 繰り返す。これが消えるのか暴走するのかはセンチメントの問題ではない。すでに構築した2つの量の比率で決まる。
価格の下落を分数で として扱う。要素は2つある。
- 清算密度 — 分数価格下落の単位あたりの強制売り想定元本。デプスチャート/ヒートマップからそのまま読み取れる:。価格帯にどれだけ燃料が積まれているかを測る。
- 市場デプス — 価格を の1単位分動かすために必要な市場売りの想定元本。線形(Kyle)インパクトモデルでは、想定元本 を売ると価格は だけ動く。これは板が強制フローを吸収する能力であり、まさにオーダーブックの壁とキュー位置分析が扱う量だ——「壁」とは の局所的な急増である。
ここで反復する。外生的ショックによって価格が 下落し、 の強制売りが発生したとする。その売りによって、さらに 下落する。カスケード倍率を
と定義すれば、漸化式は単純に となる。総下落幅は等比級数である。
すべては の値にかかっている。
- — 亜臨界。 清算の各ラウンドが発生させる売りは、直前のラウンドより少ない。カスケードは自己消滅し、総変動幅は初期ショックの 倍という有界な値に収まる。ほとんどの清算イベントはここにある。
- — 超臨界。 各ラウンドは前のラウンド以上の売りを発生させる。等比級数は発散し、値動きを制限するのは、清算可能なポジションの枯渇、より低い価格で板が厚くなること、または取引所のサーキットブレーカーだけになる。これが「フラッシュクラッシュ/ロングスクイーズ」の領域だ。
は再生産数であり、清算エピデミックの だ。価格帯に集中した強制売りの流動性が、その場で吸収できる板の流動性を上回った時に、カスケードが暴走することを示している。だから、薄い板の密集クラスターに入る小さなショックは、価格の空白地帯に入る大きなショックよりはるかに危険だ。危険なのはショックの大きさではなく、 だからである。同種のイベントがさらにイベントを引き起こすこの自己励起構造は、注文フローをHawkes過程でモデル化する動機と同じものであり、清算が均一ではなくクラスターで到来する理由でもある。

数字を入れてみよう。市場売り1,000万ドルでETHが1%動く板なら、、つまり分数価格変化1単位あたり10億ドルの想定元本だとする。ここで、現物価格直下の1%幅の帯について、2つの状況を比べる。
- 密集した帯、クラスター化した強制売り想定元本3,000万ドル。 このとき 、 となる。超臨界だ。帯の上端に触れるショックがスタック全体を爆発させ、モデルの下限は ではなく、ポジションが尽きる場所で決まる。
- 疎らな帯、クラスター化した想定元本600万ドル。 このとき 、 であり、総変動幅は となる。ショックも板も同じで、クラスターだけが5分の1の厚さになると、結果は崩壊から買えるヒゲへと反転する。
離散版は、ソート済みクラスターを走査する短いシミュレーションであり、閾値を実感するために書く価値がある。
def cascade(p0, clusters, kyle_lambda):
"""
p0: price after the exogenous shock
clusters: {trigger_price: forced_notional} for long positions
kyle_lambda: fractional price impact per $ of market sell (1/depth)
Returns the floor price and total liquidated notional.
"""
p, sold, fired = p0, 0.0, set()
while True:
new = [(tp, n) for tp, n in clusters.items()
if tp not in fired and tp >= p]
if not new:
break
q = sum(n for _, n in new) # this round's forced sell
fired.update(tp for tp, _ in new)
p *= (1 - kyle_lambda * q) # linear price impact of the round
sold += q
return p, sold
実務上の注意が2つある。第一に、 は局所的な値だ。価格軸に沿って変化する。(クラスター密度)も (板の厚さ)も変わるからである。取引可能な問いは「市場は脆弱か」ではなく、「どの具体的な価格で が1を超えるか」だ。第二に、同じ仕組みが上昇局面のショートにも逆向きに働く(ショートスクイーズは符号を反転させたカスケードだ)。そのためマップには両側がある。現物価格の下にはロング清算の燃料が、上にはショート清算の燃料がある。強制清算が価格インパクトを生み、その価格インパクトが強制清算を生むループは、投げ売りに関する文献(Cont & Wagalath)で定式化された内生的リスクのメカニズムであり、困窮した清算がそれ自身の相関とインパクトを生み出す。
シグナル:磁石としてのクラスターと反転ゾーン
強制フローのマップからは、カスケードに対するタイミングによって、ほとんど正反対の2つの取引可能な読み方が生まれる。
前:クラスターは価格の磁石。 密集した清算クラスターは、価格に左右されないことが保証されたフローのプールだ。これは2種類の参加者にとって魅力的である。強制されたカウンターパーティーに対して大きなサイズを約定させたい流動性追求型のトレーダーと、フローを発生させるために特定のクラスターへ価格を押し込む捕食的なトレーダー(プロトコル規模のストップハント)だ。その結果、価格が大きなクラスターへ引き寄せられるという、よく記録された傾向が生まれる。距離を縮める恒常的なインセンティブがあるため、その水準が磁石として働くのだ。確信の弱い状態で現物価格が明るい帯へ漂っていくのを見たなら、その帯自体が理由の一部である。価格が近づいた時に板がどう反応するか——壁がフローを吸収するのか、それとも崩れるのか——を予測することは、DeepLOBのようなモデルが取り組む短期のオーダーブック予測問題そのものだ。
後:クラスターは反転ゾーン。 これはより価値がある一方で、より濫用されている読み方なので、慎重に述べよう。強制清算フローは、構造上、非情報的だ。売り手は価格が高すぎるという見方で売っているのではなく、マージンエンジンにそう命じられたから売っている。非情報的なフローは、価格を一時的に動かす。クラスター化したポジションが尽きると機械的な売りは突然止まり、カスケードが下落の途中で公正価値を行き過ぎていたなら、価格は反落しやすい——これが「清算のヒゲ」だ。このメカニズムは俗説ではない。強制された情報を持たない売りによる価格インパクトには一時的な成分があり、フローが止まると反転するという標準的な結果である。株式の困窮売りに関する文献でも、一時的な価格乖離とその後の部分的な反転を生む、同じ投げ売りの論理が確認されている。

ここで求められる規律を、できるだけ平板に述べる。
- カスケード後の平均回帰は、記録された傾向であって法則でも数値でもない。 それは、フローが本当に非情報的であり、カスケードの間に新しい情報が到来しなかった場合に限られる。現実のニュース(デペッグ、エクスプロイト、マクロショック)による市場の再評価も同時に起きている清算カスケードは、反転しない。強制フローと情報フローが重なっており、一時的なのは前者だけだからだ。普遍的な「ヒゲを買う」優位性は存在しない。具体的なサンプル、取引所、レジームを示さずに引用された特定の反転率は、マーケティングとして扱うべきだ。
- シグナルは下落ではなく、枯渇だ。 取引可能な瞬間は、実際の清算約定が細る時——急増の後に
forceOrderテープが静かになる時——である。機械的な売り手がいなくなったからだ。超臨界カスケードの途中()で入るのは、前節が警告したフィードバックループそのものの前に立つ行為である。 - どちらの読み方にも同じマップが必要だ。 磁石と反転は、異なるフェーズで見た同じクラスターである。デプスチャートとヒートマップをまず構築し、実際の約定と継続的に突き合わせなければ、どちらも取引できない。
両側のマップの非対称性には、より遅い方向性の読み方もある。ロング清算の燃料は現物価格の下に、ショート清算の燃料は上にある。一方が他方よりはるかに重い場合、市場は重い側へ向かう機械的なバイアスを持つ。ショックが最も自己強化的なフローを見つけるのが、その側だからである。下3%にロング清算の壁があり、上にはほとんど何もない市場は、ストーリーに関係なく構造的に下方向へ脆弱だ。最も抵抗の少ない経路は、最も多くの燃料がある経路である。持続的な一方向のファンディングが、そもそもこの非対称性を作ることが多い。ロングがショートを維持するために支払う市場(深くマイナスのファンディング)は、混雑したショートを蓄積し、その清算クラスターがスクイーズの燃料として価格の上に置かれる。その逆も同じだ。ファンディングのテープと清算マップは、同じレバレッジを別の角度から見たものだ。
データパイプライン
このシステムは性格の正反対な2つのフィードを融合する。先行的なオンチェーン・ポジションインデックス(強制フローが適格になる場所)と、実現値のCEX清算ストリーム(強制フローが今まさに約定している場所)だ。一方は燃料の場所を教え、もう一方は着火したことを教える。
先行マップ——オンチェーン・ポジションインデックス。 Aave/Compoundのイベント履歴(Supply、Borrow、Repay、Withdraw、LiquidationCall)を、ログの再生またはThe Graph上のサブグラフへのクエリによって初期化し、現在のユーザーごとの残高へ畳み込む。これはメカニズム入門記事が清算ボット向けに説明している正確なインデックスサブシステムであり、ここでは実行ではなく集計に再利用する。残高と現在のリスクパラメータから、各ポジションの と を計算し、デプスチャートのヒストグラムに区分する。新しいブロックごとに更新する。残高が稼働していれば、ヒストグラムは差分更新で安価に維持できる。
実現値のテープ——Binance forceOrderストリーム。 Binance FuturesはWebSocket経由で実際の清算を公開している。wss://fstream.binance.com/ws/!forceOrder@arr(全シンボル配列)または <symbol>@forceOrder で、各イベントには清算注文のサイド、価格、数量が含まれる。ここで、正確さについて正直でいるべき、まさにその種の曖昧さが1つある。公開ストリームはシンボルごとに1秒あたり最大1件の清算イベントへスロットルされる。清算が1秒に1件をはるかに超える激しいカスケードでは、ストリームはすべての約定を報告するのではなくサンプリングする。そのため、そこが最も重要な局面で、そこから再構築した清算量は体系的に過小計上される。このストリームは、カスケードのタイミングと方向(発火しているか、どちら側か、加速しているか細っているか)に使い、正確な出来高台帳には使わないこと。
最小限の取り込みスケルトン——2つの非同期プロデューサーが1つの正規化バスへ書き込む。
import asyncio, json, websockets
async def binance_liquidations(bus):
url = "wss://fstream.binance.com/ws/!forceOrder@arr"
async with websockets.connect(url) as ws:
async for msg in ws:
o = json.loads(msg)["o"] # order payload
await bus.put({
"src": "binance", "kind": "realized",
"symbol": o["s"],
"side": o["S"], # SELL = long liquidation
"price": float(o["p"]),
"qty": float(o["q"]), # NB: stream is sampled at 1/s
})
async def onchain_positions(bus, subgraph, poll=12):
while True:
positions = subgraph.fetch_open_positions() # balances + risk params
chart = {}
for pos in positions:
p_liq = pos.debt / (pos.collateral * pos.liq_threshold)
q = pos.close_factor * pos.debt * (1 + pos.liq_bonus)
chart[round(p_liq, 2)] = chart.get(round(p_liq, 2), 0.0) + q
await bus.put({"src": "aave", "kind": "forward", "chart": chart})
await asyncio.sleep(poll) # ~1 block cadence
async def main(subgraph):
bus = asyncio.Queue()
await asyncio.gather(
binance_liquidations(bus),
onchain_positions(bus, subgraph),
consumer(bus), # reconcile forward map vs realized tape, emit signals
)
consumer が戦略の中核になる。先行マップ(オンチェーンチャートと推定CEXヒートマップ)を保持し、ライブのオーダーブックのデプスに対して局所的なカスケード倍率 を推定し、実現値の forceOrder テープを監視して着火と——取引可能な部分である——枯渇を検出する。テープが急増してから細り、価格がマップの示したクラスターを下回っているなら、非情報的な行き過ぎが起き、強制売り手がいなくなったということだ。反転セットアップになる。テープが加速し、先行して なら、距離を取るべき超臨界カスケードだ。同じマップでも行動は逆になり、リアルタイムで両者を見分けるのはテープである。
要点
清算は、市場における通常の情報の非対称性を反転させる。フローが約定するまで隠れているのではなく、強制売りの価格とサイズを事前に計算できるのだ——オンチェーンでは正確に、CEXパーペチュアルでは近似的に。マップを構築しよう(オンチェーンのデプスチャートはルーティングとオラクル遅延を除けば正確で、CEXヒートマップは未知のレバレッジ分布を条件とする事前分布であり、クロスマージンには盲目だ)。するとマップの脆弱性は1つの比率に還元される。強制売り密度を板のデプスで割ったカスケード倍率 、つまり再生産数であり、1未満では亜臨界、1を超えると暴走する。シグナルはフェーズで分かれる。クラスターは前には磁石、後には反転ゾーンだ。そして反転の優位性が存在するのは、強制フローが非情報的であり、したがって一時的だからにすぎない。その記録された傾向も、カスケードが現実のニュースと重なった瞬間に消える。下落ではなく枯渇を取引し、 を尊重し、曖昧なヒートマップを埋められたポジションの場所を示す台帳だと決して取り違えないこと。
参考文献
- Qin, Zhou, Gamito, Jovanovic, Gervais (2021), An Empirical Study of DeFi Liquidations: Incentives, Risks, and Instabilities. arXiv:2106.06389.
- Kyle, A. S. (1985), Continuous Auctions and Insider Trading. Econometrica 53(6) — カスケードモデルで使う線形価格インパクト係数 。
- Cont, R., & Wagalath, L. (2016), Fire Sales Forensics: Measuring Endogenous Risk. Mathematical Finance 26(4) — 強制清算の価格インパクトと内生的相関。
- Bacry, E., Mastromatteo, I., Muzy, J.-F. (2015), Hawkes Processes in Finance. Market Microstructure and Liquidity 1(1) — 注文フローと清算フローの自己励起的なクラスター化。
- Binance Futures API documentation — 清算注文ストリーム(
!forceOrder@arr、<symbol>@forceOrder)。シンボルごとに毎秒1イベントへスロットルされる注記を含む。 - The Graph上のAave v3およびCompound IIIサブグラフ、Aaveの
getUserAccountDataとリザーブのリスクパラメータ。
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.