Press enter or click to view image in full size

Interoperability remains one of the biggest challenges in the Web3 space. Blockchains are inherently fragmented ecosystems, each operating in isolation and unable to communicate natively with one another. To address this limitation, developers have introduced various solutions, with blockchain bridging emerging as a key innovation. Bridges enable cross-chain token transfers by locking or burning assets on the source chain and then minting or unlocking equivalent assets on the destination chain.

In this article, we’ll explore how to leverage Chainlink’s Cross-Chain Interoperability Protocol (CCIP) to mint NFTs across different blockchains. Specifically, we’ll demonstrate how an NFT can be initiated from a chain like Ethereum and minted on another chain, such as BNB Smart Chain (BSC).

CCIP is a standardised protocol designed to promote true interoperability between blockchain networks. It provides developers with the ability to transfer data, tokens, or even a combination of both across chains securely and reliably.

Prerequisites

This article assumes you are familiar with the following concepts:

• The Solidity programming language
• The ERC721 standard
• The cryptocurrency wallet, such as MetaMask

CCIP Architecture

The CCIP architecture consists of three main components to make cross communication possible:

Router
The Router is the entry-point contract deployed on every supported chain. It serves as the coordinator for cross-chain interactions, handling token approvals, routing instructions to the correct destination, and ensuring timely delivery. Depending on the request, the Router can transfer tokens directly to user accounts or forward messages to receiver contracts on the destination chain.

Sender
A Sender can be either an Externally Owned Account (EOA) or a smart contract that initiates a CCIP transaction. Senders are responsible for starting cross-chain interactions and can transmit tokens, messages, or a combination of both to the destination chain.

Receiver
A Receiver can also be an EOA or a smart contract that accepts the cross-chain transaction. While EOAs can only receive tokens, smart contracts are required to receive data or combined data-and-token transfers. The Receiver doesn’t have to be the same as the Sender.

Sender Contract Implementation

The NFTSender contract defines custom error messages, a struct for tracking NFT minting requests, and most importantly, the Router and LINK token addresses. These addresses must correspond to the source chain where the cross-chain transaction begins.

The LINK token is critical because it covers the gas fees required for CCIP operations. Without sufficient LINK, the transaction cannot be executed.

Chainlink provides an up-to-date list of supported blockchains along with their Router addresses, LINK token addresses, and chain selectors here.

The crossChainMint function requires three parameters, each serving a distinct purpose:

• DestinationChainSelector: a unique identifier assigned by Chainlink to every supported chain. In this case, it should correspond to the destination chain.
• Receiver: the address of the NFT receiver contract deployed on the destination chain.
• TokenURI: the metadata URI that defines the NFT’s attributes and properties.

The function records the minting request and encodes the message to be sent to the receiver contract into a bytes payload. This payload includes the recipient’s address, the token URI, and the request ID. Once prepared, the data is passed to the CCIP contract adaptor.

The tokenAmounts parameter is an array of structs containing a token address and amount. In this case, the array remains empty since no tokens are being transferred along with the request.

It’s important to highlight that any user interacting with thecrossChainMint function must hold LINK tokens to cover the gas fees. Additionally, the NFTSender contract itself needs to be funded with LINK, as these tokens are required to successfully execute the transaction on the destination (receiver) contract.

Receiver Contract Implementation

The ReceiverSender contract includes several implementations, but our primary focus is on the _ccipReceive function. This function is triggered by the NFTSender contract whenever a cross-chain message arrives. It ensures the incoming message ID hasn’t already been processed, extracts the sender’s address, and decodes the payload, which contains the data required to mint the NFT.

The constructor of this contract takes in the Router address of the destination chain, along with the name and symbol of the NFT collection.

Conclusion

In this article, we explored the fundamentals of cross-chain communication using Chainlink CCIP and demonstrated how it can be applied to enable cross-chain NFT minting. The tutorial focused on the core concepts required to understand CCIP-based communication, but the contracts can be further extended with additional features. For example, developers may implement fee management functions to estimate the cost of cross-chain minting, or introduce authorisation mechanisms such as whitelisting and restricting specific sender addresses or chain selectors from accessing the receiver contract.