Which route into Arc should you actually use?

Arc's native asset is USDC, and USDC has an issuer. That one fact reorders the usual bridge comparison, because Arc has a canonical path where Circle burns USDC on the source chain and mints the same USDC on Arc, rather than a bridge minting a claim against collateral held elsewhere. This page compares that path against third-party bridges and against not bridging at all. The walkthrough is at [/arc/bridge-usdc-to-arc](/arc/bridge-usdc-to-arc); this is the decision before it.

This page covers Arc in its first weeks of mainnet. Which third parties route to Arc is changing week by week, so where the picture is still settling we say so and point at the source of truth rather than publish a list that will be wrong by the time you read it. Last reviewed: September 2026.

What is the lowest-trust route into Arc?

The lowest-trust route into Arc is Circle's own burn-and-mint path, its Cross-Chain Transfer Protocol (CCTP), because the USDC that arrives on Arc is issued by Circle rather than minted by a third-party bridge against collateral held elsewhere. Third-party bridges cover more assets and more routes. Withdrawing directly from an exchange skips bridging entirely. Arc mainnet went live on September 16, 2026, and Circle's and Arc's documentation describe the CCTP path as canonical; the third-party and exchange routes are filling in on their own schedules and should be checked with the provider first.

These are not three prices for one product. They have different failure modes, and the right answer depends less on fees than on what you accept exposure to while your value sits in transit or in wrapped form.

Why does the issuer matter more on Arc than on other chains?

Because on Arc, USDC is the gas token. Arc is a Layer-1 built by Circle where fees are paid in USDC, carried at 18 decimals at the protocol level rather than the 6 decimals ERC-20 USDC uses elsewhere, so the asset you bridge in also pays for every transaction you send afterwards. On Ethereum you can hold three competing wrapped versions of a token and treat the mess as a liquidity problem; on Arc, an asset that is a bridge's IOU rather than Circle-issued USDC is not the gas asset, and no amount of liquidity fixes that. The decimals difference is its own trap; /arc/usdc-18-decimals covers it, and /arc/gas-fees covers how fees are quoted.

How does a burn-and-mint bridge differ from lock-and-mint?

A burn-and-mint bridge destroys the asset on the source chain and issues a new unit of the same asset on the destination, so supply across chains stays constant and no pool of collateral sits anywhere waiting to be stolen. A lock-and-mint bridge locks your asset in a contract on the source chain and mints a claim token on the destination, and bridges holding pooled collateral have been the most costly category of failure in crypto's public loss record.

CCTP is the burn-and-mint mechanism here. Per Circle's CCTP documentation it runs in three steps: depositForBurn on the source chain's TokenMessenger burns your USDC and emits a message; Circle's off-chain attestation service, Iris, signs that message once the source chain reaches the required finality; the signed message goes to receiveMessage on the destination, which mints the equivalent USDC. Circle addresses chains as numbered domains rather than by chain ID, so confirm Arc's domain against Circle's supported-domains reference before hardcoding it — a wrong domain sends value to the wrong chain. CCTP V2, the version Arc's documentation describes as in use, adds a Fast Transfer mode attesting at a lower "confirmed" threshold instead of full finality, plus hooks that attach calldata to a burn message so the destination executes logic in the same flow as the mint.

You still depend on Circle: Iris must be running for the mint leg to complete, and a stall means funds burned on one side and not yet minted on the other until service resumes. Attestations come from a Circle-controlled attester set, so key compromise is the tail risk in place of a collateral pool — a liveness and key-custody dependency on a regulated issuer, not custody exposure to an anonymous contract.

What do third-party bridges give you that CCTP does not?

Third-party bridges give you asset coverage, routing and packaging: they move things that are not USDC, aggregate several underlying paths, and deliver in one transaction from the user's perspective. What you pay is an extra set of contracts, an extra operator, and in liquidity-network designs a dependency on someone's inventory being available when you arrive. Quoted fees and realised cost diverge here, because a thin destination pool shows up as slippage rather than a fee line.

The names fall into two groups, and which group a bridge belongs to tells you more than its fee quote. The first verifies messages with an external validator set: Wormhole uses a fixed nineteen-node Guardian set, thirteen of which must sign; Axelar, which powers the Squid routing front-end, runs a proof-of-stake validator network that co-signs with threshold signatures; LayerZero, which Stargate is built on, lets each application pick its own verifier networks and threshold, making security a per-deployment configuration rather than a protocol constant; Hyperlane goes furthest, with pluggable security modules the deploying team defines outright.

