Where TradFi and DeFi converge

Chainlink SmartCon is the convergence point for the worlds of blockchain and finance, where digital asset leaders, DeFi pioneers, and onchain builders come together to invent the future of global markets and Web3.

👉 REGISTER NOW

Event Highlights

Hacker House | October 28-29

Build alongside onchain innovators developing real-world applications that scale blockchain tech to billions of users worldwide.

SmartCon Main Event | October 30-31

Get cutting-edge insights from global financial institutions, premier DeFi protocols, and game-changing startups.

Past SmartCon Speakers

Eric Schmidt, former CEO, Google

Jonathan Ehrenfeld Solé, Strategy Director, SWIFT

Balaji Srinivasan, Angel Investor and Former CTO, Coinbase

Laurence Moroney, AI Lead, Google

Joseph Chan, Under Secretary for Financial Services and The Treasury, Hong Kong SAR

Oliver Roucloux, Business Analyst & Product Owner, Euroclear

Rashmi Misra, General Manager AI & Emerging Technologies Business Development, Microsoft

Please make sure you have completed these steps ahead of Day 1:

• MetaMask

• GitHub profile (required for test tokens, and homework exercises)

• Avalanche Fuji, Ethereum Sepolia, Arbitrum Sepolia testnets added

• Test LINK, AVAX, ETH, ARB

  • if you have difficulties please use Bootcamp Faucet

  • password: BigMac777

• Test USDC on Avalanche Fuji

If you have any questions, please ask them on discord: https://discord.gg/m9vSfK65

Introduction to Transporter

Transporter is a highly secure interface for bridging tokens across blockchains with total peace of mind. Transporter is built on top of Chainlink CCIP, the industry-leading cross-chain protocol for defense-in-depth security. Transporter is the cross-chain bridging app for transferring digital assets across blockchains and experiencing the best that each chain has to offer. In just a few clicks, you can bridge your tokens and cross chains with confidence knowing that Transporter is underpinned by Chainlink CCIP’s Level-5 Security, offers users real-time transaction tracking, and is available to provide 24/7 support.

Warm-up Exercise: Let's bridge some testnet tokens

Video tutorial: https://www.youtube.com/watch?v=dCDQ-xetzpM

Navigate to https://test.transporter.io/

Connect your wallet by clicking the "Connect wallet button"

Select your Source and Destination Network of choice. I am going to send tokens from Avalanche Fuji to Ethereum Sepolia.

Then select Token you want to send (we can also send Messages). I am going to use USDC.

If you need tesnet USDC, you can get 10 units from the https://faucet.circle.com/

Then select the amount of tokens you want to send. I am going to choose 1 USDC.

And approve Transporter to transfer that amount of tokens on behalf of you, by clicking the "Approve USDC" button.

The next step is to select token you would like to use to pay for CCIP fees. By default the native coin of the source blockchain is selected (AVAX), but I am going to use LINK because it is cheaper.

Finally, initiate the transfer by clicking the "Send" button.

You can now sit back, relax and monitor your first cross-chain transfer in real time!

Once your transaction is completed on the source blockchain (Avalanche Fuji in this example) you can monitor it on Chainlink CCIP Block Explorer as well - at https://ccip.chain.link.

Bookmark this URL, because we are going to use it a lot during this bootcamp.

To navigate to the Chainlink CCIP Block Explorer click the "View transaction" button.

Once the transaction on the source blockchain is finalized, Chainlink DONs can proceed with the cross-chain transfers. Finality is really important security concept in blockchain technology, so make sure you familiarize yourself with it by the end of this bootcamp.

Finally, we just need to wait for a destination transaction to be included in the next Ethereum Sepolia block.

And that's it! Transport is completed, simple as that!

You can of course always come back to Chainlink CCIP Block Explorer to see more details about the transfer.

Chainlink’s tokenization bootcamp offers an exciting journey for Web3 developers, elevating your skills in bringing real-world assets onchain using Chainlink's cutting-edge tokenization infrastructure.

Secure Your Spot Before Anyone Else. September 30 - October 2, 2024

👉

Join us for a three-day tokenization adventure, where you’ll tokenize a house onchain. You’ll learn to enhance it with diverse data points, securely transfer it across chains, and unlock its potential beyond the capabilities of traditional systems.

What You’ll Learn:

• Steps to create and enrich tokenized assets

• Key stages of onchain development for tokenized assets

• Strategies to maximize the potential of tokenized assets

• Powering a Unified Golden Record for tokenized assets

Richard Gottleber, Developer Relations Engineer, Chainlink Labs

X (Twitter):

Email:

Andrej Rakic, Developer Relations Engineer, Chainlink Labs

Darby Martinez, Developer Expert, Chainlink Community

Onchain Certificate of Completion will be issued to all qualifying participants - please make sure to complete your homework for each day!

Curriculum

Day 1

Theory

Exercises

Homework

Day 2

Theory

Exercises

Homework

Day 3

Homework

Another best practice that we will implement is so called Defensive Example, the pattern which allows us to reprocess failed messages without forcing the original transaction to fail. Let's explain how it works.

Receiving and processing messages

Upon receiving a message on the destination blockchain, the ccipReceive function is called by the CCIP Router. This function serves as the entry point to the contract for processing incoming CCIP messages, enforcing crucial security checks through the onlyRouter, and onlyAllowlisted modifiers.

Here's the step-by-step breakdown of the process:

1. Entrance through ccipReceive:

   • The ccipReceive function is invoked with an Any2EVMMessage struct containing the message to be processed.

   • Security checks ensure the call is from the authorized router, an allowlisted source chain, and an allowlisted sender.

2. Processing Message:

   • ccipReceive calls the processMessage function, which is external to leverage Solidity's try/catch error handling mechanism. Note: The onlySelf modifier ensures that only the contract can call this function.

   • Inside processMessage, a check is performed for a simulated revert condition using the s_simRevert state variable. This simulation is toggled by the setSimRevert function, callable only by the contract owner.

   • If s_simRevert is false, processMessage calls the _ccipReceive function for further message processing.

3. Message Processing in _ccipReceive:

   • _ccipReceive extracts and stores various information from the message, such as the messageId, decoded sender address, token amounts, and data.

   • It then emits a MessageReceived event, signaling the successful processing of the message.

4. Error Handling:

   • If an error occurs during the processing (or a simulated revert is triggered), the catch block within ccipReceive is executed.

   • The messageId of the failed message is added to s_failedMessages, and the message content is stored in s_messageContents.

   • A MessageFailed event is emitted, which allows for later identification and reprocessing of failed messages.

Reprocessing of failed messages

The retryFailedMessage function provides a mechanism to recover assets if a CCIP message processing fails. It's specifically designed to handle scenarios where message data issues prevent entire processing yet allow for token recovery:

1. Initiation:

   • Only the contract owner can call this function, providing the messageId of the failed message and the tokenReceiver address for token recovery.

2. Validation:

   • It checks if the message has failed using s_failedMessages.get(messageId). If not, it reverts the transaction.

3. Status Update:

   • The error code for the message is updated to RESOLVED to prevent reentry and multiple retries.

4. Token Recovery:

   • Retrieves the failed message content using s_messageContents[messageId].

   • Transfers the locked tokens associated with the failed message to the specified tokenReceiver as an escape hatch without processing the entire message again.

5. Event Emission:

   • An event MessageRecovered is emitted to signal the successful recovery of the tokens.

This function showcases a graceful asset recovery solution, protecting user values even when message processing encounters issues.

Transfer Tokens With Data - Defensive Example

This tutorial extends the programmable token transfers example. It uses Chainlink CCIP to transfer tokens and arbitrary data between smart contracts on different blockchains, and focuses on defensive coding in the receiver contract. In the event of a specified error during the CCIP message reception, the contract locks the tokens. Locking the tokens allows the owner to recover and redirect them as needed. Defensive coding is crucial as it enables the recovery of locked tokens and ensures the protection of your users' assets.

Before You Begin

1. You should understand how to write, compile, deploy, and fund a smart contract. If you need to brush up on the basics, read this tutorial, which will guide you through using the Solidity programming language, interacting with the MetaMask wallet and working within the Remix Development Environment.

2. Your account must have some AVAX and LINK tokens on Avalanche Fuji and ETH tokens on Ethereum Sepolia. Learn how to Acquire testnet LINK.

3. Check the Supported Networks page to confirm that the tokens you will transfer are supported for your lane. In this example, you will transfer tokens from Avalanche Fuji to Ethereum Sepolia so check the list of supported tokens here.

4. Learn how to acquire CCIP test tokens. Following this guide, you should have CCIP-BnM tokens, and CCIP-BnM should appear in the list of your tokens in MetaMask.

5. Learn how to fund your contract. This guide shows how to fund your contract in LINK, but you can use the same guide for funding your contract with any ERC20 tokens as long as they appear in the list of tokens in MetaMask.

6. Follow the previous tutorial: Transfer Tokens with Data to learn how to make programmable token transfers using CCIP.

Coding time!

In this exercise, we'll initiate a transaction from a smart contract on Avalanche Fuji, sending a string text and CCIP-BnM tokens to another smart contract on Ethereum Sepolia using CCIP. However, a deliberate failure in the processing logic will occur upon reaching the receiver contract. This tutorial will demonstrate a graceful error-handling approach, allowing the contract owner to recover the locked tokens.

CORRECTLY ESTIMATE YOUR GAS LIMIT

It is crucial to thoroughly test all scenarios to accurately estimate the required gas limit, including for failure scenarios. Be aware that the gas used to execute the error-handling logic for failure scenarios may be higher than that for successful scenarios.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

