Attestation Mechanism - EVM CCTP Contracts

What are Attestations?

Attestations are cryptographic signatures that prove a cross-chain message is legitimate. In CCTP, attestations serve as the security bridge between chains:

Burn Proof: Attestation confirms tokens were actually burned on the source chain
Authorization: Only valid attestations allow minting on the destination chain
Decentralization: Multiple independent attesters must sign (m-of-n multisig)
Replay Prevention: Each attestation is valid for exactly one (sourceDomain, nonce) pair

Without valid attestations, it’s impossible to mint tokens on the destination chain, preventing unauthorized USDC creation.

Why Attestations Are Needed

Blockchains cannot natively communicate with each other. CCTP bridges this gap:

The Problem

Avalanche contracts cannot directly verify that USDC was burned on Ethereum. Without attestations:

Anyone could claim to have burned tokens
Malicious actors could mint unlimited USDC
Cross-chain transfers would be impossible to trust

The Solution

Trusted attesters observe burns and provide cryptographic proof that minting is authorized.

Attester Management

CCTP uses the Attestable role contract (see src/roles/Attestable.sol:22) to manage attesters:

Attester Lifecycle

Enabling Attesters

Only the attesterManager can enable new attesters:

function enableAttester(address newAttester) public onlyAttesterManager {
    require(newAttester != address(0), "New attester must be nonzero");
    require(enabledAttesters.add(newAttester), "Attester already enabled");
    emit AttesterEnabled(newAttester);
}

Requirements:

newAttester must not be zero address
newAttester must not already be enabled
Caller must be the attester manager

Example:

await messageTransmitter.methods
  .enableAttester('0x1234...')
  .send({ from: attesterManagerAddress });

Disabling Attesters

To disable a compromised or retired attester:

function disableAttester(address attester) external onlyAttesterManager {
    // Cannot disable if only 1 attester remains
    uint256 _numEnabledAttesters = getNumEnabledAttesters();
    require(_numEnabledAttesters > 1, "Too few enabled attesters");
    
    // Cannot disable if it would reduce below signature threshold
    require(
        _numEnabledAttesters > signatureThreshold,
        "Signature threshold is too low"
    );
    
    require(enabledAttesters.remove(attester), "Attester already disabled");
    emit AttesterDisabled(attester);
}

Safety Checks:

At least 1 attester must remain enabled
Number of enabled attesters must exceed signature threshold
Ensures system remains operational after disabling

Security: Disabling an attester does not invalidate existing attestations signed by that attester. Only future attestations are affected.

Signature Threshold

The signature threshold determines how many attesters must sign each message (m in m-of-n multisig):

function setSignatureThreshold(
    uint256 newSignatureThreshold
) external onlyAttesterManager {
    require(newSignatureThreshold != 0, "Invalid signature threshold");
    
    // Threshold cannot exceed number of enabled attesters
    require(
        newSignatureThreshold <= enabledAttesters.length(),
        "New signature threshold too high"
    );
    
    require(
        newSignatureThreshold != signatureThreshold,
        "Signature threshold already set"
    );
    
    uint256 _oldSignatureThreshold = signatureThreshold;
    signatureThreshold = newSignatureThreshold;
    emit SignatureThresholdUpdated(_oldSignatureThreshold, newSignatureThreshold);
}

Validation Rules:

Threshold must be at least 1
Threshold cannot exceed number of enabled attesters
Threshold must be different from current value

Security Tradeoff:

Higher threshold: More secure (more attesters needed to compromise), but slower and less fault-tolerant
Lower threshold: Faster and more fault-tolerant, but less secure

Example Configuration:

Enabled Attesters: 5
Signature Threshold: 3
Result: Any 3 of the 5 attesters can sign to authorize minting

Attester Manager Role

The attester manager has exclusive control over the attester set:

function updateAttesterManager(
    address newAttesterManager
) external onlyOwner {
    _setAttesterManager(newAttesterManager);
}

function _setAttesterManager(address _newAttesterManager) internal {
    require(
        _newAttesterManager != address(0),
        "Invalid attester manager address"
    );
    address _oldAttesterManager = _attesterManager;
    _attesterManager = _newAttesterManager;
    emit AttesterManagerUpdated(_oldAttesterManager, _newAttesterManager);
}

Responsibilities:

Enable new attesters
Disable compromised attesters
Adjust signature threshold

Access Control:

Only contract owner can change attester manager
Attester manager cannot transfer their own role

Signature Verification

The core security mechanism is signature verification in _verifyAttestationSignatures() (see src/roles/Attestable.sol:227):

Attestation Format

Attestations are concatenated 65-byte ECDSA signatures:

[signature1][signature2][signature3]...[signatureN]
│         ││         ││         │     │         │
│   65B   ││   65B   ││   65B   │ ... │   65B   │
│         ││         ││         │     │         │
└─────────┘└─────────┘└─────────┘     └─────────┘

