Overview

Solana CCTP programs are written in Rust and leverage the Anchor framework. The Solana CCTP protocol implementation is split into two programs: MessageTransmitter and TokenMessengerMinter. TokenMessengerMinter encapsulates the functionality of both TokenMessenger and TokenMinter contracts on EVM chains. To ensure alignment with EVM contracts' logic and state, and to facilitate future upgrades and maintenance, the code and state of Solana programs reflect the EVM counterparts as closely as possible.

Mainnet Program Addresses

Devnet Program Addresses

The Solana CCTP source code is available at https://github.com/circlefin/solana-cctp-contracts/. The interface below serves as a reference for permissionless messaging functions exposed by the programs.

Interface

The interface below serves as a reference for permissionless messaging functions exposed by the TokenMessengerMinter and MessageTransmitter programs. The full IDLs can be found here and here.

Please see the instruction rust files or quick-start for PDA information.

TokenMessengerMinter

depositForBurn

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

Parameters

📘

MessageSent event storage

To ensure persistent and reliable message storage, MessageSent events are stored in accounts. MessageSent event accounts are generated client-side, passed into the instruction call, and assigned to have the MessageTransmitter program as the owner. Please see the Quickstart Guide for how to generate this account and pass it to the instruction call.

For depositForBurn messages, this costs ~0.00295104 SOL in rent. This rent is paid by the event_rent_payer account which can be the user or subsidized by a calling program or integrator.

Once an attestation is available and the message has been received on the destination chain, the event account can be closed and have the SOL reclaimed to the event_rent_payer account. This is done by calling the reclaim_event_account instruction. This can only be called by the event_rent_payer account from when the message was sent.

Details on the message format can be found on the Message Format page.

depositForBurnWithCaller

The 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

replaceDepositForBurn

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.

📘

Note on replaceDepositForBurn

Only the owner account 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 on-chain. When using a third-party app/bridge that integrates with CCTP 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.

Parameters

MessageTransmitter

receiveMessage

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

Remaining Accounts

If the receiveMessage instruction is being called with a deposit for burn message that will be received by the TokenMessengerMinter, additional remainingAccounts are required so they can be passed with the CPI to TokenMessengerMinter#handleReceiveMessage:

sendMessage

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

Parameters

sendMessageWithCaller

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

replaceMessage

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.

Parameters

reclaimEventAccount

Closes the given event account and reclaims the paid rent in SOL back to the event_rent_payer account. This instruction can only be called by the event_rent_payer account that paid the rent when the message was sent.

Parameters

🚧

Warning

Once this instruction is executed for a message account, the message can no longer be read on-chain. We recommend not calling this instruction until the message has been received on the destination chain. If the message is lost before receiving the message, it can be fetched from the attestation service using the messages endpoint.

Additional Notes

Mint Recipient for Solana as Destination Chain Transfers

When calling depositForBurn on a non-Solana chain with Solana as the destination, the mintRecipient should be a hex encoded USDC token account address. The token account must exist at the time receiveMessage is called on Solana or else this instruction will revert. An example of converting an address from Base58 to hex taken from the Solana quickstart tutorial in Typescript can be seen below:

import { bs58 } from "@coral-xyz/anchor/dist/cjs/utils/bytes";
import { hexlify } from "ethers";

const solanaAddressToHex = (solanaAddress: string): string => hexlify(bs58.decode(solanaAddress));

Mint Recipient for Solana as Source Chain Transfers

When specifying the mintRecipient for Solana depositForBurn instruction calls, the address must be given as the 32 byte version of the hex address in base58 format. An example taken fro the Solana quickstart tutorial in Typescript can be seen below:

import { getBytes } from 'ethers';
import { PublicKey } from '@solana/web3.js';

const evmAddressToBytes32 = (address: string): string => `0x000000000000000000000000${address.replace("0x", "")}`;

const evmAddressToBase58PublicKey = (addressHex: string): PublicKey => new PublicKey(getBytes(evmAddressToBytes32(addressHex)));

Program Events

Program events like DepositForBurn , MintAndWithdraw , and MessageReceived are emitted as Anchor CPI events. This means a self-CPI is made into the program with the serialized event as instruction data so it is persisted in the transaction and can be fetched later on as needed. More information can be seen in the Anchor implementation PR, and an example of reading CPI events can be seen here.

MessageSent events are different, as they are stored in accounts. Please see the MessageSent Event Storage section for more info.