import {IRouterClient} from "@chainlink/contracts-ccip/src/v0.8/ccip/interfaces/IRouterClient.sol";
import {OwnerIsCreator} from "@chainlink/contracts-ccip/src/v0.8/shared/access/OwnerIsCreator.sol";
import {Client} from "@chainlink/contracts-ccip/src/v0.8/ccip/libraries/Client.sol";
import {CCIPReceiver} from "@chainlink/contracts-ccip/src/v0.8/ccip/applications/CCIPReceiver.sol";
import {IERC20} from "@chainlink/contracts-ccip/src/v0.8/vendor/openzeppelin-solidity/v4.8.3/contracts/token/ERC20/IERC20.sol";
import {SafeERC20} from "@chainlink/contracts-ccip/src/v0.8/vendor/openzeppelin-solidity/v4.8.3/contracts/token/ERC20/utils/SafeERC20.sol";
import {EnumerableMap} from "@chainlink/contracts-ccip/src/v0.8/vendor/openzeppelin-solidity/v4.8.3/contracts/utils/structs/EnumerableMap.sol";

/**
 * THIS IS AN EXAMPLE CONTRACT THAT USES HARDCODED VALUES FOR CLARITY.
 * THIS IS AN EXAMPLE CONTRACT THAT USES UN-AUDITED CODE.
 * DO NOT USE THIS CODE IN PRODUCTION.
 */

