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

Richard Gottleber, Developer Relations Engineer, Chainlink Labs

X (Twitter): @thergdev

Email: richard.gottleber@smartcontract.com

Andrej Rakic, Developer Relations Engineer, Chainlink Labs

X (Twitter): @andrej_dev

Darby Martinez, Developer Expert, Chainlink Community

X (Twitter): @darbease

LinkedIn: https://www.linkedin.com/in/darby-martinez/

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.

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

• Transporter, powered by CCIP

• Introduction to Interoperability Problem and Chainlink CCIP

  • How CCIP Programmable Token Transfers Unlock Cross-Chain Innovation

  • CCIP Programmable Token Transfers in TradFi

  • CCIP Programmable Token Transfers in DeFi

• How to Use Chainlink CCIP

Exercises

• Exercise 1: Programmable Token Transfers using the Defensive Example Pattern

  • Defensive Example Pattern

Homework

👉 Day 1 Homework

A talk with the Interport team

Day 2

Theory

• CCIP Architecture and Message Processing

• Building Cross-Chain NFTs

Exercises

• Exercise 2: Build Your First Cross-Chain NFT

• Exercise 3: Testing Cross-Chain NFTs

Homework

Debugging Tips and Tricks

👉 Day 2 Homework

A talk with the Celo team

Day 3

5 Levels of Cross-Chain Security with Chainlink CCIP

Exercise 4: Sending USDC Cross-Chain

Homework

👉 Day 3 Homework

Next Steps

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

CCIP Programmable Token Transfers are critical to enabling cross-chain . 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.

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 written in collaboration with ANZ and the between Chainlink Co-Founder Sergey Nazarov and ANZ’s Banking Services Lead Nigel Dobson.

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 and 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

Arbitrary Messaging

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

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

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.

Transfer Tokens With Data - Defensive Example

This tutorial extends the . 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 , which will guide you through using the , interacting with the and working within the .

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

3. Check the 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 .

4. Learn how to . 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 . 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: 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.

Deploy Your Contracts

To use this contract:

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.

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.

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.

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. 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

Sending messages

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:

   • 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.

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.

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

Submit your answers via this form

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?

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

👉 REGISTER NOW

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

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.

Vladimir Makarov, co-founder of Interport

Website: https://interport.fi/

X (Twitter): https://twitter.com/0xWhereto

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.

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.

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:

Submit your public GitHub repo for the exercise below via

Using chainlink-local write a test for the project. You can use 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.

Brief overview of how one can approach debugging CCIP dApps

Welcome to bonus chapter about debugging Chainlink CCIP dApps and troubleshooting issues with sending and receiving cross-chain messages. Writing code is just the beginning, the true skill often lies in effectively troubleshooting and resolving issues that arise.

Getting Started

To understand where the issue is or may arise, you first need to have bookmarked the whole transfer of cross-chain message flow, which you can find in the subsection.

The second most important thing is to understand how ABI encoding/decoding works in EVM. When you compile Solidity code, the two primary outputs are Application Binary Interface (ABI) and EVM bytecode.

EVM bytecode is the machine-level code that the Ethereum Virtual Machine executes. It is what gets deployed to the Ethereum blockchain. It's a low-level, hexadecimal-encoded instruction set that the EVM interprets and runs. The bytecode represents the actual logic of the smart contract in an executable form.

The ABI is essentially a JSON-formatted text file that describes the functions and variables in your smart contract. When you want to interact with a deployed contract (e.g., calling a function from a web application), the ABI is used to encode the function call into a format that the EVM can understand. It serves as an interface between your high-level application (like a JavaScript front-end) and the low-level bytecode running on Ethereum. The ABI includes details about each function's name, return type, visibility (public, private, etc.), and the types of its parameters.

Decode error messages

So at first glance, when seeing this message, you can go into the panic mode and think how CCIP does not work or something similar. So let's decode the error message to see what went wrong.

So the error code is: 0x1c33fbee000000000000000000000000000000000000000000000000304611b6affba76a

This is esentially a hexadecimal value that mean a lot of stuff. But if we know the ABI of the Receiver smart contract it's simple to decode it.

Couple of tools that you can use:

• Foundry's cast abi-decode

