治理研究：从提案追踪到实际执行
治理提案只有在实际状态被确认后，才能用于判断协议是否改变规则。讨论、投票、通过、排队、执行和生效是不同事件。不要因为投票成功，就把后续条件当作已经满足。
OpenZeppelin 治理参考描述治理合约和状态转换，可以提供核查词汇，但不证明某协议使用了全部组件。实际研究仍需读取部署配置和具体提案记录，不能把库中可能具备的能力写成项目已采用的机制。
把新闻标题改成状态机
先确认提案标识和权威场所。论坛讨论可能只是想法，不等于正式提案。保存提案文本、版本、关联代码或交易负载、投票期间，以及决定通过的规则。文本发生修改时，要核实投票人究竟面对哪个版本。
再检查投票权的计算方式，包括余额观察时点、委托、参与量和通过阈值。赞成票占已投票的比例，与赞成票占全部合资格投票权的比例不是同一个分母。两项都可取得时并列记录，不让很高的赞成率暗示广泛参与。
| 阶段 | 核验问题 |
|---|---|
| 讨论 | 已经正式提案，还是仅提出想法？ |
| 投票 | 标识、快照和资格规则是什么？ |
| 通过 | 所有规定条件是否满足？ |
| 排队 | 还有什么等待或前置条件？ |
| 执行 | 哪笔成功交易执行了负载？ |
| 生效 | 对应部署状态是否反映变化？ |
等待期和阈值依赖具体部署，不能编写一套普遍适用的数值。
假设案例：通过了，但额度尚未改变
假设虚构协议投票将金库支出限额从一百单位降为八十单位。投票按规则通过，但还需要独立排队和执行。研究截止时已经有排队交易，没有执行交易。准确表述应是“已经通过并排队”，而实际限额要依据状态另行判断，不能提前写成已降低。
如果后来执行成功，但负载修改的是另一份合约，也必须核对目标地址和相关状态。成功回执说明技术执行完成，并不自动说明新闻标题描述的经济变化已经实现。对于多项动作的提案，只确认其中一项也不足以代表全部生效。
以上是假设，不评价某个真实协议的治理优劣。它强调人类语言描述与机器动作应当并存，每一部分都要有自己的证据。
对照意图、权限和结果
查明谁可以执行、取消、否决、暂停或升级相关组件。代币投票可能与其他管理权同时存在，不能把整个系统笼统描述成只由某一种投票控制。权限不清楚时，就说明分析停在哪个边界。
逐项比较最终负载与提案语言，列出参数、接收方、网络和前置动作。记录生效区块，方便后来者复现。同一提案后来被取消或替代时，也要放入时间线：曾经通过仍是历史事实，却不应继续当作当前政策。
最后用时间线交付结果，每次状态变化都附来源。这样读者可以看到最后一个已核验状态，以及还缺哪一个事件才能支持下一阶段的说法。
边界与常见错误
部分治理在线下进行，或需要管理者自由裁量执行。此时投票可能只反映偏好，并不自动强制改变系统。执行追踪也不能证明社区正当性、全部投票权的受益归属或未来投票行为，这些属于其他研究问题。
常见错误包括把论坛支持等同正式通过、不标分母就引用赞成比例、将通过写成执行，以及认为成功负载必然实现标题意图。最有用的结论应明确当前状态和待确认条件。
常见问题
提案通过就可以称作协议改变了吗？
只有规则本身使其生效，或者后续证据确认实施时才可以。否则应准确写为已通过、已排队或待执行。
找到执行交易就算完成核查了吗？
这是关键一步，还需核对目标、负载和与研究主张相关的结果状态，尤其是包含多个动作的提案。