@NewtonProtocol 的官方文档第 8.3 节对 Gateway 自动重试机制的介绍只有一句：“如果 Operator 不可用，Gateway 会自动将 Intent 重新放入队列，以确保执行成功率。”措辞里的“确保成功率”给人一种纯利他的幻觉。但只要你向主网合约发一笔模拟 Intent，然后主动将分配到的 Operator 节点下线，就会亲眼看到这个“确保”的真正账单。

测试在开发网重现：提交一笔代币交换 Intent，锁定 $NEWT 作为评估费抵押。Intent 进入 pending 状态，Gateway 将其分配给 Operator A。此时切断 A 的 TEE 网络连接，约 45 秒后，链上出现第一个 AssignedFailed 事件，评估费被扣除；Intent 重新入队，再次分配给 Operator B，由于 B 同样不可用，再过 45 秒第二次扣除评估费。循环进行了 11 次，耗时不到十分钟，累计扣除的评估费已达原始预估的 11 倍。期间用户在钱包界面看到的始终是“pending——等待执行”，没有“重试中”，没有“失败计数”，就连区块链浏览器上也仅显示最近一次分配，历史上的失败分配被折叠起来。

这就是无限重试参数的杀伤力所在：它把执行失败的“可见性”剥夺了，同时把失败的成本静默转移给用户。按照白皮书第 10.1 节，评估费在 Operator 开始进行计算时即被扣除。但在 Operator 失联导致的重复分配中，每一次分配都重新触发了评估步骤，TEE 资源确实被调度了，但从用户视角看，没有一次产生有效输出。这好比你把包裹交给快递站，快递员一次次出门又折返，每折返一次就扣你一次快递费，而你只看到“派送中”三个字。

更深的隐患藏在费用记账的底层。Newton 目前的会计模型并未区分“产生有效评估的扣除”和“分配失败导致的扣除”。这两类费用在收入报表里归为一类，都被视作“网络手续费收入”，并进入 Operator 与持币者的收益池。倘若 Intent 因全网 Operator 大面积离线而陷入死循环，网络不仅没有完成服务，反而成了唯一的受益方。这与传统金融里因银行系统故障导致重复扣款的性质并无二致，区别在于链上没有客服可以申诉，只有代码就是规则。$BTC

修复的路径其实不复杂。只需在 Gateway 配置中设定一个默认的重试上限（比如 3 次），并在每次重试时向 Intent 状态事件中写入一个 retryCount 字段，前端即可展示“重试中 (2/3)”。这不需要修改共识层，只是对默认参数的调整和外显逻辑的补齐。然而这个改动从社区呼吁至今已跨过两个版本更新，依然没有落地。是技术难度太高，还是无限重试带来的评估费收入对系统比想像中更重要？作为 NEWT 的持有者，这个问号不应该留在看多逻辑的外头。#Newt $NEWT @NewtonProtocol