The decoded output unequivocally tells us that the Solidity custom error ChainNotEnabled() was thrown, which most likely means that we forgot to call enableChain() function of the Receiver's smart contract in general case.

Use CCIP Revert Reason script

You will need to provide either an error code string or the chainId, txHash and txRequester alongside JSON RPC url in .env file (archive node preffered).

And if you run go run main.go the output with these predefined values should be: If you access an array, bytesN or an array slice at an out-of-bounds or negative index (i.e. x[i] where i >= x.length or i < 0).

Measure gas costs

Probably the most common error is the following one: ReceiverError. This may be due to an out of gas error on the destination chain. Error code: 0x

This most likely means that you've used extraArgs: "" syntax which defaults to 200_000 for gasLimit while your ccipReceive function consumes more.

To solve this error, you will most likely just need to, connect your wallet to CCIP Explorer, set the "Gas limit override" field to appropriate value and trigger manual execution of this function by clicking the blue button.

In future, to prevent this issue, you can use the following syntax, if you want to set the gas limit to 500_000 gas for example:

Keep in mind that:

• If you are transferring only tokens, gasLimit should be set to 0 because there is no ccipReceive function

Tenderly is your friend

Oftentimes Tenderly is a good choice when you want to debug or simulate transactions against live test networks. Full trace feature allows you to see where the function actually reverts, which is much helpful than a below error message from at Block explorer.

One of the biggest problems when working with unverified smart contracts is function tracing. This smart contract wasn't verified, but the function selector was still known, and that's why Polygonscan was able to display it. This is sometimes very helpful.

Function selectors are the first four bytes of the Keccak-256 hash of the function's signature. The function signature includes the function name and the parenthesized list of parameter types. When a function call is made, these first four bytes are used by the EVM to determine which specific function in the contract should be executed.

Looks like we found the function which reverted. Now we can take a look at its implementation and find out what went wrong. Although it was already clear from the Tenderly's UI that the issue is that CCIP Sender contract was not funded with tokens for covering CCIP fees - which is one of the most common User errors.

Submit your public GitHub repo for the exercise below via

Following the 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

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 , 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 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 and .

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 .

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

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

Creating a new Foundry project

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

@chainlink/contracts-ccip

@openzeppelin/contracts

@chainlink/local

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

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

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

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:

If you try to compile this contract you should encounter in an error because there is no EncodeExtraArgs.sol helper smart contract from the previous exercise. Fix that by creating a new file test/utils/EncodeExtraArgs.sol and paste the following code.

Let's analyze the code so far. We've imported CCIPLocalSimulatorFork from the @chainlink/local package, meaning that we are using the Forked Mode. We created a new instance of it and made it persistent across all different forks so it can work properly.

For your homework however, you will need to import CCIPLocalSimulator from the @chainlink/local package.

We also created two forks (copies of the blockchain networks at the latest block - it is the best practice to pin this block number instead of always using the latest one) of Ethereum Sepolia and Arbitrum Sepolia test networks. We can now switch between multiple forks in Foundry, but we selected Ethereum Sepolia for start.

Fork ID is Foundry's way to manage different forked networks in a same test and those are usually numbers from 1, 2, 3... etc. Fork ID is not the same thing as block.chainid - that's the actuall Chain ID of a blockchain network you can get in Solidity - 11155111 for Ethereum Sepolia, for example.

CCIPLocalSimulatorFork in Foundry only, comes up with this Register helper smart contract that contains NetworkDetails struct which looks like this:

It is pre-populated with these details for some test networks and NO MAIN NETWORKS (on purpose) so it is the best practice to always validate these information - otherwise simulations won't work:

We are going to perform Steps 1) and 2) from previous exercise directly in the setup() function, like this:

And the rest of the steps from the previous exercise directly in a new test function, like this:

Full Final code:

💻

Level 5: Defense-In-Depth

Chainlink is a blockchain-agnostic, decentralized computing platform that provides secure access to external data, off-chain computation, and cross-chain interoperability.

The Chainlink Cross-Chain Interoperability Protocol (CCIP) serves as an interoperability standard for transferring both tokens and/or data between any supported public or private blockchain network.

