CCTP v2

Architecture

Circle’s Cross-Chain Transfer Protocol (CCTP) is a centralized burn-and-mint bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. for USDC and, underneath it, a generalized message-passing protocol. A source-chain TokenMessenger burns USDC through the local TokenMinter and asks the MessageTransmitter to emit a message for the destination domain. Circle’s offchain Iris attestation service observes the source transaction and acts as the oracle / attester at the destination. Anyone with the message and attestation can call receiveMessage on the destination MessageTransmitter; the contract verifies the attester signatures, prevents nonce replay, dispatches the message to the destination TokenMessenger, and mints the same amount of native USDC to the requested recipient.

CCTP v1 and v2

CCTP v1 and v2 use the same high-level flow and both can carry arbitrary message bodies. In the Ethereum discovery, v1’s MessageTransmitter and TokenMessenger are immutable contracts. CCTP v1 only supports ‘Standard Transfer’: Circle waits for a certain amount of blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. confirmations on the source chain before attesting.

CCTP v2 uses MessageTransmitterV2 and TokenMessengerV2, adds finalityStrongest confirmation rule that can be given on the ordering of transactions. On Ethereum, a transaction is finalized when the corresponding epoch becomes final, which currently takes around 15 mins from transaction inclusion. A rollup transaction can be said to be final when the corresponding data is published to L1 and its ordering cannot be reverted. If outputs, i.e. state diffs are published, then also a proof proving their correctness must be verified to consider the transaction final. thresholds, destination mint fees, and optional hook data. The new ‘Fast Transfer’ feature lets Iris attest much faster as long as Circle’s global ‘Fast Transfer’ allowance is available. Hooks are metadata passed with the burn message and are interpreted by app-level integrators rather than executed by CCTP core.

Crosschain oracle and validation

CCTP does not validate source-chain state on the destination chain. The destination MessageTransmitter verifies signatures from Circle-controlled attesters, so security depends on Circle’s offchain attestation service signing only valid source messages and protecting its signing keys. CCTP v1 is configured with a 2/2 attester threshold, while v2 is configured with a 2/2 threshold. The attester manager can change enabled attesters and thresholds, and the owner can change the attester manager.

UpgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees.

The v1 Ethereum contracts in discovery are immutable, but critical permissions like ownership, minters, pausing, rescuer, token-controller, and attester-manager roles govern protocol operation. V2 introduces proxied contracts; their proxy admins can replace implementations with no onchain delay. CCTP is deployed per Circle domain, so a complete risk assessment must include the corresponding contracts, signer configuration, and permissions on every supported source and destination chain.