通过投票后还有独立的排队步骤
遇到“dao区块链漏洞”传言，先辨认它说的是未经授权的操作，还是治理规则本来允许的取消。提案通过、进入时间锁、等待结束和执行完成，是不同状态。某一张投票结果截图，只能提供其中一部分信息，不能单独证明合约参数已经改变。
Compound v2治理文档的Queue说明明确，等待期从调用排队函数开始；Execute则在等待条件满足后应用提案动作。因此，不能只拿投票截止时间加上一个延迟，就当成可执行时刻。该文档允许任何以太坊地址调用排队与执行接口，但提案仍须满足相应状态和时间条件。
时间锁中的几个角色不能合称管理员
OpenZeppelin Contracts 5.x指南把排队、执行和取消分成不同角色。Proposer负责把操作排队，Executor负责执行已经可执行的操作，Canceller可以取消已排队操作。使用治理合约配合时间锁时，应分别核对这些角色授予了谁，不能从“有人能执行”推断其也能任意取消。
该指南还说明，执行权限可以按设计开放给任何人；开放触发入口不等于取消等待条件。额外授予治理合约之外的提议者或取消者则会改变权限边界：前者可能形成绕开投票的排队路径，后者可能阻断已批准提案。是否属于漏洞，要结合实际授权和预期规则判断。
取消资格要读到实现中的例外
Compound v2文档说，未执行的提案在排队期间仍可取消，并区分提案创建者与其他调用者的资格。不能把这句话缩成“所有参与者随时可取消”。本次读取的官方仓库GovernorBravoDelegate源码，首先排除已经执行的提案；提案者本人和其他地址随后进入不同判断路径。
对于其他地址，源码还区分提案者是否处于有效白名单：普通分支检查上一块的委托票权是否低于提案门槛；白名单分支同时要求调用者是指定的白名单守护者。只摘录帮助页的票权条件，会漏掉后一项身份限制。白名单还按到期时间判断，核对过去的取消操作时，不能拿今天的身份状态代替当时条件。这里解释2026年9月14日读到的master源码，不认定任一线上部署都采用同版实现。
把公告、权限和执行事件对应起来
阅读记录时，可以为同一提案保留提案编号、目标动作、排队事件、预计执行时间及取消或执行事件。Compound文档分别列出ProposalQueued、ProposalCanceled和ProposalExecuted，三者表达不同事实。执行交易的提交也仍须核对成功结果，不能只凭一串交易哈希补写完成。
例如，假设公告写着提案已通过，记录却只到Queued，应将差异记为尚待执行，而不是立即归为被攻击。若出现取消，则继续核对调用者在当时适用的角色、白名单和门槛条件。上述是本文的资料分析方法，未测试任何线上权限，也不提供绕过治理或操纵票权的步骤。