Coordinape 归档核对：GIVE 已分配为什么钱包没收到钱
链小知 · 进阶 · 核验 · 依官方文档整理
应用已关闭；用本人已有epoch与分配导出，复核积分、预算和支付阶段。
开始前准备
- 本人或获授权的历史Circle/epoch快照、成员设置、最后分配记录、预算币种/金额和CSV；本文只整理已有文件，不要求旧App登录或新导出。
- 保留文件生成时间与原epoch开始/结束时间，成员地址可脱敏；缺失数据明确未知。
1. 先标记归档产品和具体 epoch
在对照表第一行标“Coordinape已退役”，写下原Circle标识、epoch标识、文件获取时间和活动时窗。当前官网明确App关闭与合约/开发收尾，旧docs仍能阅读不代表App可恢复。
旧Schedule文档的epoch开始时间采用UTC，长度/是否重复由管理员设置；工作覆盖期可不同于实际分配窗。不要把名字Month/Epoch或本地截图日期自动视为固定月结。
检查结果：产品退役、Circle/epoch与UTC时窗明确，未承诺新导出。
2. 核对成员当时的给予与接收资格
在同epoch已有成员记录中分别核Give Tokens、Receive Tokens、Give Allotment与Fixed Payment。能给GIVE不代表能接收预算；普通团队成员不自动享有同样额度。
旧文档Epoch Statement对Circle可见，但Allocation具体amount/notes称仅接收者能看。只使用本人/授权的导出，不因有Circle成员身份要求其他人的私人分配详情。
检查结果：成员身份、可给/可收、额度及固定付款单列。
3. 区分服务器 GIVE 与钱包资产
GIVE in Gift Circles明确此GIVE只在服务器记账，不会直接发送到钱包。把给予额度、收到GIVE/GET和预算代币数量分别设列，不能将截图上的100 GIVE写成100 USDC。
CoSoul历史pGIVE/Rep采用归一化/多来源；Base Social Oracle GIVE是EAS声誉证明。这些既不是原epoch GET分母，也不证明薪酬已经转账。
检查结果：服务器积分、声誉证明和付款币种没有混用。
4. 按结束时的最终分配重算预算比例
旧Allocation文档允许epoch内调整分配，所以用结束时已保存的最终summary/导出，不能取较早截图累加同一份GIVE。管理员审阅还会核漏人、异常高低和参与者是否分配。
按原文说明例子：收到100 GET、此epoch收到总GET为1000、贡献预算50000 USDC，则预算比例10%、参考分配5000 USDC。分母须同圈同epoch收到的总量；分母为零/未知就不算，未读完整舍入规则不能把小数残差当欺诈或自填补齐。
检查结果：比例由同epoch最终分配和预算重算，示例金额不是实际到账。
5. 把固定付款与支付文件另核
若原导出含Fixed Payment或其他预算调整，分别对照当时规则，不直接将pro-rata例子当包含所有薪资的总额。既有CSV是支付输入，不能因为有收款人和金额就标资金已发。
旧文档CSV可供外部渠道处理；CoVault另有vault→distributor→末端接收/领取层。服务器分配记录和某条链回执未匹配时，结论停在预算/支付待核，不推合约现在还能领取。
检查结果：积分分配、固定付款/调整、支付输入和资金执行分层。
6. 用已有付款回执闭合结论
把已有付款渠道、网络、资产身份、接收地址、金额和交易成功状态与这份epoch文件逐项对应。只有Circle完成、给出GIVE、生成CSV或旧页面“Pay”截图，不能替代接收证据。
若记录不全，写清差异是资格、最终分配、预算还是支付回执缺失。费用按历史实际记录，不引用旧无费计划或CoSoul初始免费语气作现行保证，也不通过新授权/领取补证。
检查结果：可以解释钱包未收款发生在哪层，缺证与已失败分开。
怎样确认完成
- 历史Circle/epoch、资格、最终积分和预算可复查。
- 实际资金结果需已有接收回执；没有新账户/分配/支付操作，全为documentation。
常见错误与边界
- 这是归档排错，不提供当前登录、重新分配、恢复或领取入口。
- Gift Circle GIVE和CoSoul/Social Oracle同名数据不能直接折算付款。