Circle details custom-token crosschain transfers on Arc
Circle’s developer guidance explains how issuers can connect their own ERC-20 tokens to crosschain transfers through Arc’s CrossChainTokenService, using Circle’s verification infrastructure. This setup differs from the standard USDC flow. Issuers remain responsible for permissions, limits and operational risks.
- Issuers can deploy a new CrossChainToken or register an existing issuer-controlled ERC-20.
- Transfers burn tokens on the source chain and mint them on the destination after verification.
- Each route needs chain-specific configuration, permissions and transfer limits.
- Circle’s Forwarding Service can handle delivery on the destination chain for an additional service charge.
Custom tokens use a different transfer path from USDC
Circle describes two ways for issuers to use its crosschain infrastructure with their own tokens. They can deploy a new CrossChainToken through Arc’s CrossChainTokenService, or register an existing ERC-20 without replacing its original contract.
The difference between this process and standard USDC transfers matters. For third-party assets, Circle identifies CrossChainTokenService and an individual token manager as the components that manage transfers. Standard USDC transfers use TokenMessengerV2. Developers should confirm which contracts and routes their token requires rather than assume the USDC integration applies unchanged.
ERC-20 is a common token standard used on Ethereum-compatible blockchains. For the issuer-controlled setup Circle describes, the issuer must configure permissions and the token’s burn-and-mint behavior. Circle also describes a separate setup for tokens whose issuers do not control their contracts, but says it does not use the same burn-and-mint mechanism. The guidance does not explain that alternative in detail.
How the burn-and-mint transfer works
In this flow, tokens are burned on the source blockchain. Circle’s Iris service verifies the transaction and produces an attestation, a verification result that the destination network uses to authorize minting the corresponding amount.
Each blockchain has its own token contract and balances. The networks coordinate transfers through a shared token identity, rather than drawing from one contract with a single balance across all chains. Circle says a newly deployed token’s identity is based on the deployer’s wallet address and a selected salt value. Developers need the relevant deployment details to configure the token on another supported chain.
This differs from locking tokens on one blockchain and issuing a wrapped version on another. But issuers still need to assess the system’s dependencies. Transfers rely on correct token configuration, the token manager and Iris verification. Circle’s guidance offers no independent security assessment or detailed instructions for handling failed verification or delivery.
Issuers control permissions, and carry the responsibility
Registering a token involves more than listing it on a bridge. Issuers must configure it on every blockchain in a route, including its permissions and burn-and-mint settings. Circle also says the tokens must have compatible decimals across networks and the services handling transfers must trust each other. The guidance does not explain what that trust requirement means in practice.
Issuers assign ownership, operator and pauser roles, set transaction limits and choose the maximum transferable amount. They can configure limits during deployment or later through the token manager. Circle’s walkthrough warns that a limit set to zero prevents transfers.
These controls give issuers flexibility, but configuration also affects security and availability. Incorrect roles, limits or contract addresses can block transfers or compromise token management. Circle recommends reviewing these settings before production deployment. Issuers remain responsible for the tokens they create and for the regulatory requirements that apply to their services.
Testnet setup, fees and delivery
Circle’s walkthrough shows how to deploy a token on Arc Testnet and connect it to another supported EVM blockchain. Developers need a reusable deployer address, token details and Arc Testnet USDC to cover transaction and service fees. After minting the initial supply, they approve the token manager and submit a crossChainTransfer transaction. The destination contract mints the tokens once it receives the required attestation.
Circle’s Forwarding Service can deliver tokens on the destination chain without requiring the recipient to pay gas there, as long as the applicable service charge is included in the initial quote. Circle says recipients receive the full token amount when fees are paid separately. Charges vary by blockchain pair and the quote obtained before execution. Circle does not provide a universal fee figure. Developers adding a route should get a fresh Iris fee quote.
The walkthrough demonstrates a testnet setup, not a complete list of custom-token routes ready for production. Issuers should confirm route availability and contract addresses for their intended chains before deploying or transferring significant value.
Where custom-token transfers may fit
Circle points to potential uses in payments, collateral, tokenized real-world assets and treasury operations across networks. For example, an issuer could configure a token to move between two supported chains without relying on a locked balance and wrapped copy. Whether that works in practice depends on route availability, costs, contract configuration and the issuer’s ability to manage the system safely.
The guidance leaves key operational details unanswered, including exact fees, maximum transfer amounts, the governance and technical details of Iris verification, and what happens when a transfer fails. These are not minor details. Issuers should understand how each route works and who handles problems before moving significant value through it.
Key questions about custom-token transfers
-
Can an issuer use an existing ERC-20?
Yes. Circle describes registering an existing token without replacing its contract, provided the issuer can configure the required permissions and burn-and-mint behavior.
-
Is the custom-token flow the same as USDC’s?
No. Circle identifies CrossChainTokenService and a token manager for third-party assets. Standard USDC transfers use TokenMessengerV2.
-
What should issuers check before a transfer?
Confirm the route is supported, review token roles and limits, verify contract addresses and get a current Iris fee quote. A zero transfer limit prevents transfers.
-
Can recipients avoid paying destination gas?
Circle’s Forwarding Service can handle delivery without the recipient paying destination gas, if its service charge is included in the initial quote.
-
Does every chain use one shared token contract?
No. Each chain has its own token contract and balances, coordinated through a shared token identity.
