前回の開発記録では、Collateral Capacity Mismatch（CCM）という仮説について、複数のレンディング市場を比較しました。
調べていたのは、ざっくり言えば、
- 現在どれだけ借りられているか
- 担保評価が悪化したとき、どれだけの債務が清算対象になるか
- 清算された担保を市場で処分できる余地がどれくらいあるか
という構造です。
前回の記事：
🛠️開発記録#566(2026/9/10) 市場で売れる量より借入が大きい？
ただし、その時点では一つ大きな空欄が残っていました。
実際に清算された担保は、その後どうなるのでしょうか。
清算された量が大きくても、それがそのまま市場へ投げ売りされるとは限りません。
今回は、その部分をオンチェーンデータから追いました。
なお、この記事では研究中の市場名、コントラクトアドレス、トランザクションハッシュ、正確な件数や割合、個別プロトコル向けの検索条件などは一部伏せています。
研究結果そのものよりも、今回は何を使えばどこまで確認できたかと、その割に研究工程を必要以上に細かく分けてしまったことを記録します。
清算後の資産移動をどう確認したか
今回行ったこと自体は、特別な新技術ではありません。
EthereumのJSON-RPCから必要なログやトランザクションの実行結果を取得し、そこに含まれるイベントを読み直しました。
主に使ったのは次のような情報です。
- 清算イベント
- ERC-20の
Transfer - 担保持分の償還・引き出しイベント
- DEXの
Swap - 同一トランザクション内でのログ順序
まず、対象市場で実際に清算が発生しているかをイベントログから検索します。
清算トランザクションが見つかれば、そのトランザクションのreceiptを取得します。
receiptには、そのトランザクション内で発生したイベントログが残っています。
それを順番に並べていくと、
清算
↓
担保が清算者へ移動
↓
別の資産へ変換
↓
市場へ送られる
↓
交換される
のような流れを復元できます。
もちろん、すべての処理がイベントだけで完全に読めるとは限りません。
内部callの追跡が必要になる場合もあります。
ただし、今回調べた範囲では、主要な資産移動についてはreceipt内のイベントとtoken transferだけでかなり追うことができました。
Ethereum JSON-RPCの仕様はこちらです。
以前、価格を比較する研究でも「何を観測したことにするのか」を先に分解しました。
今回も考え方は同じです。
🛠️開発記録#559(2026/9/2) 仮説を検証する前に、観測経路を監査する
「清算された」という事実と、
「清算された担保が市場で売られた」
という事実は別物です。
今回は、その間をイベント単位で分解しました。
清算量と市場売却量は同じではありませんでした
実際に追ってみると、清算後の担保処分には複数の経路がありました。
大まかに分けると、
清算された担保
├─ 市場へ送られて交換される
├─ レンディング側へ再投入される
└─ 少なくとも同一tx内では処分されない
という違いが見えました。
ここは今回の調査で重要だった部分です。
当初は、
大きな清算
→ 大量の担保が処分される
→ 薄い市場へ強制売却が出る
という経路を強く意識していました。
しかし、実際には清算された担保の大部分が、そのまま即時売却されるとは限りませんでした。
あるケースでは、主要な経路は市場売却ではなく、同じトランザクション内でレンディング側へ戻す処理でした。
一方、別のケースでは、
清算
↓
担保持分を受け取る
↓
元の資産へ変換する
↓
DEXで交換する
↓
返済資産を得る
という、市場へ直接接続する経路も確認できました。
別の清算者でも似た処理が再現した一方で、同じ市場の別トランザクションでは、その場で市場売却まで進まない例もありました。
つまり、
「清算が起きた」だけでは、その後どれだけ市場売りが発生したかは分かりません。
清算額をそのまま強制売却額として扱うのは危険です。
MorphoやEulerの清算の基本構造については、それぞれ公式ドキュメントがあります。
Morpho Liquidations
https://docs.morpho.org/learn/concepts/liquidation/
Euler Liquidations
https://docs.euler.finance/concepts/risk/liquidations/
清算そのものの説明は既存資料に任せて、今回の研究では「そのあと資産がどこへ移動したのか」を実データで追いました。
実機では、思っていたより直接見に行けました
今回の作業で、自分の環境でどの程度まで調べられるかもかなり具体的になりました。
少なくとも今回の範囲では、
- 特定市場の過去の清算イベントを検索する
- 清算トランザクションを抽出する
- receiptからイベントログを読む
- token transferを追う
- プロトコル固有イベントと突き合わせる
- 同一トランザクション内の資産移動を復元する
- 複数の清算トランザクションを比較する
ところまでは、ローカル環境とRPC、小さな解析スクリプトで実行できました。
コードもリポジトリに残っています。
今後、別の市場を調べる場合も、すべてをゼロから作り直す必要はありません。
一方で、まだ確認していないものも多くあります。
今回確認したのは主に「清算後の資産移動」までです。
まだ、
- 全清算について処分経路を分類したわけではない
- 同一トランザクションより後の長期的な資産移動は十分追っていない
- DEXでの売却が実際に価格をどれだけ動かしたかは測っていない
- その動きを事前に検知できるかも未確認
- 手数料や滑りを含めて取引可能な優位性があるかも未確認
という状態です。
「清算後の売却が見えた」と「取引機会が見えた」は別の話です。
問題は技術ではなく、研究工程でした
ここからが今回の反省点です。
振り返ると、調査工程を必要以上に細かく刻んでいました。
たとえば、ある清算事例については、以前の調査ですでに代表トランザクションの中に、
清算
↓
担保を再び供給
↓
借入
という処理が存在することまで確認していました。
ところが今回、その既知の情報を最初から使わず、
担保が清算者へ移った
↓
別アドレスへ移った
↓
移動先の意味を再確認
↓
再供給だったことを確認
↓
資本再利用の流れを確認
と、低い解像度からもう一度登り直しました。
最終的には、清算担保の主要経路が即時市場売却ではなく再投入だったことを、複数トランザクションを通して確認できました。
この部分は新しいです。
ただし、そこへ到達するために必要だった工程より、実際に踏んだ工程の方が明らかに多かったです。
別の市場でも似たことをしました。
最初に、
「既存の成果物の中に清算トランザクションがあるか」
を監査しました。
その後で、実際のブロックチェーン上から清算イベントを検索しました。
後者を最初に行えば十分でした。
さらに、清算が大量に見つかった後も、
清算の存在確認
↓
代表1件の解析
↓
別トランザクションで再現確認
と別々の作業に分けました。
しかし今回の解析方法であれば、
清算イベントを見つけた時点で代表的な数件のreceiptまで取得し、処分経路をまとめて確認する
ところまで一度に進めても大きな問題はありませんでした。
読み取り中心の事後解析なので、長時間のデータ収集や本番発注のように、失敗時の損失が大きい作業でもありません。
慎重さのために分けていたつもりが、単に工程を増やしていた部分があります。
「必要十分」を観測だけでなく研究工程にも適用します
以前、観測基盤について、
高精度なら高精度なほどよいわけではない
という話を書きました。
🛠️開発記録#558(2026/9/1) 高頻度なら細かいほどいい？
そこで考えていたのは、
- 必要十分な観測粒度
- 必要十分な保存量
- 必要十分な分析
- 必要十分な実装
でした。
今回は、そこにもう一つ足りていませんでした。
必要十分な研究工程です。
同じデータ取得から複数の問いに答えられるなら、わざわざ別フェーズへ分ける必要はありません。
今回なら、
実清算はあるか
↓
担保はどこへ移るか
↓
市場へ売られるか
↓
別の数件でも同じか
は、必ずしも4回の研究作業に分ける必要はありませんでした。
同じイベントログとreceiptから確認できるのであれば、一度の限定調査でまとめて見る方が速いです。
今後は少なくとも、
- 最も安く、判断を大きく進める質問を先に見る
- 同じ証拠で答えられる隣接質問を別フェーズへ送らない
- 工程を分割するのは、失敗時の損失や不可逆性が大きい場合を中心にする
という形に修正します。
観測機を壊す可能性がある、長時間収集をやり直す必要がある、本番資金を使う、といった作業であれば、細かいgateには意味があります。
今回のような限定的なオンチェーン事後解析では、同じ分け方をする必要はありませんでした。
今回の現在地
CCM研究については、今回までで候補ケースの大まかな仕分けを一度終えました。
実際の清算後フローまで確認できたものもあれば、構造上は候補でも、調べた範囲では実清算が見つからず、その先へ進めなかったものもあります。
また、清算が実際に起きていても、その後の担保処分は一様ではありませんでした。
即時に市場へ売られる場合もあれば、レンディング側へ再投入される場合もあります。同じ市場の中でも経路が分かれます。
現時点では、
清算後の資産移動はかなり追えます。
一方で、
そのフローが市場価格をどれだけ動かすか、事前に見えるか、取引として使えるか
までは確認していません。
技術的には、今回実際に踏んだ工程よりも短い経路でここまで確認できました。
次からは、その前提で研究工程を組みます。
それでは、また。