大多数兑换界面只优化一件事：报价输出。
但报价仅仅是预测。它无法告诉你最终的 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 个基点。池子费用、上游提供商费用和网络 Gas 仍需支付。
现在就去试试吧，认证由 @dynamic_xyz 提供支持
