Arbitrumbridge

Arbitrumbridge USDC requirements for native transfers through CCTP

Arbitrumbridge USDC transfers through CCTP require Circle-issued native USDC on the source chain. CCTP, short for Cross-Chain Transfer Protocol, links a source-chain burn to a destination-chain mint, delivering native USDC between Ethereum and Arbitrum One. The canonical bridge offers USDC.e, backed by Ethereum USDC held in bridge contracts. Selecting the receiving token determines the transfer mechanism and completion conditions. Gas and applicable service fees also affect the transfer budget.

Last updated ยท
The receiving application's accepted token determines whether native USDC through CCTP or bridged USDC.e matches the intended deposit on Arbitrum One.

USDC contracts and the components that move balances

USDC is an ERC-20 token on Ethereum and Arbitrum One, with separate contracts recording each chain's balances and CCTP transfer contracts coordinating supply changes. The token contract records ownership, while the transfer contracts handle crosschain messages and issuance.

Native USDC on each chain

Circle issues native USDC directly on Ethereum and Arbitrum One, with separate token contracts and balance records on each network. An Ethereum balance therefore does not also appear as spendable USDC on Arbitrum One. ERC-20 is the token interface that applications use to read balances and request transfers. Native issuance describes the token's origin; it does not make USDC the network's gas currency.

CCTP V2 contract responsibilities

In CCTP V2, TokenMessengerV2 is the transfer entrypoint and TokenMinterV2 performs USDC burning and minting. MessageTransmitterV2 carries crosschain messages and checks attestations when receiving them on the destination chain. An attestation is Circle's signed confirmation of a message. These contracts have different jobs, even when an interface presents one transfer action. The interface determines which protocol version and optional services it integrates.

CCTP V1 (Legacy) supports only Standard Transfer. Circle plans to reduce V1 burn limits from October 31, 2026, and pause V1 contracts on December 1, 2026, stopping V1 transfers. V2 uses different contract addresses and interfaces, so legacy integration settings require an update.

How does CCTP move native USDC between Ethereum and Arbitrum One?

CCTP transfers native USDC between Ethereum and Arbitrum One through a burn-and-mint mechanism. Burning removes the source tokens from circulation, and minting creates destination tokens under the authenticated message's conditions, including applicable fees. The burn message records the destination chain, token recipient, and burned amount. This relationship lets the destination contracts handle the corresponding issuance without a pool of pre-positioned bridge liquidity.

Visual summary: Arbitrumbridge USDC - How does CCTP move native USDC between Ethereum and Arbitrum One?

View image file

Iris, Circle's attestation service, signs the message after the required source confirmation, and the destination MessageTransmitterV2 verifies it before passing it to token-handling contracts. The recorded token recipient determines who receives native USDC, while the account broadcasting destination execution may be a different address. A valid attestation connects those actions to the same source message, preventing an arbitrary transaction from authorizing the mint. MessageTransmitterV2 also accepts each message only once, using its unique identifier, called a nonce, to prevent repeat minting.

What determines the timing and cost of a CCTP transfer?

Source-chain confirmation requirements set the attestation wait, while transaction gas, the selected transfer mode, and any forwarding service determine the cost. Gas charges and fees deducted from USDC affect different balances.

Standard Transfer and Fast Transfer

CCTP V2 Standard Transfer waits for hard finality, when a chain reorganization is unlikely to reverse the burn. For Ethereum and Arbitrum sources, typical standard attestation time is about 15-19 minutes. Fast Transfer permits earlier attestation when Circle's global allowance has capacity for the burn amount. The allowance limits USDC minted before the corresponding burns reach hard finality. If capacity is insufficient, wait for replenishment or choose Standard Transfer. Typical fast attestation times are about 20 seconds from Ethereum and eight seconds from Arbitrum. These estimates describe attestation availability; destination execution and application processing add to the full transfer time.

Gas and destination execution

Onchain token approval, the burn, and destination execution use ETH for gas on Ethereum and Arbitrum One. With a self-managed CCTP transfer, the account submitting the destination mint needs destination gas. An integration using Circle's Forwarding Service can cover that execution through its forwarding fee. The service submits the mint when the transfer requests forwarding through a supported configuration.

Fees and the received amount

CCTP V2 Standard Transfer currently has no protocol fee from Ethereum or Arbitrum, although gas and service charges can still apply. Fast Transfer has route-dependent protocol fees. Under the deduction-based model, applicable fees reduce the USDC that the recipient receives. The maxFee parameter sets the authorized fee ceiling in USDC subunits. Supported upfront-fee integrations can collect quoted Fast Transfer and forwarding fees separately on the source chain. With these fees paid separately, CCTP mints the full burned amount to the token recipient. The signed quote must remain valid at submission.

