治理提案排队等执行时，如果想提前看到参数到底被改成多少，最可靠的办法不是翻提案正文，而是去时间锁合约里把待执行的 calldata 原样解码。前端页面的文字描述可能滞后、简写，甚至故意误导，只有链上那串原始数据才不会骗人。
下面用一套通用流程拆解，举例以以太坊主网的 Compound 治理和 Etherscan 为主，其他 EVM 链和类似 DAO 工具基本都能复用这套逻辑。
步骤 1：确认提案已进入 Timelock 队列，拿到交易数据
你要做的是找到提案对应的"排队交易"，而不是只看投票结果。投票通过只代表可以入队，不入队就没有可供解码的待执行参数。
怎么做：
- 情况 A：用治理看板（如 Tally、Sybil）
打开对应提案页面，查看状态是否为 Queued 或 "排队中"。拉到"执行交易"区域，一般会直接显示 target、value、data 三段原始数据。直接把这三段复制出来。
- 情况 B：直接从链上 Timelock 合约抓取
没有现成看板就去区块浏览器找 Timelock 合约（例如 Compound 的 Timelock 地址 0x6d903f6003cca6255D85CcA4D3B5E5146dC33925，来源：Compound 文档，2025-04）。进入合约后找到 queueTransactions 函数记录的事件，或调用 getQueueLength、queuedTransactions 这类只读方法，按提案的交易索引把 target、value、data 取出。
完成标准：你手里有至少一条原始 data（一串以 0x 开头的十六进制），这串数据就是执行后会发往目标合约的根本指令。
常见失败原因：很多人把"提案里的参数截图"当成最终依据，结果执行时才发现截图和链上 calldata 对不上。截图完全可以在 UI 层伪造，而 calldata 是绑定在排队交易里的，必须用私钥签名才能动。
步骤 2：解码 calldata，直接读出每一个参数的新数值
这一步就是拿着步骤 1 里那串 data，还原成人类能看懂的参数名和参数值。
怎么做：
- 确认执行的目标合约地址，也就是步骤 1 里的
target。 - 把目标合约地址粘贴进 Etherscan，进入 "Contract" → "Write as Proxy" 或 "Write Contract"（如果合约已开源且验证过）。
- 点击 "Input Data Decoder" 或类似入口（不同浏览器展示位置略有差异），把
data放进去解码。如果 Etherscan 没有内置解码器，就用 abi 在线工具，输入合约 ABI 和那串data手动解。 - 解码后会显示函数名（如
_setInterestRateModel）和各参数的具体数值。你要看的新利率系数、抵押系数、手续费比例都会直接以数字形式列出来。
情况分支：
- 目标合约未开源或未验证：只能用已知的完整 ABI 离线解码。可以从对应协议的官方 GitHub 获取 ABI，再通过 eth-abi 工具或 CyberChef 之类解析。这步稍微麻烦，但数据一样可读。
- 治理体系用的是 OpenZeppelin TimelockController：很多项目把多个操作打包在
scheduleBatch里。解码时需要先把整段 calldata 按数组偏移拆开再逐段解，思路相同，只是多一步拆包。
完成标准：你能看到一串明确的参数列表，比如 "multiplierPerBlock: 228310502283105" 或者 "newLiquidationThreshold: 8000"（代表 80%）。这些数字就是执行后会即刻生效的新值。
风险提醒：提案的标题和描述可能与 calldata 里的具体数值存在偏差，曾经有恶意提案在标题里写"降低费率"，实际 calldata 却将费率拉满。如果你只投票不看 decoded data，等于把自己的资产安全外包给文案。尤其是持有大量治理代币的地址，不验证 calldata 等于给社交工程攻击留后门。
步骤 3：用当前链上数值做对比，确认差异幅度
即便解码出数值，也要把新旧值放在同一个维度下对比，防止单位误解（比如究竟是 wei 还是小数，是年化率还是区块率）。
怎么做：
- 去目标合约里调用与提案要改的函数相对应的只读方法（比如
liquidationThreshold、borrowRatePerBlock），得到当前参数。 - 把步骤 2 解码出的新值与之相减，算出绝对差值与相对比例。
- 如果涉及利率模型升级（比如从 JumpRateModelV2 换成自定义模型），还要单独校验新模型合约的逻辑是否和描述一致，必要时在 Tenderly 上 fork 一笔交易模拟执行一遍。
完成标准：你清楚地知道参数将从 X 变到 Y，变化幅度 Z%。同时能判断这次变化是否在提案声称的范围内。
风险提醒：参数变更往往附带时间锁延迟（Compound 为 48 小时，来源：Compound Timelock，2025-04）。如果在执行前的等待期内没有再次检查 calldata，有可能被追加恶意操作或者被人通过多签方式替换（取决于 Timelock 的实现），所以靠近执行时间点再复查一次很有必要。
下一步动作：等待执行后立即核验
在你确认 calldata 无误并等待时间锁到期后，提案可由任何人触发执行（通常消耗 Gas）。执行后不要假设"肯定用上了新值"，应该在执行交易被打包的同一个区块确认数达到合理水平后（以太坊建议 12 个确认，约 3 分钟），立即重新读取目标合约的参数，并与步骤 3 的新值再做一次比对。核验渠道就用区块浏览器的合约读功能或直接通过钱包发起只读调用，实测时间通常不超过 1 分钟。若数值未变，很可能执行交易失败或 calldata 被发往错误的目标合约，此时切勿进行与参数相关的链上操作，先排查执行交易的状态。
