Bot DeFi bot DEX 開発ログ

🛠️開発記録#600(2026/10/27)DEX Arbの「判定不能」を分解する――短時間Runで見えた観測と実行の制約

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

ここ数日は、DEXアービトラージ(DEX Arb)のエッジ探索を進めています。

10月24日には、開発記録#598「Solanaを掘り始めた――高速チェーンに個人botterのエッジはあるのか」で、Solanaの市場構造と初期調査の結果を整理しました。

その後、原子的裁定(Atomic Arb)の継続監視を始め、並行して進めているEthereum・Base・ArbitrumのDEX Arb監視でも実相場の短時間Runを実施しました。

ただし、今回も利益を回収できるエッジが確立したわけではありません。

むしろ、実際に監視と仮実行を進める中で、利益の有無を判断する以前に、確認しなければならない問題がいくつも見つかりました。

これまでにも、価格差と実現利益は別物であることや、費用・執行条件を含めて期待値を評価する必要性は繰り返し考えてきました。

今回新しかったのは、それらの問題が具体的な測定結果や実装上の問題として現れたことです。

どこまで観測できているのか。何が原因で取引が成立しないのか。何を確認できれば探索対象を絞れるのか。

今回は、短時間Runから得られた事実と、それによって更新した判断基準、そして現時点で保留している結論を整理します。

1.DEX Arbの監視を始め、利益以前の問題が見つかった

現在、DEX Arbについては大きく二つの系列で調査しています。

一つはSolanaです。複数のDEXや流動性プールを経由し、同一トランザクション内で資産を循環させるAtomic Arbを中心に、見積取得と実行可能性を調べています。

もう一つは、Ethereum・Base・Arbitrumを対象とする監視botです。複数の取引経路について数量別の見積を継続取得し、候補が現れた場合にはローカルのフォーク環境で取引が成立するか検証します。

フォーク環境とは、既存のブロックチェーンの状態をローカルに再現し、実際の資金を動かさずに取引を試す仕組みです。

両者は異なる市場・実装を対象としているため、結果を単純に比較することはできません。

それでも、共通して見えてきた問題がありました。

監視プログラムが動いていること、価格差を検出すること、利益を回収できることは、それぞれ別の状態だということです。

これは以前から理解していた内容ですが、今回のRunでは、その区別を実際の測定結果へ落とし込む必要が生じました。

2.監視の稼働は、有効な市場観測を保証しない

まず問題になったのは、監視の継続時間と取得データの品質です。

Solanaでは、約1時間の継続Runを実施しました。

監視処理自体は予定終了まで動作しましたが、途中には通信の空白がありました。また、複数の交換を順番に見積もる経路では、取得完了までの時点差が大きくなり、設定した鮮度条件を満たせない例が多く見られました。

これは、約1時間の稼働時間すべてについて、有効な価格差を観測できたわけではないことを意味します。

EVM側の30分Runでも、同様に観測の欠落が確認されました。

実施した評価の約94.4%は成功として記録されています。しかし、予定していた評価全体を基準にすると、有効評価は約80.8%でした。

この差には、取得要求の制限、流動性不足による評価失敗、実際の処理周期の遅れなどが関係しています。

なお、ここでいう有効評価は、監視プログラムが評価成功として集計した件数です。実際に裁定取引を成立させられる見積の件数ではありません。

また、残りの約19.2%について、市場に利益機会が存在しなかったと判断することもできません。

この結果から、今回あらためて明確になったことがあります。

機会を観測できなかったことと、機会が存在しなかったことを同じ結果として扱ってはいけません。

さらに、観測間隔にも注意が必要です。

例えば、ある経路を1分に1回だけ調べた場合、その間に発生して消滅した短時間の価格差は記録されません。

反対に、同じ価格差を連続して観測した場合、それを独立した複数の利益機会として数えることもできません。

そのため、今後はプラス見積の件数だけでなく、有効観測の割合、再取得間隔、同一機会の重複、観測できなかった時間も考慮する必要があります。

3.プラスの見積が出ても、取引成立には届かなかった

次に問題になったのは、見積と実行可能性の関係です。

今回の監視では、いくつかの経路でプラスの見積を確認しました。

しかし、仮実行まで進めると取引が成立しない事例がありました。

具体的な取引経路や数量は公開しませんが、確認した出来事を整理すると次のようになります。