Level-5 cross-chain security achieves unprecedented levels of decentralization by utilizing multiple decentralized networks to secure a single cross-chain transaction, along with incorporating additional risk management systems to identify risks and take actions to prevent them, such as by implementing emergency shutdowns or imposing rate limits.

The fifth level of cross-chain security doesn’t just give you one independent network for your cross-chain data or messages; it gives you multiple networks, made up of independent nodes all working together to secure each bridge.

While many bridge solutions operate using a single node or multiple nodes under the control of one key holder (e.g., Multichain), the fifth level of security uses multiple independent nodes with their own independent key holders and even splits them up into two separate groups of nodes: the transactional DON nodes and the Risk Management Network nodes. One additional key feature of the separate networks in CCIP is the creation of two entirely separate implementations, with two independent code bases, so that CCIP features an unprecedented level of client diversity/decentralization for cross-chain interoperability.

Developed with security and reliability as the primary focus CCIP operates at the highest level of cross-chain security. CCIP’s defense-in-depth security and suitability can be broken down across four categories:

Multiple Layers of Decentralization

CCIP is underpinned by Chainlink’s proven decentralized oracle infrastructure. Rather than operating as a single monolithic network, CCIP is composed of multiple decentralized oracle networks (DONs) per chain lane, each consisting of a unique source chain and destination chain. This approach allows CCIP to be horizontally scalable, as additional DONs are added to CCIP for each additional blockchain network supported, versus funneling all cross-chain traffic through a single network.

The committing DON is a decentralized network of oracle nodes that monitor events on a given source chain, wait for source chain finality, bundle transactions to create a Merkle root, come to consensus on that Merkle root and finally commit that Merkle root to the destination chain. The executing DON is a decentralized network of oracle nodes that submit Merkle proofs on a destination chain, which is then verified onchain by ensuring the transactions were included in a previously committed Merkle root that has been validated by the Risk Management Network.

Risk Management Network

The Risk Management Network is a separate, independent network that continuously monitors and validates the behavior of CCIP, providing an additional layer of security by independently verifying cross-chain operations for anomalous activity. The Risk Management Network utilizes a separate, minimal implementation of the Chainlink node software, creating a form of client diversity for increased robustness while also minimizing external dependencies to prevent supply chain attacks.

To increase the security and robustness of CCIP, the Risk Management Network engages in two types of activities:

• Secondary Approval: The Risk Management Network independently recreates Merkle roots based on transactions from the source chain, which are then published on the destination chain and compared against the Merkle roots published by the Committing DON. Cross-chain transactions can only be executed if the Merkle roots from the two networks match.

• Anomaly Detection: The Risk Management Network monitors for abnormal behavior from the CCIP network (e.g., committed transactions with no source chain equivalent) as well as the behavior of chains (e.g., deep block reorgs). If suspicious activity is detected, the Risk Management Network can trigger an emergency halt to pause all CCIP lanes and limit any losses.

High-Quality Node Operators

Chainlink DONs are operated by a geographically distributed collection of Sybil-resistant, security-reviewed node operators with significant experience running mission-critical infrastructure across Web2 and Web3. Node operators in the Chainlink ecosystem include global enterprises (e.g., Deutsche Telekom MMS, Swisscom, Vodafone), leading Web3 DevOps teams (e.g. Infura, Coinbase Cloud), and experienced Chainlink ecosystem projects.

The Committing DONs and Executing DONs in CCIP are composed of 16 high-quality independent node operators, while the Risk Management Network is composed of 7 distinct node operators (resulting in a total of 23 node operators). Importantly, the Risk Management Network consists of a wholly separate and non-overlapping set of nodes compared to the primary CCIP networks, helping ensure independent secondary validation. As the value secured by CCIP expands over time, the number of node operators within each network can scale to meet the need for greater security.

Configurable Rate Limits

As an additional layer of security for cross-chain token transfers, CCIP implements configurable rate limits, established on a per-token and per-lane basis, which are set up in alignment with the token contract owners like Lido. Furthermore, CCIP token transfers also benefit from the increased security provided by an aggregate rate limit (across token pools) on each lane, so even in a worst-case scenario, it would be impossible for every token’s limit to be maxed out before the aggregate rate limit on a lane is hit.

Conclusion

With CCIP you get:

• Multiple independent nodes run by independent key holders.

• Three decentralized networks all executing and verifying every bridge transaction.

