CCTP

CCTP EVM Contracts and Interfaces

CCTP smart contracts for EVM-compatible blockchains
  • TokenMessengerV2: Entrypoint for cross-chain USDC transfer. Routes messages to burn USDC on a source chain, and mint USDC on a destination chain.

  • MessageTransmitterV2: Generic message passing. Sends all messages on the source chain, and receives all messages on the destination chain.

  • TokenMinterV2: Responsible for minting and burning USDC. Contains chain-specific settings used by burners and minters.

  • MessageV2: Provides helper functions for cross-chain transfers, such as bytes32ToAddress and addressToBytes32, which are commonly used when bridging between EVM and non-EVM chains. These conversions are simple: prepend 12 zero bytes to an EVM address, or strip them to convert back.

Full contract source code is available on GitHub.

This section provides the Smart Contract Interface exposed by CCTP V2, outlining the available functions, and their parameters.

The interface below serves as a reference for permissionless messaging functions exposed by the TokenMessengerV2 and MessageTransmitterV2 functions.

  • TokenMessengerV2#depositForBurnWithHook (extends depositForBurn by adding hook data)
  • TokenMessengerV2#handleReceiveUnfinalizedMessage (replaces handleReceiveMessage)
  • TokenMessengerV2#handleReceiveFinalizedMessage (replaces handleReceiveMessage)
  • TokenMessengerV2#depositForBurn
  • MessageTransmitterV2#sendMessage
  • MessageTransmitterV2#receiveMessage
  • TokenMessengerV2#handleReceiveMessage
  • TokenMessengerV2#replaceDepositForBurn
  • TokenMessengerV2#depositForBurnWithCaller
  • MessageTransmitterV2#replaceMessage
  • MessageTransmitterV2#sendMessageWithCaller

Deposits and burns tokens from sender to be minted on destination domain, and emits a cross-chain message by calling MessageTransmitter's sendMessage function. Minted tokens will be transferred to mintRecipient.

Parameters

FieldTypeDescription
amountuint256Amount of tokens to deposit and burn
destinationDomainuint32Destination domain ID to send the message to
mintRecipientbytes32Address of mint recipient on destination domain (must be converted to 32 byte array, that is, prefix with zeros if needed)
burnTokenaddressAddress of contract to burn deposited tokens on local domain
destinationCallerbytes32Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage
maxFeeuint256Max fee paid for fast burn, specified in units of burnToken
minFinalityThresholduint32Minimum finality threshold at which burn will be attested

Deposits and burns tokens from sender to be minted on destination domain, and emits a cross-chain message with additional hook data appended. In addition to the standard depositForBurn parameters, depositForBurnWithHook accepts a dynamic-length hookData parameter, allowing the caller to include additional metadata to the attested message, which can be used to trigger custom logic on the destination chain.

Parameters

FieldTypeDescription
amountuint256Amount of tokens to burn
destinationDomainuint32Destination domain to send the message to
mintRecipientbytes32Address of mint recipient on destination domain (must be converted to 32 byte array, that is, prefix with zeros if needed)
burnTokenaddressAddress of contract to burn deposited tokens on local domain
destinationCallerbytes32Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage
maxFeeuint256Max fee paid for fast burn, specified in units of burnToken
minFinalityThresholduint32Minimum finality threshold at which burn will be attested
hookDatabytesAdditional metadata attached to the attested message, which can be used to trigger custom logic on the destination chain

Calculates and returns the minimum fee required for a given amount in a Standard Transfer. If the minFee (per unit of burnToken) is non-zero, the specified maxFee must be at least the returned minimum fee. Otherwise, the burn will revert onchain.

Parameters

FieldTypeDescription
amountuint256The amount used to compute the minimum fee. Must be greater than 1 if standard fee is applied

Handles incoming message received by the local MessageTransmitter, and takes the appropriate action. For a burn message, mints the associated token to the requested recipient on the local domain. Validates the function sender is the local MessageTransmitter, and the remote sender is a registered remote TokenMessenger for remoteDomain.

Parameters

FieldTypeDescription
remoteDomainuint32The domain where the message originated from
senderbytes32The sender of the message (remote TokenMessenger)
finalityThresholdExecuteduint32Specifies the level of finality Iris signed the message with
messageBodybytes (dynamic length)The message body bytes

Handles incoming message received by the local MessageTransmitter, and takes the appropriate action. For a burn message, mints the associated token to the requested recipient on the local domain. Validates the function sender is the local MessageTransmitter, and the remote sender is a registered remote TokenMessenger for remoteDomain.

Similar to handleReceiveFinalizedMessage, but is called for messages which are not finalized (finalityThresholdExecuted < 2000).

Unlike handleReceiveFinalizedMessage, handleReceiveUnfinalizedMessage has the following messageBody parameters:

  • expirationBlock. If expirationBlockblockNumber on the destination domain, the message will revert and must be re-signed without the expiration block.
  • feeExecuted. If nonzero, the feeExecuted is minted to the feeRecipient.

Parameters

FieldTypeDescription
remoteDomainuint32The domain where the message originated from
senderbytes32The sender of the message (remote TokenMessenger)
finalityThresholdExecuteduint32Specifies the level of finality Iris signed the message with
messageBodybytes (dynamic length)The message body bytes (see Message format)

Receive message on destination chain by passing message and attestation. Emits MessageReceived event. 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
messagebytesEncoded message (see Message format)
attestationbytesSigned attestation received from attestation service (Iris)

Sends a message to the recipient on the destination domain. Emits a MessageSent event which will be attested by Circle's attestation service.

Parameters

FieldTypeDescription
destinationDomainuint32Destination domain ID to send the message to
recipientbytes32Address of recipient on destination domain
destinationCallerbytes32Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage
minFinalityThresholduint32Minimum finality threshold requested.

Initially, supported values for minFinalityThreshold are [1, 2000]. A value outside of the support values range will be interpreted as 2000 (finalized) by the attestation service (Iris).

For a value within the supported range, the attestation service (Iris) will attest the message with a finalityThresholdExecuted >= minFinalityThreshold.

Initial thresholds supported:

1000: Confirmed
2000: Finalized
messageBodybytesApp-specific message to be handled by recipient

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

CCTP V2CCTP V1
Burn USDC via depositForBurnWithHook

Currently, 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).
Burn USDC via depositForBurn

In CCTP V1, you call depositForBurn on TokenMessenger.
Retrieve, Hash, and Wait for Attestation

Currently, 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.
Retrieve and Hash Message explicitly

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

Currently, 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.
Request Attestation from Circle's Attestation Service

In CCTP V1, you poll for attestation via GET /v1/attestations.
Send Messages via MessageTransmitterV2#sendMessage

Currently, 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.
Send Messages via MessageTransmitter#sendMessage

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

WHAT'S NEXT

Did this page help you?
© 2023-2025 Circle Technology Services, LLC. All rights reserved.