If a CCTP transfer is waiting for attestation, a successful USDC burn on the source chain does not yet prove a completed destination payment. Track three separate stages: the burn, Circle's signed message, and the destination mint. Do not start another burn merely because the receiving wallet is empty; first establish which stage of the existing transfer remains incomplete.
Confirm that you are investigating an actual CCTP burn
Keep the source and destination networks, the sending app, original source transaction hash, expected receiving address and transfer reference. An approval transaction can succeed without burning USDC. A bridge app can also offer several routes, so a familiar USDC ticker does not establish which protocol it used. Use the route details and actual transaction record rather than guessing from the button you clicked.
Circle's CCTP technical guide describes an onchain source message, an offchain attestation and destination message processing. On EVM routes, the burn and message-transmitter components are distinct parts of that flow. Other supported chains have their own implementations. Do not copy an EVM contract troubleshooting instruction into a non-EVM transfer without checking the relevant integration.
Verify that the source action completed and produced the intended burn message. If it reverted, an attestation lookup is not the first problem. If only an allowance approval exists, find whether a separate burn transaction was ever authorized. Conversely, if a genuine burn completed, a second transfer creates a new case rather than completing the first.
Use a stage ledger instead of one progress label
| Evidence found | What is established | What still needs checking |
|---|---|---|
| Successful allowance approval only | Permission for a contract action | Whether a burn was submitted and completed |
| Successful burn with its message | The source-side action | Attestation availability for that message |
| Attestation available | A signed message is ready | Destination submission and execution |
| Destination transaction pending | A destination attempt exists | Its execution and intended recipient |
| Destination execution failed | That attempt did not finish the intended action | The exact error and integration's retry procedure |
| Mint completed to the intended address | A chain receipt exists | Wallet display or custodial account crediting |
| App page says complete | A product-specific status is shown | Which stage the product means |
The word complete must be read in context. Circle's messages-and-attestations API returns attestation-related data, and its example also separates forwarding information. Do not turn an attestation status into a blanket statement that the recipient has been credited. The destination transaction remains a separate piece of evidence.
Check the lookup scope before concluding that nothing exists
The current messages API accepts the source domain together with a transaction hash or nonce. CCTP domains identify chains within this protocol; they are not interchangeable with every wallet's network number. A lookup in the wrong environment or under the wrong source domain can be unhelpful even when a real burn exists. Give support the source network name as well as the hash.
A single transaction can also produce more than one message. Match the message to its destination and intended receiving amount instead of taking the first returned item as the answer. Keep the app's transfer reference alongside the chain hash. That makes it possible to relate an application record, a specific burn message and the destination action without treating them as one identifier.
Older examples use a message-hash attestation endpoint and the label pending_confirmations. Do not assume an old tutorial's endpoint or every status string is the correct interface for a current transfer. Check the version and integration that actually created the burn. Likewise, a network explorer's missing destination entry does not tell you whether an offchain attestation is already ready.
Ready to attest is different from ready to receive
Attestation timing depends on the required source-chain confirmation level and transfer mode. A fast option is not a universal deadline, and a delay does not by itself identify an outage. Read the route's current status and official notices. Avoid repeatedly refreshing a raw API at high frequency; the application or its support team should handle normal status checks.
If a valid attestation exists but no destination mint is confirmed, investigate that side. Depending on the app, a relayer may submit the destination transaction or the user may have an explicit claim step. Relevant issues can include a waiting signature, transaction execution or gas provision. Use that app's official continuation flow; do not paste message data into an unknown recovery site.
Some fast-transfer messages have an expiration condition. Circle's re-attestation reference and technical guide describe a refreshed attestation path for applicable cases. That is not a request to burn your original amount again. Ask the integration which procedure applies before authorizing any new source-side transfer.
Collect a support packet that identifies the missing action
- Save the app transfer reference, source burn hash, source network, destination network and intended recipient.
- Check the source record and distinguish an approval from the actual successful burn.
- Identify the relevant message and its attestation state through the official app or documented status interface.
- If attestation is ready, locate the destination attempt and inspect its result instead of restarting the source transfer.
- Report the last verified stage, exact error and time of your check. Share public transaction references as needed, never recovery words or wallet private keys.
For a fictional case, suppose Transfer Cedar has a completed source burn and an available attestation, but the app is still waiting for destination confirmation. The useful support question is whether the destination submission exists and why it is unresolved. Calling it simply a pending burn hides the evidence already collected. If the mint later completes, continue with the recipient's display or service crediting record. Keep a dated copy of the observed status so the next support reply can distinguish an unchanged wait from a newly failed destination attempt. A screenshot without the network and check time leaves that distinction unclear.
Before a future transfer, distinguish native and bridged USDC and verify the destination asset identity. The transaction-hash guide helps with chain records. A no-account swap has its own order instructions; mentioning CCTP here does not establish that a particular swap order uses this protocol. Diagnose the route you actually authorized.
FAQ
How can a CCTP explorer help with a pending transfer?
It can help relate the source burn, attestation and destination action. Verify which stage each displayed status describes, and compare important results with official records rather than relying on one overall progress label.
Does a USDC CCTP bridge burn mean my destination payment is complete?
No; the signed message and destination processing are separate stages. Keep the burn reference and check the existing transfer instead of starting another source payment.
Should I follow a V1 tutorial for a CCTP V2 transfer?
Use the documentation for the transfer's actual version and integration. Older endpoint shapes and status examples should not be assumed to describe the current app's continuation process.