Skip to main content

What is Circle's CCTP? The Complete Guide to Cross-Chain Transfer Protocol

Learn how Circle's CCTP enables native USDC transfers across blockchains with burn-mint mechanism. Complete cross-chain guide.

Written by Eco
Updated today

Cross-Chain Transfer Protocol (CCTP) is Circle's official cross-chain protocol for moving native USDC between blockchains. It works by burning USDC on the source chain, having Circle's off-chain Iris attestation service sign the burn message, and minting fresh native USDC on the destination chain. There is no wrapped representation, no liquidity pool, and no third-party bridge custodian. Since CCTP V2 launched on Ethereum and Avalanche on March 11, 2025, the protocol has expanded to 13+ mainnet chains and added 30-second fast finality, programmable post-transfer hooks, and Solana support (added October 2025). This article walks through the burn-and-mint mechanism, the V1 to V2 changes, supported chains as of 2026, the comparison with other cross-chain rails, and how to integrate CCTP at the contract and API level.

What Is CCTP?

CCTP is Circle's permissionless onchain protocol for transferring native USDC across supported blockchains. The mechanism is direct: the protocol burns the source-chain USDC inside Circle's TokenMessenger contract, Circle's off-chain Iris attestation service witnesses the burn and signs a message, then anyone with the signed message can call MessageTransmitter on the destination chain to mint an equal amount of native USDC.

The design choice that defines CCTP is the absence of intermediate value. Lock-and-mint bridges (Wormhole, Multichain pre-exploit, Polygon PoS bridge) hold the source asset in a vault and issue a wrapped IOU on the destination, and that vault becomes a multi-billion-dollar honeypot. The August 2022 Nomad exploit drained $190M from a single bridge contract; the February 2022 Wormhole bridge hack lost $325M; Ronin lost $625M in March 2022. CCTP eliminates the vault entirely. The supply on the destination chain comes from Circle's own minter authority on USDC, not from a wrapped claim.

Native USDC matters because every USDC contract on every supported chain is the same Circle-issued token. A USDC balance bridged via CCTP is not USDC.e (a wrapped IOU minted by a third-party bridge), it is the canonical USDC that exchanges, treasuries, and DeFi protocols treat as fungible with mainnet USDC. As of April 2026 USDC's total supply across all chains exceeds $63B per Circle's transparency reports, with roughly $2.4B moved through CCTP in March 2026 alone according to the Circle CCTP Dune dashboard.

CCTP is open-source under Apache 2.0 and free to use at the protocol level. Circle does not charge a fee for the burn-and-mint primitive itself. Costs come from gas on both chains plus any application layer that wraps CCTP (relayers, intent solvers, swap aggregators).

Brief history. Circle announced CCTP at the Permissionless conference in April 2022 and shipped V1 on Ethereum and Avalanche in April 2023. Arbitrum, Optimism, Base, and Polygon PoS came online through 2023 and 2024. Noble (the Cosmos USDC issuance hub), Sui, and Aptos joined in late 2024 as V1-only domains. CCTP V2 was announced at Token2049 Singapore in September 2024 and shipped on Ethereum and Avalanche on March 11, 2025. Solana V2 followed in October 2025 — the first non-EVM CCTP V2 deployment. The 2025 expansion brought Linea, Unichain, World Chain, Sonic, and Codex to V2.

How Does CCTP Work? The Burn-and-Mint Flow

