For developers building on Circle products, post Q&A, best practices & SDK/API insights. Use Tags

Circle Products & Developer Toolings

When you send USDC from Ethereum to Arc, something interesting happens. The USDC in your Ethereum wallet doesn't travel across chains. It gets destroyed. Completely. And then brand new USDC gets created on Arc for the recipient.

No wrapped tokens. No liquidity pools sitting in some bridge contract hoping nobody drains them. No intermediary holding your money. The original gets burned, the destination gets minted. 1:1. That's CCTP.

This post breaks down exactly what happens during that process - step by step, from the moment you hit "send" to the moment USDC appears on Arc. Whether you're trying to understand cross-chain for the first time or evaluating CCTP for something you're building, this should give you the full picture.

WHY BURN-AND-MINT INSTEAD OF LOCK-AND-MINT

Most bridges work by locking your tokens in a smart contract on Chain A and minting a "wrapped" version on Chain B. The problem is that wrapped token is only as safe as the bridge contract holding the original. If that contract gets exploited, the wrapped tokens become worthless. Billions have been lost this way.

CCTP takes a different approach. It doesn't lock anything. It burns the real USDC on the source chain and mints real USDC on the destination chain. Circle - the issuer of USDC - operates the attestation service that authorizes the mint. The total supply of USDC across all chains stays the same. Nothing is wrapped, nothing is locked in a vulnerable contract, and the USDC you receive on Arc is the same native USDC used across the entire ecosystem.

For builders, this means your users never have to worry about "which USDC" they're holding. USDC on Arc is USDC. Period.

THE THREE CONTRACTS BEHIND EVERY TRANSFER

CCTP runs on three smart contracts that work together on every supported chain. Each has one job.

 is the front door. This is the only contract your application talks to directly. On the source chain, you call it to start the burn. On the destination chain, it handles the receiving side. If CCTP were a bank, TokenMessenger would be the teller window.

 is the postal service. When USDC gets burned, MessageTransmitter packages up all the details (how much, from where, to whom, on which chain) into a structured message and broadcasts it. On the destination chain, it's the one that receives the attestation, verifies the cryptographic signatures, and only then passes the message forward. Nothing gets minted unless MessageTransmitter says the math checks out.

 is the vault. On the source chain, it executes the actual burn - USDC goes to the zero address, gone forever. On the destination chain, it mints fresh USDC into the recipient's wallet. It also enforces per-message burn limits as a safety mechanism.

These three contracts are deployed as a matching set on every CCTP-supported chain. The source-side set destroys and broadcasts. The destination-side set verifies and creates. Circle's attestation service sits between them, providing the cryptographic proof that connects the two sides.

Every cross-chain USDC transfer through CCTP follows the same five steps. Whether you're moving $10 or $10 million, Ethereum to Arc or Solana to Base, the flow is identical.

Let's walk through what happens when 100 USDC moves from Ethereum Sepolia to Arc Testnet.

Before anything moves, the TokenMessenger contract needs permission to touch the sender's USDC. This is standard ERC-20 behavior - the same approve() pattern you see with any DEX or protocol. The sender says "TokenMessenger, you're allowed to spend up to 100 USDC from my wallet."

Nothing has been burned yet. Nothing has left the wallet. This just unlocks the door.

The sender's application calls depositForBurn() on TokenMessenger with four pieces of information:

Which chain it's going to (Arc Testnet, identified as domain 26)