/// @title - A simple messenger contract for transferring/receiving tokens and data across chains.
/// @dev - This example shows how to recover tokens in case of revert
contract ProgrammableDefensiveTokenTransfers is CCIPReceiver, OwnerIsCreator {
    using EnumerableMap for EnumerableMap.Bytes32ToUintMap;
    using SafeERC20 for IERC20;

    // Custom errors to provide more descriptive revert messages.
    error NotEnoughBalance(uint256 currentBalance, uint256 calculatedFees); // Used to make sure contract has enough balance to cover the fees.
    error NothingToWithdraw(); // Used when trying to withdraw Ether but there's nothing to withdraw.
    error FailedToWithdrawEth(address owner, address target, uint256 value); // Used when the withdrawal of Ether fails.
    error DestinationChainNotAllowlisted(uint64 destinationChainSelector); // Used when the destination chain has not been allowlisted by the contract owner.
    error SourceChainNotAllowed(uint64 sourceChainSelector); // Used when the source chain has not been allowlisted by the contract owner.
    error SenderNotAllowed(address sender); // Used when the sender has not been allowlisted by the contract owner.
    error InvalidReceiverAddress(); // Used when the receiver address is 0.
    error OnlySelf(); // Used when a function is called outside of the contract itself.
    error ErrorCase(); // Used when simulating a revert during message processing.
    error MessageNotFailed(bytes32 messageId);

    // Example error code, could have many different error codes.
    enum ErrorCode {
        // RESOLVED is first so that the default value is resolved.
        RESOLVED,
        // Could have any number of error codes here.
        FAILED
    }

    struct FailedMessage {
        bytes32 messageId;
        ErrorCode errorCode;
    }

    // Event emitted when a message is sent to another chain.
    event MessageSent(
        bytes32 indexed messageId, // The unique ID of the CCIP message.
        uint64 indexed destinationChainSelector, // The chain selector of the destination chain.
        address receiver, // The address of the receiver on the destination chain.
        string text, // The text being sent.
        address token, // The token address that was transferred.
        uint256 tokenAmount, // The token amount that was transferred.
        address feeToken, // the token address used to pay CCIP fees.
        uint256 fees // The fees paid for sending the message.
    );

    // Event emitted when a message is received from another chain.
    event MessageReceived(
        bytes32 indexed messageId, // The unique ID of the CCIP message.
        uint64 indexed sourceChainSelector, // The chain selector of the source chain.
        address sender, // The address of the sender from the source chain.
        string text, // The text that was received.
        address token, // The token address that was transferred.
        uint256 tokenAmount // The token amount that was transferred.
    );

    event MessageFailed(bytes32 indexed messageId, bytes reason);
    event MessageRecovered(bytes32 indexed messageId);

    bytes32 private s_lastReceivedMessageId; // Store the last received messageId.
    address private s_lastReceivedTokenAddress; // Store the last received token address.
    uint256 private s_lastReceivedTokenAmount; // Store the last received amount.
    string private s_lastReceivedText; // Store the last received text.

    // Mapping to keep track of allowlisted destination chains.
    mapping(uint64 => bool) public allowlistedDestinationChains;

    // Mapping to keep track of allowlisted source chains.
    mapping(uint64 => bool) public allowlistedSourceChains;

    // Mapping to keep track of allowlisted senders.
    mapping(address => bool) public allowlistedSenders;

    IERC20 private s_linkToken;

    // The message contents of failed messages are stored here.
    mapping(bytes32 messageId => Client.Any2EVMMessage contents)
        public s_messageContents;

    // Contains failed messages and their state.
    EnumerableMap.Bytes32ToUintMap internal s_failedMessages;

    // This is used to simulate a revert in the processMessage function.
    bool internal s_simRevert = false;

    /// @notice Constructor initializes the contract with the router address.
    /// @param _router The address of the router contract.
    /// @param _link The address of the link contract.
    constructor(address _router, address _link) CCIPReceiver(_router) {
        s_linkToken = IERC20(_link);
    }

    /// @dev Modifier that checks if the chain with the given destinationChainSelector is allowlisted.
    /// @param _destinationChainSelector The selector of the destination chain.
    modifier onlyAllowlistedDestinationChain(uint64 _destinationChainSelector) {
        if (!allowlistedDestinationChains[_destinationChainSelector])
            revert DestinationChainNotAllowlisted(_destinationChainSelector);
        _;
    }

    /// @dev Modifier that checks if the chain with the given sourceChainSelector is allowlisted and if the sender is allowlisted.
    /// @param _sourceChainSelector The selector of the destination chain.
    /// @param _sender The address of the sender.
    modifier onlyAllowlisted(uint64 _sourceChainSelector, address _sender) {
        if (!allowlistedSourceChains[_sourceChainSelector])
            revert SourceChainNotAllowed(_sourceChainSelector);
        if (!allowlistedSenders[_sender]) revert SenderNotAllowed(_sender);
        _;
    }

    /// @dev Modifier that checks the receiver address is not 0.
    /// @param _receiver The receiver address.
    modifier validateReceiver(address _receiver) {
        if (_receiver == address(0)) revert InvalidReceiverAddress();
        _;
    }

    /// @dev Modifier to allow only the contract itself to execute a function.
    /// Throws an exception if called by any account other than the contract itself.
    modifier onlySelf() {
        if (msg.sender != address(this)) revert OnlySelf();
        _;
    }

    /// @dev Updates the allowlist status of a destination chain for transactions.
    /// @notice This function can only be called by the owner.
    /// @param _destinationChainSelector The selector of the destination chain to be updated.
    /// @param allowed The allowlist status to be set for the destination chain.
    function allowlistDestinationChain(
        uint64 _destinationChainSelector,
        bool allowed
    ) external onlyOwner {
        allowlistedDestinationChains[_destinationChainSelector] = allowed;
    }

    /// @dev Updates the allowlist status of a source chain
    /// @notice This function can only be called by the owner.
    /// @param _sourceChainSelector The selector of the source chain to be updated.
    /// @param allowed The allowlist status to be set for the source chain.
    function allowlistSourceChain(
        uint64 _sourceChainSelector,
        bool allowed
    ) external onlyOwner {
        allowlistedSourceChains[_sourceChainSelector] = allowed;
    }

    /// @dev Updates the allowlist status of a sender for transactions.
    /// @notice This function can only be called by the owner.
    /// @param _sender The address of the sender to be updated.
    /// @param allowed The allowlist status to be set for the sender.
    function allowlistSender(address _sender, bool allowed) external onlyOwner {
        allowlistedSenders[_sender] = allowed;
    }

    /// @notice Sends data and transfer tokens to receiver on the destination chain.
    /// @notice Pay for fees in LINK.
    /// @dev Assumes your contract has sufficient LINK to pay for CCIP fees.
    /// @param _destinationChainSelector The identifier (aka selector) for the destination blockchain.
    /// @param _receiver The address of the recipient on the destination blockchain.
    /// @param _text The string data to be sent.
    /// @param _token token address.
    /// @param _amount token amount.
    /// @return messageId The ID of the CCIP message that was sent.
    function sendMessagePayLINK(
        uint64 _destinationChainSelector,
        address _receiver,
        string calldata _text,
        address _token,
        uint256 _amount
    )
        external
        onlyOwner
        onlyAllowlistedDestinationChain(_destinationChainSelector)
        validateReceiver(_receiver)
        returns (bytes32 messageId)
    {
        // Create an EVM2AnyMessage struct in memory with necessary information for sending a cross-chain message
        // address(linkToken) means fees are paid in LINK
        Client.EVM2AnyMessage memory evm2AnyMessage = _buildCCIPMessage(
            _receiver,
            _text,
            _token,
            _amount,
            address(s_linkToken)
        );

        // Initialize a router client instance to interact with cross-chain router
        IRouterClient router = IRouterClient(this.getRouter());

        // Get the fee required to send the CCIP message
        uint256 fees = router.getFee(_destinationChainSelector, evm2AnyMessage);

        if (fees > s_linkToken.balanceOf(address(this)))
            revert NotEnoughBalance(s_linkToken.balanceOf(address(this)), fees);

        // approve the Router to transfer LINK tokens on contract's behalf. It will spend the fees in LINK
        s_linkToken.approve(address(router), fees);

        // approve the Router to spend tokens on contract's behalf. It will spend the amount of the given token
        IERC20(_token).approve(address(router), _amount);

        // Send the message through the router and store the returned message ID
        messageId = router.ccipSend(_destinationChainSelector, evm2AnyMessage);

        // Emit an event with message details
        emit MessageSent(
            messageId,
            _destinationChainSelector,
            _receiver,
            _text,
            _token,
            _amount,
            address(s_linkToken),
            fees
        );

        // Return the message ID
        return messageId;
    }

    /// @notice Sends data and transfer tokens to receiver on the destination chain.
    /// @notice Pay for fees in native gas.
    /// @dev Assumes your contract has sufficient native gas like ETH on Ethereum or MATIC on Polygon.
    /// @param _destinationChainSelector The identifier (aka selector) for the destination blockchain.
    /// @param _receiver The address of the recipient on the destination blockchain.
    /// @param _text The string data to be sent.
    /// @param _token token address.
    /// @param _amount token amount.
    /// @return messageId The ID of the CCIP message that was sent.
    function sendMessagePayNative(
        uint64 _destinationChainSelector,
        address _receiver,
        string calldata _text,
        address _token,
        uint256 _amount
    )
        external
        onlyOwner
        onlyAllowlistedDestinationChain(_destinationChainSelector)
        validateReceiver(_receiver)
        returns (bytes32 messageId)
    {
        // Create an EVM2AnyMessage struct in memory with necessary information for sending a cross-chain message
        // address(0) means fees are paid in native gas
        Client.EVM2AnyMessage memory evm2AnyMessage = _buildCCIPMessage(
            _receiver,
            _text,
            _token,
            _amount,
            address(0)
        );

        // Initialize a router client instance to interact with cross-chain router
        IRouterClient router = IRouterClient(this.getRouter());

        // Get the fee required to send the CCIP message
        uint256 fees = router.getFee(_destinationChainSelector, evm2AnyMessage);

        if (fees > address(this).balance)
            revert NotEnoughBalance(address(this).balance, fees);

        // approve the Router to spend tokens on contract's behalf. It will spend the amount of the given token
        IERC20(_token).approve(address(router), _amount);

        // Send the message through the router and store the returned message ID
        messageId = router.ccipSend{value: fees}(
            _destinationChainSelector,
            evm2AnyMessage
        );

        // Emit an event with message details
        emit MessageSent(
            messageId,
            _destinationChainSelector,
            _receiver,
            _text,
            _token,
            _amount,
            address(0),
            fees
        );

        // Return the message ID
        return messageId;
    }

    /**
     * @notice Returns the details of the last CCIP received message.
     * @dev This function retrieves the ID, text, token address, and token amount of the last received CCIP message.
     * @return messageId The ID of the last received CCIP message.
     * @return text The text of the last received CCIP message.
     * @return tokenAddress The address of the token in the last CCIP received message.
     * @return tokenAmount The amount of the token in the last CCIP received message.
     */
    function getLastReceivedMessageDetails()
        public
        view
        returns (
            bytes32 messageId,
            string memory text,
            address tokenAddress,
            uint256 tokenAmount
        )
    {
        return (
            s_lastReceivedMessageId,
            s_lastReceivedText,
            s_lastReceivedTokenAddress,
            s_lastReceivedTokenAmount
        );
    }

    /**
     * @notice Retrieves a paginated list of failed messages.
     * @dev This function returns a subset of failed messages defined by `offset` and `limit` parameters. It ensures that the pagination parameters are within the bounds of the available data set.
     * @param offset The index of the first failed message to return, enabling pagination by skipping a specified number of messages from the start of the dataset.
     * @param limit The maximum number of failed messages to return, restricting the size of the returned array.
     * @return failedMessages An array of `FailedMessage` struct, each containing a `messageId` and an `errorCode` (RESOLVED or FAILED), representing the requested subset of failed messages. The length of the returned array is determined by the `limit` and the total number of failed messages.
     */
    function getFailedMessages(
        uint256 offset,
        uint256 limit
    ) external view returns (FailedMessage[] memory) {
        uint256 length = s_failedMessages.length();

        // Calculate the actual number of items to return (can't exceed total length or requested limit)
        uint256 returnLength = (offset + limit > length)
            ? length - offset
            : limit;
        FailedMessage[] memory failedMessages = new FailedMessage[](
            returnLength
        );

        // Adjust loop to respect pagination (start at offset, end at offset + limit or total length)
        for (uint256 i = 0; i < returnLength; i++) {
            (bytes32 messageId, uint256 errorCode) = s_failedMessages.at(
                offset + i
            );
            failedMessages[i] = FailedMessage(messageId, ErrorCode(errorCode));
        }
        return failedMessages;
    }

    /// @notice The entrypoint for the CCIP router to call. This function should
    /// never revert, all errors should be handled internally in this contract.
    /// @param any2EvmMessage The message to process.
    /// @dev Extremely important to ensure only router calls this.
    function ccipReceive(
        Client.Any2EVMMessage calldata any2EvmMessage
    )
        external
        override
        onlyRouter
        onlyAllowlisted(
            any2EvmMessage.sourceChainSelector,
            abi.decode(any2EvmMessage.sender, (address))
        ) // Make sure the source chain and sender are allowlisted
    {
        /* solhint-disable no-empty-blocks */
        try this.processMessage(any2EvmMessage) {
            // Intentionally empty in this example; no action needed if processMessage succeeds
        } catch (bytes memory err) {
            // Could set different error codes based on the caught error. Each could be
            // handled differently.
            s_failedMessages.set(
                any2EvmMessage.messageId,
                uint256(ErrorCode.FAILED)
            );
            s_messageContents[any2EvmMessage.messageId] = any2EvmMessage;
            // Don't revert so CCIP doesn't revert. Emit event instead.
            // The message can be retried later without having to do manual execution of CCIP.
            emit MessageFailed(any2EvmMessage.messageId, err);
            return;
        }
    }

    /// @notice Serves as the entry point for this contract to process incoming messages.
    /// @param any2EvmMessage Received CCIP message.
    /// @dev Transfers specified token amounts to the owner of this contract. This function
    /// must be external because of the  try/catch for error handling.
    /// It uses the `onlySelf`: can only be called from the contract.
    function processMessage(
        Client.Any2EVMMessage calldata any2EvmMessage
    )
        external
        onlySelf
        onlyAllowlisted(
            any2EvmMessage.sourceChainSelector,
            abi.decode(any2EvmMessage.sender, (address))
        ) // Make sure the source chain and sender are allowlisted
    {
        // Simulate a revert for testing purposes
        if (s_simRevert) revert ErrorCase();

        _ccipReceive(any2EvmMessage); // process the message - may revert as well
    }

    /// @notice Allows the owner to retry a failed message in order to unblock the associated tokens.
    /// @param messageId The unique identifier of the failed message.
    /// @param tokenReceiver The address to which the tokens will be sent.
    /// @dev This function is only callable by the contract owner. It changes the status of the message
    /// from 'failed' to 'resolved' to prevent reentry and multiple retries of the same message.
    function retryFailedMessage(
        bytes32 messageId,
        address tokenReceiver
    ) external onlyOwner {
        // Check if the message has failed; if not, revert the transaction.
        if (s_failedMessages.get(messageId) != uint256(ErrorCode.FAILED))
            revert MessageNotFailed(messageId);

        // Set the error code to RESOLVED to disallow reentry and multiple retries of the same failed message.
        s_failedMessages.set(messageId, uint256(ErrorCode.RESOLVED));

        // Retrieve the content of the failed message.
        Client.Any2EVMMessage memory message = s_messageContents[messageId];

        // This example expects one token to have been sent, but you can handle multiple tokens.
        // Transfer the associated tokens to the specified receiver as an escape hatch.
        IERC20(message.destTokenAmounts[0].token).safeTransfer(
            tokenReceiver,
            message.destTokenAmounts[0].amount
        );

        // Emit an event indicating that the message has been recovered.
        emit MessageRecovered(messageId);
    }

    /// @notice Allows the owner to toggle simulation of reversion for testing purposes.
    /// @param simRevert If `true`, simulates a revert condition; if `false`, disables the simulation.
    /// @dev This function is only callable by the contract owner.
    function setSimRevert(bool simRevert) external onlyOwner {
        s_simRevert = simRevert;
    }

    function _ccipReceive(
        Client.Any2EVMMessage memory any2EvmMessage
    ) internal override {
        s_lastReceivedMessageId = any2EvmMessage.messageId; // fetch the messageId
        s_lastReceivedText = abi.decode(any2EvmMessage.data, (string)); // abi-decoding of the sent text
        // Expect one token to be transferred at once, but you can transfer several tokens.
        s_lastReceivedTokenAddress = any2EvmMessage.destTokenAmounts[0].token;
        s_lastReceivedTokenAmount = any2EvmMessage.destTokenAmounts[0].amount;
        emit MessageReceived(
            any2EvmMessage.messageId,
            any2EvmMessage.sourceChainSelector, // fetch the source chain identifier (aka selector)
            abi.decode(any2EvmMessage.sender, (address)), // abi-decoding of the sender address,
            abi.decode(any2EvmMessage.data, (string)),
            any2EvmMessage.destTokenAmounts[0].token,
            any2EvmMessage.destTokenAmounts[0].amount
        );
    }

    /// @notice Construct a CCIP message.
    /// @dev This function will create an EVM2AnyMessage struct with all the necessary information for programmable tokens transfer.
    /// @param _receiver The address of the receiver.
    /// @param _text The string data to be sent.
    /// @param _token The token to be transferred.
    /// @param _amount The amount of the token to be transferred.
    /// @param _feeTokenAddress The address of the token used for fees. Set address(0) for native gas.
    /// @return Client.EVM2AnyMessage Returns an EVM2AnyMessage struct which contains information for sending a CCIP message.
    function _buildCCIPMessage(
        address _receiver,
        string calldata _text,
        address _token,
        uint256 _amount,
        address _feeTokenAddress
    ) private pure returns (Client.EVM2AnyMessage memory) {
        // Set the token amounts
        Client.EVMTokenAmount[]
            memory tokenAmounts = new Client.EVMTokenAmount[](1);
        Client.EVMTokenAmount memory tokenAmount = Client.EVMTokenAmount({
            token: _token,
            amount: _amount
        });
        tokenAmounts[0] = tokenAmount;
        // Create an EVM2AnyMessage struct in memory with necessary information for sending a cross-chain message
        Client.EVM2AnyMessage memory evm2AnyMessage = Client.EVM2AnyMessage({
            receiver: abi.encode(_receiver), // ABI-encoded receiver address
            data: abi.encode(_text), // ABI-encoded string
            tokenAmounts: tokenAmounts, // The amount and type of token being transferred
            extraArgs: Client._argsToBytes(
                // Additional arguments, setting gas limit
                Client.EVMExtraArgsV1({gasLimit: 400_000})
            ),
            // Set the feeToken to a feeTokenAddress, indicating specific asset will be used for fees
            feeToken: _feeTokenAddress
        });
        return evm2AnyMessage;
    }

    /// @notice Fallback function to allow the contract to receive Ether.
    /// @dev This function has no function body, making it a default function for receiving Ether.
    /// It is automatically called when Ether is sent to the contract without any data.
    receive() external payable {}

    /// @notice Allows the contract owner to withdraw the entire balance of Ether from the contract.
    /// @dev This function reverts if there are no funds to withdraw or if the transfer fails.
    /// It should only be callable by the owner of the contract.
    /// @param _beneficiary The address to which the Ether should be sent.
    function withdraw(address _beneficiary) public onlyOwner {
        // Retrieve the balance of this contract
        uint256 amount = address(this).balance;

        // Revert if there is nothing to withdraw
        if (amount == 0) revert NothingToWithdraw();

        // Attempt to send the funds, capturing the success status and discarding any return data
        (bool sent, ) = _beneficiary.call{value: amount}("");

        // Revert if the send failed, with information about the attempted transfer
        if (!sent) revert FailedToWithdrawEth(msg.sender, _beneficiary, amount);
    }

    /// @notice Allows the owner of the contract to withdraw all tokens of a specific ERC20 token.
    /// @dev This function reverts with a 'NothingToWithdraw' error if there are no tokens to withdraw.
    /// @param _beneficiary The address to which the tokens will be sent.
    /// @param _token The contract address of the ERC20 token to be withdrawn.
    function withdrawToken(
        address _beneficiary,
        address _token
    ) public onlyOwner {
        // Retrieve the balance of this contract
        uint256 amount = IERC20(_token).balanceOf(address(this));

        // Revert if there is nothing to withdraw
        if (amount == 0) revert NothingToWithdraw();

        IERC20(_token).safeTransfer(_beneficiary, amount);
    }
}