The second group has someone front your value rather than hold it in transit. Across is intent-based: a relayer pays you on the destination out of its own capital immediately, then claims repayment from hub pools on Ethereum with UMA's optimistic oracle adjudicating, so the relayer carries the settlement risk. deBridge works the same way with no shared pools at all — competitive solvers fill each order individually, and an unfilled order can be cancelled and reclaimed.

Which of these route to Arc, and whether each delivers Circle-issued USDC or a wrapper, is what is still moving in Arc's first weeks, so we publish no support matrix that would be stale within days. Check the bridge's supported-networks page, then the address of the token you receive. "Supports Arc" in marketing can mean the route exists, that a wrapper exists, or that a listing is planned.

Is withdrawing from an exchange a bridge?

No, and that is the point. When you withdraw USDC from a centralised exchange directly to an Arc address, the exchange settles on its own books and pays out from its Arc-side balance. No bridge contract is involved, so no bridge contract can fail with your money in it.

Circle named Kraken, Upbit and Binance Wallet among the venues supporting Arc at launch. Being named as an ecosystem partner and offering a withdrawal network you can select are different things, and in a chain's first weeks the second lags the first. The check takes thirty seconds: open the USDC withdrawal screen on your exchange and look at the network dropdown. If Arc is not in it, no amount of announcement coverage puts it there. The trade-off is otherwise obvious: you trust a custodian, and withdrawals can be paused for reasons unrelated to you. For a treasury funding an Arc address monthly that is often the cheapest route; for programmatic settlement it is not a route at all.

How do you compare two bridges in five minutes?

Ask six questions: who mints the asset I receive; what happens if the operator stops running tomorrow; is the destination asset canonical or a wrapper; how do I have gas on arrival; what is the refund path on a stuck transfer; and how long has this contract been live with how much value through it. Audits and bug bounties are a hygiene floor, not an answer.

Then verify what landed by reading the token contract, not the interface that sent you. Arc's mainnet RPC endpoint is not yet published, so the commands below carry MAINNET-TBD; substitute Circle's published value, from Circle's own documentation.

# Substitute Circle's published mainnet RPC endpoint for MAINNET-TBD.
cast call <TOKEN_ADDRESS> "symbol()(string)"   --rpc-url MAINNET-TBD
cast call <TOKEN_ADDRESS> "decimals()(uint8)"  --rpc-url MAINNET-TBD
cast call <TOKEN_ADDRESS> "totalSupply()(uint256)" --rpc-url MAINNET-TBD

A symbol reading "USDC" proves nothing; any contract can claim it. Check the address character by character against Circle's published Arc contract-address reference before treating the balance as spendable, and confirm decimals() matches what your integration expects. On the explorer you compare the same two fields — contract address in the header, decimals in the token details. The name and logo prove nothing; whoever registered the token supplied them.

What actually goes wrong?

Four failures account for most losses, none exotic. Sending to the right address on the wrong chain, unrecoverable through the interface that caused it. Accepting a wrapped representation while believing it is canonical, discovered at the moment of exit. Assuming 6 decimals in integration code against an 18-decimal native balance, an accounting error rather than a theft but just as expensive to unwind. And approving an unlimited allowance to a bridge router, which turns a one-off transfer into a standing claim on your wallet. A fifth is social: a search result pointing at a bridge front-end that is not the real one. /arc/usdc-across-chains covers how the same asset is represented differently across networks, which is the confusion these attacks feed on.

Is CCTP always cheaper than a third-party bridge?

No. Cost depends on gas prices on both chains and on the fee model of the route you take, and a liquidity-network bridge can be cheaper on a busy day. Cost is also the wrong first question: the routes differ in what they expose you to, which for size matters far more than a few basis points.

Can I bridge assets other than USDC to Arc?

Circle's own path moves USDC and Circle's other issued stablecoins, so anything else needs a third party, and non-USDC coverage into Arc is still filling in weeks after mainnet. Check the bridge's supported-assets page for Arc specifically; coverage is usually added route by route rather than all at once.

How do I pay gas when I arrive with an empty wallet?

On Arc, gas is paid in USDC, so the asset you bridged in is the asset that pays fees, which removes the usual problem of arriving with tokens but no native coin. At a testnet average of about $0.004 per transaction as of August 2026, the buffer required is small.

Does the route I choose affect whether my token is canonical on Arc?

Yes. If you are bringing a token that already exists elsewhere, the representation you end up with on Arc determines how supply is accounted for across chains. /arc/multichain-expansion covers that decision.

Is there a way to avoid bridging entirely?

Yes: withdraw from an exchange that supports Arc directly, or receive USDC from a counterparty already on Arc. Neither involves a bridge contract.