CCTP transfers native USDC rather than wrapped tokens
A user or application burns native USDC through a Circle contract on the source network. Circle’s attestation service confirms the message, and the destination contract mints the corresponding amount of native USDC.

This design avoids maintaining a separate pool of wrapped tokens. It also means an integration depends on the correct contracts, message format and attestation endpoint for the version being used.
V2 support is not identical on every network
Circle lists 27 supported blockchains for CCTP V2 at the start of this migration window, but feature support and migration timing differ. The official network matrix shows which transfer modes and finality options are available on each chain.
The practical migration work includes updating contract addresses, SDK or API calls, event handling and tests. A partial update can leave an application watching the wrong contract even when the user interface appears unchanged.
| Migration area | Required check |
|---|---|
| Contracts | Use the V2 addresses for each supported network |
| API and SDK | Update endpoints, message format and dependencies |
| Pending V1 transfers | Keep redemption available until initiated messages settle |
| Noble exception | Relevant V1 support continues until 12 January 2027 |
| Validation | Test burn, attestation and mint in both directions |
Transfers already initiated under V1 can still finish
Circle’s guidance allows messages that were started before a migration deadline to complete through their existing route. Integrators should keep the required V1 redemption path available long enough to settle pending activity.
Noble is the stated exception to the general schedule, with its relevant V1 support continuing until 12 January 2027. Other networks follow their own dates in Circle’s current migration documentation.

Applications need monitoring as well as new addresses
Teams should test small transfers in both directions, verify the burn and mint events and confirm that failed attestations can be retried without creating duplicate actions. Status pages and user messages also need to distinguish waiting from a permanent failure.
The safest approach is a network-by-network migration with documented rollback steps. CCTP V2 can reduce friction, but only after the application has replaced every version-specific dependency rather than changing a single visible label.
This article is for information only and is not investment advice.