対象確認した出来事現時点の判断
EVM系の裁定経路費用控除前に微小な正の乖離を検出したが、フォーク上の交換で受取下限を満たせず停止失敗原因は未確定
Solanaの複数市場を利用する経路一部数量でプラス見積を取得したが、取引命令の仮実行に失敗実行可能性は未確認
Solanaの別の経路群見積の取得時点差が大きく、有効な比較がほとんどできなかった収益性以前に観測方法を再検証

同じ「利益を取得できなかった」という結果でも、中身は異なります。

EVM側では、見積を取得した時点とフォークで検証した時点の市場状態が異なっていた可能性があります。また、再取得した見積や取引データの組み立てに問題があった可能性も残っています。

Solana側では、見積の取得に成功しても、対象経路の命令を組み合わせた取引が成立するとは限らないことを確認しました。

ただし、こちらも失敗原因の特定は完了していません。

したがって、今回の実行失敗を、既存botとの速度競争に負けた結果として説明することはできません。

そもそも競争の段階へ進む前に、観測や取引組成の問題が残っているからです。

現状では、価格差が存在していた可能性と、その価格差を自分が実行可能な利益として取得できるかどうかを、別々に評価する必要があります。

4.測定方法と利益判定の前提も疑い直した

今回の研究では、市場だけでなく、すでに実装していた評価処理も見直しました。

ここは、個人的に重要だった部分です。

当初は、利益候補が少ない場合、単純に市場に機会が少ない可能性を考えていました。

しかし、監視処理を確認すると、結果そのものに影響する問題が複数見つかりました。

一つは、異なる時刻の見積を組み合わせていたことです。

例えば、投入数量を変えながら経路の採算を比較する場合、各見積が異なる時点の市場状態を参照していれば、その差をすべて数量による価格影響として解釈することはできません。

また、APIが取引数量などに応じて別の流動性プールを選択する場合、同じトークンの交換を比較していても、実際には異なる経路を評価している可能性があります。

もう一つは、利益判定そのものの問題です。

Solana側では、循環取引後に中間資産が少量残るケースを、利益評価から厳しく除外していました。

しかし、元の資産が増えており、既存在庫も減っていないのであれば、残った資産をゼロ評価したとしても利益が成立する場合があります。

この点は合成データによるテストで確認し、判定処理を修正しました。

ただし、実際の市場データにおいて利益機会を見逃していたと確認されたわけではありません。

今回の修正によって、利益候補が増えると証明されたわけでもありません。

明確になったのは、測定・評価ロジックに問題が残っている限り、観測結果から市場の収益性を判断することは難しいということです。

こうした問題を修正せず、単純に監視時間だけを延ばしても、不適切な条件で取得したデータが増えるだけになりかねません。

この認識は、今後のRun設計にも反映する必要があります。

5.「判定不能」を分け、探索の継続と停止を判断する

ここまでの調査で、DEX Arbのエッジ探索に対する判断基準も少し具体化しました。

期待値の評価や探索の終了条件については、以前の開発記録#461「EVを確定せよ:DeFiアービトラージ探索の設計論」でも整理しています。

今回更新したのは、期待値を判断する理論そのものではありません。

実際の検証が途中で止まった場合に、その原因によって次の研究判断を変える必要があるという点です。

検証で確認した状態次の判断
見積の鮮度・経路の同一性などを満たさない観測方法を再検証する
有効な見積で、対象数量の費用後収支が継続して不足する当該条件の優先度を下げる
見積はプラスだが、仮実行が失敗する原因を特定するまで実行可能性を保留する
仮実行が成立する競争・遅延・費用を含めた取得可能性の検証へ進む
取得可能性が確認できる発生頻度・容量・失敗費用を含めた反復採算を評価する

ここで大切なのは、どの段階で何を棄却できるのかということです。

例えば、観測条件を満たさない経路について、収益性がないと結論づけることはできません。

一方で、現在の観測方法では十分なデータを集められず、改善費用も大きいのであれば、研究上の優先度を下げる判断はできます。

また、費用後の収支がマイナスだったとしても、それは評価した経路・数量・市場状態に対する結果です。

異なる数量や流動性条件、別の経路まで一括して否定できるわけではありません。

仮実行の失敗についても同様です。

実装を修正すれば成立するのか、プロトコルの仕様上成立しないのかによって、次の判断は変わります。

