TimelockController状态如何判断？

拆解operation id、predecessor、salt、最短延迟与Waiting、Ready、Done状态，说明Proposer、Canceller、Executor和Admin权限。

Timelock的Pending包含Waiting和Ready；Ready只说明延迟结束，并不表示操作已执行。

操作ID

operation id由target、value、payload、predecessor与salt共同决定。相同调用换一个salt会成为不同操作，批量操作则对整组调用编码。

状态转换

Proposer负责schedule；操作在延迟期是Waiting，时间到后是Ready，两者都属于Pending，Canceller可在执行前取消。

角色矩阵

Executor只能执行Ready操作，并且predecessor必须已经Done。把Executor开放给零地址只开放“代为执行”，不会开放排队权限。

延迟变更

updateDelay只能由Timelock自身调用，所以缩短或延长minDelay也要作为操作排队。监控应覆盖RoleGranted、CallScheduled、Cancelled与CallExecuted。

证据底座

证据项	规范结论
1	Timelock operation由target、value、payload、predecessor和salt哈希识别，可处于Unset、Waiting、Ready或Done。
2	Proposer负责schedule，Canceller可取消仍属Pending的Waiting或Ready操作，Executor只能执行已经Ready的操作。
3	updateDelay只能由Timelock自身调用，因此调整最短延迟也必须先排队再执行。

现场排查顺序

检查层	需要留下的证据	阻断条件
操作ID	从OpenZeppelin Documentation确认TimelockController操作状态怎么查的正式定义，并保存网络、地址与读取时间	定义或版本对不上时，不继续套用本文步骤
状态转换	在原始返回、签名消息或交易指令中定位对应字段，不用界面缩写代替	找不到原始值时，把结果标为未验证
角色矩阵	用OpenZeppelin Access Control复核实现行为，特别记录可选扩展与权限主体	实现与规范语义不一致时，按具体部署重新评审
延迟变更	构造一个失败样例，确认客户端会明确拒绝而不是静默修正	失败仍被显示为成功时，停止上线并补充状态校验

记录TimelockController时，把“输入快照”和“判断结果”分开。该主题的快照包含原始bytes、字段单位、对象地址、区块高度与OpenZeppelin Documentation版本；结果注明通过的规则和仍未知的延迟变更。这样即使TimelockController操作状态怎么查随后变化，也能复现当时的结论。

TimelockController的测试至少覆盖正常路径、缺少状态转换、提交前状态改变及客户端不支持当前版本。前几类验证角色矩阵边界，最后一类确认产品不会删除字段或改走未经用户确认的回退路径。