Connecting Chainlink to ICON via xCall

Paul Rouge
6 min readAug 29, 2023

In this article, I will be showing you how I connected the Verifiable Random Function (VRF) service of Chainlink on Sepolia to the ICON Berlin Testnet. This project is a submission for the Incentivized Testnet Program of the ICON Foundation.

To follow along with this article, it is important that you have a basic understanding of ICON’s xCall protocol.

The Idea

The idea revolves around utilizing the xCall protocol to establish a connection between an ICON smart contract and the Chainlink Verifiable Random Function (VRF) services. You can find more information about xCall protocol here. Essentially, this involves obtaining a genuinely random number, which can be quite challenging within the context of decentralized blockchains.

I am opting for the Subscription Method provided by the Chainlink VRF service. This method allows me to create a smart contract that holds Chainlink tokens, which are used to facilitate payments for the VRF services. Additionally, other smart contracts can subscribe to this service. The smart contract responsible for holding the Chainlink tokens, managing subscriptions, and related tasks is referred to as the “Coordinator”.

Note: Whenever you encounter the term “random word” in this article, it essentially signifies a “random number”. In the realm of computer science, a piece of data is frequently referred to as a “word”.

Follow the red REQ path from the ICON dApp to the Chainlink VRF, then follow the yellow RES path from Chainlink back to the ICON dApp

Step 1

Begin by establishing a Chainlink VRF Coordinator smart contract and deploying it on the Sepolia network. Detailed instructions for this setup can be found here.

Step 2

Navigate to https://vrf.chain.link/ to access the user-friendly dashboard. Proceed to configure the Coordinator contract through this dashboard and ensure its proper setup. Utilize the dashboard’s features to infuse the contract with an allocation of Chainlink tokens.

A visual representation of this process is depicted below:

Step 3

Proceed to configure a smart contract on the Sepolia Testnet, which will be responsible for soliciting and acquiring random numbers. The specific smart contract employed for this purpose can be accessed via this link. We’ll label this contract as the “Sepolia dApp”.

While deploying the Sepolia dApp, ensure that you utilize the ID associated with your previously established Coordinator contract. In the illustration provided earlier, the ID is denoted as 3948.

Step 4

Integrate the smart contract that was recently deployed, functioning as a consumer, into the Coordinator contract. This integration process is also conducted through the Chainlink dashboard. A representation of this procedure is exemplified below:

So now the contract you added as consumer, is allowed to spend the Link tokens of the Coordinator to request random numbers from the Chainlink VRF service.

Step 5

Establish a smart contract on the ICON Berlin Testnet that encompasses two key functions: one for initiating a request for a random number and another for managing the reception of an incoming random number. The precise smart contract employed for this purpose is accessible via the following link. This particular contract will be referred to as the “Berlin dApp.”

Step 6

a. Configure the BTP (Blockchain Transfer Protocol) address associated with the Sepolia dApp onto the Berlin dApp. Execute this task by invoking the setBtpAddressSepoliaDapp function.

b. Likewise, establish the BTP address related to the Berlin dApp on the Sepolia dApp. Accomplish this by utilizing the setDappAddressBerlin function.

Step 7

Transfer a quantity of test Ether (ETH) to the Sepolia dApp. This smart contract, upon obtaining a random number from Chainlink’s VRF service, dispatches an xCall message to ICON’s Berlin Testnet. As of the present writing, I’ve been sending 0.00003 ETH for each test execution. However, it’s advisable to familiarize yourself with xCall fees by referring to this link to ensure that the amount you send is sufficient.

Recap

  • The Chainlink VRF Coordinator contract has been successfully funded with Chainlink tokens and the Sepolia dApp has been registered as a ‘consumer’.
  • Sufficient funds have been allocated to the Sepolia dApp to cover the xCall fee for receiving random numbers from the Chainlink VRF service.
  • The Sepolia dApp has the accurate BTP address of the Berlin dApp correctly configured.
  • Correspondingly, the Berlin dApp holds the accurate BTP address of the Sepolia dApp.

With these preparations in place, everything should be ready for execution!

xCall Protocol

The utilization of the xCall protocol is remarkably straightforward. Essentially, it involves the transmission and execution of messages. Notably, messages are dispatched from the source chain, while their execution transpires on the destination chain.

In our present scenario, the Berlin dApp initiates a request for a random number using xCall, directed towards the Sepolia chain. Subsequently, the Sepolia dApp employs xCall to transmit the acquired random number back to the Berlin dApp. The Berlin dApp then securely stores this received random number.

It’s worth emphasizing that this article doesn’t delve into practical xCall utilization. For those new to xCall, I strongly recommend perusing the xCall documentation and engaging with the xCall end-to-end demonstration prior to proceeding.

Step 8

Invoke the requestRandomNumber function located within the Berlin dApp. When performing this action, ensure that you include an appropriate amount of ICX (ICON tokens) to cover the associated xCall fee.

Step 9

Retrieve the reqId and data parameters from the xCall contract events on the Sepolia chain. Utilize these acquired values to trigger the execution of the executeCall function located within the Sepolia xCall contract. This process initiates the Chainlink VRF function call, subsequently activating the fulfillRandomWords function on the Sepolia dApp.

For testing purposes, the provided example encompasses the emission of a random word — denoting the Chainlink VRF result. This resultant value is subsequently employed to invoke our sendXCallMessage function.

sendXCallMessage function is designed to meticulously assemble the necessary data and subsequently transmit it to ICON’s Berlin Testnet through the xCall protocol. It’s crucial to consider that the contract must possess a sufficient quantity of ETH to cover the associated xCall fee.

Step 10

On the Berlin Testnet call the ‘executeCall’ function on the xCall contract, et voila!

The VRF result from Sepolia is stored in a map on the Berlin contract.

Conclusion

In wrapping up, this exploration into connecting Chainlink to ICON through the xCall protocol underscores the remarkable simplicity of the xCall process itself.

While much of the effort was concentrated on establishing the groundwork and showcase components, the actual implementation of xCall seamlessly facilitated communication between different chains.

This demonstration serves as a testament to the user-friendly nature of xCall, making cross-chain interactions achievable with relative ease. As the focal point shifted from setup to execution, the streamlined functionality of xCall revealed its potency in enabling robust interactions across decentralized networks.

--

--