Make Your Token Interoperable with CCTP

Applications settle, post collateral, and show balances on a specific chain. If your ERC-20 only exists where you minted it, every other venue needs a one-off bridge, a wrapped copy, or a manual ops process. Interoperability means the same economic asset can move to the chain where the application actually runs, under one bridge identity integrators can rely on.

Arc is built for applications that move value, with fees in USDC and deterministic finality that keeps CCTP attestation timing predictable. Issue or hold inventory there, then move the same economic asset when settlement, collateral, or rebalancing needs another supported EVM chain.

CCTP (Cross-Chain Transfer Protocol) is Circle’s crosschain trust layer for that movement. For USDC, the familiar path is burn on the source chain and mint of native USDC on the destination. The same message and attestation infrastructure now supports other ERC-20s.

For issuer-operated tokens you have two options: deploy a native CrossChainToken through the service, or configure an ERC-20 you already control as a custom CCTP connection. Both reuse Circle’s message and attestation layer and both use the same transfer call shape.

How CCTP burn-and-mint works

CCTP moves value by burning on the source and minting on the destination against an attested message.

1. Source burns and emits a message.
2. Iris attests the message.
3. Destination mints when MessageTransmitterV2 receives the message and attestation, and you submit receiveMessage, or Iris FORWARD does it when you include that in the fee quote.

For non-USDC assets, that path runs through CrossChainTokenService and a per-token manager, not depositForBurn on TokenMessengerV2.

Native vs. custom CCTP tokens on Arc

Both paths assume you issue or operate the token (RWA, issuer stable, similar). For tokens that you do not operate, there is also a path for ownerless configuration, but it does not use burn-and-mint. You can refer to the developer documentation for ownerless vs custom to learn more.

Custom configuration (issuer-operated). For an ERC-20 you issue or operate (RWA, issuer stable, similar), configure it on every chain in the route with burn-and-mint (BURN_MINT). You set the owner, operator, pauser, rate limits, and max transfer. Circle cannot assume control.

Native. The service deploys the ERC-20 and manager for you (CREATE3). Shared tokenId comes from deployer wallet + salt. Transfers are burn-and-mint. You still set rate limit and max transfer (at deploy in tokenManagerSettings, or later on the manager).

After the token is live on source and destination, both services must trust each other (isTrustedDomain). Then:

1. resolveTokenManager(tokenId)
2. Approve that manager (not the service)
3. Iris quote — check feeTotalAmount
4. crossChainTransfer on CrossChainTokenService (fee in source native; recipient gets the full amount)
5. Destination receiveMessage, or FORWARD in the quote

Decimals must match across chains. Configure steps for custom: Configure a custom token.

Native on Arc Testnet, end to end

To work the end-to-end flow, you need a deployer address you will reuse on every supported blockchain you want coverage on and Arc Testnet USDC for gas and Iris fees. Pick your token name, symbol, decimals, and a salt; those inputs, and the deployer address will define a single tokenId. Each chain still gets its own token contract and balances; CCTP routes against the shared id.

Call deployCrossChainToken on Arc’s CrossChainTokenService. The CREATE3 service deploys the token and its per-token manager. Transfer limits should be set in the deploy params so the managers are not left at zero (zero blocks transfers).

You can read the tokenId from the deploy receipt, then quote Iris and call deployRemoteCrossChainToken from Arc so the same identity appears on the second chain. Make use of Circle's forwarding service by including FORWARD in the quote if you want Circle to complete delivery without destination gas. Check the live fee before you send as quotes differ by pair.

Once the token contracts are deployed, you will want to mint supply on Arc. To run a crosschain transfer, approve the per-token manager, quote a transfer (again with FORWARD if you want), and call crossChainTransfer. When the destination balance updates, you can be sure the route works.

Addresses, ABI quirks, and exact parameters live in the crosschain ERC-20 deployment quickstart. Confirm the Arc Testnet service address on the contract addresses page before you ship.

What's next: Move from Arc testnet to production

With the route live, applications built on Arc can settle payments, post collateral, and show balances on Arc, and move the same economic asset to another supported EVM chain when rebalancing or a venue there needs it, under one bridge identity.

Wire those flows into your application, extend the identity to any other domain you need (re-quote Iris each time), and tighten caps and roles before mainnet. Configuring an existing ERC-20 instead of native? Start with the custom token quickstart. Also check out the developer documentation for all the details about CCTP for non-USDC assets.

‍

_{Arc mainnet is an open L1 blockchain launched and offered by Arc Network Services LLC (“Arc LLC”) and operated by a permissioned validator set. Arc testnet is offered by Circle Technology Services, LLC (“CTS”). Arc LLC and CTS are software providers only and do not provide regulated financial or advisory services. Neither the Arc mainnet nor testnet has been reviewed or approved by the New York State Department of Financial Services or any other regulatory authority.}

_{The Arc network is provided “as is” and “as available.” Use of Arc involves inherent risks associated with blockchain technology, including smart contract vulnerabilities, network disruptions, and the absence of recourse for transaction errors or losses. The ability to transact on Arc depends on the ability to obtain and use USDC to pay gas fees. Neither Arc LLC nor any permissioned validator is responsible for the content, accuracy, legality, or functionality of third-party applications, protocols, or services built on or integrated with Arc.}

_{You are solely responsible for any features or services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws. All Arc features may be modified, delayed, or cancelled at any time without notice and, where applicable, at the sole discretion of Arc LLC or CTS. Nothing herein constitutes a commitment, warranty, guarantee, or legal, regulatory, tax, or investment advice.}

_{CCTP is a crosschain messaging infrastructure service provided by Circle Technology Services, LLC ("CTS"). CCTP is non-custodial; CTS does not hold, control, manage, or transfer user assets or act as a transfer agent, registrar, broker-dealer, investment adviser, or clearing agency. CCTP is not a financial, payment, or advisory service and has not been reviewed or approved by NYDFS or any other regulatory authority. Transfers are irreversible; CTS cannot recover assets sent to an incorrect address. CTS does not vet, endorse, or back third-party assets; such assets are subject solely to the applicable third-party terms and risks. Issuers are solely responsible for their services and compliance with applicable laws. Any fee estimates are non-binding previews; actual fees may differ. Assets are subject to a number of risks, including, but not limited to, price volatility and smart-contract, relay, and bridge vulnerabilities. Availability is subject to change. Developer terms apply.}