Aragon 提案通过但未执行：核对调用者权限、动作目标与失败位图
链小知 · 进阶 · 核验 · 依官方文档整理
从提案的通过条件追到执行权限和实际动作结果，区分 canExecute、调用者授权、配置的 executor 与允许部分失败的交易。
开始前准备
- 准备网络、DAO/治理插件地址、已有 proposal ID、拟核对的执行者地址，以及已有执行交易 hash（若有）。
- 使用目标部署 ABI 的只读方法和公开交易/事件解码。以下字段主要依据 TokenVoting v1.3；其他插件、timelock 或定制 executor 必须提供各自实现。
- 本流程只检查已有数据，不调用 execute、grant/revoke、升级或提交提案。写入需要权限与链上费用。
1. 先拆分 open、成功和 executed
用匹配 ABI 的 getProposal(id) 与创建记录确认提案，记录 open/executed、startDate/endDate、tally 和保存的参数。分别读取 hasSucceeded(id) 和 canExecute(id)，不要以网页“通过”徽章替代它们。
Standard（页面称 Normal）/VoteReplacement 通常要结束投票才能执行，EarlyExecution 则有提前成功的最坏情况判断。尚未结束、参与不足或已执行都可能使 canExecute=false；调用不存在提案的错误不是“等待执行”。
检查结果：提案存在，开放、成功、可执行、已执行四项各有独立依据。
2. 检查三类投票门槛
逐项查看 isSupportThresholdReached（提前模式还看 Early 判断）、isMinParticipationReached、isMinApprovalReached 的提案结果。赞成/反对支持率、含弃权的参与量和最低赞成票数是三种门槛；支持率使用严格超过，不把刚好相等当通过。
优先使用该提案保存的门槛与 getter，避免把 DAO 后来更新的全局设置应用到旧提案。v1.3 固定源码的最低赞成条件是 tally.yes≥该提案 minApprovalPower；API注释中的比例说明不能代替实际存储判断。
检查结果：失败的具体门槛已定位；原始整数、比率和当前全局设置没有混算。
3. 核对执行者与 DAO 的两层授权
canExecute(id) 不含 caller 参数，因此 true 不能证明某钱包有权发送 execute。查看插件上的 EXECUTE_PROPOSAL_PERMISSION_ID 授权记录，确认 where=插件、who=拟执行者或适用的 ANY_ADDR，且条件对这个方法负载成立。
再核对治理插件/配置 executor 对 DAO 的 EXECUTE_PERMISSION_ID。若使用条件权限，仅看一次 Grant 事件或带空 data 的权限查询不足；要结合后续 revoke、当前配置与对应条件实现。没有条件材料时标未知，不建议随意 grant ROOT 或移除治理插件来解决。
检查结果：调用者→插件、执行路径→DAO 两层权限及条件分开检查；未证实授权明确保留。
4. 读取提案保存的 executor 与动作负载
取出 getProposal 的 targetConfig.target/operation、actions 和 allowFailureMap。按数组零起点记录每项 to、value、data，并用目标合约 ABI 解码方法及参数；原生币 value 与 ERC-20 转账参数、gas 费用不是同一个金额。完整目标地址与接收地址要逐项核对。
targetConfig 是提案保存的配置，不能把当前默认 executor 或 DAO 地址直接替代。若目标是另一个执行合约或 timelock，继续查该目标的已排队标识、状态和等待条件；OSx 文档不能给所有外部目标一个统一等待期。DelegateCall、无法解码的 data 或陌生目标均需实现资料，不能只看中文提案标题。
检查结果：实际执行目标、operation 和每个动作负载均有对应记录；定制目标的未知条件未被略去。
5. 追踪允许失败位图与执行交易
若已有执行 hash，打开同一链的交易回执、执行事件和可用的目标调用结果，对齐 proposal ID 与动作列表。allowFailureMap 是“允许失败”，不是“实际失败”：例如6（二进制110）允许索引1、2失败；返回 failureMap=4只表明索引2实际失败。
没有允许失败的动作应按一组原子交易理解；允许失败时顶层成功仍可能缺少某个转账或配置结果。若浏览器未解码实际 failureMap 或目标结果，记录缺口，不能把允许失败位设为已失败，也不能据 executed=true 宣称每项执行成功。
检查结果：已执行交易、允许失败项、实际失败项和目标效果分别核对；无回执不标完成。
6. 用目标状态证明具体动作效果
针对转账核对对应资产、完整接收地址、原始金额及目标资产变化记录；针对治理配置变更查看目标合约在执行后的设置。仅有 ProposalExecuted 或交易成功不足以证明所有提案承诺完成，尤其允许失败或外部 executor 场景。
将结果写为“未到执行条件”“执行者权限未证”“目标等待中”“有执行回执但某动作失败”或“各动作结果已逐项证实”。如需实际执行，重新核对当前状态、调用者、gas 与目标条件；勿为重复执行已完成提案发送交易。
检查结果：结论能回到具体状态/权限/动作证据；费用未知、未执行或部分失败有明确说明。
怎样确认完成
- 保存提案门槛、两层权限、targetConfig、动作清单及已有执行结果的对应关系。
- 文档/源码核验没有目标 DAO 的实时权限或执行回执；缺失现场记录时只能定位待验项，不宣称已执行。
常见错误与边界
- canExecute=true 就认为任意钱包都有 execute 权限。
- 把提案通过、EXECUTE_PROPOSAL_PERMISSION 和 DAO EXECUTE_PERMISSION 当一个状态。
- 把 allowFailureMap 当实际结果，或用当前 executor/global设置覆盖提案创建时保存的配置。