Circle publishes CCTP guidance for non-USDC ERC-20 cross-chain transfers

3 min

TL;DR: Circle published technical guidance that extends its Cross-Chain Transfer Protocol to issuer-controlled ERC-20s beyond USDC. The Arc example is a testnet walkthrough. The guide explains how to configure token identity and burn-and-mint flows across supported networks, without promising universal production support.

Scope and intent

Circle released an October 30 developer guide that shows how the message and attestation infrastructure behind CCTP can support issuer-operated ERC-20 assets beyond USDC. The guide covers native deployment or configuration of an existing custom token and includes an example using Arc Testnet with another supported EVM network.

USDC transfers under CCTP use burn on the source network and mint native supply on the destination after a verified message. Circle describes an analogous route for other issuer-controlled ERC-20s through CrossChainTokenService and a token manager. The model maintains a common token identity across chains instead of treating wrapped bridge tokens as separate economic instruments.

Mechanics and attestation flow

Issuer-controlled tokenisation faces fragmentation across chains: liquidity, identity and accounting can diverge. A controlled burn-and-mint model keeps a single economic supply while enabling presence on multiple networks. This affects payments, collateral management and treasury rebalancing. It does not guarantee support across every chain.

For investors: interoperability is infrastructure. Easier movement between venues does not alter cash flows, supply rights or governance. The commercial outcome depends on whether regulated issuers adopt the tooling for real assets and payments, and whether those flows justify the costs and risks of the transfer mechanism. Circle has published implementation guidance without forecasting adoption.

Trust boundaries and roles

Process: the source contract burns the transfer amount and emits a message. Circle’s Iris service attests the message. The destination contract receives the attestation and mints the corresponding supply. Operators configure roles, caps, rate limits, trusted domains and ownership. The transfer path and services differ from the USDC TokenMessengerV2 route. Developers must select the correct contracts and calculate fees for a specific route.

Circle states it is not the issuer or guarantor of third-party tokens. Developers are responsible for token permissions, legal obligations and transfer risks. Arc Testnet examples are not production deployments.

Testing and adoption considerations

Required tests before moving material value: domain trust configuration, fee paths, rate-limit behaviour, decimal consistency and failure recovery. The adoption question: can issuers reduce fragmented bridge operations without concentrating unacceptable risk in attestations, administrative roles or third-party services.

Institutions may use public, private or hybrid networks. Each choice sets different expectations for access, settlement finality and oversight. Interoperability aims to connect these environments without assuming identical rules.

Primary source: Circle primary disclosure. Statements and figures are attributed to the organisation providing them. Source dates appear in the article metadata.