Circle Opens Its Blockchain Bridge to Third-Party Tokens: CCTP Now Carries Non-USDC ERC-20s Across Seven Networks

Circle has just opened its best-known piece of blockchain plumbing to everybody else's tokens. On October 30, 2026, the company published a developer guide explaining how token issuers can use its Cross-Chain Transfer Protocol (CCTP) to move ERC-20 tokens other than USDC across blockchains. Until now, CCTP was mainly the road USDC itself travelled on. From here, it becomes a shared bridge that other issuers can plug into — with one important condition: the issuer, not Circle, stays in control of the token's rules.

That condition is the whole story. CCTP for non-USDC tokens launched in September 2026, and the October 30 guide is the practical manual for using it. It sets out two routes. A new token can be deployed as a native cross-chain token through Circle's service, built for CCTP from the start. An existing ERC-20 can instead be registered as a custom CCTP connection on each chain in its route. Either way, the transfer runs over Circle's messaging and attestation infrastructure — the same layer that attests USDC burns on a source chain before native USDC is minted on the destination — and the issuer keeps control of the owner, operator, pauser, rate limits and maximum transfer settings. Circle, by its own account, cannot take over those settings.

What actually moves, and how
The mechanics depend on the token. For Circle-issued assets such as USDC, EURC and cirBTC, CCTP uses native burn-and-mint: tokens are burned on the source chain and minted natively on the destination after an off-chain attestation from Circle's Iris service. For third-party assets, the issuer-operated model runs through a CrossChainTokenService and a per-token manager, and the guide also describes lock-and-mint wrapping for permissionlessly wrapped third-party assets. The distinction matters because it decides who bears the risk if something goes wrong: in the issuer-operated model, the issuer's own manager and limits are part of the transfer, not an afterthought bolted on by a bridge operator.

The supported map is deliberately narrow for now. The guide covers seven networks: Ethereum, Avalanche, OP Mainnet, Arbitrum, Base, Polygon PoS and Arc — with Arc starting on testnet, where Circle describes an end-to-end flow in which developers deploy the token, quote Iris, deploy the remote token on a second chain, approve the per-token manager and call the transfer function. Non-EVM chains such as Solana are excluded from these custom token connections today. That is a real limit, not a footnote: a token that lives natively on Solana cannot simply ride this bridge, and any issuer promising otherwise is getting ahead of the documentation.

Why issuers would want this — and what they give up
For a token issuer, the appeal is standardisation. Building a custom bridge for every chain pair means stitching together fragmented infrastructure, inconsistent trust models and a different security review each time. CCTP offers one attestation layer, one message format and a familiar burn-and-mint pattern, with enterprise controls — rate limits, circuit breakers, blocklists, governance and token lifecycle management — that a small team would struggle to build alone. Fees on Arc are paid in USDC, and Circle pitches deterministic finality on Arc as a way to make attestation timing predictable, which matters for settlement use cases where a delayed mint is a failed trade.

The trade-off is dependence. An issuer that adopts CCTP is betting its cross-chain future on Circle's attestation service, its supported-chain list and its fee model, and Circle is explicit that CCTP is non-custodial, transfers are irreversible, fee estimates are non-binding previews, and availability is subject to change. Circle also does not vet, endorse or back third-party assets; those assets carry only their own issuers' terms and risks. In other words, the bridge does not make a token safer — it makes a token portable, and the safety still comes from the issuer's own controls, audits and limits.

The timing: a V1 phase-out and a tokenization race
The guide also lands at a telling moment in Circle's own roadmap. Circle's CCTP V1, the original 2023 version that supported USDC transfers, is due to begin its phase-out on October 31, 2026, with existing integrators directed to a migration guide and new developers told to start with the current docs. The message to builders is unambiguous: build on the current protocol, not the legacy one.

The wider context is a blockchain industry racing to put existing assets on chain rather than invent new ones. The same weeks have brought DTCC and Canton Network toward tokenizing large pools of eligible securities, Securitize extending tokenization to Stellar, and Sony's Soneium chain pivoting to tokenized entertainment royalties. Circle's move is the infrastructure end of that trend: if stocks, funds, Treasuries and royalty streams are all going to live as blockchain records, they will need bridges that do not break when they cross chains — and issuers will want those bridges to leave the controls in their own hands. CCTP's third-party opening is Circle's bid to be that default bridge for EVM-compatible assets.

That bid will be judged on unglamorous things: whether decimals match across chains (the guide requires it), whether rate limits hold under stress, whether the Arc testnet flow survives contact with mainnet, and whether non-EVM support ever arrives. A bridge that works for seven EVM networks and not for Solana is a partial answer, and Circle's own documentation says so. But for ERC-20 issuers that already live inside the EVM world, October 30 is the day their tokens got a standard road across chains — with the keys, the pause button and the speed limits still in their own hands.

Read more on Zimbuck: https://zimbuck.com/pages/zimbucknews and join the discussion at https://zimbuck.com/groups/zimbuckmarketnews . Related reading on the site: https://zimbuck.com/blogs/539/Initia-s-Blockchain-Restart-Audited-MoveVM-Patch-No-Rollback-and

FAQ
What did Circle publish on October 30, 2026? A developer guide explaining how token issuers can use its Cross-Chain Transfer Protocol (CCTP) to transfer ERC-20 tokens other than USDC across chains.
Which networks are supported? Seven: Ethereum, Avalanche, OP Mainnet, Arbitrum, Base, Polygon PoS and Arc (starting on Arc testnet). Non-EVM chains such as Solana are excluded from custom token connections.
What are the two routes for issuers? Deploy a new native cross-chain token built for CCTP from the start, or register an existing ERC-20 as a custom CCTP connection on each chain in its route.
Who controls the token's rules? The issuer — owner, operator, pauser, rate limits and maximum transfer settings stay with the issuer; Circle says it cannot take over those settings.
How do transfers work? Circle-issued assets use native burn-and-mint with off-chain attestation; issuer-operated third-party transfers run through a CrossChainTokenService and per-token manager, and permissionless wrapping uses lock-and-mint.
Is CCTP custodial, and can transfers be reversed? No — Circle says CCTP is non-custodial and transfers are irreversible, and fee estimates are non-binding previews.
What happens to CCTP V1? The original 2023 version begins its phase-out on October 31, 2026; existing integrators should use the migration guide and new developers should start with the current docs.
Does this make a third-party token safer? No — Circle does not vet, endorse or back third-party assets; the bridge makes a token portable, while safety still depends on the issuer's own controls.

This article is market news and general information only, not financial advice.