The sender of the original depositForBurn has access to call
replaceDepositForBurn. The resulting mint will supersede the original mint,
as long as the original mint has not confirmed yet onchain. When using a
third-party app/bridge that integrates with CCTP V1 to burn and mint USDC, it
is the choice of the app/bridge if and when to replace messages on behalf of
users. When sending USDC to smart contracts, be aware of the functionality
that those contracts have and their respective trust model.
- 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
bytes32ToAddressandaddressToBytes32, 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
| Chain | Domain | Address |
|---|---|---|
| Ethereum | 0 | 0xBd3fa81B58Ba92a82136038B25aDec7066af3155 |
| Avalanche | 1 | 0x6B25532e1060CE10cc3B0A99e5683b91BFDe6982 |
| OP Mainnet | 2 | 0x2B4069517957735bE00ceE0fadAE88a26365528f |
| Arbitrum | 3 | 0x19330d10D9Cc8751218eaf51E8885D058642E08A |
| Base | 6 | 0x1682Ae6375C4E4A97e4B583BC394c861A46D8962 |
| Polygon PoS | 7 | 0x9daF8c91AEFAE50b9c0E69629D3F6Ca40cA3B3FE |
| Unichain | 10 | 0x4e744b28E787c3aD0e810eD65A24461D4ac5a762 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum | 0 | 0x0a992d191DEeC32aFe36203Ad87D7d289a738F81 |
| Avalanche | 1 | 0x8186359aF5F57FbB40c6b14A588d2A59C0C29880 |
| OP Mainnet | 2 | 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8 |
| Arbitrum | 3 | 0xC30362313FBBA5cf9163F0bb16a0e01f01A896ca |
| Base | 6 | 0xAD09780d193884d503182aD4588450C416D6F9D4 |
| Polygon PoS | 7 | 0xF3be9355363857F3e001be68856A2f96b4C39Ba9 |
| Unichain | 10 | 0x353bE9E2E38AB1D19104534e4edC21c643Df86f4 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum | 0 | 0xc4922d64a24675E16e1586e3e3Aa56C06fABe907 |
| Avalanche | 1 | 0x420F5035fd5dC62a167E7e7f08B604335aE272b8 |
| OP Mainnet | 2 | 0x33E76C5C31cb928dc6FE6487AB3b2C0769B1A1e3 |
| Arbitrum | 3 | 0xE7Ed1fa7f45D05C508232aa32649D89b73b8bA48 |
| Base | 6 | 0xe45B133ddc64bE80252b0e9c75A8E74EF280eEd6 |
| Polygon PoS | 7 | 0x10f7835F827D6Cf035115E10c50A853d7FB2D2EC |
| Unichain | 10 | 0x726bFEF3cBb3f8AF7d8CB141E78F86Ae43C34163 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum | 0 | 0xB2f38107A18f8599331677C14374Fd3A952fb2c8 |
| Avalanche | 1 | 0x21F337db7A718F23e061262470Af8c1Fd01232D1 |
| OP Mainnet | 2 | 0xDB2831EaF163be1B564d437A97372deB0046C70D |
| Arbitrum | 3 | 0xE189BDCFbceCEC917b937247666a44ED959D81e4 |
| Base | 6 | 0x827ae40E55C4355049ab91e441b6e269e4091441 |
| Polygon PoS | 7 | 0x02d9fa3e7f870E5FAA7Ca6c112031E0ddC5E646C |
| Unichain | 10 | 0x395b1be6E432033B676e3e36B2c2121a1f952622 |
Select the applicable CCTP version below:
- CCTP V1
- CCTP V2
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5 |
| Avalanche Fuji | 1 | 0xeb08f243E5d3FCFF26A9E38Ae5520A669f4019d0 |
| OP Sepolia | 2 | 0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5 |
| Arbitrum Sepolia | 3 | 0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5 |
| Base Sepolia | 6 | 0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5 |
| Polygon PoS Amoy | 7 | 0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5 |
| Unichain Sepolia | 10 | 0x8ed94B8dAd2Dc5453862ea5e316A8e71AAed9782 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0x7865fAfC2db2093669d92c0F33AeEF291086BEFD |
| Avalanche Fuji | 1 | 0xa9fB1b3009DCb79E2fe346c16a604B8Fa8aE0a79 |
| OP Sepolia | 2 | 0x7865fAfC2db2093669d92c0F33AeEF291086BEFD |
| Arbitrum Sepolia | 3 | 0xaCF1ceeF35caAc005e15888dDb8A3515C41B4872 |
| Base Sepolia | 6 | 0x7865fAfC2db2093669d92c0F33AeEF291086BEFD |
| Polygon PoS Amoy | 7 | 0x7865fAfC2db2093669d92c0F33AeEF291086BEFD |
| Unichain Sepolia | 10 | 0xbc498c326533d675cf571B90A2Ced265ACb7d086 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0xE997d7d2F6E065a9A93Fa2175E878Fb9081F1f0A |
| Avalanche Fuji | 1 | 0x4ED8867f9947A5fe140C9dC1c6f207F3489F501E |
| OP Sepolia | 2 | 0xE997d7d2F6E065a9A93Fa2175E878Fb9081F1f0A |
| Arbitrum Sepolia | 3 | 0xE997d7d2F6E065a9A93Fa2175E878Fb9081F1f0A |
| Base Sepolia | 6 | 0xE997d7d2F6E065a9A93Fa2175E878Fb9081F1f0A |
| Polygon PoS Amoy | 7 | 0xE997d7d2F6E065a9A93Fa2175E878Fb9081F1f0A |
| Unichain Sepolia | 10 | 0x7348358C94519Da790DB38638d8c23669d343Bc6 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0x80537e4e8bAb73D21096baa3a8c813b45CA0b7c9 |
| Avalanche Fuji | 1 | 0xeAf1DB5E3eb86FEbD8080368a956622b62Dcb78f |
| OP Sepolia | 2 | 0xffbeA106ce4A3CdAfcC82BAebeD78C81814e32Ed |
| Arbitrum Sepolia | 3 | 0x70fAB9868cd54E12C7d87196424d6E0ca21be534 |
| Base Sepolia | 6 | 0x8E52a9e76148185536F0f0779749Cc895E5f70dC |
| Polygon PoS Amoy | 7 | 0x8E52a9e76148185536F0f0779749Cc895E5f70dC |
| Unichain Sepolia | 10 | 0x1Fae490d95dDcFFD70728AF5024C524ed303a2e3 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Avalanche Fuji | 1 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Arbitrum Sepolia | 3 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Base Sepolia | 6 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Linea Sepolia | 11 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Sonic Testnet | 13 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| World Chain Sepolia | 14 | 0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Avalanche Fuji | 1 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Arbitrum Sepolia | 3 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Base Sepolia | 6 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Linea Sepolia | 11 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Sonic Testnet | 13 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| World Chain Sepolia | 14 | 0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Avalanche Fuji | 1 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Arbitrum Sepolia | 3 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Base Sepolia | 6 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Linea Sepolia | 11 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Sonic Testnet | 13 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| World Chain Sepolia | 14 | 0xb43db544E2c27092c107639Ad201b3dEfAbcF192 |
| Chain | Domain | Address |
|---|---|---|
| Ethereum Sepolia | 0 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| Avalanche Fuji | 1 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| Arbitrum Sepolia | 3 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| Base Sepolia | 6 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| Linea Sepolia | 11 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| Sonic Testnet | 13 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
| World Chain Sepolia | 14 | 0xbaC0179bB358A8936169a63408C8481D582390C4 |
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
| Field | Type | Description |
|---|---|---|
amount | uint256 | Amount of tokens to deposit and burn |
destinationDomain | uint32 | Destination domain identifier |
mintRecipient | bytes32 | Address of mint recipient on destination domain |
burnToken | address | Address 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
| Field | Type | Description |
|---|---|---|
amount | uint256 | Amount of tokens to deposit and burn |
destinationDomain | uint32 | Destination domain identifier |
mintRecipient | bytes32 | Address of mint recipient on destination domain |
burnToken | address | Address of contract to burn deposited tokens on local domain |
destinationCaller | bytes32 | Address 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
| Field | Type | Description |
|---|---|---|
originalMessage | bytes calldata | Original message bytes (to replace) |
originalAttestation | bytes calldata | Original attestation bytes |
newDestinationCaller | bytes32 | The 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 |
newMintRecipient | bytes32 | The 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
| Field | Type | Description |
|---|---|---|
message | bytes calldata | Message bytes |
attestation | bytes calldata | Signed 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
| Field | Type | Description |
|---|---|---|
destinationDomain | uint32 | Destination domain identifier |
recipient | bytes32 | Address to handle message body on destination domain |
messageBody | bytes calldata | App-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
| Field | Type | Description |
|---|---|---|
destinationDomain | uint32 | Destination domain identifier |
recipient | bytes32 | Address of message recipient on destination domain |
destinationCaller | bytes32 | Address of caller on the destination domain |
messageBody | bytes calldata | App-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
| Field | Type | Description |
|---|---|---|
originalMessage | bytes calldata | Original message to replace |
originalAttestation | bytes calldata | Attestation of originalMessage |
newMessageBody | bytes calldata | New message body of replaced message |
newDestinationCaller | bytes32 | The 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) |
The interface below serves as a reference for permissionless messaging functions exposed by the TokenMessengerV2 and MessageTransmitterV2 functions.
TokenMessengerV2#depositForBurnWithHook(extendsdepositForBurnby adding hook data)TokenMessengerV2#handleReceiveUnfinalizedMessage(replaceshandleReceiveMessage)TokenMessengerV2#handleReceiveFinalizedMessage(replaceshandleReceiveMessage)
TokenMessengerV2#depositForBurnMessageTransmitterV2#sendMessageMessageTransmitterV2#receiveMessage
TokenMessengerV2#handleReceiveMessageTokenMessengerV2#replaceDepositForBurnTokenMessengerV2#depositForBurnWithCallerMessageTransmitterV2#replaceMessageMessageTransmitterV2#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
| Field | Type | Description |
|---|---|---|
amount | uint256 | Amount of tokens to deposit and burn |
destinationDomain | uint32 | Destination domain ID to send the message to |
mintRecipient | bytes32 | Address of mint recipient on destination domain (must be converted to 32 byte array, that is, prefix with zeros if needed) |
burnToken | address | Address of contract to burn deposited tokens on local domain |
destinationCaller | bytes32 | Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage |
maxFee | uint256 | Max fee paid for fast burn, specified in units of burnToken |
minFinalityThreshold | uint32 | Minimum 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
| Field | Type | Description |
|---|---|---|
amount | uint256 | Amount of tokens to burn |
destinationDomain | uint32 | Destination domain to send the message to |
mintRecipient | bytes32 | Address of mint recipient on destination domain (must be converted to 32 byte array, that is, prefix with zeros if needed) |
burnToken | address | Address of contract to burn deposited tokens on local domain |
destinationCaller | bytes32 | Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage |
maxFee | uint256 | Max fee paid for fast burn, specified in units of burnToken |
minFinalityThreshold | uint32 | Minimum finality threshold at which burn will be attested |
hookData | bytes | Additional metadata attached to the attested message, which can be used to trigger custom logic on the destination chain |
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
| Field | Type | Description |
|---|---|---|
remoteDomain | uint32 | The domain where the message originated from |
sender | bytes32 | The sender of the message (remote TokenMessenger) |
finalityThresholdExecuted | uint32 | Specifies the level of finality Iris signed the message with |
messageBody | bytes (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. IfexpirationBlock≤blockNumberon the destination domain, the message will revert and must be re-signed without the expiration block.feeExecuted. If nonzero, thefeeExecutedis minted to thefeeRecipient.
Parameters
| Field | Type | Description |
|---|---|---|
remoteDomain | uint32 | The domain where the message originated from |
sender | bytes32 | The sender of the message (remote TokenMessenger) |
finalityThresholdExecuted | uint32 | Specifies the level of finality Iris signed the message with |
messageBody | bytes (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
| Field | Type | Description |
|---|---|---|
message | bytes | Encoded message (see Message format) |
attestation | bytes | Signed 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
| Field | Type | Description |
|---|---|---|
destinationDomain | uint32 | Destination domain ID to send the message to |
recipient | bytes32 | Address of recipient on destination domain |
destinationCaller | bytes32 | Address as bytes32 which can call receiveMessage on destination domain. If set to bytes32(0), any address can call receiveMessage |
minFinalityThreshold | uint32 | Minimum 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 |
messageBody | bytes | App-specific message to be handled by recipient |
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 V1 | CCTP 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.