Each 65-byte signature consists of:

r (32 bytes): Signature component
s (32 bytes): Signature component
v (1 byte): Recovery ID

Total Length: 65 * signatureThreshold bytes

Verification Algorithm

function _verifyAttestationSignatures(
    bytes calldata _message,
    bytes calldata _attestation
) internal view {
    // 1. Validate attestation length
    require(
        _attestation.length == signatureLength * signatureThreshold,
        "Invalid attestation length"
    );
    
    // 2. Hash the message
    bytes32 _digest = keccak256(_message);
    
    // 3. Track last attester address (for ordering check)
    address _latestAttesterAddress = address(0);
    
    // 4. Verify each signature
    for (uint256 i = 0; i < signatureThreshold; ++i) {
        // Extract individual signature
        bytes memory _signature = _attestation[
            i * signatureLength : i * signatureLength + signatureLength
        ];
        
        // Recover signer address from signature
        address _recoveredAttester = _recoverAttesterSignature(
            _digest,
            _signature
        );
        
        // 5. Enforce increasing address order (prevents duplicates)
        require(
            _recoveredAttester > _latestAttesterAddress,
            "Invalid signature order or dupe"
        );
        
        // 6. Verify signer is enabled attester
        require(
            isEnabledAttester(_recoveredAttester),
            "Invalid signature: not attester"
        );
        
        _latestAttesterAddress = _recoveredAttester;
    }
}

Verification Steps Explained

Step 1: Length Validation

Ensures attestation contains exactly the required number of signatures:

require(
    _attestation.length == 65 * signatureThreshold,
    "Invalid attestation length"
);

Examples:

Threshold = 1: Attestation must be exactly 65 bytes
Threshold = 3: Attestation must be exactly 195 bytes
Threshold = 5: Attestation must be exactly 325 bytes

Step 2: Message Hashing

bytes32 _digest = keccak256(_message);

The complete message bytes (including all fields) are hashed. Attesters sign this hash, not the raw message.

Step 3-4: Signature Recovery

For each signature, recover the signer’s address using ECDSA:

function _recoverAttesterSignature(
    bytes32 _digest,
    bytes memory _signature
) internal pure returns (address) {
    return ECDSA.recover(_digest, _signature);
}

Uses OpenZeppelin’s ECDSA.recover() which:

Extracts v, r, s from signature
Performs elliptic curve point recovery
Returns the address that created the signature

Step 5: Increasing Address Order

Critical Security Check: Signatures must be ordered by ascending attester address:

require(
    _recoveredAttester > _latestAttesterAddress,
    "Invalid signature order or dupe"
);

Why This Matters:

Prevents Duplicate Signatures: Same signature cannot be used twice (address would not increase)
Simplifies Verification: O(n) complexity instead of O(n²) for checking duplicates
Canonical Format: Only one valid ordering exists for any signature set

Example:

Valid:   [sig_0x1234] [sig_0x5678] [sig_0x9ABC]  ✓
Invalid: [sig_0x5678] [sig_0x1234] [sig_0x9ABC]  ✗ (wrong order)
Invalid: [sig_0x1234] [sig_0x1234] [sig_0x5678]  ✗ (duplicate)

Step 6: Attester Authorization

require(
    isEnabledAttester(_recoveredAttester),
    "Invalid signature: not attester"
);

Verifies the recovered address is currently in the enabled attester set. This prevents:

Random addresses from providing signatures
Disabled/retired attesters from authorizing transfers

Complete Verification Example

// Example: 3-of-5 multisig (threshold = 3, enabled = 5)

const enabledAttesters = [
  '0x0000...1111',  // Attester 1
  '0x0000...2222',  // Attester 2
  '0x0000...3333',  // Attester 3
  '0x0000...4444',  // Attester 4
  '0x0000...5555'   // Attester 5
];

// Valid attestation: signatures from attesters 1, 3, and 5 (in order)
const validAttestation = 
  signature_from_0x0000_1111 +  // 65 bytes
  signature_from_0x0000_3333 +  // 65 bytes
  signature_from_0x0000_5555;   // 65 bytes
// Total: 195 bytes

// Invalid: wrong order
const invalidAttestation = 
  signature_from_0x0000_3333 +  // ✗ Not in ascending order
  signature_from_0x0000_1111 +
  signature_from_0x0000_5555;

// Invalid: duplicate
const invalidAttestation2 = 
  signature_from_0x0000_1111 +  // ✗ Duplicate signature
  signature_from_0x0000_1111 +
  signature_from_0x0000_3333;

// Invalid: unauthorized signer
const invalidAttestation3 = 
  signature_from_0x0000_1111 +
  signature_from_0x0000_6666 +  // ✗ Not an enabled attester
  signature_from_0x0000_3333;

Attestation Service Architecture

Circle operates the off-chain attestation service:

Service Responsibilities

