CCTP 源链已 burn、目标链没到账？核对消息、证明与 mint
链小知 · 进阶 · 核验 · 依官方文档整理
以已有跨链转移为输入，沿源链 burn、Circle attestation 和目标链 receiveMessage 检查，区分证明就绪与真实铸造到账。
开始前准备
- 已有源链交易哈希、来源与目标网络、资产地址、接收地址及所用 CCTP 版本。
- 只读核对已发生的转移；不 burn、不提交 receiveMessage，也不发起 reattest。
1. 确定版本、环境与 domain
从原集成说明确认是哪个 CCTP 版本以及主网或测试网。CCTP domain 是协议的网络标识，不能直接把 EVM chainId 当成 domainId。
记录源与目标 domain、burnToken 和预期 mintRecipient。非 EVM 地址的编码规则可能不同，不能将 EVM 地址的截断办法通用于所有目标网络。
检查结果：已有记录可以确定版本与两个 domain；不明时先查原服务商。
2. 先证明源链 burn 真的成功
打开源链交易回执，确认成功状态与实际消息事件。只看到钱包提交或交易哈希，还不足以说明资产已经被销毁。
一笔交易可能产生多条消息。保存每条消息的日志索引及目标信息，按目标 domain、资产、数量和接收方选中本次转移对应的消息。
检查结果：记录成功源交易与可识别的那条消息，而非只保存整笔交易。
3. 按源交易查证明状态
官方当前查询路径为 GET /v2/messages/{sourceDomainId}，按 transactionHash 或 nonce 筛选。主网与 sandbox 主机不同，使用与原转移一致的环境。
这里只说明读取方法；若已有服务商页面可展示消息，就保存其原始结果。API 返回 400、404 或网络错误时，先检查参数与环境，不能写成证明不存在或资产归零。
检查结果：保存 sourceTxHash、对应消息、nonce、status 与查询时间，失败单列。
4. 证明 complete 后继续查目标执行
Circle 返回 status complete 说明证明已经取得，不等于目标链 mint 交易成功。当前响应还可能包含 forwardState 与 forwardTxHash，应把它们当后续执行线索。
如果没有目标交易，记录为证明就绪、执行待确认。不要反复在源链 burn 作为重试；缺少执行结果需要沿同一条消息排查。
检查结果：证明状态和目标执行状态分两列，complete 没有被写成已到账。
5. 核对 receiveMessage 与接收资产
打开目标交易，检查调用链、成功状态和 mint 到预期接收方的资产记录。V2 的 destinationCaller 可能限制谁可接收消息；不能假设任何地址都能完成。
对失败记录检查是否消息已经使用、证明版本错误、调用方限制或过期等条件。Fast Transfer 消息可能有 expirationBlock；在 ARB-stack 目标链该字段使用 L1 区块，不能用 L2 当前高度比较。
检查结果：目标成功回执、资产地址、数量与接收方相互匹配；失败原因有对应日志。
6. 检查费用与后续逻辑
以消息与目标回执里的实际费用解释数量差异，不把历史固定费用用于所有路线。V2 hookData 是交给集成方处理的元数据，核心协议不会替集成方自动完成全部后续业务。
最终结论可为“源链成功、证明等待”“证明就绪、目标未确认”或“目标已 mint、后续操作待确认”。如果需重新证明，交由原集成方按官方恢复流程处理，本教程不调用写入接口。
检查结果：最终记录清楚指出完成阶段、未完成阶段和需要提供的错误证据。
怎样确认完成
- 源链消息、证明与目标交易可以串联。
- 资产及接收方已核对。
- 没有执行证据的阶段明确保留待确认。
常见错误与边界
- 将 domainId 与 chainId 混用。
- 只看 attestation complete 就宣布到账。
- 一笔多消息时选错 nonce 或接收方。
- 用错误层的区块高度判断 Fast 消息过期。
- 把 mint 成功扩展为 hook 后续业务成功。