先明确“资料更新记录”指什么
“资料更新记录”可能包含三类内容：一是开发团队或社区维护的治理文档发生了什么变化；二是治理提案的创建、投票、通过或取消状态如何变化；三是提案通过后，相关参数、合约或资金操作是否已经在链上执行。三类记录的保存位置和核验方式不同，不能只查看一个页面就下结论。
如果 goc 是某个项目、代币、治理合约或站点的简称，应先确认其官方名称、所属网络和治理合约地址。所提供材料没有明确说明 goc 的具体身份，因此以下方法适用于采用 Governor、DAO 或类似链上治理机制的项目。
第一步：查官方文档及其变更信息
先从项目官方文档、代码仓库或治理门户进入。重点查看治理规则、提案流程、投票期限、法定人数、执行延迟、治理代币和合约地址等信息。如果页面提供版本选择、更新日志、修订历史或代码提交记录，可据此判断资料何时发生了变化。
需要注意，文档更新不等于链上规则已经改变。文档只是说明性资料，真正影响治理行为的内容通常还包括治理合约、投票代币的历史投票权、时间锁合约以及提案执行交易。因此，发现文档内容变化后，还应继续核对链上记录。
第二步：在治理平台查看提案生命周期
链上治理通常围绕提案和投票展开。一个提案可能经历创建、等待投票、投票中、成功、失败、取消、排队和执行等阶段。治理平台一般会展示提案内容、投票选项、投票权、投票期限和当前状态。查询时应记录提案编号或提案哈希，并保存提案涉及的目标合约、调用数据和执行时间等信息。
采用 OpenZeppelin Governor 一类设计时，提案标识可能由提案参数的哈希计算得出，而不是简单连续递增的编号。某些兼容模块会提供更接近传统 Governor 实现的查询方式。因此，不能只按“提案 1、提案 2”这类编号推断全部记录，应结合治理平台显示的哈希、事件和交易进行确认。
如果治理平台没有显示完整历史，可使用其提供的区块浏览器链接，或直接根据治理合约地址筛选事件。治理平台适合阅读和整理，区块链浏览器更适合核验交易是否真实发生。
第三步：用区块浏览器核对链上证据
在确认网络和治理合约地址后，打开对应的区块浏览器，查看合约的交易、事件日志和已验证代码。重点关注提案创建、投票、取消、排队、执行以及时间锁相关事件。事件能够帮助定位治理状态变化，但不同合约版本和模块的事件名称、参数及调用方式可能存在差异，应以实际合约接口为准。
核对一项更新时，可以按照“提案创建交易—投票记录—状态变化—执行交易”的顺序检查。若提案涉及合约升级或参数修改，还要查看执行交易的目标地址、函数调用参数和交易结果。只有交易成功并被网络确认，通常才能说明对应的链上操作已经执行；提案通过本身不一定代表操作已经完成。
治理代币若支持历史投票权，系统会依据提案相关时间点的快照计算投票权，而不是简单读取当前余额。这意味着查询投票记录时，应同时关注投票发生的区块或时间点，不能用当前账户余额反推过去的投票权。
第四步：区分文档更新、提案通过与规则生效
三种状态经常被混淆。文档更新表示说明材料发生了修订；提案通过表示投票满足相应条件；规则生效则通常还需要执行交易，部分治理系统还会经过时间锁延迟。一个参数在文档中已经写出，并不必然表示链上治理合约已经采用该参数。
对于涉及资金、权限或合约升级的提案，还应确认是否由时间锁合约排队后执行。时间锁的存在意味着投票通过与最终执行之间可能有延迟，查询者应同时查看排队和执行记录。若采用多签或人工执行模式，治理结果与最终链上交易之间也可能存在额外步骤。
适用条件与常见问题
这种查询方法适用于采用公开区块链、治理合约和可检索交易记录的 DAO 或协议。若项目使用链下投票、中心化后台、私有网络或未公开治理地址，区块浏览器可能无法提供完整答案，此时需要结合官方治理页面、投票快照或代码仓库进行核对。
常见问题一：为什么治理页面显示的状态与浏览器不一致？可能是索引服务尚未同步、使用了不同的网络，或页面依据的是链下缓存。应以合约所在网络的交易和事件为最终核验依据。
常见问题二：为什么找不到连续的提案编号？部分 Governor 设计使用提案参数哈希作为标识，或通过事件索引提供查询能力，因此应搜索提案哈希、创建者地址、治理合约事件和交易时间。
常见问题三：提案投票通过后为什么没有立即生效？提案可能仍处于时间锁延迟、排队或等待执行阶段，也可能执行交易失败。应继续检查时间锁合约和后续执行交易，而不是只看投票结果。
常见问题四：如何判断资料是否为最新？至少交叉比较官方文档的修订记录、治理平台的提案状态和区块浏览器的链上执行记录。三者相互一致时，结论更可靠；若不一致，应明确标注差异及其对应时间点。