> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/circlefin/evm-cctp-contracts/llms.txt
> Use this file to discover all available pages before exploring further.

# CCTP Overview

> High-level overview of Cross-Chain Transfer Protocol and its core concepts

## What is CCTP?

Cross-Chain Transfer Protocol (CCTP) is a permissionless on-chain system that enables native USDC transfers between blockchain networks. Unlike traditional bridge mechanisms that lock assets, CCTP uses a secure burn-and-mint mechanism to maintain USDC as a native asset across all supported chains.

## Burn-and-Mint Mechanism

CCTP operates on a fundamental principle: tokens are **burned** on the source chain and **minted** on the destination chain. This ensures:

* **1:1 Exchange Rate**: USDC maintains a constant value across all chains
* **Native Assets**: Minted USDC is native to each chain, not a wrapped representation
* **Supply Control**: Total USDC supply remains constant across the ecosystem

### How It Works

1. **Source Chain**: User initiates a transfer by calling `depositForBurn()`, which:
   * Transfers USDC from the user to the TokenMinter contract
   * Burns the specified amount of USDC
   * Emits a `MessageSent` event containing transfer details

2. **Off-Chain Attestation**: Circle's attestation service:
   * Monitors for `MessageSent` events
   * Validates the burn transaction
   * Provides cryptographic attestation (signature)

3. **Destination Chain**: User or relayer calls `receiveMessage()` with:
   * The original message bytes
   * The attestation signature
   * Mints equivalent USDC to the recipient address

## Domain Concept

CCTP uses **domain IDs** to identify different blockchain networks. Each supported chain is assigned a unique 32-bit domain identifier:

* **Domain 0**: Ethereum
* **Domain 1**: Avalanche
* **Domain 2**: Optimism
* **Domain 3**: Arbitrum
* And more...

Domains enable:

* Unambiguous chain identification in cross-chain messages
* Routing of messages to correct destination networks
* Domain-specific configuration and token mappings

## Key Participants

CCTP consists of four primary smart contract components that work together:

### TokenMessenger

**Role**: User-facing interface for cross-chain token transfers

**Responsibilities**:

* Accepts user deposits via `depositForBurn()` and `depositForBurnWithCaller()`
* Coordinates with TokenMinter to burn tokens
* Formats and sends burn messages through MessageTransmitter
* Handles incoming messages to trigger mints on destination chain
* Maintains registry of remote TokenMessenger contracts

**Key Functions**:

```solidity theme={null}
// Burn tokens on source chain
function depositForBurn(
    uint256 amount,
    uint32 destinationDomain,
    bytes32 mintRecipient,
    address burnToken
) external returns (uint64 nonce)

// Handle minting on destination chain
function handleReceiveMessage(
    uint32 remoteDomain,
    bytes32 sender,
    bytes calldata messageBody
) external returns (bool)
```

### MessageTransmitter

**Role**: Cross-chain messaging infrastructure

**Responsibilities**:

* Sends messages to destination domains
* Receives and validates messages with attestations
* Verifies attester signatures using m-of-n multisig scheme
* Prevents replay attacks using nonce tracking
* Dispatches validated messages to recipient contracts

**Key Functions**:

```solidity theme={null}
// Send a message to another domain
function sendMessage(
    uint32 destinationDomain,
    bytes32 recipient,
    bytes calldata messageBody
) external returns (uint64)

// Receive and process attested message
function receiveMessage(
    bytes calldata message,
    bytes calldata attestation
) external returns (bool)
```

### TokenMinter

**Role**: Token lifecycle management (minting and burning)

**Responsibilities**:

* Burns tokens transferred from users
* Mints tokens to recipients on destination chain
* Maintains registry of local and remote token mappings
* Enforces burn limits per message
* Controls which TokenMessenger can call mint/burn functions

**Key Functions**:

```solidity theme={null}
// Mint tokens on destination domain
function mint(
    uint32 sourceDomain,
    bytes32 burnToken,
    address to,
    uint256 amount
) external returns (address mintToken)

// Burn tokens on source domain
function burn(
    address burnToken,
    uint256 burnAmount
) external
```

### Attestation Service (Off-Chain)

**Role**: Cryptographic validation of burn transactions

**Responsibilities**:

* Monitors `MessageSent` events on all supported chains
* Validates burn transactions against protocol rules
* Signs message hashes with authorized attester keys
* Provides attestations via REST API
* Implements rate limiting and security controls

**API Endpoint**:

```
GET https://iris-api.circle.com/attestations/{messageHash}
```

## Security Model

CCTP's security relies on multiple layers:

1. **Attester Multisig**: Multiple independent attesters must sign each message (m-of-n threshold)
2. **Nonce Tracking**: Each message can only be processed once per (sourceDomain, nonce) pair
3. **Domain Validation**: Messages are validated for correct source and destination domains
4. **Role-Based Access Control**: Critical functions restricted to authorized addresses
5. **Emergency Controls**: Pausable functionality for security incidents

## Next Steps

<CardGroup cols={2}>
  <Card title="Architecture" icon="sitemap" href="/concepts/architecture">
    Explore the contract hierarchy and system design
  </Card>

  <Card title="Message Flow" icon="arrow-right-arrow-left" href="/concepts/message-flow">
    Learn the complete lifecycle of a cross-chain transfer
  </Card>

  <Card title="Attestation" icon="signature" href="/concepts/attestation">
    Understand how attestations secure cross-chain messages
  </Card>

  <Card title="API Reference" icon="code" href="/api/message-transmitter">
    View detailed contract interfaces and functions
  </Card>
</CardGroup>