# CCTP 源链已 burn、目标链没到账？核对消息、证明与 mint

整理：链小知（AI 辅助）
资料核对日期：2026-10-11
引用地址：https://lianxiaozhi.com/tools/guides/circle-cctp-burn-attestation-mint-status
难度：进阶
核验方式：官方文档整理，未执行真实账户操作

以已有跨链转移为输入，沿源链 burn、Circle attestation 和目标链 receiveMessage 检查，区分证明就绪与真实铸造到账。

## 使用工具
- [Circle CCTP](https://lianxiaozhi.com/tools/circle-cctp) · [官方入口](https://developers.circle.com/cctp)

## 前置条件
- 已有源链交易哈希、来源与目标网络、资产地址、接收地址及所用 CCTP 版本。
- 只读核对已发生的转移；不 burn、不提交 receiveMessage，也不发起 reattest。

## 1. 确定版本、环境与 domain

从原集成说明确认是哪个 CCTP 版本以及主网或测试网。CCTP domain 是协议的网络标识，不能直接把 EVM chainId 当成 domainId。

记录源与目标 domain、burnToken 和预期 mintRecipient。非 EVM 地址的编码规则可能不同，不能将 EVM 地址的截断办法通用于所有目标网络。

核对结果：已有记录可以确定版本与两个 domain；不明时先查原服务商。
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)

## 2. 先证明源链 burn 真的成功

打开源链交易回执，确认成功状态与实际消息事件。只看到钱包提交或交易哈希，还不足以说明资产已经被销毁。

一笔交易可能产生多条消息。保存每条消息的日志索引及目标信息，按目标 domain、资产、数量和接收方选中本次转移对应的消息。

核对结果：记录成功源交易与可识别的那条消息，而非只保存整笔交易。
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)
依据：[Circle：查询消息与 attestations](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)

## 3. 按源交易查证明状态

官方当前查询路径为 GET /v2/messages/{sourceDomainId}，按 transactionHash 或 nonce 筛选。主网与 sandbox 主机不同，使用与原转移一致的环境。

这里只说明读取方法；若已有服务商页面可展示消息，就保存其原始结果。API 返回 400、404 或网络错误时，先检查参数与环境，不能写成证明不存在或资产归零。

核对结果：保存 sourceTxHash、对应消息、nonce、status 与查询时间，失败单列。
依据：[Circle：查询消息与 attestations](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)

## 4. 证明 complete 后继续查目标执行

Circle 返回 status complete 说明证明已经取得，不等于目标链 mint 交易成功。当前响应还可能包含 forwardState 与 forwardTxHash，应把它们当后续执行线索。

如果没有目标交易，记录为证明就绪、执行待确认。不要反复在源链 burn 作为重试；缺少执行结果需要沿同一条消息排查。

核对结果：证明状态和目标执行状态分两列，complete 没有被写成已到账。
依据：[Circle：查询消息与 attestations](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)

## 5. 核对 receiveMessage 与接收资产

打开目标交易，检查调用链、成功状态和 mint 到预期接收方的资产记录。V2 的 destinationCaller 可能限制谁可接收消息；不能假设任何地址都能完成。

对失败记录检查是否消息已经使用、证明版本错误、调用方限制或过期等条件。Fast Transfer 消息可能有 expirationBlock；在 ARB-stack 目标链该字段使用 L1 区块，不能用 L2 当前高度比较。

核对结果：目标成功回执、资产地址、数量与接收方相互匹配；失败原因有对应日志。
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)

## 6. 检查费用与后续逻辑

以消息与目标回执里的实际费用解释数量差异，不把历史固定费用用于所有路线。V2 hookData 是交给集成方处理的元数据，核心协议不会替集成方自动完成全部后续业务。

最终结论可为“源链成功、证明等待”“证明就绪、目标未确认”或“目标已 mint、后续操作待确认”。如果需重新证明，交由原集成方按官方恢复流程处理，本教程不调用写入接口。

核对结果：最终记录清楚指出完成阶段、未完成阶段和需要提供的错误证据。
依据：[Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)
依据：[Circle：查询消息与 attestations](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)

## 常见错误
- 将 domainId 与 chainId 混用。
- 只看 attestation complete 就宣布到账。
- 一笔多消息时选错 nonce 或接收方。
- 用错误层的区块高度判断 Fast 消息过期。
- 把 mint 成功扩展为 hook 后续业务成功。

## 完成检查
- 源链消息、证明与目标交易可以串联。
- 资产及接收方已核对。
- 没有执行证据的阶段明确保留待确认。

## 相关知识
- [跨链显示已发送却未到账？来源交易、消息与目标执行分开查](https://lianxiaozhi.com/learn/bridge-transfer-status)
- [原生 USDC 与桥接 USDC 有什么区别？先核对发行与兑付路径](https://lianxiaozhi.com/learn/native-usdc-and-bridged-usdc)

## 官方依据
- [Circle：CCTP 技术流程、消息字段与过期恢复](https://developers.circle.com/cctp/references/technical-guide)
- [Circle：查询消息与 attestations](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)