Bot DeFi bot DEX 開発ログ

🛠️開発記録#572(2026/9/17)清算エッジ探索をどうフェーズシフトするか?

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

清算エッジの研究を一度整理しました。

これまで、Morpho × Pendleを起点として、価格形成、Oracle、借り手の清算条件、実際の清算取引、清算後の資産移動までかなり細かく追ってきました。

その過程で、「見えるか?」についてはかなり解像度が上がりました。一方で、清算エッジとして利益までつなげようとすると、その先には別の問題があります。

今回、一連の研究結果、実装、測定上の限界をまとめて監査しました。

その結果、清算研究そのものをやめるわけではありませんが、今後のエッジ探索では研究時間の使い方を少し変える必要があると判断しました。


1. 清算のどこまで見てきたか

清算というイベントだけを見ると、

担保価格が下がる
→ 借り手が清算される

という比較的単純な出来事に見えます。

実際には、もう少し長い経路があります。

市場価格

Oracle・担保評価

借り手の清算条件

清算可能な状態

清算取引

担保取得

担保の換金・再利用

最終損益

今回までの研究では、この経路をかなり細かく分解しました。

Morpho × Pendleでは、34市場・10種類のOracle構造を調べ、複雑な価格参照経路についても過去blockでかなり高い精度で再構成できるようになりました。借り手ごとの清算距離についても、担保量、借入量、LLTV、Oracle価格などから計算できます。

ここにはかなり時間をかけました。

Oracle内部にはTWAP、比較器、複数の価格参照先などがあり、単純に「市場価格が何%下がれば清算」という形では扱えない市場もあります。

この分解作業自体は必要でした。

どの数字が何を表しているのか分からないまま、「清算まであと○%」のような指標だけを作っても、その数字を正しく解釈できないからです。

イメージ:市場価格 → Oracle → 清算条件 → 清算 → 担保処理 → 損益】


2. 「見えるか?」はかなり進んだ

研究初期では、

清算より前の状態を観測できるのか?

という問いをかなり重視していました。

PT-reUSDの事例では、市場価格の変化、TWAP、Oracleへの反映、借り手の清算リスクという順番を分けて確認しました。

結果として、Oracleは必ずしも最速の情報源ではありませんでした。

市場価格の方が先に変化しており、Oracleの主な役割は、その市場変化を「この借り手がどれくらい清算に近づいたか」という貸借市場側の状態へ変換することでした。

これは重要な区別でした。

一方で、ここまで再構成できるようになると、別の問題も見えてきます。

Oracleをさらに正確に再現したとしても、それだけでは清算機会を取れるとは限りません。

「見える精度」をさらに上げることと、「利益へ近づくこと」が同じではなくなってきました。


3. 前回は「見える」から「取れる」へ移ろうとした

過去の記事では、清算研究を次のように整理しました。

見えるか

予測できるか

取れるか

儲かるか

この4つは別々に確認する必要があります。

たとえば、清算が3分後に起こりそうだと正確に予測できたとしても、その清算取引を他の参加者より先に通せなければ、直接清算のエッジにはなりません。

逆に、清算自体は取れたとしても、受け取った担保を換金した結果、手数料や価格への影響で利益が残らなければ、やはり実用的なエッジにはなりません。

この点については、前回の記事で一度整理しています。

関連記事:開発記録#569「清算を『先に見る』研究:オラクル分解から見えてきた予測と実行の距離」

今回の記事は、その後に実際に複数の清算市場を調べた結果です。

【「見える」「予測できる」「取れる」「儲かる」は別の問題】


4. 実際に「取れるか?」まで掘ると、止まる場所が違った

複数のprotocolを調べた結果、同じ「清算エッジがまだ確認できない」という状態でも、その理由はかなり違っていました。

Morpho:予測できても競争が速い

Morpho Ethereumでは、25件の清算取引、11市場について、実際の清算者が取引を成立させる前の状態を調べました。

block単位で解決できた範囲では、すべて同一blockまたは1block以内で清算されており、「清算可能な状態が丸々1block以上残っていた」と確認できる例はありませんでした。

もちろん、block内部のどのtransactionで正確に清算可能になったのかまでは完全に再現できていません。

そのため、

Morphoでは絶対に取れない

という結論ではありません。

ただし、少なくとも私が調べたsampleでは、最後の取引取り込み競争がかなり速いという証拠が残りました。

上流状態を詳しく見ることだけでは、この問題は解消しません。


Project 0:構造は見えるが、実例が足りない

Solana上のProject 0についても調べました。

借り手の状態や清算条件は仕組み上かなり明示的で、清算経路そのものも確認できました。

一方、代表的な過去清算sampleを十分に集められず、実際の清算競争、必要なtransaction構成、優先手数料、担保処理まで比較できる状態には届きませんでした。

ここでは、

仕組みとしてあり得る

ということと、

実際に研究を進めるだけの証拠がある

ということを分ける必要がありました。

現在は WATCH_ONLY としています。


Euler:実行できても、最後に利益が残るとは限らない

Eulerは今回かなり長く調べた対象です。

最初の再現では、新しい第三者アドレスから清算を試すと失敗し、

実際の清算者にしか使えない何かがあるのではないか

