Coordinape 归档 CSV 怎么核对：分配文件、Safe 格式与付款结果
链小知 · 进阶 · 核验 · 依官方文档整理
只检查已保存文件，区分Coordinape预算导出和第三方支付输入格式，定位地址、币种和结果差异。
开始前准备
- 已有获授权的epoch分配CSV、转换后支付CSV（如有）、原渠道/网络/预算以及已有付款回执；保留原文件副本，不上传到支付工具。
- 当前官方App已关闭；本文不能帮助重新导出不存在的数据，也不使用Parcel账户、Safe签名或付款。
1. 固定原文件和支付渠道范围
对两份文件分别记录来源、生成时间、Circle/epoch、预算和原支付渠道。Coordinape当前已sunset，旧文档的CSV Export/Disperse/Safe/Parcel是历史选择，不代表今天还能打开对应集成。
缺原epoch来源时，先标未知；文件名写Coordinape或同名成员不能证明是哪次预算。保留原件，在本地另做核对表，避免把修改后文件当原始凭证。
检查结果：文件来源、时点、epoch和历史产品边界明确。
2. 区分原预算导出和目标 Safe CSV
原Coordinape CSV是否包含具体header，须以原文件看见的列为准。旧Safe目标格式列token_type、token_address、receiver、amount、id，不能宣称Coordinape原导出必然已具备这些列。
检查已保存目标文件用逗号分隔、第一行header且名称正确。分号分隔、漏header或列对错位会使字段理解错误；不要向支付App上传试错来确认。
检查结果：原数据与目标格式各自列名明确，未混同两个文件。
3. 核对地址与资产类型的条件字段
按目标旧格式，token_type仅erc20/nft/native；native token_address留空，native/ERC20 id可空，ERC721 amount可空。把receiver与原成员收款地址逐行对照，检查是否在转换时被截断或错位。
原文称登录地址是ETH mainnet地址，CSV可交其他支付渠道处理，这不保证所有地址在目标链都可正确收款。网络、token合约和NFT id分别核，不能用USDC简称或ETH地址外形决定网络。
检查结果：字段按资产类型核对，receiver/网络/token身份可追溯。
4. 确认金额单位和预算总额
保留amount原字符串及原渠道单位说明，避免表格软件科学计数或小数舍入覆盖数据。旧格式文档未完整说明amount是否采用代币显示小数还是最小单位，不能看见整数就自动乘10的精度次方。
对有明确单位的行合计，与原epoch预算/Fixed Payment/调整记录比较；未能确定单位就列“无法完成金额比对”。ETH/native空token_address不代表零金额，ERC721空amount也不是漏付ERC20。
检查结果：金额单位有依据后才合计，未知没有由默认精度补齐。
5. 把 CSV 验证和授权/提交证据分开
即使本地header/地址/金额检查通过，也只能说明文件与已有分配记录一致。旧Safe流程最后仍需上传/submit，旧Parcel连接会要求签数据访问消息；这些不属于匿名读文件，也不是已到账。
如已保存渠道确认页或提议记录，把它们与最终交易回执分开。没有接收记录时不要写“已支付”；合约分发或CSV预览中的收款列表也不能替代最终执行。
检查结果：文件检查、权限会话、提交和实际付款有分别的证据。
6. 用已有执行记录对每个收款行核查
若有成功付款回执，核同网络/同资产、实际receiver和金额，与对应CSV行相连；失败、未确认或缺回执分别标记。一个批次有确认文字不自动证明每行经济结果都已核对。
记录已知费用和余额差异来源，缺原单位/预算调整/完整支付回执时如实写未决。该归档检查不承诺旧合约可用，也不产生可直接导入或立即执行的新支付文件。
检查结果：每行能定位到资金证据或明确未知，没有将CSV当到账凭证。
怎样确认完成
- 能复查原导出→目标字段→金额单位→已有付款证据链。
- 缺失文件或单位无法恢复时保留未知；无上传、签名或付款，verification=documentation。
常见错误与边界
- Safe是历史目标格式；本文未核当前Safe App菜单或金额解析版本，不生成执行文件。
- 第三方只读账户集成也可能要求签消息，不能当匿名文档读取。