Deploy Your Contracts

To use this contract:

1. Open the contract in Remix.

2. Compile your contract.

3. Deploy, fund your sender contract on Avalanche Fuji and enable sending messages to Ethereum Sepolia:

   1. Open MetaMask and select the network Avalanche Fuji.

   2. In Remix IDE, click on Deploy & Run Transactions and select Injected Provider - MetaMask from the environment list. Remix will then interact with your MetaMask wallet to communicate with Avalanche Fuji.

   4. Click the transact button. After you confirm the transaction, the contract address appears on the Deployed Contracts list. Note your contract address.

   6. Enable your contract to send CCIP messages to Ethereum Sepolia:

      1. In Remix IDE, under Deploy & Run Transactions, open the list of functions of your smart contract deployed on Avalanche Fuji.
4. Deploy your receiver contract on Ethereum Sepolia and enable receiving messages from your sender contract:

   1. Open MetaMask and select the network Ethereum Sepolia.

   2. In Remix IDE, under Deploy & Run Transactions, make sure the environment is still Injected Provider - MetaMask.

   4. Click the transact button. After you confirm the transaction, the contract address appears on the Deployed Contracts list. Note your contract address.

   5. Enable your contract to receive CCIP messages from Avalanche Fuji:

      1. In Remix IDE, under Deploy & Run Transactions, open the list of functions of your smart contract deployed on Ethereum Sepolia.
   6. Enable your contract to receive CCIP messages from the contract that you deployed on Avalanche Fuji:

      1. In Remix IDE, under Deploy & Run Transactions, open the list of functions of your smart contract deployed on Ethereum Sepolia.
   7. Call the setSimRevert function, passing true as a parameter, then wait for the transaction to confirm. Setting s_simRevert to true simulates a failure when processing the received message. Read the explanation section for more details.

At this point, you have one sender contract on Avalanche Fuji and one receiver contract on Ethereum Sepolia. As security measures, you enabled the sender contract to send CCIP messages to Ethereum Sepolia and the receiver contract to receive CCIP messages from the sender on Avalanche Fuji. The receiver contract cannot process the message, and therefore, instead of throwing an exception, it will lock the received tokens, enabling the owner to recover them.

Note: Another security measure enforces that only the router can call the _ccipReceive function. Read the explanation section for more details.

Recover the locked tokens

You will transfer 0.001 CCIP-BnM and a text. The CCIP fees for using CCIP will be paid in LINK.

2. Send a string data with tokens from Avalanche Fuji:

   1. Open MetaMask and select the network Avalanche Fuji.

   2. In Remix IDE, under Deploy & Run Transactions, open the list of functions of your smart contract deployed on Avalanche Fuji.

   3. Fill in the arguments of the sendMessagePayLINK function:
   4. Click on transact and confirm the transaction on MetaMask.

   5. After the transaction is successful, record the transaction hash. Here is an example of a transaction on Avalanche Fuji.

NOTE

During gas price spikes, your transaction might fail, requiring more than 0.5 LINK to proceed. If your transaction fails, fund your contract with more LINK tokens and try again.

1. Open the CCIP explorer and search your cross-chain transaction using the transaction hash.

1. The CCIP transaction is completed once the status is marked as "Success". In this example, the CCIP message ID is 0x120367995ef71f83d64a05bd7793862afda9d04049da4cb32851934490d03ae4.

1. Check the receiver contract on the destination chain:

   1. Open MetaMask and select the network Ethereum Sepolia.

   2. In Remix IDE, under Deploy & Run Transactions, open the list of functions of your smart contract deployed on Ethereum Sepolia.

   4. Notice the returned values are: 0x120367995ef71f83d64a05bd7793862afda9d04049da4cb32851934490d03ae4 (the message ID) and 1 (the error code indicating failure).

2. To recover the locked tokens, call the retryFailedMessage function:

1. After confirming the transaction, you can open it in a block explorer. Notice that the locked funds were transferred to the tokenReceiver address.

Note: These example contracts are designed to work bi-directionally. As an exercise, you can use them to transfer tokens with data from Avalanche Fuji to Ethereum Sepolia and from Ethereum Sepolia back to Avalanche Fuji.

Explanations

The smart contract featured in this tutorial is designed to interact with CCIP to transfer and receive tokens and data. The contract code is similar to the Transfer Tokens with Data tutorial. Hence, you can refer to its code explanation. We will only explain the main differences.

Sending messages

The sendMessagePayLINK function is similar to the sendMessagePayLINK function in the Transfer Tokens with Data tutorial. The main difference is the increased gas limit to account for the additional gas required to process the error-handling logic.

Receiving and processing messages

Upon receiving a message on the destination blockchain, the ccipReceive function is called by the CCIP router. This function serves as the entry point to the contract for processing incoming CCIP messages, enforcing crucial security checks through the onlyRouter, and onlyAllowlisted modifiers.

Here's the step-by-step breakdown of the process:

1. Entrance through ccipReceive:

   • The ccipReceive function is invoked with an Any2EVMMessage struct containing the message to be processed.

   • Security checks ensure the call is from the authorized router, an allowlisted source chain, and an allowlisted sender.

2. Processing Message:

   • ccipReceive calls the processMessage function, which is external to leverage Solidity's try/catch error handling mechanism. Note: The onlySelf modifier ensures that only the contract can call this function.

   • Inside processMessage, a check is performed for a simulated revert condition using the s_simRevert state variable. This simulation is toggled by the setSimRevert function, callable only by the contract owner.

   • If s_simRevert is false, processMessage calls the _ccipReceive function for further message processing.

3. Message Processing in _ccipReceive:

   • _ccipReceive extracts and stores various information from the message, such as the messageId, decoded sender address, token amounts, and data.

   • It then emits a MessageReceived event, signaling the successful processing of the message.

4. Error Handling:

   • If an error occurs during the processing (or a simulated revert is triggered), the catch block within ccipReceive is executed.

   • The messageId of the failed message is added to s_failedMessages, and the message content is stored in s_messageContents.

   • A MessageFailed event is emitted, which allows for later identification and reprocessing of failed messages.

Reprocessing of failed messages

The retryFailedMessage function provides a mechanism to recover assets if a CCIP message processing fails. It's specifically designed to handle scenarios where message data issues prevent entire processing yet allow for token recovery:

1. Initiation:

   • Only the contract owner can call this function, providing the messageId of the failed message and the tokenReceiver address for token recovery.

2. Validation:

   • It checks if the message has failed using s_failedMessages.get(messageId). If not, it reverts the transaction.

3. Status Update:

   • The error code for the message is updated to RESOLVED to prevent reentry and multiple retries.

4. Token Recovery:

   • Retrieves the failed message content using s_messageContents[messageId].

   • Transfers the locked tokens associated with the failed message to the specified tokenReceiver as an escape hatch without processing the entire message again.

5. Event Emission:

   • An event MessageRecovered is emitted to signal the successful recovery of the tokens.

This function showcases a graceful asset recovery solution, protecting user values even when message processing encounters issues.

Chainlink CCIP

General overview of the Chainlink CCIP

The interoperability problem

Interoperability is the ability to exchange information between different systems or networks, even if they are incompatible. Shared concepts on different networks ensure that each party understands and trusts the exchanged information. It also considers the concept of finality to establish trust in the exchanged information by validating its accuracy and integrity.

The Web3 ecosystem has become multi-chain, with the rise of layer-1 blockchains and layer-2 scaling solutions like appchains, subnets, and more, where each network has its own approach to scalability, security, and trust.