Burn confirmation and the destination USDC balance

A successful burn receipt confirms source-chain execution; native USDC reaches the destination balance after the receiving contracts successfully execute the mint.

An application can report a ready attestation while destination submission remains outstanding. The destination receipt establishes whether execution succeeded; a transaction hash only identifies the transaction. The recipient's balance under the native USDC contract reveals the credited asset. Wallet views can miss that balance when they show another network or token contract. These transfers also leave public records of addresses and token amounts. Changing chains does not make a USDC transfer private.

Native USDC and USDC.e have different bridge relationships

The canonical Ethereum-to-Arbitrum One bridge produces USDC.e when depositing Ethereum USDC. This token represents Ethereum USDC that gateway contracts hold as backing. Native USDC belongs to Circle's direct issuance on Arbitrum One. Both use ERC-20 interfaces, with separate token identities.

Contract addresses and application compatibility

On Arbitrum One, native USDC uses 0xaf88d065e77c8cC2239327C5EDb3A432268e5831, and USDC.e uses 0xff970a61a04b1ca14834a43f5de4533ebddb5cc8. These addresses identify different tokens on the same chain, so an application accepting one contract does not automatically accept the other. Changing a wallet's displayed token name cannot change that contract relationship.

Conversion and the transfer back to Ethereum

A swap between USDC.e and native USDC changes the token held on Arbitrum One without moving funds between chains. Any available conversion has its own quote, liquidity conditions, and applicable fees. Returning native USDC through CCTP uses burn-and-mint, while a USDC.e exit through the canonical bridge uses the gateway withdrawal and parent-chain claim process. The selected token and route carry different settlement requirements.

A decision checklist for receiving native USDC

If the intended balance is native USDC on Arbitrum One, CCTP matches that form when the input is Ethereum-native USDC. Choosing the canonical deposit creates USDC.e, which can suit an application that accepts that contract. The expected payment amount also depends on whether fees reduce the mint or are paid separately.

  • Use native USDC as the burn token for CCTP's USDC transfer.
  • Match Arbitrum One and its native USDC contract to the receiving application's accepted token.
  • Confirm that the burn configuration names the intended token recipient.
  • Include fee deductions in the received amount unless a supported upfront-fee arrangement pays them separately.
  • Account for destination gas through the submitting account or an integration that provides forwarding.

Once you have selected the receiving token, choose among the transfer modes and fee arrangements that the selected interface supports.

Answers to common questions

Does approving USDC start a CCTP transfer?

Approving USDC authorizes contract spending and does not itself begin a CCTP transfer. For a direct CCTP V2 burn, the spender is TokenMessengerV2. An upfront-fee wrapper uses its own spender address. The transfer begins when the burn call succeeds. An existing sufficient allowance for the chosen spender can avoid another approval. The allowance must belong to the native USDC contract on the source chain.

Can the native USDC recipient differ from the sender?

CCTP supports a mint recipient that differs from the wallet supplying the source USDC. The burn configuration records that destination recipient explicitly. This capability belongs to the protocol; a particular bridge interface must expose recipient selection to make it available there. The mintRecipient field specifies the receiving address, while destinationCaller controls who may submit destination execution.

Is Arbitrum's CCTP domain ID the same as its wallet chain ID?

Arbitrum One uses CCTP domain ID 3 and EVM chain ID 42161. Circle's domain identifiers select crosschain messaging destinations. Wallet chain IDs identify execution networks. These identifiers have different functions and cannot substitute for each other in contract parameters. CCTP's destinationDomain expects its domain identifier. The token and transfer contracts must also match the selected network and mainnet environment.

How can an expired CCTP V2 Fast Transfer attestation be renewed?

CCTP V2 permits re-attestation of an expired Fast Transfer message while its burn transaction still exists on the source chain. Request re-attestation from Circle's API using the message nonce. Retrieve the renewed attestation, then submit the destination mint before its refreshed expiration block. On an Arbitrum One destination, that expiration refers to an Ethereum block number. Expiry alone does not undo the source burn or return the USDC.

Do CCTP hooks automatically deposit transferred USDC into an application?

CCTP V2 hooks carry metadata and do not automatically execute an application deposit. The integration supplies the destination logic and decides how to process the hook. It also chooses whether that logic runs before or after minting. Mint confirmation describes token issuance; completion of an application deposit depends on the integration's execution rules.