Every CCTP transfer follows the same four-step pattern. The chain-specific contracts have different addresses but the same interface across all 13+ supported networks.

  1. Approve and burn on the source chain. The sender approves the TokenMessenger contract to spend USDC, then calls depositForBurn(amount, destinationDomain, mintRecipient, burnToken). TokenMessenger calls burn() on the source-chain USDC contract, and the supply on that chain decreases by the transfer amount. TokenMessenger emits a MessageSent event containing the destination domain ID, the recipient address, the amount, and a nonce.

  2. Iris attests to the burn. Circle runs an off-chain service called Iris that listens for MessageSent events. After the source-chain transaction reaches finality (more on this below), Iris signs an attestation over the message hash with Circle's attester key. The signed attestation is exposed at a public REST endpoint: https://iris-api.circle.com/v2/messages/<sourceDomain>?transactionHash=<tx>.

  3. Fetch the attestation. The recipient (or a relayer working on the recipient's behalf) polls the Iris API until status returns complete. The response includes the original message bytes plus Circle's signature.

  4. Mint on the destination chain. Anyone, recipient, relayer, or third-party, calls receiveMessage(message, attestation) on the destination chain's MessageTransmitter contract. MessageTransmitter validates the signature against Circle's attester key, checks the nonce hasn't been used, then routes to the destination TokenMinter, which calls mint() on the destination-chain USDC contract.

The end state: source-chain USDC supply is N lower, destination-chain USDC supply is N higher, and global USDC supply is unchanged. No wrapped token exists. No vault held collateral.

Finality and the Iris wait window. The dominant latency cost in CCTP V1 was source-chain finality. Circle waits for "hard finality" before signing — on Ethereum that meant ~13 minutes (two epochs, ~64-95 blocks for safe finalization), on Avalanche ~1 minute, on Polygon PoS ~20 minutes. Latencies for L2s in V1 inherited from their settlement layer: Arbitrum and Optimism took the full Ethereum finality wait because Circle waited for safe-rollup state. CCTP V2 introduces "Fast Transfer" which uses Circle's own attestation as the finality guarantee plus a small per-transfer fee, dropping the end-to-end window to 8-20 seconds on supported chains.

Why anyone-can-mint matters. The receiveMessage call is permissionless — once Iris has signed the message, any address with enough destination-chain gas can call MessageTransmitter and trigger the mint to the encoded recipient. That makes CCTP relayer-friendly: aggregators like LI.FI and Squid run their own relayers that pay destination gas on the user's behalf, so the user only signs one source-chain transaction. The recipient still receives exactly what was burned (minus any V2 Fast Transfer fee), since the recipient is locked into the signed message.

CCTP V1 vs V2: What Changed in 2025

Circle launched CCTP V2 on Ethereum and Avalanche on March 11, 2025, then rolled out to Base, Arbitrum, Linea, OP Mainnet, Polygon PoS, Unichain, World Chain, Sonic, and Codex through 2025. V2 is a contract upgrade and a service upgrade — same burn-and-mint core, three new capabilities.

Capability

CCTP V1

CCTP V2

End-to-end latency

13-19 min on Ethereum (hard finality)

8-20 sec via Fast Transfer; standard transfer still available

Finality model

Source-chain hard finality before attestation

Fast Transfer: Circle attests pre-finality with a fee buffer

Programmable hooks

None — recipient must be an EOA or pre-approved contract

hookData field passed to a destination contract on mint, enabling atomic post-transfer logic

Message format

V1 message envelope

V2 envelope with versioned headers; backwards-compatible

Supported chains (Apr 2026)

Frozen on legacy contract addresses

13+ mainnet chains, more in pipeline

Per-transfer fee

Gas only

Fast Transfer adds a basis-point fee charged in USDC at burn; standard transfer is gas-only

Hooks are the most consequential V2 addition for builders. In V1 a CCTP transfer had to land at an externally-owned account (EOA) or a contract that held a CCTP-aware integration. With V2, the source-chain caller passes a hookData bytes field. After the destination mint, MessageTransmitter forwards that bytes payload to the recipient contract via a callback. That lets a single source-chain transaction trigger atomic logic on the destination — depositing the freshly minted USDC into Aave, swapping into another stablecoin, settling an order, or paying a merchant. Without hooks the pattern required two user transactions or an off-chain relayer holding signing power.

Fast Transfer changes the trust assumption slightly. With standard CCTP V2 (and all of V1) the security guarantee is that USDC was burned and Circle saw enough source-chain confirmations to consider the burn irreversible. Fast Transfer relies on Circle's own attestation as the finality guarantee — Circle signs before the source chain finalizes, and assumes the chain risk through a Fast Transfer Allowance (FTA) escrow. If a source-chain reorg unwinds the burn, Circle absorbs the loss from the FTA, not the recipient. In exchange Circle charges a small fee in basis points of the transfer. As of Circle's V2 docs, the Fast Transfer fee is 0.0001% per chain pair, capped per transfer.

Standard Transfer still exists in V2. Not every flow needs sub-finality settlement. A treasury rebalance, a scheduled payment, or a custodian sweep can wait for hard finality and pay zero protocol fee. The V2 contracts expose both Fast and Standard via the same depositForBurn entry point — the caller picks the finality threshold via the minFinalityThreshold parameter. A value of 1000 means hard finality (Standard); 500 or below selects Fast Transfer where supported.

Supported Chains and Domain IDs (April 2026)

CCTP routes use a domain ID rather than a chain ID — Circle's internal numbering separate from EIP-155. As of April 2026 the live domains on V2 are:

  • Ethereum (domain 0)

  • Avalanche C-Chain (domain 1)

  • OP Mainnet (domain 2)

  • Arbitrum One (domain 3)

  • Noble Cosmos chain (domain 4) — V1 only as of writing

  • Solana (domain 5) — V2 launched October 2025

  • Base (domain 6)

  • Polygon PoS (domain 7)

  • Sui (domain 8) — V1

  • Aptos (domain 9) — V1

  • Unichain (domain 10)

  • Linea (domain 11)

  • Codex (domain 12)

  • Sonic (domain 13)

  • World Chain (domain 14)

The full list of contract addresses by domain lives at Circle's EVM smart contracts reference for EVM and Solana programs reference for SVM. The TokenMessenger and MessageTransmitter addresses are deterministic per chain — the same code is deployed in every domain, so an integration written against the V2 interface works identically across all of them.

Stellar and Hedera are listed in Circle's roadmap for 2026 V2 expansion, per the January 2026 Circle roadmap post. Tron remains absent from CCTP — Tron USDC is issued by separate mint authority arrangements and Circle has not announced a Tron CCTP domain.

Solana V2 is structurally different from EVM V2. Solana doesn't have EVM-style smart contracts; it has programs and accounts. The Solana CCTP V2 deployment uses a TokenMessengerMinter program and a MessageTransmitter program, with per-message accounts derived via PDA (program-derived address) seeds. Hooks on Solana invoke a destination program via Cross-Program Invocation (CPI). The trust model is identical to EVM V2 — Circle's attester signs over the burn — but the developer integration is account-driven rather than calldata-driven. Circle published a TypeScript SDK at circlefin/solana-cctp-contracts that abstracts the account derivation.

CCTP vs Other Cross-Chain Rails

CCTP is one of several primitives a builder might use to move value across chains. Each has a different scope.

Rail

What it moves

Trust assumption

Latency

Fee model

CCTP V2 Fast

Native USDC only

Circle attester + Circle FTA

8-20s

Gas + ~0.0001% fee

CCTP V2 Standard

Native USDC only

Circle attester after source finality

1-19 min depending on source

Gas only

Any token via OFT, any message

Configurable DVN set + executor

~30s-3min depending on confirmations

Gas + relayer fee

Any token, any message

19/19 Guardian signers

~15min Ethereum, ~1-3min others

Gas + relayer fee

Any token via ITS, any message

~75 Axelar validators

~1-3min

Gas + Axelar tx fee

Any token, any message

Chainlink DON + RMN risk-management network

~15-20min on Ethereum (high finality bar)

Gas + LINK or USDC fee

Any token via Warp Routes, any message

Configurable ISM (modular)

~30s-2min

Gas + relayer fee

CCTP wins on USDC. The token landing on the destination is the canonical USDC, not a wrapped variant — you don't end up holding USDC.e or BridgedUSDC that needs a separate redemption flow. The trust model is also as tight as it gets for issuer-canonical movement: you trust Circle to mint USDC, which you already do by holding USDC at all. There is no additional bridge multisig or validator set to worry about.

CCTP loses on everything else. It cannot move USDT, DAI, ETH, BTC, or any other asset. It cannot deliver an arbitrary message. For multi-asset cross-chain logic you need LayerZero, Wormhole, Axelar, Chainlink CCIP, or Hyperlane on top of (or in place of) CCTP.

The practical pattern in 2026 is composition. An aggregator like LI.FI, Squid, or deBridge uses CCTP for the USDC leg of a route and a different rail (LayerZero OFT, Wormhole NTT, native swap) for non-USDC legs. The user submits one intent, the aggregator picks the cheapest combination per token.

Comparing CCTP to a hub-and-spoke approach. One alternative for moving USDC across many chains is to use a hub chain — typically Noble in the Cosmos ecosystem, or Solana — and routing every transfer through it. CCTP V2 makes this less necessary because pairwise direct routes exist between most major chains. A direct Ethereum-to-Solana CCTP V2 Fast Transfer takes 8-15 seconds and one Iris attestation; the hub-and-spoke equivalent (Ethereum → Noble → Solana) takes two attestation cycles and adds a Cosmos IBC hop. For specific routes (anything Cosmos-side) Noble remains the best path. For the EVM-Solana mainstream, direct CCTP V2 is simpler.

Worked Example: 1,000 USDC, Ethereum to Solana via V2

To make the mechanics concrete, here is the full sequence for moving 1,000 USDC from an Ethereum EOA to a Solana SPL token account using CCTP V2 Fast Transfer.

  1. Caller approves 0xBd3fa81B58Ba92a82136038B25aDec7066af3155 (Ethereum TokenMessengerV2) to spend 1,000 USDC.

  2. Caller calls depositForBurn(1_000_000_000, 5, recipientPubkey, USDC, ZERO_ADDR, fee, minFinalityThreshold, hookData). Domain 5 is Solana. The recipientPubkey is the 32-byte Solana account.

  3. TokenMessengerV2 burns the 1,000 USDC and emits MessageSent.

  4. Caller polls https://iris-api.circle.com/v2/messages/0?transactionHash=<txhash>. With Fast Transfer enabled the response transitions from pending_confirmations to complete in 8-15 seconds.

  5. Caller submits a Solana transaction calling receive_message on the Solana MessageTransmitter program, passing the message bytes and Circle's signature.

  6. Solana TokenMinter mints 1,000 USDC to the recipient SPL account. Total Ethereum-to-Solana wall-clock time: typically 12-25 seconds, dominated by Solana confirmation rather than CCTP.

End-state ledger effects: Ethereum USDC supply is 1,000 lower, Solana USDC supply is 1,000 higher. Circle's transparency report at the next monthly snapshot reflects the rebalanced per-chain reserves backing each. Total USDC supply unchanged at $63B+.

Cost breakdown for the same transfer. Source-chain gas at 30 gwei on Ethereum mainnet runs about $4-6 for the depositForBurn call. Iris attestation is free. Solana receive_message costs ~0.000005 SOL, about $0.001 at SOL=$200. Fast Transfer fee at 0.0001% on 1,000 USDC is $0.001 (rounded down to zero by the contract for this size). Total round-trip: ~$5 dominated by Ethereum gas. The same flow Base-to-Solana drops the gas to ~$0.10, and Avalanche-to-Solana ~$0.05.

Building on CCTP: Practical Notes

A few engineering details that catch teams integrating CCTP for the first time.

Domain IDs are not chain IDs. Circle uses an internal numbering — domain 0 is Ethereum, but Ethereum's EIP-155 chainId is 1. Domain 6 is Base, chainId 8453. Always pull the domain table from Circle's supported domains page rather than hardcoding.

Recipient encoding. EVM destinations expect a 32-byte left-padded address (the 20-byte EVM address with 12 leading zero bytes). Solana destinations expect the 32-byte Pubkey directly. Aptos and Sui have their own address formats. The recipient field is always 32 bytes, and you encode per destination.

Nonce and message hash. Each depositForBurn emits a unique nonce (uint64). The message hash combines source domain, destination domain, nonce, sender, recipient, and the burn token. MessageTransmitter rejects replay by tracking used nonces in a bitmap. If you need an idempotency key, the nonce is it.

Hook contract interface. If the destination is a contract that should react to the mint, the contract must implement handleReceiveFinalizedMessage(uint32 sourceDomain, bytes32 sender, uint32 finalityThresholdExecuted, bytes calldata messageBody) for V2. The hook fires after the mint inside the same destination-chain transaction — atomic.

Fast Transfer Allowance. Circle caps Fast Transfer per chain via the FTA. If a route's daily Fast Transfer Allowance is exhausted (rare in practice, but possible during volatile flow), the transfer falls back to standard finality timing. Check FTA status via the Iris API.

Attestation costs. The Iris API is free for standard transfers. Fast Transfer fees are charged in USDC at burn time — the burn amount minus fee is what gets minted on the destination. Plan UX accordingly: a 1,000 USDC Fast Transfer at 0.0001% delivers 999.9999 USDC, not 1,000.

Replay protection across V1 and V2. The V1 and V2 MessageTransmitter contracts are separate — a V2 message cannot be replayed against the V1 contract or vice versa. If you have a hybrid integration that supports both V1 chains (Sui, Aptos, Noble) and V2 chains, you maintain two attestation pollers, two contract sets, and two nonce spaces. Most aggregators wrap this in a single SDK call that routes to the right version per destination.

Circuit breaker risk. Circle retains the ability to pause CCTP via a privileged role on the contracts. In a hypothetical incident — Iris key compromise, destination-chain mint exploit — Circle could pause attestations or pause receiveMessage globally. This is the same trust model as USDC itself: Circle can freeze any USDC address by executive order. Teams that already accept USDC accept this risk. Teams that need fully trustless settlement need a different rail.

Security Model and Audit History

CCTP V1 was audited by Halborn in March 2023 before mainnet launch. CCTP V2 went through audits by OtterSec, Halborn, and Zellic across late 2024 and early 2025 before the March 11, 2025 launch. Audit reports are linked from Circle's CCTP GitHub repo. As of April 2026, no exploits have been disclosed against CCTP V1 or V2 contracts in production.

The protocol's security boundary is the attester key. Circle controls a multisig that signs Iris attestations; compromise of that key would let an attacker mint USDC on a destination chain without a corresponding source-chain burn. Circle's mitigation is hardware-backed key custody plus an emergency-pause role that can stop receiveMessage acceptance globally within minutes. The replicated risk is comparable to a stablecoin issuer's mint key for the underlying USDC — the same trust assumption already in place by anyone holding USDC.

Reorg risk is the other consideration, particularly for Fast Transfer. If a deep source-chain reorg unwinds the burn after Circle has signed and the destination has minted, the global USDC supply drifts upward by the transferred amount. CCTP V2 caps this risk through the Fast Transfer Allowance (FTA) — Circle escrows USDC against potential reorgs and absorbs the loss, not the user. The FTA is sized per chain based on observed reorg depth: Ethereum FTA is conservative because deep reorgs are theoretically possible during validator coordination failures; Solana FTA is sized against typical 1-2 slot reorgs. As of January 2026 Circle has not had to draw on the FTA in production.

Compliance and sanctions. Circle enforces sanctions screening at the Iris layer — Iris will not sign an attestation for a transfer to or from a sanctioned address per OFAC SDN list. This is consistent with Circle's broader USDC compliance posture; the same screening applies to direct USDC transfers Circle observes. Builders using CCTP inherit this screening, which simplifies regulatory exposure for payment-class flows and is sometimes a deal-breaker for fully permissionless DeFi use cases.

Where CCTP Fits in Production Stablecoin Stacks

CCTP is a primitive, not an application. Production stablecoin stacks combine CCTP with several other layers.

Aggregators and intent solvers.LI.FI, Squid, Mayan, deBridge, and Jumper all integrate CCTP for the USDC leg of cross-chain routes, falling back to LayerZero, Wormhole, or native bridges for non-USDC assets. The aggregator picks the route per token at quote time.

Wallets.MetaMask Bridge, Phantom cross-chain, Coinbase Wallet, and Circle's own Programmable Wallets route USDC moves through CCTP under the hood.

Exchanges. Coinbase, Binance, and Kraken use CCTP for internal cross-chain USDC rebalancing — moving treasury USDC between Ethereum and Base, or Avalanche and Solana, without taking wrapped-token exposure.

Stablecoin payment processors.Stripe's 2025 stablecoin payment product uses CCTP to move merchant USDC across chains. Bridge (acquired by Stripe in October 2024) integrates CCTP for B2B stablecoin transfers.

DeFi protocols.Aave, Compound, and Sky reference native-USDC pools that depend on CCTP for cross-chain rebalancing rather than wrapped USDC pools. Uniswap's cross-chain swap UX uses CCTP for the USDC settlement leg when the destination chain is a CCTP domain.

Eco's Role: Orchestration Above the Rails

CCTP solves the USDC leg of cross-chain movement. Most production stablecoin flows need more than that — multi-token swaps, multi-rail routing when CCTP doesn't reach a destination, gas abstraction, settlement guarantees, compliance hooks. Eco is the stablecoin execution network that orchestrates these pieces. A team submits an intent ("move 100k USDC from Ethereum to Solana, settle within 30s, fall back to USDT if USDC liquidity is thin"); Eco's solver network picks the rails — including CCTP V2 Fast Transfer for native USDC moves on supported chains — and returns settlement confirmation. Eco Routes (the developer surface) abstracts the per-rail details: instead of managing CCTP attestation polling, LayerZero DVN config, Wormhole VAA fetching, and native bridge interactions separately, integrators call a single API and receive a unified settlement. CCTP remains the canonical primitive for native USDC; Eco handles everything around it. Read more at eco.com/routes or the Eco docs.

FAQ

What is the difference between CCTP V1 and CCTP V2?

V2 launched March 11, 2025 on Ethereum and Avalanche and added three things to the V1 burn-and-mint primitive: Fast Transfer (8-20 second finality via Circle's attestation guarantee, vs 13+ minutes for V1 hard finality on Ethereum), programmable hooks (a destination contract can run atomic logic when USDC arrives), and a versioned message format. V1 contracts remain live for chains not yet on V2.

Which chains does CCTP support?

As of April 2026, CCTP is live on 13+ mainnet chains: Ethereum, Avalanche, OP Mainnet, Arbitrum, Base, Polygon PoS, Solana, Sui, Aptos, Noble, Unichain, Linea, World Chain, Sonic, and Codex. V2 is on the EVM mainstream plus Solana; V1-only chains include Sui, Aptos, and Noble. The full live domain list is on Circle's supported domains page.

Is CCTP a bridge?

CCTP is not a bridge in the lock-and-mint sense. Traditional bridges hold the source asset in a vault and issue a wrapped IOU on the destination, creating a multi-billion-dollar honeypot — Wormhole lost $325M, Ronin lost $625M. CCTP burns the source-chain USDC and Circle mints fresh native USDC on the destination, eliminating the vault. The output is canonical USDC, not a wrapped variant.

How much does CCTP cost?

CCTP V1 and CCTP V2 Standard charge gas only — Circle does not take a protocol fee for the burn-and-mint primitive. CCTP V2 Fast Transfer adds a small basis-point fee (0.0001% per Circle's V2 docs as of 2026, capped per transfer) charged in USDC at burn time, in exchange for sub-finality settlement. Aggregators wrapping CCTP may add their own routing fees on top.

Why does CCTP only move USDC?

CCTP relies on Circle's mint authority over USDC. The protocol's burn-and-mint mechanism only works for tokens whose issuer can mint on the destination chain — Circle for USDC and EURC. For USDT, DAI, or other stablecoins, CCTP is not applicable; teams use Tether's bridging arrangements, Sky's Teleport, LayerZero OFT, Wormhole NTT, or other multi-asset rails. Most production stacks combine CCTP for USDC with another rail for non-USDC assets.

Did this answer your question?