TL;DR: Circle published technical guidance for issuer-controlled ERC-20 transfers using CCTP infrastructure beyond USDC. Its Arc demonstration is a testnet walkthrough, not a promise of universal production support.
Circle’s developer guidance on non-USDC Cross-Chain Transfer Protocol transfers exposes a core design problem in tokenization: how an issuer can preserve one economic asset identity when its onchain supply appears on several networks. The documented approach combines controlled burning, attestation and destination minting.
How the attestation flow works
The source contract burns the amount to be transferred and emits a message; Circle’s Iris service attests the message; a destination contract receives the attestation and mints the corresponding supply. Operators configure roles, caps, rate limits, trusted domains and ownership. The transfer and service details differ from USDC’s familiar TokenMessengerV2 path, and a developer must confirm the correct contracts and quote fees for a specific route.
Circle published an October 30 developer guide explaining how the message and attestation infrastructure behind Cross-Chain Transfer Protocol can support issuer-operated ERC-20 assets beyond USDC. The guide walks through native deployment or configuration of an existing custom token, including an example using Arc Testnet and another supported EVM network.
Moving non-USDC tokens
For USDC, CCTP is associated with burning tokens on a source network and minting native USDC on a destination after a verified message. Circle says an analogous route exists for other issuer-operated ERC-20s through CrossChainTokenService and an associated token manager. The guide describes a common token identity across chains, rather than treating a wrapped bridge token as an entirely separate economic instrument.
Token identity is a bookkeeping challenge as much as a transport challenge. Two contracts can represent the same economic asset on different chains only if the issuer and infrastructure enforce coherent supply, ownership and redemption rules. Circle’s described burn-and-mint model addresses one aspect of that problem by requiring an attested message before destination minting. It does not remove the possibility of misconfiguration, contract failure or a dispute over the underlying legal asset.
Where the trust boundaries sit
Issuer-controlled tokenisation faces a fragmentation problem: a digital asset represented separately on several chains can have inconsistent liquidity, identity and accounting. A controlled burn-and-mint model offers one way to keep the economic asset coherent while letting it appear where different applications operate. This matters for payments, collateral management and treasury rebalancing, although it does not guarantee universal chain support.
The primary source is a technical guide, not a statement that every ERC-20 can immediately move across every network in production. Arc Testnet examples must not be confused with deployment on a production system. Circle says it is not the issuer or guarantor of third-party tokens, and developers remain responsible for their own token permissions, legal obligations and transfer risks.
Tests before production
Developers evaluating the approach should test domain trust configuration, fees, rate-limit behaviour, decimal consistency and failure recovery before transferring material value. The adoption question is whether issuers can reduce fragmented bridge operations without concentrating unacceptable risk in attestations, administrative roles or third-party services.
Institutions may use public, private or hybrid networks, and each choice creates different expectations about access, settlement finality and oversight. Interoperability attempts to connect those environments without pretending they have identical rules.
Primary source: Circle primary disclosure. Statements and figures are attributed to the organisation providing them; source dates are noted in the article metadata.
This article was written by the News Desk and edited by Samuel Rae.
Leave a Reply