However, blockchains are isolated networks that operate independently and cannot communicate natively. To create a truly interoperable Web3 ecosystem, data and value must move seamlessly between chains. This is where bridges come in.

Traditional bridges are one of the biggest problems in today's Web3 ecosystem because they are centralized. When you are transferring funds from one chain to another using bridge, you are essentially giving your funds to some centralized entity, and you are trusting them that the funds will appear on the other side. And surprise, surprise, numerous bridge hacks have happened so far.

The solution - Chainlink CCIP

The Chainlink Cross-Chain Interoperability Protocol (CCIP) provides a single simple interface through which dApps and web3 entrepreneurs can securely meet all their cross-chain needs, including token transfers and arbitrary messaging.

Chainlink CCIP connects blockchain networks via lanes. The lane is a unique combination of source blockchain to destination blockchain path, e.g., from blockchain A to blockchain C. To transfer messages in reverse order, from blockchain C to blockchain A using Chianlink CCIP, you will need to use a different lane, the one which is unique to the C -> A path.

Chainlink CCIP will always support bi-directional lanes for each new chain added in the future. The logical question is how CCIP knows through which lane to transfer a CCIP cross-chain message. It's actually quite simple - each blockchain supported by CCIP has a unique chain selector.

We said multiple times that by using Chainlink CCIP, you can send cross-chain messages. But what can a cross-chain message consist of? With Chainlink CCIP, one can:

• Transfer (supported) tokens

• Send any kind of data

• Send both tokens and data

CCIP sender can be:

• EOA

• Any smart contract

CCIP receiver can be:

• EOA

• Any smart contract that implements CCIPReceiver.sol

Note: If you send a message and token(s) to EOA, only tokens will arrive.

For now, you can consider CCIP as a "black-box" component and be aware of the Router contract only. We will explain the Chainlink CCIP architecture in the following chapters.

The Router is the primary contract CCIP users interface with. This contract is responsible for initiating cross-chain interactions. One router contact exists per chain. When transferring tokens, callers have to approve the router contract to be able to "spend" (transfer) the caller's tokens. When a message is received on the destination chain, the router is the contract that “delivers” tokens to the user's account or the message to the receiver's smart contract.

Recap

The Chainlink Cross-Chain Interoperability Protocol provides a single interface to transfer tokens and data across multiple chains in a secure and decentralized manner.

Cross-Chain Swaps

CCIP Programmable Token Transfers enable cross-chain swap use cases, where any token can be effectively bridged over CCIP by connecting to liquidity pools / DEXs on the source and destination chains.

For example, a cross-chain swap app built on CCIP enables users holding Token A on Arbitrum to be swapped for Token B on Optimism by first swapping Token A on Arbitrum for USDC, bridging the USDC to Optimism along with data about the swap, and then automatically swapping the USDC to Token B and sending it to the user’s wallet. This is why CCIP’s support for native USDC is so powerful; it doesn’t just support the cross-chain transfer of native USDC via burn and mint, but also the simultaneous transmission of data on what to do with the USDC once it arrives on the destination chain—a unique feature of CCIP Programmable Token Transfers.

XSwap is a cross-chain swaps protocol and BUILD participant that uses CCIP for Programmable Token Transfers to enable cross-chain swaps between blockchain networks. USDC is used as the liquidity token for XSwap. Since its launch, XSwap users have initiated over $130M in CCIP Programmable Token Transfers.

Other users of CCIP Programmable Token Transfers include Transporter, ChainSwap, WEMIX PLAY, Amino Rewards, and more.

Cross-Chain Staking and Restaking

CCIP Programmable Token Transfers unlock innovation for cross-chain staking and restaking. End-users can stake/restake assets directly from a layer-2 network, where CCIP is used to transfer the native assets back to the layer-1 blockchain chain along with instructions to (re)stake the asset in a specified (re)staking protocol. This reduces gas costs for users and provides them the convenience to (re)stake from any chain.

For example, EigenPie is integrating Chainlink CCIP to enable its users to deposit ETH directly into their layer-2 contracts in order to receive the corresponding LRT (egETH) without ever having to leave the chain. Once users deposit ETH into the layer-2 contract, CCIP’s Programmable Token Transfers will bridge the tokens to Ethereum with instructions to restake them into Eigenlayer. CCIP is then used to lock the minted egETH on Ethereum and bridge it back to the L2 where it is minted and sent to the end user’s wallet address.

You can read more about Chainlink’s support for staking and restaking in the blog: How The Chainlink Platform Unlocks LST and LRT Adoption in DeFi. Learn how to implement Chainlink CCIP Programmable Token Transfers in the CCIP Masterclass: Cross-Chain Staking Edition for a more technical deep dive.

CCIP Programmable Token Transfers are critical to enabling cross-chain Delivery vs. Payment (DvP) transactions. DvP in traditional finance refers to the requirement that the delivery of assets (e.g., securities) and the payment for those assets happen simultaneously (i.e., atomic settlement). DvP is an important feature in reducing the risk that a counterparty won’t deliver on its leg of the transaction despite the other leg being fulfilled.

The Australia and New Zealand Banking Group Limited (ANZ) demonstrated how CCIP Programmable Token Transfers can enable a cross-border, cross-chain, cross-currency DvP transaction. In a single cross-chain transaction, a stablecoin backed by a local currency (NZ$DC) was converted to another stablecoin in a different national currency (A$DC), transferred from the buyer’s source chain to the seller’s destination chain along with the instruction to purchase a tokenized asset (e.g., reef credits), which was subsequently sent back to the customer’s wallet on the source chain.

To learn more, check out the case study Cross-Chain Settlement of Tokenized Assets Using CCIP written in collaboration with ANZ and the Sibos panel discussion between Chainlink Co-Founder Sergey Nazarov and ANZ’s Banking Services Lead Nigel Dobson.

The minimal CCIP architecture

To recap, with Chainlink CCIP, one can:

• Transfer (supported) tokens

• Send any kind of data

• Send both tokens and data

CCIP receiver can be:

• EOA

• Any smart contract that implements CCIPReceiver.sol

Note: If you send a message and token(s) to EOA, only tokens will arrive.

For now, you can consider CCIP as a "black-box" component and be aware of the Router contract only. We will explain the Chainlink CCIP architecture in the following chapters.

Getting started

You can use Chainlink CCIP with any blockchain development framework. For this Masterclass, we prepared the steps for Hardhat, Foundry, and Remix IDE.

Let's create a new project

node -v

npm -v

mkdir ccip-masterclass

cd ccip-masterclass

npx hardhat@2.14.1 init

forge --version

mkdir ccip-masterclass

cd ccip-masterclass

forge init

Alternatively, you can clone:

• CCIP Starter Kit (Hardhat version)

• CCIP Starter Kit (Foundry version)

The @chainlink/contracts-ccip NPM package

To use Chainlink CCIP, you need to interact with Chainlink CCIP-specific contracts from the @chainlink/contracts-ccip NPM package.

To install it, follow steps specific to the development environment you will use for this Masterclass.

npm i @chainlink/contracts-ccip --save-dev

# Node modules
node_modules/

npm i @chainlink/contracts-ccip --save-dev

libs = ['node_modules', 'lib']
remappings = [
    '@chainlink/contracts-ccip/=node_modules/@chainlink/contracts-ccip'
]

forge install smartcontractkit/ccip@ccip-develop

# foundry.toml
remappings = [
    '@chainlink/contracts-ccip/=lib/ccip/contracts/'
]

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

import {Client} from "@chainlink/contracts-ccip/src/v0.8/ccip/libraries/Client.sol";

contract Empty {}

Basic interface

Although, as being said, CCIP sender and receiver can be EOA and smart contract, and all combinations are possible, we are going to cover the most complex use-case where both CCIP sender and receiver are smart contracts on different blockchains.

Source blockchain

To send CCIP Messages, the smart contract on the source blockchain must call the ccipSend() function, which is defined the IRouterClient.sol interface.

// SOURCE BLOCKCHAIN 

interface IRouterClient {
    /// @notice Request a CCIP message to be sent to the destination chain
    /// @param destinationChainSelector The destination chain selector
    /// @param message The cross-chain CCIP message including data and/or tokens
    /// @return messageId The message ID
    function ccipSend(
        uint64 destinationChainSelector,
        Client.EVM2AnyMessage calldata message
    ) external payable returns(bytes32 messageId);
}

The CCIP Message which is being sent is a type of EVM2AnyMessage Solidity struct from the Client library.

// SOURCE BLOCKCHAIN

library Client {
    struct EVM2AnyMessage {
        bytes receiver; // abi.encode(receiver address) for dest EVM chains
        bytes data; // data payload
        EVMTokenAmount[] tokenAmounts; // token transfers
        address feeToken; // fee token address; address(0) means you are sending msg.value
        bytes extraArgs; // populate this with _argsToBytes(EVMExtraArgsV1)
    }
    
    struct EVMTokenAmount {
        address token; // token address on local blockchain
        uint256 amount;
    }
    
    struct EVMExtraArgsV1 {
        uint256 gasLimit;
        bool strict;
    }
}

Let's now understand what each property of the EVM2AnyMessage struct we are sending represents and how to use it.

receiver

Receiver address. It can be a smart contract or an EOA. Use abi.encode(receiver) to encode the address to the bytes Solidity data-type.

data

Payload sent within the CCIP message. This is that "any type of data" one can send as a CCIP Message we are referring to from the start. It can be anything from simple text like "Hello, world!" to Solidity structs or function selectors.

tokenAmounts

Tokens and their amounts in the source chain representation. Here we are specifying which tokens (out of supported ones) we are sending and how much of it. This is the array of a EVMTokenAmount struct, which consists of two properties only:

• token - Address of a token we are sending on the local (source) blockchain

• amount The amount of tokens we are sending. The sender must approve the CCIP router to spend this amount on behalf of the sender, otherwise the call to the ccipSend function will revert.

