最近在做 AllSwap ，先说明利益关系：我是项目参与者。下面想讨论的是工程问题，不是发优惠码，也不把产品包装成第三方推荐。
跨链聚合器最直观的排序方式，是选择“预计到账最多”的路线。但实际做下来发现，只按输出数量排序容易选到不稳定路线。
举个例子：
● 路线 A 预计到账 100.2 USDT ，历史完成率 91%，P95 时间 18 分钟；
● 路线 B 预计到账 99.9 USDT ，历史完成率 99.4%，P95 时间 4 分钟。
如果只看报价，A 是最优；如果考虑失败、退款和等待成本，很多用户可能会选择 B 。
我们现在考虑把路线评分拆成下面几项：
score = output_value
- gas_cost
- time_penalty
- failure_risk_penalty
- liquidity_penalty
- stale_quote_penalty
这里有几个比较难定的点。
1. 时间惩罚不是线性的
从 1 分钟增加到 3 分钟，大部分用户可能可以接受；从 10 分钟增加到 30 分钟，用户的不确定感会明显增加。因此时间惩罚可能更适合分段函数，而不是简单乘以秒数。
2. 历史成功率可能存在幸存者偏差
如果只统计已经被路由器选中的订单，低流动性路线样本很少，成功率看起来可能反而很高。需要同时记录候选报价、未选路线和失效原因。
3. 小额和大额不应该共用权重
小额用户更在意固定费用；大额用户更在意滑点、深度和失败风险。评分权重应该根据金额区间动态调整。
4. 报价新鲜度需要单独处理
报价数值很漂亮，但生成时间已经超过几个区块，这种路线不应继续排在前面。除了 TTL ，还可以监控连续区块中的输出变化率。
产品流程可以在 https://allswap.io/ 看到。当前是用户选择资产和网络后获取报价，不连接钱包，通过订单地址完成源链转账，再跟踪目标链结算。
想请教做过交易路由、支付通道或聚合器的朋友：
1. 你们会把失败率直接折算成期望价值，还是作为硬阈值先过滤？
2. 路线耗时应该使用最近窗口的 P95 ，还是按链上拥堵状态实时修正？
3. 面向用户展示时，是给一个“推荐路线”，还是同时展示“到账更多”和“更稳定”两个选项？
欢迎讨论评分模型和可观测性设计。涉及真实资产时，任何新路线都应该先小额测试；本文不构成投资建议。