以前から探索候補を継続・保留・棄却に分類してきましたが、今回はその前段階として、何が分からないために保留しているのかを、より明確に分ける必要があると感じました。

ただし、保留を無期限に続けるつもりもありません。

原因を調べるための費用が大きく、期待できる利益機会も限定的であれば、結論を確定できなくても研究配分を下げる判断は合理的です。

研究を停止することと、市場にエッジが存在しないと証明することは別です。

この区別は、今後も維持したいと思います。

6.次のRunは、時間よりも解消する疑問で決める

今回の結果を受けて、監視の実装とRunの進め方も見直しています。

Solana側では、見積取得方法の比較、残差の利益判定、手数料と資産残高の扱い、設定値の反映などを再検証しました。

修正後には短時間の追加計測も行っていますが、現時点で費用後利益を回収できる経路は確認できていません。

EVM側では、仮実行に失敗した取引の見積や取引データを、失敗した段階でも記録する改善を優先しています。

また、APIの要求制限による欠測を減らすため、取得間隔や要求の集中についても見直す方針です。

こちらは修正後に短時間Runを挟み、改善が確認できてから長時間Runへ移行する想定です。

今回、特に避けたいと思ったのは、長く動かせば研究が進むと考えてしまうことです。

もちろん、利益機会の頻度や市場状態の変化を調べるためには、長時間の観測が必要になる場合があります。

しかし、見積の取得方法そのものに問題がある場合、単純な観測時間の延長では解決しません。

反対に、観測品質が十分で、あとは機会の出現頻度や継続時間を確認したいのであれば、24時間以上のRunにも意味があります。

今後は、追加のRunで何を判断できるようにするのかを先に明確にして、その目的に合わせて観測期間と対象を決めたいと考えています。

高速化や有料インフラの導入についても同様です。

速度が原因で利益を取得できないと確認できていない段階で、単純に処理性能へ投資しても、問題が解決するとは限りません。

必要な改善は進めますが、実装量や稼働時間ではなく、解消できた疑問と更新できた判断を研究の成果として扱いたいと思います。

7.DEX Arbの収益性は、まだ結論を出さない

最後に、現在の認識を整理します。

DEX Arbはすでに多くの参加者が競争している領域です。主要な裁定市場では利益が一部の参加者に集中しているという外部調査もあり、一般的な価格差の収束だけで優位性を確保することは容易ではないと考えています。

ただし、今回の短時間Runから、自分が既存botとの速度競争に負けていると確認できたわけではありません。

また、特定の経路で利益を確認できなかったことから、DEX Arb全体に個人botterの取得余地が存在しないと結論づけることもできません。

現段階で確認できたのは、主に観測と取引組成に関する問題です。

したがって、単独のDEX Arbについては、引き続き収益性を保留します。

一方で、DEX Arbを調べる価値は、単独の裁定利益に限らないとも考えています。

DEXの流動性や経路を評価する能力は、清算で取得した担保の売却、マーケットメイク後の在庫処理、別市場でのヘッジなどにも利用できる可能性があります。

こうした収益構造の接続については、開発記録#597「DeFi botの戦略統合について考えていること」でも触れています。

もちろん、複数の仕組みを組み合わせれば利益が増えると確認できたわけではありません。

単独戦略で十分な利益を取得できるなら、複雑な統合を行う必要はありません。

ただ、DEX Arbを単独戦略として評価することと、別の収益構造を成立させるための取引経路として評価することでは、必要な判断が異なります。

今後は、そうした使い道も視野に入れながら、個々の市場や経路の検証を進めるつもりです。

今回の研究では、目立った利益機会を確認できたわけではありません。

それでも、実際に監視を動かしたことで、観測できないこと、採算が不足すること、取引として成立しないことを、異なる問題として扱う必要性が具体化しました。

特に重要なのは、結論を出せない状態を、そのまま曖昧に残さないことだと思います。

何が確認できていて、何が不足しているのか。

次に何を検証すれば判断が変わるのか。

そして、どこまで調べたら、その候補への研究配分を下げるのか。

DEX Arbのエッジ探索では、今後もこの区別を重視していきます。

価格差を探すこと自体が目的なのではありません。

自分が取得できる利益の構造を明らかにし、その判断に必要な情報を集めることが目的です。

今回は、そのための観測と判定の仕組みを少し具体化できた回だったと思います。

それは、また。

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