Allo 申请通过却没收到匹配资金：核对 DirectTransfer 状态、捐款和 Merkle 发款
链小知 · 进阶 · 核验 · 依官方文档整理
限定DonationVotingMerkleDistributionDirectTransfer策略，分别检查申请、直接捐款、分发证明和已有接收回执。
开始前准备
- 已有同链/同池的strategy实现标识与ABI，确认匹配固定d262e7的DVM DirectTransfer分支；另备recipientId/recipientAddress、状态/窗口快照、已脱敏捐款和分发记录。
- 已有distribution index、amount、proof/root和对应区块时点可用于字段比对，若无这些记录只能定位缺证，不重新调用或生成业务请求。
1. 先确认具体策略，而不是通用 Donation Voting 标签
从已有pool.strategy和strategy.getAllo/getPoolId核对该池身份，确认是DonationVotingMerkleDistributionDirectTransferStrategy且ABI/实现范围匹配。Allo的register/allocate/distribute将原sender和data交给策略，策略data不是所有池通用格式。
DirectTransfer捐款经_afterAllocate直接转recipientAddress，另有Pool匹配资金分发；Vault或旧v2.1文档“捐款留strategy”不能套它。实现只知名称时暂停解码，下文固定源码不是当前部署确认。
检查结果：确认DirectTransfer具体范围，未把其他策略同名标签当方法证据。
2. 核对收款身份与申请最新状态
把recipientId、recipientAddress、useRegistryAnchor、metadataRequired和最新getRecipientStatus分列。useRegistryAnchor开启时ID为注册anchor且sender须profile owner/member；关闭时使用非零anchor或sender身份。收款recipientAddress独立，不必等于ID。
新申请为Pending；此前Accepted申请更新会回Pending，Rejected更新变Appealed。对已有Registered/UpdatedRegistration和最新状态逐项核，不能用旧“通过”截图代表当前资格。固定Status枚举Accepted为2，但这仅是申请状态，并非到账凭证。metadata required缺protocol/pointer会INVALID_METADATA，零收款地址会RECIPIENT_ERROR。
检查结果：申请身份、实际收款地址和最新状态对应，没有把Accepted当付款。
3. 按窗口、token 和完整回执解释直接捐款
核已有registration/allocationStartTime和EndTime（Unix秒），配对应区块timestamp，不用浏览器本地日期判断。固定窗口包含start/end等号且manager可更新；isValidAllocator恒true仍受Accepted、时间和allowedTokens检查。native token时msg.value须与amount一致。
已有Allocated日志只记录捐款阶段，核同笔_afterAllocate路径及recipientAddress实际token收款。None、Permit、PermitDAI、Permit2授权途径不同；Permit调用失败而已有足额allowance时可继续，所以局部trace错误不自动等于整笔revert。捐款token也不必等于Pool匹配token。
检查结果：直接捐款金额/token/接收者由完整已有回执支撑，窗口和授权分支具体定位。
4. 核对 matching 分发的 root 与输入层级
对已有DistributionUpdated核merkleRoot和metadata时点。固定updateDistribution须allocation严格结束后、manager、且尚未开始distribution；不要把轮次end当天UI文字当完成条件。
具体_distribute忽略外层recipientIds，用data内Distribution[]的index/recipientId/amount/proof；getPayouts又需外层recipientIds/data数组等长，但具体_getPayout忽略外层单个recipientId，读取data内Distribution。检查两个层级是否一致，再对该时点recipientAddress；证明叶子绑定index、ID、当前收款地址和amount双重Keccak，不只按项目名称匹配。
检查结果：root/index/data内身份/收款地址/金额在同一快照匹配，未误用外层列表或旧地址。
5. 把 payout view、已分配 bitmap 和权限分开
核已有hasBeenDistributed(index)与getPayouts结果：已分配index或无效proof使amount返回0；返回0不能直接称未获资助。非零view也不检查完整manager资格或池资金够不够，因此不保证能发款。
固定distribute须poolManager，非零root，先置distributionStarted，再逐项验证/扣poolAmount/转pool.token；任意项失败会整体revert，不能把失败交易前trace的局部动作写成部分成功。30天后manager withdraw是另一回收方法（严格晚于allocationEndTime+30days），不是受资助人自助领取入口。
检查结果：预览、bitmap、权限、资金和整笔交易状态分别判断，无资金/无资格保留未知。
6. 用 FundsDistributed 和接收记录确定匹配资金结果
已有成功分发回执时，逐项核FundsDistributed的amount、grantee、pool token、recipientId以及对应index已分配状态；再对相同token收款记录。只看到BatchPayoutSuccessful或捐款Allocated不能代替本项目匹配资金到账证据。
把结果写为“申请状态”“直接捐款接收”“matching proof/view”“已有matching转移”四列。缺root/proof/区块时点或当前实现时注明缺项；维护模式不等旧服务会代为发款，也不承诺补发时间/费用。
检查结果：明确差异发生在申请、捐款或匹配分发，不用重复捐款/签名/分发来验证。
怎样确认完成
- 同一池、策略和时点下，申请/捐款/匹配分发与实际接收记录分开可复查。
- 没有新注册、授权、捐款或distribute；缺失字段和部署差异明确未知，verification为documentation。
常见错误与边界
- recipientId可能是anchor，recipientAddress才是该策略记录的收款地址；旧anchor/新metadata不能混合时点。
- getPayouts的data内ID是具体DVM实际输入，外层列表不能覆盖它；其他策略可能不同。
- Accepted、Allocated、非零PayoutSummary和FundsDistributed属于不同阶段；业务回执未读取不能标实测。