How to bridge USDC to Circle's Arc: CCTP, Gateway and the steps

Here is the sequence, then the detail behind each choice.

The steps

1. Decide whether you are moving a balance or building a habit. A one-off transfer is a CCTP job. If you will be pulling USDC onto Arc repeatedly from several chains, Gateway's unified balance is the design that fits, and it is worth the extra integration work up front.
2. Get USDC on a source chain you already use. CCTP moves USDC between chains; it does not create it. If you are starting from fiat, that is an on-ramp problem, covered further down.
3. Confirm the Arc destination values before you touch anything. Mainnet: chain ID 5042 (0x13b2), RPC https://rpc.mainnet.arc.io, explorer https://explorer.arc.io. Testnet: chain ID 5042002, RPC https://rpc.testnet.arc.io. Verify against docs.arc.io, never from a post, an ad or a search result.
4. Execute the transfer through Circle's own interface or SDK, not a third-party front end you found while searching. The burn on the source chain, the attestation, and the mint on Arc are three steps of one operation; let Circle's tooling sequence them.
5. Wait for attestation, then verify the mint on the official explorer. Arc targets sub-second finality, so inbound CCTP transfers can reach attestation faster than transfers into chains needing several block confirmations. The transfer is not done when the burn confirms; it is done when the mint lands.
6. Fund gas separately, in your head. Gas on Arc is paid in USDC, so the balance you just bridged is also the balance that pays to move it. Bridge more than you intend to spend, and keep a floor in the account — a wallet at zero USDC on Arc cannot transact at all, it does not degrade gracefully.
7. Test with a small amount first, every time you change anything — a new endpoint, a new wallet, a new source chain. The cost of a test transfer is a rounding error against the cost of finding out that a value was wrong.

CCTP, in plain terms

CCTP is Circle's Cross-Chain Transfer Protocol, and Arc's own developer documentation confirms native support with Arc assigned its own CCTP domain. The mechanism is burn-and-mint: the USDC you send is destroyed on the source chain, Circle attests to that, and native USDC is minted for you on Arc.

Why that distinction matters more on Arc than on a general-purpose chain: the older bridge design locks an asset on one side and mints a synthetic representation on the other, which introduces a dependency on the bridge contract staying solvent and uncompromised, and leaves you holding a token that some contracts on the destination chain will not recognise or price correctly. Arc exists to settle stablecoins. USDC that arrives by native mint is the same asset every Arc-native contract expects; a wrapped stand-in would not be. That is a structural reason to prefer the canonical route here, not a preference.

Arc's CCTP domain is 26. Mainnet contract addresses: TokenMessenger 0x28b5a0e9C621a5BadaA536219b3a228C8168cf5d, MessageTransmitter 0x81D40F21F12A8F0E3252Bccb954D722d4c464B64.

Gateway, which is not a bridge

Circle Gateway is a unified-balance product rather than a cross-chain messaging protocol. You deposit USDC once and can then access that balance's liquidity across supported chains without a separate bridge-and-wait cycle each time you need funds somewhere new. Circle and Arc have published joint developer material on combining CCTP and Gateway to consolidate cross-chain USDC into Arc, including a Unified Balance Kit that exposes the whole thing through one integration.

Pick between them on this basis. CCTP is the right answer when you know where the money needs to be and want it there. Gateway is the right answer when you do not know in advance, and the cost of guessing wrong — capital stranded on the wrong chain — is the thing you are trying to eliminate. Treasury operations and multi-chain applications usually want the second; a person moving a balance wants the first.

Fiat on-ramps are a separate problem

Getting from a bank account or card to USDC is a different piece of plumbing from moving USDC between chains, and it is worth naming as its own step because it is usually the slow one. In practice most routes onto Arc will run through an exchange you already hold an account with, or through a business on-ramp with KYB already completed, and then bridge. Crossmint has announced an Arc partnership covering on-ramps alongside wallet and checkout tooling. Kraken and Upbit are named in Circle's August 2026 release for USDC access, though exchange-side Arc deposit and withdrawal support varies by exchange — check your exchange's own withdrawal screen for an Arc network option.

For which bridges and on-ramps are live today, see Arc bridges and on-ramps status, which tracks each provider against whether it has published Arc-specific technical detail rather than a partnership announcement.

The mistake to avoid

Every chain launch produces a crop of fake bridge front-ends, and Arc is no exception. A site that looks like a bridge, appears in a search ad, and asks for a token approval is the standard shape of the problem.

Two rules cover almost all of it. Reach Circle's tooling by typing the address, not by clicking a result. And treat any URL claiming to be the Arc mainnet RPC or explorer that you have not verified on docs.arc.io as hostile.

What CCTP on mainnet means in practice

CCTP moves real value on Arc mainnet today, not testnet USDC. Gateway's unified balance is a live capital-efficiency tool. Any third-party bridge claiming to support Arc should be able to point you to a mainnet contract address you can verify on the Arc explorer — treat a bridge that cannot as part of the conversation rather than part of the infrastructure.