大多數兌換介面只最佳化一件事：報價的輸出結果。
但報價僅僅是一個預測。它無法告訴你最終的 calldata 是否會成功執行、路由是否會回滾、會消耗多少 Gas，或者交易是否仍能強制執行使用者審核過的參數。
Route 的設計圍繞著完整的執行路徑。
針對每個請求，Route 會在經過驗證的 Robinhood Chain 池中發現流動性，並從 96 個池子的有限集合中建立最多 32 條候選路徑。路徑最多可包含三個跳轉。最佳化器還會考慮最多三個不相交的分支，使用 10% 的分配網格，然後進行 1% 的局部微調。
部分容量取樣在這裡很重要。對整個訂單來說最好的池子，不一定對其中一部分訂單也是最好的。Route 會對不同的分配進行取樣，拒絕重複使用相同流動性的分支，並對結果組合進行評分，而不會假裝這種有限搜尋是數學上的全域最佳化。
直接路由目前涵蓋 Uniswap V2、V3、無鉤子的 V4 以及 GIGA CL。Route 也可以評估來自 KyberSwap 以及（啟用時）0x 的受保護上游候選方案。這些被視為獨立的提供者——不會被錯誤地標記為原生的 Route 整合。
提供者請求會並行執行，成功的重複項會被合併，上游計劃的建構與直接搜尋重疊。價格和池子狀態是請求範圍內的：沒有完成的報價或價格會存活到另一個請求或區塊中。
重要的差異在於發現之後。
Route 會為每個最終候選方案建構實際的交易，並針對同一個區塊使用相同的執行 Gas 價格上下文來執行 eth_call 和 estimateGas。會回滾的候選方案會被移除。成功模擬的候選方案優先於僅有報價的備選方案。
當 Gas 可以使用一個共同參考轉換為輸出代幣時，Route 會根據以下條件對候選方案進行排名：
模擬輸出 − 估計執行 Gas
這可以防止名義上較大的報價在執行路徑消耗足夠多的額外 Gas 而抵消其優勢時自動勝出。
結算在鏈上受到獨立約束。執行者會強制執行確切的輸入、實際收到的輸出、簽署的最低輸出、接收者和截止時間。臨時授權會被清除。上游 calldata 會根據固定的目標和選擇器進行驗證，Route 不會在使用者審核後默默地替換成不同的提供者或授權支出者。
我們研究了執行時間路由系統，例如 DFlow 的 JIT 模型，該模型可以在交易內部重新評估專有的 AMM 定價。Route 建立並測試了一個較窄的實驗性雙路徑 JIT 原型，但它不是活躍產品的一部分。現有系統在簽署之前執行執行感知的選擇；它並不聲稱與 DFlow 同等或具備執行時間重新路由的能力。
Route 也不聲稱提供全球最佳價格、通用的 MEV 保護、保證成交或經過審計的安全性。
它所提供的是一個有限、可檢查的路由系統，該系統評估可執行的交易，而不僅僅是報價回應，並在使用者審核過的約束條件下完成結算。
老實說，我看到 @LadyExchange_ 試用過它，有些路由功能就是無法運作。所以我為自己打造了這個工具，並決定看看我能把它推到什麼程度。
Route 收取 0 bps。池子費用、上游提供者費用和網路 Gas 仍然適用。
現在就去試試看吧，身份驗證由 @dynamic_xyz 提供支援。
