In a CCTP transfer, source-chain USDC is burned before destination-chain USDC is minted. During that gap, the sender has no spendable balance representing that amount on either chain. A lock-
Sources checked November 3, 2026, Eastern Time (GMT−05:00).
You send USDC to another blockchain. The source transaction succeeds, your balance drops, and the receiving wallet still shows nothing. Where is the money?
The answer depends on the route. With Circle’s Cross-Chain Transfer Protocol, or CCTP, the tokens are not sitting in a bridge vault waiting to be released. They have been burned, and the destination mint remains unfinished. A traditional lock-and-wrap route leaves the original tokens in a contract and creates a separate representation elsewhere. Those designs expose users to different failure points. Circle’s CCTP overview, Plume migration guide.
“Native USDC” describes an asset issued by Circle on that blockchain. It does not describe every service used to move it. A bridge interface can deliver native USDC through CCTP while adding its own routing, fees or execution contracts.
Circle’s September 18, 2025 Plume migration guide illustrates the distinction: it identified separate contracts for native USDC and USDC.e bridged from Ethereum. That is historical migration context, not a new launch or a recommendation to use the services listed then. A ticker or logo is insufficient evidence of token identity. Circle’s migration guide.
The current CCTP documentation uses V2 contracts for its main USDC flow and separately labels V1 as legacy. Noble appears in the V1-only section. Support also varies by feature: a destination supporting CCTP does not imply every source supports Fast Transfer or every destination supports automated forwarding. Circle domain identifiers are separate from ordinary chain IDs. Check the actual route against the current support matrix.
For a lock-and-wrap transfer, the bridge locks native USDC on the source chain. The destination token represents that backing. Its usefulness depends on the bridge preserving the locked assets and honoring the mechanism that releases them. Holding the wrapper therefore adds a bridge-specific dependency to the underlying USDC exposure. Circle’s explanation of bridged USDC.
✅ For CCTP, consider an illustrative 1,000-USDC transfer before fees:
This is a transfer of token supply between ledgers, not a bank wire moving a segregated pile of dollars for that individual transfer. “Pending” describes an incomplete protocol operation. It does not mean the user can withdraw the burned tokens from an intermediary wallet. This interpretation follows the documented burn-and-mint model and TokenMessengerV2 implementation.
On EVM chains, TokenMessengerV2 initiates the burn through the token infrastructure and sends a message through MessageTransmitterV2. Circle’s offchain service, Iris, signs after the required confirmation level. The destination then needs a transaction carrying the message and attestation. CCTP technical guide.
The destination contracts verify the attestation. Checking the signature before submission is optional for an application because verification already occurs onchain. That verifies authorization by Circle’s attestation system; it does not remove the dependency on that system being available and operating correctly. Attestation verification.
There is another dependency after signing: someone must submit the destination transaction and pay for execution. That may be the user, an application’s relayer or Circle’s Forwarding Service where supported and requested. An interface can hide this step without eliminating it. A relayer outage can therefore leave an otherwise valid transfer unfinished. Forwarding Service.
Standard Transfer waits for the source chain’s required hard-finality conditions. Fast Transfer allows earlier attestation at a confirmed level. These are different acceptance conditions, not a universal stopwatch.
Circle’s current table lists average Ethereum attestation availability at roughly 20 seconds for Fast Transfer and 15–19 minutes for Standard Transfer. Standard timing varies substantially elsewhere, including a listed 6–32 hours for Linea. These figures describe attestation availability, not a guaranteed time for an exchange account, application or recipient to credit the funds. Destination inclusion and downstream processing remain separate. Finality and block confirmations.
Fast Transfer also relies on a global allowance limiting how much can be minted before the corresponding source burns reach hard finality. Capacity replenishes as those burns finalize. If capacity is insufficient, applications must account for it rather than promise fast completion unconditionally. The allowance is a limit across supported chains, not a dedicated pool for each user’s route. Fast Transfer allowance.
Fees need the same precision. Circle currently lists Standard protocol fees at zero and Fast fees by route, while documenting Standard fee-switch capability in some deployments. Gas, forwarding and application charges are separate considerations. Fast fees may be deducted at mint or paid upfront where supported. “No swap slippage” therefore does not establish that a 1,000-USDC input always produces a 1,000-USDC recipient balance. CCTP fees.
3 fields answer different questions:
A nonce identifies a message and prevents a successful message from being consumed twice. It does not check whether the user chose the intended beneficiary. CCTP message format.
Circle’s published EVM implementation checks the destination domain, message version, signatures and unused nonce. If destinationCaller is nonzero, it also checks the submitting address. Thus “anyone can finish the mint” is conditional: unrestricted messages permit that submission pattern, but restricted ones do not. None of those checks authorizes a relayer to substitute a different recipient. MessageTransmitterV2 implementation.
Address handling is chain-specific, too. Circle’s forwarding documentation says a Solana mintRecipient must be the recipient’s USDC associated token account, rather than the wallet address used for an EVM destination. Copying an address without checking the receiving chain’s requirements can create a different problem from a slow transfer. Solana recipient requirements.
A useful investigation starts with the original transaction, not a second send.
📌No successful burn: A reverted source transaction has not completed the cross-chain burn. Circle’s TokenMessengerV2 implementation documents checks including supported tokens, destination configuration, balance and allowance. Resolve that source failure before treating the operation as funds in transit. TokenMessengerV2 implementation.
📌Burn succeeded, attestation unavailable: Preserve the source transaction hash and correct source domain. Circle’s messages endpoint supports lookup by transaction hash or nonce. A source transaction may contain multiple messages, so reconcile the specific amount and recipient rather than assuming the first result is yours. Messages and attestations API.
📌Attestation available, destination unfinished: Check whether a destination transaction was submitted, whether it reverted, and whether the permitted caller can act. First verify that the nonce has not already been consumed. A duplicate successful mint is prevented by the protocol; repeatedly submitting transactions can still waste gas. Destination validation.
📌Fast attestation expired: An expired Fast burn can be re-attested while the source burn exists, with no request deadline. The mint must then be submitted before the refreshed expiration. This does not refund the transfer. Expired Fast Transfer burns.
📌Recipient requires stronger finality: Re-attestation can obtain a higher finality level than originally requested. Circle notes that the reserved-allowance fee still applies. Re-attestation API.
📌Mint succeeded, intended application action failed: USDC CCTP passes hook metadata; integrators control execution and recovery. Check the application transaction and token holder separately from the transfer. Hooks design.
Successful minting to an unintended account is another category. Re-attestation is not a general address-correction tool, and receipt by the wrong party is not fixed merely by completing more confirmations. Circle’s terms warn that onchain transfers cannot be reversed or recalled by Circle. USDC terms.
CCTP avoids creating a bridge-issued USDC wrapper for its native transfer. The remaining dependencies are still concrete: source-chain confirmation, Circle attestation, destination contracts, transaction submission and correct recipient handling. An application layered above the protocol adds its own responsibilities.
Native status also does not give every holder unconditional direct dollar-redemption access. Circle’s terms make eligibility, account requirements and applicable restrictions relevant; third-party market prices are not guaranteed to stay exactly at $1. Those issuer-level considerations remain after a cross-chain transfer succeeds. USDC terms.
For a pending transfer, the decisive question is: Which step has verifiably completed, and who can perform the next one? That reveals more than a familiar ticker, a successful source transaction or an estimated arrival time.
Related reading: CoinRank’s Sei native USDC launch analysis covers the ecosystem transition; its Noble cross-chain analysis provides Cosmos context. Their historical route counts and timing claims should not replace current protocol documentation.
Looking for the latest scoop and cool insights from CoinRank? Hit up our Twitter and stay in the loop with all our fresh stories!
〈Native USDC vs Bridged USDC: What Actually Happens Between Burn and Mint〉這篇文章最早發佈於《CoinRank》。
