> 正規版 PDF: https://blazephoenix.xyz/docs/BlazePhoenix_Whitepaper.pdf > DOI: https://doi.org/10.5281/zenodo.23084091 （寄託版、v2.3）· 全バージョン: https://doi.org/10.5281/zenodo.23084090 · 最初の寄託シリーズ（v2.2）のコンセプト DOI: https://doi.org/10.5281/zenodo.22526574 > ライトペーパー（平易な言葉による姉妹編）: https://blazephoenix.xyz/docs/BlazePhoenix_Litepaper.pdf > 検証報告書およびスワップテスト（2026 年九月）、本論文が引用する計測値: > https://blazephoenix.xyz/verification-report-2026-09.md · https://blazephoenix.xyz/swap-tests-report-2026-09.md > 本ファイルはホワイトペーパーの全文を markdown 形式で収めたものであり、 > AI による取り込みと引用のために公開されている。コンテンツのライセンス: CC BY 4.0 — 引用の際は > BlazePhoenix へのクレジットとリンクを付すこと。本論文が記述する Solidity ソースは > 2030 年まで BUSL-1.1 である。アーキテクチャを引用し、再デプロイや > クローンはしないこと。機械向けインターフェース: /llms.txt · /facts.json · /knowledge-graph.jsonld > 本文中の引用可能な列挙: イノベーション I-1–I-18、基本方程式 E1–E42 > （付録 A）および強制される不変条件 INV-1–INV-31（付録 B）。 # BlazePhoenix-Dex *英語原本 v2.3.0 の翻訳であり、英語の原文が優先する。* **見積もりこそが取引である。** **計測される取引所：見積もりと実行が一つの計算であるオンチェーン流動性アグリゲーター** *技術ホワイトペーパー — バージョン 2.3.0* | | | |---|---| | バージョン | 2.3.0 — 2026-10-14 | | 日付 | 2026-10-14 | | 著者 | Mitra | | DOI | [10.5281/zenodo.23084091](https://doi.org/10.5281/zenodo.23084091)（v2.3）· 全バージョン [10.5281/zenodo.23084090](https://doi.org/10.5281/zenodo.23084090) · 最初の寄託シリーズ（v2.2）のコンセプト DOI [10.5281/zenodo.22526574](https://doi.org/10.5281/zenodo.22526574) | | 所属 | BlazePhoenix — https://blazephoenix.xyz | | テキストのライセンス | CC BY 4.0 — クレジットとリンクを付して引用すること | | コードのライセンス | BUSL-1.1（変更日 2030-06-01）— アーキテクチャを引用し、再デプロイしないこと | | リポジトリ | `Blaze-Phoenix-Dex`、`main` の `8916545`、2026-09-24 — https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex | > 表示される価格は、あなたの取引を実行する公開コードによって、それを実行するフレームの中で計算される。手数料やフロアは誰にも — 著者自身にも — 変更できない。それらはコンパイル時に組み込まれている。 ## 十行。マーケティングなし。 1. **サーバーが経路を選ぶことはない。** 経路を実行するトランザクションそのものが、公開されたプール状態から経路を導出する。 2. **オラクルが取引の価格を決めることはない。** 価格を決めるのはプールであり、それを決済するフレームの中で読み取られる。 3. **見積もりとフロアは一つの評価器である。** 価格がずれ込む継ぎ目は存在しない。 4. **最小出力は必須である。** Router は最小出力のないスワップを拒否する。 5. **プールの主張は自由に偽造できるが、その計測された出力は偽造できない。** ルーティングは後者に基づいて動く。 6. **手数料、分配、フロアはコンパイル時に組み込まれている。** セッターは存在しない。誰も — 著者自身も — それらを動かせない。 7. **プロキシなし、アップグレード経路なし、`selfdestruct` なし、保有残高なし。** 取引と取引の間、Router から盗めるものは何もない。 8. **敵対的なプールは価格を損なわせ、その後リバートする。** フロアを下回る額を届けることは決してない。 9. **ここにあるすべての数値は、その分母と並べて示されている** — そして、それがどのように操作されうるかとも並べて。 10. **我々が運用するすべてのサーバーが今夜消えたとしても、コントラクトは明日も見積もり、ルーティングし、決済する。** 以下のすべてはその証明であり、各主張を強制するコード行と、それを制限する限界を添えている。 ## 概要 BlazePhoenix-Dex は、一つの主張の上に構築されたオンチェーン流動性アグリゲーターである。すなわち、見積もりとその実行は同一の計算である。経路は、それを実行するトランザクションの内部で、公開されたプール状態から、誰でも再実行できるステートレスなライブラリによって導出される。決済時に拘束力を持つ数値は、同じディスパッチャによって実行フレーム内で再導出される。ルーティングサービスも、価格オラクルも、キーパーも、アップグレード経路も存在しない。本論文は五つのコントラクト — Core、Hub、Solver、Router、Quoter — と、メタ方程式の演算子、すなわち八重ディスパッチャ Ω、決定論的導出 𝒟、Iron-Law フロア Φ、活力場 Ψ、反詐欺射影子 Ξ を規定する。それらの背後には一つの規律、計測学的設計がある。計測可能なすべての座標を計測し、残りを単調にすることで、偽の入力がその供給者だけを害するようにする。すべての保証は、その強制箇所と限界とともに述べられる。検証装置はその分母とともに示される。236 ファイルにわたる 1,609 件の宣言済みテスト、キュレートされたミュータント 268 件中 268 件の撃破、43 個のステートフル不変条件を狙った 15 件のミュータントのうち 14 件の検出、強度 2（63 行、258 組）および強度 3（168 行、1,636 組の三つ組）のカバリング配列、14 + 5 個のメタモルフィック関係、一致する三つのオプティマイザビルド、そして見積もりがどのように古くなるかについての 240 サンプルの研究である。十八の名前付きイノベーションが設計を支えており、メタ方程式から網羅による免疫まで、それぞれが仕様の開始前にその数学とともにカタログ化されている。Base、Ethereum、Optimism、Arbitrum で稼働している世代は V1 である。本論文は V2 を規定しており、これは対象とするすべてのチェーンにおいて、実際の流動性のフォーク上でエンドツーエンドに実行検証されている。 ## 本論文の読み方 すべてのメカニズムには、精密な文の前に平易な文が与えられる。したがって本論文は二つの深さで読める。平易な文と図はアーキテクチャを与え、精密な文、表、付録はそれを検証することを可能にする。すべての保証は一文で述べられる — 主張、それを強制する箇所、それを制限する限界である。六つの計算例が算術を手計算で追う。定積の見積もり（§4）、二つのプールにまたがる分割（§10）、二ホップ経路における Iron-Law フロア（§11）、キーから導出される Uniswap V4 プール識別子（§5）、一つの経路上の二つの手数料レジーム（§13）、そして決済の読み方（§11）である。数値は、それが計測された分母と並べて示され、それを再現するコマンドは付録 C にある。リポジトリが正典である。本文とソースが食い違う場合は、ソースが優先する。 ## イノベーション BlazePhoenix-Dex は、より優れたサーバーを持つアグリゲーターではない。**サーバーを持たない**アグリゲーターである — そしてそこに到達するには、それまで存在しなかった一連のメカニズムが必要だった。そのうち十八個が設計を支えている。それぞれについて、それが何であるか、それを定義する数学、それが取引者にとってなぜ重要か、そしてそれを完全に規定する節をここに列挙する。 ### I-1 · 見積もり ≡ 実行 **何か。** 提示される数値と、取引を拘束する数値は、一つの評価器 — Core のディスパッチャ Ω — から得られる。それは計画のために一度、決済のために実行フレーム内でもう一度実行される。システムのどこにも第二の価格モデルは存在しない。 **数学。** すべてのレッグ $\ell$ について、プランナーとエグゼキュータは同じ公開状態に対して同じ関数 $\Omega(p_{\ell}, x_{\ell})$ を評価する。経路のフロアはそのフレーム内の値から再導出され（E15、E16）、決して経路から読み取られることはない。 **なぜ重要か。** 「サーバーが言ったこと」と「チェーンがしたこと」の間の隙間に棲むあらゆるアグリゲーター攻撃のクラスは、棲む場所を失う。計測結果：ドリフトのない見積もりは、モック上でもライブの Base 上でも、**64 回中 64 回**、予測どおりの値で正確に決済される。（§3、§11、§12） ### I-2 · オンチェーンソルバー、無料で呼び出し可能 **何か。** `Solver.findBestRoutePlan(tokenIn, tokenOut, amountIn)` は `view` 関数である。誰でも無料の `eth_call` によってトラストレスな最良経路を得られる — API キーも、リレイヤーも、署名も不要である — そして `swapBestExactIn` は一つのトランザクション内で求解と決済をアトミックに行う。 **数学。** Solver 全体は、経路空間 $\mathcal{R}_{\mathcal{D}}$ 上でのメタ方程式（E1）の制約付き最大化であり、決定論的なパイプラインとして実行される：導出 → 順位付け → プローブ → フィルタ → 割り当て → ゲート → フロア。 **なぜ重要か。** 業界のルーティング知能は、監査可能な行数を持たないクローズドなサーバー上で動いている。我々のものは 29,183 バイトの公開バイトコードであり、誰でも再実行して同じ答えを得られる。（§2、§10、§11.1） ### I-3 · メタ方程式 **何か。** アグリゲーター全体を、一つの式として書いたもの。 **数学。** $$R^{\star} = \arg\max_{R}\ \mathrm{net}(R)\cdot\prod_{\ell \in R}\hat{\Psi}(p_{\ell})\cdot\mathbf{1}[\mathrm{net}(R)\ge\Phi(R)]\cdot\Xi(R)$$ **なぜ重要か。** 積の形は安全性の性質である。ただ一つの因子の失敗 — ゼロを見積もるレッグ、信用のないプール、フロアを下回る経路、敵対的なフック — が、その経路のスコアを厳密にゼロにする。ソフトなペナルティも、調整可能な重みも、すり抜けるニアミスの経路もない。（§3） ### I-4 · 八重ディスパッチャ Ω **何か。** 六種類のベニュー — Uniswap V2、V3、V4、Algebra、Solidly stable、Solidly volatile — が、一つの属性テーブルと一つのディスパッチャの背後で四つの数学的ファミリーに集約される。 **数学。** 定積 $y = \lfloor x(\mathrm{BPS}-f)\,r_{\mathrm{out}} / (r_{\mathrm{in}}\mathrm{BPS} + x(\mathrm{BPS}-f)) \rfloor$（E2）；Q64.96 における集中流動性 $\sqrt{P}' = L\sqrt{P}/(L + x_{f}\sqrt{P}/Q_{96})$、$y = L(\sqrt{P}-\sqrt{P}')/Q_{96}$（E3）；危険な積はすべて 512 ビットの `mulDiv` を通して因数分解される。 **なぜ重要か。** 断片化は数学の問題ではなく、言語の問題であることがわかる。ファミリーごとに一つの監査済み公式が、すべてのチェーン上のすべてのベニューの価格を決める。既知のファミリーの新しいフォークはテーブルの一行であり、新しいコードではない。（§4） ### I-5 · 決定論的導出 𝒟 **何か。** プールは問い合わせて得るものではなく、**計算される**ものである。Hub はファクトリー、ペア、init-code ハッシュから各候補アドレスを導出し、ランタイムバイトコードを持つアドレスだけを受け入れる。 **数学。** $\mathrm{pool} = \mathrm{addr}_{20}(\mathrm{keccak256}(\mathtt{0xff}\,\Vert\,\mathrm{origin}\,\Vert\,\mathrm{salt}\,\Vert\,\mathrm{initCodeHash}))$（E8）。 **なぜ重要か。** ファクトリーの答えは偽装されうるが、算術は偽装されえない。探索には候補ごとの外部呼び出しが一切かからず、すべての EVM チェーンで同一に動作し、プールマネージャーとファクトリーはハードコードされることなく、ランタイム設定として扱われる。（§7） ### I-6 · Uniswap V4、完全にフレーム内で **何か。** V4 プールにはアドレスがなく、呼び出しにも応答しない。BlazePhoenix はそれらの ID を導出し、PoolManager のストレージに対して各 ID が稼働中であることを**証明**し、`extsload` を通じて価格と流動性を読み取り、最大十六区間にわたってティックブックを辿り、シングルトンを通じて決済し — ネイティブ ETH も含めて — 、算術だけでフックを審査する。 **数学。** ストレージの基点 $\mathrm{slot} = \mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6))$。$\sqrt{P}$ はビット [0,160) に、LP 手数料は [208,232) に置かれる（E4）；フックゲート $(\mathrm{uint160}(\mathrm{hook})\,\&\,\mathtt{0x3FFF})\,\&\,((1\ll3)\mid(1\ll2)) \ne 0 \Rightarrow$ 拒否、呼び出しは行わない（E18）；動的手数料ゲート E19。 **なぜ重要か。** ベニューからの答えを一つも信頼することなく、V4 を導出し、証明し、価格を付け、審査し、決済する — アグリゲーターが持ちうる最も深い V4 統合であり、そのすべてがオンチェーンで検証可能である。（§5） ### I-7 · Solidly stable ソルバー **何か。** Aerodrome 系および Velodrome 系のベニューが用いる四次の stable 曲線に対する、厳密でフェイルクローズドなソルバー。 **数学。** 不変量 $k(x,y) = x^{3}y + xy^{3}$（E5）。小数を 18 桁に正規化した後（E7）、テイカーに不利な一単位の補正と 64 ステップの上限を伴う有界ニュートン反復によって解かれる（E6）。 **なぜ重要か。** ステーブルコインやリキッドステーキングのフローはこれらの曲線に集中しており、そこでは入力のほぼ全額が出力として届けられる。ソルバーはそれらを厳密に見積もり — 上界を証明できない場合には、推測ではなくゼロを返す。（§6） ### I-8 · モノスロット **何か。** プールのルーティング状態全体 — アクティビティ、深さクラス、手数料、種類、フラグ、新しさ — を**一つの 256 ビットワード**に詰め込んだもの。 **数学。** $s = a \,\vert\, f\!\ll\!8 \,\vert\, k\!\ll\!32 \,\vert\, r\!\ll\!40 \,\vert\, (c\wedge\mathtt{0xFFF})\!\ll\!48 \,\vert\, b\!\ll\!60 \,\vert\, \dots \,\vert\, B_{\mathrm{last}}\!\ll\!224$（E9）。 **なぜ重要か。** 一回の `SLOAD` でプールを順位付けし、一回の `SLOAD` に続く一回の `SSTORE` でそれを最新に保つ。そしてこのワードには価格が含まれないため、レジストリのメモリは構造的に取引の価格を誤ることができない。（§8） ### I-9 · 自己修復レジストリと活力場 Ψ **何か。** プロトコルは、流動性を取引することによって流動性を学習する。ペアごとに十六のスロット、実際のスワップから獲得される適応度スコア、算術による減衰、そして**ペア証明**：プールは保存される前に、自らがどのトークンを取引するかを証明する。 **数学。** $\Psi = V \cdot 2^{b} \cdot (1 + 0.25\,\mathbf{1}_{\mathrm{bridge}}) \cdot (1 + 0.05\,\mathbf{1}_{\mathrm{conc}})$（E10）；アクティビティは沈黙 24,576 秒ごとに半減し、$V = \mathrm{swapCount} \gg \lfloor (t - t_{\mathrm{last}})/24{,}576 \rfloor$（E11）；深さクラス $b = \min(15, \lfloor \log_{10}(d/10^{15}) \rfloor)$（E12）；新参者は、マージンを超えた場合にのみ最弱のものを置き換える、$2^{b(d_{\mathrm{new}})} > \Psi_{\mathrm{worst}} + \lfloor \Psi_{\mathrm{worst}}/4 \rfloor$（E13）。 **なぜ重要か。** キーパーも、cron も、どのプールが重要かを決めるキュレーターもいない。レジストリは、ユーザーがすでに送っていたフローから自らを修復する。（§9） ### I-10 · 資本に錨を下ろした分割 **何か。** 価格の質とプールの深さは別々に計測される。微小なプローブが各プールの限界レートを計測し、資本に錨を下ろした**信頼帯**が外れ値を捨て、生き残ったプールが計測された深さに比例して注文を分け合う。 **数学。** 中心 = 深さ加重中央値 — $\sum_{j \le i} d_{j} \ge \lceil \sum d / 2 \rceil$ となる最初の $r_{i}$ — であり、帯は $[0.95, 1.05]\times$ 中心である（E25）。分割は $\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}}\cdot(1 + 25/10^{6})$ の場合にのみ生き残る（E14）。 **なぜ重要か。** アンカーを動かすには、攻撃者はペアの実際の流動性の半分を上回る預け入れをしなければならない — それはリスクにさらされる資本であり、無料の寄付ではない。恒常的な保証：**分割が最良の単一プールより少なく支払うことは決してない。** Base 上での網羅的グリッドに対して計測すると、Solver の経路は最適から 0.13 bps 以内に収まる。（§10） ### I-11 · Iron-Law フロア Φ **何か。** 計測された価格インパクトと経路の集中度から、**オンチェーンで、実行時に**再導出される最小出力 — 呼び出し元が与えたいかなるものからも独立している。 **数学。** $\mathtt{floorBps} = \max(9{,}600 - \mathtt{legShv} - \min(\delta, 10^{4}) - \sigma_{\ln}/10^{14},\ 8{,}000)$（E15）。ここで集中度による削減は $\mathtt{legShv} = \sum_{\mathrm{hops}} \lfloor 200\,((\sum a)^{2} - \sum a^{2})/\sum a^{2} \rfloor$（E23）である；送付額は $\mathtt{effMin} = \max(\mathtt{userMinOut},\ \mathtt{route.singleOutFloor},\ \lceil \mathtt{finalHopQuote}\cdot\mathtt{floorBps}/10^{4}\rceil)$ を満たさなければならない（E16）。 **なぜ重要か。** 呼び出し元のデータは保護を強めることしかできず、決して弱めることはできない。深さの 1 % の取引において、フロアはサンドイッチを取引額の約 2.7 % に制限し、それを超えるものは**拒否する** — その縁を越えると、攻撃者の往復取引は損失に転じる。（§11.5、§14.3） ### I-12 · あらゆる継ぎ目での計測 **何か。** Router は送金が行われたと信じることはなく、計測する。すべての引き出し、各ホップの到着、すべての送付は、スワップの最初の命令から受取人のウォレットに至るまで、実際の残高差分である。 **数学。** 各ホップは計測された到着額に対して再スケーリングされる。定積レッグ上の fee-on-transfer トークンは、プールが実際に目にする差分に基づいて価格付けされる。それは、プール自身の不変量が検査する正確な量である。 **なぜ重要か。** 課税し、リベースし、あるいは虚偽の報告をするトークンも、Router に保有していないものを約束させることはできない — そして Router はトランザクション間で**何も保有しない**（INV-1）。（§11.2、§11.4） ### I-13 · 単一コールバックの原則 **何か。** 一つの `fallback` が、V3 型のあらゆるベニュー — Uniswap V3、Algebra、Pancake V3、Sushi V3、集中流動性型の Solidly フォーク — のフラッシュ会計コールバックに応答し、実行中のレッグのコンテキストは EIP-1153 のトランジェントストレージに保持される。 **数学。** 支払うべきトークンは二つの差分の符号から読み取られる。支払いは三通りに制限される — コミットされたプールに対してのみ、レッグの実行中のみ、そしてレッグに記録された予算を決して超えない（INV-10）。 **なぜ重要か。** 小さく、三重に保護された一つのエントリポイントが、フォークごとのコールバックの寄せ集めを置き換える — バイトコードが減り、攻撃面が減り、検証すべきものは一つになる。（§11.4） ### I-14 · 余剰ルールと網羅による免疫 **何か。** コンパイル時に組み込まれた 0.28 % の手数料であり、Router が保有する最初のブリッジコインに対して一度だけ課される — そして**見積もりと送付額の差に応じて増える手数料項は存在しない。** **数学。** $\mathrm{fee} = \lceil 28 \cdot \mathrm{base} / 10^{4} \rceil$、分配は $t_{1} = \lfloor 3{,}000\cdot\mathrm{fee}/10^{4} \rfloor$、$t_{2} = \mathrm{fee} - t_{1}$（E17）；レジーム述語 $\mathrm{feeHop} = \min\{h : \mathrm{isBridge}(\mathrm{hops}[h].\mathrm{tokenIn})\}$（E26）。すべてのブリッジを避ける経路はすべてのホップで支払うため、ダストの接頭部が手数料を持ち去ることはできない。 **なぜ重要か。** プールが見積もりを上回って届けたものはすべて、あなたに全額届く。手数料を取引者に対して引き上げることも、優遇されたインテグレーターのために引き下げることもできない — その鍵を持つ者は誰もいない。（§13） ### I-15 · バイト–ガス交換レート ρ* **何か。** Router の四つの扉は、インターフェースに仕立てられたアフィンコストモデルである。オンチェーンで求解するか、事前に求解された経路をカルデータで運ぶか — そのチェーンでより安い方を選ぶ。 **数学。** $p_{\mathrm{byte}} < \rho^{*}$ のとき、かつそのときに限り、経路をカルデータで運ぶ。ここで $\rho^{*}$ は経路の形状に応じてバイトあたり 66.9–105.5 ガスと計測されている（E22）。 **なぜ重要か。** すべてのチェーンには、バイトの価格と計算の価格がある。BlazePhoenix はその間の交換レートを計測し、取引者により安い扉を渡す。（§17.6） ### I-16 · 反詐欺射影子 Ξ **何か。** V4 フックが差分を変更する権限を宣言しているプールは、フックが一度も呼び出されることなく、**順位付けの前に**候補集合から除去される。 **数学。** メタ方程式における $\Xi(R) \in \{0,1\}$ であり、フックのアドレスに対する E18 のビット判定によって評価される。 **なぜ重要か。** 敵対的なフックには嘘をつく機会すら与えられない。そもそも問い合わせられないからである。三つの独立した層 — アドレスビット、codehash で固定された許可リスト、そして Ξ — が、取引者と悪意あるベニューの間に立ちはだかる。（§5.5、§14.2） ### I-17 · 一方通行の扉 **何か。** 管理権限は、バイトコードの中で不可逆的に終わる。`renounceControl` は、いかなるコードパスも解除できないフラグを書き込む。その後に残るのは、追加のみ可能なキュレーター層だけである。 **なぜ重要か。** 「我々は触らない」は「我々は触れない」になる。手数料、分配、フロアは最初から設定可能ではなかった（INV-4）。扉が閉じた後は、それ以外のものも何一つ設定できない。（§14.7） ### I-18 · 計測学的設計と公表された分母 **何か。** 上記すべての背後にある規律 — 計測可能なすべての座標を計測し、残りを単調にすることで偽の入力がその供給者だけを害するようにする — と、**すべての数値をその分母と並べて**報告する検証装置。 **数学。** 236 ファイルにわたる 1,609 件の宣言済みテスト；キュレートされたミュータント 268 件中 268 件を撃破、それぞれが失敗しなければならない一つのテストと対になっている；レジーム因子に対する強度 2（258 組中 258 組）および強度 3（1,636 組中 1,636 組の三つ組）のカバリング配列；14 + 5 個のメタモルフィック関係；ビット単位で一致する三つのオプティマイザビルド；Halmos と Certora Prover による記号的証明。 **なぜ重要か。** ほとんどのプロジェクトはテスト件数を公表する。BlazePhoenix は、その証拠がどのように操作されうるか、そして何に対して計測しているかを公表し — すべてのコミットでそれを再計算する。（§2.3、§15） ### スコアボード | 計測された性質 | 結果 | |---|---| | ドリフトのない見積もりのうち、予測どおりの値で正確に決済されたもの（240 サンプルの研究） | **64 / 64** | | ベニューの異常 × 扉の組み合わせのうち、決済されるか我々のセレクタで拒否されるもの — 第三の道は決してない | **20 / 20** | | 撃破されたキュレート済みミュータント | **268 / 268** | | 拒否が厳密なコードによって実行検証されている制御アクション | **31 / 31** | | 二箇所で計算され、名前付きテストによって結び付けられている量 | **7 / 7** | | 構成により実行検証されたレジーム因子値のペア | **258 / 258** | | 構成により実行検証されたレジーム因子値の三つ組 | **1,636 / 1,636** | | 見積もり数学のオプティマイザビルドのうち一致するもの（runs 1 / 300 / 20,000） | **3 / 3** | | 四つのチェーンにおけるプレビュー → 送付額 | **0–1 bps** | | Solver の経路と Base 上での網羅的グリッドとの比較 | **0.13 bps 以内** | | 深さの 1 % の取引においてフロアが許容し、その後拒否する最大のサンドイッチ | **≈ 2.7 %** | | クレジットされた外部セキュリティ研究者 · 重大度 Critical の発見 | **25 · 0** | ## 目次 - イノベーション（I-1–I-18）とスコアボード - §1 問題：見積もりは他者が計算した約束である - §2 答えと規律：不変条件駆動設計と計測学的設計 - §3 メタ方程式と依存関係の予算 - §4 八重ディスパッチャ Ω — 種類、ファミリー、閉形式 - §5 Uniswap V4 のエンドツーエンド — シングルトン、存在証明、手数料ゲート、フック - §6 Solidly ソルバー - §7 決定論的導出 𝒟 - §8 モノスロット - §9 自己修復レジストリと活力場 Ψ - §10 ルーティングと分割アロケータ - §11 実行層と Iron-Law フロア Φ - §12 見積もりのインターフェースと、見積もりはどのように古くなるか - §13 手数料ポリシー：二つのレジームと余剰ルール - §14 セキュリティモデル - §15 計測された検証装置 - §16 アーキテクチャとサイズ - §17 計測された性能 - §18 骨格まで削ぎ落とした DEX - §19 デプロイ状況 - §20 トークン — BZPX - §21 研究プログラムとセキュリティ記録 - §22 信頼しなければならないもの、そしてその必要がないもの - §23 関連研究 - §24 結論 - §25 ステーキング V4：設計 - 付録 A · 基本方程式（E1–E42） - 付録 B · 不変条件（INV-1–INV-31） - 付録 C · 再現コマンド - 用語集 - 参考文献 --- ## §1 問題：見積もりとは、他者が計算した約束である 二十のディーラーがある街で車を売ることを想像してほしい。優れたブローカーは二十すべてを回り、最良の価格を見つけ、場合によっては売却を二つのディーラーに分割する。オンチェーンの「ブローカー」の多くは、自前のデータベース — 古くなっている可能性がある — で価格を確認し、その結果を見せる。彼らが二十すべてを確認したこと、あるいは最良のものを見せたことを、あなたは検証できない。検証できるのは、彼らがこれまでのところ誠実であったということだけである。 我々がドキュメントを読んだすべてのアグリゲーター — 1inch、CoW Swap、Velora（ParaSwap）、KyberSwap、OpenOcean、Jupiter、UniswapX（2026-09-07 時点のドキュメントによる） — は、この方式で動作する。すなわち、サービスがオフチェーンで経路を計算し、コントラクトは渡された経路を実行する。コントラクトは選ばない。検査するだけである。これは健全なエンジニアリングであり — それらのシステムが高速かつ安価である理由でもある — 、めったに率直には語られない一つの帰結を伴う。**そのようなシステムが行える最も強い主張は、その運営者が誠実であるということである。** その乖離は、通常は詐欺ではない。それは三つのありふれた源から生じるドリフトである。見積もりは、トランザクションが取り込まれる前に動いた準備金に対して計算されていた。探索は、運営者の予算が許す範囲でしか網羅的でなかった。そして見積もりから約定までのあらゆる補正 — スリッページのバッファ、途中で取られる手数料 — は、ユーザーが読んでいないコードによって、ユーザーが再現できない数値に適用された。そのいずれも悪意を必要としない。そしてそのすべてが目に見えない。 ### §1.1 断片化は現実であり、見かけより浅い 最良の価格を求めるトレーダーは逆説に直面する。流動性は存在し、数十の分散型取引所に分散している。それぞれが独自のプールコントラクト、独自の価格曲線、独自のアドレス体系を持つ — しかし、そのすべてを保持する単一のベニューは存在しない。最良の実行の代償とは、あらゆる取引所の言語を同時に話すコストであり、表示された価格と実際に成立する取引とのあいだに立つあらゆる翻訳者を信頼するコストである。 既存の答えは、ベニューを一つずつ統合する。Uniswap 用のコネクタ、Solidly フォーク用の別のコネクタ、集中流動性の各変種用のさらに別のコネクタ — それぞれが独自の見積もり、独自のアドレス参照、独自の実行を持つ。統合面はベニュー数に対して線形に増大し、すべてのコネクタは、価格設定の欠陥や、見積もられた数値と実行された数値との無言の不一致が生じる新たな場所となる。 断片化は見かけより浅い。表面上の多様性の下で、オンチェーン流動性の大半を保持する自動マーケットメイカーは、少数の不変条件に支配されている。定積プールは $x \cdot y = k$ に従う。集中流動性プールは、区分的に一定のアクティブ流動性の上で、固定小数点の平方根価格を追跡する。Solidly 系は、ステーブルペアでは四次式 $x^{3}y + xy^{3} = k$ に、ボラタイルペアでは定積に従う。形は一握りであり、六十ではない。 形が少なければ、集約のコストはベニュー数とともに増大する必要はない。形の数とともに増大すればよい。各形を一度だけ正しく実装し、すべてのベニューを適切な形にディスパッチするプロトコルは、統合面を線形から定数へと縮約する。ベニューの追加はエンジニアリングではなくなり、設定となる。種別とアドレス導出モードを割り当てれば、既存の数学がそれに価格を付け、既存のルーターがそれを決済し、既存のレジストリがそれを学習する。 **設計の中心的主張：** BlazePhoenix がルーティングに用いるすべてのベニューは、少数の出力関数族のいずれかのパラメータ化である — 六種別の分類体系（§4）にわたる四つの実働族 — それらは単一のステートレスなライブラリに一度だけ保持され、決して再定義されない。ベニューの追加とは、種別と導出モードを割り当てることであり、新たな価格設定コードを書くことではない。 ### §1.2 オフチェーンという抜け道 主流のアグリゲーターアーキテクチャは、サーバー群で経路を見積もり、オフチェーンのソルバー間でオークションを行い、キーパーボットでプールの流動性をインデックス化し、その結果を薄いオンチェーン決済コントラクトに送る — そのコントラクトは、管理者キーでロジックを丸ごと差し替えられるアップグレード可能なプロキシの背後にあることが多い。Web サービスが価格を生成し、データベースが流動性グラフを保持し、特権的な運営者がルールを変更でき、チェーンは、ユーザーが見ることも検証することもできないソフトウェアによって別の場所で下された決定の、決済の場となる。 この構成は、この技術が取り除くはずだった信頼を、まさにそのまま再導入する。オフチェーンの見積もりはオンチェーンの約定と異なりうるが、ユーザーはそれが異なるべきでなかったことを証明できない。キーパーが沈黙すれば、ルーターは盲目になる。プロキシ管理者は、一つのトランザクションで、誠実なコントラクトを敵対的なものに変えることができる。 | 論点 | オフチェーンで解くアグリゲーター | BlazePhoenix-Dex | |---|---|---| | 見積もり | オフチェーンのサーバーまたはソルバーオークション | プレビューとフレーム内実行が共有する、一つのオンチェーンディスパッチャ | | 流動性の発見 | キーパーボットがインデックス化し、リストを送り込む | 自己修復レジストリ — 取引することによって学習される流動性 — と決定論的発見 | | 経路選択 | 独自のオフチェーン最適化器 | オンチェーンの Solver。公開状態から誰でも再現可能 | | アップグレード面 | 管理者が制御するプロキシ | ステートレスな Core。プロキシなし、アップグレード経路なし、`selfdestruct` なし | | 資金に対する特権的権限 | しばしば存在する | Router は静止時に何も保持しない。ユーザーの元本を動かす関数は存在しない | | クロスチェーンの一貫性 | チェーンごとのバックエンドロジック | チェーンごとに一つのバイトコード | | 信頼の前提 | 運営者の誠実さ | ユーザー自身の最小出力。コントラクトはそれをゼロとして受け入れることを拒否する | BlazePhoenix は、この取り決めの両半分を拒否する。統合面が線形ではないことを示すことで線形の統合面を拒否し、決定全体 — 発見、見積もり、スコアリング、ルーティング、決済 — を、誰でも読めて、どのチェーンでも同じ答えを出すコントラクトの内部に留めることで、オフチェーンという抜け道を拒否する。コストは現実のものである。集中プールをオンチェーンで見積もることは、データベースから読むより高くつく。そのコストで買えるのは、一つの類の障害の除去である — サーバーが約束したものとチェーンが届けたものとの間の、無言で証明不能な乖離である。以下に続くすべての設計判断は、このトレードオフの一例である。 ## §2 答えと規律 **選ぶものが、取引するものである。** BlazePhoenix-Dex には、六つの値 — 二つのトークン、数量、あなたの最小出力、受取人、期限 — を受け取り、経路を実行するトランザクションの内部で、公開状態であるプールの準備金からその経路を算出するエントリーポイントがある。どのベニューを使うか、それぞれにいくら流すか、どの順序で流すか、である。経路は公開コードによって公開状態から導出されたので、誰でもそれを再導出できる。決済時に拘束力を持つ数値は、同じディスパッチャによって、同じフレームで、同じライブ状態から再導出されるので、見積もりと実行は突き合わせるべき二つの成果物ではない。それらは一つの計算であり、プレビューと約定を隔てるのは時間であって、第二のモデルではない。 さらに三つのエントリーポイントは、より安価な道を望み、自らの答えを供給する意思のある呼び出し元のために、事前計算された経路を calldata から受け取る。同じ計測、フロア、決済の仕組みが四つの扉すべてに適用される（§11）。我々はオフチェーンの手法が間違っていると主張しないし、より安価であるとも主張しない。我々が主張するのは異なる類の保証 — 約束されたものではなく監査可能なもの — であり、それを望み、そのためにガスを支払うユーザーのためのものである。 この設計における四つの判断は、我々が確認できた限り、この分野では珍しいものであり、それぞれをその誠実さを保つ境界とともに述べる。 - **アドレスは取得されるのではなく、導出される。** ベニュー族のデプロイが再現可能な場合には、プールのアドレスはファクトリのストレージから読み取られるのではなく、CREATE2 の算術 — 三つの公開入力から誰でも再検証できる定理 — によって計算される。その算術が健全でない場合、プロトコルは問い合わせを行い、問い合わせを受けたプールは掲載される前に自らのペアを証明する（§7）。 - **プールのルーティング状態は一ワードである。** モノスロットは、ベニューの順位付けに必要なすべてを単一の 256 ビットのスロットに詰め込み、意図的に価格を一切含まない。そのため、レジストリの記憶はどのプールに問い合わせるかに偏りを与えうるが、取引に価格を付けることは構造的に不可能である（§8–§9）。 - **フロアは、実際に起きた取引から再導出される。** Router は、実行フレームの内部で各レッグの実現インパクトと各ホップの実現集中度を計測し、それらの計測からフロアを再計算する。そのため、呼び出し元が供給するフィールドは保護を強めることはできても、緩めることは決してできない（§11）。 - **アドレスを持たないベニューでは、発見はデプロイヤーに依存しない。** Uniswap V4 シングルトンについては、プール識別子は公開パラメータから導出され、その後マネージャー自身のストレージに対して実在が証明される — 他の誰にも書けない証明である（§5）。 これらのいずれも、あらゆるアグリゲーターが抱える残余 — 署名から取り込みまでの間に状態が動きうること — を取り除くものではない。だからこそ、あなた自身が設定する最小出力は必須であり、最終的なものである。すべての扉は、トークンが動く前に、ゼロの最小出力を `RouterE(10)` で拒否する。 ### §2.1 不変条件駆動設計 この答えの背後には方法がある。我々はそれを不変条件駆動設計と呼ぶ。プロトコルは一連の操作としてではなく、到達可能なすべての状態で成り立たねばならない性質の集合として仕様化され、コードはそれらの性質が構造的になるように — プログラマーの注意深さではなく、コードの形によって強制されるように — 組織される。 ほとんどのソフトウェアは命令的に書かれ、正しさは創発的な希望にすぎない。通常のソフトウェアではそれで許容される。障害は回復可能だからである。公開ブロックチェーンでは、そのどれも成り立たない。コードはデプロイ後に不変であり、価値を直接保管し、あらゆる端が狙われる敵対的環境で実行され、そして一つの算術上の誤りは、クラッシュではなく不可逆な損失となる。 不変条件とは、システムがどのようにその状態に到達したかに関わらず真である性質である。*Router はトランザクション間で資金を保持しない。* *レジストリのペアは最大十六のプールを保持し、退去は最も適合した十六を残す。* *プロトコル手数料を支払わなかった決済は存在しない。* 三つの原則が、このような言明を中心に据える。 | 原則 | 言明 | 現れる場所 | |---|---|---| | 信頼せず、計算せよ | 値を導出または証明できる場合は、決して取得したり仮定したりしない。 | 𝒟 がプールのアドレスを計算する。Router は計測された残高から、手数料基準とフロアをフレーム内で再導出する。 | | 唯一の真実の源 | すべての数学的プリミティブは一度だけ定義されてインポートされ、決して再記述されない。 | Core がすべての価格設定、導出、フロア、スコアリングの数学を保持する。Hub、Solver、Router、Quoter はそれをインポートし、いずれもプリミティブを再定義しない。共有量レジスタ（§15）は、二つの生成元を持つすべての量を等級付けする。 | | フェイルクローズ | 性質を保証できないときは、推測で進むのではなく停止する。 | Solver は捏造した経路ではなく、経路なしを返す（`SolverE(5)`）。ステーブルソルバーは飽和した見積もりではなくゼロを返す（§6）。レジストリの整合性ガードは、状態が書き込まれる前に、構造的に不可能なベニューを revert させる（§9）。 | 第四の原則は保管を律する。**資金への特権的経路は存在しない。** Solver と Quoter は読み取り経路のコントラクトである。Router は資金を動かす唯一のコントラクトであり、ユーザー自身が設定した制約の下でアトミックに動かす。そしてそれを転用しうるあらゆる管理権限は、一方通行の扉（§14）を通じて永久に放棄できる。 ### §2.2 なぜこの規律がこの媒体に適合するのか 命令的コードを危険にする環境の各性質は、不変条件駆動のコードが利点に変える性質である。不変性は証明可能性に報いる。デプロイ済みのコードは修正できないので、事前の証明の価値はそれに応じて高い。コンポーザビリティは唯一の真実の源に報いる。価格関数は、その作者が予期しなかったボールトの内部で呼び出されるかもしれず、Core が一つであれば、すべての呼び出し元が同じ答えを得る。敵対性はフェイルクローズに報いる。攻撃者に必要なのは作者が考慮しなかった一つの経路だけであり、前提が崩れたときに停止するシステムは、攻撃者から即興の余地を奪う。賭けられた価値は可読性に報いる。一つの数学的コアの上の五つの名前付き演算子として表現されたプロトコルは、それを書いていない人々が一行ずつ検査できる。 この規律は無償ではなく、そのトレードオフは意図的なものである。オーバーフローの上界を証明するには、それを仮定で片付けるより時間がかかる。すべての積を全精度の乗除算に通すことは、素朴な乗算ならかからないガスを要する。アドレスを導出することは、取得するなら省けるエンジニアリングを要する。それは、デプロイ後には回復できない障害を除去することと引き換えに、デプロイ前により多くのコストを払うということである。 ### §2.3 計測学的設計：一つの射、計測された座標、単調な入力 不変条件駆動設計は、何が常に成り立たねばならないかを述べる。さらに三つの規則が、それを支えるコードがどのように*形作られる*かを述べ、それらは合わせて、この分野で他に名付けられているのを我々が見つけていない方法を形成する。そこで本稿はそれを名付ける。**計測学的設計** — コントラクトを*計測器*として構築することである。その主題を一行で言えば、*信じるコードは攻撃面であり、計測するコードは防御である。* **一点で評価される一つの射。** アグリゲーターはベニューごとの統合を含まない。それは、空間（ベニューの形、チェーン、手数料モデル）の一点における、一つのパラメータ化された価格設定射の評価である。分岐として表現すれば、それぞれ独自の手数料慣行を持つ半ダースほどの稼働中のベニュー種別は、数百のペアごとの組み合わせへと乗算的に増える — 乗算的なバイトコード、乗算的な監査面、乗算的なドリフト。射として表現すれば、同じ網羅範囲は一握りの*状態の形*、一つのステートレスな Core、ネイティブ単位で運ばれる手数料慣行、そして登録テーブルとなり — バイトコードは*加法的に*増える。新しいベニューは分岐ではなく行である。この縮約を守る規則は `KIND → SHAPE` である。ベニュー族は*データ* — 既存の形に割り当てられた種別と導出モード — であり、敵対的入力が選択できる新たなコード経路では決してない。Core は形をビットテーブル（`THETA_ATTR`、§4）として記述するので、「この種別は準備金を読むか？」はシフトと AND であり、誰かが忘れうるデフォルト分岐は存在しない。この縮約にはブレーキがある。単一の普遍的公式は存在しない。二つの閉形式 — 定積と集中流動性 — は厳密に評価され、複製が負債となるあらゆる曲線については、ベニュー自身のバイトコードに問い合わせる（§6）。射が縮約するのは*帰属*であり、*検証*では決してない。 **座標は計測され、決して信じられない。** オンチェーンの計測が存在する場合、コントラクトはモデル化された値、名目値、呼び出し元が供給した値に基づいて行動することは決してない — そして、パーミッションレスなデータがどのコードを実行するかを選ぶことも決してない。信頼されない当事者が供給するデータ — 経路、申告された手数料、主張された深さ、プール id — は*座標*である。すなわち計測器を向ける場所であり、コントラクトはその後それを自ら読み取り、フェイルクローズする。本稿のあらゆる荷重を担う防御はその一例である。名目数量の代わりに計測されたプル後の残高（§11）、calldata の代わりに計測された残高差分から取られる手数料基準（§13）、寄付で水増しできる生の残高ではなく、計測された深さの深さ加重中央値に錨を下ろした信頼帯（§10）、計測された保有量に対して切り詰められる容量クランプ（§10）、センチネルを信頼する代わりにライブ状態を読む V4 手数料ゲート（§5）、シングルトン自身のストレージを読む存在証明による発見（§5）、そして発見が掲載する前に自らの `token0`/`token1` を証明する、問い合わせを受けたプール（§7）である。リポジトリは、この規則の下で呼び出し元が書き込めるすべてのフィールドの分類を公開している。23 フィールドのうち、14 は観測に対して確認され、5 は誘導用、4 は理由付きで申告されたものである（§15）。 **計測が終わるところで、単調性が始まる。** 計測も再導出もできない数値がある — 呼び出し元のフロア、呼び出し元が申告したスケール、呼び出し元自身の最小出力である。これらについて、設計はその数値を受け入れ、嘘をつけば嘘をついた者だけが損をするように関数を形作る。経路の表明されたフロアは、強制されるフロアを*引き上げる*ことしかできない（§11）。レッグの表明された見積もりは、計測された見積もりを下回る場合、計測された見積もりまで引き上げられる（§11）。申告されたスケーリングは計測された到着量によって上限が設けられるので、過大申告によって存在しなかった資金をルーティングすることはできない。そして、プロトコルが選ぶことのできない唯一の数値 — あなたの最小出力 — は必須である。単調な入力には信頼が不要なので、それはオフチェーンで、誰によっても、無償で計算され、calldata で運ばれうる — これこそが、このプロトコルが*信頼をオフチェーンに移すことなく*作業をオフチェーンに移す方法であり、Router が一つのソルビング扉と三つの calldata 扉を同じ保証で提供できる理由である。 計測学的設計は成果物を取り巻くエンジニアリングも律する。計測器はその校正以上には良くならないからである。安全余裕は計測されたハザードから値付けされる。レッグの損益分岐点が 3 ppm と計測されたので、分割ゲートは 25 ppm に置かれている（§10）。計測されたハザードを 27× 上回っていた計画用ヘアカットは廃止された（§10）。外部との比較は、その手法の誤差範囲を伴うか、さもなければ掲載されない（§17）。そして計測装置そのものも計測される。各保証用計測器は、その数値が掲載される前に、別の経路ですでに知られていた欠陥に対して校正された（§15）。これが理論のすべてであり、本書の残りはその実践である。 ## §3 メタ方程式と依存予算 アグリゲーター全体は、一つの式の最大化として読むことができる。入力トークン $t_{\mathrm{in}}$、出力トークン $t_{\mathrm{out}}$、数量 $x$ が与えられると、Solver は、実行可能性のフロアと反詐欺ゲートを制約として、許容される経路の中から正味受取価値を最大化するものを探索する。 $$ R^{\star} \;=\; \mathrm{arg\,max}_{\;R \,\in\, \mathcal{R}_{\mathcal{D}}(t_{\mathrm{in}},\, t_{\mathrm{out}},\, x)} \;\; \mathrm{net}(R)\cdot\prod_{\ell\in R}\hat{\Psi}(p_{\ell})\cdot \mathbf{1}[\,\mathrm{net}(R) \ge \Phi(R)\,]\cdot \Xi(R) $$ ^e1 $$ \mathrm{net}(R) \;=\; \sum_{\ell\in R}\Omega(p_{\ell},\, x_{\ell})\;-\;f_{\mathrm{proto}} $$ ここで $\mathcal{R}_{\mathcal{D}}$ は、決定論的導出 𝒟 とレジストリによって特定されたプール上の経路空間である。$\Omega(p_{\ell}, x_{\ell})$ は、プール $p_{\ell}$ に $x_{\ell}$ を流し込むレッグ $\ell$ に対するディスパッチャの出力である。$f_{\mathrm{proto}}$ はプロトコル手数料である。$\hat{\Psi}(p_{\ell})$ はレッグの正規化された活力である。$\Phi(R)$ は、経路の計測されたインパクトと集中度に対する Iron-Law フロアである。そして $\Xi(R) \in \{0, 1\}$ は反詐欺射影子である。 | 演算子 | 名称 | 方程式における役割 | 節 | |---|---|---|---| | Ω | 八重ディスパッチャ | 各レッグに価格を付け — プール種別ごとに一つの分岐 — 分割アロケータのためにトークン建ての深さを報告する | §4 | | 𝒟 | 決定論的導出 | 経路が使うプールを特定する。族が許す場合は計算されたアドレスによって、V4 シングルトンについては証明されたプール id によって | §5, §7 | | Φ | Iron-Law フロア | 経路を実行可能集合へ射影する。実行フレームで再導出される、正味出力の下のフロア | §11 | | Ψ | 活力場 | 各プールを、その詰め込まれたオンチェーン状態から読み取った、獲得された品質によって重み付けする | §9 | | Ξ | 反詐欺射影子 | 提示するには安全でない経路の価値をちょうどゼロとする | §5, §14 | この因数分解は意図的である。Ω は*プールがいくら返すか*に答え、Ψ は*それをどれだけ信頼するか*に答え、Φ は*経路が許容されるか*に答え、𝒟 は*プールがどこに存在するか*に答え、Ξ は*経路を提示しても安全か*に答える。積の形は、単一の失敗するレッグが経路のスコアを崩壊させることを意味する — ゼロを見積もるレッグや、実績を持たないプールは、積を割り引くのではなくゼロにする — そして指示関数は、正味出力がフロアを下回るあらゆる経路を強制的にゼロにする。ソフトなペナルティも、調整可能な重みも、すり抜けるニアミスの経路もない。  オンチェーンでは、Solver はこの方程式をパイプライン（`findBestRoutePlan`）として実現する。ペアごとの候補はレジストリによって、そしてレジストリが新鮮でない場合は 𝒟 によって収集され、Ψ によって順位付けされて `MAX_CANDIDATES = 8` に切り詰められ、Ω によってプローブされて見積もられ、信頼帯によってフィルタリングされ、レッグ間に配分される。そして組み立てられた経路は Φ が表明するフロアを運ぶ。その後 Router は、実際に到着した数量で Ω と Φ を再評価する。この方程式が行う主張 — 監査人がコードに守らせることのできる主張 — は、そのパイプラインのどの段階も五つの演算子の外部にあるものを参照しないということである。ある量が五つのいずれかの引数でないなら、それは経路に影響を与えられない。ベニューのマーケティングも、オフチェーンの評判も、運営者の好みも、である。 ### §3.1 依存予算 形容詞 — *分散型*、*サーバーレス*、*トラストレス* はもはや情報を運ばなくなった — の代わりに、検査可能なリストを示す。一つの取引が決済されるために存在し、動作し続けなければならないもののすべてである。 | 依存 | 典型的なオフチェーンで解くアグリゲーター | BlazePhoenix-Dex | |---|---|---| | 経路を計算するサービス | 必要 | 使用しない — Solver はどのノードでも提供できる `view` 関数である | | 価格オラクルまたはフィード | 場合による | なし — 五つのコントラクトにフィード呼び出しは存在しない | | ソルバーネットワークまたはオークション | 一般的 | なし | | キーパー、cron、リレイヤー | 場合による | なし — 活力は次に読まれたときに算術によって減衰する。レジストリは通常の取引から学習する | | アップグレード可能なプロキシ | 一般的 | なし — プロキシなし、`selfdestruct` なし、イニシャライザなし。唯一の `delegatecall` は、リンク時に固定される公開 Core ライブラリへのコンパイラ自身によるものである | | ホストされたインターフェース | 実際上は必要 | 利便性のためのみ | 最後の行は、ほとんどの予算が静かに破綻する場所である。ホストされたインターフェースは利便性であって依存ではない。`swapBestExactIn` は人が手で組み立てられる六つの値を受け取り、インテグレーター、スクリプト、あるいは競合のフロントエンドは、我々とのいかなる関係もなしにそれを呼び出せる。このプロジェクトが運営するすべてのサーバーが今夜消えたとしても、コントラクトは明日も今日とまったく同じように見積もり、ルーティングし、決済する。その性質のコストは、呼び出し元が探索の費用をガスで支払うことである。上の予算は、そのガスが買い取るものの一覧である。 不変性は逆方向にも働く。欠陥は修正できない — 一度だけ監査するコントラクトの代償である — だからこそ、欠陥は代わりに開示され、報奨金の対象とされる（§21）。 ### §3.2 三つの縁 予算には三つの縁があり、それらが境界付ける主張の隣に記す。インターフェースは誰のものとも同様にホストされており、侵害されたフロントエンドは脅威モデルにおける単一で最大のエクスポージャーである。コントラクトは渡されたゼロでない最小出力を何であれ尊重するので、あなたが設定する最小出力こそが、どのインターフェースもあなたから奪えない唯一の制約である。ベニューの発見は、以前のトランザクションが書き込んだ状態を読む — 公開かつパーミッションレスだが、取引時に魔法のように生み出されるものではない。そして管理権限は、一方通行の扉を通じて放棄されるまで存在する。放棄後、コントロール層 — 一時停止、ロール、トレジャリー、配線、削除 — は永久に消え、成長のみのキュレーター層だけが残る（§14）。ステートレスなコア、サーバーレスな運用、成長のみのガバナンス。表が主張であり、言葉はその影である。 ## §4 八重ディスパッチャ Ω *平易に：* あらゆる種類のプールに価格を付ける方法を知っている一つの関数。*厳密に：* Core の `universalQuote(QuoteCtx, amountIn)` は、Solver および Quoter のプレビューのための見積もりディスパッチャである。期待出力と、分割アロケータのためのトークン建ての深さを返し、価格を付けられないプールはゼロを返して、何かが送られる前に除外される。Router は同じ Core のプリミティブをレッグごとに自身のフレームで評価し（`_hopScaleImpactAndQuote`）、これはガスとスタック深さのために保たれた兄弟関数である。そして Quoter の Exact Pass はさらに別の問いを発する（§12）。三者はリポジトリの共有量レジスタにまとめて記録され、その一致は仮定されるのではなく、名前付きテストによって固定されている（§15）。この社内名称は、ディスパッチャが出荷時に持っていた八種別の列挙から引き継がれている。列挙はその後九番目のメンバーを得て、三つを意図的な切除によって手放した。番号付けはその欠番を保つ。昨日記録されたモノスロットは、永久に同一にデコードされなければならないからである。 ### §4.1 六つの種別、四つの族、一つの属性テーブル | 種別 | 定数 | 族 | 価格設定の分岐 | Θ 属性 | ガスラダー（Solver） | |---|---|---|---|---|---| | 0 | `KIND_V2` | 定積（Uniswap V2、Sushi、フォーク） | `getReserves` に対する閉形式 `outV2` | 準備金 · ペア検証可能 | 90,000 | | 1 | `KIND_V3` | 集中流動性（Uniswap V3 および V3 型フォーク） | `slot0` に対する閉形式 `outV3` | プールで集中 · ペア検証可能 | 110,000 | | 4 | `KIND_V4` | Uniswap V4 シングルトン | `extsload` に対する閉形式 `outV3` | シングルトン内で集中 | 180,000 | | 5 | `KIND_SOLIDLY` | Solidly（Aerodrome、Velodrome、フォーク）、ステーブルおよびボラタイル | プールに `getAmountOut` を問い合わせる。フォールバックとして複製曲線 | 準備金 · ペア検証可能 | 90,000 | | 6 | `KIND_ALGEBRA` | Algebra（Camelot 級）、動的手数料 | `globalState` に対する閉形式 `outV3` | プールで集中 · ペア検証可能 | 110,000 | | 8 | `KIND_V4_NATIVE` | チェーンのネイティブ通貨を保持する V4 プール | 種別 4 と同じ分岐 | シングルトン内で集中 | 215,000 | 六つの種別、四つの実働族：定積 {0}、集中 {1, 6}、Solidly {5}、そして V4 シングルトン {4, 8}。属性列は散文ではない。それは Core のビットテーブル `THETA_ATTR = 0x040A9400A9` であり、種別ごとに四ビット — *準備金を読む*、*プールアドレスで集中*、*シングルトン内で集中*、*`token0()`/`token1()` を公開する* — を持つ。そのため、五つのコントラクトにおけるあらゆる帰属の問い（「この種別は準備金を読むか？」）は一回のシフトと一回の AND（`kindHas`、`kindHasAny`）であり、ビットを持たない種別は、誰かが忘れうるデフォルト分岐なしにフェイルクローズする。ガス列は第二のテーブル `THETA_GAS` であり、Solver の `estGas` だけが読み、単位はレッグあたり 5,000 ガスである。 **種別 2、3、7 は意図的な切除により欠けている。** 加重族（3）はルーティング可能な見積もりを一度も生成しなかった。二つの Curve 族（2、7）は機能していたが、それでも 2026 年八月のトラスト境界の強化において削除された。それらをサポートするには、Router の唯一のトークン `approve`、プールから計測されるのではなく呼び出し元によって表明される唯一の深さの数値、そして Hub のペア真正性証明における唯一の例外が必要だったからである — 三つの攻撃面であり、それぞれがその類の最後のものであった。廃止された番号は決して再割り当てされない。`decodeKind` はモノスロットのビットから種別を読むので、2 を再利用すれば、その番号の下でこれまでに記録されたすべてのプールが再解釈されてしまう。そして、切除されたシンボルが戻ってきた場合には CI ガードがビルドを失敗させる。 **ネイティブ通貨種別（8）が存在するのは、ある不変条件がそこで、そしてそこでのみ破れるからである。** Router の作業前提 — すべての資産は `balanceOf` を持つ ERC-20 である — は、V4 プールの通貨がチェーンのネイティブ資産である場合にちょうど破綻する。その例外を*型*として符号化することで、それはプール記録の中で可視となり、経路計画に運ばれ、監査人が grep できるものとなる。価格設定には分岐は不要である。プール識別子は二つのソートされた通貨から導出され、`address(0)` は構成上最初にソートされる。この種別はその地位を経験的に獲得している。2026-08-13 に対象チェーン全体で計測したところ、V4 内の ETH 建て流動性の 62.9 % がネイティブプールにあった（Arbitrum 99.6 %、Optimism 95.0 %、Base 48.9 %）。 ### §4.2 閉形式 **定積。** 準備金は $x \cdot y = k$ を満たし、ベーシスポイント単位の手数料 $f$ が入力から取られる。Core は次を計算する。 $$ y \;=\; \mathrm{outV2}(x,\, r_{\mathrm{in}},\, r_{\mathrm{out}},\, f) \;=\; \left\lfloor \frac{x\,(\mathrm{BPS}-f)\; r_{\mathrm{out}}}{\,r_{\mathrm{in}}\cdot \mathrm{BPS} \;+\; x\,(\mathrm{BPS}-f)\,} \right\rfloor $$ ^e2 最終段階まで除算を行わないので、唯一の丸めは最後の商の切り捨てであり、`BPS` 以上の手数料はそのプールを見積もり不能にする（ゼロを返す）。この式に入る手数料は `effV2Fee(declared)` である。申告された手数料がゼロ、または `V2_FEE_CEILING_BPS = 100` を超える場合は標準の 30 bps に置き換えられるので、登録は、ありえない手数料を申告することによって自らの見積もり — そしてその見積もりが錨となるフロア — を引き下げることはできない。同じ規則が実行経路にもミラーされているので、取引の両側は一つの数値で価格付けされる。 **計算例 1 — 定積の見積もり。** あるプールが標準の 30 bps で $r_{\mathrm{in}} = 1{,}000{,}000$ USDC と $r_{\mathrm{out}} = 500$ WETH を保持している。トレーダーは $x = 10{,}000$ USDC を売る。プール自身の単位で（USDC は小数点以下 6 桁、WETH は 18 桁）、$x = 10^{10}$、$r_{\mathrm{in}} = 10^{12}$、$r_{\mathrm{out}} = 5 \times 10^{20}$ である。 1. 手数料調整後の入力：$x(\mathrm{BPS}-f) = 10^{10} \times 9{,}970 = 9.97 \times 10^{13}$ 。 2. 分子：$9.97 \times 10^{13} \times 5 \times 10^{20} = 4.985 \times 10^{34}$ 。 3. 分母：$10^{12} \times 10^{4} + 9.97 \times 10^{13} = 1.00997 \times 10^{16}$ 。 4. 出力：$\lfloor 4.985 \times 10^{34} / 1.00997 \times 10^{16} \rfloor = 4.935790 \times 10^{18}$ wei、すなわち **4.935790 WETH**（小数点以下六桁まで。コントラクトは最後の商を wei 単位に切り捨てる）。 USDC あたり 0.0005 WETH というスポット価格であれば、同じ 10,000 USDC で 5 WETH が得られる。約定はスポットより 1.28 % 低く、そのうち 0.30 % が手数料である。このレッグに対する Core の準備金ベースのインパクト指標は $\mathrm{impactV2Bps} = \lceil x \cdot \mathrm{BPS} / (r_{\mathrm{in}} + x) \rceil = \lceil 10^{14} / 1.01 \times 10^{12} \rceil = 100$ bps であり — §11 で Iron-Law フロアが消費する数値である。 **集中流動性。** V3 型のプールは準備金を保存しない。それらは Q64.96 固定小数点の平方根価格 $\sqrt{P}$ とアクティブ流動性 $L$ を保存する。一つのティック内で、手数料 $f$ を百万分率で表し $x_{f} = \lfloor x\,(10^{6} - f)/10^{6} \rfloor$ とすると、token0 → token1 については次のとおりである。 $$ \sqrt{P}\,' \;=\; \frac{L\,\sqrt{P}}{\,L \;+\; x_{f}\,\sqrt{P}/Q_{96}\,}, \qquad y \;=\; \frac{L\left(\sqrt{P}-\sqrt{P}\,'\right)}{Q_{96}} $$ ^e3 そして token1 → token0 については $\sqrt{P}\,' = \sqrt{P} + x_{f} Q_{96}/L$ および $y = L\,Q_{96}(\sqrt{P}\,' - \sqrt{P})/(\sqrt{P}\,\sqrt{P}\,')$ であり、除算は二段階に分けられる。素朴な計算はオーバーフローする。$L \cdot \sqrt{P}$ は $2^{288}$ に達しうる。Core は決してそれを形成しない — すべての積は全精度の `mulDiv`（512 ビットの中間値、256 ビットの結果）を通して因数分解されるので、各段階は証明可能な形で収まり、価格を誤った方向に、あるいはゼロへと動かすような段階は、数値ではなくゼロを返す。Algebra プール（種別 6）はこの分岐を共有し、分岐が扱う一点においてのみ異なる。その状態と動的手数料は `globalState` にあり、一度だけ読み取られる（§5.4）。 この公式は単一のティック内では厳密であるが、ティック境界をまたぐ場合は厳密ではなく、そこでは単一ティックの形は過大評価する。ディスパッチャはティックをまたぐ算術を複製しない。ベニュー内部の数学を複製することは構造的な負債である。複製と原本との間のいかなる乖離も、誤って価格付けされた見積もりとして表面化するからである。その代わりに二つのものが置かれている。Core は、ステップを現在のレンジの端で切り詰める境界クランプ（`sqrtBoundary`）を持つ — レンジ内に収まる部分については厳密で、残りについては厳密に下回り、決して上回らない — そして設計はそれを順位付けではなく*約束*の側に置く。ティックを持つ族だけをクランプすれば、ベニューを二つの慣行の下で比較することになるからである。本稿が計測するツリーでは、このクランプは定義されているがまだ配線されていない。`Router._v4LegQuote` と Core の順位付けアームはどちらもクランプされていない単一ティックの形を呼び出すので、レンジを離れる集中レッグは、§11.3 のレッグごとのフロアとホップ予算によってのみ制約され、Iron-Law フロアが最後の砦となる。そして実行時には、Iron-Law フロアは、Router が実際に到着した数量からフレーム内で再導出する見積もりに対して強制されるので、ティック境界での過大評価が損なうのは経路の順位付けの精度であって、ユーザーのフロアでは決してない。Quoter の Exact Pass（§12）は、インテグレーターが望むときにプール自身の数値を与える。 **深さ。** すべての分岐は、トークン単位の深さも返す — 準備金族については短い側の準備金（`shortSide18`）、集中族については $L$ が現在価格で表す仮想準備金 $L/\sqrt{P}$ または $L\sqrt{P}$（`depthFromL18`）である。そのため、等しい深さの V3 プールと V2 プールは、$\sqrt{P}$ 倍異なるのではなく、アロケータにおいて等しく比較される。 ### §4.3 二つの手数料単位をネイティブのまま運ぶ 定積および Solidly のベニューは手数料をベーシスポイントで見積もり、集中ベニューは百万分率で見積もる。ディスパッチャはそれぞれをそのネイティブ単位で運び、決して相互変換しない。これにより、定数が一つではなく二つになることを代償として、丸め障害の一つの類が除去される。二つのベニュー族 — V4 の動的手数料プールと Algebra — は実行時にしか手数料を知らず、どちらも価格を供給するのと同じ状態読み取りから手数料を計測することで扱われる（§5.4）。 ### §4.4 一つのディスパッチャ、二つの面 | 種別 | Quoter のプレビュー | フレーム内（Solver の計画、Router の再導出） | |---|---|---| | V2 (0) | 閉形式 `outV2` | 閉形式 `outV2` | | V3 / Algebra (1, 6) | `slot0` / `globalState` に対する閉形式 `outV3`。Algebra のライブ手数料は同じ読み取りから計測される | 同じ | | Solidly (5) | プールに問い合わせる。フォールバックとして複製曲線 × 9,800 / 10,000 | 同じ | | V4 / V4 ネイティブ (4, 8) | `extsload` を介した閉形式 `outV3`、フェイルクローズの手数料ゲート（E19） | 同じ | したがって、プレビューと約定を隔てるのは時間である。すなわち、プレビューのブロックと実行フレームとの間に動いた状態である。§12 はまさにその隔たりを 240 サンプルで計測する。 ## §5 Uniswap V4 のエンドツーエンド Uniswap V4 は新しいプールコントラクトではない。それは新しい形のベニューであり、2020 年から 2024 年の間に構築されたあらゆるルーターが依拠する四つの前提を無効にする。プールにはアドレスがない――それらは一つのシングルトンのストレージ内のエントリであり、ハッシュをキーとする。スワップの内部で任意のコードが実行される――フックは、ルーターが行っている決済の定められた時点で実行される。手数料は一定である必要がない。そしてプールはチェーンのネイティブ通貨を保持しうるが、それには `balanceOf` がない。本節はこれら四つすべてに構造的に答え、V4 レッグが――Solver にとっても、フロアにとっても、トレーダーにとっても――他のいかなるレッグとも区別できないようにする。 ### §5.1 アドレスを持たないプールの特定：導出し、そして証明する 決定論的導出 𝒟 はアドレスを計算する（§7）が、V4 プールには計算すべきアドレスがない。あるのは識別子――その `PoolKey` の keccak ハッシュ――であり、そのため導出表のモード 9 はアドレスではなく *poolId* を導出し、続いていかなるアドレス導出にもできないことを行う。すなわち、その id について PoolManager 自身のストレージを読み、非ゼロの平方根価格と非ゼロの流動性を要求することで、プールが存在することを証明する。この証明は誰にも偽造できない。そのストレージに書き込むのはマネージャー以外にいないからである。捏造された id はゼロに解決され、破棄される。 **計算例 4 ―― キーから得る V4 プール識別子。** 正準 id は $\mathrm{poolId} = \mathrm{keccak256}(\mathrm{abi.encode}(c_{0}, c_{1}, \mathrm{fee}, \mathrm{tickSpacing}, \mathrm{hooks}))$（`computeV4PoolId`）であり、32 バイトのワード五つからなる。Base 上の 0.05 % ティアのネイティブ ETH / USDC プールを例に取る：$c_{0} = \mathtt{0x0000…0000}$（ネイティブ通貨が先にソートされる）、$c_{1} = \mathtt{0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913}$（USDC）、fee $= 500$、tickSpacing $= 10$、hooks $= \mathtt{0x0}$。 1. `abi.encode` は 160 バイトを配置する：二つの通貨をそれぞれ 32 バイトに左パディングしたもの、次に `500`、次に `10`（`int24` であり、32 バイトに符号拡張される）、最後にゼロのフックである。 2. $\mathrm{poolId} = \mathtt{0x96d4b53a38337a5733179751781178a2613306063c511b78cd02684739288c0a}$。 3. V4 行に対するレジストリの `pool` フィールドは id の下位 160 ビット $\mathtt{0x781178a2613306063c511b78cd02684739288c0a}$ である――コードを持たないアドレスであり、それゆえ V4 行には決して `token0()` が問い合わされず、残高が読まれることもなく、代わりに再導出によって自らを証明する（§9）。 4. プールのストレージ基点は $\mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6)) = \mathtt{0x13a3a697…73b2893d}$ である：マネージャーのスロット 6 が `pools` マッピングである。Core はそのスロットのワード 0 と、$\mathrm{base} + 3$ のワード 3 を読む（`v4SqrtAndLiq`、セレクタ `extsload(bytes32)` = `0x1e2eaeaf`）。 5. ワード 0 はビット [0, 160) に $\sqrt{P}$、[160, 184) にティック、[184, 208) にプロトコル手数料、[208, 232) に LP 手数料を詰め込む。ワード 3 は下位 128 ビットにアクティブな流動性を保持する。$\sqrt{P}$ と $L$ のいずれかがゼロであれば、このプロトコルにとってそのプールは存在しない。 同じペアのラップ版の兄弟――$c_{0} = \mathtt{0x4200…0006}$（WETH）、同じティア――の id は $\mathtt{0x90333bb0…ebd943a0}$ である：深さの異なる別のプールであり、それゆえスキャンは両方のキーをプローブし、ネイティブのものを先にプローブする（後述）。ステップ 5 のレイアウトはドキュメントから取ったものではない：同じプールをこのレイアウト経由と正準の `StateView` コントラクト経由で読むと、メインネットのフォーク上で同じ数値が返り、Core のコメントが引用しているのはこの同一性である。 **コストの梯子。** 候補 id を生み出すスキャンは梯子であり、最も安い段から順に試す。あらゆる手数料とスペーシングの組み合わせを素朴に総当たりすれば、ソルビング経路上で許容できないガス代となるからである： | 段 | 試すもの | ヒット時のコスト | |---|---|---| | 1 | このトークンペアについて既に学習済みのティアパターン | プローブ一回――定常状態の経路 | | 2 | コールドスキャンに支払う前の来歴チェック | 読み取り一回 | | 3 | 正準の Uniswap ティア、`extsload(bytes32[])` によるバッチ | バッチで呼び出し一回 | | 4 | 登録行が宣言する `(fee, spacing)` の組 | 登録によって上限が決まる | | 5 | コールドスタート用ジェネレータのグリッド――fee $= 10{,}000\,j$、spacing $= 100\,j$、$j$ は `V4_GRID_MAX = 99` から降順 | プローブは最大 `V4_GRID_PROBES = 40` | スキャン全体は `V4_CAP = 8` 個の証明済みプールで停止する。二つの性質は、チェックからではなく構造そのものから導かれる：フック付きプールはこのスキャンによって決して出力されない――スキャンは*フックなし*の id を導出し、フック付きプールのフックなし id はマネージャー内に存在しないため、いかなるポリシー上の問いが発せられる前に生存性の証明に失敗する――また、異なるティア推測から得られた重複 id は一つの候補に縮約されるため、一つのプールがエイリアシングによってファネルを飽和させることはできない。プローブ順序それ自体がポリシーである。上限は最初にプローブされたものによって消費されるからである：チェーンのネイティブ資産を相手とするペアは V4 において二つのキー、すなわちネイティブとラップ版を持ち、順序が決定された時点で対象チェーン上ではネイティブキーの方が深いことが測定された（Base で 3.76×、Robinhood Chain で 292×）ため、ネイティブキーが先にプローブされる。  **パーミッションレスの扉。** 誰でも `claimV4(c0, c1, fee, tickSpacing)` を呼び出してフックなしプールを受け入れさせることができる。請求がそれ自身の証明を携えているからである：id は提出されたキーから再計算され、マネージャーのストレージから読み戻されるため、虚偽の請求はゼロに解決され、何も受け入れさせない（`HubE(9)`）。さらに三つの条件がこの扉を制限する：上限のあるレジストリの席が、ルーターが決して渡れないペアに費やされることのないよう、ペアの一方はルーティング可能なブリッジコインでなければならない。実効手数料は後述の手数料ゲートの下で見積もり可能でなければならない。そして請求は、プールの測定された流動性を深さとして、スワップ駆動の登録が満たすのと同じ受け入れマージンを満たさなければならない（§9）。レジストリは公衆によって教えられうるが、公衆によって欺かれることはない。 ### §5.2 呼び出しに応答しないプールを読む id の生存が証明されると、ディスパッチャには価格と流動性が必要になる――しかし呼び出すべき `slot0()` は存在しない。Core は上の例のように `extsload` によってシングルトンのストレージを直接読み、V4 分岐は §4.2 の集中流動性の閉形式に帰着する：同じ数学、同じオーバーフロー規律である。シングルトンが変えるのは状態がどこに存在するかであって、状態が何を意味するかではない。コードのない、あるいは準拠しないマネージャーはすべてゼロのワードを返す――フェイルクローズであり、決してリバートしない。 ### §5.3 シングルトンによる決済 実行は通常の制御フローを反転させる。プールを呼び出して支払いのためにコールバックされる代わりに、Router はマネージャーの `unlock` を呼び出し、マネージャーが与えるコールバックの内部でスワップ全体を実行する：スワップし、次に `sync → settle → take` によってすべての債務通貨を決済し、それからロックを解放する。処理中の通貨はトランジェントストレージ（`TSLOT_V4IN`、`TSLOT_V4OUT`）によってアンロック境界を越えて運ばれるため、フレームは永続状態を一切汚さず、スワップ間でコンテキストが空であることが証明可能である。マネージャーが返す `BalanceDelta` はパックされており――`amount0` が上位 128 ビット、`amount1` が下位――Router は決済の算術が実行される前にそれをそのとおりにデコードする。 ネイティブ通貨は、重要な不変条件を保つ。Router はあらゆる箇所で WETH を正準とする――`swapExactInNative` に入るネイティブ値は入口でちょうど一度だけラップされ、ネイティブ出力は意図的に実装されていない：受取人は WETH を受け取り、それはいかなる経路によっても黙って閉じ込められることがない。ネイティブの V4 レッグは自らのアンロックフレームの内部で*ジャストインタイム*にアンラップする――`WETH.withdraw`、次に値付きの `settle`、そしてネイティブの `take` から受け取った ETH は同じフレーム内で再ラップされる――ため、ネイティブ ETH がコントラクト内に静止して存在することは決してない。これが必要とした唯一の新しい面は、要件が許す限り狭くゲートされた `receive()` である：トランジェントスロット（`TSLOT_ETHOK`）が、その瞬間に Router へ生の ETH を送ることを許された単一のアドレスを保持する――アンラップ中は正準 WETH コントラクト、ネイティブ take 中は PoolManager、それ以外のあらゆる瞬間はゼロ――ため、それ以外の誰からの裸の ETH もリバートする。ネイティブの扉は `weth` が接続されるまでフェイルクローズである（`RouterE(3)`）。 ### §5.4 実行時にのみ存在する手数料 静的手数料の V4 プールは LP 手数料をキーに保持し、そこでは不変である。プールマネージャーはさらに Uniswap 自身のマネージャー手数料――方向ごとに 1,000 pips、すなわち千分の一を上限とする――を取ることができ、Core の静的アームはそれを加算しないため、静的キーに対する見積もりは、Uniswap の手数料コントローラがそれを有効にした時点で、届けられる出力をそのマネージャー手数料の分まで過大に示しうる（執筆時点では対象のすべてのチェーンでゼロである）。その不足分はフロアの内側に収まり、手数料ベースは測定値であるためそれを無視する。動的手数料プールは代わりにセンチネル `0x800000` を保持し、その実際の手数料は `slot0` に存在する。センチネルを額面どおりに見積もれば、実行が実勢レートを支払う一方で、取引を無料として価格付けしてしまう。このゲートは Core 内の三行である（`effV4Fee`）： $$ f_{\mathrm{eff}} \;=\; \begin{cases} f_{\mathrm{key}} & f_{\mathrm{key}} \ne \mathtt{0x800000} \\ \mathtt{0xFFFFFF}\ (\text{unquotable}) & f_{\mathrm{key}} = \mathtt{0x800000} \ \wedge\ f_{\mathrm{proto}} \ne 0 \\ f_{\mathrm{LP}}\ \text{read from } \mathtt{slot0} & \text{otherwise} \end{cases} $$ ^e19 非ゼロのプロトコル手数料を伴う動的手数料キーは $10^{6}$ 以上の手数料を返し、`outV3` はそれに対してゼロを返す：フェイルクローズである。プロトコル手数料と LP 手数料の合成は我々が納得できる程度には確定されておらず、また執筆時点で Base 上で測定されたプロトコル手数料はゼロであるため、この分岐は実際には何のコストも生じない。同じ規則が、一つ隣のファミリーで同じ継ぎ目を塞ぐ：Algebra プールは構造上動的手数料であり、ゼロのセンチネルを登録するため、`quoteV3Fee` は非ゼロの設定済み手数料を真値とし、動的プールの手数料はその価格を既に供給した `globalState` の読み取りから取り、そして――手数料がティックスペーシングをキーとしプール上に存在する集中流動性フォークについては――プール自身の `fee()` を取り、何も応答しない場合は `0xFFFFFF` でフェイルクローズする。静的な V3 プールは追加の読み取りを行わず、バイト単位で同一の見積もりを返す。 一つの継ぎ目が残り、それは除去されるのではなく有界に抑えられている：動的手数料フックは `beforeSwap` 内でスワップごとに手数料を上書きできるため、`slot0` に格納された手数料があらゆる場合に実行されるものと一致するわけではない。その残余は、受け入れ時の Hub のフック許可リストと、実行時に実現出力から再導出される Iron-Law フロアによって封じ込められるため、敵対的な上書きはリバートかフロア内の不足として現れ、フロアを下回る約定には決してならない（§14）。 ### §5.5 フック：算術によって選別し、決して問いただすことはしない フックとは、Router が行っている決済の内部で実行される任意のコードである。直感的な防御――フックに何を意図しているかを尋ねること――は防御にならない。敵対的なフックは嘘をつくか再入するからである。BlazePhoenix はフックに決して何も尋ねない。代わりに三つの独立した層が、最も安いものから順に立ちはだかり、§14 がそれらを詳述する：フックの権限ビットはそれ自身のアドレスの下位十四ビットに存在し、デプロイ時に固定される。スワップのデルタの変更を許可する二つのビットは、トークンが動く前に一回の AND によって拒否される（`hookAltersDeltas`、`RouterE(9)`）。フックは、許可リストに載っており、かつその実行時コードが受け入れ時に固定されたコードハッシュと一致し続けている間に限りルーティング可能である（`isHookLive`）。そして射影子 Ξ は、デルタを変更するフックをランキングの前に Solver の候補集合から除去するため、その経路は表現されることすらない。残余は機構とともに明示される：許可リストに載った、デルタを変更しないフックでも、スワップの途中でリバートし、試行のガスを浪費させうる――これは、信頼できないコードが何をしたであろうかを知るためにそれを呼び出すことを原則として拒否することの代価である。 ### §5.6 この統合の価値 上記のすべての機構は、既に他所で用いられている Core のプリミティブを新しい状態レイアウトに適用したものか、V4 を超えて一般化する真に新しいプリミティブ――存在証明による発見――のいずれかである。プールごとの統合は一つもなく、人間が最新に保たなければならないキュレーションされたリストも一つもない。V4 プールはディレクトリなしに発見され、他の誰も書き込めないストレージに対して証明され、他のすべての集中型ベニューと同じ閉形式で価格付けされ、測定によって手数料ゲートを受け――測定が厳密でない場合はフェイルクローズの拒否を伴い――、不変のアドレス算術によって敵対的なフックを選別され、シングルトン自身のロックプロトコルを通じて決済され、Router がその一 wei たりとも静止状態で保持することなくネイティブ ETH で到達可能である。§17 が測定結果を示す：Arbitrum におけるファクトリー・センサスでは V4 ファミリーが他のどの登録済みベニューよりも多くのホップペアを獲得し、Optimism ではセンサスが、我々の知る限り同チェーン初の V4 経由のアグリゲーションを記録した。V4 プールを、ネイティブ ETH を含めて、キュレーションされたプールリストなしに、実行トランザクションの内部だけで導出し、証明し、価格付けし、選別し、決済する公開アグリゲーターを、我々は他に知らない。もし見つけたなら、この主張は誤りであり、我々はそれを知りたい。 ## §6 Solidly ソルバー 一部の不変量には、安全に再現できるほど単純な閉形式が存在せず、それを再現することは、プロトコルが他所で拒否している複製リスクそのものである。そのようなベニューに対して、ディスパッチャはベニューが公開する最も狭く誠実なチャネルを通じてプールに尋ねる――そして応答しないフォークのためにレプリカを予備として保持する。 Solidly ファミリー――Aerodrome、Velodrome、およびそれらのフォーク――は、ステーブルペア上の相関資産を、乖離を許容しつつも定積よりはるかに密に対角線に沿う四次の不変量によって扱う： $$ k(x, y) \;=\; x^{3}y \;+\; x\,y^{3} \;=\; x\,y\left(x^{2}+y^{2}\right) $$ ^e5 均衡点の近傍では、この曲線は入力のほぼ全量を出力として届ける――ステーブルコインとリキッドステーキングのフローが集中するまさにその場所で、スリッページを最小にする。ボラタイルな Solidly ペアは定積であり、Core のボラタイルアームは `outV2` *そのもの*である――生成元は一つであり、メタモルフィック関係 MR7 がそれを固定する（§15）。  **主経路：プールに尋ねる。** `getAmountOut(amountIn, tokenIn)` はペア自身のバイトコード――実勢の手数料、曲線、丸めを含む――によって計算されるため、ちょうどその値を要求するスワップは構造上プールの不変量チェックを満たし、マージンは不要である。フォールバックの引き金は最大 1 wei の応答であり、ちょうど 1 を返すプールがかつて三つのうち二つのチャネルを異なる分岐に送ったことを受けて、問い合わせを行う三つのチャネル（Solver、Router、Quoter）の間で揃えられている。 **フォールバック：複製し、控えめに要求する。** フォークがこのセレクタを公開していない場合、ディスパッチャはペアのファクトリーから実勢の手数料を読み（`getFee(pool, stable)`。宣言されたフォールバック手数料は V2 アームと同じ 100 bps の上限内でのみ信用され、そうでなければ 30 bps）、小数桁を正規化した準備金の上で不変量を解き、結果に 9,800 / 10,000 を乗じる――レプリカが観測できないプールの丸めに常に余裕を持たせるための 200 bps のヘアカットである。このヘアカットはフォールバック時にのみ適用され、プールが自ら応答した場合には決して適用されない。 **求解。** 取引後の入力残高 $x$ と、取引前の準備金から得た目標不変量 $K$ が与えられると、Core は $f(y) = x^{3}y + xy^{3} - K$ の根を、$f'(y) = x(x^{2} + 3y^{2}) > 0$ のもとで、反対側の取引前準備金 $y_{0} = Y$ を初期値とするニュートン反復によって求める（`_solY`）： $$ k(x, y_{n}) < K:\ \ y_{n+1} = y_{n} + \max\!\left(1,\ \left\lfloor \tfrac{K - k(x,y_{n})}{f'(y_{n})} \right\rfloor\right); \qquad k(x, y_{n}) \ge K:\ \ y_{n+1} = y_{n} - \delta_{n},\ \ \delta_{n} = \begin{cases} \lfloor y_{n}/2 \rfloor & d_{n} \ge y_{n} \\ \max(1, d_{n}) & \text{otherwise} \end{cases},\ \ d_{n} = \left\lfloor \tfrac{k(x,y_{n}) - K}{f'(y_{n})} \right\rfloor $$ ^e6 自然に見える初期値――定数和近似――は、価格を黙って破損させる形で誤っている：準備金の数倍の入力を吸収するプールでは、それは $f$ が極めて急峻な領域で根のはるか上に着地し、ステップはゼロに切り捨てられ、ソルバーは確信に満ちた、もっともらしい、誤った数値に張り付く。反対側の準備金を初期値とし、両方向にステップすることで、均衡したプールでも大きく偏ったプールでも同様に収束する。ゼロを越えてしまう下向きのステップは反復値の半分に置き換えられる。すべてのステップは少なくとも一単位の前進を強制する。反復は連続する反復値の差が最大一単位になった時点で終了し、テイカーに不利な方向への最後の一単位の調整によって不変量の安全側に着地する。ループは 64 回の反復で上限が設けられ、その上限はフェイルクローズである：ソルバーは初期値そのものを返し、呼び出し元の $y \ge Y$ ガードがそれをゼロの見積もりに写す――プールは価格付け不能として扱われ、これは Aerodrome 自身が誤った価格付けをするよりも拒否することと一致する。消失する導関数も同じ出口を取る。 **小数桁の正規化。** 不変量は四次の同次式であるため、両トークンが同じ小数桁数を持つ場合はスケールが相殺され、生の準備金がそのまま使える。DOLA（18 桁）と USDC（6）のようなペアはその不一致を四次式に持ち込むため、Core は求解の前に両側を共通の $10^{18}$ 基準にスケーリングし、その後に逆スケーリングする： $$ X = r_{\mathrm{in}}\cdot 10^{\,18-d_{\mathrm{in}}},\quad Y = r_{\mathrm{out}}\cdot 10^{\,18-d_{\mathrm{out}}},\quad A = \left\lfloor\frac{x\cdot 10^{\,18-d_{\mathrm{in}}}\,(\mathrm{BPS}-f)}{\mathrm{BPS}}\right\rfloor,\quad \mathrm{out} = \left\lfloor\frac{Y - y^{\star}(X+A,\,K)}{10^{\,18-d_{\mathrm{out}}}}\right\rfloor $$ ^e7 十八桁を超える小数桁を報告するトークンは、スケーリングをアンダーフローさせる代わりにゼロを見積もる。もう一方のトークンの小数桁数は呼び出し元から受け取るのではなくプールから読まれる――呼び出し元の座標を受け入れる単一生成元のプリミティブは、それが塞ぐために存在する乖離を再び開いてしまうからである。 **定義域全体でのフェイルクローズ。** 四つのガードが曲線をそもそも評価するかどうかを決定し、それぞれリバートするのではなくゼロを返す。見積もり内部のリバートは、ライブラリの `DELEGATECALL` がそのペアに対する Solver の計画全体を巻き戻すことを意味するからである：$X$ と $Y$ は $3.4 \times 10^{38}$ を超えてはならない。$X + A$ も同様である。そして `_solKFits` は、不変量 $k = xy(x^{2}+y^{2})/\mathrm{WAD}^{3}$ と導関数 $x(x^{2}+3y^{2})/\mathrm{WAD}^{2}$ の両方が、ニュートン法が訪れる最大点である初期値において 256 ビットのワードに収まることを要求する。この最後のテストは除算なしで問われる――512 ビット積の上位ワードを計算し、それを一 WAD と比較する（`_mulFitsWad`）――なぜなら以前の形式 $a \le \max \cdot \mathrm{WAD} / b$ は、トークンを一単位未満しか保持しないプール上でそれ自体がオーバーフローしたからである。§15 の N バージョンレーンが 2026-09-05 にその漏れを発見した。修正は置き換えたコードより 35 バイト小さく、レッドファーストで導入され、定義域全体にわたる 5,000 回のファズ、Python による同じ算術の 60,000 サンプルのスイープ、およびガード内の三つのミュータントを伴った。 **測定された残余と 200 bps のマージン。** レプリカは、プール自身の `getAmountOut` を正解値として、稼働中の Aerodrome プールに対して測定された： | プール | 状態 | 正解値 | Core の出力 | 偏差 | |---|---|---|---|---| | USDC / USDbC | 均衡（6 / 6 桁） | 999,534,071 | 999,534,071 | 0.000 % | | DOLA / USDC | 偏り（18 / 6 桁） | 985,528,437 | 987,998,286 | 0.251 % | | USDz / USDC | 偏り（18 / 6 桁） | 899,325,141 | 901,565,830 | 0.249 % | 均衡したペアは整数単位で一致する。偏ったペアは 0.5 % 以内、高い側に位置する。プールの手数料後の残高の丸めは外部から見えないからである。その残余こそ、フォールバックが 200 bps 控えめに要求する理由である：このマージンは実行時にペアの不変量チェックに余裕があることを保証し、起こりうる過大見積もりによるリバートを確実な約定に変える。そしてそれはプレビューとフレーム内の両方の面で同一に適用されるため、両者は歩調を揃え続ける。§15 の正準オラクルレーンは曲線を独立に有界に抑える：ベニューの仕様から書かれた実装に対して、Core のステーブル見積もりは 5,000 個のファズ入力にわたって 4 wei 以内に収まる。 ## §7 決定論的導出 𝒟 プールは、見積もられる前に見つけられなければならない。業界の答えは尋ねることである：ベニューのファクトリーへの呼び出しがストレージのマッピングを読んでアドレスを返し、呼び出し元はファクトリーの言葉を信じる。BlazePhoenix はその答えもサポートする――四つのファクトリー呼び出しモードが、デプロイが再現不可能なベニューをカバーする――が、算術が許すところではより強い答えを優先する：外部呼び出しなしにアドレスを計算することである。計算されたアドレスは、同じ三つの入力を持つ誰もが検証できる。取得されたアドレスは信頼することしかできない。 その機構は CREATE2 である。EVM はコントラクトのアドレスを、そのデプロイヤー、ソルト、およびそのイニットコードのハッシュの純粋関数とする： $$ \mathrm{pool} \;=\; \mathrm{addr}_{20}\!\left(\mathrm{keccak256}(\mathtt{0xff}\,\Vert\,\mathrm{origin}\,\Vert\,\mathrm{salt}\,\Vert\,\mathrm{initCodeHash})\right) $$ ^e8 ここで $\mathrm{addr}_{20}$ はハッシュの最後の二十バイトを取る。Core は 85 バイトのプリイメージをちょうど一度だけ書き下す（`create2Address`）。`deriveAddress` はモードからソルト多項式とオリジンを選択し、Hub のアテスト済み Algebra 導出も同じ生成元を再利用する。 | モード | ファミリー | 解決方法 | ソルト / プローブの詳細 | |---|---|---|---| | 0 | V2 | ファクトリー呼び出し `getPair(t0,t1)` ―― セレクタ `0xe6a43905` | — | | 1 | V3 / Algebra | ファクトリー呼び出し `getPool(t0,t1,fee)` ―― `0x1698ee82`。ミスした場合は `poolByPair(t0,t1)` ―― `0xd9a641e1` | — | | 2 | Solidly | ファクトリー呼び出し `getPool(t0,t1,stable)` ―― `0x79bc57d5` | — | | 3 | 集中型 Solidly フォーク（Slipstream、Velodrome CL） | ファクトリー呼び出し `getPool(t0,t1,tickSpacing)` ―― `0x28af8d0b` | — | | 4 | V2 CREATE2 | 純粋な算術 | `keccak256(packed(t0,t1))`、オリジン = ファクトリー | | 5 | V3 CREATE2 | 純粋な算術 | `keccak256(encode(t0,t1,fee))`。`fee == 0` は Algebra のセンチネル → `keccak256(encode(t0,t1))`、オリジン = ファクトリーの `poolDeployer()`（`0x3119049a`）、受け入れ時にアテスト | | 6 | Solidly クローン CREATE2 | 純粋な算術 | `keccak256(packed(t0,t1,stable))`、オリジン = ファクトリー | | 7 | CL CREATE2 | 純粋な算術 | `keccak256(encode(t0,t1,tickSpacing))`、オリジン = ファクトリー | | 8 | *廃止* | Curve の除去によって空いた。墓標であり、`MODES_VALID = 0x2FF` がこれを拒否する | — | | 9 | V4 導出スキャン | フックなし poolId を導出し、PoolManager 上で生存を証明する（§5.1） | グリッド ≤ 99 ティア、コールドでのプローブ ≤ 40、8 プールで停止 | モード 0–3 はそれぞれ一回の `staticcall` である。モード 4–7 は呼び出しゼロであり、正しいイニットコードハッシュのみを必要とする。モード 9 は、どちらの方法でもプールを特定できない唯一のファミリーに対応する。 **定理、主張、そして証明。** 導出されたアドレスはペアに関する定理である：オリジン、ソルト多項式、イニットコードハッシュが与えられれば、アドレスは keccak のみによって導かれ、異議を唱える者は誰でもそれを再計算できる。尋ねて得たアドレスは、ファクトリーが自らのストレージについて述べる主張である――そしてファクトリーは別のトークンのプールを返答しうる。2026-09 以降、尋ねて得たプール（モード 0–3）は、発見がそれをリストする前に自らのペアを証明する：Hub はその `token0()` と `token1()` を読み――支払いを行う継ぎ目で Router が行うのと同じ二つの読み取りである――不一致があれば候補を除外するため、実行者が拒否するであろうプールが、リストされ、計画され、ランク付けされることは決してない。これを変えたのは §15 の敵対的ベニュー行列である：その最初の実行では、キュレーターが受け入れたファクトリーが返答したプールがリストされ、プランナーがそれをランク付けし、実行者が支払いを行う継ぎ目でそれを拒否した――資金が危険にさらされることは決してなかったが、ペアは拒否され、その一方で偽者が分割を勝ち取った。 **V3 形の行における二つの微妙な点。** Algebra（Camelot 系）は動的手数料を課すため、手数料がその同一性の一部になることは決してない：Algebra の登録はセンチネルとして手数料ゼロを宣言し、モード 5 はソルトから手数料を除き、CREATE2 のオリジンは Algebra ファクトリーが公開する別個の `poolDeployer` コントラクトである。そのオリジンは、受け入れ後もなおファクトリーが操作しうる唯一の導出入力である――プロキシはコードハッシュを保ったまま答えを変えられる――ため、Hub はそれを `addFactory` で一度だけアテストし（`factoryDeployer`）、以後はアテスト済みのオリジンから導出する。制御が放棄された後、そのアテストは凍結される。ファクトリー呼び出し側では、Algebra ファクトリーは `getPool` ではなく `poolByPair` を公開するため、何も返さなかったモード 1 の検索は、断念する前にそのセレクタで再試行する。 **すべての導出は一つの最終ゲートを通過する。** Hub は実行時バイトコードを持たない導出アドレスをすべて破棄する――`extcodesize` がチェックのすべてである（`hasCode`）――ため、誤ったイニットコードハッシュ、古くなった登録、あるいはそのファミリーが一度もデプロイされていないチェーンは、幻のベニューではなく何も生み出さない。そのアドレスのバイトコードは存在を証明するが誠実さは証明しない。それゆえ、受け入れ、信頼帯、フロアが、特定されたプールと約定した取引の間に依然として立ちはだかる。複数の `(fee, spacing)` の組み合わせの下で導出された同じプールは一度だけリストされる。 **導出と問い合わせの境界は経験的である。** Velodrome や Aerodrome のようなクローンベースのベニューは、イニットコードハッシュが既知であってもファクトリー呼び出しに留まる。それらの CREATE2 オリジンはファクトリーではなく内部の決定論的クローンデプロイヤーの中に存在するからである――アドレスは公開入力から再現できないため、プロトコルは尋ねる。Uniswap V3 は反対方向の代表例である：同じプールのバイトコードがあらゆる場所にデプロイされているため、そのイニットコードハッシュはすべてのチェーンで一つの定数であり、同一性 `derived == getPool` は Ethereum、Arbitrum、Optimism、Base のフォーク上で各チェーン自身のファクトリーに対して成立する（§17）。算術が健全なところでは導出し、そうでないところでは尋ね、いずれの場合もすべてを検証する。 **発見は表を一行ずつ消費する。** 最大 `MAX_FACTORIES = 16` 個の登録済みファクトリーのそれぞれについて、Hub は宣言されたすべての `(fee, spacing)` の組み合わせをプローブする――Solidly の行はステーブルとボラタイルの両方のフレーバーで、V4 の行は最大八つを予約する――ため、スキャンの最悪ケースはチェーンの気分ではなく登録によって固定される。設定面は入口で守られている（§9）：構造的に不可能なベニューは格納できない。 ## §8 モノスロット ストレージは EVM 上で何かを行う際の支配的なコストである：コールドの `SLOAD` は 2,100 ガスであり、プールの属性を別々のスロットに散らばらせたレジストリは、すべての属性について、すべてのプールについて、評価されるすべての経路について、それを繰り返し支払うことになる。BlazePhoenix はプールのルーティング状態全体を単一の 256 ビットワード――モノスロット――に詰め込み、一度だけ読み、純粋な算術によってデコードする。 | ビット | フィールド | 幅 | 意味 | |---|---|---|---| | 0 | `active` | 1 | スロットが有効である | | 1–7 | 予約 | 7 | ビット 5 = ステーブル曲線（登録時にプール自身の `stable()` から読み取る）。ビット 6 = ネイティブ側の入れ替え。ビット 7 はかつてのブリッジフラグで、現在は書き込まれない――ブリッジボーナスはペアから実時間で読まれる（§9） | | 8–31 | `fee` | 24 | ベニュー固有の単位での手数料ティア | | 32–39 | `kind` | 8 | ベニューの種類（§4） | | 40–47 | `tier` | 8 | 0 = キュレーション（オペレーターが投入）、2 = パーミッションレス（取引によって学習、または請求による） | | 48–59 | `conc` | 12 | 集中度フィールド。パッキング前に `0xFFF` でマスクされる | | 60–63 | `bucket` | 4 | 対数深さバケット | | 64–95 | `lastUpdateTs` | 32 | 最後に触れられた時点の実時間タイムスタンプ | | 96–127 | `emaIn` | 32 | 入力量 EMA のために予約。登録時にゼロとして書き込まれ、出荷版のティックでは更新されない | | 128–159 | `emaOut` | 32 | 出力量 EMA のために予約。同上 | | 160–191 | `swapCount` | 32 | 活動カウント。$2^{32}-1$ で飽和する | | 192–223 | `regBlk` | 32 | 登録ブロック | | 224–255 | `lastBlk` | 32 | 最後に触れられたブロック |  エンコーディングはシフトと OR の列である（`encodeSlot`）： $$ s \;=\; a \;\vert\; f\!\ll\!8 \;\vert\; k\!\ll\!32 \;\vert\; r\!\ll\!40 \;\vert\; (c \wedge \mathtt{0xFFF})\!\ll\!48 \;\vert\; b\!\ll\!60 \;\vert\; t\!\ll\!64 \;\vert\; e_{\mathrm{in}}\!\ll\!96 \;\vert\; e_{\mathrm{out}}\!\ll\!128 \;\vert\; n\!\ll\!160 \;\vert\; B_{\mathrm{reg}}\!\ll\!192 \;\vert\; B_{\mathrm{last}}\!\ll\!224 $$ ^e9 一つの細部は利便性ではなくガードである：集中度フィールドはシフトの*前に*十二ビットにマスクされるため、ビット [63:60] の深さバケットへ決して滲み出さない――パッキングは、呼び出し元が範囲内に留まることを信頼するのではなく、パックされた状態を破損させる黙ったフィールド重複というクラスそのものを禁じる。デコードも同様に機械的である：各アクセサはシフトと切り詰めであり、バケットの書き込み側は設定前にその四ビットをクリアし、スワップカウントはラップアラウンドせずに飽和するため、満杯のスロットが活発なプールの履歴をゼロに巻き戻すことは決してない。ティックと登録のたびに Hub が刻印する実時間タイムスタンプは、§9 の活力の減衰と Solver の発見鮮度ゲートの両方を駆動する。 このワードが含まないものに注目されたい：価格である。モノスロットはプールをランク付けするのに必要なすべて――活動、深さクラス、手数料、種類、フラグ、新しさ――を保持し、見積もりと取り違えられうるものは何も保持しないため、レジストリの記憶は構造的に取引を価格付けすることができない。価格は、それに基づいて取引するフレームの内部で、稼働中の準備金から新たに計算される。パックされたワードが決めるのは、どのプールに尋ねる価値があるかだけである。更新経路も同じ節約を守る：既知のプールを経由するスワップはワードを一度だけ書き換える――カウント、バケット、タイムスタンプ、一回の `SLOAD` に対して一回の `SSTORE`――ため、レジストリを最新に保つ限界コストは、ユーザーが既に送っていたトランザクションの中に乗る。 一つのワードがなぜ重要かは、掛け算の問題である。Solver はペアごとに最大 `MAX_CANDIDATES = 8` 個のベニューを、最大三つのトポロジーにわたってプローブするため、一つの求解済み取引は、トークンを動かす前に二十数個のプールをスコアリングしうる。コールドスロットあたり 2,100 ガスでは、プールあたり五スロットのレイアウトはそのスコアリングパスを数十万ガスと見積もる。モノスロットはそれをプールあたり一回の読み取りと見積もり、Hub の `psisOf` はすべての候補のスコアを一回のバッチ呼び出しで返す。モノスロットはオンチェーンルーティングに適用された最適化ではない。それはオンチェーンルーティングがそもそも手頃な費用で成り立つ理由なのである。 ## §9 自己修復レジストリと活力場 Ψ 大半のアグリゲーターがベニューを把握しているのは、キーパーがオフチェーンでプールをインデックスし、リストをオンチェーンへ送り込むからである——それは信頼されたプロセス、陳腐化の時間窓、運用上の依存という三つを伴い、経路をオンチェーンで解くプロトコルにはいずれも受け入れられない。BlazePhoenix は逆の立場を取る：レジストリは流動性を取引することによってそれを学習する。 ### §9.1 取引による学習と、ペア証明 実行されたすべてのレッグで、Router は Hub の `recordSwap`（`onlyRouter`、`whenLive`）を呼び出し、プール、その種別、その手数料、ペア、金額、そして計測した深さを渡す。Hub はまず、Router が実行し得なかったはずの種別を拒否する（`KINDS_EXECUTABLE`）——これはデプロイ時の Router がそのままであり続けることに依存しない局所的な防御である——その後、二つの処理経路のいずれかを取る。 既知のプールではモノスロットが更新される：スワップ回数は*現時点で減衰済みの*基数から増加し、深さバケットが再計算され、ブロック番号と実時間のタイムスタンプが進む——パックされた一ワードを書き換えるだけで、外部呼び出しはない。未知のプールはコールドパスを通る。まず受け入れ審査（後述の `_canInsert`）を通過しなければならない。次に、格納しようとしている主張を証明しなければならない：ペア形状のすべての種別（`KINDS_PAIR_PROOF` = V2、V3、Solidly、Algebra）について、Hub はプール自身の `token0()` と `token1()` を読み、それらがペアと一致することを要求する——`staticcall` は最大二回で、コールドパスでのみ行われる。`recordSwap` へのすべての引数は Router の経路に載って運ばれる呼び出し元制御のコールデータ（プール、種別、深さ）であり、この証明がなければ、攻撃者は自ら書いたコントラクトを、自ら選んだペアの下に、自ら選んだ深さで、どちらのトークンも保有しないまま登録できてしまう。二つの V4 種別では `pool` フィールドがバイトコードを持たない切り詰められた ID であるため、証明は再導出となる：ティック間隔を復元し、ID を再計算して照合する。これはフックなしのプールに限られるため、フック付きプールがこの扉から登録されることは決してない。ネイティブ V4 プールは `(address(0), T)` の両方の向きで照合される。不一致の場合は登録を*スキップ*し、決してリバートしない。ユーザーのスワップはすでに決済されており、レジストリの判断を理由に失敗してはならないからである。 登録時のペア証明は 2026 年九月に新たに加わったものであり、それを生み出した計測は §15 のものである：十五個のソース変異をすべてのステートフル不変条件に対して実行したところ、この証明を除去したミュータントは初回の実行ですべてのキャンペーンを生き延びた。他のトークンを取引するプールを Hub に提示したテストが一つもなかったからである。現在の Hub キャンペーンは毎回それを行い——ペアを逆にしたもの、トークンを一つだけ共有するもの、二つとも無関係なもの——`invariant_ActiveEntriesTradeThePair` がすべてのアクティブなエントリの `token0`/`token1` を読む。このミュータントは今やガードエントリとなり、この不変条件によって殺される。ディスカバリーも、問い合わせ型のプールに対して同じ証明を行う（§7）。 稼働させるべきインデクサーは存在せず、サーバーが停止しているためにプロトコルが盲目になる瞬間もない。オペレーターの `seedPool` の扉はデプロイ時にペアを事前投入し（ティア 0、キュレーション済み）、パーミッションレスな `claimV4` の扉はフックなし V4 プールをそれ自身の証明の下で受け入れる（§5.1）。いずれも最適化であって依存ではない——空のレジストリは、通常の取引を通じて自ら修復し、充填されたレジストリとなる。 ### §9.2 スコア 活力場 Ψ は品質と容量を分離し、モノスロットとペアのライブなブリッジ状態のみを読む（Core `psi`）： $$ \Psi(s, t) \;=\; V(s, t)\cdot 2^{\,b(s)} \cdot \left(1 + \tfrac{2{,}500}{10^{4}}\,\mathbf{1}_{\mathrm{bridge}}\right)\cdot\left(1 + \tfrac{500}{10^{4}}\,\mathbf{1}_{\mathrm{conc}}\right) $$ ^e10 深さバケット $b = \min(15, \lfloor \log_{10}(d / 10^{15}) \rfloor)$ は、その重み $2^{b}$ を通じてスコアに入る：深さが一桁増すごとに重みは二倍になるため、深さは劣線形に効く——深いプールは確実に優遇されるが、単に健全なだけのプールが巨大なプールによって消し去られることはない。ブリッジペア上のプールは +25 % を得る。ブリッジは流動性グラフの結合組織だからである。集中流動性プールはさらに +5 % を得る。ブリッジボーナスは、登録時に凍結されたビットからではなく、一つの生成元（`_pairBridged`）によってペアからライブに読まれ、ペア内では一様であるため、同一ペアのプールの順位を入れ替えることは決してない。 **減衰——単一の機構。** 活動量は、単一の実時間ルール（`_decayedSwapCount`）によって、アイドル時間に応じて減衰する： $$ V(s,t) \;=\; \mathrm{swapCount}(s) \;\gg\; \left\lfloor \frac{t - t_{\mathrm{last}}}{24{,}576\ \mathrm{s}} \right\rfloor, \qquad V = 0 \ \text{once the shift exceeds } 31. $$ ^e11 ステップは `VITALITY_DECAY_STEP_SECONDS = 24,576`——約 6.8 時間——であり、三十二回の半減でいかなるスコアも消滅するため、沈黙したプールは 786,432 秒、約 9.1 日後にゼロとなり、完全に退去可能となる。一回のスワップでプールは復活し、その復活は誠実である：回数は減衰が残したところから再開し、減衰前の合計からは決して再開しないため、長い沈黙の後のダストスワップ一回でプールの蓄積した順位を回復することはできない。スコアラーは二種類のゼロを区別する：*死んだ*スロット——空のもの、一度も更新されていないもの、あるいは期限を過ぎたもの——は真のゼロとなりランキングから外れる一方、*生きている*スロットのうち、小さな回数がシフトによって丸めで消えたにすぎないものは一に下限設定されるため、実在し最近触れられたプールが丸めの副作用で消えることは決してない。時間窓を実時間の秒で定めているのは意図的である：ブロック数で数える窓はチェーンごとに異なる実時間を意味し、16 ブロックごとにシフトしていた以前の実装は、文書の記載より約 128× 速くゼロへ減衰していた。  ### §9.3 退去 各ペアが保持するプールは最大 `MAX_SLOTS = 16` 個である。十七番目のプールが参入しようとすると、Hub はすべての既存プールを完全な Ψ でスコア付けし——深さ、ボーナスなどすべてを含むため、深い新参者は浅いが温まった居座りを押し出せる——新参者の予測スコアが最弱の既存プールをマージン付きで上回る場合にのみ、新参者を受け入れる（`_canInsert`）： $$ \Psi_{\mathrm{new}} \;>\; \Psi_{\mathrm{worst}} + \left\lfloor \Psi_{\mathrm{worst}}/4 \right\rfloor, \qquad \Psi_{\mathrm{new}} = 2^{\,b(d_{\mathrm{new}})} $$ ^e13 ここで新参者は保守的にスコア付けされ——活力は一、自身の深さバケット、ボーナスなし——深さゼロの新参者は即座に拒否される。このマージンはグリーフィングの経路を塞ぐ：単純に最下位を押し出すルールの下では、敵対者は十六の浅いスロットをかろうじてアクティブに保ち、深い競合を締め出すことができる。マージン付きで Ψ により順位付けすれば、真に深いプールが依然として勝つ。この定数の限界は、それが強制される箇所に明記されている：新参者の重みは二の冪である一方、既存プールのスコアは連続値であるため、実効マージンは約 100 %（一をわずかに上回る既存プール）から約 25 %（51 の既存プールに対し、受け入れ可能な最小の新参者が 64）まで変化する。ルールの 25 % は挙動の下限でもあり、それを下回ることは決してない。頻繁に取引される既存プールは、減衰が作用するまで押し出しにくい——アイドル二日で七回分の半減を失う。パーミッションレスな V4 クレームも、プールの計測された流動性を深さとして、同じマージンをクリアしなければならない。 ### §9.4 ディスカバリーと、そのガスのつまみ ディスカバリーは公開の view である：任意のペアについて、Hub はファクトリーリストを巡回し、§7 のモードによって候補を導出し、`hasCode` とペア証明を適用する。Solver はその結果を登録済みの集合とマージし、アドレスで重複排除するため、どちらの情報源も他方を抑え込むことはできない。ガスを抑えるため、Solver は鮮度ゲート（`_registryFresh`）を適用する：そのペアについて少なくとも `MIN_FRESH_VENUES = 3` 個の*キュレーション済み*登録ベニューが `DISCOVERY_TTL_SECONDS = 3,600` 以内に触れられていれば、レジストリを信頼し、導出のスイープを省略する。保証できるのはキュレーション済みの行（ティア 0）のみである：パーミッションレスな行は最初にスワップした者が書き込むものであり、それを数えていたため、一時間に三回のダストスワップで鮮度を保たれた三つの自己登録ダストペアが、あるペアのディスカバリーを停止させ、登録されていないすべての誠実なベニューを隠すことができた。パーミッションレスな行は候補として残るが、もはや経路を選ぶことはない。このゲートはガスとカバレッジのつまみであり、決して安全性のパラメータではない——Iron-Law フロアとユーザーの最小値は、レジストリがどれほど古くとも、あらゆる約定を保護する。どちらもレジストリを一切読まないからである。 ### §9.5 設定面 Hub の登録の扉は、入口で守られている。`addFactory` は、いかなる状態も書き込まれる前に（`HubE(5)`）次のものを拒否する：`KINDS_ROUTABLE` に含まれない種別、`MODES_VALID` に含まれないモード、init-code ハッシュがゼロの CREATE2 モード、V2 種別以外に結び付けられた V2-salt スロット、Solidly 以外の種別に結び付けられた clone スロット、V3 または Algebra 以外に結び付けられた V3-salt スロット（Algebra の登録ではすべての手数料をゼロのセンチネルとして宣言することが要求される）、そして V4 以外の種別に結び付けられた、あるいは手数料とスペーシングのリストの対応が誤っている V4 derive-scan 行。既知のファクトリーはその場で更新され、二つ目の行が与えられることはないため、一つのアドレスが十六の席を使い尽くすことはできない（`HubE(4)`）。制御が放棄された後は、ランタイムコードが変化したファクトリーを再び有効化することはできず、derive 行を ask 行へ変換することもできない。`allowHook` は受け入れ時にフックのコードハッシュを固定し、フックは許可リストに載っており*かつ*変化していない間だけルーティング可能である（`isHookLive`）。放棄後は許可リストからの除外は不可能となり、変化したフックは永久に停止されたままとなる。ブリッジは最大 `MAX_BRIDGES = 3` 個である。`addBridge` は放棄後も存続するキュレーターの権限であり、`removeBridge` は放棄とともに消滅する制御の権限である。 ### §9.6 構造的境界 一つの文が上記のすべてを限界づける：**Ψ はベニューを隠すことはできても、誤って値付けすることは決してできない。** スコアは候補集合を順位付けし、切り詰める——見積もり、フロア、配分のいずれもそれを読まない。それらはトランザクション内の計測から計算されるからである。記憶が経路選択に到達するのは、省略を通じてのみである。レジストリが何を信じていようとも、それが表に出し得る最悪のものは、より悪いが実在するライブ価格であり、そのような価格が通過させ得る価値は、信頼帯、フレーム内で再導出される Iron-Law フロア、ユーザーが設定した最小値のうち最も厳しいものによって上限が定められる。元本は構造上、手の届かないところにある。レジストリは何が見えるかを決めるが、何が支払われるかについては投票権を持たない。 ## §10 ルーティングと分割アロケータ 定積プールは一つのルールで価格を付ける：二つの準備金を掛け合わせたものが決して縮小してはならない。手数料保持率 $\gamma$（0.30 % のベニュー手数料は $\gamma = 0.997$ を意味する）で $\Delta$ を投入すると、$y\,\gamma\Delta / (x + \gamma\Delta)$ を受け取る。分母には自分自身の入力が含まれている：一つのプールに多く押し込むほど、追加の各トークンが支払う量は悪化する。スリッページは算術であり、その治療法もまた算術である：同じ注文を同一ペアの複数のプールに分割すれば、各プールの動きは小さくなる。 **計算例 2——二つのプールにまたがる分割。** 同一ペアの二つのプール（いずれも 0.30 %）に対する 100 の注文一件：プール A は片側 1,000、プール B は片側 4,000 を保有する。 | 経路 | 算術 | 受取額 | |---|---|---| | 100 をすべて A へ | $1{,}000 \times 99.7 / 1{,}099.7$ | 90.661 | | 100 をすべて B へ | $4{,}000 \times 99.7 / 4{,}099.7$ | 97.275 | | A へ 20、B へ 80 | $1{,}000 \times 19.94 / 1{,}019.94 \;+\; 4{,}000 \times 79.76 / 4{,}079.76$ | $19.550 + 78.201 = 97.751$ | 20 / 80 の分割は推測ではなく、アロケータ自身の選択である：重みは最も深い候補に対する計測された深さに比例する——A の重みは 10,000 のうち $1{,}000/4{,}000 = 2{,}500$、B の重みは 10,000——したがって A は注文の $2{,}500 / 12{,}500 = 20$ % を受け持つ。この分割は最良の単一プールを 0.476 トークン、すなわちその 48.9 bps 上回る。続いて分割ゲートが、その利得が二つ目のレッグに見合うかを問う：閾値は $97.275 \times (1 + 25 / 10^{6}) = 97.278$ であり、97.751 はこれをクリアするため、分割は維持される。すべての行は電卓で検算でき、その効果は積み重なる：価格インパクトは*自身の*割り当て分に対する各プールの応答であるため、受け入れ可能なレッグが経路に加わるごとに、すべてのプールの動きは小さくなる。  ### §10.1 経路の形状と予算 Solver は三つのトポロジーを構築し、最大化するものを返す（`findBestRoutePlan`、次点をフォールバックとする）：一ホップの*直接*経路、一つの中間トークンを経由する*ブリッジ*経路、二つを経由する*ダブルブリッジ*経路——三ホップであり、Solver が構築する最も深い形状であり、Router が受け入れる上限でもある（`MAX_HOPS = 3`）。各ホップは、意図的に分離された二つの予算の下で並列レッグに分割される：`MAX_LEGS_PER_STAGE = 4` は*一ホップに何本のレッグが収まるか*に答え、`MAX_LEGS = 11` は*一経路に何本収まるか*に答える。両者を合わせると 4、4 + 4、4 + 4 + 3 となる——三ホップ経路の最後のホップが三本となるのは、全体の上限がそれを圧迫するからであり、誰かが特別なケースを書いたからではない。ブリッジは、Hub 内でオペレーターが設定した最大三つのトークンの集合から来る。Solver は設定されたすべてのブリッジを展開し、取引ごとに計測された `totalOut` に決定させる。計測されたインパクトが `MAX_ROUTE_IMPACT_BPS = 9,000` を超える経路はそもそも返されず、受け入れ可能な経路のないペアは、経路を捏造するのではなく `SolverE(5)` で拒否する。Router は、呼び出し元が提供する任意の経路に対し、ホップあたり五本という独自のレッグ上限を強制する（`MAX_LEGS_PER_HOP = 5`、`RouterE(3)`）。 ### §10.2 ファネル 各ペアについて、Solver は登録済みのプールと、レジストリが新鮮でない限り（§9.4）ディスカバリーされたプールを集める。デルタを変更するフックを持つプールを除去し（射影子 Ξ。ここで適用するのは、計画用の扉が Router の拒否する経路を組み立てることが決してないようにするためである）、和集合を一回のバッチ呼び出しで Ψ により順位付けし、`MAX_CANDIDATES = 8` 個を残す——これは意図的にどのホップのレッグ予算よりも広く、いくつかの薄いベニューの後ろに掲載された深いプールも視野に入り、重み付けされ、リストの順序によって締め出されることなくそれらを押し出すことができる。Ψ が完全に同点の場合は手数料の低い方が優先されるため、コールドなレジストリにおいてファネルは履歴ではなく価格の関数となる。 次に各候補は、注文の百分の一（`amountIn / 100`、それがゼロに切り捨てられる場合は注文全体）で一回だけ探査され、同じ呼び出しで限界レートと深さが取得される。限界レートは、フルサイズのレートが混同してしまう二つのシグナルを明確に分離する：価格が古いプールはサイズにかかわらず誤った限界レートを持つ一方、小さいが健全なプールは正しい限界レートを持ち、フルサイズの出力が劣るにすぎない。ペア形状の種別では、宣言された深さはプールが物理的に保有する出力トークンの量で上限が設けられるため、各側のトークンを一つずつしか保有しないのに $3 \times 10^{30}$ を宣言する合成ペアは、実際の保有量で重み付けされる。 ### §10.3 信頼帯 配分の前に、候補は信頼されなければならず、その信頼は偽造にコストがかかる量に錨を下ろさねばならない。帯の中心は、生き残った候補の限界レートの**深さ加重中央値**である（`_depthWeightedMedian`）：レートは深さを伴ったままソートされ、中央値は*深さの質量*の半分を通過した時点のレートである。その崩壊点は質量の 50 % であり——これを動かすには、攻撃者はペアの実流動性の半分を深さで上回らなければならない——重み付けに用いる深さは、準備金型プールでは `getReserves`、集中流動性プールではアクティブ流動性、V4 では計測された流動性である：いずれもプールへの単純な寄付では動かない量である。この最後の性質こそ、アンカーが最大の実残高ではない理由である：プールへの送金は準備金も価格も動かさずに `balanceOf` を膨らませ、寄付者が回収可能であるため、リスクにさらされた資本ではない——外部の研究者が、以前の残高アンカーが寄付によって乗っ取られることを実証し、アンカーは置き換えられた。限界レートが中心から `MEDIAN_FILTER_BPS = 500`（±5 %）を超えて乖離する候補は、何かが送られる前に除外される。候補が一つだけの集合はまったくフィルタされず、中心がゼロに丸められる集合は単純な中央値にフォールバックするため、本来ルーティング可能なホップが丸めの副作用で潰されることはない。この幅は較正された選択である：流動性ステーキングのペアを見積もる Solidly の stable カーブは典型的に真のレートから 20–40 % 離れており、除外される。この取引サイズでの読み値が中心からわずかに異なるだけの健全なプールは受け入れられる。§15 のメタモルフィックレーンは帯を外部から計測した：一つのプールが兄弟プールから $10^{10}$ 離れた価格を付けている場合、プランは外れ値単独の場合より 35 % 少なく支払う——中央値がそれを信じることを拒んでいるのである。 ### §10.4 アロケータとその三つのガード 重みは計測された深さに比例し、集合内の最大の深さに対して正規化される（`_weights`）——正規化は一つで、モードはない。すべてのファミリーの深さはトークン建てであり（§4.2）、それゆえ比較可能だからである。比例配分は敵対的な環境において堅牢な選択である：反復もベニューごとの曲率モデルも必要とせず、一様分割が生む壊滅的な失敗を回避する——計測された WETH/USDC の事例では、790 WETH のプールと 0.34 WETH のダストプールに 50 / 50 で分割すると 1,302 USDC が返されたのに対し、深いプールに集中させると 1,638 が返された。深さ加重配分は 1,638 を返した。ファネルにホップの予算より多くの生存候補がある場合、*重みによる*上位の予算数の候補が残されるため、遅れて掲載された深いプールが、早く掲載された薄いプールを押し出す。その後、三つのガードが、配分とそれが成る経路との間に立つ。 - **容量クランプ。** 単一ティックの集中流動性の式は、現在のティックの流動性があらゆる価格にわたるかのようにモデル化するため、薄いプールではプールがかつて保有したことのある量を超えて約束し得る——観測されたある事例では 117× であった。そのため、プール形状のベニュー（種別 1 と 6）上の集中レッグは、プールの*計測された*実際の出力トークン残高の `MAX_CONC_DRAIN_BPS = 3,000`——30 %——にクランプされる。クランプは V4 レッグには及ばない：シングルトンはすべてのプールのトークンを一つの残高で保有するため、Solver は種別 4 と 8 では読み取りを省略し、V4 の約束は §11.3 のフロアを超える物理的な上限を持たない——フロアがその上限である。クランプは二段階である：見積もりがプールの保有量全体を超える場合、その約束は物理的に不可能であり、クランプはレッグの*確約された入力*を同じ比率で削減し、解放された入力を残りのレッグへ順に回し、ルーティング不能な分は呼び出し元へスイープして返す。約定が積極的だが可能な場合は、約束のみに上限を設ける。その場合に資本を削ると、問題なく実行されるプールで部分約定を強いることが計測で示されたからである。準備金で上限づけられる式は過剰に約束できないため、手を加えない。このクランプは、帯がそうしないところで意図的に `balanceOf` を読む：帯は寄付によって歪められ得る*相対的な*問いを立て、クランプは*物理的な*問い——このプールはこれを支払えるか——を立てる。そして寄付は、プールが実際に支払える量を増やすのである。 - **分割ゲート。** 追加の各レッグには実際のガスがかかるが、アロケータは意図的にガス価格の項を含まない。ネイティブトークン建てのガスを取引トークン建ての出力と比較するには、プロトコルが持つことを拒むまさにその価格オラクルが必要になるからである。オラクルを使わない代理指標が閾値である：分割は $\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}} \cdot (1 + 25/10^{6})$ の場合にのみ維持され——`MIN_SPLIT_IMPROVEMENT_PPM = 25`——そうでなければ配分は一本のレッグへ縮退する。閾値は計測された数値である：レッグのガスとその改善との真の損益分岐点は Base 上で 3 ppm と計測され（追加レッグ一本あたり 320 バイトのコールデータ、バイトあたり 105.5 ガス）、ゲートはその約八倍に置かれている。百万分率で表すのは、ベーシスポイントの四分の一はベーシスポイントでは存在しないからである。その経緯——20 bps、次に 5、次に 0.25——は、一度も計測に対して較正されたことのない二つの値の記録である。ゲートが経路を縮退させるとき、一つではなく二つの単一レッグ候補をフルサイズで計測する——最も深いプールと、最良の限界レートのプールである——限界レートは浅いプールを実際よりよく見せる一方、深さはサイズ全体を運ぶための代理指標だからである。より良い約定が勝つ。 - **マージンではなく計測による保険。** 以前の設計では、レッグ間のドリフトに対する保険として、長い経路のすべてのレッグを計画時に 5 bps 削っていた。その後ドリフトが同一ブロック内の Base の九つのペアで計測された：最悪のケースで −2 bps であり、保険より一桁小さかった。その保険は、誠実なマルチレッグ経路がすべての取引で支払っていたものであり——計測されたハザードの 27× であった。この削減は廃止された。実現された出力に対して強制されるフロアが、計画コストゼロでそのリスクを担う。計測は平穏な時間窓で行われたものであり、反論はソース内に記録されている：保守性を再び導入することがあれば、正しい場所はチェックされるフロアであって、順位付けにしか使われない推定値ではない。 組み立てられた経路は、Router が再導出するものを運ぶ：各レッグの確約された入力と期待出力、経路の割合加重インパクト、そして Solver が Router の強制するのと同じ算術から表明するフロア Φ である（§11）。Solver はまた、`THETA_GAS` の段階表から種別ごとに各レッグの実行を価格付けし、合計を `estGas` として公開する。これは経路が運ぶ助言的な数値であり、オンチェーンでは何もそれを読まない。読者の経験則は、この機構全体を経ても変わらずに残る：確定する前に、ルーターが主張する改善とウォレットが示すガスを比較せよ。 ## §11 実行層と Iron-Law フロア Φ Solver は提案し、Router は処置する——アトミックに、さもなくば一切行わない。Router は資金を動かす唯一のコントラクトであり、トランザクション間で資金を一切保有せず、一つの原則に基づいて構築されている：関心事ごとに一つの機構を、普遍的に適用する。計測できるものは何も仮定しない。 ### §11.1 四つの扉、一つの実行器 | 扉 | シグネチャ（抜粋） | 認可 | 経路 | |---|---|---|---| | `swapExactIn` | `(route, amountIn, userMinOut, recipient, deadline)` | 従来の `approve` + `transferFrom` | コールデータから | | `swapExactInWithPermit2` | `(route, amountIn, userMinOut, recipient, deadline, permit, signature)` | 正規の Permit2 コントラクトを介した一段階の Permit2 署名転送。Router への常設のアローワンスはない | コールデータから | | `swapExactInNative` | `(route, userMinOut, recipient, deadline)` payable | ネイティブ値。扉で一度だけラップされる。`weth` が接続されるまではフェイルクローズ（`RouterE(3)`） | コールデータから | | `swapBestExactIn` | `(tokenIn, tokenOut, amountIn, userMinOut, recipient, deadline)` | 従来型 | Solver によってフレーム内で解かれ（`findBestRoutePlan`）、その後、支払者を明示的に引き渡す自己呼び出しを通じて実行される | トランザクション内で Solver を呼び出すのは `swapBestExactIn` のみである。他の三つは、呼び出し元が Quoter を通じてオフチェーンで無料で計算した経路を受け取る（§12）。四つすべてが一つのプライベートな実行器（`_execute`）に収束するため、以下のすべてのチェックはすべての扉で実行される。EIP-7702 の委任アカウントは、コントラクトと同様に同じ扉を呼び出す。そのための別個のエントリは存在しない。 何かが動く前に、二つの拒否が実行される。最小値ゼロはすべての扉で拒否される——`RouterE(10)`、例外なし、互換性フラグなし——最小値は、コントラクトがユーザーに代わって計算できない唯一の下限であり、存在しないかもしれないガードはガードではないからである。そして、三ホップを超える経路、一ホップに五本を超えるレッグを持つ経路、あるいは入力トークンが前のホップの出力でないホップを含む経路は `RouterE(3)` で拒否される：ホップの連続性こそが、各中間トークンのスワップ前の「外来」残高を既知にするものであり、そのため細工された経路が、取り残されたトークンを入力として指定し、Router が保有するその全残高をスワップへ組み入れることはできない。 ### §11.2 最初の命令からの計測 どの扉が使われても、Router が最初に行うことは到着したものの計測である：名目上の金額を信頼するのではなく、引き出し後の自身の残高差分を読むため、転送時に不足して届くトークンも真のサイズで経路に入る。ベースラインは一度だけ生まれる：入力トークンのスワップ前残高（`baseIn`）と出力トークンのそれ（`toutStart`）がエントリ時に取得され、以降のすべての計測はそれらに対する差分であるため、すでにコントラクト内にあるトークン——ダスト、寄付、無関係な履歴から取り残されたもの——は、スワップが支払い得るものから除外される。自身のベースラインを下回って支出しようとする経路は、チェック付き算術で失敗する——それは安全な結果である。それらの資金はそもそもこのスワップが支出すべきものではなかったからである。 マルチホップ経路は計画であり、計画はすべてのホップ境界で現実と出会う。Router は各ホップのレッグを*実際に*到着した残高に対して再スケールする——ホップ 0 は計測された引き出し後の入力に対して、経路が確約した量を上限として（したがって Router は事前に削減された注文を薄いプールへ無理に押し込むことはない）、以降の各ホップは外来ベースラインを超える計測されたブリッジ残高に対して——各レッグは $\mathrm{amt} = \mathrm{amountIn}_{\mathrm{leg}} \cdot \mathrm{real}/\mathrm{planned}$ を実行する（`_hopScaleImpactAndQuote`）。ゼロにスケールされたレッグはスキップされる。未使用の入力とブリッジの残余は支払者へスイープして返され、決して Router には返されない。同じパスで各レッグのプール状態を一度だけ読み、その単一の読み取りから、レッグのスケール後の金額、計測されたインパクト、フレーム内見積もり——フロアが消費する三つの量——を生成するため、準備金型と集中型のファミリーは計測のために追加の `staticcall` を支払わない。 ### §11.3 すべてのレッグの下にある三つのフロア **レッグごとのフロア。** 各レッグの Router 出力残高への計測された寄与は、その基準値の `LEG_FLOOR_BPS = 8,000`——80 %——に達しなければならず、さもなくばスワップ全体が `RouterE(5)` でリバートする（`_execScaled`）。そのため、サンドイッチされた、あるいは操作されたプールが一つでもあれば、それ以外は健全な合計の中に損失を隠すのではなく、トランザクションは即座に失敗する。基準値は、呼び出し元が表明した見積もりを実際に支出された金額に比例配分したものであり——表明がフレーム内で計測された見積もりの `MIN_QUOTE_COVERAGE_BPS = 5,000` 未満しかカバーしない場合は、常にその計測された見積もりへと*引き上げられる*。これは意図的に最小ではなく最大である：フロアにおいて、デフレートされた主張に対する `min(claimed, measured)` はデフレートされた方を返して緩むが、それこそがこのゲートが塞ぐ攻撃である。ガードはフロアの根拠——呼び出し元の表明またはフレーム内見積もり——が何かしらあれば常に実行されるため、経路にゼロを書き込んでも、もはや呼び出し元自身のフロアが無効化されることはない。その限界：計測可能な見積もりも表明もないベニューは、集計フロアとユーザーの最小値へと委ねられ、それらがいずれにせよその上限を定める。 **ホップごとの集計フロア。** レッグごとのフロアは局所的だが、合成は大域的である：$L$ 本のうち一本のレッグを握る攻撃者は、どの単一のフロアにも失敗することなく、ホップの約 $20\,\% \cdot (L-1)/L$ を抜き取ることができる。そこで各ホップは、*平均的な*表明済みレッグ一本が正当に失い得る量までしか失ってはならない：$\sum \mathrm{got} + \lfloor (\mathrm{BPS} - \mathrm{LEG\_FLOOR\_BPS}) \cdot \lfloor \sum \mathrm{attested} / n \rfloor / \mathrm{BPS} \rfloor \ \ge\ \sum \mathrm{attested}$——スラックは平均表明レッグの 20 % であり、さもなくば `RouterE(5)`。最大ではなく平均であるのは、最大の下では攻撃者が自身のレッグを膨らませて共有予算を膨らませるからである。レッグが一本の場合、このルールはレッグごとのフロアに正確に一致する——構造上、新たな硬直性はゼロである。 **経路フロア Φ** は §11.5 で扱う。 ### §11.4 一つのコールバック、一つのアンロック すべての V3 形状のベニュー——Uniswap V3、Algebra、集中流動性の Solidly フォーク、Pancake V3、Sushi V3——は、異なるコールバック名の下で同じフラッシュ会計パターンを用いる：プールはスワップの途中で token0 のデルタ、token1 のデルタ、任意のデータを伴ってコールバックし、支払いを要求する。Router はフォークごとに名前付きコールバックを一つずつ用意するのではなく、それらすべてに応答する単一の `fallback` を公開する——**単一コールバックの原則**である：二つのデルタを読み、その符号から負っているトークンを特定し、正確にその額を支払う。その際、進行中のレッグのコンテキストはトランジェントストレージ（`TSLOT_POOL`、`TSLOT_TOKEN`、`TSLOT_AMT`）から取得する。fallback は誰でも到達可能であるため、三つの面で守られている：現在のレッグについて確約されたプールにのみ支払い、進行中のレッグがない場合には動作を拒否し（トランジェントなコンテキストはスワップ間でゼロである）、レッグに記録された予算を超えて放出することは決してない——一つのレッグ内での二度目の要求は `RouterE(6)` で拒否される。新たな名前のコールバックを持つ新規ローンチの V3 フォークも、デプロイされたその日からサポートされる。 V4 シングルトンは同じホップインターフェースの背後にラップされる：`unlock`、次にスワップ、`sync → settle → take`、再ロックであり、通貨はトランジェントストレージで運ばれ、§5.3 のネイティブの継ぎ目を用いる。いずれかの V4 レッグが実行される前に、Router はフックアドレスを読み、そのビットがデルタを変更する権限を宣言している場合はレッグを拒否する（`RouterE(9)`）。ふるいにかけられたフックが、実行されるフックである。正規の PoolManager はアンロックデータをそのまま返すからである（`test/V4SievedHookIsTheExecutedHook.t.sol`）。経路形状のルールは経路全体にわたる正規順序である：フック付きレッグが一度実行されたら、このホップでも以降のどのホップでも、その後にフックなしレッグは実行されない（`sawHooked`）。そのため、フックは同じ経路の後続のフックなしレッグを、それが決済される前に観察することはできない。フック付きレッグが前のホップに置かれてよいのは、その後のすべてのレッグもフック付きである場合に限られる。 **転送時手数料は、それに耐えられるレッグで。** 一部のトークンは転送のたびに不足して届く。定積レッグでは、Router はこれを正規のパターンで処理する——まず転送し、次に同じ転送後の状態でプールの準備金と残高を読み、プールが実際に見る差分に基づいて出力を価格付けする——これは構造上正しい量である。プール自身の不変条件がチェックするのはまさにその量だからである。この分岐はトークンが不足と計測された場合（`TSLOT_FOT`）にのみ作動し、作動のコストもあわせて明記されている：見積もりから導出された経路フロアは税を考慮せずに計算されたものであり、そのスワップでは破棄される。プロトコルフロアは計測された正味の比率で再スケールされる（切り上げ、すなわち保守的な方向）。レッグごとの基準値も同じ比率で再価格付けされる。そしてユーザーの最小値が拘束的な制約となる。集中レッグは設計上、転送時手数料をサポートしない——フラッシュ会計は負っている額を正確に支払わなければならない——そのため、V3 のみの経路上の課税トークンは、プール内でリバートするのではなく、最初から `RouterE(13)` で拒否される。 ### §11.5 Iron-Law フロア Φ の全容 実行可能なすべての経路が実行されるべきではない——公正価値の 60 % しか返さない経路は取引しないより悪い——そのため、上記すべての下に、プロトコルが自ら導出するフロアが置かれる。それはベーシスポイント単位の保持率である（Core `ironFloorBpsShv`、`legShaveBps`）： $$ \mathtt{floorBps} \;=\; \max\!\left(\;9{,}600 - \mathtt{legShv} - \min(\delta,\, 10^{4}) - \sigma_{\ln}/10^{14},\;\; 8{,}000\;\right) $$ ^e15 $$ \mathtt{legShv} \;=\; \sum_{\mathrm{hops}} \left\lfloor 200 \cdot \frac{(\sum_{i} a_{i})^{2} - \sum_{i} a_{i}^{2}}{\sum_{i} a_{i}^{2}} \right\rfloor \;=\; \sum_{\mathrm{hops}} \left\lfloor 200\,(n_{\mathrm{eff}} - 1) \right\rfloor $$ ^e23 三つの定数がそれを決める：`FLOOR_BASE_BPS = 9,600`、`FLOOR_PER_LEG_BPS = 200`、`FLOOR_HARD_MAX_LOSS_BPS = 2,000`。フロアはクリーンな単一レッグのスワップでは 96 % から始まり、計測されたインパクト $\delta$ の一ベーシスポイントごとに一ベーシスポイント、*実効的な*追加レッグ一本ごとに 200 bps 緩み、決して 8,000 bps を下回らないようにクランプされる：入力が何であれ、プロトコルは参照値の 80 % 未満しか保持しない経路を承知の上で受け入れることは決してない。レッグ削減は、レッグ間での取引の*集中度*から計算される——$(\sum a)^{2}/\sum a^{2}$、すなわち実効レッグ数であり、$N$ 個の等しい割合では正確に $N$、一本の支配的なレッグでは正確に 1 となる——そのため分割は、それが真に分割されている程度に比例して緩和を得て、消えゆくほど小さな割合しか運ばないレッグは、ゼロを宣言しても一 wei を宣言しても、消えゆくほど小さな緩和しか得ない。コーシー–シュワルツの不等式により、分子がアンダーフローすることは決してない。インパクト項は、経路全体にわたるレッグの計測インパクトの割合加重平均である。二つの性質が定義の一部として明記されている：ボラティリティ項 $\sigma_{\ln}$ はシグネチャに存在するが、すべての呼び出し箇所でリテラルのゼロとして渡される——将来の推定量のためのフックであり、現在は不活性である——そして準備金ファミリーのインパクトは手数料を除外し、集中ファミリーのインパクトは手数料を含む。それぞれ、そのファミリーの仕様が与える形式に従っている。 Φ をヒューリスティックではなく強制たらしめるのは、それがどこで、何に対して実行されるかである。Router に渡される経路は助言的なフィールド——見積もられた合計、表明されたフロア——を運ぶが、Router はそのどちらも信頼しない：実行フレーム内で各レッグの実際のインパクトを計測し、渡された金額からレッグ削減を計算し、`floorBps` を再計算し、それを**最終ホップに実際に到着した金額でのフレーム内見積もり**に適用する——これは出力トークン建ての参照値であり、この実行中に読まれたプール状態から導出され、コールデータでは偽造できない。この参照値の選択こそが、ガードが発動し得ることを可能にしている：*実現された*出力の割合が、実現された出力を超えることは決してあり得ないからである。最終ホップをフレーム内で見積もれない場合——現在のティックにおける流動性の欠落、手数料センチネル——参照値はそのホップの表明済み見積もりにフォールバックする。それはカバレッジゲートによってすでに引き上げられ、転送時手数料の計測によって再価格付けされているため、薄いプールにおけるジャストインタイム（JIT）流動性の欠落がフロアを無効化することはできない。フロアのアンカーは常に、価値を動かし経路の出力を生み出すホップである。チェックは、出力側のいかなる手数料よりも前に、グロス出力に対して実行される。実効最小値は三者の最大値であり、 $$ \mathtt{effMin} \;=\; \max\!\left(\mathtt{userMinOut},\;\; \mathtt{route.singleOutFloor},\;\; \left\lceil \mathtt{finalHopQuote} \cdot \mathtt{floorBps}/10^{4} \right\rceil\right) $$ ^e16 その非対称性こそが要点である：呼び出し元が提供するフィールドは保護を強めることはできても、決して緩めることはできない。Solver は同じ金額に対して同じ `legShaveBps` と `ironFloorBpsShv` から `singleOutFloor` を表明するため、Solver が構築した経路では、表明されたフロアと強制されるフロアは構造上一致する（`test/FloorParitySolverRouter.t.sol`）。また §15 のレジームハーネスは、生成されたすべての行で二つのフレームを固定する：手数料が入力から差し引かれる場合、強制されるフロアは $[\mathrm{attested} \times (1 - \mathrm{fee}),\ \mathrm{attested}]$ の範囲にあり、手数料が出力から差し引かれる場合、表明されたフロアに等しい。  **計算例 3——二ホップ経路上のフロア。** 経路 A → WETH → B：ホップ 0 は 600 A をプール P へ、400 A をプール Q へ分割する。ホップ 1 は生成された WETH を一つのプール R に通す。フレーム内での計測：ホップ 0 のレッグはそれぞれ 100 bps と 60 bps のインパクトを示し、ホップ 1 のレッグは 40 bps であり、経路全体の割合加重平均は 80 bps である。実際に到着した WETH 量におけるホップ 1 のフレーム内見積もりは 1,000.000 B である。 1. ホップ 0 の集中度：$(600 + 400)^{2} = 1{,}000{,}000$、$600^{2} + 400^{2} = 520{,}000$、$n_{\mathrm{eff}} = 1.923$、削減 $= \lfloor 200 \times 480{,}000 / 520{,}000 \rfloor = \lfloor 184.6 \rfloor = 184$ bps。 2. ホップ 1 はレッグが一本である：$(\sum a)^{2} - \sum a^{2} = 0$、削減 0。合計 `legShv` = 184。 3. $\mathtt{floorBps} = \max(9{,}600 - 184 - 80 - 0,\ 8{,}000) = 9{,}336$：経路は参照値の 93.36 % を保持しなければならない。 4. $\mathtt{protocolFloorOut} = \lceil 1{,}000.000 \times 9{,}336 / 10{,}000 \rceil = 933.600$ B。 5. トレーダーが `userMinOut` = 990 B を設定し、Solver が `singleOutFloor` = 933.6 B を表明している場合、`effMin` = 990 B となる——誠実な経路ではそうあるべきように、ユーザー自身の下限が拘束的なものとなる。998.4 B の引き渡しは決済され、985 B の引き渡しは `RouterE(5)` で拒否され、トランザクション全体は、すべてのプールのスワップを含めて、起こらなかったことになる。 トレーダーが `userMinOut` = 900 B を設定していたなら、プロトコルフロアが 933.6 B で拘束的となる：930 B での約定は、フレーム内参照値を 7 % 下回るため、ユーザーの数値はクリアしていても拒否される。 ### §11.6 決済と、その読み方 決済はフレームを開いたときと同じ方法で閉じる：計測によってである。Router はエントリ時のベースラインに対する出力トークンの差分をグロス出力として取り（ゼロなら `RouterE(8)`）、上記のフロアチェックを実行し、レジームが定める箇所で手数料を徴収し（§13）、正味額を受取人へ転送して*受取人の*残高差分を計測し、その引き渡された金額に対して `userMinOut` を強制する——そのため転送時手数料のある出力トークンがユーザーを下限より下に滑らせることはできない——そして手数料台帳を一度読む：プロトコルに何も支払わなかった決済は拒否され（`RouterE(15)`）、アンカー付き経路では二度目の支払いが拒否される（`RouterE(16)`）。その後、成功パスでのみ、実行された各レッグについて一度ずつ Hub の `recordSwap` を呼び出す（`_recordHits`）。その際の金額は、そのホップが支出できた金額——計測値対宣言値の比率を各レッグに適用したもの——であり、これがスワップが行う唯一の外部書き込みである。フロアが拒否した場合は何も書き込まれない。 すべての決済は `ExecutionProof(user, tokenOut, quoted, realized, floorUsed, blockNumber)` を発行する：実行と同じフレームで生成された参照見積もりであり、オンチェーンの系列として公開され、誰でもそのブロックにおける `findBestRoutePlan` への `eth_call` によって再導出できる。そのフィールドを、過大な主張をせずに述べる：`user` は支払者であり、決して `msg.sender` ではない。`quoted` は最終ホップの見積もりである——それは経路ではなく最後のホップを証明する。`realized` は引き渡された量であり、受取人の側で計測される。`floorUsed` は上回らなければならなかったプロトコルフロアである。各 `Fee(token, amount, toT1, toT2)` イベントはトークンと分配を示す。 **計算例 6——決済の読み方。** 計算例 3 の経路が決済され、`ExecutionProof(0xUSER, B, 1,000.000, 998.400, 933.600, N)` と一つの `Fee(WETH, 0.014, 0.0042, 0.0098)` を発行する。 | 量 | 値 | 読み方 | |---|---|---| | `quoted` | 1,000.000 B | 実際に到着した WETH における最終ホップのフレーム内見積もり | | `realized` | 998.400 B | 受取人へ引き渡され、そこで計測された量。見積もりの 9,984 bps | | `floorUsed` | 933.600 B | 見積もりに適用された `floorBps` 9,336。約定はそれを 64.8 B 上回った | | `Fee` | 一つのイベントで 0.014 WETH | アンカー型レジーム：ホップ 0 が生成した 5.000 WETH の 28 bps を、ホップ 1 の入力で支払い、30 % が第一のトレジャリーへ。B からは何も取られていない | | `userMinOut` までの距離 | 8.4 B | ユーザーの 990 B の下限は 0.84 % の余裕を残した | 引き渡し額から見積もり額を引いたものは市場の答えであり、プロトコルの答えではない：手数料はより早い段階で WETH で差し引かれており、この経路には出力側の控除は存在しない。出力トークン建ての `Fee` イベントが現れるのは、ブリッジコインへの直接経路の場合のみである（§13）。 ### §11.7 Router の拒否 | コード | 意味 | 箇所 | |---|---|---| | `RouterE(1)` | 認可されていない制御呼び出し | `onlyControl` | | `RouterE(2)` | 一時停止中、または一時停止中の放棄の試み | `whenLive`、`renounceControl` | | `RouterE(3)` | 不正な入力——ゼロアドレス、未接続のネイティブ扉、ホップ数、ホップあたりのレッグ数、ホップの不連続 | エントリポイント、`_execute` | | `RouterE(4)` | 期限切れ | エントリポイント | | `RouterE(5)` | 出力がフロアを下回る——レッグごと、ホップごとの集計、経路フロア、または `userMinOut` | `_execScaled`、`_execute` | | `RouterE(6)` | コールバックが認可されていない——誤ったプール、進行中のレッグなし、二度目の要求 | `fallback` | | `RouterE(7)` | 再入 | `nrEntrant`（トランジェントロック） | | `RouterE(8)` | スワップ失敗——出力ゼロ、未知の種別、金額以上の手数料 | `_execute`、`_execScaled`、`_chargeHopFee` | | `RouterE(9)` | V4 フックがデルタを変更する | V4 レッグの事前確約 | | `RouterE(10)` | `amountIn > 0` で `userMinOut == 0` | すべての扉 | | `RouterE(13)` | 集中型のみの経路上の転送時手数料トークン | `_execute` | | `RouterE(14)` | レスキューがキューに入っていない、または 48 時間の遅延期間内 | `executeRescue` | | `RouterE(15)` | プロトコル手数料を支払わずに決済された | 手数料台帳、`_execute` の末尾 | | `RouterE(16)` | アンカー付き経路で手数料が二度支払われた | 手数料台帳、`_execute` の末尾 | コード 11 と 12 は割り当てられていない。API と同じほど列挙可能なリバート面こそが、§15 のレジーム配列がすべての行を一つのルール——決済するか、我々のセレクタで拒否するか——で判定し、それ以外のものを第三の道と呼ぶことを可能にしている。 ## §12 見積もりの提示面と、見積もりの経年変化 「あなたの見積もり」と呼ばれる数値の出どころは二か所あり、それらは別々のコードパスである。一つは署名前にインターフェースが呼び出す読み取り専用のプレビュー用コントラクトである **Quoter**、もう一つは Solver と Router が実行中のトランザクション内で見積もりを計算する **フレーム内パス** である。§4.4 は種類ごとの真実を示した。本節はその提示面を示し、両者の間の差を計測する。 ### §12.1 Quoter の提示面 | 関数 | 戻り値 | 備考 | |---|---|---| | `previewPlan(tIn, tOut, amountIn)` | `Preview` 一つ | Solver の計画を、手数料と安全バッファとともにまとめたもの | | `previewPlanWithMinOut(…, userMinOut)` | `Preview` 一つ | 同上。ただし `canExecute` は呼び出し元の最小値に照らして判定される | | `previewAndEncode(…)` / `previewAndEncodeWithMinOut(…)` | `Preview` 一つと `swapExactIn` 用の calldata | インテグレーターが見積もりを取得する方法であり、§12.2 の調査はまさにこれを用いる | | `batchQuote(entries[])` | 最大 `MAX_BATCH = 32` 件のプレビュー | 計画できないペアはゼロ初期化されたエントリを残す | | `previewPlanExact(tIn, tOut, amountIn)` | 経路と正確な純出力 | 厳密パス（Exact Pass）：すべての集中流動性レッグを、そのプール自身のスワップに対してドライランする | **プレビューとは何か。** `Preview` 構造体は設計上あくまで助言的なものであり、拘束力のある検査は Router がフレーム内で再導出するものである。そのフィールドは定義箇所に文書化されている。`grossOut` は計画の合計を反映する。`protocolFee` は出力に対する手数料の影響であり、Router が課すのとまったく同じようにレジームごとにモデル化される（§13）。すなわちアンカー型経路では一度、網羅型経路ではホップごとに一度、Router が丸めるのと同じく切り上げで計算される。`safetyBuffer` はレッグ間バッファであり、 $$ s \;=\; \min\!\left(\max(0,\, n-2) + 5a,\;\; 10\right)\ \text{bps} $$ ^e21 二レッグ以下ではゼロ、二を超えるレッグ一つごとに一ベーシスポイント、さらに *仮定された* 手数料（Core が上限のもとで置き換えた申告手数料）で価格付けされた定積レッグ一つごとに五を加え、全体で共通の上限十を課す。上限のないバッファはもはやバッファではなくフロアになってしまうからである。`netOut` は $\mathrm{grossOut} - \mathrm{protocolFee} - s$ である。`ironFloor` は証明されたフロアを反映する。`topology` と `bridgeUsed` は、ホップ数と、Router が用いる手数料アンカーから導出される。同じ生成元を同じように走査するため、プレビューと実行者が異なるブリッジを指すことはありえない。インテグレーター向けの規則は一文に収まり、本論文で最も重要な助言である：最小値は自分自身の価格予想から導出せよ。決してプレビューのフィールドから導出してはならない。 **厳密パス。** 集中流動性ベニューのプール厳密プレビューでは、Quoter はプールの実際のスワップ入口を呼び出す。プールは支払いを要求してコールバックする。Quoter のコールバックは支払う代わりにリバートし、計算されたデルタをリバートのペイロードに載せて返す。リバートによりすべての状態は巻き戻され、何も支払われず、デコードされた出力はライブ状態に対するベニュー自身のスワップを実行して巻き戻したものとなる。V4 も同様に扱われ、アンロックのコールバックがパックされたデルタとともにリバートする。ドライランを拒否するプールについては、計画自身の主張をその下の弦で縮尺した値が保持される。上回ることは決してない。AMM の出力は凹だからである。Hop 0 は計画がコミットした量で上限が設けられるため、容量でクランプされた経路が、Router が決して支出しない規模でドライランされることはない。2026-09-03 以降、返されるスカラーはプロトコル手数料控除後の値であり、プレビューが控除するのと同じく一度だけ控除されるため、そこから導出された最小値はフロアによって尊重される（`test/QuoterExactNetOut.t.sol`）。これは Quoter のプレビュー側の計測手段であり、拘束力を持つ面はフレーム内の再導出である。 ### §12.2 見積もりの経年変化 見積もりとは将来のブロックについての約束である。本調査はインテグレーターと同じ方法で見積もりを取得し（`previewAndEncode` がプレビューと calldata を返す）、世界を動かし（他者による同じプールを通る取引をゼロから三回、それぞれ浅い側の準備金の最大 3 % まで、すべてユーザーと同じ方向に行い、どの取引もユーザーに不利に働くようにする）、ゼロから十秒を経過させ、calldata を変更せずに実行する。定積モックによる三トークンの世界（A、B = ブリッジコイン、C。ブリッジへの直接経路、ブリッジを経由する二ホップ、逆方向の二ホップ）で 240 サンプルを取り、すべての結果を分類した（`test/QuoteDelayStatistics.t.sol`）： | 見積もりから実行までのドリフト | サンプル数 | 決済 | フロアにより拒否（`RouterE(5)`） | 受領額 / 予測額 — 平均 | 最小 | |---|---|---|---|---|---| | なし | 64 | 64 | 0 | 10,000 bps | 10,000 | | 1 – 100 bps | 43 | 43 | 0 | 9,952 bps | 9,803 | | 100 – 300 bps | 133 | 102 | 31 | 9,966 bps | 9,653 | | 見積もりから実行までの遅延 | サンプル数 | 決済 | 拒否（`RouterE(5)`） | 受領額 / 予測額 — 平均 | 最小 | |---|---|---|---|---|---| | 0 s | 17 | 15 | 2 | 9,989 bps | 9,857 | | 1 – 5 s | 99 | 89 | 10 | 9,959 bps | 9,653 | | 6 – 10 s | 124 | 105 | 19 | 9,983 bps | 9,659 |  時間は見積もりを動かさない。動かすのはドリフトである。すべてのサンプルで次が検証された：ドリフトのない見積もりはどの遅延でも決済され、予測どおりの額を正確に受け渡す（64 中 64）。決済がプレビューの証明したフロアを下回る額を受け渡すことは決してない。第三の結果は存在しない。期限経過後（`deadline = now + 5`、`+10` で実行）は 20 中 20 が期限自身のコード `RouterE(4)` で拒否され、決済されたものは一つもない。最大 1 % の不利なドリフトのもとでは、すべての見積もりが依然として約定し、予測の 2 % 以内に収まる。1–3 % のもとでは、フロアは証明された出力を下回って約定させるよりも、四件に一件を拒否し、約定したものは予測の 3.5 % 以内に収まる。これは §14 のサンドイッチ曲線を見積もりの側から見たものである。 **ライブ Base**（`test/fork/QuoteDelayFork.t.sol`、1,000 USDC → WETH、実際のプール、現在のブロックでフォーク上にデプロイしたプロトコル）：他に何も動かない状態で 0、3、6、10 s 後に実行したところ、見積もりは四回とも予測どおりの額を正確に受け渡した。同じ経路を通じて 10,000 · 50,000 · 200,000 · 1,000,000 · 5,000,000 USDC を先行して取引し、古い calldata を 10 s 後に実行したところ、五件すべてがフロアの内側で決済され、予測に対して 9,999 · 9,998 · 9,994 · 9,974 · 10,000 bps であった。千ドルの取引の前に百万ドルの取引があると千ドルの側は四分の一パーセントを失い、五百万ドルの取引は千ドルの経路が触れないプールを通ってルーティングされた。上記の分布はモックによるものである。ライブ Base は一つのブロックにおける一つのペアについての到達範囲を示すものであり、分布ではない。 ### §12.3 ABI を通じた見積もりのコスト ガスは外部呼び出しの前後で計測した。三トークンの世界ではそれぞれ四十の規模（`test/QuoterGasStatistics.t.sol`）、ライブ Base では五つの規模（`test/fork/QuoterGasFork.t.sol`）である： | 世界 | `previewPlan` 平均 | 最小 | 最大 | σ | `previewAndEncode` 平均 | σ | |---|---|---|---|---|---|---| | モック — 探索：ペアはファクトリーのみが知り、プールを一つ発見 | 121,313 | 116,468 | 123,491 | 1,433 | 123,317 | 1,851 | | モック — 新鮮なレジストリ：シードされた三つのプールを価格付け | 235,574 | 227,205 | 237,843 | 1,815 | 239,647 | 1,937 | | ライブ Base — コールド：レジストリは空、承認済みファクトリーを走査 | 1,524,221 | | | | 1,525,341 | | | ライブ Base — ウォーム：一回の実行直後で新鮮、二つのプールが登録済み | 1,414,633 | | | | 1,416,037 | | | ライブ Base — 探索 TTL 経過後に再びコールド | 1,359,925 | | | | 1,361,582 | | モック上での十エントリの `batchQuote`：2,055,390 ガス、エントリあたり 205,539。新鮮なレジストリのモックが探索よりも高くつくのは、探索が一つのプールを見つけたのに対し三つのプールを価格付けするからである。公正な比較はライブのものであり、そこでは探索の走査は見積もりの約 7 % にあたる。そして見積もりとは、インテグレーターがオンチェーンで決して支払うことのない view 呼び出しである。 ## §13 手数料方針：二つのレジームと余剰ルール *平易に：* プロトコルは 0.28 % を一度だけ、計測された一つの金額から、トレジャリーが保有したいコインで受け取り、そうしたことを数える。*厳密に：* `PROTOCOL_FEE_BPS = 28` は Core 内のコンパイル時定数であり、デプロイされたバイトコードのどこにもセッターは存在しない。手数料は `mulDivUp(base, 28, 10,000)` であり、切り上げであるため、ゼロでない基数に対してゼロの手数料には到達しえない。これは `TREASURY1_SHARE = 3,000` bps が第一トレジャリーへ、残りが第二トレジャリーへと分割される（`fee − t1` として計算されるため、二つの和は常に端数なしで手数料に等しい）。トレジャリーは構築時に固定され、一方通行の扉によって永久に凍結できる。いかなる鍵もトレーダーに不利になるよう料率を引き上げることはできず、いかなる鍵も優遇されたインテグレーターのために料率を引き下げることはできない。手数料の問題はコンパイル時に解決され、鍵にできることの一覧から取り除かれたのである。 ### §13.1 手数料が課される場所：二つのレジーム、いずれも名前付き 2026-08-22 以降の規則は一文である：**Router が保有する最初のブリッジコインに対して、一度だけ課す。** Router は経路を走査し、入力トークンが登録済みブリッジ（`hub.isBridgeToken`、ホップ順）である最初のホップを探す。そのホップが `feeHop` であり、そのホップの *計測された* 入力の 28 bps を課す。hop 0 では経路がコミットした量で上限を設けた計測済みの引き出し額、それ以降のホップでは外部由来のベースラインを超える Router のブリッジコイン残高であり、これは送金時手数料型トークンや紛れ込んだ残高に対してすでに耐性を持つ量である。その後 Router はその経路で他に何も課さない。宛先自体がブリッジコインである直接経路（TOKEN → WETH）は、代わりにフロア検査の後に出力に対して課す。フロアはスワップの質を検証し、プロトコルの取り分はすでに検証された金額から差し引かれ、ユーザーの最小値は実際に受け取る額と比較される。これが **アンカー型レジーム** である。なぜ宛先ではなくブリッジに課すのか：ブリッジは WETH と USDC であり、トレジャリーは宛先となる任意のテールトークンの端数ではなく、保有したい流動的なコインを受け取る。なぜ hop 0 の出力ではなく hop 1 の入力に課すのか：両者は同じトークン・同じ金額であるが、hop 1 の入力は実際の残高によって計測され、それは Router がすでに行っている計測だからである。 この規則には、2026-09-05 まで上記の一文が名指ししていなかった第二のレジームがある。レジストリが保持しないであろうプールを通る手作りの経路で、どのホップの入力にもブリッジコインがないものは、決して `feeHop` を見つけない。このとき課金の述語は *すべての* ホップについて真となり、各ホップはそれ自身の計測済み入力の 28 bps を支払う。これが **網羅型レジーム** であり、見落としではなく意図的な規則である。そのような経路に hop 0 で一度だけ課すことが同日スイート内で試みられたが、それは網羅方針が塞ぐために存在する抜け道を再び開いてしまった。価値のない最初のホップが手数料の課金位置を端数の上に運び、実際のホップは何も支払わないのである（`test/FeeEscapeViaJunkPrefix.t.sol`）。固定された五つのテストがその実行中にこの変更を拒否した。すべてのホップから逃れるように端数を挿入できる位置は存在しない。これが「網羅による免疫」の意味である。Solver はすべての複数ホップ経路を登録済みブリッジを通じて構築するため、Solver が構築した経路は常にちょうど一度だけ支払う。網羅型レジームは呼び出し元がレジストリを迂回してルーティングしたときに遭遇するものであり、Quoter はこれをモデル化している（`_pack` は、どのホップ入力もブリッジでない場合は `hops.length` 回、それ以外では一度課す）。したがってプレビューと受け渡しは両方のレジームで一致する（`test/ExhaustionRegimePreviewParity.t.sol`）。  ### §13.2 コミットメントの生成元は一つであり、コントラクトは数を数える 二つのシールがこれらのレジームに伴う。ホップの申告レッグ入力の合計（hop 0 における手数料基数であり、スケールの分母でもある）は一つの関数 `_legSum` によって計算される。2026-09-05 以前は、それぞれが独自のループでレッグを合計しており、一つの数値に二つの生成元があった。そして手数料台帳である：手数料を送金する唯一の関数 `_payFee` は、トランジェントスロット（`TSLOT_FEE`）に回数を数える。すべての決済はこのスロットを一度読み、何も支払わなかった受け渡し（`RouterE(15)`）を拒否し、アンカー型経路では二回目の支払い（`RouterE(16)`）を拒否し、その後スロットをクリアする。台帳の二つの検査は *ベルト* である。単独ではどのテストもこれらを発火させることはできない。その前段にある述語が、支払わずに決済する経路も、アンカー型経路で二度支払う経路も残さないからである。これらは、テストがレビュー時に拒否するものを、まだ存在しない経路についてコントラクトが実行時に拒否するものである。ベルトとして列挙され、どこでもカバー済みとは数えられず、名前付きテストが殺すミュータントのみを認めるミューテーション・ガードからも除外されている。 ### §13.3 余剰ルール **余剰ルール** は手数料設計の整合性に関する論証であり、コードが実装するとおりに述べれば次のとおりである：プロトコルの取り分は計測された一つの基数の 28 bps であり、アンカー型経路では一度、網羅型経路ではホップごとに一度であって、決済のどこにも、見積もられた額と受け渡された額の差に比例する項は存在しない。基数が入力である場合（すべての複数ホップ経路、および宛先がブリッジコインでないすべての直接経路）、出力には手を付けない。プールが見積もりを上回って受け渡したものはすべて受取人に満額届き、約定が有利になったからといって手数料が上がることはない。基数が出力である場合（ブリッジコインへの直接経路）、手数料は余剰を含む総受け渡し額の 28 bps であり、それ以上ではない。アグリゲーターが最も掠め取りたくなる軸は見積もりと約定の差である。この設計はその差に一切の手数料項を与えないため、表示料率が真の、そして唯一の料率である。基数が calldata から読まれることは決してない：`route.totalOut` は見知らぬ者の主張として Router に届き、何者にも読まれない（`test_FeeBase_IgnoresLiedAboutTotalOut`）。 **計算例 5 — 一つの経路における二つのレジーム。** ブリッジは {WETH, USDC} であり、トレーダーは 10,000 A を売却する。 *アンカー型、二ホップ。* A → WETH → B。Hop 0 には課されない（その入力 A はブリッジではない）。Hop 0 のプールは 5.000 WETH を支払い、これは外部由来のベースラインを超える Router の WETH 残高として計測される。`feeHop` = 1：手数料は $\lceil 5.000 \times 28 / 10{,}000 \rceil = 0.014$ WETH であり、第一トレジャリーへ 0.0042、第二トレジャリーへ 0.0098 に分割され、hop 1 は 4.986 WETH を B へと支出する。`Fee` イベントは一つ。台帳は 1 を示して満たされ、プレビューは 28 bps を一度控除した。 *アンカー型、ブリッジへの直接経路。* A → WETH を一ホップで。入力には何も課されない。プールは総額 5.000 WETH を受け渡し、フロアは 5.000 に対して検査される。その後、出力側の手数料 $\lceil 5.000 \times 0.0028 \rceil = 0.014$ WETH が支払われ、4.986 WETH が受け渡される。`userMinOut` は 4.986 と比較される。`Fee` イベントは一つで、出力トークン建てである。 *網羅型、二ホップ。* A → C → B で、A、C、B のいずれもブリッジではない。これはどの Solver も構築しない経路である。Hop 0 は $\lceil 10{,}000 \times 0.0028 \rceil = 28$ A を支払い、9,972 A をそのプールへ送り、プールは 2,000 C を支払う。hop 1 は $\lceil 2{,}000 \times 0.0028 \rceil = 5.6$ C を支払い、1,994.4 C を B へと送る。`Fee` イベントは二つ。台帳は `feeHop` なしで 2 を示すため、`RouterE(16)` は適用されない。実効料率は $1 - 0.9972^{2} = 55.9$ bps であり、プレビューもそう示していた。 ### §13.4 Router の外側から計測した手数料 `test/FeeSeals.t.sol` は Router の数値を一切読まない。手数料トークンは規則とブリッジ一覧から、基数はプールの残高差分（Router から手数料ホップへ出ていったもの、または前のホップのプールが支払ったもの）または受取人の残高差分から、手数料はトレジャリーの差分から、回数は `Fee` イベントから得る。これを Router が受け入れるあらゆる形状（一から三ホップ、ブリッジの位置はなし・最初・中間・最後、ホップあたり一または二レッグ）にわたり、$10^{12}$ から $10^{21}$ wei までのファズ金額で 2,000 回実行し、失敗はなく、すべての決済後に Router は何も保有していなかった。 | 経路の形状 | レジーム | 手数料が課される場所 | 計測結果 | |---|---|---|---| | A → B（どちらもブリッジでない） | 網羅型、一ホップ | hop 0 の入力、一度 | 手数料 = ⌈28 bps × 入力⌉、イベント一つ | | W → A（ブリッジが入力） | アンカー型 | hop 0 の入力 | 同上 | | A → W（ブリッジが出力、直接） | アンカー型、出力側 | 出力 | 手数料 = ⌈28 bps × 総出力⌉、受け渡し額 = 総額 − 手数料 | | A → C → B（ブリッジなし） | 網羅型、二ホップ | 各ホップの計測済み入力 | イベント二つ | | W → A → B | hop 0 でアンカー | hop 0 の入力 | イベント一つ | | A → W → B | hop 1 でアンカー | hop 0 が生成したブリッジコイン | イベント一つ、⌈28 bps × hop 0 のプールが支払った額⌉ | | A → C → W（ブリッジは二ホップの出力としてのみ） | 網羅型 | 各ホップの入力 | イベント二つ | | A → C → D → B · A → W → C → B · A → C → W → B | 上記のとおり | 上記のとおり | 3 · 1 · 1 イベント | **手数料テストが欠陥にどれほどの頻度で気づくか** は、仮定せずに計測した（`docs/assurance/fee-seal-detection.json`）。すべての手数料ミュータント（レジーム述語をどちらかの方向に動かしたもの、コミットメント生成元、台帳の二つの検査、および不変条件研究の三つの手数料ミュータント）を、ファズテストごとに二十のファズシードで、決定論的テストごとに一度実行した。検出率は Wilson 95 % 区間とともに報告し、見逃しがなかった場合には見逃し確率に対する三の法則による上界を示す。 | ミュータント | FeeSeals ファズ | Router キャンペーン（2 ホップ、2 レッグ） | カバリング配列 t = 2 | ジャンク接頭辞による抜け道 | 網羅型プレビュー整合性 | |---|---|---|---|---|---| | 網羅型が hop 0 にのみ課す | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | いいえ | はい | はい | | 網羅型が hop 0 を飛ばす | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | いいえ | はい | はい | | コミットメントが最初のレッグのみを数える | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | いいえ | いいえ | いいえ | | 手数料が二倍 | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | はい | はい | はい | | 入力側手数料が一度も課されない | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | いいえ | はい | はい | | 手数料が両側で課される | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | いいえ | はい | はい | | ベルト：手数料なしの決済がもはや拒否されない | 0/20 [0.00, 0.16] | 0/20 [0.00, 0.16] | いいえ | いいえ | いいえ | | ベルト：アンカー型の二重支払いがもはや拒否されない | 0/20 [0.00, 0.16] | 0/20 [0.00, 0.16] | いいえ | いいえ | いいえ |  行に沿って読めば、どのテストがその欠陥を検出するかがわかる。列に沿って読めば、そのテストが何を検出でき何を検出できないかがわかる。最初の計測では、Router キャンペーンは hop 0 を免除する網羅型ミュータントとコミットメント生成元を検出できなかった。直接の一レッグ経路しか構築していなかったからである。キャンペーンは同日に拡張され、二ホップを辿り hop 0 を二つのプールに分割するようになり、世界にブリッジコインを含めて一つのキャンペーンがすべてのレジームを扱うようにした。その結果、両者はいまや 20 中 20 で検出される。カバリング配列が検出するのは二倍の手数料のみである。その行は常にブリッジを横切るからである。二十のシードで 20 中 20 であれば、単一キャンペーンの見逃し確率は 15 % を上界とする。これが、ミューテーション・ガードが名前付きテストとキャンペーンの両方を実行する理由である。 本節を本論文の形式（主張、強制箇所、限界）でまとめる。料率も分割も誰にも動かせない。いずれもデプロイされたバイトコードにセッターを持たないからである。呼び出し元は見積もりを過少申告して手数料を縮めることはできない。基数は計測された残高であり、`route.totalOut` は何者にも読まれないからである。呼び出し元は価値のない接頭辞で手数料を回避することはできない。ブリッジ入力のない経路はすべてのホップで支払うからである。そして決済が何も支払わないこと、あるいはアンカー型経路で二度支払うことはありえない。Router が数を数えるからである。ただし、そのカウンター自身の二つの検査はどのテストも発火させられないベルトである、という限界を伴う。 ## §14 セキュリティモデル *平易に：* Router はトランザクション間で何も保有せず、すべてのスワップは全か無かであり、本リポジトリが検討した各攻撃クラスには名前付きの検査で答えるか、範囲外として名指しされている。*厳密に：* 脅威カタログは `docs/assurance/threats.json` であり、公開されたエクスプロイト記録から抽出した 23 のクラスからなる。各クラスはそれを拒否するガードのシンボルを名指しし、CI スクリプトはそのシンボルが `src/` から消えるか、名指しされたテストが `test/` から消えた場合にビルドを失敗させる。カタログの網羅度は、検討されたものの下限であって、存在するものの上限では決してない。 ### §14.1 攻撃と、それを拒否する検査 | クラス（id） | それを拒否する検査 | 強制される場所 | 状態 | その検査が失敗しうることを示すテスト | |---|---|---|---|---| | リエントランシー（DASP-1） | 価値を動かすすべての扉にトランジェントロック `nrEntrant`。コールバック面は呼び出し元を認証する | Router `nrEntrant` → `RouterE(7)`；`fallback` → `RouterE(6)` | 阻止 | `invariant_reentrancyBlocked`（`test/RouterAdversarialV4FromV1.t.sol`） | | アクセス制御（DASP-2） | 四つのロール。すべての特権的な扉はゲートされ、制御層は永久に放棄可能 | Hub `onlyAdmin` / `onlyControl` → `HubE(1)`；Router `onlyControl` → `RouterE(1)` | 阻止 | `test/HubAllowHookAfterRenounce.t.sol`、`test/ControlEvents.t.sol` | | 算術オーバーフロー/アンダーフロー（DASP-3） | 全体で検査付き算術。すべての `unchecked` ブロックには書面化された上界がある。ハードカーブの表現可能性は境界（`MAX_SQRT_PRICE_MINUS_ONE`）でテスト済み | Core | 阻止 | `test/BoundaryEquality.t.sol`、`test/CompilerPanicSurface.t.sol` | | 無制限の反復によるサービス拒否（DASP-5） | 経路のあらゆる次元に上限：`MAX_HOPS = 3`、`MAX_LEGS_PER_HOP = 5`、`MAX_LEGS = 11`、`MAX_CANDIDATES = 8`、`MAX_SLOTS = 16`、`MAX_FACTORIES = 16` | Router `_execute` → `RouterE(3)`；Solver；Hub → `HubE(4)`（ファクトリー）、`_canInsert`（スロット） | 阻止 | `test/RouteHopCeiling.t.sol` | | トランザクション順序依存 / サンドイッチ（DASP-7） | Iron-Law フロア。`FLOOR_HARD_MAX_LOSS_BPS = 2,000` でハードにクランプされ、呼び出し元の最小値（これを厳しくすることしかできない）とは独立に強制される | Core `ironFloorBpsShv`；Router `_execute` → `RouterE(5)` | 阻止（有界、§14.3） | `test/regime/SandwichCurve.t.sol`；`invariant_DeliveredNeverBelowTheProtocolFloor` | | ベニューを経由する関数横断リエントランシー（SWC-107） | 同じトランジェントロックが、プールのコールバックを含むスワップ全体に及ぶ | Router `nrEntrant` | 阻止 | `test/V4LockedRegionReentrancy.t.sol` | | 価格オラクル操作（SOK-ORACLE） | フィードは存在しない。参照見積もりは取引されるベニューから実行フレーム内で生成され、フロアはそこから導出される（`ironFloorBps`） | Core；Router `_execute` | 阻止 | `test_Parity_SplitRoute_AttestedFloorEqualsEnforcedFloor`（`test/FloorParitySolverRouter.t.sol`） | | 計測値の代わりに呼び出し元提供の量を用いる（SOK-FEE-BASE） | 手数料基数は計測された残高である（`_chargeHopFee`）。`route.totalOut` は何者にも読まれない | Router `_chargeHopFee` | 阻止 | `test_FeeBase_IgnoresLiedAboutTotalOut`（`test/BlazePhoenixRouter.t.sol`） | | 送金時手数料型トークンとリベーストークン（SOK-FOT） | 重要なすべての金額は計測された残高差分（`balanceOf`）であり、仮定された送金額では決してない | Router、すべての継ぎ目 | 阻止 | `test/FotFloorReprice.t.sol`、`test/PartialFotAtPrePulledDoors.t.sol` | | 敵対的なベニューのレジストリへの承認（SOK-VENUE-ADMISSION） | 承認はキュレーターのみが行い、アドレスごとに一行。導出元は承認時に証明され（`factoryDeployer`）、放棄後は凍結される | Hub `addFactory`、`_probe` | 阻止 | `test_C4_FirstPin_AfterRenounce_MustNotAttestTheLiveAnswer`（`test/T19ReadmissionEdge.t.sol`） | | 承認済みベニューのロジックがプロキシの背後で変わる（SOK-PROXY-VENUE） | 放棄後、ランタイムが変化していれば再承認は拒否される（`factoryCodehash`）。プロキシがコードを変えずに応答を変えうる場合は、代わりに応答が固定される | Hub `addFactory` → `HubE(1)` | 阻止 | `test/FactoryCodehashPin.t.sol`、`test/RenouncedFactoryRearm.t.sol` | | 硬直化後にベニュー行が導出型から問い合わせ型へ変換される（SOK-MODE-FLIP） | `controlRenounced` 後は derive 行が ask 行になることはできない。逆方向への厳格化は引き続き許される | Hub `addFactory` | 阻止 | `test_C4_S3_DeriveRowMustNotBecomeAnAskRowAfterRenounce`（`test/T19ReadmissionEdge.t.sol`） | | 呼び出し元の申告をそのまま報告する公表指標（SOK-VOLUME） | レジストリには、計測値対申告値の比（`hopScale`）から、ホップが実際に支出できた量が渡される | Router `_recordHits` | 阻止 | `test_INV_F4_VolumeInEqualsTheMeasuredPoolDelta`（`test/VolumeEventFidelity.t.sol`） | | 実行を予測しないプレビュー（SOK-QUOTE-EXEC） | プレビューと受け渡しは両方の手数料レジームで等しいことが検証される（`previewRoute`、`_pack`） | Quoter；Router | 阻止 | `test_INV_F2_PreviewPredictsDeliveryWithNoBridge`（`test/ExhaustionRegimePreviewParity.t.sol`） | | 決定論的導出が攻撃者のアドレスへ誘導される（SOK-V4-DERIVE） | CREATE2 のプリイメージの生成元は一つ（`create2Address`）。プール id はそれ自身のキーから導出される。`hasCode` と生存性証明は解決しないものを破棄する | Core；Hub `_probe`、`_scanV4` | 阻止 | `test/ConditionAdequacyCore.t.sol`、`test/KindIsDerivedNotDeclared.t.sol` | | フック付きベニュー上の悪意あるフック（SOK-HOOK） | 三つの層（§14.2）：不変のアドレスビット、コードハッシュ固定付き許可リスト（`hookAllowed`、`isHookLive`）、射影子 Ξ | Router → `RouterE(9)`；Hub `allowHook` → `HubE(8)`；Solver `_topKPools` | 阻止 | `test/V4SievedHookIsTheExecutedHook.t.sol`、`test/SeedPoolHookMustBeAllowed.t.sol`、`test/RenouncedHookRearm.t.sol` | | 繰り返しの承認によるレジストリ枯渇（SOK-GRIEF-SEATS） | アドレスごとに一行。繰り返しの追加は席（`MAX_FACTORIES`）を消費せず、その場で更新する | Hub `addFactory` → `HubE(4)` | 阻止 | `test/RenouncedFactoryRearm.t.sol` | | 任意の外部呼び出しまたは transfer-from の受け皿（SOK-ARBITRARY-CALL） | 実行者は呼び出し元が提供する呼び出し先を決して受け取らない。ベニューとのやり取りは種類によって選ばれる閉じた形状集合からディスパッチされ（`_execScaled`）、未知の種類はリバートする | Router `_execScaled` → `RouterE(8)` | 阻止 | `test/regime/HostileVenueMatrix.t.sol` | | 委任承認における署名リプレイ（SOK-SIG-REPLAY） | 委任承認は正規の Permit2（`permitTransferFrom`）が扱う。システムは独自の署名方式を持たない | Router `swapExactInWithPermit2` | 阻止 | `test/RouterPermit2OneStep.t.sol` | | ガバナンスの乗っ取り（SOK-GOV） | ガバナンスは存在しない：トークン投票も、タイムロックも、プロキシもない。唯一の特権はベニューの承認と一時停止であり、いずれも放棄可能 | — | 範囲外 | — | | 悪意あるアップグレード（SOK-UPGRADE） | コントラクトは不変であり、プロキシも実装スロットも存在しない | — | 範囲外 | — | | 外部ブリッジまたはベニューの侵害（SOK-BRIDGE-EXT） | 第三者のベニューは組み合わされるのであって、制御されるのではない。その失敗はここではフロアと呼び出し元の最小値によって有界とされ、その内部のセキュリティについては主張しない | — | 範囲外 | — | | ユーザーの秘密鍵の侵害（SOK-KEY） | 信頼境界の外側。公表されたインシデントデータが損失の大きな割合をこれに帰しているため記録している | — | 範囲外 | — | 二十三クラスのうち十九は名前付きのガードで答えられ、四つは理由を記録したうえで範囲外とされている。カタログは資産閉包（`assets.json`）によって逆方向からも照合される。システムが保有または決定する六つのもの（移動中の資金、委任された許可額、プロトコル手数料、レジストリの完全性、取り残された残高、呼び出し元のガス）を、ものが失われうる五つの方法と掛け合わせた三十のセルであり、各セルは脅威クラス、範囲外の根拠、または明示的な *未解決* のいずれかに帰着する。十九セルがカバーされ、三セルが範囲外、五セルが該当なし、三セルが未解決であり、そのように公表されている：手数料の建て通貨に対する嫌がらせ、回収を不経済にするための端数の置き去り、そして呼び出し元が名前付きの拒否ではなく到達可能な三つのコンパイラパニックのいずれかに遭遇することである。未解決のセルのいずれも、他者の資金への経路ではない。 ### §14.2 敵対的なフック：三つの層、最も安価なものから フックとは Router が実行中の決済の内部で動く任意のコードであり、素朴な防御、すなわち何をするつもりかをフックに尋ねることは防御にならない。敵対的なフックは嘘をつくか再入するからである。代わりに三つの独立した層が立ち、最も安価で最も確実なものが最初に実行されるよう配置されている。これらはデルタの改変を有界とする。これらが届かない唯一の残余、すなわちデルタを持たないフックが動的手数料を上書きすること（§5.4）は、代わりに Φ と呼び出し元の最小値によって有界とされる。 **第 1 層 — 権限ビットはアドレスに宿り、アドレスは嘘をつけない。** V4 はフックの権限をそのコントラクトアドレス自身の下位 14 ビットに符号化する。これらのビットはデプロイ時に CREATE2 ソルトによって固定され、PoolManager 自身がフックを呼び出す前に同じビットを検査するため、フックはそのアドレスが宣言していない権限を持つことはできない。フックにスワップ会計の変更を許すビットはちょうど二つであり、Router はいかなるトークンも動く前に、単一の AND でそれらをマスクする（`hookAltersDeltas`）： $$ \left(\mathrm{uint160}(\mathrm{hook})\ \&\ \mathtt{0x3FFF}\right)\ \&\ \left((1 \ll 3) \mid (1 \ll 2)\right) \ne 0 \;\;\Longrightarrow\;\; \text{leg refused, } \mathtt{RouterE(9)} $$ ^e18 信頼できないコードへの呼び出しはなく、欺くべきものもなく、回避するにはビットがマネージャー自身の強制と矛盾するアドレスが必要となる。プロキシはそのロジックのすべての行を置き換えても、アドレスがもともと持っていなかったビットを一つも得られない。この拒否が射影距離ゼロ（§15.9）に位置し、その下のコードハッシュ固定がそうでないのはこのためである。 **第 2 層 — 既定で閉じた許可リストと、コードの固定。** ビットがクリーンなフックでも、嫌がらせやガスの浪費のために悪意をもってリバートしうる。そのため V4 プールは、そのフックがキュレーターによって許可リストに載せられている場合にのみルーティング可能であり、Hub は承認時にフックのコードハッシュを固定する。ランタイムが後に変化したフックは追放されずに自動的に一時停止され（`isHookLive` が false）、再承認された場合にのみ再開する。この権限は、放棄後はコードが変化したあらゆるフックについて拒否される。固定の限界はその箇所に明記されている：固定はランタイムコードを拘束するため、再デプロイや直接の改変は捕捉するが、自身のランタイムがバイト単位で同一のまま実装が差し替えられるデリゲートプロキシは捕捉しない。EVM はコントラクトに他のコントラクトのストレージを読む手段を与えないからである。アップグレード可能なフックを承認することは、この固定では代替できない人間の判断である。これに依存しない層は、それとは無関係に立ち続ける。 **第 3 層 — 経路がそもそも提示されない。** 射影子 Ξ は、ランキングの前に、フックがデルタを改変するプールを Solver の候補集合から取り除き（`_topKPools`）、Hub の読み取りチャネルは生存しているフックのみを提供する。承認不可能なフックに触れる経路は最大化に参加しない。経路形状の規則がこれを完成させる：経路全体にわたる正準順序により、フックが実行された後にフックなしのレッグが実行されることは決してない（§11.4）。  このスタックを破るには、デルタビットを持たず、変化しないまま許可リストに載り、それでも決済を覆すフックが必要である。この組み合わせは、第 1 層 が V4 自身の不変の強制に依拠することにより、デルタ改変については排除される。§5.4 の手数料上書きという残余は残り、フロアがそれを有界とする。残余は表に明記されている：許可リストに載った、デルタを持たないフックは依然としてスワップの途中でリバートし、試行のガスを浪費させうる。そして篩の唯一のレバーも名指しされている：篩にかけられたフックが実行されるスワップを拘束するのは、正準の PoolManager がアンロックデータをそのまま返し、自身のアンロック呼び出し元にのみコールバックするからである。制御権限である Hub の `setV4Manager` は、その前提が依拠する唯一のアドレスであり、不正直なマネージャーは計測された出力を崩壊させるため、呼び出し元自身の上界がスワップを拒否する（`HostileV4Manager` キャンペーン）。これは有界であって、存在しないわけではない。 ### §14.3 排除ではなく有界化：陳腐化、順序付け、そしてサンドイッチ曲線 見積もりは過去についての言明であり、取引は未来に起こる。フレーム内ソルビングの扉は、その隔たりのうちオペレーター側の半分を完全に閉じる。経路はそれを実行するトランザクションの内部で、そのブロックにおける現状の準備金から導出される。残るのはチェーン自身の半分である：署名した瞬間からトランザクションが取り込まれる瞬間までの間に、プールは動きうる。コードが実行される前に順序が決まるため、これをコントラクトの内部から防ぐことは誰にもできない。フロントランニングを排除したと主張するプロトコルは、あなたの取引を公開キューから外して、それを今保持している誰かを信頼しているか、聞こえるよりも狭い何かを説明しているかのいずれかである。本プロトコルが行うのは、これを二重に、かつ独立に有界とすることである：あなたの最小値は損害をあなたが選んだ数値で頭打ちにし、Iron-Law フロアは（攻撃者や経路が提供したものからではなく、計測された影響と最終ホップのフレーム内見積もりから Router が再導出するものであり）プロトコル自身の責任において再びそれを頭打ちにする。 この上界は攻撃者の側から計測される（`test/regime/SandwichCurve.t.sol`）：被害者の経路とフロアは、保留中のトランザクションと同様に、見積もり時点で固定される。攻撃者は被害者より先にプールの深さの一定割合を取引し、被害者が実行し、攻撃者が逆方向に取引する。ベニューは定積ペア（あらゆるサンドイッチモデルが用いる形状）であるため、この曲線はフロアの性質である。深さの 1 % の取引（片側 1,000,000 に対して 10,000）について： | 攻撃者が動かす量 | 被害者 | 見積もりに対する被害者の損失 | 攻撃者の往復損益 | |---|---|---|---| | 深さの 0.1 % | 決済 | 0.47 % | +13.9 | | 0.5 % | 決済 | 1.26 % | +68.9 | | 1 % | 決済 | 2.22 % | +136.7 | | 2 % | 決済 | 4.12 % | +268.7 | | 3 % 以上 | **拒否** | 0 | −174.5 … −544.9 |  すべての点で検証された保証：決済された被害者は、見積もり時点で証明されたフロアを下回る額を受け取ることは決してない。したがって損失は、証明された見積もりと証明されたフロアの間の距離によって有界となる。そして拒否領域は上方に閉じている：境界を越えると、より大きな操作はすべて拒否され、攻撃者は自らが動かした価格を抱えたまま取り残される。引用に値する数値は最後の決済行である：フロアは、1 % の取引からサンドイッチが奪えるものをその約 2.7 % で頭打ちにし、それ以上を奪おうとした瞬間に攻撃者の取引を損失に変える。フレーム内経路はより静かな抑止力を加える：経路を実行するブロックまで経路は存在しないため、サーチャーが研究できる事前公開された経路は存在しない。広い最小値は招待状である。狭い最小値は、本節においてあなたに属する唯一にして最も効果的な制御である。 ### §14.4 敵対的なベニュー ベニューの病理には独自のマトリクスがある（§15.5）：十の不正挙動（何も支払わないプール、半分だけ支払うプール、64 KiB の returndata 爆弾を返すプール、読み取り時またはスワップ時にすべてのガスを燃やすプール、`decimals()` が決して返らないトークン、二回発火する支払いコールバック、支払う前に Router に再入するプール、リバートする `slot0()`、別のトークンのプールで応答するファクトリー）を calldata の扉とソルビングの扉と掛け合わせたもので、20 中 20 のセルが、受け渡し額が残高差分に等しく Router に何も残らない形で決済されるか、こちらのセレクタで拒否される。転送されたすべてのガスを燃やすスワップは、呼び出し元が呼び出し先のために決定できない唯一のセルである。トランザクションは丸ごとリバートし、ユーザーの残高には手が付けられない。Core がベニューに対して行うすべてのガード付き読み取りは `GAS_CAP = 100,000` ガスで上限が設けられているため、*読み取り* でガスを燃やすベニューのコストは有界であり、致命的ではなく除外される。 ### §14.5 敵対的なフロントエンド これまでに構築されたあらゆるアグリゲーターにおいて、最小値を提案するのはインターフェースであり、不注意なインターフェースはそれを不適切に提案する。あなたが何を選んだはずかを知りうるコントラクトは存在しない。コントラクトにできるのは、その提案を証明可能にすることである：すべてのスワップは `ExecutionProof`（使用された見積もり、受け渡された金額、適用されたフロア）を永続的にオンチェーンで発行するため、あらゆるインターフェースの実行品質は、あなた自身を含む誰もが監査できる、トランザクションごとの公開記録となる。一貫して不適切な最小値を提案するインターフェースは、自らの告発状をイベントログに書き込むことになる。この仕組みを完成させる防御は習慣である：署名する前に最小値を確認せよ。それは完全にあなたのものである唯一のフィールドである。 ### §14.6 敵対的な鍵にできること、できないこと 放棄の前には管理鍵が存在する。それらを正直に記述する方法は、保有者が敵対的であると仮定したうえで能力によって記述することである。権限の完全な列挙は §16.4 にある。 **敵対的な Router 鍵にできること：** 手数料の送り先を変更する（`setTreasuries`）。スワップを一時停止する（`setPaused`）。ネイティブの扉と Permit2 の扉が呼び出す WETH コントラクトと Permit2 コントラクトを付け替える（`setWeth`、`setPermit2`）。これにより、その二つの扉の信頼性は設定されたアドレスと同程度にしかならない。Router に取り残されたトークンの救出をキューに入れ、48 時間後に実行する（`queueRescue`、`executeRescue`、`RESCUE_DELAY = 48 hours`、`RescueQueued` によってオンチェーンで告知される）。**できないこと：** 手数料率、分割、フロアを動かすこと。これらはセッターを持たないコンパイル時定数だからである。元本を奪うこと。プロキシもアップグレード経路も `selfdestruct` もなく、ユーザー資金の Router への常設承認もなく、Router は平常時に何も保有しないからである。それを行うはずの関数は無効化されているのではなく、存在しないのである。 **敵対的な Hub 鍵にできること：** ベニューまたはフックを掲載する（`addFactory`、`allowHook`）。プールをシードする（`seedPool`、オペレーター席を通じて）。レジストリの学習を一時停止する（`setPaused`）。Hub から見た Router、Solver、Quoter を付け替える（`setRoles`）。そして V4 マネージャーを付け替える（`setV4Manager`、篩の唯一のレバー）。**できないこと：** 約定の価格を誤らせること。レジストリが決めるのは何が見えるかだけだからである（§9.6）。敵対的な掲載が到達しうる最も鋭いものは、見積もりと *あなたの最小値* の間の差である。元本には手が届かないが、あなたのスリッページ許容度には届く。これもまた、最小値をあなた自身が厳しく設定すべき理由の一つである。 ### §14.7 一方通行の扉 管理権限は、約束によってではなくバイトコードにおいて、不可逆に終わる。Hub と Router はいずれも `renounceControl` を公開し、それぞれ一時停止中の呼び出しを拒否する（`RouterE(2)`、`HubE(2)`）。一時停止したうえで放棄されたプロトコルは、誰も望まず誰も抜け出せない終端状態となるだろう。そして一時停止に意味があるのは、まさに行動するために制御が保持されているからである。放棄フラグは各コントラクトのちょうど一か所で `true` に書き込まれ、`false` に書き込まれる箇所は一つもない。したがって、デプロイされたバイトコードのいかなる関数も扉を再び開くことはできない。これが「しない」と「できない」の違いである。 何が閉じ何が開いたままかは、要約ではなく列挙される。Router では、`onlyControl` 配下のすべてが消滅する：`setAdmin`、`setTreasuries`、`setPermit2`、`setWeth`、`setPaused`、救出経路である。トレジャリー、配線、一時停止フラグは現在の値で永久に凍結され、Router はその固定された構成のもとでスワップを実行し続ける。Hub では **制御層** が消滅する：`setRoles`、`setOperator`、`setPaused`、`setV4Manager`、`removeBridge`、そしてフックの *掲載解除* である。**キュレーター層** は存続し、レジストリを拡大することしかできない：`addFactory`（放棄後は、ランタイムが変化したファクトリーや、ask 行になろうとする derive 行を拒否する）、`addBridge`（追加のみ、最大三つ、冪等）、`allowHook(h, true)`（コードが変化した掲載済みフックを拒否する）。既存のオペレーター席は `seedPool` と `addV4` を保持し、新たな席を付与することはできない。放棄後の悪意ある掲載は資金を流出させられない：プールは見積もり時と実行時に検証され、フロアと呼び出し元の最小値によって有界とされる。レジストリは取引を通じて学習し続ける。本プロトコルについて「放棄済み」と繰り返す者は誰であれ、どの扉が開いたままか（承認、ブリッジ、フックの掲載、キュレーションされたシード）と、どの扉が閉じるか（送り先を変えたり凍結したりするあらゆる権限）を言えるべきである。 ### §14.8 このモデルがあなたに求めること 本プロトコルは、コントラクトが閉じうるものを閉じる：アドレスの偽造、コールバックのなりすまし、会計の偽造、敵対的なフック、算術である。いかなるコントラクトも排除できないもの、すなわち陳腐化と順序付けは、あなたの最小値とフロアによって有界とする。そして有界にすらできないもの、すなわちあなたに代わって不適切な最小値を提案するフロントエンドに対しては、証拠を公表する。すべての行は同じフィールドに収束する。最小値は毎回、意図的に、あなた自身で設定せよ。それは本節において、その質があなた以外の誰の能力にも依存しない唯一の防御である。 ## §15 検証装置、その計測 *平易に：* ここに示すすべての数値は、それが計測された分母と並べて印字され、クリーンなチェックアウトからスクリプトまたは名前付きの `forge` コマンド（付録 C）によって再計算され、その数値が確立しないものが後に続く。*厳密に：* 計測対象のツリーは `8949a9d` 時点の `main` と、それになったブランチであり、リリースプロファイル（`optimizer_runs = 300`、`via_ir`）上で 2026-09-05 に計測した。 ### §15.1 数字で見るスイート | 何を | 件数 | 数え方 | |---|---|---| | 宣言されたテスト | 236 個の `.t.sol` ファイルにわたる 1,609 個の `test*` / `invariant*` / `check*` 関数 | `test/` に対する `grep` | | リリースプロファイルでグリーン（フォークスイートを除く） | 1,320 件中 1,319 件合格 · 0 件失敗 · 1 件スキップ | `forge test --no-match-path 'test/fork/**'` | | ライブ流動性でグリーン | フォークレーンの 39 スイート、五つのチェーンで 119 件中 119 件；加えて §12 の三つのライブ Base テスト | アーカイブ RPC を用いた `forge test --match-path 'test/fork/**'` | | ステートフル不変条件 | 14 のキャンペーンにおける 43 個の `invariant_*` 関数 | `grep -rc 'function invariant_' test` | | キュレーションされたミュータント（すべて撃破） | 268 中 268 | `.github/scripts/mutants.py`、`check_targets.py` | | レジームのカバリング配列 | 強度 2：63 行、全 258 ペア · 強度 3：168 行、全 1,636 トリプル · 5,184 通りの組み合わせに対して | `covering_array.py --check` | | 出荷サイズ（ランタイムバイト；EIP-170 の上限 24,576；プロジェクトのゲート 24,000） | Hub 23,648 · Router 23,781 · Solver 19,686 · Quoter 11,429 · Core 6,442 | `FOUNDRY_PROFILE=release forge build --sizes` | ### §15.2 証拠の連鎖と、キュレーションされたミューテーションガード ある性質の価値は、脅威から、その性質が破れたときに失敗するはずの何かまでの最短経路で決まる：`threat → property → guard → test → mutant`。ガードはシンボルで、テストは名前で、ミュータントはそれが改変する正確な行で名指しされる。三つのうちいずれかがツリーから消えれば、ビルドは失敗する。スイート中のすべての回帰テストは、その名の由来となった理由で一度失敗するところを確認されている——修正は、修正なしのコードに対してレッドだったテストとともに届く。 ミューテーションガードは手書きの 268 個のミュータントを保持し、それぞれがソースの正確な一行と、その行が改変されたときに失敗しなければならない単一のテストとを対にする——削除されたガード、拒否を決める境界で反転された比較、拡大された認可、隣のエラーコードと入れ替えられたエラーコード。これをスコアではなくガードにしている性質は三つある。対になるテストはまず変異のないツリー上でグリーンであることを確認される。オプティマイザが除去する変異——ランタイムバイトコードが同一になるもの——は *不活性* として報告され、決して撃破とはされない。そして一秒で終わる静的チェックが、すべてのミュータントが依然としてちょうど一行を指していることを検証する。203 中 203 が撃破される。この数値は *この* 台帳に対する十分性である：飽和したスコアはフロアであって、天井ではない。 ### §15.3 不変条件に向けたミュータント 2026-09-05 まで、キュレーションされたミュータントのいずれも、それによって倒れなければならないテストとしてステートフル不変条件を名指ししていなかった。14 のキャンペーンにわたる 43 個の `invariant_*` 関数はグリーンであり、そのいずれかがレッドになり得るのかを問うたものは何もなかった。ある性質が保護する状態にハンドラが一度も到達しないキャンペーンは、その性質を空の宇宙の上で認証しているにすぎず、外から見ると、その状態に到達するキャンペーンと見分けがつかない。この計測はガードの計測をキャンペーンに向けたものである：ソース中のガードを一つ改変し、一つのシードですべての不変条件を実行し、どれが気付くかを記録する（`docs/assurance/invariant-mutants.json`）。 | ミュータント | 除去するもの | 気付いたもの | |---|---|---| | 最終送金が 一 wei 少なく支払う | 何も保持しないこと | `RouterHoldsNothing`、`routerHoldsNothing`、`HoldsNothingBeyondTheSeed` | | プロトコル手数料が二倍になる | 手数料の上限 | `FeeNeverExceedsProtocolMax` | | 入力側の手数料が一切課されない | 手数料のフロア | `FeeNeverEscapes`、`DeliveredNeverBelowUserMinOut` | | 手数料が両側で課される | 一つの手数料、一つの側 | `FeeIsChargedOnExactlyOneSide` | | すべての手数料の 30 % がデッドアドレスに送られる | 保存則 | `conservationA/B/C/H`、`TokenConservation`、`LedgerConservationA` | | レッグ・ペアのガードが誤ったペア上のレッグを通す | 同質なホップ | `DivergentLegNeverSettles`、`HoldsNothingBeyondTheSeed`、`StrandedMoneyIsNeverSwept` | | `whenLive` が `paused` を確認しなくなる | 一時停止 | `PausedRouterNeverSettles` | | リエントランシーロックが拒否しなくなる | ロック | `reentrancyBlocked` | | プロトコルフロアが半分になる | フロア | `DeliveredNeverBelowTheProtocolFloor` — 2026-09-05 に解消 | | `MAX_SLOTS` が 17 になる | レジストリの上限 | `neverExceedsMaxSlots` | | 登録時のペア証明が除去される | ペアの真正性 | `ActiveEntriesTradeThePair` — 2026-09-05 に解消 | | 入力残余のスイープがベースラインを無視する | 取り残された資金 | `StrandedMoneyIsNeverSwept`、`HoldsNothingBeyondTheSeed` | | ブリッジ残余のスイープがベースラインを無視する | 取り残された資金 | 同じ二つ — 2026-09-05 に解消 | | 出力の計測がベースラインを無視する | 取り残された資金 | 同じ二つ | | 手数料控除後の `userMinOut` チェックが半分になる | — | 設計上生き残る：手数料付き送金（fee-on-transfer）の出力トークンを持たないキャンペーン宇宙では到達不能な回帰の歩哨であり、二つのユニットミュータントがそれを見張る |  最初の計測では十五のうち十一が気付かれた。二十の異なる不変条件名が少なくとも一度レッドになった。四つの生存者のうち三つは、キャンペーンに欠けていたアクションを与えることで同日中に解消された——ペアの下に提示される外部のプール、事前にシードされた中間残高の上を通る二ホップの経路、古くなった経路が実行される前に見積もられた経路に逆らってプールを 0–8 % 動かすホエール——いずれもガードなしでレッドになることを確認済みである。いかなる種類の見張りも持たないガードが二つ、というのがこの計測が印字するために存在した数値であり、それは今やゼロである。十五のうち十四が気付かれる。その十四は、それによって倒れる不変条件と対にされたガードのエントリである。見張られていないガードを含んだグリーンなスイートは、このコードベースで記録された二つの回帰の双方の形であった。それを見つける計測は、今やキャンペーンが主張するすべてのガードに対して実行される。 ### §15.4 レジームのカバリング配列 カバレッジ基準はコードを索引し、ミューテーションは注入された欠陥を索引する。どちらも、呼び出しの前に *フィクスチャ* が固定する状態を索引しない。そのような因子が十個列挙される——ベニューのファミリー（V2、V3、Solidly）、ホップ数（1–3）、ホップあたりのレッグ数（1–2）、入力トークンが登録済みブリッジであるか、中間トークンがそうであるか、手数料付き送金の形（なし、pull のみ、すべての送金）、入力トークンの小数桁数（18、6）、ドア（calldata 経路、トランザクション内ソルブ、Permit2）、制御（稼働中、放棄済み）、そしてペアが満杯であるか——で 5,184 通りの組み合わせとなる。`covering_array.py` は、因子の値のすべてのペア（強度 2）またはすべてのトリプル（強度 3）が少なくとも一つの行に現れる配列を生成する。各行は一つのハーネス（`test/regime/RegimeHarness.sol`）を通る一つのフィクスチャであり、一つのアサーションを持つ：スワップが決済され、配送された量が受取人の残高差分に等しく、Router が発したフロア以上であり、Router に何も残らない——あるいは、我々のセレクタで拒否される。パニック、外部のセレクタ、配送不足、取り残された残高は第三の道であり、その行を失敗させる。 | 強度 | 行数 | 保持されたタプル | 決済 | 拒否（我々のもの） | 構築不能 | 第三の道 | |---|---|---|---|---|---|---| | 2 | 63 | 258 ペア | 53 | 4 | 6 | 0 | | 3 | 168 | 1,636 トリプル | 158 | 10 — `SolverE(5)` ×7、`RouterE(13)` ×3 | 0 | 0 |  拒否は、プランナーが構築すべきブリッジ経由の経路を持たない場合と、実行器が集中流動性のみの経路で課税トークンを拒む場合である。強度 2 で構築できない六つの行（pull のみ課税されるトークンには小数点以下六桁の形がない）は名前付きで印字され、分母に算入される。配列に含まれないファミリー——V4、ネイティブ V4、Algebra、ネイティブのドア、フック——は `regimes-covering.json` に記載されている。配列の最初の実行は、パリティテストが片側でしか固定していなかったフレームを明示化した：Router が強制するフロアは、手数料が出力から差し引かれるときは証明済みフロアに等しく、入力から差し引かれるときは $[\mathrm{attested} \times (1 - \mathrm{fee}), \mathrm{attested}]$ の内側に位置する——両方のフレームが今やすべての行でアサートされる。生成されたファイルは CI でその生成器と照合されるため、配列がカバーすると主張する因子から乖離することはない。 ### §15.5 敵対的ベニューのマトリクス トークンの病理にはテストがあったが、ベニューの病理はマトリクスの形では一つもなかった。`test/regime/HostileVenues.sol` はベニューごとに一つの不正動作を保持し、`HostileVenueMatrix.t.sol` はそれぞれを、カバリング配列の規則の下で calldata のドアおよびソルブのドアと交差させる： | ベニュー | calldata のドア | ソルブのドア | |---|---|---| | 何も支払わない / 半分だけ支払う | `RouterE(5)` で拒否 | `RouterE(5)` で拒否 | | 準備金読み取りでの returndata 爆弾 | 決済される | 決済される | | 準備金読み取りがすべてのガスを燃やす | `RouterE(8)` で拒否 | プランナーは決してそれを選択しない | | スワップがすべてのガスを燃やす | トランザクション全体がリバートし、残高は無傷 | トランザクション全体がリバートし、残高は無傷 | | `decimals()` がすべてのガスを燃やす | 決済される | 決済される | | 支払いコールバックが二度発火する | `RouterE(6)` で拒否 | `RouterE(6)` で拒否 | | 支払い前に Router に再入する | 決済される；ネストしたスワップは実行されなかった | 決済される；ネストしたスワップは実行されなかった | | `slot0()` がリバートする | 証明済み見積もりで決済される | プランナーは決してそれを選択しない | | ファクトリーが他のトークンのプールで応答する | 一切リストされない | 一切リストされない | 二十のセルのうち二十：我々のセレクタで決済または拒否され、第三の道は決してない。最後の行は、マトリクスの最初の実行が変えたものである——ディスカバリーは、キュレーターが承認したファクトリーが応答として返したプールをリストし、実行器はそれを支払いの継ぎ目で拒否していた。今では、問い合わせたプールは、ディスカバリーがそれをリストする前に自らのペアを証明する（ §7 ）。 ### §15.6 正準オラクル スイート中のすべてのモックは Core 自身の式で見積もるため、式の欠陥は、それを使うすべてのパリティテストからは見えない：オラクルこそが対象なのである。`test/regime/CanonicalOracles.t.sol` は、ベニューが公表している不変式から書かれた三つの実装を保持する——入力に手数料がかかる定積、プール自身のトレーダー不利の丸めを伴う V3 の単一ティック平方根価格ステップ、ニュートン法で解く Solidly の stable 曲線——そして Core をそれらに対してそれぞれ 5,000 回ファズし、まず方向（Core はベニューの数学が配送する以上を決して約束しない）を、次に厳密さをアサートする。 | ファミリー | 方向 | 計測された厳密さ | |---|---|---| | Uniswap V2 | Core は仕様を決して超えない | wei 単位で厳密 | | Solidly stable | Core はソルバー自身の最後のステップを超えて曲線を上回ることはない | 4 wei 以内 | | Uniswap V3 | Core は平方根価格の最終桁一単位（ulp）、すなわち $L / 2^{96}$ wei に相当する分を超えて仕様を上回ることはない | $L < 2^{96}$ であるすべてのプールで一 wei 未満 | V3 の上限は、それを生じさせる量で述べられている——プールは新しい価格をトレーダー不利に丸め、Core はそれを一度丸めるため、両者は $\sqrt{P}$ の一単位だけ異なり得る——そしてアサーションはサンプルではなく上限である（$L = 10^{30}$ での $6.5 \times 10^{34}$ の出力に対して 13 wei）。オラクルはベニューのバイトコードからではなく仕様から書かれている。それがオラクルの限界である。 ### §15.7 メタモルフィック関係 同じ式から書かれたオラクルは、その式を捕らえられない。メタモルフィック関係は代わりに、入力が動いたとき出力がどう *動か* なければならないかを問い、ベニュー自身の曲線が参照実装なしにそれに答える。`test/CoreMetamorphicRelations.t.sol` は Core の見積もり数学について十四の関係を、`test/RouteMetamorphicRelations.t.sol` は実際の Hub と実際の Solver を備えた二つのプールからなる宇宙での Solver の計画について五つの関係を保持する： | レベル | 関係 | 意味するところ | |---|---|---| | Core、V2 · V3 · stable | MR1 単調性 | より多く入れれば、出力が減ることはない | | Core、V2 · V3 · stable | MR2 劣加法性 | 同じプールに注文を分割しても決して得をしない | | Core、V2 · stable | MR3 往復なし | 入れて、更新された準備金で戻しても、入れた以上が返ることはない | | Core、V2 · V3 · stable | MR4 スケール同変性 | 注文とプールを同時にスケールすると、丸めの範囲で出力もスケールする | | Core、V2 · V3 | MR5 手数料単調性 | 手数料が高いほうが多く支払うことはない | | Core、V3 | MR6 方向対称性 | 価格 1.0 では `outV3` の二つのアームが二 ulp 以内で一致する | | Core、Solidly | MR7 同一性 | volatile アームは `outV2` *そのもの* であり、生成元は一つ | | 計画 | MR-R1 | 分割は最良の単一プールが支払う額を決して下回らない | | 計画 | MR-R2 | `amountIn` に対して単調 | | 計画 | MR-R3 | 価格帯の内側にプールを追加しても計画が下がることはない | | 計画 | MR-R4 | 登録順序は計画を分割の重み一単位までしか動かさない | | 計画 | MR-R5 | 証明済みフロアは期待出力を決して超えない | 上限のうち三つは書かれる前に計測されており、アサーション中の数値はサンプルではなくメカニズムである。MR6：$L = 8.5 \times 10^{37}$ かつ入力 1,374 wei において、一方のアームは 1,073,741,823 wei——ちょうど $L / 2^{96}$、一 ulp——を見積もり、もう一方はゼロを見積もった。そのステップが無に丸められ、閉じる側に失敗したのである。関係は二 ulp、アームごとに一つを述べる。MR-R1 と MR-R3：一方のプールの価格が他方から $10^{10}$ 離れているとき、計画は外れ値単独よりも 35 % 少なく支払った——深さ加重中央値がそれを信じることを拒んだのである——そのため、これらの関係は価格帯が受け入れるプールの上で成り立ち、定義域は二つの価格を ±4 % 以内に保つ。MR-R4：深さの重みが最小値に切り下げられるプールは、最初に登録されたときはダストレッグとして保持され、二番目に登録されたときは切り捨てられ、計画を出力の $3 \times 10^{-7}$ だけ動かす——最小重みのプールを分割が保持するか切り捨てるかはその位置に依存し、そのことは今や、それが発見された場所に書かれている。 ### §15.8 N バージョン：同じソースを別のコード生成で スイートは一つのバイナリを実行する——リリース設定が出力するものであり、`profile_parity.py` がスイートをその設定に保つ。他のあらゆるオプティマイザ設定は同じソースからコンパイルされた別のプログラムであり、コンパイラは構成要素の一つである。`test/nversion/` は Core の見積もり数学をさらに二つのプロファイル——`optimizer_runs` 1 と 20,000、その他はすべて同一——でコンパイルし、`NVersionCore.t.sol` は三つのバイナリを並べてデプロイし、ファズされた入力に対して等価性をアサートする：`outV2`、`outV3`、`outSolidly`、`outSolidlyStable`、`mulDiv`、`mulDivUp` を、入力の定義域全体にわたりそれぞれ 3,000 回。このレーンはまず、代替のバイトコードが出荷されたものと *異なる* ことをアサートするため、プログラムをそれ自身と比較して合格することはあり得ない。また、アーティファクトの欠落はスキップではなく失敗である。 **三つのバイナリは一致する。** 発見はコンパイラではなかった。このレーンの最初の全定義域実行は、*参照* 側をリバートさせた：stable 曲線の適合チェックは `max · WAD / b` を除算しており、その除算自体が、あるトークンを一単位未満しか保持しないプールでオーバーフローした。第二の抜け道——ホエール級の入力準備金とダスト級の出力準備金の組み合わせ——は不変式チェックを通過し、導関数をオーバーフローさせた。どちらも誤った数値ではなかった。どちらも見積もりの内側でのリバートであり、`universalQuote` はライブラリの `DELEGATECALL` であるため、出力トークンを一 wei 保持する登録済みプールが、そのペアに対する Solver の計画を巻き戻してしまった。修正（ §6 ）は、除算が代わりに担っていた問いそのものを問い、レッド先行で投入された。さらなるガード——ニュートン法の反復値への上限——も書かれたが、二つのチェックが成り立つ以上いかなるテストからも観測不能であることが判明し、持ち越されるのではなく削除された。その分類は、このリポジトリが最初に名指しするもの——フェイルオープン——であり、それを探していなかった計器によって発見された。 ### §15.9 射影距離 このリポジトリで確認されたすべての欠陥は、内部で見つかったものも報告されたものも、一つの形を持つ：チェックがある対象を観測する一方で、*別の* 対象が振る舞いを決定する。そのため、拒否にとって興味深い性質はその複雑さではなく距離——それが読むものが、決定するものからどれだけ離れているか——となる。`projection_distance.py` は、五つのコントラクト中のすべての `revert` を守る述語を分類する：定数、immutable、残高差分、あるいはそれらからフレーム内で計算された量は距離 0 であり、呼び出し元の経路のフィールド、または別のコントラクトの可変ストレージ内のルックアップは距離 1 であり、振る舞いを委譲し得るコントラクトの性質は非有界である。99 の拒否箇所について：**距離 0 が 86、距離 1 が 11、非有界が 2。** 二つの非有界箇所はどちらも `EXTCODEHASH` のピン——承認されたフックのコードと承認されたファクトリーのコード——であり、両者は対称ではない：フックについては、残余はピンが担わないアドレスビットによって閉じられる（ §14.2 ）。ファクトリーについては同等のものがなく、残余はプールの承認、レッグごとのフロア、ユーザーの最小値によって制限されるため、被害は資金の流出ではなく経路の劣化であり、そのことはその箇所に記載されている。このスクリーンの限界：それは一つの述語を読むだけで、ある値が三フレーム上で制約されていたことを見ることはできない。呼び出し元が宣言したフィールドがプールセレクタでもある場合、それが距離 0 であるのは一つの代入が両者を束縛しているからにすぎず、その代入は `test/V4SievedHookIsTheExecutedHook.t.sol` によって固定されている。 ### §15.10 証拠の独立性、共有量台帳、そしてアーティファクト 荷重を担う各ガードについて、装置は *独立した* 確認がいくつ存在するか——ソース、オラクル、ツール、環境、方法論ごとに——を記録し、その最小値を報告する。証拠の連鎖は最も弱い環で破綻するからである。荷重を担う性質は、仮説を一つも共有しない少なくとも二つの経路で確認される。共有量台帳（`SHARED_QUANTITIES.md`）は、複数の生成元または消費者を持つすべての量を列挙し、それが答える *問い* を述べ、複製どうしを束縛するものを `SINGLE`、`PINNED`、`WEAK`、`OPEN`、`UNVERIFIED` で格付けする。テストが固定すると主張する対象に届いていない行を降格させる CI ルールを伴う。関係台帳中の二つの生成元を持つすべての量（7 中 7）は、名前付きのテストによって結び付けられている。そして、ソースだけでなくコンパイルされたアーティファクトも読まれる：決して現れてはならないオペコード（`SELFDESTRUCT`、`CALLCODE`、`ORIGIN`）。実行器に依然として存在するトランジェントのオペコード——リエントランシーロックがひそかに永続ストレージになっていないことの確認。ディスパッチャに存在する、宣言されたすべての関数。五つのコントラクトのうち三つがストレージ書き込みをゼロ件しか発行しないこと。出荷形の命令列の 88.3 % が健全な下界によって実行済みと証明されていること——計器が印字する前に正しく分類しなければならない正解既知のコントラクトに対して検証済み。そして、リリース版 Router 上で各ステップでオペコードを確認しつつ再生した、記録済みの誠実な V2 スワップ一件について、Router 命令 4,382 個と Hub 命令 407 個が実行され、不一致はゼロ——二つのコードセクションの 28.2 % と 2.5 % であり、その補集合は、どの記録済みシナリオも実行しなかったコードであって、デッドコードではない。 ### §15.11 これらのいずれも確立しないこと - **正しさの確率は示されない。** 超高信頼性の検証に関する文献は、テストがそれを生み出せないことを明言している。ここではいかなる確率も述べない。 - **ミューテーション十分性は、この台帳に対する十分性である。** 台帳は手作業でキュレーションされており、飽和したスコアはフロアである。 - **脅威とレジームのカバレッジは、検討されたものに対するフロアである。** 誰も名指ししていない分類や因子は、構成上、分母の外にある。 - **§12 の分布はモックに対するものである。** ライブの Base は到達範囲を与えるが、分布は与えない。 - **検出率はテストごとの、シードあたり 256 回のファズ実行におけるものである。** その予算で見逃すテストも、より大きな予算では捕らえるかもしれない。 - **このリポジトリは V2 であり、V2 はデプロイされていない**（ §19 ）。 上記のすべての計器は、その数値が印字される前に較正された：まず別の経路で既に知られている欠陥に対して実行し、それを見逃した箇所は修正した——コメント内のテキストにマッチしたためにドキュメントを振る舞いとして読んでしまったテキストマッチャー、call-option ブロックを考慮していなかったカバレッジの正規表現、パターンリストが空だった対応物検索。計器は、既に知られている事例を見つけるまでは何の価値もない。探索なしの判定は空虚である。そしてコンパイラが決定するものはすべて計測され、決して見積もられない。 我々の知る限り、ミュータントごとの撃破テストと不活性ミューテーションの報告を伴う、キュレーションされ名前付けされたミューテーションガード；それを降格させる CI ルールを伴う共有量台帳；生存者を公表したうえでステートフル不変条件に向けたミュータント；一つのアサーションの下でのレジーム因子に対する強度 3 のカバリング配列；見積もり数学の N バージョンテスト；見積もりがどのように古びるかの計測曲線；あるいは自らの手数料ミュータントの検出率を信頼区間付きで公表している公開 DeFi コードベースは他に存在しない。アーティファクトはリポジトリにある。先行例を見つけたなら、この主張は誤りであり、我々はそれを知りたい。 ## §16 アーキテクチャとサイズ *平易に：* 五つのコントラクトがあり、そのうち一つは他の四つがインポートする純粋な数学であって、どの数学も二度定義されることはない。*厳密に：* Core はストレージもオーナーもアップグレード経路も持たないステートレスなライブラリである。Hub、Solver、Router、Quoter はそれをインポートし、いずれもプリミティブを再定義しないため、数学の一度の監査がすべての利用者をカバーする。 ### §16.1 五つのコントラクト：それぞれが保持するもの、それぞれが呼び出し得るもの | コントラクト | 保持するもの | 呼び出し得るもの | 永続状態を書き込むか | サイズ（ランタイムバイト） | |---|---|---|---|---| | **Core**（ライブラリ） | 何もない——pure および view 関数：Ω、𝒟、Φ、Ψ、モノスロットのコーデック、安全な送金、`mulDiv` | プールとトークン、読み取り専用、ガード付きのすべての `staticcall` は `GAS_CAP = 100,000` で上限設定 | 決して書き込まない——`tstore` も `sstore` もない | 6,442 | | **Hub** | レジストリ（プールごとに一つのモノスロット、ペアあたり ≤ 16）、ファクトリー行（≤ 16）、ブリッジ（≤ 3）、codehash ピン付きのフック許可リスト、V4 エントリ、ロール；ERC-7201 名前空間化 | プールとファクトリー、読み取り専用、Core 経由；V4 PoolManager には `extsload` 経由 | `recordSwap`（Router のみ）時、承認時および設定時 | 23,648 | | **Solver** | 何もない——`view` のみ | Hub（レジストリ読み取り、ディスカバリー）、Core 経由のプール | 決して書き込まない | 19,686 | | **Router** | 管理者、トレジャリー、`permit2`、`weth`、`paused`、`controlRenounced`、レスキューキュー；**静止時のトークン残高なし** | 入力トークン、経路のプール、出力トークン、Hub（`isBridgeToken`、`isHookLive`、`recordSwap`）、Solver（`swapBestExactIn` のみ、`view`）、V4 用の WETH と PoolManager、そのドア用の Permit2、トレジャリー、受取人——呼び出し元が指定したターゲットは決して呼ばない | 自身の設定；スワップごとの唯一の外部書き込みは成功経路上の `Hub.recordSwap` | 23,781 | | **Quoter** | 何もない | Solver（`view`）、Hub（`isBridgeToken`、読み取り専用）、Exact Pass のドライラン用のプール（呼び出してリバート） | 決して書き込まない | 11,429 |  信頼は一方向に流れる。Hub は `recordSwap` を呼び出すことについて Router を信頼し（`onlyRouter`）、他の誰も信頼しない。Router は経路が必要とする三つの事実——このトークンはブリッジか、このフックは稼働中か、そして登録の書き込み——について Hub を信頼し、取引の価格を決めるものについては何も信頼しない。Solver は Hub のレジストリを、計測すべき座標のリストとしてのみ信頼する。Quoter は Solver の計画を助言として信頼し、集中流動性のレッグをプールそのものに対して再価格付けする。calldata を信頼するものは何もない：経路は見知らぬ者の主張として Router に届く。 ### §16.2 一つのスワップの生涯  1. **プレビュー**（オフチェーン、無料）：`previewAndEncode` は `findBestRoutePlan` を実行する——レジストリ、そして新鮮でなければディスカバリー；Ξ；Ψ による順位付け；プローブ；価格帯；配分；クランプ；分割ゲート；証明済みフロア——そして `Preview` と calldata を返す。トレーダーは自らの価格予想から `userMinOut` を設定する。 2. **ドア**：`swapExactIn`（またはその兄弟関数）は期限を確認し（`RouterE(4)`）、ゼロの最小値を拒否し（`RouterE(10)`）、入力を引き込んで差分を計測する。 3. **`_execute`**：ホップ数、ホップあたりのレッグ数、ホップの連続性（`RouterE(3)`）；手数料のスキャン；ベースラインは一度だけ生成される。 4. **ホップごと**：計測された到着量に対して再スケールする；手数料ホップであれば手数料を課す（網羅時にはすべてのホップで）；各プールを一度だけ読んで量、インパクト、見積もりを得る；各レッグをその種別が選択する形で実行する（未知の種別には `RouterE(8)`、差分を改変するフックには `RouterE(9)`）；カバレッジゲート付きのレッグごとのフロアとホップの合計（`RouterE(5)`）；コールバックはコミットされたプールにのみ支払う（`RouterE(6)`）。 5. **スイープ**：ベースラインを超える未使用の入力とブリッジ残余は支払者に返還される。 6. **決済**：差分としての総出力（ゼロなら `RouterE(8)`）；計測されたインパクトと集中度からの `floorBps`；最終ホップのフレーム内見積もりと三者の最大値に対する経路フロア（`RouterE(5)`）；ブリッジコインへの直接経路での出力側手数料；送金、受取人での配送量の計測、配送量に対する `userMinOut`（`RouterE(5)`）；手数料台帳（`RouterE(15)`、`RouterE(16)`）。 7. **唯一の書き込み**：実行されたレッグごとに、計測された量で `Hub.recordSwap`；続いて `ExecutionProof`、`Swap`、`Fee` イベント。いずれかのチェックが拒否すれば何も書き込まれない。トランザクションは、すべてのプールのスワップを含めて、起こらなかったことになる。 ### §16.3 EIP-170 に対するサイズ | コントラクト | ランタイムバイト | 24,000 バイトのゲートまでの余裕 | EIP-170（24,576）までの余裕 | |---|---|---|---| | Router | 23,781 | 219 | 795 | | Hub | 23,648 | 352 | 928 | | Solver | 19,686 | 4,314 | 4,890 | | Quoter | 11,429 | 12,571 | 13,147 | | Core | 6,442 | 17,558 | 18,134 | | 合計 | 84,986 | | |  ゲートはスイート自身の内部（`DeployedSizeGate`）で、スイートが実行されるのと同じプロファイル上でアサートされ、そのプロファイルは `profile_parity.py` によってリリースプロファイルと同一に保たれる——チェーンが受け入れられないバイナリをテストするスイートは、誤った対象をテストしていることになる。サイズは計測され、決して見積もられない：数十バイトと見積もられたガードが、選んだ形が変数の生存区間を延ばしたために、計測すると数百バイトになったことがある。Router と Hub は壁まで数百バイト以内に位置しており、それゆえ §9 のペア証明は 179 バイトのコストで済み、§6 の stable 曲線の修正は置き換えたコードより 35 バイト *小さい*：追加されるすべてのバイトは、削除されるバイトで支払われる。 ### §16.4 数えられた攻撃面 攻撃面とは、敵対者が書き込めるもの、コントラクトが保持するもの、それが呼び出す相手、そしてそれに対して権限を持つ者である。ここではそれぞれが数えられる量である。 **呼び出し元が書き込めるもの。** 経路は型付きの構造である——最大 3 ホップ × 5 レッグ、各レッグは十個のフィールド（`pool`、`hooks`、`kind`、`fee`、`tickSpacing`、`zeroForOne`、`stable`、`amountIn`、`expectedOut`、`auxId`）——であり、呼び出しターゲットを名指ししたり calldata の塊を運んだりするフィールドはない。`docs/assurance/fields.json` は、状態、イベント、ガードのいずれかに到達する、呼び出し元が書き込み可能なすべてのフィールドを分類しており、全部で 23 個である： | 分類 | 件数 | 意味 | 例 | |---|---|---|---| | **確認済み** | 14 | 実行がそのフィールドを読み、*かつ* チェックがそれを観測値と比較する | プールの形から再導出される `leg.kind`（Hub の `recordSwap`）；プールが答える集中流動性プール上の `leg.fee`；計測された到着量で再スケールされる `leg.amountIn`；カバレッジゲートで引き上げられる `leg.expectedOut`；プール自身の `token0`/`token1` に対してゲートされる `hop.tokenIn`/`tokenOut`；実行されるプール id に入る V4 上の `leg.hooks` と `leg.auxId` | | **操舵** | 5 | フィールドがトークンの移動を方向付けるため、偽の値は呼び出し元を罰し、別個のチェックを必要としない | ペア型および集中流動性ベニュー上の `leg.pool`（トークンはそこへ送られる）；V4 上の `leg.zeroForOne`（誤った方向はマネージャーの会計で閉じる側に失敗する）；`route.singleOutFloor`（単調——締め付けることしかできない）；助言的な経路フィールド（`totalOut`、`estGas`、…）、誰にも読まれない | | **宣言のみ** | 4 | 状態、イベント、ガードのいずれかに到達するが、それを観測するものは何もない——それぞれ理由が記録されている | V2 ペア上の `leg.fee`（どのペアも `fee()` を公開しない；100 bps の上限で制限され、見積もりと実行の双方で同じく使われるため、両者は乖離し得ない）；V4 以外のレッグ上の `leg.hooks`（フック付きを最後にする順序付けにのみ供給される；偽れば呼び出し元が自らの経路を失う）；`Volume` イベントで公表される `leg.expectedOut`（同じフィールドを消費するレッグごとのフロアにより +25 % 付近で制限される；オンチェーンの消費者はない）；`leg.stable`（Hub は登録時に `stable()` を計測し、両方の消費者が同じ宣言を読む） | レジストリの順位付け、プロトコルフロア、手数料の基数は、確認済みの量のみから計算される。Hub は `kind` を確認し、Router は量、トークン、集中流動性の手数料を確認し、導出は V4 のフィールドを構成上確認する。 **トランザクション間に Router が保持するもの。** トークン残高はゼロ——`INV-1` であり、キャンペーンを通じて `invariant_RouterHoldsNothing`、`invariant_routerHoldsNothing`、`invariant_HoldsNothingBeyondTheSeed` によってアサートされ、四つのガードミュータント（一 wei 不足する送金、および三つのベースラインそれぞれの除去）によって見張られている。手数料はスワップの内部でトレジャリーへ流れ、残余はスワップの内部で支払者へ返る。Router に留まり得る唯一のものは誤送金であり、48 時間のレスキューはそれを返還するために存在し、すべてのスワップのベースラインはそれを支払いから除外する。五つのコントラクトのうち三つ——Core、Solver、Quoter——はストレージ書き込みを一切発行しない。 **スワップが呼び出す相手。** 一つのスワップの相手方は、八つのクラスからなる閉じた集合をなす：入力トークン；出力トークン；経路が名指しするプール（最大 15）；Hub；Solver（`swapBestExactIn` を通じてのみ、かつ view としてのみ）；WETH と PoolManager（V4 およびネイティブのレッグのみ）；Permit2（そのドアを通じてのみ）；トレジャリーと受取人。九番目はない：実行器は呼び出し元が指定した呼び出しターゲットを一切受け取らず（SOK-ARBITRARY-CALL）、レジストリが保持する種別によって選択される閉じた形の集合からベニューとのやり取りをディスパッチする。ガード付きのすべての読み取りは 100,000 ガスで上限設定される。スワップの正確な命令数はアサートされるのではなく記録される：リリースバイナリ上の一つの誠実な V2 スワップで、各ステップでオペコードを確認しつつ、Router 命令 4,382 個（ §15.10 ）。 **権限を持つ者。** Router に九つ、Hub に六つの制御関数があり、そのすべてが §14.6–§14.7 で、到達できるものとできないものとともに列挙されている。いずれも元本、手数料、分割、フロアを動かすことはできない。それらはすべて `renounceControl` で終わり、その後に残るのは、四つの関数からなる増加のみのキュレーター層と既存のオペレーター席である。`selfdestruct` はなく、プロキシもなく、Hub の一度きりの `initialize` 以降のイニシャライザもない。アーティファクト中の唯一の `delegatecall` は、公開 Core ライブラリへのコンパイラ自身によるものである。 **取引が決済されるために存在しなければならないもの。** §3.1 の予算：ルーティングサービスなし、オラクルなし、ソルバーネットワークなし、キーパーなし、プロキシなし——既存の設計が「必須」「一般的」「場合による」とするところに五つのゼロ。 **数えられた差異。** 経路をオフチェーンで取得して汎用の呼び出しリストを実行する設計、あるいは在庫を保持する設計に対して： | 攻撃面 | この設計 | オフチェーンでソルブされる実行器 | 在庫を保持するベニューまたはルーター | |---|---|---|---| | ガードに到達する、呼び出し元が書き込み可能なフィールド | 23、うち 14 は観測値に対して確認済みで、呼び出しターゲットを名指しするものは 0 | `(target, calldata)` ペアのリスト：非有界であり、各ターゲットはコントラクトが呼び出し元の言葉を根拠に行う呼び出しである | — | | 実行器内の静止時のトークン残高 | 0（`INV-1`） | 通常 0 | 在庫そのもの | | スワップ中にストレージを書き込むコントラクト | 1（`Hub.recordSwap`、実行されたレッグごとに一回の書き込み、成功経路のみ） | 場合による | ベニューの会計 | | 経路を計算するのは誰か | チェーン（`findBestRoutePlan`、`view`）または呼び出し元であり、いずれにせよフレーム内で再計測される | サーバー；コントラクトはチェックするが、選択はしない | — | | オラクル、キーパー、プロキシ、アップグレード経路 | 0 | それぞれ一般に ≥ 1 | 一般にプロキシ | | 元本に到達し得る特権関数 | 0 | プロキシ管理者がロジックを置き換えられる | 場合による | | 監査者が読まなければならないデプロイ済みバイト | 84,986、五つのコントラクト、すべて EIP-170 未満 | 決済コントラクト、加えて監査可能な行数としてのサイズが知り得ないサーバー | — | この比較は論じられたものではなく数えられたものである：差異は、非有界なリストに対する有界で型付きの確認済み経路であり、在庫に対するゼロであり、多数に対する一回の書き込みであり、そしてサーバーが導出しチェーンが単にチェックするだけの経路に対する、チェーンが導出した——あるいは呼び出し元が導出しチェーンが再計測した——経路である。 ## §17 計測された性能 *平易に：* 本節のすべては実在するチェーンのフォーク上で計測された——実在するベニュー、見知らぬ人々が預けた実在する準備金、一つのバイトコード——そして、まさにそのようなものとしてラベル付けされている。*厳密に：* ここに数値が現れるのは、リポジトリ内の公開ハーネスがそれを再現する場合に限られ、ハーネス、チェーン、日付がその横に印字される。フォークでの計測は挙動についての証拠であって、デプロイ記録ではない。デプロイ記録は §19 である。§12 と §15 の計測は 2026-09-05 のものであり、本節のキャンペーンは 2026 年八月に実施され、そのハーネスは `test/fork/` にある。 ### §17.1 クロスチェーンでの同一性 同一のバイトコードが Ethereum、Arbitrum、Optimism、Base のフォーク上で実行され、各チェーンのベニュー構成——Base では V4 と並んで Aerodrome と Pancake、Arbitrum では Camelot、Optimism では Velodrome——に、チェーンごとのコード変更なしで適応した。この四つのチェーンが選ばれたのは、これらを合わせるとレジストリが受け入れるすべてのベニューファミリーが実行されるためであり、したがってチェーンごとの特殊ケースがもし存在したならば、それが表面化する機会は四度あったことになる。すべてのチェーンで、二つの同一性がグラウンドトゥルースに対して計測された。CREATE2 導出については、𝒟 が計算した各プールアドレスを、同じペアとパラメータに対してそのチェーン自身のファクトリーが報告するアドレスと照合し、`hasCode` によって導出されたすべてのアドレスにバイトコードが存在することを確認した。Exact Pass については、ベニュー自身のスワップをライブ状態の上で呼び出し、そのデルタを revert ペイロードで持ち出し、チェーンごとに、Algebra のものを含む各ファミリーのコールバック規約を通り抜けることを確認した。両方の同一性は四つのチェーンすべてで成り立ち、表に必要となるはずの差異の列は空である。 ### §17.2 四つのチェーンにわたるプレビュー → 受け渡しの忠実度 この主張は直接の計測を許す：スワップを見積もり、実行し、比較する。`FidelityMatrix` フォークハーネスは、Arbitrum、Base、Optimism、Robinhood Chain 上で固定されたブロックにおいて実在するペアを見積もり、実行し、決済し、触れたすべてのペアについてプレビューと受け渡しを並べて印字する。50 bps に恒久的なアラームを備えているため、忠実度の退行は自ら名乗り出る。2026-08-24 に計測： | チェーン | プレビュー → 受け渡し | 併せて記録された事項 | |---|---|---| | Arbitrum | 実行されたすべてのペアで 0–1 bps | Solver の経路は 10 % 刻みの網羅的な二方向分割グリッドと一致する | | Base | 0–1 bps | グリッド最大値から 0.13 bps 以内；実際の約定はすべて込みで 222,000–326,000 ガス | | Optimism | 0–1 bps | このエンジンによる Optimism 上での、フォーク計測された初の V4 経由実行 | | Robinhood Chain | 0–1 bps | グリッドと完全一致；このチェーン上で初めて計測された実行 | このマトリクスは、定積、集中、V4——ネイティブを含む——、および Solidly のレッグをエンドツーエンドで実行する。帯域は実行されたすべてのペアで一ベーシスポイントであり、その背後に 50 bps のアラームがある。§17.1 の Solver 対グリッドの比較は単位まで一致する唯一の結果であり、そのように記述されている。二つの挙動上の結果が併せて得られている：ブリッジの中継トークンはメタ方程式の最大化子としてペアごとに適応的に選択され、意図的に孤立させたペアは捏造された経路ではなく経路なしを返す。 ### §17.3 ファクトリーの悉皆調査 ベニューの登録は一つの主張であり、その主張には固有の計測器がある。悉皆調査ハーネス（`FactoryCensus`）は本番のデプロイ配線を継承する——チェーンが受け取るのと同じスクリプトを通じてデプロイし、ハーネスとデプロイがずれれば実行を拒否する等価ゲートの背後にある。それはそのスクリプトとともに非公開のデプロイツリー内にあり、公開リポジトリには含まれないため、下の表は報告されたものであって、このチェックアウトから再現できるものではない。そのフィクスチャと反空虚性ゲートを共有する公開スイープは `test/fork/TokenSweep.t.sol` である。これは、固定されたトークンコーパスに対して、すべてのチェーン上の登録済みファクトリーそれぞれについて三つの列を報告する：登録済み、そのペアのプールを保有、そのペアを獲得（勝利経路のレッグを供給）。各列は一つの分母、すなわちホップペアを共有し、明示的な未解決バケットを持つが、それは四つのチェーンすべてでゼロと計測された：エンジンがルーティングしたすべてのレッグは、名前のあるファクトリーに帰属する。 | Arbitrum、88 ホップペア | プールを保有 | ペアを獲得 | |---|---|---| | Uniswap V4（ネイティブ + ラップ） | 67 | 48 | | Uniswap V3 | 86 | 33 | | Pancake V3 | 77 | 13 | | Camelot V3 | 66 | 10 | あるペアは、その勝利経路のレッグを供給したすべてのベニューに計上されるため、列はペア数を超えうる——分割ではなく帰属である。Arbitrum では、V4 ファミリーが正規の V3 ファクトリーを含む他のどの登録済みベニューよりも多くのペアを獲得している——§5.1 のネイティブ優先のプローブ順序の、外部からの確認である。悉皆調査は剪定の計測器でもある：登録され、プールを保有し、数百の計測ペアにわたって何も獲得しないファクトリーは、評判ではなく帰属によって値付けされた退役候補であり、すべてのスイープは反空虚性ゲートを備えている——深さがあると報告されたペアは、非ゼロの見積もりも返さなければならない。 ### §17.4 ガス すべての数値は名前のあるハーネスまで追跡可能であり、コールドとウォームは別々に報告される。 | 計測 | 値 | 出典 | |---|---|---| | コールドソルブ（初回発見、4 ファクトリー） | 169,093 ガス | `test/fork/DiscoveryColdWarm.t.sol`；`REPORTS.md` | | ウォームソルブ（キャッシュ済みモノスロット、発見をスキップ） | 132,691 ガス | 同一の実行 | | ウォームによる節約 | −36,402 ガス（−21 %） | 差分 | | 追加レッグ一つあたりの限界コスト | ≈ 28,700 ガス | `LifecycleMetrics`（2026 年八月） | | ブリッジ経由の第二ホップ | ≈ 59,000 ガス | `LifecycleMetrics`（2026 年八月） | | ライブ Base 上の `previewPlan`、コールド / ウォーム / TTL 後のコールド | 1,524,221 / 1,414,633 / 1,359,925 ガス | `test/fork/QuoterGasFork.t.sol`（§12.3） |  三つの構造的な読みは、アーキテクチャから導かれるため、いかなる計測もなしに成り立つ。ウォームによる節約は取引の大きさではなくレジストリの幅に比例する：コールドパスが支払う対象はファクトリーのスイープであり、スイープに取って代わるキャッシュ読み出しはいずれにせよ一回の `SLOAD` である。レッグは限界コストの単位であり、それが分割ゲートの存在理由である（§10.4）。そしてホップは高価な次元である：ブリッジ経路は、ポンプでの自らのコストを賄えるだけの差をプールで勝ち取らなければならない。呼び出し元はこの曲面上の自らの位置を取引ごとに選ぶ——フレーム内でソルブして探索の対価を払うか、経路を供給して実行の対価のみを払うか——そして §9.4 の鮮度ゲートは、プロトコルがまだ知らないペアのためにスイープを取っておく。ライブ見積もりのコストは 1.4–1.5 百万ガスの *view* 計算であり、オンチェーンでは誰もそれを支払わない。 ### §17.5 他の実装と比べたエグゼキュータ 外部の基準を持たないガス表は自画自賛であるため、実行層は同じフォーク上、同じブロックで、実際の本番 calldata を用いてベンチマークされた：KyberSwap の `MetaAggregationRouterV2`（`0x6131B5fae19EA4f9D964eAc0408E4408b66337b5`）を、各経路が構築されたブロックに固定した Base フォーク上で、2026-08-22 に、第二の比較対象として Paraswap の見積もりを併記して計測した：Kyber 自身がエンコードした経路をその公開 API から要求し、デプロイ済みのコントラクトに対して再生し、その横で我々の経路を実行し、双方の受け渡し量を残高デルタとして計測した。ハーネスはまず自らを検証する：競合の計測された受け渡し量はその API の約束と wei 単位で一致するため、どちらの側の revert も結果を装うことはできない。レッグあたりで、エグゼキュータは基準よりも 2.4× から 10.9× ガス効率が高いと計測された——最も明瞭なペアでは、四レッグで 322,172 ガス対一レッグで 879,553 ガス、トランザクションあたり 2.7×——この計測は、捕捉された calldata とともに非公開ツリー内にあるハーネス（`BenchExec.t.sol`）によるものであり、したがって数値は報告されたものであって、`optimizer_runs = 999999` でコンパイルされたこのチェックアウトから再現できるものではない——したがって差はコンパイラ設定ではなく設計によるものである。彼らのルーターはサーバーが決めた汎用の呼び出しリストを解釈し、我々のものは型付けされた構造を実行する。そして解釈にはコストがかかる。最も明瞭なペアでは、彼らの単一レッグ経路は 879,553 ガスを要し、我々の四つのレッグは 322,172 ガスを要した。九つの計測ペアにわたり、完全にソルブする扉と calldata の扉は同一の出力を受け渡した。手法の誤差範囲は結果の一部である：見積もりはそれが構築されたブロックに固定され、API 側のガス見積もりは、実際の実行がそのうちの一つを 148 % 過小と計測した後に破棄された。 ### §17.6 バイト–ガス交換レート ρ* 呼び出し元はどの扉を使うべきか——経路を calldata で運ぶか、チェーンにソルブさせるか？ トランザクションのコストはアフィンかつ分離可能である——$21{,}000 + \mathrm{bytes} \cdot p_{\mathrm{byte}} + \mathrm{gas} \cdot p_{\mathrm{gas}}$——したがって calldata と実行の間のトレードオフ全体は一つのスカラーに帰着する：**ρ\***、すなわち calldata の一バイトが購入する実行ガスである。リリースプロファイル上で `test/EquationBench.t.sol` により計測すると、ρ* はトランザクション全体で、単一レッグの経路で 66.9 ガス/バイトから、四レッグおよび五レッグの経路で 105.5 にわたる。これに対置されるのが各チェーンのライブなバイト価格であり、チェーン自身の手数料プリデプロイ——OP-Stack のガス価格オラクル、Arbitrum の `ArbGasInfo`——から、キーも第三者フィードもなしに読み取られる。 | チェーン、2026-08 にライブで読み取った価格 | $p_{\mathrm{byte}}$（ガス/バイト） | スワップに占めるデータの割合 | 安価な扉 | |---|---|---|---| | Base | 7.2 | 0.9 % | calldata 経路 | | Arbitrum | 12.8 | 3.4 % | calldata 経路 | | Optimism | 33.9 | 14.0 % | calldata 経路 | | calldata 価格のデータ可用性を支払う ZK ロールアップ | 243,256 | 99.9 % | フレーム内ソルブ——エンドツーエンドで 14× 安価 | $p_{\mathrm{byte}} < \rho^{*}$ であれば calldata の扉が安価なものであり、$p_{\mathrm{byte}} > \rho^{*}$ であればフレーム内ソルブが安価である。OP-Stack と Arbitrum のチェーンでは、データ項はスワップのコストの 0.9–14 % であり、したがって費用がかかるのは実行である——そこにこそ、上述のエグゼキュータの効率が複利的に効いてくる。Router の四つの扉は利便性のための機能ではない。それらはアフィンなコストモデルを、インターフェースにしたものである。 ## §18 骨格まで削ぎ落とした DEX 十七の節にわたるメカニズムは一ページに帰着する。他に何も読まないなら、これを読んでほしい。 **一つの仕事。** 二つのトークン、数量、あなたの最小値、受取人、期限を受け取る。そのチェーンの公開流動性が受け渡せる最大の出力を返す——さもなくば、理由を示すコードとともに拒否する。第三の結果は存在しない：敵対的ベニューのマトリクスでは、ベニューの病理と扉の組み合わせからなるフィクスチャ二十件中二十件が、フロアの内側で決済されるか、我々のセレクタで拒否する（§15.5）。 **五つのコントラクト、一つの数学。** | コントラクト | 一行で言えば何か | |---|---| | **Core** | ステートレスなライブラリ：すべてのベニューの閉形式、導出 𝒟、フロア Φ、活力スコア Ψ。一度だけ定義され、他の四つにインポートされる。 | | **Hub** | 流動性を取引することで学習するレジストリ——そして保存する前にすべてのペアを証明する。何も値付けしない。 | | **Solver** | *計測された*限界出力と深さから経路と分割を構築する。`view` のみ。 | | **Router** | 資金を動かす唯一のコントラクト。すべての残高デルタを計測し、フロアを強制し、静止時には何も保持しない。 | | **Quoter** | 無料のプレビュー——Router が決済に用いるのと同じ評価器であり、したがってプレビューと受け渡しは一致する。 | **六つのベニュー種別、四つのファミリー。** Uniswap V2、V3、V4（ネイティブ ETH を含む）、Algebra の動的手数料プール、そして Solidly のステーブルおよびボラタイルペア——それぞれが Core 内の一つの閉形式によって値付けされ、そのすべてに一つのディスパッチャ Ω が対応する（§4）。Curve と Balancer は切除され、その種別番号は永久に退役した（§4.1）。 **四つの扉、一つのエグゼキュータ。** `swapExactIn`、`swapExactInWithPermit2`、`swapExactInNative` は経路を calldata で受け取り、`swapBestExactIn` はオンチェーンでアトミックにソルブして実行する。四つすべてが同じ `_execute`、同じフロア、同じ手数料に到達する（§11.1）。 **すべての取引の下にある三つのフロア。** レッグごとのフロア、ホップの集計、そして実行フレーム内で計測されたインパクトから再導出される経路フロア Φ——その上で、受取人に実際に届くものに対する*あなたの* `userMinOut`。受け渡し量は、プロトコルのフロアとあなたのものとの大きい方である（§11.5）。 **一つの手数料、コンパイル時に組み込み。** 0.28 %、Router が保持する最初のブリッジコインに対して一度だけ課され、決してゼロにならないよう切り上げられ、見積もりと受け渡しの差とともに増大するものは何もない（§13）。 **それが信頼を拒むもの。** 宣伝された流動性。申告された手数料。calldata の深さ。どのトークンを取引するかについてのプール自身の申告。そのいずれもが、共有状態に到達しうる前に、プールから計測されるか算術によって導出される（§7、§9、§16.4）。 **それが要するコスト。** ガス：フレーム内で経路を導出することは、他所で計算された答えを決済するよりも高くつき、§17.6 はチェーンごとにどの扉が最も安価かを示す。不変性：欠陥は開示され報奨金の対象となるが、決してパッチされない（§21）。 ## §19 デプロイ状況 本稿はリポジトリを文書化するものであり、リポジトリが正典である：本文とソースが食い違う場合、ソースが優先する。二つの世代が存在し、それらが混同されることは決してない。 **V1 がオンチェーンで稼働しているものである。** それは別の、より以前のコードベースであり、独自のリポジトリにアーカイブされている——このリポジトリの以前のコミットではない。2026-09-04 に RPC で計測したところ、デプロイ済みの V1 ルーターは Base、Ethereum、Optimism、Arbitrum 上で同一の 14,624 バイトのコントラクトである。`test/fork/DeployedParity.t.sol` と `test/fork/DeployedCodehashPin.t.sol` は、SDK が名指すすべてのネットワーク上で V1 が何であるかを固定する——各デプロイ済みコントラクトのコードハッシュであり、`test/fork/deployed-codehash.json` に記録されている——そのため、デプロイされているものへの変更は察知される。そしてこれらは世代に関わらず成り立つ性質を表明する：`SELFDESTRUCT` がないこと、`CALLCODE` がないこと、`tx.origin` による権限がないこと、トランジェントな再入ロック、固定されたランタイムサイズ、ライブな配線、そしてまだ放棄されていない制御。 **このリポジトリは V2 であり、V2 はデプロイされていない。** 本稿で計測されたツリーは 23,781 バイトの Router をビルドし、V1 が持たない外部関数を備えている——その中には、ネイティブ値の扉、ラップ/アンラップの継ぎ目、救出経路、そして Permit2 の扉がある。V2 コントラクトはライブ流動性のフォーク上にデプロイされ、すべてのフォーク実行においてエンドツーエンドで実行される（§15.1、§17）。§15 や §17 のいかなる内容も、デプロイ済みの V1 コントラクトを保護するものではない。本稿のすべての主張は、`8949a9d` 時点の V2 についての主張である。 それに応じて、二つの方針が読者を保護する。本稿はコントラクトアドレスを一切含まない——アドレスはそれを引用する文書よりも長く生き残るものであり、ライブなアドレスの表面は、それが更新でき機械的に検証できる場所で維持される：リポジトリの記録、そしてサイトの検証ページとマニフェストである。そして、デプロイ記録には規定された形式がある——チェーン、アドレス、デプロイしたコミット、ランタイムバイトコードのハッシュを、ブロードキャスト時に記録し、クリーンなビルドからハッシュを再導出する検証ステップを伴う——そのため、V2 がデプロイされるとき、すべてのアドレスの主張は信頼ではなく算術となる。 ## §20 トークン——BZPX 十億 BZPX、永久に固定、素の ERC-20 として：18 デシマル、ミント経路なし、転送時手数料なし、リベースなし、転送フックなし、一時停止やブラックリストなし——六つのデプロイ不変条件が、配線時にトークンのバイトコードに対して検査される。完全希薄化後の供給量はジェネシスから既知であり、希少性はポリシーではなくコントラクトの性質である。 | 配分 | トークン数 | 割合 | 注記 | |---|---|---|---| | 市場流動性 | 520,000,000 | 52.0 % | アグリゲーターがルーティングする流通分 | | ステーキングエミッション | 180,000,000 | 18.0 % | 留保；V4 のエミッション設計は §25 にある | | エアドロップ & バウンティ | 130,000,000 | 13.0 % | 一つのプール：旧 50,000,000 のエアドロップ、§21 の旧 50,000,000 の研究プール、そして市場流動性から移された 30,000,000 | | チームと運営 | 103,000,000 | 10.3 % | 唯一のロックされたインサイダー分；30 か月の線形ベスティング | | パートナーとエコシステム | 60,000,000 | 6.0 % | インテグレーション、ベニューとのパートナーシップ | | マーケティング | 7,000,000 | 0.7 % | ローンチの認知 | **2026 年九月に変わったこと。** エアドロップとセキュリティ研究プールは、同じ人々に同じこと——プロトコルを徹底的に読み込み、本気で使うこと——に対して支払う二つの項目であった。それらは現在 130,000,000 BZPX の一つの項目となっている：エアドロップから 50,000,000、研究プールから 50,000,000、そして市場流動性から 30,000,000 を取り、市場流動性は 550,000,000 から 520,000,000 へと移る。他の誰の項目からも何も取られておらず、供給量は依然として正確に十億である。 トークンコントラクトのオンチェーン記録は、公表され次第、この表の正典版となる。執筆時点で、トークンには供給された流動性もトークン生成イベントもない。オンチェーン出来高がゼロであることはこの段階の想定された状態であり、コードについてのシグナルではない。 ## §21 研究プログラムとセキュリティ記録 このプロジェクトがその名に値する研究プログラムを持つ前から、独立した研究者たちがソースを敵対的に読み——頼まれもせず、何の約束もなく——見たものを非公開で開示した。本稿が記述するコードは、彼らの読解を生き延びたコードである。彼らそれぞれが何を報告し、それがどうなったかは、そうした記録があるべき場所に置かれている：リポジトリの `SECURITY.md` と `SECURITY_HALL_OF_FAME.md` の中、コードの隣であり、そこではすべての項目を双方向に検証できる。本節は、彼らが誰であるか、敵対的な読解が何を支払われるか、そしてそれが見出したものの形を記録する。 **研究者たち。** NetGakarot · duxun · AmanDara1 · amitbhakar · auditor_1b3f2c · siam siddik · Thomas · llen · destinyae · superagent · Mohd Huzaifa · Raditya · bai bo · Josh W · Borutobro · mohaseenkatika · mohaseenbasha · Karan Rathod · Seavia Resources · acit aja · Brian Wahyu · M2000 Slash · Binod Bk · CHARIR ABDELHAMID · そして匿名のままでいることを選んだ一人の研究者。二十五人の研究者がクレジットされており、Critical クラスに達した報告はない。帰属は決して切り捨てられない：名前は与えられたとおり正確に公表される。 **プール：エアドロップ & バウンティ、130,000,000 BZPX——固定供給量の 13 %**（§20）。セキュリティ報奨はここから以下の帯域で支払われ、その帯域は変更されていない。 | 深刻度 | 報奨 | |---|---| | Critical——ユーザー資金の直接的な窃取または恒久的な凍結；到達可能な支払不能状態 | 2,500,000 – 7,500,000 BZPX | | High——特定条件下での窃取；誤った当事者に系統的に支払う再分配 | 625,000 – 2,500,000 BZPX | | Medium——グリーフィング、一時的なサービス拒否、回収可能な残余 | 125,000 – 625,000 BZPX | | Low——上記を下回る実証された影響 | 最大 125,000 BZPX | 報奨は BZPX で支払われる——数量とスケジュールは約束されるが、市場価値は約束されない——支払いは 2026 年十月以降に開始され、報告は現在トリアージされている。一つの条項は意図的なものである：報告が Critical であるために保存則を破る必要はない——帳簿が釣り合っている一方で誤った当事者に系統的に支払う再分配は、窃取と同様に値付けされる。なぜなら、それこそが敵対的な読み手だけが捕捉するクラスだからである。 **記録が含むもの、クラス別。** 確認されたすべての発見は、名前付きの性質、修正前のコードに対して失敗する回帰テスト、そしてテストが撃破しなければならないミュータントとなった。クラスを、それぞれ一文で、登録簿を参照して示す： - *一つの量の二つの生成者*——プランナーとエグゼキュータ、プレビューと受け渡しが、一つの問いに二つのフレームで答えること（フロアのインパクト集計、プレビューが名指すブリッジと手数料が錨を下ろすホップ、二つのコントラクトにまたがるレッグ予算、凍結されたブリッジビットとライブな述語）：一つの生成者への集約または名前付きのパリティテストによって閉じられ、CI ルールを伴う登録簿として列挙されている。 - *計測が存在したところでの呼び出し元供給の量*——`route.totalOut` から読まれた手数料ベース、calldata から書き込まれたレジストリの手数料とフック、計測されずに申告された深さ、申告をそのまま報告した公表出来高：計測することによって、そして §16.4 のフィールド分類によって閉じられた。 - *不在を許可として読むこと*——フレーム内で見積もれなかった最終ホップがフロアを不活性のままにしたこと、呼び出し元がゼロを書き込むことで無効化できたカバレッジゲート、ファミリー全体をゼロで見積もった空の手数料リスト：無ではなく、証明された値または計測された値へのフォールバックによって閉じられた。 - *誤った対象への固定*——コードハッシュが変わらないままプロキシが動かしうるファクトリーの導出元、実装が動きうる箇所で固定されたフックのランタイム：コードを固定できない箇所では答えを証明し、閉じることのできない箇所では残余をその場所で記述することによって閉じられた。 - *見積もりにおけるフェイルオープン*——ダストに対してそれ自体がオーバーフローしたステーブル曲線のドメインガードであり、N バージョンレーンによって発見された：レッドファーストで閉じられ、修復は置き換えたコードよりも小さかった。 - *二つの対称なチャネルの一方にだけ適用された修正*——このコードベースが最初に名指す欠陥の署名であり、繰り返し遭遇した。現在では、すべての閉鎖がマージ前に兄弟を探索する。 この招待こそが本節の要点であり、それは常設である：独立した読み手は、公開の場で招待され、数量が固定された通貨で支払われる。リポジトリの `SECURITY.md` にある開示チャネルを通じて、非公開で報告されたい。 ## §22 信頼しなければならないもの、そして信頼する必要のないもの あらゆるプロトコルはトラストレスであると主張するが、その例外を列挙できるものはほとんどない。以下が完全なリストであり、各権限はそれを制限する一行とともに記述されている。 - **ベニューレジストリ、ブリッジリスト、V4 フックの許可リスト**——キュレーションされる。敵対的な掲載の最悪のケースは、あなたの最小値と Iron-Law フロア Φ のうち厳しい方によって制限され、元本には到達できない（§9.6、§14.6）。 - **放棄前の Router の制御鍵**——手数料の送り先を変更し、スワップを一時停止し、そのネイティブの扉と Permit2 の扉が呼び出す WETH および Permit2 コントラクトの参照先を変更し、48 時間の公開遅延の背後で誤送されたトークンを回収できる。手数料率、分割、フロアを動かすこと（コンパイル時定数であり、セッターはない）や、元本に到達すること（プロキシなし、アップグレード経路なし、`selfdestruct` なし、静止時に保持するものなし）はできない。 - **放棄前の Hub の制御鍵**——Hub から見た Router、Solver、Quoter の参照先を変更し、V4 マネージャの参照先を変更し、レジストリの学習を一時停止し、オペレーター席を付与できる。約定の値付けを誤らせることはできない。取引を値付けするものは何もレジストリを読まないからである。 - **トレジャリー**——構築時に固定され、30 / 70 の分割にはセッターがない。 - **扉が依存する正規コントラクト**——Permit2 の扉には Uniswap の Permit2、ネイティブの扉にはチェーンの WETH、V4 レッグには PoolManager：それぞれはその扉またはそのレッグを通じてのみ呼び出され、Router はすべてのレッグを自身が計測した残高デルタから値付けするため、不誠実な相手方は出力を崩壊させ、あなたの制限がスワップを拒否する。 - **トークンと対応関係**——BZPX がその六つのデプロイ不変条件を満たすこと、そしてあなたが呼び出すアドレスが本文に対応すること：§19 の記録が公表された瞬間から、§19 が規定する手順によって検証可能である。 信頼する必要のないもの：あなたの取引を値付けする誰か——経路は公開状態から実行フレーム内で導出されるか、あなたが供給した場合はそこで再計測される。それを公正にルーティングする誰か——フロアは計測された出力からオンチェーンで再導出され、手数料には見積もりと受け渡しの差とともに増大する項がない。手数料を数える誰か——Router はそれを支払わずに決済することを拒否する。そしてあなたに奉仕し続ける誰か——このプロジェクトが運営するすべてのサーバーが今夜消えたとしても、コントラクトは明日も今日とまったく同じように見積もり、ルーティングし、決済するだろう。 そして、この文書から一つの習慣を持ち帰るなら、それを自らの取引に設定する最小値にしてほしい。アグリゲーターのあらゆる制限はその数値にフォールバックする。それは、その質が他の誰でもなくあなた自身の能力だけに依存する、システム内で唯一の保護である。 ## §23 関連研究 **ルーティング。** Angeris、Evans、Chitra、Boyd は、定数関数マーケットメイカーにわたるルーティングを、その最適解がベニュー間で限界価格を等しくする凸計画として定式化した。Diamandis、Resnick、Chitra、Angeris はそれに対する効率的な双対分解アルゴリズムを与えている。本設計はオンチェーンにおいて意図的にその最適解の手前にとどまる：分割アロケータは一回のパスで深さに比例するもの（§10.4）であり、反復もベニューごとの曲率モデルも必要とせず、反復型ソルバーがガスの請求書であり攻撃面であるところで頑健である。メタモルフィックレーンはこの選択が要する距離を計測する——分割は最良の単一プールを決して下回らず（MR-R1）、忠実度マトリクスは Base 上で Solver の経路を網羅的グリッドから 0.13 bps 以内に位置づける。定積ファミリーに対する、限界収益を厳密に等しくする閉形式は、ベニューごとに二つの和と一つの平方根であり、後のリリースの候補である。目的関数はその最適解の近くで平坦であり、それが頑健な規則が先に出荷される理由である。オフチェーンのソルバー設計は最適化をサーバーに移し、コントラクトをチェッカーに縮小する。§3.1 の依存予算は、それが何を要するかについての本稿の記述である。近年の研究はモデルをガスで拡張している：*Optimal Routing across Constant Function Market Makers with Gas Fees* は、ガスが無取引領域を広げ、断片化と非自明に相互作用することを示し、*Routing Frictions and Executable Liquidity in Fragmented Markets* は宣伝された流動性と実行可能な流動性を区別する——本設計がモデル化するのではなくフレーム内で計測する区別である。 **頑健な集計。** §10.3 の信頼中心は深さ加重中央値であり、その破綻点は重みの半分である。Müller、Moumeni、Messaoudi は *Cost of Manipulation in AMM-Based Oracles*（FC 2026）において、AMM 価格を集計するオラクルに対する対応する上界を証明している：等しい重みでは最も安価な攻撃は最も浅いプールを動かし、一方で流動性による重み付けでは、重みの半分を支配するには見積もり深さ全体の少なくとも半分が必要となる。Ormer は TWAP の平均に代えて中央値を推定するオンチェーンオラクルを提案し、*From Means to Medians* はどのベンチマークが最も操作されにくいかを研究している。E25 は同じ原理をルーティングに適用する：プールは、その背後にあるリスクに晒された資本の分だけ信じられる。 **ベニュー。** Uniswap v2 は定積の基準と、V2 ブランチがデフォルトとする 30 bps の慣行を与える。Uniswap v3 は、§4.2 の閉形式が従う集中流動性モデル、`slot0`、Q64.96 固定小数点を与える。Uniswap v4 は、§5 と §14.2 が依拠するシングルトン、フラッシュ会計、フック権限のアドレスエンコーディングを与える——本設計は、我々の知る限り、V4 プールを完全にフレーム内で導出、証明、値付け、選別、決済する最初のものである。Egorov の StableSwap は Curve ファミリーの増幅された不変条件を定義しており、本プロトコルは計測されない信頼仮定の上でそれをサポートするのではなく切除した（§4.1）。§6 の Solidly ステーブル曲線には査読付き論文がなく、そのデプロイされた実装によって引用される。 **MEV。** Daian らは順序付けの敵対者を名付け、その規模を示した。Zhou らは分散型取引所に対するサンドイッチ攻撃を計測し、その収益性を定式化した。本稿は排除を主張しない——順序付けはコントラクトコードが実行される前に決まる——代わりに上界を計測する：§14.3 のサンドイッチ曲線を攻撃者の側から、拒否の縁とその先での攻撃者の負の往復とともに示す。 **検証。** Clarkson と Schneider のハイパープロパティは、§21 の再分配に関する発見が属するクラスを名付ける——一つのトレースではなくトレースの集合の性質——そして、なぜ保存則が成り立ちながら誤った当事者に支払われうるのかを説明する。Cousot と Cousot の抽象解釈は単一ティックの閉形式の枠組みである：ある範囲内では厳密で、その外側では一方向に健全なベニューの数学の抽象化であり、フロアが具体化の検査となる。Chen、Cheung、Yiu はメタモルフィックテストを導入した。これは、式から独立したオラクルが存在しないところでの §15.7 の第二の審判である。DeMillo、Lipton、Sayward はミューテーション解析を導入し、その結合仮説に §15.2 のキュレーションされたガードが依拠している。Avizienis の N バージョンプログラミングは §15.8 の祖先であり、独立したチームではなくコード生成に適用されている。Kuhn、Kacker、Lei の組み合わせテストは、§15.4 のカバリング配列にその構成と主張を与える：レジーム因子のすべての t 方向の相互作用が構成によって実行され、分母が印字される。Littlewood と Strigini の超高信頼性の検証に関する結果は、本稿のどこにも正しさの確率が記述されていない理由である。 **標準。** EIP-1153 のトランジェントストレージは、単一コールバックの原則のレッグコンテキスト、手数料台帳、再入ロックを運ぶ。EIP-170 は、Router と Hub が数百バイト以内に収まっている 24,576 バイトの壁である。EIP-1014 は 𝒟 の CREATE2 算術である。EIP-2612 と Uniswap の Permit2 は第二の扉の署名ベースの転送を定義する。ERC-7201 は Hub のストレージに名前空間を与える。EIP-7702 の委任アカウントは、他のどのコントラクトとも同じ扉を呼び出す。 ## §24 結論 我々は一つの規律——計測せよ、信じるな——の上にアグリゲーターを構築し、数値が代わりに誰かの言葉で受け取られえたあらゆる箇所でそれを堅持することを目指した：経路、価格、フロア、手数料ベース、ベニューの集合、プールが取引すると主張するペア、さらにはプロトコル自身のコストモデルまで。 結果は、強い形を持つ小さなシステムである。流動性の断片化は、数学ではなく言語の問題であることが判明した：ベニューの増殖の下には小さな不変条件のファミリーが横たわっており、それぞれを一度だけ表現するプロトコル——ディスパッチャ、導出、フロア、活力場——は、ベニューごとの特殊扱いなしに全体像を値付けし、それを実行するトランザクションの内部で経路を導出し、トークンがあなたに届く前に、計測された出力に対して自らの約束を再検査することができる。計測された記録は、それが何をもたらすかの最も短い要約である：モック上でもライブ Base 上でも 64 回中 64 回、予測どおりに正確に決済されるドリフトのない見積もり。1 % の取引に対するサンドイッチをその約 2.7 % に抑え、それを超えれば拒否するフロア。四つのチェーンにわたって 0–1 ベーシスポイントしか離れていないプレビューと受け渡し。そして、自らがどのように悪用されうるか、何が見えないかを、分母とともに公表する装置。 それが要するコストも同様に明白である。ガス：フレーム内で経路を導出することは、他所で計算された答えを決済するよりも高くつく——それは、誰かの言葉で受け取らなければならない保証ではなく、自ら検査できる保証の価格である——そしてバイト–ガス交換レートは、チェーンごとに、どの扉がその価格を最小にするかを教えてくれる。不変性：欠陥は開示され報奨金の対象となるが、パッチされない——一度監査すれば済むコントラクトの価格であり、§21 はその価格が購入するものである。 主張を改めて述べる：選ぶものが、取引するものである。見積もりとその実行は同一の計算であり、したがってかつてオペレーターの誠実さが占めていた隙間は算術によって閉じられる。流動性を取引することで学習し、保存するすべてのペアを証明するレジストリ。誰も——著者たちを含めて——動かすことのできない手数料、フロア、エントリー面。それらはコンパイル時に組み込まれているからである。このプロトコルは信頼されることを求めない。検証されることを求め、検証を安価で、公開的で、恒久的なものにするために働く。 ## §25 ステーキング V4：設計 ステーキング V4 は現行のコードベースであり、アドレスはローンチ時に公開される。 本章は、ステーキングエンジンをそのソースの現状どおりに記述する。すなわち `Blaze-Phoenix-Staking` リポジトリの `src/BlazePhoenixStaking.sol`、`cc614f9`（2026-10-14）時点の `main` であり、これは `VERSION = "4.0.0"` を宣言している（L169）。本章のすべての行番号（L*n*）は、そのコミットにおけるそのファイルを指す。本文とソースが食い違う場合は、ソースが優先する。本章はアドレスもデプロイ日も利回りも含まない。本章のすべての数値は、コントラクトにコンパイルされた定数であるか、それから導出されたものであり、その導出は傍らに印字されている。 エンジンは本論文の他の部分と同じ規律に従う。エンジンが保持するトークンは BZPX ただ一つであり、その BZPX に対するあらゆる請求権は台帳上の項であって、その総和をコントラクトは各状態変更の前後で再検査する（E35）。ステーカーは BZPX を選んだ日数だけロックし、二つのストリームを得る — 予定されたエミッション（E27–E29）と借り手が支払う利息（E31–E34）— それぞれがコミットメントとともに増大するブーストで重み付けされる（E30）。ステーカーはステークを担保に BZPX を借り入れることができる（E41）。損失が生じた場合、それは一つの固定された順序に従い（E37）、コントラクトは負っているものを保有しているかどうかを公開のビューとして報告する（E36）。 ### §25.1 アーキテクチャとロール コントラクトは一つ、`BlazePhoenixStaking` であり、`AccessControl`、`Pausable`、`ReentrancyGuard` を継承する（L167）。トークン、トレジャリー、エミッションウィンドウ（`emissionStart`、`emissionEnd`）はイミュータブルである（L266–269）。コンストラクタは、コードを持たないトークンアドレスを拒否する（L477）。オラクルも、アップグレード経路も、パラメータのセッターも存在しない。以下のすべての定数はコンパイル時に組み込まれている。 | ロール | 保有者 | 可能な操作 | 行 | |---|---|---|---| | `DEFAULT_ADMIN_ROLE` | デプロイヤー（構築時） | ロールの付与と剥奪（`_setRoleAdmin` の呼び出しは存在しないため、このロールがすべてのロールを管理する） | L485 | | `ADMIN_ROLE` | デプロイヤー（構築時） | `fundEmission`（累積資金供給 ≤ `TOTAL_REWARDS`）；`withdrawReserve`（イミュータブルなトレジャリーへのみ、最大 `protocolReserve`、ハードブリーチ下では閉鎖）；`sweepUndistributedEmission`（`emissionEnd` 以降のみ）；`unpause`；`cancelEmergency`（支払能力のある帳簿でのみ） | L486, L516, L533, L563, L580, L618 | | `GUARDIAN_ROLE` | 構築時には誰も保有しない。ロール管理者が付与する | `pause`；`declareEmergency` — いずれも資金を動かさない | L171, L578, L608 | | 誰でも | — | `liquidate`；`tripBreaker`（帳簿がハードブリーチ状態でない限りリバートする）；`absorbBadDebt`；`lockStep` | L1066, L597, L639, L1291 | いかなるロールもステーカーの元本を動かすことはできず、いずれかのロールが収益を送ることのできる唯一の宛先はイミュータブルなトレジャリーである。 | 定数 | 値 | 意味 | 行 | |---|---|---|---| | `TOTAL_REWARDS` | 180,000,000e18 | エミッション予算、かつ累積 `fundEmission` の上限 | L192 | | `HALVING_PERIOD` | 2 × 365 日 | 一つのエミッション期間の長さ | L193 | | `EMISSION_PERIODS` | 8 | プログラム終了までの期間数（`EMISSION_LENGTH` = 16 年） | L194–195 | | `INITIAL_REWARD_PER_SEC` | (`TOTAL_REWARDS` / 2) / `HALVING_PERIOD` | 期間 0 のレート、$R_{0}$ | L196 | | `MAX_STAKE_PER_WALLET` | 30,000,000e18 | ポジションあたりのステーク上限 | L198 | | `MIN_EMISSION_WEIGHT` | 1,000e18 | 総重みがこれを下回ると、両ストリームは按分でスロットルされる | L208 | | `MAX_LTV` | 50 | 借入上限、正味ステークに対する % | L210 | | `LIQ_THRESHOLD` | 95 | 負債 ≥ ステークの 95 % で清算可能 | L211 | | `LIQ_BONUS_BPS` | 500 | 呼び出し元への清算余剰、負債に対する bps | L212 | | `RESERVE_FACTOR_BPS` | 300 | 各利息スライスのうち `protocolReserve` に保持される割合 | L213 | | `MIN_LOCK_DAYS`, `MAX_LOCK_DAYS` | 90, 2,555 | ロック日数の範囲 | L221–222 | | `BOOST_BASE`, `BOOST_LINEAR`, `BOOST_QUAD` | 10,000, 750, 250 | ブースト多項式、bps | L224–226 | | `MIN_DEPOSIT_BLOCKS` | 10 | 引き出し、純粋利回りの請求、またはロック変更の前に、預け入れが経過しなければならないブロック数 | L228 | | `RATE_R0`, `RATE_RK`, `RATE_UK`, `RATE_S1`, `RATE_S2` | 100, 500, 0.8e18, 500, 72,500 | キンク付き利率曲線、年率 bps | L231–235 | | `MAX_PROTOCOL_UTIL_WAD` | 0.75e18 | 新規借入に対する帳簿利用率の上限 | L242 | | `CONSERVATION_DUST` | 1e10 | 保存ガードの許容誤差、wei 単位 | L247 | | `MAINT_BASE`, `MAINT_DENSITY`, `MAINT_GAP_UNIT`, `MAINT_MAX_SCAN`, `MAINT_MAX_LOCK_ACTIONS` | 1, 50, 15 分, 10, 4 | 自律メンテナンスの予算（E42） | L252–255, L263 | ### §25.2 フロー：ステーク、アンステーク、請求、借入 すべてのユーザーエントリポイントは、`deposit` が定める順序で一つのパイプラインを実行する。保存恒等式のスナップショットを取る。帳簿がハードブリーチ状態であれば拒否する。利息インデックスとエミッションウィンドウを進める（`_updateGlobal`、L1428）。ポジションが保持していた重みで両ストリームを決済する。ポジションが負う利息を帰属させる（`_accrueInterestFor`、L1627）。経過したロックを解除する。アクションを実行する。単一の書き込み手（`_resync` → `_applyBoost` → `_checkpoint`、L1726–1756）を通じてポジションの重みを再計算する。自律メンテナンスウィンドウを実行する（E42）。そして保存恒等式を再び検査する（E35）。扉どうしの違いは、それぞれが追加するゲートだけである。 | エントリポイント | 一時停止中 | 緊急時 | ハードブリーチ | その他の条件 | |---|---|---|---|---| | `deposit(amount, lockDays)` — ステーク | 閉鎖 | 閉鎖 | 閉鎖（L760） | $90 \le$ `lockDays` $\le \min(2{,}555,\ \text{days left to } \mathtt{emissionEnd})$；ポジションのステーク ≤ `MAX_STAKE_PER_WALLET`；`emissionEnd` より前（L743–760） | | `lock(lockDays)` | 閉鎖 | 閉鎖 | — | 最後の預け入れから `MIN_DEPOSIT_BLOCKS`（L964–971） | | `withdraw(amount)` — アンステーク | 開放 | 閉鎖 | 閉鎖（L902） | 負債なし；ロック経過済み；最後の預け入れから `MIN_DEPOSIT_BLOCKS`（L890–895） | | `claimRewards()` | 開放 | 閉鎖 | 閉鎖（L932） | エミッションと純粋利回りを決済する（L930） | | `claimPureYield()` | 開放 | 閉鎖 | 閉鎖（L948） | 負債なし；最後の預け入れから `MIN_DEPOSIT_BLOCKS`（L944–948） | | `borrow(amount)` | 閉鎖 | 閉鎖 | 閉鎖（L826） | E41（L820–840） | | `repay(amount)` | 開放 | 閉鎖 | 開放 | —（L858） | | `liquidate(user)` | 閉鎖 | 閉鎖 | 開放 | E39（L1066） | | `emergencyWithdraw()` — 退出 | — | のみ | — | E40（L658） | | `absorbBadDebt(amount)` | 開放 | 開放 | 開放 | E38（L639） | **ステーク。** `deposit` は BZPX をポジションに引き込み、そのロックを開始または延長する。ロックがエミッションプログラムの終了を超えて続くことは決してなく、それによって得られるブースト（E30）はロックが有効である間にのみ支払われる。**アンステーク。** `withdraw` は、ポジションが何も負っておらず、そのロックが経過した時点で元本を返す。これはガーディアンによる一時停止の下でも開放されたままであるため、一時停止は誰も閉じ込めることなく新たなリスクを止める。緊急時の唯一の出口は `emergencyWithdraw` であり、これは正味エクイティを支払い — コントラクトの保有額がポジションへの債務より少なければ按分で縮小される（E40）— ポジションの未請求のストリームを没収する。**請求。** 収穫とは二つの請求のことである。`claimRewards` は両ストリームを支払い、`claimPureYield` は負債のないポジションに対して同じものを支払う。別個の収穫関数は存在しない。**借入、返済、清算。** ステーカーは自らのステークを担保に、二つの上限の範囲内で BZPX を借り入れることができる（E41）。利息は負債に加算されるのではなく、ステークに対して課される（E34）。`repay` は一時停止の下でもハードブリーチの下でも開放されたままである。負債を閉じることは帳簿をより安全にするだけだからである。負債がステークの 95 % に達したポジションは誰でも閉じることができ、閉じた者は E39 の余剰を受け取る。  ### §25.3 報酬の会計 **エミッション。** $T$ = `TOTAL_REWARDS`、$P$ = `HALVING_PERIOD`、$R_{0}$ = `INITIAL_REWARD_PER_SEC`、$s$ = `emissionStart` とし、時刻 $t$ に対して $\tau = t - s$、$p = \lfloor \tau / P \rfloor$ とする。累積予定エミッションは閉形式である（`_emittedAt`、L1458–1467）： $$ E(t) \;=\; \begin{cases} 0 & t \le s \\ \left(T - (T \gg p)\right) \;+\; (R_{0} \gg p)\,(\tau - pP) & s < t < s + 8P \\ T - (T \gg 8) & t \ge s + 8P \end{cases} $$ ^e27 *導出。* 厳密な算術では期間 $q$ のレートは $T/(2^{q+1}P)$ であるから、完全な期間 $q$ は $T/2^{q+1}$ を発行し、期間 $p$ より前のエミッションは $\sum_{q 0 \end{cases} $$ ^e30 ここで $s_{u}$ はポジションのステーク、$d_{u}$ はその負債である。厳密値：$b(90) = 10{,}199$、$b(365) = 11{,}000$、$b(730) = 12{,}500$、$b(1{,}825) = 20{,}000$、$b(2{,}555) = 27{,}500$ bps。エミッション重みは正味ステークに対するものである。純粋利回りの重みは負債のないポジションにのみ存在する — 借り手は自らが支払う利息を稼がない。 ### §25.4 利息：曲線とインデックス **曲線。** 利用率は $U = \min(\lfloor D \cdot 10^{18} / S \rfloor, 10^{18})$ であり、$D$ = `totalDebt`、$S$ = `totalStaked` である（$S = 0 < D$ ならば $U = 10^{18}$；両方がゼロならば基本レート）。年率 bps は 80 % でキンクを持つ（`_interestRate`、L1768–1782）： $$ r(U) \;=\; \begin{cases} 100 + \left\lfloor 500\,U / 10^{18} \right\rfloor & U \le 0.8 \cdot 10^{18} \\ 500 + \left\lfloor 72{,}500\,(U - 0.8\cdot 10^{18}) / 10^{18} \right\rfloor & U > 0.8 \cdot 10^{18} \end{cases} $$ ^e31 二つの分岐はキンクで接続する — $100 + 0.8 \times 500 = 500$ — そして曲線は完全利用時に $500 + 0.2 \times 72{,}500 = 15{,}000$ bps に達する。借入は帳簿を 75 % より上に引き上げることができないため（E41）、いかなる借入もそれ単独で急勾配の分岐に入ることはない。 **インデックス。** 経過した各スライス $\Delta t$ には、$D$ または $S$ へのいかなる書き込みよりも前に、その区間で有効なレートが刻印される（`_interestSlice`、L1589–1619；`_updateInterestIndex`、L1539–1583）。ここで $Y$ = 365 日である： $$ \delta \;=\; \left\lfloor \frac{\lfloor 10^{18}\, r(U) / 10^{4} \rfloor \cdot \Delta t}{Y} \right\rfloor, \qquad \sigma \;=\; \left\lfloor \frac{D\,\delta}{10^{18}} \right\rfloor, \qquad I \leftarrow I + \delta, \quad S \leftarrow S - \sigma $$ ^e32 $\sigma$ が $S$ を超える場合、インデックスの前進は $\delta = \lfloor S \cdot 10^{18}/D \rfloor$ として再導出され、$\sigma$ はそこから再計算される。したがってポジションごとの課金の総和がグローバルな借方を超えることは決してない。算術はリバートせずゼロに飽和するため、その下で動くエントリポイントが凍結することはなく、緊急時には時計は課金なしに滑る（L1547）。一つの関数が実行とあらゆる見積もりのためにスライスを計算するため、両者が異なる丸めを行うことはありえない。 **分割。** スライスはステークを離れ、同じステップで分割される（L1560–1580；`_dampPure`、L1623–1625）。ここで $W_{\mathrm{p}}$ = `totalBoostedPure`、$A^{\mathrm{p}}$ = `accPureYieldPerShare` である： $$ \kappa_{r} = \left\lfloor \frac{300\,\sigma}{10^{4}} \right\rfloor, \quad \pi = \sigma - \kappa_{r}, \quad \eta = \left\lfloor \frac{\pi \cdot \min(W_{\mathrm{p}}, W_{\min})}{W_{\min}} \right\rfloor, \quad A^{\mathrm{p}} \leftarrow A^{\mathrm{p}} + \left\lfloor \frac{\eta \cdot 10^{18}}{W_{\mathrm{p}}} \right\rfloor, \quad \mathtt{protocolReserve} \mathrel{+}= \kappa_{r} + (\pi - \eta) $$ ^e33 したがって $\sigma = \kappa_{r} + \eta + (\pi - \eta)$ が厳密に成り立つ。純粋重みがなければ、$\pi$ のすべてが準備金に行く。スロットルはエミッションのもの（E28）と同じであり、同じ定数を用いる。 **帰属。** グローバル側は利息が発生した時点で決済されている。ポジション自身の分担は、それが次に触れられた時に帰属される（`_accrueInterestFor`、L1627–1671）。ここで $I_{u}$ はそのインデックスのチェックポイントである： $$ i_{u} \;=\; \left\lfloor \frac{d_{u}\,(I - I_{u})}{10^{18}} \right\rfloor; \qquad i_{u} > s_{u} \;\Rightarrow\; \lambda = i_{u} - s_{u} \ \text{enters E37},\ S \mathrel{+}= \lambda,\ i_{u} \leftarrow s_{u}; \qquad s_{u} \leftarrow s_{u} - i_{u}, \quad I_{u} \leftarrow I $$ ^e34 利息はステークから支払われる。負債そのものは増加しない。負債のないポジションは再チェックポイントするだけであるため、何も負っていなかった時期のインデックス増加を引き継ぐことは決してない。ポジションが支払えない利息も、それでもなお E33 によって分配されている。それを $S$ に加え戻すことで $S = \sum_{u} s_{u}$ が保たれ、損失はそれが判明した時点で E37 によって計上される。 ### §25.5 準備金、支払能力、損失ウォーターフォール **保存。** $B$ をコントラクトの BZPX 残高、$D$ = `totalDebt`、$\mathit{BD}$ = `totalBadDebt`、$S$ = `totalStaked`、$\mathit{RR}$ = `rewardReserve`、$\mathit{PR}$ = `protocolReserve`、$\Pi$ = `totalRewardDistributed − totalRewardsPaid`（分配済みで未払い）とすると、`conserves` 修飾子を付けたすべての関数は、本体の前に両辺のスナップショットを取り、本体の後で次が成り立たない限りリバートする（L419–438；`_conservationSnapshot`、`_conservationCheck`、L449–457）： $$ \left|\, \Delta(B + D + \mathit{BD}) \;-\; \Delta(S + \mathit{RR} + \mathit{PR} + \Pi) \,\right| \;\le\; \varepsilon, \qquad \varepsilon = \mathtt{CONSERVATION\_DUST} = 10^{10}\ \text{wei} $$ ^e35 すべての項は単一の非負の状態変数であり、フロアなしに合計されるため、恒等式はあらゆるレジームで線形である — 回復ツール（`repay`、`liquidate`、`absorbBadDebt`）が動作し続けなければならない終末的な窮境も含めて — そして比較されるのは呼び出しをまたぐ変化だけであるため、履歴が蓄積して誤警報になることはない。 **支払能力。** コントラクトが負っているもの、およびそれを保有しているかどうかの公開テスト（`_owed`、L1794–1798；`_hardBreach`、L1808–1810；`isSolvent`、L1824）： $$ \mathrm{owed} \;=\; (S + \mathit{RR} + \mathit{PR} - D)^{+} \;+\; \Pi, \qquad \mathrm{hardBreach} \iff B + \varepsilon < \mathrm{owed}, \qquad \mathtt{isSolvent}() = \neg\,\mathrm{hardBreach} $$ ^e36 *不良債権との関係の導出。* $S + \mathit{RR} + \mathit{PR} \ge D$ である場合、E35 は保護されたすべての呼び出しをまたいで $\Delta(B - \mathrm{owed} + \mathit{BD}) = 0$（$\varepsilon$ の範囲内で）を与えるため、$B - \mathrm{owed} = c - \mathit{BD}$ となる。ここで $c$ は台帳を超えて保有される残高である。したがって記録された不良債権は、帳簿をハードブリーチへと押しやるまさにその項であり、$\mathit{BD} > c + \varepsilon$ となった時点で帳簿は支払不能と読まれる。ハードブリーチの下では、額面で支払う扉、あるいは不足した資金プールに新たな資金を加える扉はリバートする — `deposit`、`borrow`、`withdraw`、`claimRewards`、`claimPureYield` およびそれらの内部の純粋利回り決済、`withdrawReserve`、`cancelEmergency`（L760, L826, L902, L932, L948, L1510, L539, L620）— 一方で `repay`、`liquidate`、`absorbBadDebt` は開放されたままであり、誰でも `tripBreaker` を呼び出してコントラクトを緊急状態に移行させることができる（L597）。 **ウォーターフォール。** 損失 $\lambda$ が生じるのは三つの箇所のみである。負債がステークを超える清算（L1101–1106, L1128）、債務超過状態での緊急退出（L704–709）、そしてポジションが支払えない利息（L1657–1663）である。三つすべてが同じ順序を適用する： $$ \kappa \;=\; \min(\lambda,\ \mathit{PR}), \qquad \mathit{PR} \leftarrow \mathit{PR} - \kappa, \qquad \mathit{BD} \leftarrow \mathit{BD} + (\lambda - \kappa) $$ ^e37 準備金 — すべての利息スライスの準備金係数（E33）と自己清算のボーナスから積み上がる — が最初に吸収する。カバーされない残りだけが記録された不良債権となる。資本再構成は公開の扉であり、まず準備金を充て、次に呼び出し元が差し出す額を上限として、なおカバーされていない額を決して超えずに取り込む（`absorbBadDebt`、L639–649）。ここで $a$ は呼び出し元の金額である： $$ \rho \;=\; \min(\mathit{BD},\ \mathit{PR}), \qquad \gamma \;=\; \min(a,\ \mathit{BD} - \rho), \qquad \mathit{PR} \leftarrow \mathit{PR} - \rho, \qquad \mathit{BD} \leftarrow \mathit{BD} - \rho - \gamma, \qquad B \leftarrow B + \gamma $$ ^e38 $\rho + \gamma = 0$ のときはリバートし、何も外へ動かさず、呼び出し元には何も支払わない。E35 は構成上成り立つ（$\Delta \mathrm{LHS} = \gamma - \rho - \gamma = -\rho = \Delta \mathrm{RHS}$）。$\mathit{BD}$ がダストの範囲内に戻れば、`isSolvent()` は true を返し、管理者は緊急状態を解除できる。 **清算。** ポジションが清算可能であるのは、$d_{u} > 0$ かつ（$s_{u} = 0$ または $100\,d_{u} \ge 95\,s_{u}$）である場合、かつその場合に限る（`_isLiquidatable`、L1133–1137）。その清算（`_executeLiquidation`、L1079–1131）： $$ \mathrm{seized} \;=\; \min\!\left(d_{u} + \left\lfloor \frac{500\,d_{u}}{10^{4}} \right\rfloor,\ s_{u}\right), \qquad \mathrm{bonus} \;=\; (\mathrm{seized} - d_{u})^{+}, \qquad \lambda \;=\; (d_{u} - s_{u})^{+} \ \text{to E37} $$ ^e39 ボーナスは呼び出し元に渡る。ただし借り手が自らのポジションを閉じる場合は例外で、その場合ボーナスは `protocolReserve` に留まる。ポジションの獲得済みストリームは閉じられる前に支払われ、残ったステークは、ロックを保持したまま負債のないポジションとして残る。 **緊急退出。** $\mathrm{pot} = B$、および追跡値としての $E_{+}$ = `totalPositiveEquity` $= \sum_{u} \max(s_{u} - d_{u}, 0)$ のもとで、退出は次を支払う（`emergencyWithdraw`、L658–725；スケーリング、L689–696）： $$ x_{0} \;=\; (s_{u} - d_{u})^{+}, \qquad E' \;=\; E_{+} - e_{u} + x_{0}, \qquad x \;=\; \min\!\left( \begin{cases} \lfloor x_{0}\,\mathrm{pot} / E' \rfloor & \mathrm{pot} < E' \\ x_{0} & \text{otherwise} \end{cases},\ \mathrm{pot} \right) $$ ^e40 ここで $e_{u}$ は退出者の追跡項であり、発生計上後にはその厳密なエクイティに置き換えられる。支払能力のある帳簿ではスケーリングは決して作動せず、正味エクイティが全額支払われる。不足している帳簿では各退出がその請求権の同じ割合を受け取り、債務超過状態の退出はその不足分を E37 を通じて計上する（L704–709）。  **借入上限。** 額 $a$ の借入は両方を満たさなければならない（`borrow`、L834–840；`_ltvCap`、L1908–1909）： $$ d_{u} + a \;\le\; \left\lfloor \frac{50\,(s_{u} - d_{u})^{+}}{100} \right\rfloor, \qquad \left\lfloor \frac{(D + a)\cdot 10^{18}}{S} \right\rfloor \;\le\; 0.75 \cdot 10^{18} $$ ^e41 第一はポジションの正味ステークに対するもの、第二は帳簿全体に対するものであり、後者は E31 の 80 % のキンクより下に保たれる。 **メンテナンス。** 各ユーザートランザクションは、コントラクトが一時停止中または緊急状態でない限り、借り手レジストリのウィンドウ（債務超過のものを清算する）とロックレジストリのウィンドウ（期限切れのロックを正規化する）も走査する。それぞれのサイズは次のとおりである（`_windowBudget`、L1148–1157；`_autoMaintain`、L1170–1178）： $$ c(n) \;=\; \min\!\left(1 + \left\lfloor \frac{n}{50} \right\rfloor + \left\lfloor \frac{t - t_{m}}{15\ \mathrm{min}} \right\rfloor,\ 10,\ n\right) $$ ^e42 ここで $n$ はレジストリのサイズ、$t_{m}$ は最後のスイープである。一回のトランザクションあたり最大四回のロック正規化が実行される（L263）。このスケジュールはオンチェーン状態の純粋関数であり — キーパーもガバナンスもない — そのガスはあらゆる場合に有界である。 **不変条件。** 本設計は九つの不変条件 INV-23 から INV-31 を追加する（付録 B）：保存恒等式、エミッション上限、損失の順序、ブリーチ下で閉じられる扉、資本再構成の上限、重みの単一の書き込み手、借入上限、有界な緊急退出、そして預け入れの経過ルールである。 ### §25.6 V4 における堅牢化 三つのマージされた変更が、Base 上にデプロイされている設計の後に V4 のソースを形作った。それぞれを、それが生み出した設計の水準でここに記述する。 - **#22（`b44e238`、2026-10-11）。** 利息は、実行とあらゆる見積もりで共有される一つの関数によってスライスごとに刻印される（E32）。したがってプレビューとトランザクションは、スライス全体で有効なレートで同じ課金を計算する。純粋利回りのチャネルはエミッションと同じ重みフロアによってスロットルされる（E33）。したがって残余の分母がフローを捕捉することはできない。自らのポジションを閉じる借り手は清算ボーナスを受け取らない。読み取り専用のリスクビューが追加された（`healthFactor`、`daysToLiquidation`、`maxBorrowOf`）。 - **#26（`7fc0c2a`、2026-10-13）。** 三つの損失箇所すべてに対する一つの損失順序：まず準備金、次に記録された不良債権（E37）；公開の資本再構成の扉（E38）；ハードブリーチ下で閉じられる、価値を動かす扉（E36）；コードを持たないトークンアドレスを拒否するコンストラクタ；保存検査を、保護されたすべての箇所にインライン化する代わりに二つの内部ヘルパーとして一度だけ出力すること（恒等式は不変）；そして保証テストスイート。 - **#25（`cc614f9`、2026-10-14）。** ドキュメントのみ：ガイドとテストヘッダー内の短い要約行。コントラクトのソースは変更されていない。 ### §25.7 テストの証拠 `cc614f9` 時点の `origin/main` において、実行からではなくソースツリーから数えた：37 個の `*.t.sol` ファイル（`git ls-tree -r --name-only origin/main | grep -c '\.t\.sol$'`）が、256 個の `test*` 関数と 14 個の `invariant*` 関数を宣言している（`git grep -E '^\s*function (test|invariant)' origin/main -- '*.t.sol'`、接頭辞で分割）。リポジトリの README（84 行目）は、それらと並んで九つのスイートからなる Node ハーネスを記述している。これらは宣言されているものの件数である。本論文はステーキングスイートの合格率を報告しない。 --- ## 改訂履歴 ### バージョン 2.3.0 (2026-10-14) 2.3.0 — ステーキング V4 設計の章（§25）を追加し、式 E27–E42、不変条件 INV-23–INV-31、図 FIG-19–FIG-21 を伴う。これは、ステーキングエンジンはもはや本論文では記述されないとする下記の記述に取って代わる。それ以外で変更されるのは、バージョン表記、列挙の範囲、付録の導入文、DOI の行のみであり、残りは 2.3 の本文である。 ### バージョン 2.3 (2026-09-24) バージョン 2.3 は 2.2 の系統を継ぐ。この文書の草稿に一時的に用いられた 3.0 という番号は撤回される。それに先立つ 2026-09-01 の 3.0 という番号も同様である。2.2 からの変更点は次のとおりである。十八のイノベーションに名称を与え、I-1 から I-18 まで番号を振り、その数学とともに論文の冒頭で述べ、計測された実績のスコアボードを添えた。すべての図を `8916545` 時点の `main` に対して再計測した。ステーキングエンジンはここではもはや記述されない（それ自身の仕様が担う）。トークンの節は、単一の Airdrop & Bounties プール 130,000,000 BZPX を記録する。そして、下記の 2.2 の正誤は、それが訂正した本文に組み込まれた。 ### 2.2 への正誤表 (2026-09-07) 2026-09-06 の本文を `main 8949a9d` に照らして敵対的に読んだ後に適用された。バージョン表記は 2.2 のままである。各項目は、本文が何と述べていたか、そしてチェックアウトが何を示しているかを記す。 1. §4.2 — 境界クランプ `sqrtBoundary` は Core に定義されているが、ランキングにもフレーム内の約束にもまだ配線されていない。本文はそれが約束の側に適用されていると述べていた。未解決項目：これを配線すること（`Router._v4LegQuote`、Core のランキング側）。V4 レッグがレンジを離れるとき、E21 のバッファを超えて正味見積もりを下回って引き渡されることを示す、赤から始めるテストを伴う。 2. §10.4 — 容量クランプは V4 レッグを除外する（Solver は種別 4 と 8 の残高読み取りを省略する）。本文はすべての集中型レッグがクランプされると述べていた。未解決項目：シングルトンに対する物理的な上限。 3. §5.4 — 静的手数料の V4 キーはマネージャーのプロトコル手数料を無視する（現在サービスしているすべてのチェーンでゼロ）。本文はキーの手数料が曖昧でないと述べていた。 4. §9.3 — 退去マージンは 3 % ではなく約 25 %（既存 51、新規 64）まで下がる。以前の数値は E13 に違反しており、ソースコードのコメントから写されたものであった。 5. §15 と概要 — `invariant_*` 関数は 43（印字されたコマンドは 43 を返す）、`.t.sol` ファイルは 217。 6. §14.1 — `HubE(6)` は存在しない。ファクトリの枯渇は `HubE(4)`、スロットの枯渇は `_canInsert` である。 7. §14.2 — 「どの一層でも十分である」は撤回する。各層はデルタの改変を抑える。§5.4 の手数料オーバーライドの残余はフロアによって抑えられる。 8. §11.4、INV-21 — 経路形状の規則は、「フック付きは最後のホップのみ」ではなく、経路全体での正準順序（`sawHooked`）である。 9. §11.3、E24 — 集計ホップフロアの余裕は BPS で割られる。すなわち、証明されたレッグ平均の 20 %。 10. §17.3 と付録 C — `FactoryCensus` ハーネスは非公開のデプロイ用ツリーにある。この表は報告されたものであり、このチェックアウトからは再現できない。 11. §17.5 — ガスの基準が明示された（KyberSwap `MetaAggregationRouterV2`、Base フォーク、2026-08-22、第二の比較対象として Paraswap）。トランザクションごとの比（2.7×）がレッグごとの比の隣に印字された。ハーネスと取得済み calldata は非公開であるため、数値は報告されたものであり、このチェックアウトからは再現できない。 12. §17.2 — 「チェーン初の V4 経由のアグリゲーション」は撤回する。「正確」は計測された帯（0–1 bps）に置き換えた。 13. INV-8、INV-10、INV-15、INV-20、INV-22 — 施行の引用を、それを担うテストとコードに訂正した。INV-22 は四つのデプロイ済みコントラクトを名指しする。 14. §1 — アグリゲーターの調査は、2026-09-07 に文書化されたとおり、名指しされた七つに限定される。 15. 参考文献 16 と 20 — EIP-1153 は A. Akhunov と M. Salem による。EIP-7702 は V. Buterin、S. Wilson、A. Dietrichs、M. Garnett による。 16. §2.3、§15.11、§21 — 計器の較正と欠陥パターンの数は、較正の規則そのものに置き換えた。 - §14.2、第 2 層（2026-09-07、フックの受け入れ）：許可リストは自動の扉を管理し、コードハッシュのピン留めは、コードが移動した、リストされたフックを、あらゆる扉で停止させる。アドレスビットにスワップ権限を持たないフックはスワップで決して実行されず、リストもピン留めも必要としない。スワップで実行され、誰もリストしなかったフックは、呼び出し側の署名された選択として明示的な扉で受け入れられ、あらゆる会場と同様に、フレーム内の約束、証明ゲート、`userMinOut` によって抑えられる。自動の扉がそれを提案することは決してない。フック付きプールの登録はそのフックを受け入れてピン留めするため、フック付きプールは運用者の一手順で済む。三つの層は維持される。「デフォルトで閉じている」は自動の扉を指す。 ### 2.2 への正誤表 (2026-09-24) 第九回バウンティウェーブの後に適用された。バージョン表記は 2.2 のままである。 1. §4.2、および 2026-09-07 の正誤表の項目 1 — 解消。V4 プールは自身の板を歩くことで見積もられる。その価格、流動性、ティックビットマップ、ティックを `extsload` を通じて読み、PoolManager 自身のステップ演算を用いる。ランキングにも約束にも同じである（`Core.v4WalkOut`）。境界クランプ `sqrtBoundary` は廃止された。ディスパッチャがティック横断の演算を複製しないという記述は、今や V3 系統にのみ当てはまる。 2. §10.4、および 2026-09-07 の正誤表の項目 2 — それが果たした目的については解消。ウォークは、板が横断するティックに保持している流動性だけを数えるため、V4 レッグは自身のプールが保持するものによって抑えられる（`test_AOneTickRangeWithNothingBeyondPaysWhatItHolds`）。 3. 2026-09-07 の正誤表の項目 3 — 解消：静的手数料のキーは、マネージャーのプロトコル手数料をキーの LP 手数料にスワップの方向で合成する（`Core.effV4Fee`；`test_StaticKey_ProtocolFee_ReachesThePromise`）。 4. §4 — 見積もり経路がプールに対して行うすべての読み取りはガス上限が付され、固定数のワードをコピーする。高水準呼び出しであった二つ（Solidly ペアの `getAmountOut`、および `factory()` に続く `getFee`）は `Core._askWord` を通じて問い合わせる（`test/APoolsAnswerIsBoundedByTheReader.t.sol`）。 ## 付録 A · 基本方程式 本論文のあらゆる定量的主張は、次のいずれかに帰着する。それぞれは、名指しされたコントラクトに一度だけ実装され、他のすべての場所でインポートされる。E1–E22 の番号は前版から安定しており、E23–E26 は新規で末尾に追加された。E27–E42（2.3.0）はステーキングエンジンのものであり、ステーキングリポジトリの `cc614f9` における `src/BlazePhoenixStaking.sol` に定義される（§25）。第四列の「Staking」はそのコントラクトを指し、行番号を伴う。 | # | 名称 | 式 | 定義箇所 | § | |---|---|---|---|---| | E1 | メタ方程式 | $R^{\star} = \arg\max_{R}\ \mathrm{net}(R)\cdot\prod_{\ell}\hat{\Psi}(p_{\ell})\cdot\mathbf{1}[\mathrm{net}(R)\ge\Phi(R)]\cdot\Xi(R)$ | Solver パイプライン | §3 | | E2 | 定積出力 | $y = \lfloor x(\mathrm{BPS}-f)\,r_{\mathrm{out}} / (r_{\mathrm{in}}\,\mathrm{BPS} + x(\mathrm{BPS}-f)) \rfloor$ | Core `outV2` | §4.2 | | E3 | 集中流動性の出力（ティック内） | $\sqrt{P}' = L\sqrt{P}/(L + x_{f}\sqrt{P}/Q_{96})$, $y = L(\sqrt{P}-\sqrt{P}')/Q_{96}$；逆方向には双対形 | Core `outV3` | §4.2 | | E4 | V4 ストレージの基底スロット | $\mathrm{slot} = \mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6))$; $\sqrt{P}$ はビット [0,160)、LP 手数料はワード 0 の [208,232)；$L$ はワード 3 | Core `v4SqrtAndLiq` | §5 | | E5 | Solidly stable 不変条件 | $k(x,y) = x^{3}y + xy^{3}$ | Core `_solK` | §6 | | E6 | Solidly ニュートン・ステップ | シード $y_{0} = Y$；上方ステップ $\max(1, \lfloor (K-k)/f' \rfloor)$；下方ステップ $\max(1, \lfloor (k-K)/f' \rfloor)$、$\lfloor y/2 \rfloor$ に置換（ゼロを跨ぐ場合）；終了条件 $\lvert y_{n+1}-y_{n}\rvert \le 1$、テイカーに不利な方向へ一単位の補正；上限 64 → シード → 見積もり 0 | Core `_solY` | §6 | | E7 | 小数桁の正規化 | $X = r_{\mathrm{in}}10^{18-d_{\mathrm{in}}}$, $Y = r_{\mathrm{out}}10^{18-d_{\mathrm{out}}}$、求解後にスケールを戻す | Core `_solidlyStable` | §6 | | E8 | CREATE2 導出 | $\mathrm{pool} = \mathrm{addr}_{20}(\mathrm{keccak256}(\mathtt{0xff} \Vert \mathrm{origin} \Vert \mathrm{salt} \Vert \mathrm{initCodeHash}))$ | Core `create2Address`, `deriveAddress` | §7 | | E9 | モノスロットのパッキング | $s = a \,\vert\, f\!\ll\!8 \,\vert\, k\!\ll\!32 \,\vert\, r\!\ll\!40 \,\vert\, (c\wedge\mathtt{0xFFF})\!\ll\!48 \,\vert\, b\!\ll\!60 \,\vert\, \dots \,\vert\, B_{\mathrm{last}}\!\ll\!224$ | Core `encodeSlot` | §8 | | E10 | 活力場 | $\Psi = V \cdot 2^{b} \cdot (1 + 0.25\,\mathbf{1}_{\mathrm{bridge}}) \cdot (1 + 0.05\,\mathbf{1}_{\mathrm{conc}})$ | Core `psi` | §9.2 | | E11 | 活動の減衰 | $V = \mathrm{swapCount} \gg \lfloor (t - t_{\mathrm{last}})/24{,}576 \rfloor$；シフトが 31 を超えると 0 | Core `_decayedSwapCount` | §9.2 | | E12 | 深さバケット | $b = \min(15, \lfloor \log_{10}(d/10^{15}) \rfloor)$ | Core `depthBucket` | §9.2 | | E13 | 退去のハードル | $2^{b(d_{\mathrm{new}})} > \Psi_{\mathrm{worst}} + \lfloor \Psi_{\mathrm{worst}}/4 \rfloor$ | Hub `_canInsert` | §9.3 | | E14 | 分割ゲート | 分割を維持するのは次の場合に限る：$\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}}\cdot(1 + 25/10^{6})$、$\mathrm{out}_{\mathrm{single}}$ は全量における最も深い候補と最良レートの候補のうち良い方 | Solver `_buildHop` | §10.4 | | E15 | Iron-Law フロア | $\mathtt{floorBps} = \max(9{,}600 - \mathtt{legShv} - \min(\delta, 10^{4}) - \sigma_{\ln}/10^{14},\ 8{,}000)$ | Core `ironFloorBpsShv` | §11.5 | | E16 | 実効最小値 | $\mathtt{effMin} = \max(\mathtt{userMinOut},\ \mathtt{route.singleOutFloor},\ \lceil \mathtt{finalHopQuote}\cdot\mathtt{floorBps}/10^{4}\rceil)$；fee-on-transfer が検出された場合、第二項は除かれ、第三項は計測された正味比率で再スケールされる | Router `_execute` | §11.5 | | E17 | プロトコル手数料 | $\mathrm{fee} = \lceil 28 \cdot \mathrm{base} / 10^{4} \rceil$, base = 手数料ホップの計測された入力（アンカー型）、総出力（ブリッジコインへの直接経路）、または各ホップの計測された入力（網羅型）； $t_{1} = \lfloor 3{,}000\cdot\mathrm{fee}/10^{4} \rfloor$, $t_{2} = \mathrm{fee} - t_{1}$ | Router `_chargeHopFee`, `_payFee` | §13 | | E18 | フックゲート | $(\mathrm{uint160}(\mathrm{hook}) \,\&\, \mathtt{0x3FFF}) \,\&\, ((1\ll 3)\mid(1\ll 2)) \ne 0 \Rightarrow$ レッグは拒否され、呼び出しは行われない | Core `hookAltersDeltas`; Router | §14.2 | | E19 | 動的手数料ゲート | $f_{\mathrm{eff}} = f_{\mathrm{key}}$ 静的な場合；センチネルがゼロでないプロトコル手数料を伴うときは見積もり不能；それ以外は `slot0` / `globalState` / プールの `fee()` から得た現行の LP 手数料 | Core `effV4Fee`, `quoteV3Fee` | §5.4 | | E20 | V2 手数料の上限 | $f_{\mathrm{eff}} = f_{\mathrm{decl}}$、ただし $0 < f_{\mathrm{decl}} \le 100$ bps の場合、それ以外は 30 | Core `effV2Fee`; Solidly の宣言されたフォールバックにも同じ規則 | §4.2 | | E21 | プレビュー安全バッファ | $s = \min(\max(0, n-2) + 5a,\ 10)$ bps | Quoter `_pack` | §12.1 | | E22 | サーフェスの選択 | 経路を calldata で運ぶのは次の場合に限る：$p_{\mathrm{byte}} < \rho^{*}$；$\rho^{*}$ は経路の形状ごとに 66.9–105.5 gas/byte と計測された | `test/EquationBench.t.sol` | §17.6 | | E23 | 集中によるレッグのシェーブ | $\mathtt{legShv} = \sum_{\mathrm{hops}} \lfloor 200\,((\sum a)^{2} - \sum a^{2})/\sum a^{2} \rfloor$ | Core `legShaveBps` | §11.5 | | E24 | 集計ホップフロア | $\sum \mathrm{got} + \lfloor (\mathrm{BPS} - 8{,}000)\cdot \lfloor \sum \mathrm{attested}/n \rfloor / \mathrm{BPS} \rfloor \ge \sum \mathrm{attested}$ | Router `_execute` | §11.3 | | E25 | 信頼性の中心 | 深さ加重中央値：$(r_{i}, d_{i})$ を $r_{i}$ で整列し、次を満たす最初の $r_{i}$ を返す：$\sum_{j \le i} d_{j} \ge \lceil \sum d / 2 \rceil$；帯 $[0.95, 1.05] \times$ 中心 | Solver `_depthWeightedMedian` | §10.3 | | E26 | 手数料レジーム述語 | $\mathrm{feeHop} = \min\{h : \mathrm{isBridge}(\mathrm{hops}[h].\mathrm{tokenIn})\}$；$h$ で課金するのは次の場合に限る：$\neg\mathrm{feeOnOut} \wedge (\mathrm{feeHop} = \infty \vee h = \mathrm{feeHop})$; $\mathrm{feeOnOut} \iff$ ホップが一つであり、かつ $\mathrm{isBridge}(\mathrm{tokenOut})$ | Router `_execute` | §13.1 | | E27 | エミッションの閉形式 | $E(t) = (T - (T \gg p)) + (R_{0} \gg p)(t - s - pP)$, $p = \lfloor (t - s)/P \rfloor$；$0$（$s$ まで）；$T - (T \gg 8)$（$s + 8P$ 以降） | Staking `_emittedAt` (L1458–1467) | §25.3 | | E28 | エミッション窓 | $r = \min(\lfloor (E(t') - E(t_{\ell}))\min(W, W_{\min})/W_{\min} \rfloor,\ \mathit{RR})$; $A \mathrel{+}= \lfloor r \cdot 10^{18}/W \rfloor$ | Staking `_updateGlobal` (L1428–1448) | §25.3 | | E29 | 決済 | $\mathrm{due}_{u} = (\lfloor w_{u}A/10^{18} \rfloor - c_{u})^{+}$ 、続いて $c_{u} \leftarrow \lfloor w_{u}A/10^{18} \rfloor$ | Staking `_settlePendingRewards`, `_settlePendingPureYield` (L1487–1517) | §25.3 | | E30 | ロックブーストと重み | $b(\ell) = 10^{4} + \lfloor 750\ell/365 \rfloor + \lfloor 250\ell^{2}/365^{2} \rfloor$ bps, $\ell$ は有効なロック； $w_{u} = \lfloor (s_{u} - d_{u})^{+} b/10^{4} \rfloor$; $w^{\mathrm{p}}_{u} = \lfloor s_{u} b/10^{4} \rfloor$ $d_{u} = 0$ の場合に限る | Staking `boostByDays`, `_computeBoost` (L496–505, L1695–1700) | §25.3 | | E31 | 利息曲線 | $r = 100 + \lfloor 500U/10^{18} \rfloor$、ただし $U \le 0.8 \cdot 10^{18}$ の場合、それ以外は $500 + \lfloor 72{,}500(U - 0.8 \cdot 10^{18})/10^{18} \rfloor$ bps／年 | Staking `_interestRate` (L1768–1782) | §25.4 | | E32 | 利息インデックスとスライス | $\delta = \lfloor \lfloor 10^{18} r/10^{4} \rfloor \Delta t / Y \rfloor$, $\sigma = \lfloor D\delta/10^{18} \rfloor$；$\sigma > S$ の場合、$\delta = \lfloor S \cdot 10^{18}/D \rfloor$ とし、$\sigma$ を再計算する | Staking `_interestSlice`, `_updateInterestIndex` (L1539–1619) | §25.4 | | E33 | スライスの分割 | $\kappa_{r} = \lfloor 300\sigma/10^{4} \rfloor$ は準備金へ；$\eta = \lfloor (\sigma - \kappa_{r})\min(W_{\mathrm{p}}, W_{\min})/W_{\min} \rfloor$ は純粋ステーカーへ；残りは準備金へ | Staking `_updateInterestIndex`, `_dampPure` (L1560–1580, L1623–1625) | §25.4 | | E34 | 利息の帰属 | $i_{u} = \lfloor d_{u}(I - I_{u})/10^{18} \rfloor$, $s_{u}$ に課される；$s_{u}$ を超える分は E37 に回る損失となる | Staking `_accrueInterestFor` (L1627–1671) | §25.4 | | E35 | 保存ガード | $\lvert \Delta(B + D + \mathit{BD}) - \Delta(S + \mathit{RR} + \mathit{PR} + \Pi) \rvert \le 10^{10}$ | Staking `conserves` (L419–457) | §25.5 | | E36 | 未払額と支払能力 | $\mathrm{owed} = (S + \mathit{RR} + \mathit{PR} - D)^{+} + \Pi$; ハード違反となるのは次の場合に限る：$B + 10^{10} < \mathrm{owed}$ | Staking `_owed`, `_hardBreach`, `isSolvent` (L1794–1824) | §25.5 | | E37 | 損失ウォーターフォール | $\kappa = \min(\lambda, \mathit{PR})$; $\mathit{PR} \mathrel{-}= \kappa$; $\mathit{BD} \mathrel{+}= \lambda - \kappa$ | Staking L1101–1106, L704–709, L1657–1663 | §25.5 | | E38 | 資本再構成 | $\rho = \min(\mathit{BD}, \mathit{PR})$, $\gamma = \min(a, \mathit{BD} - \rho)$; $\mathit{BD} \mathrel{-}= \rho + \gamma$ | Staking `absorbBadDebt` (L639–649) | §25.5 | | E39 | 清算 | 清算可能となるのは次の場合に限る：$d_{u} > 0 \wedge (s_{u} = 0 \vee 100 d_{u} \ge 95 s_{u})$; $\mathrm{seized} = \min(d_{u} + \lfloor 500 d_{u}/10^{4} \rfloor, s_{u})$；損失 $(d_{u} - s_{u})^{+}$ | Staking `_executeLiquidation`, `_isLiquidatable` (L1079–1137) | §25.5 | | E40 | 緊急ヘアカット | $x_{0} = (s_{u} - d_{u})^{+}$, $E' = E_{+} - e_{u} + x_{0}$; $x = \lfloor x_{0}\,\mathrm{pot}/E' \rfloor$ 、ただし $\mathrm{pot} < E'$ の場合、それ以外は $x_{0}$; $x \le \mathrm{pot}$ | Staking `emergencyWithdraw` (L689–696) | §25.5 | | E41 | 借入の上限 | $d_{u} + a \le \lfloor 50(s_{u} - d_{u})^{+}/100 \rfloor$ かつ $\lfloor (D + a) 10^{18}/S \rfloor \le 0.75 \cdot 10^{18}$ | Staking `borrow`, `_ltvCap` (L834–840, L1908–1909) | §25.5 | | E42 | メンテナンス予算 | $c(n) = \min(1 + \lfloor n/50 \rfloor + \lfloor (t - t_{m})/900\ \mathrm{s} \rfloor,\ 10,\ n)$ レジストリごと | Staking `_windowBudget` (L1148–1157) | §25.5 | ## 付録 B · 不変条件 これらは到達可能なあらゆる状態で成り立つ性質である。それぞれは名指しされた箇所のコードの形によって施行され、それに違反するトランザクションは実行されない。INV-1–INV-18 は前版から番号を保ち、施行の列はコードに合わせて改められた。INV-19–INV-22 は新規である。INV-23–INV-31（2.3.0）はステーキングエンジン（§25）のものであり、ステーキングリポジトリの `cc614f9` における `src/BlazePhoenixStaking.sol` で施行される。 | # | 不変条件 | 施行 | |---|---|---| | INV-1 | Router はトランザクション間で資金を保持しない。静止時の残高はゼロである。 | ベースライン範囲のスイープと支払い（§11）；`invariant_RouterHoldsNothing`、`HoldsNothingBeyondTheSeed` | | INV-2 | すべてのスワップはアトミックである。取引の一部が決済された状態は存在しない。 | EVM のトランザクション意味論；単一のフレーム | | INV-3 | オラクルなし：外部の価格フィードは、受け入れ、順序付け、分割、フロア設定、手数料のいずれの入力でもない。 | 五つのコントラクトにフィード呼び出しは存在しない | | INV-4 | 手数料率、手数料の分割、フロア定数には、デプロイ済みバイトコードにセッターがない。 | Core と Router のコンパイル時定数（§13） | | INV-5 | 呼び出し側が供給する経路フィールドは保護を強めることはできても、緩めることはできない。 | E16 の三者最大値；カバレッジゲートは証明を引き上げるのみで、引き下げない（§11） | | INV-6 | 最小値がゼロのスワップは実行されない。 | あらゆる扉で `RouterE(10)` | | INV-7 | Ψ は候補を順位付けして切り詰める。見積もり、フロア、割り当てのいずれもそれを読まない。 | データフロー：ランキングより下流には Ψ を消費するものがない（§9.6） | | INV-8 | ペアのレジストリが保持するプールは最大でも十六であり、退去は E13 のマージンのもとで完全な Ψ により最も適合するものを残す。 | Hub `_canInsert`；`invariant_neverExceedsMaxSlots`（上限）；`test_RecordSwap_EvictsWeakestWhenFullAndNewcomerClearsMargin`（退去） | | INV-9 | ランタイムバイトコードを持たないアドレスは経路に入らない。 | あらゆる導出での `hasCode`（§7） | | INV-10 | 汎用コールバックは、現在のレッグのためにコミットされたプールにのみ、レッグが進行中の間のみ、そしてそのレッグの記録された予算を超えない範囲でのみ支払う。 | 一時的なレッグコンテキスト；プールには `RouterE(6)`、予算には `RouterE(8)`（§11.4） | | INV-11 | アドレスがデルタを改変する権限を宣言している V4 フックは、トークンが動く前に、呼び出されることなく拒否される。 | E18；`RouterE(9)`；Solver `_topKPools` | | INV-12 | いかなる価格計算の積もオーバーフローしない。危険な乗算はすべて 512 ビットの `mulDiv` を通して因数分解され、上限を定められない状態はゼロを見積もる。 | Core（§4.2、§6） | | INV-13 | 丸めは過剰な約束に逆らう方向に働く。見積もりと支払いは切り捨て、保護的なフロアと手数料は切り上げる。 | 各箇所の Core `mulDiv` / `mulDivUp` | | INV-14 | 上限を証明できない場合、計算はゼロを返し、会場は放棄される。推測はせず、見積もりの内部でスケジュール可能なリバートも起こさない。 | Core 全体にわたるフェイルクローズの姿勢；`_solKFits`（§6） | | INV-15 | 手数料の基準は、経路のコミット済み入力で上限が付された計測済みのプルである。宣言された出力ではない。`route.totalOut` は何にも読まれない。 | `_chargeHopFee`；`test_FeeBase_IgnoresLiedAboutTotalOut` | | INV-16 | 放棄は一方向である。フラグは一箇所で `true` に書かれ、`false` に書かれる箇所はない。その後に残るのは増加のみのキュレーター層だけであり、移動したファクトリやフックは再び武装させることができない。 | Hub と Router の `renounceControl`（§14.7） | | INV-17 | 宣言された定積または Solidly のフォールバック手数料は、100 bps の上限内でのみ信じられる。それを超える場合は、標準の 30 bps がそのプールの価格を決める。 | E20 | | INV-18 | Solver の計画では、どのホップも四つを超えるレッグを持たず、どの経路も十一を超えない。Router が受け入れるのは最大で三ホップ、ホップごとに五レッグである。 | Solver の予算；Router `_execute` → `RouterE(3)` | | INV-19 | プールがレジストリに入るのは、そのペアを取引することを自ら証明した場合に限る。ペア型の種別では `token0()`/`token1()`、V4 ではプール id の再導出による。問い合わせたプールは、ディスカバリが列挙する前に同じことを証明する。 | Hub `recordSwap`、`_probe`；`invariant_ActiveEntriesTradeThePair` | | INV-20 | 決済は、アンカー型の経路ではプロトコル手数料をちょうど一度、網羅型の経路ではホップごとに一度支払う。何も支払わなかった決済は存在しない。 | 手数料台帳、`RouterE(15)`/`RouterE(16)`；`invariant_SettledSwapEmitsExactlyOneFee`（アンカー型）；`test/FeeSeals.t.sol`、`test/ExhaustionRegimePreviewParity.t.sol`（網羅型） | | INV-21 | ホップは連鎖する。各ホップの入力は前のホップの出力であり、フックなしのレッグは、このホップまたは以降のいずれのホップでも、フック付きのレッグの後に実行されない（`sawHooked` は経路全体にわたる）。 | Router `_execute` → `RouterE(3)`；`sawHooked` | | INV-22 | 四つのデプロイ済みコントラクト、すなわち Hub、Solver、Router、Quoter は、リリースプロファイルでプロジェクトの 24,000 バイトのゲートの下で出荷され、Core ライブラリは別に計測され（24,576 のうち 6,477 バイト）、スイートはそのプロファイルで実行される。 | `DeployedSizeGate`；`profile_parity.py` | | INV-23 | `conserves` を身にまとうステーキングのすべてのエントリポイントで、残高と負債と記録済み不良債権の合計は、ステークと両方の準備金と分配済みだが未払いの報酬の合計と同じ量だけ変化する。誤差は 1e10 wei 以内（E35）。 | Staking `conserves`、L419–457 → `Staking__InvariantBreached` | | INV-24 | 予定されたエミッションは `TOTAL_REWARDS − (TOTAL_REWARDS >> 8)` を超えない。累積の資金供給は `TOTAL_REWARDS` を超えない。いかなるエミッション窓も `rewardReserve` の保持額を超えて支払わない。 | `_emittedAt` L1458–1467；`fundEmission` L518 → `Staking__CapExceeded`；`_updateGlobal` L1442 | | INV-25 | 実現したすべての損失、すなわち清算の不足額、水面下の緊急退出、回収不能な利息は、まず `protocolReserve` から引き当てられる。カバーされなかった残りだけが `totalBadDebt` に加えられる（E37）。 | Staking L1101–1106、L704–709、L1657–1663 | | INV-26 | 残高に 1e10 を加えた額が `owed` を下回る間は、入金、借入、引き出し、報酬または純粋利回りの請求、準備金の引き出し、緊急キャンセルのいずれも実行されない（E36）。 | `_hardBreach` のゲート L760、L826、L902、L932、L948、L1510、L539、L620 → `Staking__InvariantBreached` | | INV-27 | `absorbBadDebt` は BZPX を外へ動かさず、呼び出し側に何も支払わず、`totalBadDebt` をその現在値以下しか下げない。まず準備金、次に呼び出し側の額がカバーされなかった残りで頭打ちとなる（E38）。 | `absorbBadDebt` L639–649 | | INV-28 | エミッション重み、純粋利回り重み、正の純資産の合計は `_applyBoost` によってのみ書かれ、これはポジションの追跡項を再計算された項に置き換える。ロックがブーストを得るのは、有効である間に限られる（E30）。 | `_applyBoost` L1726–1734；`_effectiveLockDays` L1687–1690 | | INV-29 | 借入が実行されるのは、新しい負債がその前のポジションの正味ステークの半分以下であり、その後の帳簿の利用率が 75 % 以下である場合に限る（E41）。 | `borrow` L834 → `Staking__LTVExceeded`；L838–840 → `Staking__UtilTooHigh` | | INV-30 | 緊急退出が支払うのは、高々ポジションの正味資産、かつ高々コントラクトの残高であり、残高が追跡された資産に満たないときは pot/E′ でスケールされる（E40）。 | `emergencyWithdraw` L689–696 | | INV-31 | ポジションの最後の入金から `MIN_DEPOSIT_BLOCKS` = 10 ブロック以内には、引き出し、純粋利回りの請求、ロックの変更はいずれも実行されない。 | L894、L947、L971 → `Staking__FlashLoanProtection` | ## 付録 C · 再現コマンド 本論文のうちリポジトリに由来するすべての数値は、`Blaze-Phoenix-Dex` の `8949a9d` のクリーンなチェックアウトから、Foundry と Python 3 をインストールした状態で、以下のいずれかによって再現される。フォークスイートには `DRPC_KEY` にアーカイブ RPC キーが必要である。 ```bash forge test --no-match-path 'test/fork/**' # the suite, release settings (§15.1) forge test --match-path 'test/fork/**' # the fork lane, five chains (§15.1, §17) FOUNDRY_PROFILE=release forge build --sizes --skip test --skip script # sizes against EIP-170 (§16.3) python3 .github/scripts/mutants.py # the curated mutation guard, 268/268 (§15.2) python3 .github/scripts/check_targets.py # every mutant still points at one line python3 .github/scripts/assurance/covering_array.py --check # both covering arrays current (§15.4) forge test --match-contract RegimeCoverageTest -vv # strength 2, 63 rows forge test --match-contract RegimeCoverageT3Test -vv # strength 3, 168 rows forge test --match-path test/regime/HostileVenueMatrix.t.sol # ten pathologies × two doors (§15.5) forge test --match-path test/regime/SandwichCurve.t.sol -vv # the sandwich curve (§14.3) forge test --match-path test/regime/CanonicalOracles.t.sol # the quote maths against the specifications (§15.6) forge test --match-path 'test/*MetamorphicRelations.t.sol' # 14 + 5 relations (§15.7) FOUNDRY_PROFILE=nver1 forge build --skip '*.t.sol' && FOUNDRY_PROFILE=nver2 forge build --skip '*.t.sol' NVERSION_LANE=1 forge test --match-path 'test/nversion/*' # the three binaries agree (§15.8) forge test --match-test invariant_ --fuzz-seed 0xb1a2ef00 # the stateful campaigns (§15.3) forge test --match-path test/FeeSeals.t.sol # the fee rule, both regimes (§13.4) forge test --match-path test/QuoteDelayStatistics.t.sol -vv # how a quote ages, 240 samples (§12.2) forge test --match-path test/QuoterGasStatistics.t.sol -vv # what a quote costs (§12.3) forge test --match-path test/fork/QuoteDelayFork.t.sol -vv # live Base, 1,000 USDC → WETH (§12.2) forge test --match-path test/fork/FidelityMatrix.t.sol -vv # preview → delivery, four chains (§17.2) forge test --match-path test/fork/DiscoveryColdWarm.t.sol -vv # cold and warm solve (§17.4) forge test --match-path test/EquationBench.t.sol -vv # ρ* (§17.6) forge test --match-path 'test/fork/Deployed*.t.sol' # what V1 is, pinned by codehash (§19) python3 .github/scripts/assurance/projection_distance.py # 86 / 99 (§15.9) python3 .github/scripts/assurance/metrics.py # every assurance number, with its denominator bash .github/scripts/shared-quantities.sh # the register agrees with the tree ``` 計算例 4 のハッシュは、`abi.encode(currency0, currency1, fee, tickSpacing, hooks)` に対する任意の keccak-256 実装によって再現される。本論文の図は、純 Python の Keccak-f[1600] で作成され、空文字列と `"abc"` のテストベクトルに対して、また Core がハードコードしている `extsload(bytes32)` セレクタに対して検査された。 ## 用語集 **演算子。** | 記号 | 名称 | 一行説明 | |---|---|---| | Ω | 八重ディスパッチャ | すべてのレッグの価格を決める。閉形式が正確な場合は閉形式で、会場自身のバイトコードが唯一の誠実な情報源である場合は会場に問い合わせる。「八重」は歴史的な呼称であり、今日稼働している種別は六つ | | 𝒟 | 決定論的導出 | デプロイが再現可能な場合は CREATE2 演算でプールのアドレスを計算し、そうでない場合は問い合わせたうえでペアを証明し、V4 シングルトンについてはプール id を導出して証明する。`hasCode` はバイトコードのないものを捨てる | | Φ | Iron-Law フロア | プロトコル自身の保持フロア：基準は 96 %、計測された影響と計測された集中に応じて緩み、80 % で厳格にクランプされ、最終ホップのフレーム内見積もりに適用される | | Ψ | 活力場 | モノスロットのみから計算される会場の品質。候補集合を順位付けして切り詰める。会場を隠すことはあっても、誤って価格付けすることはない | | Ξ | 反詐欺射影子 | デルタを改変するフック、または受け入れられないフックに触れるあらゆる経路を、ランキングの前に、そのフックを呼び出すことなく、最大化から取り除く | **用語。** **アンカー型レジーム**（Anchored regime）— 手数料は、Router が保持する最初のブリッジコインに対して（またはブリッジコインへの直接経路の出力に対して）一度だけ課される。**信頼帯**（Believability band）— 候補の限界レートの深さ加重中央値の周囲 ±5 %。候補が一つの集合では作用しない。**カバレッジゲート**（Coverage gate）— 証明が計測された見積もりの半分に満たない範囲しかカバーしないとき、レッグの証明された上限をその計測された見積もりまで引き上げること。**Exact Pass** — Quoter のプール厳密なプレビュー：会場自身のスワップを実行し、リバート抽出によって巻き戻す。2026-09-03 以降は手数料控除後。**網羅型レジーム**（Exhaustion regime）— どのホップの入力にもブリッジコインがない：各ホップが自身の計測された入力に対して 28 bps を支払う。構造上、価値のない接頭辞に対して免疫がある。**手数料台帳**（Fee ledger）— 決済ごとの手数料支払いの一時的な計数。ゼロを拒否し、アンカー型の経路では二回目も拒否する。**計測学的設計**（Metrological Design）— コントラクトを計器として作る：多様性を座標へ畳み込み、計測できるすべての座標を計測し、残りを単調にする。**メタ方程式**（Meta-Equation）— アグリゲーター全体を一つの最大化として表したもの。単一の失敗する因子が経路をゼロにするよう、積の形をとる。**モノスロット**（Monoslot）— プールのルーティング状態のすべてを一つの 256 ビットワードに収めたもの。内部に価格はない。**単一コールバックの原則**（One-Callback Doctrine）— 一つの `fallback` が、V3 型のすべての会場のフラッシュ会計コールバックに応答し、三重に守られる。**一方通行の扉**（One-Way Door）— バイトコードとしての放棄：制御層は死に、増加のみのキュレーター層が残る。**ペア証明**（Pair-proof）— プールは、レジストリが保存する前、またはディスカバリが列挙する前に、自身の `token0`/`token1`（または再導出された id）を証明する。**射影距離**（Projection distance）— 拒否の観測対象が、決定を下す対象からどれだけ離れているか。**自己修復レジストリ**（Self-Healing Registry）— プロトコルは流動性を取引することで学習する：ペアごとに十六スロット、適合度による順位付けの退去、演算による減衰。**余剰ルール**（Surplus Rule）— プロトコルの取り分は、一つの計測された基準の 28 bps であり、見積もりと引き渡しの差に応じて増えるものは何もない。**第三の結果**（Third way）— フィクスチャの結果のうち、フロア内の決済で Router に何も残らないものでも、当方のセレクタを伴う拒否でもないもの。 ## 参考文献 1. G. Angeris, A. Evans, T. Chitra, S. Boyd. *Optimal Routing for Constant Function Market Makers.* arXiv:2204.05238, 2022 (ACM EC '22). — 最適化を凸計画として扱う CFMM 上のルーティング。§10.4 の比例アロケータが及ばない最適解。 2. T. Diamandis, M. Resnick, T. Chitra, G. Angeris. *An Efficient Algorithm for Optimal Routing Through Constant Function Market Makers.* arXiv:2302.04938, 2023 (Financial Cryptography 2023). — 同じ問題に対する双対分解アルゴリズム（§23）。 3. H. Adams, N. Zinsmeister, D. Robinson. *Uniswap v2 Core.* 2020. https://uniswap.org/whitepaper.pdf — 定積の基準と §4.2 の 30 bps のデフォルト。 4. H. Adams, N. Zinsmeister, M. Salem, R. Keefer, D. Robinson. *Uniswap v3 Core.* 2021. https://uniswap.org/whitepaper-v3.pdf — 集中流動性、`slot0`、Q64.96 固定小数点（§4.2、§15.6）。 5. Uniswap Labs (H. Adams et al.). *Uniswap v4 Core.* 2024. https://uniswap.org/whitepaper-v4.pdf — シングルトン PoolManager、フラッシュ会計、フック権限のアドレス符号化（§5、§14.2）。 6. M. Egorov. *StableSwap — Efficient Mechanism for Stablecoin Liquidity.* 2019. https://curve.fi/files/stableswap-paper.pdf — §4.1 で切除された系統の増幅された不変条件。 7. P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, A. Juels. *Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability.* IEEE S&P 2020. DOI 10.1109/SP40000.2020.00040. — §14.3 が排除を主張するのではなく抑える、順序付けの敵対者。 8. L. Zhou, K. Qin, C. F. Torres, D. V. Le, A. Gervais. *High-Frequency Trading on Decentralized On-Chain Exchanges.* IEEE S&P 2021. DOI 10.1109/SP40001.2021.00027. — サンドイッチ攻撃の計測と形式化（§14.3）。 9. P. Cousot, R. Cousot. *Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints.* POPL 1977. DOI 10.1145/512950.512973. — 健全な抽象化としての単一ティック閉形式の枠組み（§23）。 10. M. R. Clarkson, F. B. Schneider. *Hyperproperties.* Journal of Computer Security 18(6), 2010. DOI 10.3233/JCS-2009-0393. — トレース集合の性質。再分配に関する所見が属するクラス（§21、§23）。 11. T. Y. Chen, S. C. Cheung, S. M. Yiu. *Metamorphic Testing: A New Approach for Generating Next Test Cases.* HKUST-CS98-01, 1998; arXiv:2002.12543. — §15.7 の第二の審判。 12. R. A. DeMillo, R. J. Lipton, F. G. Sayward. *Hints on Test Data Selection: Help for the Practicing Programmer.* IEEE Computer 11(4), 1978. DOI 10.1109/C-M.1978.218136. — ミューテーション解析と結合仮説（§15.2）。 13. A. Avizienis. *The N-Version Approach to Fault-Tolerant Software.* IEEE TSE SE-11(12), 1985. DOI 10.1109/TSE.1985.231893. — §15.8 の祖先。 14. D. R. Kuhn, R. N. Kacker, Y. Lei. *Practical Combinatorial Testing.* NIST SP 800-142, 2010. DOI 10.6028/NIST.SP.800-142. — カバリング配列と t-way 相互作用カバレッジ（§15.4）。 15. B. Littlewood, L. Strigini. *Validation of Ultrahigh Dependability for Software-Based Systems.* Communications of the ACM 36(11), 1993. DOI 10.1145/163359.163373. — 正しさの確率が述べられない理由（§15.11）。 16. A. Akhunov, M. Salem. *EIP-1153: Transient Storage Opcodes.* https://eips.ethereum.org/EIPS/eip-1153 — レッグコンテキスト、手数料台帳、リエントランシーロック（§11.4、§13.2）。 17. V. Buterin. *EIP-170: Contract Code Size Limit.* https://eips.ethereum.org/EIPS/eip-170 — 24,576 バイトの壁（§16.3）。 18. V. Buterin. *EIP-1014: Skinny CREATE2.* https://eips.ethereum.org/EIPS/eip-1014 — 𝒟 のアドレス演算（§7）。 19. M. Lundfall et al. *EIP-2612: Permit Extension for EIP-20 Signed Approvals.* https://eips.ethereum.org/EIPS/eip-2612 · Uniswap Labs. *Permit2.* https://github.com/Uniswap/permit2 — Permit2 の扉（§11.1）。 20. V. Buterin, S. Wilson, A. Dietrichs, M. Garnett. *EIP-7702: Set Code for EOAs.* https://eips.ethereum.org/EIPS/eip-7702 — 委任されたアカウントが同じ扉を呼び出す（§11.1）。 21. *ERC-7201: Namespaced Storage Layout.* https://eips.ethereum.org/EIPS/eip-7201 — Hub のストレージ名前空間（§16.1）。 22. MariaDB Corporation Ab. *Business Source License 1.1.* https://mariadb.com/bsl11/ — コードのライセンス。 23. Fable & Mitra. *BlazePhoenix-Dex: an on-chain DEX aggregator with measured routing.* リポジトリ、`main` 8949a9d, 2026-09-05. https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex — 本論文のあらゆる主張の正準的な出典。付録 C はそこから数値を再現する。 24. S. Müller, N. Moumeni, A. Messaoudi. *Cost of Manipulation in AMM-Based Oracles.* arXiv:2606.03548, 2026 (Financial Cryptography 2026, DeFi workshop). — E25 の背後にある流動性加重中央値の上限（§10.3、§23）。 25. *Ormer: A Manipulation-resistant and Gas-efficient Blockchain Pricing Oracle for DeFi.* arXiv:2410.07893. — 中央値を推定するオンチェーンオラクル（§23）。 26. *From Means to Medians: Optimal Benchmark Design.* arXiv:2506.22142. — どのベンチマークが最も操作しにくいか（§23）。 27. *Optimal Routing across Constant Function Market Makers with Gas Fees.* arXiv:2603.02844. — ガスを伴うルーティング（§23）。 28. *Routing Frictions and Executable Liquidity in Fragmented Markets.* arXiv:2609.19013. — 広告された流動性と実行可能な流動性（§23）。 ## 引用方法 Mitra. *BlazePhoenix Technical Whitepaper: an on-chain liquidity aggregator whose quote and execution are one computation.* バージョン 2.3.0、2026-10-14。Zenodo。DOI [10.5281/zenodo.23084091](https://doi.org/10.5281/zenodo.23084091) （寄託された v2.3）。全バージョン： [10.5281/zenodo.23084090](https://doi.org/10.5281/zenodo.23084090). 最初の寄託シリーズ（v2.2）の Concept DOI： [10.5281/zenodo.22526574](https://doi.org/10.5281/zenodo.22526574). BibTeX その他の形式： https://blazephoenix.xyz/research/whitepaper