Currently, the maximum number of tokens one can send in a single CCIP send transaction is five.

feeToken

Address of feeToken. CCIP supports fee payments in LINK and in alternative assets, which currently include native blockchain gas coins and their ERC20 wrapped versions. For developers, this means you can simply pay on the source chain, and CCIP will take care of execution on the destination chain. Set address(0) to pay in native gas coins such as ETH on Ethereum or MATIC on Polygon. Keep in mind that even if you are paying for fees in the native asset, nodes in the Chainlink DON will be rewarded in LINK only.

extraArgs

Users fill in the EVMExtraArgsV1 struct and then encode it to bytes using the _argsToBytes function. The struct consists of two properties:

• gasLimit - The maximum amount of gas CCIP can consume to execute ccipReceive() on the contract located on the destination blockchain. Unspent gas is not refunded. This means that if you are sending tokens to EOA, for example, you should put 0 as a gasLimit value because EOAs can't implement the ccipReceive() (or any other) function. To estimate the accurate gas limit for your destination contract, consider Leveraging Ethereum client RPC by applying eth_estimateGas on receiver.ccipReceive() function, or use the Hardhat plugin for gas tests, or conduct Foundry gas tests.

• strict - Used for strict sequencing. You should set it to false. CCIP will always process messages sent from a specific sender to a specific destination blockchain in the order they were sent. If you set strict: true in the extraArgs part of the message, and if the ccipReceive fails (reverts), it will prevent any following messages from the same sender from being processed until the current message is successfully executed. You should be very careful when using this feature to avoid unintentionally stopping messages from the sender from being processed. The strict sequencing feature is currently experimental, and there is no guarantee of its maintenance or further development in the future.

If extraArgs are left empty, a.k.a extraArgs: "", a default of 200_000 gasLimit will be set with no strict sequencing. For production deployments, make sure that extraArgs is mutable. This allows you to build it off-chain and pass it in a call to a function or store it in a variable that you can update on demand. This makes extraArgs compatible with future CCIP upgrades.

Destination blockchain

To receive CCIP Messages, the smart contract on the destination blockchain must implement the IAny2EVMMessageReceiver interface. The @chainlink/contracts-ccip NPM package comes up with the contract which implements it in the right way, called CCIPReceiver.sol, but we are going to talk more about it in the next chapter. For now, let's understand which functions from the IAny2EVMMessageReceiver interface must be implemented in the general-case scenario.

// DESTINATION BLOCKCHAIN

/// @notice Application contracts that intend to receive messages from 
/// the router should implement this interface.
interface IAny2EVMMessageReceiver {
    /// @notice Router calls this to deliver a message
    /// @param message CCIP Message
    /// @dev Note ensure you check that msg.sender is the Router
    function ccipReceive(Client.Any2EVMMessage calldata message) external;
}

As you can see, the ccipReceive() function from the IAny2EVMMessageReceiver interface accepts object of the Any2EVMMessage struct from the Client library. This struct is the Solidity representation of the received CCIP Message. Please note that this struct, Any2EVMMessage is different than the one we used to send on the source blockchain - EVM2AnyMessage. They are not the same.

// DESTINATION BLOCKCHAIN

library Client {
    struct Any2EVMMessage {
        bytes32 messageId; // MessageId corresponding to ccipSend on source
        uint64 sourceChainSelector; // Source chain selector
        bytes sender; // abi.decode(sender) if coming from an EVM chain
        bytes data; // payload sent in original message
        EVMTokenAmount[] tokenAmounts; // Tokens and their amounts at destination
    }
    
    struct EVMTokenAmount {
        address token; // token address on local blockchain
        uint256 amount;
    }
}

Let's now understand what each property of the Any2EVMMessage struct we are receiving represents and how to use it.

• messageId - CCIP Message Id, generated on the source chain.

• sourceChainSelector - Source chain selector.

• sender - Sender address. abi.decode(sender, (address)) if the source chain is an EVM chain.

• data - Payload sent within the CCIP message. For example, "Hello, world!"

• tokenAmounts - Received tokens and their amounts in their destination chain representation.

To recap, here's the diagram with the minimal architecture needed to send & receive the Chainlink CCIP Message:

The Chainlink Cross-Chain Interoperability Protocol (CCIP) is far more than a simple token bridging solution. It’s a generalized cross-chain messaging protocol for transferring tokens (value), messages (data), or both tokens and messages simultaneously within a single cross-chain transaction—referred to as Programmable Token Transfers.

In effect, CCIP Programmable Token Transfers enable smart contracts to transfer tokens cross-chain along with instructions on what the receiving smart contract should do with those tokens once they arrive on the destination chain. This revolutionary concept of wrapping value and instructions together allows tokenized value to interact automatically and dynamically once it arrives at a destination, opening up a world of new possibilities.

In decentralized finance (DeFi), CCIP Programmable Token Transfers enable the creation of cross-chain native dApps, such as a smart contract that can automatically transfer tokens cross-chain and deposit them into the highest yield lending markets. Within traditional finance (TradFi), CCIP Programmable Token Transfers enable advanced use cases, such as a cross-chain delivery-vs-payment (DvP) transaction where an institution holding stablecoins on its private blockchain can purchase a tokenized asset issued on a different private or public chain.

Importantly, CCIP Programmable Token Transfers enable institutions to interact with smart contracts and tokenized assets on other blockchain networks without needing to integrate or directly interact with that blockchain. All they need to do is send instructions to CCIP on how to interact with that chain, greatly reducing their overhead and the risks associated with point-to-point integrations with each blockchain network.

CCIP Supports Any Cross-Chain Transfer Involving Both Data and Value

Just as TCP/IP is a universal standard that underpins the Internet, Chainlink CCIP serves as a universal standard that underpins the Internet of Contracts. To support all the various cross-chain use cases that exist within DeFi and TradFi, CCIP allows for a variety of ways to transfer data and/or value across blockchains.

Arbitrary Messaging

CCIP’s support for Arbitrary Messaging enables developers to transfer any arbitrary data (encoded as bytes) across blockchain networks. Developers utilize CCIP’s Arbitrary Messaging to make their smart contract applications cross-chain native.

With CCIP, smart contracts on a source chain can call any arbitrary function on any arbitrary smart contract on a destination chain to trigger any arbitrary action (and receive a callback on the source chain if needed). Developers can encode multiple instructions in a single message, empowering them to orchestrate complex, multi-step, multi-chain tasks.

Token Transfers

CCIP Token Transfers enable the transfer of tokens between chains via highly audited and security-reviewed token pool contracts. Transactions can be initiated directly by externally owned accounts (EOAs), such as from user wallets via a bridging app like Transporter, or directly by a smart contract. Tokens can then be sent to an EOA or to a smart contract.

In order to ensure the highest level of security and a superior user experience, token issuers can use CCIP directly within their token’s smart contract to make it a native cross-chain token. As a result, any user or developer can use CCIP to transfer the official (canonical) version of that issuer’s token cross-chain. Various layer-1 blockchain and layer-2 rollups such as Wemix and Metis built upon this concept by integrating CCIP as their official cross-chain infrastructure to power their canonical token bridges. Every token transferred onto those blockchain networks via CCIP is the canonical representation of that token on that chain.

There are three primary ways developers can integrate CCIP for token transfers:

• Burn and mint—Tokens are burned on a source chain, and an equivalent amount is minted on a destination chain. This enables the creation of cross-chain native tokens with a dynamic, unified supply across chains. CCIP supports Circle’s USDC via the burn and mint token transfer method.

• Lock and mint—Tokens are locked on the chain they were natively issued on, and fully collateralized “wrapped” tokens are minted on destination chains. These wrapped tokens can be transferred across other non-native destination chains via burn and mint or be burned to unlock tokens back on the original issuing source chain. Truflation’s TRUF token utilizes lock and mint for its token transfers on CCIP.

• Lock and unlock—Tokens are locked on a source blockchain, and an equivalent amount of tokens are released on the destination blockchain. This enables the support of tokens without a burn/mint function or tokens that would introduce challenges if wrapped, such as native blockchain gas tokens. CCIP supports native ETH transfers via the lock and unlock token transfer method.

Programmable Token Transfers

Programmable Token Transfers combine Token Transfers with Arbitrary Messaging. This enables developers to transfer both tokens (value) and instructions (data) about what to do with those tokens cross-chain within a single transaction. Importantly, Programmable Token Transfers are built natively into CCIP to give users the best possible security, reliability, UX (e.g., composability), and risk management.

What are Cross-Chain NFTs?

A cross-chain NFT is a smart contract that can exist on any blockchain, abstracting away the need for users to understand which blockchain they’re using.

Typically, NFT movements from one chain to another are eye-catching events, but this simple fact brings up a larger question of the reliability and security of Web3’s middleware infrastructure. In a seamless cross-chain world, moving digital assets from one chain to another should be as normal as submitting a transaction on the same blockchain.

When an NFT moves from one blockchain to another, it becomes a cross-chain NFT.

How Do Cross-Chain NFTs Work?

At a high level, an NFT is a digital token on a blockchain with a unique identifier different from any other token on the chain.

Any NFT is implemented by a smart contract that is intrinsically connected to a single blockchain. The smart contract is arguably the most important part of this equation because it controls the NFT implementation: How many are minted, when, what conditions need to be met to distribute them, and more. This means that any cross-chain NFT implementation requires at least two smart contracts on two blockchains and interconnection between them.

This is what a cross-chain NFT looks like - equivalent NFTs that exist across multiple blockchains.

With this in mind, cross-chain NFTs can be implemented in three ways:

• Burn-and-mint: An NFT owner puts their NFT into a smart contract on the source chain and burns it, in effect removing it from that blockchain. Once this is done, an equivalent NFT is created on the destination blockchain from its corresponding smart contract. This process can occur in both directions.

