CCTP

CCTP Contract Addresses and Interfaces

Learn about CCTP smart contracts for EVM-compatible blockchains
  • TokenMessenger, TokenMessengerV2: Entrypoint for cross-chain USDC transfer. Routes messages to burn USDC on a source chain, and mint USDC on a destination chain for CCTP V1 and CCTP V2, respectively.
  • MessageTransmitter, MessageTransmitterV2: Generic message passing. Sends all messages on the source chain, and receives all messages on the destination chain for CCTP V1 and CCTP V2, respectively.
  • TokenMinter, TokenMinterV2: Responsible for minting and burning USDC. Contains chain-specific settings used by burners and minters for CCTP V1 and CCTP V2, respectively.
  • Message: Provides helper functions bytes32ToAddress and addressToBytes32, which are used when bridging between EVM and non-EVM chains. These conversions are easy in practice: add 12 empty bytes in front of the EVM address, or remove those 12 empty bytes for the reverse conversion. If you are writing your own contract integration, including this logic in your own contract would be cheaper than calling the external contract.
  • MessageV2: Provides additional helper functions for CCTP V2.

Full contract source code is available on GitHub.

Select the applicable CCTP version below:

  • CCTP V1
  • CCTP V2

Select the applicable CCTP version below:

  • CCTP V1
  • CCTP V2

This section provides the CCTP Smart Contract Interface exposed by CCTP V1 and CCTP V2, outlining the available functions, their parameters, and notable changes between versions.

Select the applicable CCTP version:

  • CCTP V1
  • CCTP V2

The interface below serves as a reference for permissionless messaging functions exposed by the TokenMessenger and MessageTransmitter functions. The full ABIs are available on GitHub.

Deposits and burns tokens from sender to be minted on destination domain. Minted tokens will be transferred to mintRecipient.

Parameters

FieldTypeDescription
amountuint256Amount of tokens to deposit and burn
destinationDomainuint32Destination domain identifier
mintRecipientbytes32Address of mint recipient on destination domain
burnTokenaddressAddress of contract to burn deposited tokens on local domain

Same as depositForBurn but with an additional parameter, destinationCaller. This parameter specifies which address has permission to call receiveMessage on the destination domain for the message.

Parameters

FieldTypeDescription
amountuint256Amount of tokens to deposit and burn
destinationDomainuint32Destination domain identifier
mintRecipientbytes32Address of mint recipient on destination domain
burnTokenaddressAddress of contract to burn deposited tokens on local domain
destinationCallerbytes32Address of caller on the destination domain

Replace a BurnMessage to change the mint recipient and/or destination caller. Allows the sender of a previous BurnMessage (created by depositForBurn or depositForBurnWithCaller) to send a new BurnMessage to replace the original. The new BurnMessage will reuse the amount and burn token of the original, without requiring a new deposit.

This is useful in situations where the user specified an incorrect address and has no way to safely mint the previously burned USDC.

Parameters

FieldTypeDescription
originalMessagebytes calldataOriginal message bytes (to replace)
originalAttestationbytes calldataOriginal attestation bytes
newDestinationCallerbytes32The new destination caller, which may be the same as the original destination caller, a new destination caller, or an empty destination caller, indicating that any destination caller is valid
newMintRecipientbytes32The new mint recipient, which may be the same as the original mint recipient, or different

Messages with a given nonce can only be broadcast successfully once for a pair of domains. The message body of a valid message is passed to the specified recipient for further processing.

Parameters

FieldTypeDescription
messagebytes calldataMessage bytes
attestationbytes calldataSigned attestation of message

Sends a message to the destination domain and recipient. Emits a MessageSent event which will be attested by Circle’s attestation service (Iris).

Parameters

FieldTypeDescription
destinationDomainuint32Destination domain identifier
recipientbytes32Address to handle message body on destination domain
messageBodybytes calldataApp-specific message to be handled by recipient

Same as sendMessage but with an additional parameter, destinationCaller. This parameter specifies which address has permission to call receiveMessage on the destination domain for the message.

Parameters

FieldTypeDescription
destinationDomainuint32Destination domain identifier
recipientbytes32Address of message recipient on destination domain
destinationCallerbytes32Address of caller on the destination domain
messageBodybytes calldataApp-specific message to be handled by recipient

Replace a message with a new message body and/or destination caller. The originalAttestation must be a valid attestation of originalMessage, produced by Circle's attestation service (Iris).

Parameters

FieldTypeDescription
originalMessagebytes calldataOriginal message to replace
originalAttestationbytes calldataAttestation of originalMessage
newMessageBodybytes calldataNew message body of replaced message
newDestinationCallerbytes32The new destination caller, which may be the same as the original destination caller, a new destination caller, or an empty destination caller (bytes32(0), indicating that any destination caller is valid)

This table highlights the key interface improvements of CCTP V2 over CCTP V1 in terms of enhanced cross-chain messaging, fewer manual steps, and greater control over message acceptance:

CCTP V1CCTP V2
Burn USDC via depositForBurn

In V1, you call depositForBurn on TokenMessenger.
Burn USDC via depositForBurnWithHook

In V2, you can call depositForBurnWithHook on TokenMessengerV2, which supports hooks and finality thresholds. New parameters include destinationCaller, maxFee, and minFinalityThreshold, allowing you to choose Fast Transfer (1000) or Standard Transfer (2000).
Retrieve and Hash Message explicitly

In V1, you need to manually extract and hash the messageBytes data from the MessageSent event logs using Keccak256.
Retrieve, Hash, and Wait for Attestation

In V2, Iris automates message retrieval and hashing, allowing you to just poll for attestation via GET /v2/messages. The attestation includes both the hashed message and the attestation signature.
Request Attestation from Circle’s Attestation Service

In V1, you poll for attestation via GET /v1/attestations.
Wait for Attestation via Iris

In V2, the attestation request is merged with message retrieval and hashing from the previous step. You simply wait for the polling to complete and retrieve the attestation.
Send Messages via MessageTransmitter#sendMessage

In V1, you send an arbitrary message via sendMessage on MessageTransmitter. The recipient must implement IMessageHandler#handleReceiveMessage to process the message.
Send Messages via MessageTransmitterV2#sendMessage

In V2, the recipient must implement message handling methods based on finality thresholds:
handleReceiveFinalizedMessage for messages with finalityThresholdExecuted ≥ 2000 (fully finalized).
handleReceiveUnfinalizedMessage for messages with finalityThresholdExecuted < 2000 (pre-finalized).

This allows recipients to enforce specific finality requirements before accepting a message.
Did this page help you?
© 2023-2025 Circle Technology Services, LLC. All rights reserved.