ほとんどのスワップインターフェースは、表示される見積もり出力の最適化に重点を置いています。
しかし、見積もりはあくまで予測に過ぎません。最終的な calldata が実行されるかどうか、ルートがリバートするかどうか、どれだけのガスを消費するか、あるいはトランザクションがユーザーが確認したパラメータを依然として強制しているかどうかは、教えてくれません。
Route は、完全な実行パスを中心に設計されています。
すべてのリクエストに対して、Route は検証済みの Robinhood Chain プール全体の流動性を発見し、96 のプールの限定されたセットから最大 32 の候補パスを構築します。パスには最大 3 つのホップを含めることができます。また、オプティマイザーは、10% の割り当てグリッドとそれに続く 1% のローカル調整を使用して、最大 3 つの独立した分割ブランチも考慮します。
ここでは、部分的な容量のサンプリングが重要です。注文全体に最適なプールが、その一部に最適なプールであるとは限りません。Route はさまざまな割り当てをサンプリングし、同じ流動性を再利用する分割ブランチを拒否し、限定された検索が数学的な大域的最適解であると偽ることなく、結果の組み合わせをスコアリングします。
直接ルーティングは現在、Uniswap V2、V3、フックなしの V4、および GIGA CL をカバーしています。Route は、KyberSwap からのガードされたアップストリーム候補、および有効な場合は 0x も評価できます。これらは、ネイティブの Route 統合として誤ってラベル付けされることなく、個別のプロバイダーとして扱われます。
プロバイダーリクエストは並行して実行され、成功した重複はマージされ、アップストリームプランの構築は直接検索と重なります。価格とプールの状態はリクエストスコープです。完了した見積もりや価格が別のリクエストやブロックに引き継がれることはありません。
重要な違いは、発見の後に現れます。
Route は、各最終候補の実際のトランザクションを構築し、同じ実行ガス価格コンテキストを使用して、共有ブロックに対して eth_call と estimateGas の両方を実行します。リバートする候補は削除されます。シミュレーションに成功した候補は、見積もりのみのフォールバックよりも優先されます。
ガスを共通のリファレンスを使用して出力トークンに変換できる場合、Route は候補を次の順位でランク付けします。
シミュレーションされた出力 − 推定実行ガス
これにより、名目上はより大きな見積もりが、その実行パスがアドバンテージを消し去るのに十分な追加ガスを消費する場合に、自動的に勝利するのを防ぎます。
決済はオンチェーンで独立して制約されます。執行者は、正確な入力、実際に受け取った出力、署名された最小出力、受取人、および期限を強制します。一時的な承認はクリアされます。アップストリームの calldata は、固定されたターゲットとセレクターに対して検証され、Route は確認後に異なるプロバイダーや承認支出者を黙って代用することはありません。
私たちは、DFlow の JIT モデルなどの実行時ルーティングシステムを調査しました。これは、トランザクション内で独自の AMM 価格設定を再評価できます。Route は、より狭い実験的な 2 パス JIT プロトタイプを構築してテストしましたが、これはアクティブな製品の一部ではありません。ライブシステムは、署名前に実行を認識した選択を実行します。DFlow との同等性や実行時の再ルーティングを主張するものではありません。
また、Route は、グローバルな最良価格、普遍的な MEV 保護、保証されたフィル、または監査済みのセキュリティを主張するものでもありません。
Route が提供するのは、見積もり応答だけでなく、実行可能なトランザクションを評価し、ユーザーが確認した制約を決済まで維持する、境界があり検査可能なルーティングシステムです。
正直なところ、@LadyExchange_ が試してみたのを見ましたが、一部のルーティングは機能しませんでした。そこで、自分用にこれを構築し、どこまで押し進められるか試してみることにしました。
Route は 0 bps を請求します。プール手数料、アップストリームプロバイダー料金、およびネットワークガスは引き続き適用されます。
ぜひお試しください。認証は @dynamic_xyz によって提供されています。
