治理提案通过就生效了吗？核对 Snapshot 与链上执行状态
链小知 · 进阶 · 核验 · 依官方文档整理
只读检查提案的投票资格、快照、结果、排队和执行记录，区分社区信号与已执行的协议变更。
开始前准备
- 一个具体治理组织及提案链接；如果研究执行结果，还需该组织的 Governor 或 Timelock 地址。
- 本教程只读检查，不连接钱包投票、签名、排队或执行。
1. 识别提案所在的投票系统
先确认是普通 Snapshot 空间、Snapshot X，还是链上 Governor 的治理页面。普通 Snapshot 的链下投票与链上治理执行不能凭页面长得相似混为一谈。
从组织官方入口进入提案，记录空间或组织、提案编号、网络和创建者。转发截图或标题不足以确定是哪一次投票。
检查结果：记录包含可定位的提案链接与投票系统类型。
2. 核对投票资格的具体策略
在空间策略中查看计票依据，例如代币余额、委托投票权或白名单。策略参数还可能指定网络与代币地址，持有同名资产并不自动满足条件。
Snapshot 的投票权依赖提案的快照时点及验证规则，当前余额与当时余额可能不同。遇到投票权为零，先核对策略、快照及委托，而不是要求用户再购入代币。
检查结果：能够说明资格计算依据及其网络、资产或委托要求。
3. 读出投票结果的原始范围
记录开始和结束时间、选项、各选项票权及所用计票规则。阅读组织对 quorum 和通过门槛的规定，不能只按人数或某选项占比判断通过。
结果页面是该次投票的证据。普通链下投票若仅用于表达意见，还需找到后续执行提案或组织的落地说明，才能判断是否产生链上变化。
检查结果：结论分别写明投票是否结束、是否满足该组织门槛，以及执行证据是否存在。
4. 检查通过后的排队和时间锁
Cactus 官方执行文档说明，使用 Timelock 的治理通常还需 queue 操作来启动延迟，之后才能执行。提案通过不等于自动排队，排队也不等于已经执行。
查看是否有排队交易及时间锁地址，读取该实例的延迟。没有 Timelock 的治理可能不需要这一阶段，不能给所有协议套一个固定等待时长。
检查结果：有明确的 queue 状态、交易证据和延迟来源，或标明该治理不采用时间锁。
5. 核对执行调用与真实变化
打开执行记录，核对网络、提案编号、执行是否成功以及调用目标。若提案包含转账、升级或参数更新，继续核对相应合约事件或当前参数；标题中的意图不能替代调用结果。
谁能排队和执行取决于 Governor 的具体实现。没有成功执行记录时，将结论保留为“投票通过但执行尚未确认”，避免将失败调用报道成协议已经升级。
检查结果：生效结论能指向成功执行交易和对应参数或事件；证据缺失时明确保留未知。
怎样确认完成
- 得到从资格、结果到排队和执行的状态记录。
- 每个生效判断有可追溯的执行证据。
- 没有执行证据的提案保留为待确认。
常见错误与边界
- 把普通 Snapshot 的赞成票当成自动执行的合约变更。
- 用当前余额代替快照时点的投票资格。
- 将 Passed、Queued 与 Executed 三种状态混用。
- 按其他组织的门槛、延迟或权限解释当前组织。