という見え方になりました。

しかし、実装と測定方法を確認すると、この判断には問題がありました。

必要なcontrollerやcollateralの設定は同一transaction内で行うことができ、資本条件も明示したうえで再検証すると、選んだ6件すべてで第三者による清算処理を再現できました。

さらに5件では、実際の勝者が清算する20block以上前から処理可能でした。

ここだけを見ると、

実行可能性はかなり残っている

という判断になります。

しかし、その後に受け取った資産を普通の公開市場で換金するところまで計算すると、状況が変わりました。

5件のうち、換金まで含めて明確にプラスとして再構成できたものは1件だけで、その利益は約2セントでした。

つまり、

清算できる
≠ 利益になる

ということです。

「取れるか?」という問い自体にも、実行、資金、担保処理、換金、最終損益という複数の層がありました。


Moonwell:測れないことと、ダメだったことは別

Moonwellでは、別の問題にぶつかりました。

最初の測定では、RPCの失敗、内部transactionの取得、DEX経路の不足などが混ざり、かなりのケースが未解決になりました。

そこで測定方法を修正し、少数事例では最初から最後まで確認できることを確かめました。

しかし、20件へ広げると、最後まで解決できたのは5件でした。

3件が測定できた範囲ではプラス、2件がマイナス、残り15件は未解決です。

この状態で、

Moonwellは儲からない

とは言えません。

正しい判断は、

現状の測定では十分に分類できない

です。

さらに現在のMoonwellでは、確認時点で21市場すべてのborrow capが実質的に新規借入を止める状態になっていました。

そのため、今から通常の新規ポジションを使ってliveで検証する対象としても適していません。

ここでは、「市場が悪い」のではなく、「測定上の限界と現在の市場状態が研究継続を止めている」と整理しました。

【Morpho=競争 / Project 0=証拠不足 / Euler=採算 / Moonwell=測定限界】


5. 清算後の資産移動でも同じ問題があった

以前、清算された担保がその後どこへ移動したのかも調べました。

大量に清算された場合、

受け取った担保がそのまま市場で売られるのではないか

という想定がありました。

しかし、PT-reUSDなどで実際のtransactionを追うと、直接市場へ売却された割合は低く、担保を別のpositionへ再投入するような動きが多く確認されました。

調べた3事例で直接売却された比率は、約1.53%、0.37%、3.02%でした。

つまり、

清算額
≠ そのまま市場へ出る売り圧力

でした。

この過程でも、清算額だけを見て市場への影響を推定することはできませんでした。

実際に資産がどこへ移動し、どの経路で市場へ出るのかを確認する必要があります。

この研究では、作業を細かく分割しすぎることで、判断に必要な情報よりも成果物の量が増えてしまう問題もありました。

関連記事:🛠️開発記録#567(2026/9/11)清算後の資産移動をオンチェーンから追う|研究工程を細かく刻みすぎた話

今回のフェーズシフトは、このときに感じていた研究効率の問題を、清算エッジ探索全体へ広げたものでもあります。


6. 今回変えるもの、変えないもの

今回の整理で、変えない部分があります。

まず、mechanismの理解は今後も省きません。

市場価格、Oracle、清算条件、transaction構造などを正しく理解できていなければ、その後の数字も正しく解釈できません。

また、

測れなかった
= 存在しない

とも扱いません。

Moonwellで実際に起きたように、測定方法の問題によってnegativeに見えることがあります。

実際の清算者が成功したtransactionを見るだけで、「自分でも実行できる」と判断することもしません。

これらは今後も維持します。

一方で、変えるのは研究時間の配分です。

これまでは、「見えるか?」の解像度を上げることに長く時間を使うことがありました。

今後は、観測可能性だけを先に完成させるのではなく、

その先に実行可能性や採算性へ接続する見通しがあるか

についても、研究の比較的早い段階から意識します。

具体的な仕組みを飛ばして雑に候補を落とす、という意味ではありません。

むしろ、

深く調べる価値がある対象に、深いmechanism研究を使う

という方向です。

【「これまで:見えるものを増やす」→「これから:mechanism理解+取れる見通しも早期から意識」】


7. 次の清算エッジ探索へ

今回の監査時点では、

EDGE_CONFIRMED = false
TRADEABLE_EDGE_CONFIRMED = false

です。

live環境で再現し、実際に取得可能で、すべてのコストを含めても利益が残る清算エッジはまだ確認できていません。

ただし、研究開始時と比べると、何を区別する必要があるかはかなり整理されました。

清算条件が見えること。

その状態を事前に予測できること。

第三者が実際に処理できること。

競争の中でtransactionを成立させられること。

受け取った資産を処理できること。

そして最後に利益が残ること。

これらは同じ問題ではありません。

一方で、すべてを最初から最高精度で確認する必要もありません。

今回までの研究では、「見えるか?」を深く掘ったことで得られたものが多くありました。その一方で、後段まで進めて初めて判明した制約もありました。

次の清算エッジ探索では、この経験を研究時間の配分にも反映します。

清算研究そのものを閉じるわけではありません。

一度ここまでの探索を整理し、次は新しいフェーズとして再開します。

それでは、また。

-Bot, DeFi bot, DEX, 開発ログ