• Lock-and-mint: An NFT owner locks their NFT into a smart contract on the source chain, and an equivalent NFT is created on the destination blockchain. When the owner wants to move their NFT back, they burn the NFT and it unlocks the NFT on the original blockchain.

• Lock and unlock: The same NFT collection is minted on multiple blockchains. An NFT owner can lock their NFT on a source blockchain to unlock the equivalent NFT on a destination blockchain. This means only a single NFT can actively be used at any point in time, even if there are multiple instances of that NFT across blockchains.

At this Masterclass, we are going to implement the Burn-and-Mint mechanism

In each scenario, a cross-chain messaging protocol in the middle is necessary to send data instructions from one blockchain to another.

How to use Chainlink CCIP to create Cross-Chain NFTs?

To build Cross-Chain NFTs with Chainlink CCIP, let's first understand what one can do with Chainlink CCIP. With Chainlink CCIP, one can:

• Transfer (supported) tokens

• Send any kind of data

• Send both tokens and data

CCIP sender can be:

• EOA

• Any smart contract

CCIP receiver can be:

• EOA

• Any smart contract that implements CCIPReceiver.sol

Implementing Burn-and-Mint model

To implement Burn-and-Mint model using Chainlink CCIP, we will on cross-chain transfer function burn an NFT on the source blockchain (Arbitrum Sepolia) and send the cross-chain message using Chainlink CCIP. We will need to encode to and from addresses, NFT's tokenId and tokenURI so we can mint exactly the same NFT on the destination blockchain once it receives a cross-chain message.

The Arbitrum Sepolia side:

The Ethereum Sepolia side:

This design allows the cross-chain transfer and vice-versa, from Ethereum Sepolia back to Arbitrum Sepolia using the exact same codebase and Burn-and-Mint mechanism.

NFT Metadata

For this Cross-Chain NFT we will use Four Chainlink Warriors hosted on IPFS, as a Metadata.

Development Best Practices

For this exercise we will try to follow some of the CCIP Best Practices. For the full list you should always refer to the Chainlink Official Documentation.

Verify source chain, destination chain, sender and receiver addresses

It's crucial for this exercise that sending cross-chain messages is between Cross-Chain NFT smart contracts. To accomplish that, we need to track a record of these addresses on different blockchains using their CCIP chain selectors.

Verify Router addresses

When you implement the ccipReceive method in the contract residing on the destination chain, validate that the msg.sender is the correct Router address. This verification ensures that only the Router contract can call the ccipReceive function on the receiver contract and is for developers that want to restrict which accounts are allowed to call ccipReceive.

Setting gasLimit

The gasLimit specifies the maximum amount of gas CCIP can consume to execute ccipReceive() on the contract located on the destination blockchain. It is the main factor in determining the fee to send a message. Unspent gas is not refunded.

Using extraArgs

The purpose of extraArgs is to allow compatibility with future CCIP upgrades. To get this benefit, make sure that extraArgs is mutable in production deployments. This allows you to build it off-chain and pass it in a call to a function or store it in a variable that you can update on-demand.

If extraArgs are left empty, a default of 200000 gasLimit will be set.

To make extraArgs mutable, set them as described previously in the enableChain function. To calculate which bytes value to pass, you can create a helper script like this:

Vladimir Makarov, co-founder of Interport

Website:

We will now see what the workflow of a CCIP Message looks like in a couple of steps.

Step 1: Prepare

1. The Sender prepares a CCIP Message (EVM2AnyMessage) for their cross-chain transaction to a destination blockchain (chainSelector) of choice. A CCIP message includes the following information:

   • Receiver

   • Data payload

   • Tokens and amounts

   • Fee token

   • Additional parameters (gasLimit)

2. The Sender calls Router.getFee() to receive the total fees (gas + premium) to pay CCIP and approves the requested fee amount.

3. The Sender calls Router.ccipSend(), providing the CCIP Message they want to send along with their desired destination chainSelector. In the case of token transfers, the amount to be transferred must be approved to the Router.

Step 2: Send

1. The Router validates the received Message (e.g., valid and supported destination chainId and supported tokens at the destination chain).

2. The Router receives and transfers fees to the OnRamp.

3. The Router receives and transfers tokens to its corresponding Token Pool. If the sender has not approved the tokens to the Router, this will fail.

4. The Router forwards the Message to the correct OnRamp (based on destination chainSelector) for processing:

   • Validate the message (number of tokens, gasLimit, data length …)

   • [For token transfers] Ensure that the transferred value does not hit the aggregate rate limit of the lane.

   • Sequence the message with a sequence number.

   • For each Token included in the Message: instruct the token pool to lock/burn the tokens. This will also validate the token pool rate limit for this lane.

5. The OnRamp emits an event containing the sequenced message. This triggers the DONs to process the message.

6. A messageId is generated and returned to the Sender.

Step 3: Committing DON

1. Nodes in the Committing DON listen for events of Messages that are ready to be sent

2. Messages must be finalized to be considered secure against reorg attacks.

3. Triggered by time or number of messages queued in the OnRamp, the Committing DON creates a Report with a commitment of all messages ready to be sent, in a batch. This commitment takes the form of a Merkle Root

4. Upon consensus in the Committing DON, the Report containing the Merkle Root is transmitted to the CommitStore contract on the destination chain

5. The Risk Management Network “blesses” the Merkle Root in the CommitStore, to make sure it is a correct representation of the queued messages at the OnRamp.

Merkle Root & Merkle Proof

• Merkle Root: the root hash of the Merkle Tree. It is a commitment to all the leaves (Messages M1-M4) in the tree. Each node in the tree is the hash of the nodes below it.

• Merkle Proof: to prove that Message M1 is included in the Merkle Root (commitment), a Prover provides the following elements as proof to a Verifier (who only has the root hash):

  • M1

  • H(M2)

  • H(H(M3),H(M4))

  Using this Merkle Proof, a Verifier can easily verify that, indeed, M1 is included in the commitment (root hash) that it possesses.

Step 4: Executing DON

1. Nodes in the Executing DON listen for events of Messages that are ready to be sent, similar to the Committing DON

2. Messages must be finalized to be considered secure against reorg attacks.

3. In addition to the time or number of messages queued in the OnRamp, the Executing DON also monitors the CommitStore to make sure the messages are ready to be executed at the destination chain, i.e., are the messages included in a blessed on-chain commitment?

4. If conditions are met, the Executing DON creates a Report with all messages ready to be sent, in a batch. It accounts for the gasLimit of each message in its batching logic. It also calculates a relevant Merkle Proof for each message to prove that the message is included in the Merkle Root submitted by the Committing DON in the CommitStore. Note that Executing DON batches can be any subset of a Committing DON batch.

5. Upon consensus, the Report is transmitted to the OffRamp contract on the destination chain.

Step 5: Execute

1. For each message in the batch received, the OffRamp verifies using the provided Merkle Proof whether the transaction is included in the blessed commitment in the CommitStore.

2. If tokens are included in the transaction, the OffRamp validates the aggregate rate limit of the lane and identifies the matching Token Pool(s).

3. OffRamp calls the TokenPool’s unlock/mint function. This will validate the token pool rate limit, unlock or mint the token and transfer them to the specified receiver.

4. If the receiver is not an EOA and has the correct interface implemented, the OffRamp uses the Router to call the receiver’s ccipReceive() function

5. The receiver processes the message and is informed where the message comes from (blockchain + sender), the tokens transferred, and the data payload (with relevant instructions).

6. Based on the data payload, the receiver might transfer the tokens to the final recipient (end-user)

CCIP as an International Flight

Now, do you need to know in details how the processing of CCIP Message works? Absolutely not, you just need to send the cross-chain Message by interacting with the Router contract and Chainlink CCIP will deliver it, the same as when sending a package you just drop it at the Post Office, mark to whom you are sending it and pay for fees.

Just as international travel involves various checkpoints and procedures to ensure a safe and verified journey from one country to another, Chainlink CCIP ensures secure and verified communication between different blockchain networks.

Pre-Boarding at JFK Airport: The Committing Phase

Before any plane takes off, a series of rigorous checks are in place—mirroring the initiating phase of CCIP. Here, the Router acts as our check-in desk, where users present their cross-chain requests, akin to passengers confirming their flight details.

Travelers check in their luggage, which is then handled by the airport staff. As with any luggage on a long-haul flight, the cross-chain message undergoes a meticulous security protocol. Similarly, in CCIP, the OnRamp contract checks the validity of the destination blockchain address, message size, gas limits, and sequence numbers, ensuring that the 'luggage' (or data payload) is prepared correctly for its journey.

Passport and Visa verification are much comparable to the Commit Store smart contract, which stores the Merkle root of finalized messages and ensures they are 'blessed' by the Risk Management Network for authenticity and security before being executed on the destination chain.

In-Flight: The Cross-Chain Transit

During the flight, passengers and luggage are in transit, similar to the cross-chain message being propagated across networks. The Executing DON works behind the scenes, analogous to the flight crew, ensuring the smooth passage of the cross-chain interaction.

As we know, the duration of a flight can vary - flying east might chase the sun, shortening our perceived day, while westward travel extends it. Similarly, the delivery time of a cross-chain message depends on the source blockchain finality. We remember from the CCIP Masterclass #1 that finality refers to the state of irreversibility and permanent record of a transaction on the blockchain.

Touchdown at Hong Kong Airport: The Executing Phase

On arrival, the OffRamp contract ensures the message is authentic, verifying the proof against the committed and blessed Merkle root.

Similarly to the final checks by the Risk Management Network, behind the scenes (unseen by the passenger) the suitcase or our cross-chain message undergoes various security checks, ensuring that the message adheres to the rules and regulations of the destination blockchain.

Finally, the Router on the destination chain assumes the role of border control, delivering the message data and/or tokens to the receiver's address, akin to a traveler receiving their stamped passport and entering a new country.