Event Monitoring: Listen for MessageSent events on all supported chains
Validation:
- Verify transaction confirmation and finality
- Check burn amount is within limits
- Validate destination domain is supported
- Confirm source contract is legitimate TokenMessenger
Signing: Generate signatures with authorized attester keys
API: Provide attestations via REST API with rate limiting
Observability: Log all attestations for audit trails

Attestation API

Endpoint:

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

Request:

curl https://iris-api.circle.com/attestations/0xabc123...

Response - Pending:

{
  "status": "pending"
}

Response - Complete:

{
  "status": "complete",
  "attestation": "0x1234567890abcdef..."
}

Rate Limits:

Maximum 1 request per second per IP
Exceeding limit returns HTTP 429

Best Practice: Poll with exponential backoff (2s, 4s, 8s, 16s…) to respect rate limits and reduce unnecessary requests.

Security Considerations

Attester Key Management

Critical: Attester private keys are the root of CCTP security

Hardware Security Modules (HSMs): Keys stored in tamper-resistant hardware
Multi-Party Computation (MPC): Distributed key generation and signing
Key Rotation: Periodic rotation of attester keys
Separation: Each attester key held by independent party

Threshold Selection

Choosing the right threshold balances security and availability: Example Scenarios:

Enabled	Threshold	Security Level	Fault Tolerance
3	2	Moderate	1 attester can fail
5	3	High	2 attesters can fail
7	5	Very High	2 attesters can fail
9	7	Maximum	2 attesters can fail

Recommendation: Set threshold to at least floor(n/2) + 1 where n is number of enabled attesters (Byzantine fault tolerance).

Attack Vectors and Mitigations

Replay Attacks

Attack: Reuse valid attestation to mint tokens multiple times Mitigation: Nonce tracking in MessageTransmitter

require(usedNonces[_sourceAndNonce] == 0, "Nonce already used");
usedNonces[_sourceAndNonce] = 1;

Signature Malleability

Attack: Modify signature to create alternative valid signature for same message Mitigation:

ECDSA library validates signature format
Increasing address order requirement ensures canonical representation

Attester Compromise

Attack: Compromise m attesters to authorize fraudulent mints Mitigation:

Geographic distribution of attesters
Different security vendors for each attester
Regular security audits
Ability to quickly disable compromised attesters

Front-Running

Attack: Monitor mempool and submit receiveMessage before intended recipient Mitigation: Use depositForBurnWithCaller() to restrict who can complete transfer

Monitoring and Observability

Key Metrics

Attestation Service:

Average attestation time
Success/failure rate
API request rate and errors

On-Chain:

Number of enabled attesters: getNumEnabledAttesters()
Current threshold: signatureThreshold
Attester manager: attesterManager()

Events

event AttesterEnabled(address indexed attester);
event AttesterDisabled(address indexed attester);
event SignatureThresholdUpdated(uint256 oldThreshold, uint256 newThreshold);
event AttesterManagerUpdated(address indexed previousManager, address indexed newManager);

Monitor these events to track attester set changes and detect anomalies.

Next Steps

Message Flow

See how attestations fit into the complete transfer flow

Quickstart

Build your first integration with attestations

Get Started

Core Concepts

Guides

Version 2

​What are Attestations?

​Why Attestations Are Needed

​The Problem

​The Solution

​Attester Management

​Attester Lifecycle

​Enabling Attesters

​Disabling Attesters

​Signature Threshold

​Attester Manager Role

​Signature Verification

​Attestation Format

​Verification Algorithm

​Verification Steps Explained

​Step 1: Length Validation

​Step 2: Message Hashing

​Step 3-4: Signature Recovery

​Step 5: Increasing Address Order

​Step 6: Attester Authorization

​Complete Verification Example

​Attestation Service Architecture

​Service Responsibilities

​Attestation API

​Security Considerations

​Attester Key Management

​Threshold Selection

​Attack Vectors and Mitigations

​Replay Attacks

​Signature Malleability

​Attester Compromise

​Front-Running

​Monitoring and Observability

​Key Metrics

​Events

​Next Steps

Message Flow

Quickstart

Build docs developers (and LLMs) love

What are Attestations?

Why Attestations Are Needed

The Problem

The Solution

Attester Management

Attester Lifecycle

Enabling Attesters

Disabling Attesters

Signature Threshold

Attester Manager Role

Signature Verification

Attestation Format

Verification Algorithm

Verification Steps Explained

Step 1: Length Validation

Step 2: Message Hashing

Step 3-4: Signature Recovery

Step 5: Increasing Address Order

Step 6: Attester Authorization

Complete Verification Example

Attestation Service Architecture

Service Responsibilities

Attestation API

Security Considerations

Attester Key Management

Threshold Selection

Attack Vectors and Mitigations

Replay Attacks

Signature Malleability

Attester Compromise

Front-Running

Monitoring and Observability

Key Metrics

Events

Next Steps