こんにちは、よだかです。
ここ数日は、CCMという研究を進めていました。
CCMは、**担保流動性と借入能力の不均衡（Collateral Capacity Mismatch）**を調べる研究です。
出発点は比較的単純でした。
DeFiのレンディング市場では、担保価値に応じて資産を借りることができます。しかし、担保として認められている資産が大量に清算されたとき、その資産を市場が十分に処理できるとは限りません。
たとえば、
- 清算対象になり得る担保は多い
- 実際に清算された担保が市場で売却される
- その売却量に対して市場の流動性が小さい
という条件が重なると、清算によって生じる売却フローそのものが価格を押し下げる可能性があります。
今回は、この構造を実際の事例で順番に確認しました。
最終的には、価格への影響だけでなく、
その歪みを実際の取引で利益に変えられたのか
というところまで確認しています。
以前の開発記録#566、#567で始めたCCM研究は、今回でいったん一区切りにします。
1．清算額ではなく「市場が処理できる量」を見たかった
CCM研究で最初に考えていたのは、
大きな担保があること
そのものではありません。
重要なのは、
ストレスが発生したときに市場へ出てくる可能性がある量と、それを市場が受け止められる量の関係
です。
研究を進める中で、確認する対象を次のように分けました。
清算対象になり得る担保量
↓
実際に清算される
↓
清算された資産が市場へ出る
↓
市場がその売却を処理する
↓
価格への影響が残る
ここでいう「市場へ出るフロー」は、清算などによって発生する**強制フロー（forced flow：主体の裁量が小さい状態で発生する売買フロー）**として扱っています。
また、市場が一定の価格変化の範囲内で処理できる量を、今回は**処理能力（clearance capacity）**として測定しました。
単に、
清算額が大きかった
ではなく、
清算による売却量が市場の処理能力を超えていたのか
を見るためです。
【CCM研究全体の流れ】
2．清算された担保は、本当に市場へ出ていた
今回中心的に調べたのは、Euler上のynRWAxを担保にした市場です。(もう少し正確に表現するなら、RWA商品であるynRWAxを担保に利用できるEulerの貸付市場です)
まず確認したのは、
清算された担保が本当に市場で売却されていたのか
でした。
清算された担保は、そのまま別の貸付市場へ預け直されることもあります。
その場合、
清算額が大きい
＝
市場への売却圧力が大きい
とは言えません。
そこで、清算後の資産移動を取引単位で追いました。
対象期間では106件の清算取引を確認しました。
清算後に引き出されたynRWAxは約16.5万枚で、その99.98%にあたる量が市場で売却されていました。
確認できた範囲では、引き出された資産のほぼ全量が市場へ向かっていました。
これによって、
清算された担保が帳簿上で移動しただけ
ではなく、
実際に市場へ売却フローが発生していた
ことを確認できました。
ここまでが、以前の開発記録#567で確認していた部分です。
3．強制フローは市場の処理能力を超えていた
次に調べたのは、
その売却量を市場がどの程度処理できたのか
です。
代表的な1件では、約14,967 ynRWAxが市場へ売却されました。
これに対して、売却直前の市場全体を再構築すると、
- 価格変化を50bps以内に抑えて処理できる量：約3,119 ynRWAx
- 価格変化を100bps以内に抑えて処理できる量：約6,140 ynRWAx
でした。
1bpsは0.01%なので、50bpsは約0.5%、100bpsは約1%です。
つまり、この清算で発生した約14,967 ynRWAxの売却は、
約0.5%の価格変化で処理できる量の約4.8倍
でした。
最初は主要なCurveプールだけを見ていましたが、その後、他の売却経路も含めて計算しています。
それでも結論は大きく変わりませんでした。
単に、
1つのプールだけ流動性が薄かった
という話ではなく、市場全体で見ても売却量が処理能力に対して大きい状態でした。
【Case Aの強制フロー量と50bps・100bps処理能力の比較】
さらに時間を進めて確認すると、100bpsまで価格変化を許容すれば約60秒後には処理能力が回復していました。
一方、50bps以内という厳しい条件では、1時間後まで不足状態が残りました。
市場は売却を処理していましたが、
元の価格水準に近いまま処理できていた
わけではありません。
4．価格への影響も、すぐには消えなかった
処理能力が不足していても、価格への影響がすぐ消えるのであれば、取引上の意味は小さくなります。
そこで、売却後の実行可能価格も追いました。
代表事例では、強制売却の直後に主要プールの価格が約671bps下落しました。
一方で、その瞬間の市場全体で最も有利な売却価格は、まだ約2bpsしか動いていませんでした。
つまり直後には、
強制売却を受けた市場
→ 大きく下落他の売却経路
→ まだほとんど動いていない
という価格差が生まれていました。
その後、市場全体の価格も動きます。
T0を基準にすると、
- 60秒後：約-47bps
- 5分後：約-93bps
- 30分後：約-96bps
- 1時間後：約-96bps
でした。
5分後には6経路中5経路がT0より下落し、そのうち3経路では50bpsを超える下落を確認しています。
主要プールだけの一時的な歪みではなく、複数の売却経路へ価格変化が広がっていました。
【T0 → 売却直後 → 60秒 → 5分 → 30分 → 1時間の価格推移】
ここまでで、
清算による売却量が市場の処理能力を超え、その後も価格への影響が残る
というところまでは確認できました。
5．では、この歪みは実際に利益になったのか
ここまで数字が揃ったところで、研究の問いを変えました。
追加で市場構造を細かく説明するよりも、
では、この価格差をどうやって取引に変えるのか
を先に確認することにしました。
強制売却の直後には、
- 売却された主要プールではynRWAxが安い
- 別の売却経路ではまだ高く売れる
という状態がありました。
そこで、
USDC
↓
価格が下がった主要プールでynRWAxを買う
↓
別の経路でynRWAxを売る
↓
USDCへ戻す
という往復取引を、当時のブロック状態を再現して計算しました。
単純な価格差ではなく、実際のプールに注文を通した場合の受取量を使っています。
結果として、約1,500 ynRWAx相当を取引したケースでは、
- 粗利益：約52.7ドル
- ガス代と一定の競争コストを差し引いた試算：約45.6ドル
が残りました。
少なくとも、
値段が違って見えただけ
ではありません。
当時の実行可能な価格を使っても、利益が残る取引経路が存在していました。
【強制売却 → 主要プールで安く買う → 別経路で売る → USDCへ戻す → 利益】
6．利益はあった。しかし、取れる時間軸が違った
ここが今回の研究で最も重要だった部分です。
利益が存在したからといって、自分が取れるとは限りません。
そこで、強制売却後のブロック内を取引順に再構築しました。
強制売却直後には利益が残っていました。
その後、同じブロック内のいくつかの取引後でも、まだ利益は残っています。
しかし、さらに取引が進むと利益は消えました。
ブロック終了時点ではすでに赤字です。
次のブロックでも利益は残っていませんでした。
つまり、
強制売却を確認してから次のブロックで注文する
という通常のボットでは遅いことになります。
さらに、最初に価格差へ反応した取引を調べると、
安くなった主要プールでynRWAxを買い、同じ取引内で別の市場へ売る
という、今回再現したものと近い経路を確認しました。
実際にこの価格差を取りに行く参加者が存在していました。
7．ここから先はCCMではなく、別の実行技術になる
最後に、
では、自分でもこの取引に参加できたのか
を確認しました。
ここで、研究対象の層が変わりました。
対象の清算取引は、通常の取引手数料による優先順位付けだけではなく、ブロック構築者（builder）への直接支払いを利用していました。
対象ブロック自体もBuilderNetによって構築され、MEV-Boost経由で提案者へ渡されたことを確認しています。
また、清算を行っていた実行主体の近接取引を調べると、10件中9件でブロック構築者側への直接支払いが確認できました。
最初に価格差へ反応した取引にも、同様の直接支払いがあります。
つまり、今回見つけた利益機会は、
普通の公開メモリプールを監視して、次のブロックで注文する
という世界ではなく、
同じブロック内で取引順序を競うMEV（Maximal Extractable Value：ブロック内の取引順序などから得られる追加的な価値）の世界
にありました。
対象の清算取引が、公開メモリプールで事前に見えていたかどうかについても調べました。
Flashbotsの当日アーカイブには対象取引がありませんでした。
ただし、そのアーカイブで捕捉されていたのは対象ブロック65取引中26件だけでした。
このため、
アーカイブにない
＝
非公開取引だった
とは判断できません。
ここは最後まで不明として残しました。
個人でもBuilderNetへ取引束（bundle）を送る技術的な経路自体は公開されています。
一方で、
そもそも対象となる清算取引を事前に見ることができたのか
は別問題です。
最終的には、
利益機会 ：確認
同一ブロック内の競争 ：確認
一般的なボットでの取得：支持されず
個人searcherの参加可能性：一部残る
というところまでで止めました。
8．CCM研究はここでいったん閉じる
今回のCCM研究では、
清算対象になり得る担保
↓
実際の清算
↓
市場への売却
↓
市場の処理能力不足
↓
価格への影響
↓
実行可能な利益
↓
その利益へアクセスできる時間軸
まで確認しました。
最初に考えていた、
市場が処理できる量より大きな清算フローが発生すると、局所的な価格の歪みにつながるのではないか
という構造については、少なくとも今回の事例ではかなり具体的なところまで確認できました。
一方で、その歪みから生まれた利益は、通常のボットが扱いやすい時間軸には残っていませんでした。
この先を進めるなら、
- 公開メモリプールの監視
- 非公開注文フロー
- 取引束の送信
- ブロック構築者
- リレー
- 同一ブロック内での後続取引
- MEV競争
などを扱うことになります。
これらはCCMという市場構造をさらに説明するための調査というより、同一ブロック内で利益機会を取りにいくための実行技術です。
そのため、CCM研究としてはここで区切ることにしました。
今回も、
edge_confirmed = false
tradeable_edge_confirmed = false
のままです。
利益機会そのものは確認できました。
しかし、
利益が存在すること
と、
自分が継続的にその利益へアクセスできること
は別でした。
ここまで確認できれば、CCMの事例研究としては十分だと判断しています。
残っている不明点をすべて消すことよりも、ここから先は別の研究体系になると判断できたことを区切りにします。
MEVを使った清算後の裁定取引については、現時点では監視対象として残し、CCM研究そのものはいったん終了します。
それでは、また。
-
-
🛠️開発記録#566(2026/9/10)市場で売れる量より借入が大きいと何が起きるのか？｜CCM仮説を4ケースで調べた話
続きを見る
-
-
🛠️開発記録#567(2026/9/11)清算後の資産移動をオンチェーンから追う｜研究工程を細かく刻みすぎた話
続きを見る