Realms 提案 Succeeded 但资金没动：逐个检查指令组、等待期与执行回执
链小知 · 进阶 · 核验 · 依官方文档整理
从提案投票结果定位 ProposalTransaction，区分完成投票、可执行条件、DAO PDA 签名与实际成功记录，特别检查多组指令和无动作问卷。
开始前准备
- 准备 Realm/Governance/Proposal 完整地址、对应程序与版本、已有 ProposalTransaction 解码，以及执行交易签名（如有）；交易签名是公开标识，不是钱包秘密。
- 优先用官方 V2 提案已有显示与公开账户/交易记录，只读取已存在数据；不点击 SignOff、FinalizeVote、Execute、Flag error 或签署任何操作。
- 固定程序依据为官方 governance-v3.1.0 提交7b90ecf…；实际部署若为其他版本/自定义程序，须另核对状态与时间条件。
1. 确认状态是否已经完成投票判断
在对应提案查看当前 state、governing_token_mint、选项投票结果和 voting_completed_at。SigningOff 不是 Voting；Voting 即使网页倒计时结束，也未必已完成链上最终化。按 3.1.0 文档，未被 tipping 提前结算的结束投票需要 FinalizeVote 才转换状态。
不要为诊断发送 FinalizeVote：先找已有最终化记录及准确链上状态。Succeeded 仅说明投票成功；Defeated/Vetoed/Cancelled 不是等待执行，Completed 还可能来自无动作问卷，须继续检查指令。
检查结果：状态、投票人口、成功选项和投票完成时间有对应记录；网页倒计时不代替状态转换。
2. 列出真正属于提案的交易记录
读取该提案每个 ProposalTransaction 的 proposal、option_index、transaction_index、hold_up_time、instructions、executed_at 和 execution_status，对照父 Proposal 地址及账户所属治理程序。只列成功选项下的记录，编号是组内索引，不是交易签名。
有 signaling/survey 提案没有可执行指令；这时不能因为 Completed 就寻找一笔不存在的资金转账。记录解码失败、漏组或来自另一提案时先补齐关联，别把第一页的一项当全部动作。
检查结果：每个指令组对应正确父提案、成功选项及程序；无动作情况单独确认。
3. 按链上秒数计算各组等待期
对每组把 voting_completed_at 与 hold_up_time 相加：两者分别是 Unix 秒和秒数，不是浏览器毫秒或 Solana slot。固定 3.1.0 在当前链上时间小于或等于这个和时都会拒绝；只有严格晚于该时点才通过这项检查。
还要满足 Succeeded/Executing/ExecutingWithErrors、该选项成功且 executed_at 未设置。不同组 hold_up_time 可以不同，不能只看一个全局倒计时。当前帮助页提到过期但未给通用数值，固定 3.1.0 此检查也没有统一天数；其他部署的期限需看其实际规则。
检查结果：每组有原始秒值、计算出的等待边界及实际版本条件，未用本地时间或猜测的过期天数代替。
4. 解码指令与 DAO 的真实签名身份
查看每个 instruction 的 program id、账户列表、is_signer/is_writable 和 data，用目标程序的匹配解码器解释转账 mint、源/目的账户、数量或配置变化。Governance、Native Treasury 和资产 token account 是不同账户；完整接收地址和单位不明确时不能确认转账对象。
SPL Governance 3.1.0 的执行处理器用 Governance PDA、必要时 Native Treasury PDA 的 seeds 做 invoke_signed；外部 Execute 调用者的交易签名不代表这个钱包持有 DAO 资产权限。缺少必要账户、错误目标程序或前序条件尚未成立可造成指令失败，Preview transaction 也只是模拟。
检查结果：指令实际目标、账户和 PDA 身份与提案一致；模拟或外部交易签名没有冒充 DAO 执行结果。
5. 区分组内原子执行和跨组依赖
一个 ProposalTransaction 的 instructions 在同一笔交易中按顺序执行，任一 CPI 报错会退出；不同 ProposalTransaction 是分别执行的组。3.1.0 处理器没有按 transaction_index 强制所有组依编号顺序，不能据“第2组”认定“第1组已成功”。
如后一组依赖前一组创建账户或修改配置，先看前组真实记录与目标状态。帮助页的顺序说明不能替代部署源码的约束。若状态为 ExecutingWithErrors，检查是否已有 Flag error 记录；一笔执行交易失败本身不等于链上自动写入此状态。
检查结果：跨组依赖有实际证据；组内失败、未执行及被标记错误分别记录。
6. 对齐交易签名、成功标记和资产结果
若已有公开执行交易签名，在同一网络查交易成功/错误及程序日志，再对照对应组的 executed_at 与 execution_status。固定 3.1.0 成功处理后写 Success 并累计执行数，成功选项下所有组完成后才使提案 Completed；仅顶层提案状态不足以指认某一组转账。
转账任务还需查看同一资产、目标账户、原始数量及实际资产变化；失败的日志、尚未执行的组或无法解析的金额不能补成成功。不存在交易签名时只保留“可执行条件待核/尚无执行回执”，不为获得回执发送 Execute。
检查结果：成功标记、真实交易与目标效果逐组一致；Completed 无动作与资金执行完成明确分开。
7. 整理未执行原因和实际费用边界
将每组状态写成“尚未最终化”“等待期内”“选项未成功”“依赖未满足”“执行失败”“成功且目标效果已核对”之一，并保留原始字段/交易标识。未能读取目标实时账户或程序版本时，明确列出缺口。
如需后续实际最终化或执行，应由有权处理者在可信应用中核对当前请求和 SOL 网络费；可能的提案存款退回与 Execute 费用不是同一件事。官方文档和源码证明流程，不证明用户当前 SOL 足够或某笔动作一定能成功。
检查结果：结论能逐组解释资金未动的证据或未知项；未签名、未执行的状态没有越级标为完成。
怎样确认完成
- 形成逐个 ProposalTransaction 的选项、负载、等待边界、依赖、成功/错误记录和目标效果清单。
- 所有流程为官方文档/固定源码核验，未进行 FinalizeVote、Execute 或真实钱包操作；缺少交易与目标账户证据时不宣称资产动作完成。
常见错误与边界
- Succeeded 当成已转账，或无指令 Completed 当成资金已经执行。
- 把 hold_up_time 当区块高度、把 Unix 秒当毫秒，或把等于等待边界当已过期。
- 交易编号自然保证跨组执行顺序；外部执行者地址等于 DAO PDA 资产权限。