Splits 收到分账却未到账：区分 Pull、Push、Warehouse 与提现
链小知 · 进阶 · 核验 · 依官方文档整理
把原始收款、分配凭证和外部转账分开，按已有余额与回执解释资金停在哪个阶段。
开始前准备
- 已有网络、Split 类型、代币地址/精度、收款人及入金、分配、Warehouse、提现的去敏记录。
- 只核已有资料，不调用余额/RPC/withdraw，不授权、不签名或重试提现。
1. 按资产身份建立收款记录
核对 Split 地址收到的是哪条链的原生币或哪一个代币合约，保留原整数金额和时间。协议流程先接收，再分配，最后可能提现。
仅有入金成功不能写成各收款人已得到外部钱包转账；代币符号相同不代表同一资产。
检查结果：收款记录有链、合约和原数量，阶段未合并。
2. 根据 Pull 或 Push 定位分配去向
Pull 分配后通常计入 Warehouse；Push 尝试直接发送。以原 SplitDistributed 及实际资产移动对照，不以 UI 的 Distributed 标签替代到账。
Push 原生发送失败可进入 Warehouse；ERC20 没有该回退，任一收款转账失败可令整笔分配回滚。原生重入等情况也可能整体失败，不能一律断言已回退。
检查结果：每笔明确成功、回滚或 Warehouse 待提现，未知路径保留。
3. 分开 Split 余额与个人凭证
原 getSplitBalance 返回 splitBalance 与 warehouseBalance，按该 Split/资产理解；个人已分配份额另对照 Warehouse balanceOf(ownerAddress, tokenAddress) 的已有结果。
Warehouse 使用 ERC6909 凭证记底层资产请求权，不能把凭证数量再与同一底层余额相加；精度与 bigint 原值保留。
检查结果：Split 未分配款、Split 在 Warehouse 的余额和个人份额没有串用。
4. 检查提现配置与激励路径
核对已有 getWithdrawConfig(userAddress) 的 incentive 和 paused。Warehouse 可暂停外部第三方代为提现，不等同暂停 Split 分配。
SDK withdraw 描述单资产全余额且忽略提现激励；batchWithdraw 按 tokensAddresses/amounts 并可给 withdrawerAddress 激励。记录各自方法和单位，不把调用人当收款人。
检查结果：暂停层、ownerAddress、代币和激励领取者分列。
5. 用原提现回执核对实际转账
从已有 Withdraw 回执对应网络、合约、ownerAddress、代币和转账数量，核对外部收款地址与交易成功状态。事件或请求已发送不足以证明余额已到账。
批量记录逐资产对照 amounts，不能将多种代币原整数相加。若只取得 Warehouse 余额，结论停在已有份额，不猜提现完成。
检查结果：实际到账结论绑定正确资产和成功转账，缺证仍为待提现或未确认。
6. 保留不兼容资产与恢复边界
Pull 文档警示不可转让、转账扣费和 rebasing 资产；V2.0/2.1 的主网 USDT 限制也须按原版本确认。原金额差异不自动归为平台扣费。
Push 是否可更新收款人或处理余额取决于是否可变及 owner 权限。不可变 Split 没有 owner 恢复通道，保留原错误和官方支持入口，不建议追加转账试错。
检查结果：输出资产/版本/流程差异和未核原因，不承诺可恢复或提现时限。
怎样确认完成
- 逐资产形成接收、分配、内部份额、提现和外部转账的证据链。
- 全部结论限已有记录，未执行提现或取得当前余额。
常见错误与边界
- 分配完成当外部到账；Push 原生回退套到所有 ERC20。
- 把 Split 的 Warehouse 余额当个人份额。
- 凭证与底层双计、不同代币整数相加，或外部暂停当 Split 暂停。