Governor投票快照如何计算？

解释proposalSnapshot、proposalDeadline、getPastVotes和quorum(timepoint)的关系，说明投票期内转币为何不应改变已快照票数。

围绕“OpenZeppelin Governor的quorum和投票快照在哪个时间点计算”，本文只处理OpenZeppelin Governor快照与法定人数能被一手资料直接证明的部分，并把部署差异、客户端支持和治理权限留在各自边界内。

OpenZeppelin Governor快照与法定人数：时间线先于票数

Governor在proposalSnapshot对应的timepoint读取提案投票权，后续转移代币不会回写已经记录的历史检查点。

OpenZeppelin Governor快照与法定人数读取必须先确认clock模式，再确定snapshot、deadline和历史查询timepoint，顺序反了会把当前余额错当历史票权。

OpenZeppelin Governor快照与法定人数：三次读取构成同一快照

quorum(timepoint)按相同历史时点计算法定人数；GovernorVotesQuorumFraction通常把历史总供应量乘以配置比例。

proposalSnapshot与proposalDeadline都使用Governor时钟单位，不一定是Unix秒。

OpenZeppelin Governor快照与法定人数比较提案结果时，应让个人票数、历史总供应量与法定人数落在同一timepoint。

OpenZeppelin Governor快照与法定人数：委托之后发生了什么

getPastTotalSupply与getPastVotes必须在同一timepoint读取，法定人数比较才有意义。

proposalDeadline界定投票结束点，前端应通过合约clock和CLOCK_MODE解释timepoint而不是假设固定秒数。

OpenZeppelin Governor快照与法定人数的新委托会影响未来检查点，不会回写已经产生的治理快照。

OpenZeppelin Governor快照与法定人数的三条硬事实

核验点	规范结论
1	Governor在proposalSnapshot对应的timepoint读取提案投票权，后续转移代币不会回写已经记录的历史检查点。
2	quorum(timepoint)按相同历史时点计算法定人数；GovernorVotesQuorumFraction通常把历史总供应量乘以配置比例。
3	proposalDeadline界定投票结束点，前端应通过合约clock和CLOCK_MODE解释timepoint而不是假设固定秒数。

OpenZeppelin Governor快照与法定人数：边缘条件

委托在快照之后发生可影响未来提案，却不能改变当前提案的历史票权。

不同Governor扩展可能使用绝对票数、分数法定人数或额外计票规则，界面要以部署合约组合为准。

OpenZeppelin Governor快照与法定人数审计证据包

OpenZeppelin Governor快照与法定人数审计证据包不只收集“成功交易”。第一组证据证明提案时间线怎样读取，第二组证据证明票数快照由谁触发，第三组证据保留法定人数公式被拒绝时的原始错误，第四组证据说明前端读取如何从前述材料推出。OpenZeppelin Governor快照与法定人数四组材料都绑定同一网络、对象和版本，避免跨快照拼接出一个表面一致的答案。

OpenZeppelin Governor快照与法定人数审计后的持续监控

OpenZeppelin Governor快照与法定人数如果包含管理员、代理、Mint权限、网关或可升级模块，监控应覆盖角色变化、实现变化、关键配置变化和异常失败率。OpenZeppelin Governor快照与法定人数的标准页面发生状态或版本更新时，内容进入人工复核队列；部署侧变化则按链上事件触发复查。两条线分开，才能判断是规范变化还是具体项目变化。