こんにちは、よだかです。
ここしばらく、DeFiのエッジ探索で「状態遷移」という見方を使っています。
ここでいう状態遷移とは、単なる価格変動のことではありません。ある注文や取引機会が、時間や条件の変化によって「第三者にはまだ触れない状態」から「第三者も実行できる状態」へ移ったり、「利益にならない状態」から「外部市場との価格差が生まれる状態」へ移ったりすることを指しています。
今回は、この Lifecycle Transition Edge（状態遷移型の取引機会） という見方をUniswapXに持ち込み、実際の注文や約定を使って検証しました。
結論を先に書くと、状態遷移そのものは実在していました。また、状態が変わる途中で実際に価格差がプラスへ転じるケースも確認できました。
一方で、現時点では、自分がbotを実装して取りに行きたいと思えるほど、強くて反復的な取引機会までは確認できていません。
UniswapXを「捨てた」というより、ひとまず現在の市場構造と、自分にとっての取引可能性を一巡して確認した、という整理が近いです。
Acrossで得た視点をUniswapXへ持ち込んだ
今回の出発点はUniswapXではありません。
少し前にAcross Relayerを調べていたとき、
特定の参加者だけが動ける
↓
時間や条件が変わる
↓
第三者も処理できるようになる
という構造を見ていました。
たとえば Exclusive → Public、日本語にすれば「優先権のある状態から、第三者にも開かれた状態への変化」です。
Acrossでは最終的に、個人botterとして取りに行くには利益幅や資本効率が弱いと判断しました。ただし、状態が切り替わる瞬間そのものを観測対象にする考え方は、他の市場でも使えるのではないかと考えました。
そこで次の検証先として選んだのがUniswapXです。
UniswapXでは、ユーザーが交換条件を含む注文に署名し、その注文を第三者の実行者（filler）が処理します。注文によっては、一定期間だけ特定の実行者が優先される排他的実行期間（exclusivity）が設定されます。
さらに、時間経過とともに交換条件が変わるダッチ方式（Dutch）や、交換条件が固定された指値型（Limit）があります。
つまりUniswapXには、
- 誰が実行できるかが変わる
- 注文条件が時間とともに変わる
- 外部市場の価格変化によって注文の採算が変わる
という複数の状態遷移が存在します。
Lifecycle Transitionという見方を試す対象として、構造的に相性が良いと考えました。
関連記事：🛠️開発記録#578「Across Relayerのエッジ探索｜仮説から24Hシャドーまで」
【状態遷移型の取引機会という見方】
UniswapXでは状態遷移そのものが実在した
最初に確認したかったのは、そもそも想定していた状態遷移が実市場で起きているのか、という点です。
ここでは大きく二種類の変化を考えました。
一つ目は、参加可能性の変化です。
排他的実行期間が終わることで、
特定の実行者だけが処理できる状態 → 第三者も処理できる状態
へ移ります。
保存した過去データでは、排他的実行期間の終了後に約定した注文が41件、そのうち指定外の実行者による約定が27件ありました。また、少なくとも1ブロック以上、第三者に開かれた状態が続いてから約定した注文も15件確認できました。
したがって、
排他的な状態が終わり、第三者が途中参加できる
という構造そのものは実在しています。
もう一つは、経済状態の変化です。
これは同じUniswapXでも少し仕組みが違います。
ダッチオークション方式(以下、ダッチ方式)では、時間経過によって注文条件そのものが変化します。
一方、指値型では注文条件は固定されています。その代わり、外部市場の価格が動くことで、
利益にならない状態 → 利益になり得る状態
へ変化します。
今回の後半では、この指値型で実際に価格差がマイナスからプラスへ転じるケースまで確認できました。
つまり、Lifecycle Transitionという見方は単なる抽象モデルではなく、UniswapX上の実際の状態変化を捉えることができていました。
関連記事：🛠️開発記録#580「エッジはどこで消えるのか｜DeFi探索の見方を少し変えた話」
最初は六つの候補を別々のedgeとして扱った
構造監査を進める中で、最初は六つの候補を分けて見ていました。
- 排他的実行期間が存在しない注文
- 保有資産を使った直接充当
- 排他的実行期間中の有料参加
- 指値注文
- Baseなど低コストなチェーン上での実行
- 複数注文のまとめ処理
ただ、掘っていくと、この六つは同じ種類ではないことが分かってきました。
たとえば「低いgas代」は、それ自体が利益を発生させるものではありません。
「複数注文をまとめて処理する」ことも、それだけでは利益源ではありません。
先に利益の出る注文が存在して初めて、それらは意味を持ちます。
ここは今回かなり大きく理解が更新された部分です。
利益源と取り方を分けて考えるようになった
最終的には、六つの候補を四種類に分ける方が自然だと考えるようになりました。
利益そのものを発生させるもの
- ダッチ方式による注文条件の変化
- 指値注文と外部市場価格の交差
第三者が参加するための条件
- 排他的実行期間が存在しない状態
- 追加コストを払うことで保護期間中でも参加できる仕組み
利益を取得するための実行方法
- 保有資産による直接充当
- 複数注文のまとめ処理
実行コストを左右する環境
- Ethereumより取引コストの低いBaseなどのチェーン
この整理をすると、最初の六枝のうち、独立した「利益源」として残るものは大きく二つになります。
一つは、ダッチ方式で時間とともに条件が変化するものです。
もう一つは、固定された指値に対して外部市場価格が動き、採算ラインをまたぐものです。
【６つの候補を２つの収益源へ圧縮した図】
「見えるか」と「動けるか」は実際に確認できた
過去データだけを見ていると、
後から見れば取れそうだった
という問題が残ります。
そこで途中からは、実際に注文を収集し、
- 勝者が約定させる前に注文を観測できるか
- 観測した時点で第三者がその注文を実行可能か
を確認しました。
指値型では、この二つはかなり明確に確認できました。
つまり今回の指値型については、
見えないから取れない
でも、
仕組み上、第三者には触れないから取れない
でもありませんでした。
ここまでは通過しています。
【今回使った取引機会の確認順序】
状態遷移の強さを測ると状況が変わった
ここからが今回の本題です。
状態遷移が実在していても、それだけではbotのedgeにはなりません。
実際にどれくらいの価格差が残るのかを見ていきました。
たとえば、排他的実行期間中でも追加コストを払えば第三者が参加できる仕組みがありました。
しかし、実際に価格を付けられた10件では、追加コストを支払った後に利益が残るケースは確認できませんでした。代表例では、追加コスト前には約1.09 USDCの価格差があったものが、参加コスト約3.00 USDCを加えると約−1.91 USDCになっています。 handoff
つまり、
早く参加できること
と、
早く参加すると儲かること
は別でした。
指値型でも同じです。
外部市場価格を取得できた注文について、Uniswap V3の標準的な手数料帯を使って比較しました。
ここでいう Uniswap V3 は、Uniswap上で流動性プールを使ってトークンを交換する仕組みの一世代です。今回の検証では、注文の入力トークンから出力トークンへ直接交換する経路だけを対象にし、複数の標準的な手数料帯を試しました。
38件の実行可能な注文のうち28件について価格を取得できましたが、初期の観測範囲では利益がプラスになる注文は0件でした。
評価できた注文の最良価格差の中央値は約−544bps、上位10％付近でも約−212bpsでした。1bpsは0.01％なので、大半は「ほんの少し工夫すればプラスになる」という距離ではありませんでした。 summary
ただし、ここで「指値型にedgeはない」とは結論づけていません。
その後、実際に約定した注文の直前まで時間を広げて確認すると、1件だけ、約定直前に +0.044955bps まで価格差がプラスへ転じるケースがありました。
したがって、
状態遷移によって価格差がプラスになる現象自体は存在する
ところまでは確認できています。
ただし、+0.044955bpsは、Ethereum上で取引を実行するためのgas代や競争コストを考える前の値です。
個人botterとして取りに行くには、かなり薄い価格差です。
未解決部分は残したまま研究を止める
UniswapXについて、まだ分かっていないことはあります。
たとえば今回、指値注文の外部価格を測る主な基準として、Uniswap V3の直接交換経路を使いました。
しかし、実際の実行者が同じ経路を使っているとは限りません。
Uniswapには、V3より新しい流動性基盤である Uniswap V4 もあります。V4ではプールの仕組みや拡張方法がV3とは異なり、V3の直接交換では価格を取得できなかった注文でも、別の流動性を使える可能性があります。
また、
- 一度別のトークンを経由する複数段階の交換
- 他のDEXを利用する経路
- 実行者があらかじめ保有している資産を直接渡し、後から在庫を戻す方法
- 複数注文を一つの取引でまとめて処理する方法
なども考えられます。
今回、実際に約定した注文の中にも、最後までUniswap V3の直接交換だけでは説明できないものがありました。
したがって、
Uniswap V3で価格が取れなかった
＝
その注文に利用可能な流動性が存在しなかった
とは言えません。
ここにはまだ未解決部分があります。
ただし、未解決があることと、そこを全部解決する価値があることは別です。
現在までに確認できた価格差の強さを考えると、V4、複数段階の交換、在庫利用、他のDEXと順番に調べ続けることは可能ですが、その研究コストを正当化するほど強いsignalはまだ見えていません。
そこで今回は、UniswapXを「edgeなし」として捨てるのではなく、
現在の構造と、自分が現時点で取りに行けそうな範囲を一巡して把握した
ところで、能動的な探索を一旦閉じることにしました。
関連記事：🛠️開発記録#584「Across Relayer Botを実装直前で捨てた話」
Acrossでも同じように、「仕組みとして成立している」と「個人botterとして追う価値がある」は別でした。
今回のUniswapXでも、不明点をすべてゼロにすることを目的にはしていません。
状態遷移はedgeではなく探索地点になる
今回一番残ったのは、
State Transition ≠ Edge
という整理です。
状態遷移そのものが利益なのではありません。
むしろ、
どこで利益が発生する可能性があるのかを絞り込むための探索地点
として使う方が正確でした。
今回の経験を踏まえると、今後はprotocolを選んだ後、次の順番で見るのが良さそうです。
価値差はどこから生まれるか
↓
どの状態変化で現れるか
↓
第三者が参加できるか
↓
勝者より前に観測できるか
↓
その時点で実行できるか
↓
実市場との価格差はプラスか
↓
十分な強度・頻度・容量があるか
↓
自分のbotで実際に取得できるか
この順番なら、利益源そのものと、
- 参加条件
- 実行方法
- gas代などのコスト条件
を混同しにくくなります。
関連記事：🛠️開発記録#588「清算を探すのではなく、『清算可能になる瞬間』を追う」
清算研究でも、「清算が存在するか」ではなく、「清算できない状態から清算可能な状態へ変わる瞬間」を観測対象にしています。
UniswapXとは仕組みが異なりますが、「状態が切り替わる場所から取引機会を探す」という見方は共通しています。
現在のLifecycle Transition Edge探索モデル
UniswapXの現状把握を一巡させる
今回のUniswapX研究では、状態遷移型の取引機会が実在することを確認できました。
第三者が注文へ参加可能になる状態変化も存在しました。
外部市場価格との関係で、注文が利益にならない状態からプラスへ変わるケースも実際に確認できました。
その意味では、Acrossから持ち込んだLifecycle Transitionという見方そのものは有効でした。
一方で、状態遷移の存在を確認した後に、その強さや頻度、実行条件を見ていくと、現時点では自分が実装コストを払って取りに行きたいと思える取引機会までは確認できませんでした。
未解決部分は残っています。
Uniswap V4など別の流動性、複数段階の交換、在庫を使った実行方法などを掘れば、さらに理解できることはあるはずです。
ただし今のところ、それらを追うための追加研究コストに見合うだけのsignalはありません。
なので今回の結論は、
UniswapXにedgeが存在しない
ではありません。
UniswapXで状態遷移型の機会を一巡して観測した結果、現時点で自分が優先して取りに行くべきedgeは確認できなかった
です。
Lifecycle Transitionは「利益そのもの」を表すモデルではありませんでした。
しかし、どこを見れば取引機会が発生し得るのかを絞り込む探索モデルとしては使えることが分かりました。
この理解は、UniswapXだけでなく、今後ほかのDeFi市場を調べるときにも持ち出せそうです。
それでは、また。
一次情報・参考資料
今回のUniswapX調査で参照した、Uniswap公式の一次情報です。
- UniswapX公式リポジトリ
Reactor、Limit/Dutch/Exclusive Dutch注文、Direct Fill、Batch処理など、UniswapXの基本的な実行構造を確認できます。GitHub
UniswapX公式GitHub - V2 Dutch Order Reactor
Dutch注文の価格変化や、排他的実行期間に関係する処理をコード側から確認できます。GitHub
V2DutchOrderReactor.sol - UniswapX公式API仕様
/limit-ordersを含む注文取得APIの仕様です。Limit注文がDutch形式と同じデータ構造を使いつつ、開始額と終了額が同じ＝価格が時間減衰しない形式であることも記載されています。GitHub
UniswapX API仕様（swagger.json） - UniswapX Service公式リポジトリ
/ordersと/limit-ordersの取得方法や、注文タイプごとのサービス構造を確認できます。GitHub
UniswapX Service公式GitHub - Uniswap v4公式解説
V3とは異なる流動性基盤として、全プールを一つのPoolManagerで扱うsingleton構造や、プールの動作を拡張するhooksの考え方が解説されています。今回の記事で「V3以外の流動性経路は未検証」とした部分の背景資料です。Uniswap Labs
Uniswap v4公式解説
※記事中の注文件数、価格差、+0.044955bps などの数値は、上記一次情報そのものではなく、今回の検証で取得・集計した結果です。