What's new in CCIP v1.2?

Overview of additions to Chainlink CCIP in version 1.2

Quick recap - What is 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.

To build Cross-Chain NFTs with Chainlink CCIP, let's first quickly recap from previous Masterclasses 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

The Minimal CCIP Architecture

Chainlink CCIP v1.2.0 Release

CCIP v1.0.0 has been deprecated on testnet. Here is the brief overview of additions to Chainlink CCIP with this latest release:

• There is no change to the CCIP Router interface. However, new Router contracts were deployed, so you must use new Router addresses mentioned in the Official Chainlink Documentation to switch to the 1.2 version.

• The support for USDC token transfers has been added.

• The message sequencing process in Chainlink CCIP message handling has been simplified by removing the strict sequencing flag from the extraArgs field. That means that extraArgs: Client._argsToBytes(Client.EVMExtraArgsV1({gasLimit: 0, strict: false})) syntax became extraArgs: Client._argsToBytes(Client.EVMExtraArgsV1({gasLimit: 0})) This is a good moment to recap one of the CCIP Development Best Practices from previous Masterclasses: make sure that extraArgs is mutable in production deployments. The purpose of extraArgs is to allow compatibility with future CCIP upgrades. 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. To make extraArgs mutable, which essentially is a bytes variable under the hood, store them in a storage variable that only owner of the contract can update using a setter function or pass it as a function argument. To calculate which bytes value to pass, you can create a helper script like this:

// EncodeExtraArgs.s.sol

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

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

contract EncodeExtraArgs {
    // Below is a simplistic example (same params for all messages) of using storage to allow for new options without
    // upgrading the dapp. Note that extra args are chain family specific (e.g. gasLimit is EVM specific etc.).
    // and will always be backwards compatible i.e. upgrades are opt-in.
    // Offchain we can compute the V1 extraArgs:
    //    Client.EVMExtraArgsV1 memory extraArgs = Client.EVMExtraArgsV1({gasLimit: 300_000});
    //    bytes memory encodedV1ExtraArgs = Client._argsToBytes(extraArgs);
    // Then later compute V2 extraArgs, for example if a refund feature was added:
    //    Client.EVMExtraArgsV2 memory extraArgs = Client.EVMExtraArgsV2({gasLimit: 300_000, destRefundAddress: 0x1234});
    //    bytes memory encodedV2ExtraArgs = Client._argsToBytes(extraArgs);
    // and update storage with the new args.
    // If different options are required for different messages, for example different gas limits,
    // one can simply key based on (chainSelector, messageType) instead of only chainSelector.

    function encode(
        uint256 gasLimit
    ) external pure returns (bytes memory extraArgsBytes) {
        Client.EVMExtraArgsV1 memory extraArgs = Client.EVMExtraArgsV1({
            gasLimit: gasLimit
        });
        extraArgsBytes = Client._argsToBytes(extraArgs);
    }
}

• The gas limit and maximum message data length for CCIP messages have been adjusted on testnets. These changes are detailed in the Service Limits documentation.

• If you currently use CCIP v1.0.0, use the @chainlink/contracts-ccip npm package version 0.7.6. To migrate to v1.2.0, use version 1.2.1 of the npm package or later.

How do USDC transfers with Chainlink CCIP work?

USDC is a digital dollar backed 100% and is always redeemable 1:1 for US dollars. The stablecoin is issued by Circle on multiple blockchain platforms.

Fundamentally, CCIP Architecture remained unchanged meaning that all we learned in past Masterclasses about transferring tokens and data just works with USDC as well. Meaning that sender has to interact with the CCIP router to initiate a cross-chain transaction, similar to the process for any other token transfers. The process uses the same onchain components including the Router, OnRamp, Commit Store, OffRamp, and Token Pool smart contracts. The process uses the same offchain components including the Committing DON, Executing DON, and the Risk Management Network.

The diagram below shows that the USDC token pools and Executing DON handle the integration with Circle’s contracts and offchain CCTP Attestation API. As with any other supported ERC-20 token, USDC has a linked token pool on each supported blockchain to facilitate OnRamp and OffRamp operations.

CCIP <> USDC Diagram

The following describes the operational process:

1. On the source blockchain:

   • When the sender initiates a transfer of USDC, the USDC token pool interacts with CCTP’s contract to burn USDC tokens and specifies the USDC token pool address on the destination blockchain as the authorized caller to mint them.

   • CCTP burns the specified USDC tokens and emits an associated CCTP event.

2. Offchain:

   • Circle attestation service listens to CCTP events on the source blockchain.

   • CCIP Executing DON listens to relevant CCTP events on the source blockchain. When it captures such an event, it calls the Circle Attestation service API to request an attestation. An attestation is a signed authorization to mint the specified amount of USDC on the destination blockchain.

3. On the destination blockchain:

   • The Executing DON provides the attestation to the OffRamp contract.

   • The OffRamp contract calls the USDC token pool with the USDC amount to be minted and the Circle attestation.

   • The USDC token pool calls the CCTP contract. The CCTP contract verifies the attestation signature before minting the specified USDC amount into the CCIP receiver.

   • The USDC token pool transfers the specified USDC amount to the CCIP receiver.

   • If there is data in the CCIP message, then the OffRamp contract transmits the CCIP message to the Router contract.

To learn more about how CCTP attestations work, check out Circle's Official Documentation.