GTON Academy. How to run your own Chainlink DON on Fantom testnet and mainnet?
0x8c8b
February 24th, 2022

In this article, we will describe various caveats that we encountered while setting up Chainlink nodes on Fantom, and ways to work around them, to help other developers and DAOs set up their custom permissionless price feeds.

The evolution of GTON CAPITAL DAO (𝔾ℂ DAO) creates a need for reliable oracle solutions necessary for the operation of Pathway, Staking, and Bonding. These core products demand appropriate DONs that provide validated data feeds of price, liquidity, and other fundamental factors. To meet all the oracle-related requirements, SuSy, an infrastructure department of GC, is focused on R&D, DevRel, and the development of infrastructure-level services.

The current oracle-oriented work at SuSy consists of R&D that adds new essential components into the DON solution of Chainlink to attain the goals of GC. To do so, SuSy is extending the functionality of Chainlink oracle services, deploying them first on Fantom, the original 𝔾ℂ DAO blockchain. Even though Chainlink already provides official price feeds on Fantom, applying for such a feed for your token can be difficult and time-consuming. We believe that our permissionless approach can be useful to other dev teams that build on Fantom.

⚜️🏛𝔾ℂ DAO was started on Fantom blockchain network, with its governance token GTON. The main distinguishing feature of ⚜️🏛𝔾ℂ DAO is Pathway protocol, and as described in Pathway white paper, its primary aim is maintaining a price peg to a sum of DAO performance parameters, such as liquidity, active users, integrations, transactions, revenue, assets under management, by determining algorithmically when and how to carry out liquidity interventions.

During Q1 2022, most of the GTON liquidity will be concentrated on the Fantom network, which creates a need for reliable, custom data feeds from the largest pools on Fantom-native AMMs such as Spiritswap. For the Pathway oracle system to function safely, an important requirement is the security and reliability of oracles that provide factors and peg data. To satisfy that requirement, the Chainlink DON solution was chosen and adapted, as shown below. Since documentation on how to set up Chainlink oracle infrastructure with networks other than Ethereum is lacking, we believe that this brief guide can provide some valuable insights for those who need to troubleshoot their Chainlink node testing and production setups on Fantom and other blockchains.

Chainlink on Fantom

Chainlink is a blockchain-agnostic technology, which means that a node can be set up to provide data to any blockchain that supports the LINK token. Even though there are official Chainlink price feeds on Fantom, our setup requires launching a separate consortium of nodes owned by the DAO contributors that can provide a custom data feed. Moreover, the approach for permissionless listing of such feeds can be used by other teams.

Chainlink node settings
Chainlink node settings

In order to run a Chainlink service on the Fantom network, the node itself needs to be deployed according to the official guide from Chainlink. This guide specifies the requirements and basics for running a Chainlink node, focusing on Ethereum Rinkeby as the network of choice for testing.

In theory, a Chainlink setup that works with an Ethereum testnet network such as Rinkeby is expected to be easily reconfigured to serve data on-chain with other EVM-based networks (e.g. Fantom). However, our initial experiments with Rinkeby/Ropsten and Fantom demonstrated that a simple migration approach does not work out of the box and requires research on specific implicit parameters and settings, and reconfiguration to adapt the node to the new network.

SuSy uses a fork of Chainlink node with a custom initiator. Chainlink nodes require their operators to specify jobs to gather and post data. For example, if we need to provide token price data to a blockchain, this has to be described as a job in the TOML format. The v2 Job Specs are much more powerful, as they support new functionality and advanced capabilities like running tasks in parallel in Chainlink nodes. This is an example of job specification used by the SuSy Chainlink node:

Chainlink Job Definition
Chainlink Job Definition

Starting from a working setup on Ropsten, we attempted to transfer the node to Fantom and encountered several challenges: below are a number of important considerations that arose during the deployment process.

Gas Fees

During the initial experiments, it turned out that when the node tries to send the transaction with a higher gas price (to “bump” it), the new price often exceeds the configured max gas price, which leads to transactions failing. This problem with gas calculation was blocking the deployment of a permissionless Fantom price feed and required research and troubleshooting. As it turned out, after the Ethereum update that introduced the EIP1559 feature, the Gas Fee calculation parameters for transactions have changed. Therefore, a dynamical recalculation of fees on the Fantom network is required now. To switch it on, the following parameters for the Chainlink node must be set explicitly:GAS_UPDATER_ENABLED=true

GAS_ESTIMATOR_MODE=BlockHistory

EVM_EIP1559_DYNAMIC_FEES=true

It was later found that in the Ethereum test networks, these settings are applied by default, while with Fantom they must be set explicitly.

Other considerations

RPC Setup

First and foremost, the Chainlink node can only properly communicate with RPC via Websockets. Information about any Websocket endpoints for Fantom testnet in the official documentation of Fantom seems to be lacking (only mainnet is mentioned: wss://wsapi.fantom.network/). Therefore, a testnet Websockets endpoint was found experimentally: wss://wsapi.testnet.fantom.network/

Webhook

If in order for the application to work, a webhook will be used as an initiator, the parameter FEATURE_WEBHOOK_V2=true must be set explicitly. Without this parameter set properly, webhooks will not work, and the Chainlink Job specification will not be applied.

CORS

In addition, CORS must be enabled explicitly to allow sending requests, including from the browser: ALLOW_ORIGINS=* 2.

Currently, a SuSy Chainlink DON that provides a price feed of GTON is deployed to Fantom testnet and mainnet. Here, you can study a verified testnet contract: https://testnet.ftmscan.com/address/0x041d7fc5afcf9dca535769782b80b58370c8f874

Conclusion

This article described our path of setting up our own Chainlink DON on Fantom, together with the discovery of specific parameters and implicit requirements. If all the above conditions are met and native tokens are available on the node’s address, the node will fully function in the Fantom network, both Opera Mainnet and Testnet. Currently, a Chainlink DON on Fantom Mainnet is being integrated into Pathway’s v1 version that is due to be launched in Q2.

In addition, we aim to provide custom Chainlink DONs as a service with permissionless price or liquidity feeds to other projects on Fantom. If you need to setup a custom data feed, please use this form to show interest.

Follow us:

Website | Twitter | Telegram chat | Telegram channel | Discord | Github | Forum |

Arweave TX
ezadq4lYrzmwY1zA-T2vkw7DEikx4PmkxsNH78dngS8
Ethereum Address
0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0
Content Digest
rU9uPkD1kSFTz5PKAw7u34ENDLGr9p1UrD6tdnQG0xU