投票通过不等于落地：治理提案执行失败之后的重排与失效

链上治理给人一个错觉：投票结束、提案显示 Succeeded，事情就办了。实际上从 Succeeded 到链上参数真的变化之间，还有排队、等待延迟期、调用目标合约三段路，而第三段最容易出问题——目标调用失败。理解失败之后系统处于什么状态，比理解投票机制更能解释为什么有些改动迟迟不见生效。

先看主干状态。主流 Governor 实现把提案推进做成几个互相独立的操作：先投票，投票窗口结束后由任何人把它排进执行队列，队列里的条目经过设定的延迟时间后变为可执行，最后调用执行函数触发真正的合约变更。每一步都是普通交易，任何人都能提交，谁先跑到谁拿到那笔燃料成本。这个设计的好处是没有专职运维，坏处是每一环都可能因为外部条件而卡住。

执行失败最常见的来源是目标调用本身。提案内容通常是对协议合约的一次函数调用，而那个函数在真正执行时会重新跑一遍校验：参数边界是否仍然成立、市场是否处于允许改动的状态、地址是否还有权限、被改动的资产是否已被冻结。协议在这些月里继续演进，提案通过时合法的调用，几个月后延迟期满时可能不再合法，于是执行交易回滚。另一种失败是纯工程性的：目标函数消耗的燃料超过队列条目允许的上限，或者调用链里存在不兼容的组合，这类失败与立场无关，只与实现有关。

关键在于失败之后系统处于什么状态。以队列式执行为核心的实现里，执行失败通常不会把提案退回投票阶段，也不会取消它已经排上的位置，而是让这条条目继续停在队列里等待下一次尝试。这意味着一次失败只是记账意义上的未成功，只要条件恢复，任何人可以再执行一次。但也存在另一类设计：为了让失败不留下半途状态，一次执行会把同批的多条操作整批回滚——这就要回到排期时那次批量操作的结构去看，一个提案里塞的动作越多，失败半径越大。

从用户视角，读一个通过未生效的提案，值得盯三个字段。第一个是提案状态与提案是否在队列中的区分：Succeeded 只说明票数过线，队列里的条目状态才说明它排上了没有、延迟期什么时候到。第二个是执行所需 Gas 的预估值：队列记录的 Gas 上限与目标函数实际消耗如果差距明显，反复回滚就是可以预期的，社区通常需要重新排队或提高上限。第三个是执行地址与调用数据：把调用数据解码出来看清楚它到底改哪个参数，比读讨论帖的标题可靠得多，也决定了它会不会撞上今天已经收紧的校验。

围绕失败还有两类治理行为值得认识。一类是重排：社区用同样的调用数据重新提一次案、重新投票、重新排队，走完整流程。这条路干净但慢，等于承认延迟期之后条件变了。另一类是走紧急通道：一些协议在正常治理之外保留了多签直接改参数的权限，用来处理等待周期来不及的事故。紧急通道的存在本身是双刃剑，它降低响应时间，也稀释了时间锁带来的可预期性。读协议文档时要看清哪些参数只能走治理、哪些可以在多签下直改，边界写在哪一行，就是它的权限结构。

还有一种情形经常让人误判：执行交易成功上链、状态也变了，但用户看到的参数没变。这通常是因为协议读取的是另一份配置或另一个版本的合约，改动生效在别的市场上。同一个协议在多链部署时，治理执行只落在治理合约所指向的那条链上的那一处，这属于范围问题而非失败问题，但表现形式和失败很像。

把上面收敛成操作建议：看到治理公告里写已通过，先确认它是否已排队、延迟期满没有；排队中的提案，用模拟执行跑一遍调用数据，看它今天会不会回滚；反复回滚的条目，去看 Gas 上限和目标函数校验，而不是在讨论区追问谁在阻挠；急改类公告，先查它走的是哪条权限路径。这套动作不预测任何人的意图，只把治理的技术状态看清楚。

本文只讨论治理机制与合约执行流程，不构成收益承诺，本文内容不构成投资建议；治理变更可能影响协议参数与市场状态，参与前请核对项目官方文档与链上数据。