投票通过不等于生效：提案队列的状态机与执行失败

治理投票以高票通过，社区公告发出，然后参数页上的数字纹丝不动——这不是玄学，是链上治理最常见的收尾事故。要理解为什么，得先把提案看成一台状态机：创建、投票、计票通过、排进时间锁、执行，每个状态由不同合约函数推动，后两个状态是普通交易，普通交易就可以失败。投票通过改变的只是提案自身的状态字段，协议参数真正的写入，发生在执行那笔交易成功落块的瞬间。

执行会失败，根子在于提案不是脚本，而是一次带前提的调用。提案在创建时把要执行的调用原样写死：目标合约、函数、参数、有时还有最低到账量或滑点上限。从投票到执行之间往往隔着数天的时间锁，期间世界会动：国库提案依赖的授权额度可能已被上一笔支出消耗；换币类执行撞上了价格漂移，滑点保护触发回滚；目标合约自己升级了，函数签名或存储布局变了；执行调用的Gas估算在拥堵块里不够用。任何一种情形下，执行交易回滚，提案的排队记录还在原地，状态不会前进——通过和执行之间，永远隔着一道可失败的门。

失败之后的规则同样重要。多数治理合约允许对同一提案反复执行：失败不消耗提案，重试直到成功或过期；Gas由提交执行的人付，权限在多数实现里对任何人开放，所以一个协议的执行是否及时，取决于有没有人盯着队列。过期条款是另一半答案：排进时间锁的调用通常有一个执行窗口，过了窗口未成功执行，整条记录作废，参数维持原值，想改就得把提案重新跑一遍。一个提案反复执行失败最终悄悄过期的剧本，在多数治理看板上只表现为队列里一条颜色变灰的记录，不点开是看不到的。

用户核验生效的方法因此非常具体：别看投票页的结果条，去看参数本体。每个被治理的参数在合约里都有公开的读取函数，区块浏览器上对着地址调一次，读到的值和提案目标值一致，才算生效；协议前端的数据有缓存和聚合层，只能当二手信息。更进一步，可以订阅目标合约的变更事件——参数改动几乎必然发事件，事件的交易哈希能反查是哪条提案执行的。反过来也有省事的一面：一个设计良好的治理前端会把排期、执行次数、失败原因直接展示在提案页上，读它比读裸合约快得多，前提是你知道这些字段存在且知道去哪找失败记录。

这套状态机知识还解释了两个常见现象。一是为什么有的参数变更需要连发两条提案：第一条失败过期后，创建者必须重新发起走完整个周期，而时间锁的等待不可跳过；二是为什么关键提案创建前要做链上模拟：模拟执行就是把调用放进当前状态跑一遍，能筛掉大部分依赖已经漂移的提案——模拟通过不等于未来执行通过，但模拟都过不了的提案，排进时间锁只会更快过期。把提案理解成一台可以被现实打脸的状态机，比把它理解成一张选票，更接近链上治理的真相。

治理平台上还有两类容易混淆的记录：执行失败与待执行。前者有失败的交易回执可以查原因，后者只是暂时没有人花钱提交，提案安静地躺在队列里。一个社区多久能把排期内的提案执行完、平均等多久、失败后多久有人重试，这些数字拼出来的是治理的后勤能力，和投票通过率一样值得进评估表。参数改不动、改了就回滚的治理，和没有治理只差一步，而那一步往往要持仓人用清算来补票。

本文只做机制说明，不构成投资建议，具体状态名称与重试规则因协议实现而异。