This entire process, while complex, remains largely invisible to the end-user, who simply experiences the seamless transfer of their digital assets from one blockchain to another. From the moment of check-in to the joy of retrieval, the journey of a cross-chain message through CCIP is a marvel of modern cryptography, ensuring that what we entrust to the network is what we receive.

Please answer these 15 questions by the end of the bootcamp.

Submit your answers via

Easy:

1. What is CCIP Lane?

2. What is CCIP Chain Selector? How does it differ from Chain ID?

3. What is gasLimit in CCIP Messages used for?

4. How can one monitor CCIP Messages in real time?

5. What are the three main capabilities of Chainlink CCIP? Provide examples of potential use cases leveraging these capabilities.

Medium:

1. Detail the security best practices for verifying the integrity of incoming CCIP messages in your smart contracts. What specific checks should be implemented in the ccipReceive function, and why are these verifications crucial for the security of cross-chain dApps

2. Which token transfer mechanisms are supported by Chainlink CCIP?

3. Describe the role of the Risk Management Network in Chainlink CCIP and explain the process of "blessing" and "cursing".

4. Discuss the significance of the "finality" concept in the context of Chainlink CCIP. How does the finality of a source chain impact the end-to-end transaction time in CCIP?

5. Discuss the best practices for setting the gasLimit in CCIP messages. How can developers accurately estimate and optimize the gas limit to ensure reliable execution of cross-chain transactions?

Hard:

1. Explain the DefensiveExample Pattern and how to handle CCIP message failures gracefully.

2. List and explain the scenarios that would trigger the need for manual execution using the Chainlink CCIP Explorer.

3. Explain why it is a best practice to make the extraArgs mutable in Chainlink CCIP and describe how a developer can implement this in their smart contract.

4. What are CCIP Rate Limits? What considerations should developers keep in mind when designing applications to operate within these limits?

5. What is going to happen if you send arbitrary data alongside tokens to an Externally Owned Account using Chainlink CCIP?

Submit your public GitHub repo for the exercise below via this form

Using chainlink-local write a test for the https://github.com/smartcontractkit/ccip-cross-chain-name-service project. You can use https://cll-devrel.gitbook.io/chainlink-local-documentation for help.

In the test you must:

• Create an instance of CCIPLocalSimulator.sol smart contract.

• Call the configuration() function to get Router contract address.

• Create instances of CrossChainNameServiceRegister.sol, CrossChainNameServiceReceiver.sol and CrossChainNameServiceLookup.sol smart contracts and call the enableChain() function where needed.

• Call the setCrossChainNameServiceAddress function of the CrossChainNameServiceLookup.sol smart contract "source" instance and provide the address of the CrossChainNameServiceRegister.sol smart contract instance. Repeat the process for the CrossChainNameServiceLookup.sol smart contract "receiver" instance and provide the address of the CrossChainNameServiceReceiver.sol smart contract instance.

• Call the register() function and provide “alice.ccns” and Alice’s EOA address as function arguments.

• Call the lookup() function and provide “alice.ccns” as a function argument. Assert that the returned address is Alice’s EOA address.

• Send a url pointing to the public Github repository.

Submit your public GitHub repo for the exercise below via this form

Following the https://docs.chain.link/ccip/tutorials/ccipreceive-gaslimit guide measure the gas consumption of the ccipReceive function. Once you have the number, increase it by 10% and provide as gasLimit parameter of the transferUsdc function instead of the currently hard-coded 500.000

Use this Gitbook for guidance

You might noticed so far that building with CCIP directly on test networks is not ideal due to extra points of friction - like setting up a wallet, getting testnet tokens, waiting for cross-chain transactions to complete, etc. This is because test networks are for testing and local environments (like Foundry, Hardhat or Remix IDE) are for building and unit testing.

Introducing Chainlink Local

To address this issue, we created Chainlink Local - the Chainlink CCIP Local Simulator, and in this chapter you will learn how to simulate your cross-chain transactions locally and build with Chainlink CCIP 2000x quicker compared to working on test networks!

Chainlink Local is an installable dependency, like OpenZeppelin for example. It provides a tool (the Chainlink Local Simulator) that developers import into their Foundry or Hardhat or Remix IDE projects. This tool runs Chainlink CCIP locally which means developers can rapidly explore, prototype and iterate CCIP dApps off-chain in a local environment, and move to testnet only when they're ready to test in a live environment.

Most importantly, smart contracts tested with Chainlink Local can be deployed to test networks without any modifications (assuming network specific contract addresses such as Router contracts and LINK token addresses are passed in via a constructor).

To view more detailed documentation and more examples, visit the Chainlink Local Documentation and Chainlink Local YouTube Playlist.

Local Mode vs Forked Mode

The simulator supports two modes:

1. Local Mode - working with mock contracts on a locally running development blockchain node running on localhost, and

2. Forked Mode - working with deployed Chainlink CCIP contracts using multiple forked networks.

Local Mode

When working in local simulation mode, the simulator pre-deploys a set of smart contracts to a blank Hardhat/Anvil network EVM state and exposes their details via a call to the configuration() function. Even though there are two Router contracts exposed, sourceRouter and destinationRouter, to support the developer's mental model of routing cross-chain messages through two different Routers, both are actually the same contract running on the locally development blockchain node.

Forked Mode

When working in fork mode, you will need to create multiple locally running blockchain networks (you need an archive node that has historical network state in the pinned block from which you have forked for local development - see here) and interact with the contract addresses provided in the Official Chainlink Documentation.

Coding time: Let's write a unit test for our XNFT.sol smart contract

The full example is available at: https://github.com/smartcontractkit/ccip-cross-chain-nft

Creating a new Foundry project

To get started let's first create a new Foundry project by running:

forge init

If this command fails, make sure you have Foundry installed.

Installing necessary dependencies

After that we will need to install the following dependencies. If you don't want to commit changes after each installment, append the --no-commit flag to each of the following commands

@chainlink/contracts

forge install smartcontractkit/chainlink-brownie-contracts

@chainlink/contracts-ccip

forge install smartcontractkit/ccip@b06a3c2eecb9892ec6f76a015624413fffa1a122

@openzeppelin/contracts

forge install OpenZeppelin/openzeppelin-contracts

@chainlink/local

forge install smartcontractkit/chainlink-local

And then set the following remappings in your foundry.toml or remappings.txt file:

# foundry.toml
[profile.default]
src = "src"
out = "out"
test = "test"
libs = ["lib"]
solc = '0.8.24'

remappings = [
    '@chainlink/contracts-ccip=lib/ccip/contracts',
    '@chainlink/contracts/=lib/chainlink-brownie-contracts/contracts/',
    '@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/',
    '@chainlink/local/=lib/chainlink-local/',
]

Delete src/Counter.sol, test/Counter.t.sol and script/Counter.s.sol files. Create new XNFT.sol file in src folder and paste the content of the XNFT smart contract from the previous page/exercise. Run forge build to compile that contract. This should work if you installed dependencies properly.

Getting Ethereum Sepolia and Arbitrum Sepolia RPC URLs

Create a new file by copying the .env.example file, and name it .env. Fill in with Ethereum Sepolia and Arbitrum Sepolia RPC URLs using either local archive nodes or a service that provides archival data, like Infura or Alchemy.

ETHEREUM_SEPOLIA_RPC_URL=""
ARBITRUM_SEPOLIA_RPC_URL=""

Then add the rpc_endpoints section to your foundry.toml file. Its final version should look like this:

# foundry.toml
[profile.default]
src = "src"
out = "out"
test = "test"
libs = ["lib"]
solc = '0.8.24'

remappings = [
    '@chainlink/contracts-ccip=lib/ccip/contracts',
    '@chainlink/contracts/=lib/chainlink-brownie-contracts/contracts/',
    '@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/',
    '@chainlink/local/=lib/chainlink-local/',
]

[rpc_endpoints]
ethereumSepolia = "${ETHEREUM_SEPOLIA_RPC_URL}"
arbitrumSepolia = "${ARBITRUM_SEPOLIA_RPC_URL}"

# See more config options https://github.com/foundry-rs/foundry/blob/master/crates/config/README.md#all-options

Write your first test with Chainlink Local

In the previous exercise, we performed 7 steps on two different test networks in order to deploy, mint and transfer XNFT from one account to another. Using Chainlink Local, you can write a test that will perform the same action, using exactly the same CCIP contracts from test networks, in your local environment, much faster.

Create a new test/XNFT.t.sol file. Paste the following content:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {CCIPLocalSimulatorFork, Register} from "@chainlink/local/src/ccip/CCIPLocalSimulatorFork.sol";

import {XNFT} from "../src/XNFT.sol";
import {EncodeExtraArgs} from "./utils/EncodeExtraArgs.sol";

contract XNFTTest is Test {
    CCIPLocalSimulatorFork public ccipLocalSimulatorFork;
    uint256 ethSepoliaFork;
    uint256 arbSepoliaFork;
    Register.NetworkDetails ethSepoliaNetworkDetails;
    Register.NetworkDetails arbSepoliaNetworkDetails;

    address alice;
    address bob;

    XNFT public ethSepoliaXNFT;
    XNFT public arbSepoliaXNFT;

    EncodeExtraArgs public encodeExtraArgs;

    function setUp() public {
        alice = makeAddr("alice");
        bob = makeAddr("bob");

        string memory ETHEREUM_SEPOLIA_RPC_URL = vm.envString("ETHEREUM_SEPOLIA_RPC_URL");
        string memory ARBITRUM_SEPOLIA_RPC_URL = vm.envString("ARBITRUM_SEPOLIA_RPC_URL");
        ethSepoliaFork = vm.createSelectFork(ETHEREUM_SEPOLIA_RPC_URL);
        arbSepoliaFork = vm.createFork(ARBITRUM_SEPOLIA_RPC_URL);

        ccipLocalSimulatorFork = new CCIPLocalSimulatorFork();
        vm.makePersistent(address(ccipLocalSimulatorFork));
    }

    // YOUR TEST GOES HERE...
}