Who should receive it on the other side (the recipient's address on Arc)

Which token is being burned (the USDC contract address on Sepolia)

TokenMessenger takes this, instructs TokenMinter to burn the USDC (sending it to the zero address - it's gone), and then tells MessageTransmitter to broadcast a message containing all the transfer details.

MessageTransmitter emits a MessageSent event. This event contains the raw bytes of the cross-chain message - everything the destination chain needs to know to mint the USDC on the other side.

At this point, the 100 USDC no longer exists on Ethereum. It's been destroyed. The only record that it ever existed is the message sitting in the transaction logs.

Each chain in the CCTP network has a domain identifier. Ethereum is 0. Avalanche is 1. Base is 6. Arc is 26. When your app specifies destinationDomain: 26, it's telling CCTP "send this to Arc."

This is the step that makes CCTP secure without liquidity pools.

Circle operates an offchain service called the attestation service. This service monitors every CCTP-supported chain, watching for MessageSent events. When it sees one, it doesn't immediately sign off. It waits.

It waits for sufficient block confirmations on the source chain. On Ethereum, this means waiting for enough blocks to pass that the burn transaction is considered final - no chance of a reorg or rollback undoing it. Only after the service is confident the burn is irreversible does it proceed.

Then it takes the raw message bytes from the event, computes a keccak256 hash, and signs that hash using ECDSA with Circle's authorized attester keys. The resulting signature is the attestation - a cryptographic guarantee from Circle that says "yes, this burn really happened, and it's final."

The attestation is then made available through Circle's IRIS API. Your application polls this endpoint until the attestation status changes from "pending" to "complete."

What makes this secure: the attestation is not just "Circle says it's fine." The destination chain contract independently verifies the cryptographic signatures. It recovers the signer's address from the ECDSA signature and checks it against Circle's registered attester addresses stored onchain. If the signatures don't match, the transaction reverts. No USDC gets minted. The verification is trustless at the contract level - the contract doesn't trust Circle's API, it trusts the math.

With the attestation in hand, the final step is calling receiveMessage() on the MessageTransmitter contract on Arc Testnet. This call takes two inputs: the original message bytes (from Step 2) and the attestation signature (from Step 3).

MessageTransmitter verifies the signatures. If they pass, it forwards the message to TokenMessenger, which instructs TokenMinter to mint 100 USDC to the recipient's address on Arc.

The USDC is now on Arc. Native USDC - the same token used across the entire ecosystem. And because Arc uses USDC as its native gas token, the recipient can immediately use it for transactions without needing to acquire a separate gas token first. That's a detail that matters a lot for user experience.

The recipient now has 100 USDC on Arc. Not wrapped. Not synthetic. Real USDC, minted fresh by Circle's authorized contracts. The total USDC supply across all chains hasn't changed - 100 was burned on Ethereum, 100 was minted on Arc. The books balance.

The entire process - from burn to mint - typically takes under a minute on testnet with a standard transfer. On mainnet, the time depends on the source chain's finality requirements.

CCTP V2 shipped several improvements that matter for builders at every level.

 V1 only had one speed: standard. V2 adds a fast transfer mode that significantly reduces the time between burn and mint. The tradeoff is a small fee - between 0 and 14 basis points depending on the source chain. Standard transfers remain completely free. If you're building a trading application where seconds matter, fast transfer is the option. If you're building payroll or scheduled settlements, standard transfer saves on fees.

 This is the composability feature. With V2, you can chain actions that execute automatically after USDC arrives on the destination chain. For example: USDC lands on Arc and is immediately deposited into a lending protocol, or triggers a swap, or calls a custom contract to kick off business logic. In V1, minting was the end of the journey. In V2, minting can be the beginning of the next step.

 V2 introduces a maxFee parameter. You set the maximum fee you're willing to pay, and if the live fee exceeds your cap, the burn transaction reverts on the source chain before any USDC is destroyed. Your money stays in your wallet. This prevents surprises in production.

 V1 had separate API endpoints for attestations and messages. V2 combines them into a single endpoint that returns everything in one call. Less code, fewer requests, simpler integration.

 V2 lets you restrict who can call receiveMessage() on the destination chain. Set it to a specific contract address and only that contract can trigger the mint. This is what enables hooks - your hook contract is the only one authorized to receive the message and chain the next action. Set it to zero and anyone can call it, which is fine for simple transfers.

 works for: payroll distributions, scheduled settlements, treasury rebalancing, any flow where you're optimizing for cost over speed. No fee.

 works for: trading applications, real-time payments, time-sensitive settlements, anything where latency directly impacts user experience. Small fee (0-14 bps).

 work for: automated DeFi deposits on arrival, triggering contract logic after USDC lands, chaining cross-chain workflows where the mint is just the first step of a larger operation.

For most builders starting out, standard transfer with no hooks covers 80% of use cases. Start simple, add fast transfers and hooks when your application actually needs them.

USDC on Arc has a unique address. Unlike most chains where USDC is deployed as a standard ERC-20 contract, USDC on Arc lives at a precompiled address: 

0x3600000000000000000000000000000000000000

. If you're hardcoding addresses, this one looks different from what you're used to.

Gas on Arc is USDC. When your USDC arrives on Arc after a CCTP transfer, it can immediately be used for gas. There's no "I bridged my USDC but now I need ETH for gas" problem. This is one of the practical benefits of Arc's stablecoin-native design - the onboarding step of acquiring a separate gas token is eliminated entirely.

Replay protection is built in. Every CCTP message has a unique nonce. The destination chain tracks which nonces have been used. A message can only be minted once. Calling receiveMessage() with an already-used nonce reverts. You cannot double-mint.

The fee is deducted at mint time. If you burn 100 USDC with a 1 bps fast transfer fee, 99.99 USDC gets minted on the destination. The fee doesn't come out of the sender's wallet separately - it's subtracted from the minted amount. Design your application logic with this in mind.

Arc App Kits abstracts all of this. If you want to skip the manual contract integration entirely, the Bridge Kit from Arc App Kits handles the full burn-attest-mint flow with minimal setup. It uses CCTP as its protocol provider under the hood. For builders who want to move fast, this is the shortcut. For builders who want to understand the plumbing, the five steps above are the plumbing.

If you want to try this yourself on Arc Testnet:

The official quickstart for transferring USDC from Ethereum to Arc is on Circle's developer docs.

Circle's sample bridge app is open source and supports Arc Testnet.

The full CCTP smart contract source code is available for review.

The Arc App Kits Bridge Kit documentation covers the high-level SDK integration.

CCTP solves cross-chain USDC movement at the protocol level. No wrapped tokens, no liquidity pool risk, no intermediaries holding your funds. Burn on one chain, attest offchain, mint on the other. That's the entire model.

For Arc, this means every USDC that arrives from any supported chain is native and immediate - ready to use for gas, for transactions, for DeFi, for anything the builder designs. The infrastructure layer handles the complexity so your application doesn't have to.

Anatomy of a Cross-Chain USDC Transfer on Arc - How CCTP Burns, Attests, and Mints

Home

Forum

Events

Content

Courses

People

Contributors

Albums

Groups

Chat

Channels

Arc Apps

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

Profession

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via noreply@arc.network if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via noreply@arc.network for any questions.