• Separation of responsibilities, with distinct sets of node operators, and with no nodes shared between the transactional DONs and the Risk Management Network.

• Increased decentralization with two separate code bases across two different implementations, written in two different languages to create a previously unseen diversity of software clients in the bridging world.

• Never-before-seen level of risk management that can be rapidly adapted to any new risks or attacks that appear for cross-chain bridging.

Coding Time 🎉

CCIP Config Details

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

Alternatively, you can clone:

The @chainlink/contracts-ccip NPM package

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

Faucet

Develop xNFT smart contract

Prepare for deployment

Follow the steps to add the necessary environment variables for deploying these contracts and sending your first CCIP Message.

This contract expects at least 0.8.20 Solidity version. It is very important to understand that with Solc version 0.8.20, the default EVM version is set to "Shanghai". A new opcode, PUSH0, was added to the Ethereum Virtual Machine in the Shanghai upgrade.

However, besides Ethereum, the majority of blockchains haven't included PUSH0 opcode.

That means the PUSH0 opcode can now be part of the contract's bytecode and if the chain you are working on does not support it, it will error with the "Invalid opcode" error.

To understand more, we highly encourage you to check this StackOverflow answer:

Step 1) Deploy XNFT.sol to Ethereum Sepolia

Step 2) Deploy XNFT.sol to Arbitrum Sepolia

Step 3) On Ethereum Sepolia, call enableChain function

Step 4) On Arbitrum Sepolia, call enableChain function

Step 5) On Arbitrum Sepolia, fund XNFT.sol with 3 LINK

To cover for CCIP fees, fund XNFT.sol with some amount of LINK, 3 should be more than enough for this demo. Obviously, for the sake of full functionality, you should fund XNFT.sol smart contract on other blockchains as well, so you can perform cross-chain transfers between all of them.

Step 6) On Arbitrum Sepolia, mint new xNFT

Step 7) On Arbitrum Sepolia, crossTransferFrom xNFT

You can now monitor this cross-chain transfer on CCIP Explorer page.

Once cross-chain NFT arrives to Ethereum Sepolia, you can manually display it inside your Metamask wallet. Navigate to the "NFT" tab and hit the "Import NFT" button.

Then, fill in XNFT.sol smart contract address on Ethereum Sepolia and token ID you received (0).

Finally, your NFT will appear inside Metamask wallet.

Getting started

You can use Chainlink CCIP with any blockchain development framework. For this Masterclass, we will use Remix IDE.

Let's create a new project by navigating to and clicking the "Create new Workspace" button. Select "Blank" template and name the workspace as "CCIP Masterclass 4".

Alternatively, you can clone:

The @chainlink/contracts-ccip NPM package

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

To install it, create a new Solidity file, and paste the following content. It is an empty contract that just imports one of the contracts from the @chainlink/contracts-ccip and @openzeppelin/contracts packages that we will use throughout this Masterclass as well.

This contract expects at least 0.8.20 version of a Solidity compiler. It is very important to understand that with the latest Remix IDE release, the default EVM version is set to "Cancun". A new opcode, PUSH0, was added to the Ethereum Virtual Machine in the Shanghai upgrade, which happened prior to the current, Cancun upgrade.

However, besides Ethereum, the majority of blockchains haven't included PUSH0 opcode.

That means the PUSH0 opcode can now be part of the contract's bytecode and if the chain you are working on does not support it, it will error with the "Invalid opcode" error.

What we want is to downgrade Ethereum Virtual Machine version to "Paris" instead.

To understand more, we highly encourage you to check this StackOverflow answer:

To set EVM version to "Paris", navigate to the "Solidity compiler" tab and then:

• Set "COMPILER" version to 0.8.20+commit.a1b79de6

• Toggle the "Advanced Configurations" dropdown

• Toggle the "EVM VERSION" dropdown menu and select paris instead of default

Now compile the smart contract by clicking the "Compile Empty.sol" button. If compiled successfully, go back to "File explorer" tab and if new .deps/npm/@chainlink/contracts-ccip and .deps/npm/@openzeppelin/contracts folders are generated, that means we imported all of the necessary packages into the Remix IDE Workspace successfully.

Faucet

Develop TransferUSDC smart contract