Circle plans to begin phasing out CCTP V1 on October 31, 2026, by reducing legacy burn limits, with its general deprecation timetable completing on December 1. As of this October 27 check, that is an upcoming schedule, not proof that every route has already stopped. The relevant question is whether your application still uses V1 contracts and APIs, rather than whether a token is simply labelled USDC.
The first milestone concerns capacity for new legacy transfers
The dated Circle notice, published August 27, describes declining V1 burn limits ahead of a contract pause. The change is staged. Do not collapse October 31 and December 1 into one shutdown date, and do not infer that a route remains available at unchanged capacity until the later milestone.
This article concerns the upcoming October milestone; it does not redate the original announcement as new October news. Recheck the timetable before acting or publishing it. Chain-specific coverage also needs its own review, rather than treating a general migration headline as a guarantee for every source and destination.
Check which operation you are discussing
| Your situation | Relevant evidence | Question for the application |
|---|---|---|
| A new cross-chain transfer | Current route, version and available capacity | Does this path still initiate a V1 burn? |
| A transfer already initiated | Source transaction and protocol-specific message state | What remains to complete this existing operation? |
| USDC held in a wallet | Network and actual token identity | Does a transfer-protocol change affect my intended route? |
| Recipient account not credited | Destination delivery and service deposit record | Did the destination receive it, and what remains in the service? |
A useful support question is “Which CCTP version handles this route on these two networks?” It is more precise than “Does your app support USDC?” Supporting an asset does not identify the messaging version, contract addresses or endpoint the application actually uses. The application may need an integration update even though the user still sees the same asset name.
V2 is not a label an old integration can simply adopt
The current migration guide documents different contracts, changed interfaces and new API endpoints. That is why replacing a version label in a user interface does not establish compatibility. The application operator needs to verify the actual configuration and implementation, while a retail user needs a confirmed supported route rather than instructions to edit a signed transaction.
Use the current domain and feature table for the chosen endpoints. It distinguishes supported features and separately lists Noble under legacy-only coverage. Do not assume a V2 replacement exists everywhere. This report does not extend the general December date into a complete chain-specific retirement timetable or invent a destination that will remain available.
Existing work and new work need different checks
Circle’s migration guide says the phase-out is designed to preserve pending redemptions while allowances for initiating new activity tighten. That is the issuer’s stated transition design, not independent confirmation that your particular transfer completed. Preserve its source transaction and records and ask the relevant application about the unfinished stage.
If funds arrived on the destination chain but an exchange account remains pending, that is a further accounting boundary. Conversely, a source burn alone does not establish destination receipt. This article does not repeat an attestation-recovery walkthrough, recommend creating a second burn or promise that changing to a V2 endpoint can process an arbitrary legacy message.
- Identify the exact source, destination and token required by the recipient.
- Ask the application which protocol version and contracts actually serve the route.
- Check the current issuer timetable and chain-specific support instead of relying on an old cached page.
- Keep already initiated transfers separate from decisions about new activity.
- After delivery, verify any receiving service’s own credit rather than assuming the protocol version settles that question.
What to watch next
The next event to verify is whether the planned October 31 reductions begin under the published schedule and whether your application has updated its route. No reduction percentage, per-transfer fee or guaranteed completion time is asserted here. A future schedule is not a measurement of the live allowance on a particular chain.
The current protocol is described in Circle’s CCTP documentation. For a separate no-account swap, compare supported assets and follow the actual exchange flow. KOT.CASH is not claimed to use CCTP or any named provider. This notice does not create a new migration address to which every USDC holder must send funds.
FAQ
Does CCTP V1 deprecation require every holder to buy a V2 token?
V1 and V2 here describe the cross-chain integration. Check the actual asset, chain and supported route rather than sending USDC to an invented migration address.
Can a CCTP V1 bridge become V2 just by renaming its interface?
Circle documents different contracts and APIs with breaking changes. The application needs to verify its implementation, not merely its visible label.
Does CCTP V1 vs V2 decide whether my exchange account is credited?
Protocol delivery and internal exchange credit are separate records. Establish destination receipt and then investigate the service’s own unfinished stage.