How To Become An FTSO Data Provider

Index

Being an FTSO Data Provider is a very rewarding role, you encounter new challenges to overcome and battle in a friendly competition with fellow data absorbing, signal providing entities.

Before you take up arms to join this adventure you’re going to need to understand and learn some important key aspects of a good Data Provider.

Keep in mind, if your goal is to become the next leader in success rate, you must have a solid foundation that employs these vital methodologies. Also, the goal of the FTSO system is to be a decentralised data oracle, so you must avoid copying and following others strategies where possible.

I recommend watching through this entire video first so you can pick up on all the nuggets of information in each section then later you can jump back to a particular topic you need more information on. Use this information as a guide and you’ll be on your way to being a quality FTSO Data Provider.

Coding languages

Your first decision is choosing which language to use to build the part of your service which makes submissions to the FTSO smart contracts. This for the most part is personal preference but my recommendation would be to use the language you are most comfortable with so long as there is a Web3 library available.

Some examples of Web3 libraries are:

EthersJs or Web3Js for Javascript/NodeJs
Web3Py for Python
Web3J for Java

The best way to find a library for your selected language is to do a quick Google search for your language name and append “web3 library”.

Components

As a Data Provider you can consider there to be two components that make up your service: The code that submits data to the FTSO, and the code that runs your data algorithm. While you could have both aspects in one code base, a good consideration would be to separate these components to make each easier to maintain.

Let's call the first component your “Submitter”. This will house all the logic required to assess which data epoch you are submitting for as well as when and what to submit throughout all reward epochs. As you should already be aware, the FTSO system uses epochs to segment rounds.

Reward Epoch

At the top level we have the “Reward Epoch” which runs for a set amount of days and at the beginning something called a “Vote Power Block” is chosen. The Vote Power Block is a block number which is chosen from the last quarter of mined blocks in the previous reward epoch. This is important to understand as the Vote Power Block determines at what point in time a snapshot of your vote power is taken. This affects the amount of weight your data submissions will carry against all other data providers as well as your earning potential during the Reward Epoch.

To determine your snapshotted vote power, or otherwise known as locked vote power, for a particular Reward Epoch we first must find the Vote Power Block from FtsoRewardManager smart contract and query the getRewardEpochVotePowerBlock function specifying the reward epoch we’re interested in. We then navigate to the wNat smart contract and query VotePowerOfAt specifying the data providers address and the Vote Power Block we just gathered. Displayed is your locked vote power in Wei, we can divide this number by the exponent of 18, since it's an 18 decimal token, and find the value in FLR or SGB.

Whitelisting

The FTSO system only allows a set number of FTSO Data Providers to actually participate in making submissions. You can find the exact number on the VoterWhitelister contract under the method maxVotersForFtso. This by default is 100. Now to be a part of this 100 you must get whitelisted - but the cool thing about this is that you can make a request to be whitelisted and are automatically added providing you meet the minimum criteria.

The criteria is very straightforward, the whitelist is composed of the data providers with the most locked vote power. So, as long as you have more locked vote power in the active reward epoch than a Data Provider with the smallest amount of locked vote power in the whitelist, you will bump the smallest data provider out and be granted entry upon calling the requestFullVoterWhitelisting method on the VoterWhitelister contract.

The key takeaway for whitelisting is, your request for whitelisting will be judged on your locked vote power that you entered the active reward epoch with. This means you might need to wait until the next reward epoch to request whitelisting if you have only seen an increase in vote power after the latest Vote Power Block has been chosen.

Setting Fee

Setting your fee is done via the FTSORewardManager smart contract by calling the setDataProviderFeePercentage method. Now listen up because this often catches out new providers, you must specify your fee in Basis Points or “BIPs” for short. So for example, if you would like to set your fee to 15 percent, you must specify the value 1500. Essentially take the percentage amount you want to use, say 15 percent and multiply it by 100. By default your fee is set to 20 percent so there is no need to make any changes if you’re happy with that.

Data Epoch

The next level down from the reward epoch is the “Data Epoch” which are rounds spanning only a few minutes. In every data epoch you are competing to submit time series data for all supported assets and have the value of your submissions fall into the median of all other submissions. This is the front of the battle. It’s recommended you study the FTSO Median specification document to learn more about how the median behaves.

Submit Window

The data epoch is broken into two windows, the submit period and the reveal period. It’s the Submit Period where you will apply most of your strategy. You must take time and assess the activities of other data providers. The submit period runs for a duration of 3 minutes; therefore it’s important to determine when in that period to make your final submission, also known as your “commit”. You may find that data providers tend to make their commit after a certain duration has elapsed in the submit period.

Reveal Window

The following “reveal period” requires less strategy however some considerations you should have are ensuring you only send your “reveal” after the submit period concludes and before the reveal period concludes. You should also expect to be required to use more gas in your reveal transaction due to the larger amount of data contained. On the topic of gas, a cool feature of the FTSO system is that Data Providers get refunded up to a gas limit of 3,000,000 on all their commit and reveal transactions. The only caveat is that if the transaction is reverted, a refund will not be processed and the gas will be spent. So before setting your gas limit to this generous maximum, ensure your code is working smoothly.

Algorithm

The algorithm you build which collects and processes data is your secret weapon. It’s something that you must build independently and avoid sharing. You’ll find this to be the biggest challenge of your data provider journey. Since it is something each provider holds close to their chest, I am limited to what information I can share here.

However, some things you should consider are:

Don’t use centralised data sources for your submissions

What do I mean by this? I mean your primary source of data should not come from API’s provided by the likes of CoinGecko, CoinMarketCap or any other similar data aggregators. Your aim to to provide an accurate and decentralised data feed, these sources will leave you open to availability issues and decentralisation issues. Instead look at gathering data directly from each source.

Avoid using open source code

This goes for both your submitter code and your algorithm. While you are free to do so, you will quickly find that you will not be as successful as you may want to be. It’s also extremely beneficial to write your own code which gives you a far better understanding of the systems you are working in and thus a much better competitive advantage.

Be open to trying new strategies

You should allow yourself time to test new strategies and even build your own tools that assist you in doing this. You can also use the freely accessible FTSO Monitor tool for Songbird or Flare which makes certain statistical data about your performance available.

There is no right or wrong

Something that is best to understand early on is that there isn’t any particular discussed consensus on what the “correct” value is when it comes to your submissions. There are however strategies that allow data providers to find the median more frequently than others. Also don’t get caught up in blaming vote power as the determining factor of good performance as in the big picture, it really will not help you if you have an inferior algorithm.

Additional Advice

Kick Off Package

You should consider utilising the official “kick off” package from Flare which deploys the FTSO smart contracts on a local hard-hat server enabling you to run your provider code in a controlled environment. This is a great place to test new features, just be sure to use the correct version that you want to test for. As an example, a new way of submitting data was introduced on Flare Mainnet while the old version remained on Songbird, so you will need to consider having two code bases for each network. All details for running the kick off package can be found within the package.

ABIs

You should ensure you are using the correct ABI’s - these are essentially instructions for your Web3 library to use when interacting with each smart contract. If the ABI you are using is out of date or only intended to be used on one of Songbird or Flare you will run into problems. So ensure you use the latest and network specific ABIs by finding them in the Flare Foundations smart contract repository under the deployed branches.

Nodes

It’s a necessity to run your own Flare and Songbird node while participating as a Data Provider if you want optimal performance. Making your commits and reveals on time is vital and if you are using a public node, you’ll experience delays, especially during peak periods such as just after a reward epoch ends when delegators scramble to claim their rewards. So, invest in good infrastructure and preferably ensure your node server is geographically in the same region or availability zone as your FTSO submission server.

Public Listings

In Flare’s blockchain, you’re identified as just an address, a string of letters and numbers. This makes it a bit tricky for delegators, who you are trying to attract, to find your service and make their delegations. To help grow your public profile as a data provider you can link your address to a name and image via services like the BiFrost Wallet from TowoLabs by making a pull request on their providers repository as well as submitting your profile to FlareMetrics.io by visiting their support site to find the latest instructions on how to do so.

Final Comments

The developer community on Flare is growing and full of people willing to offer their advice so if you do have questions or issues you should tap into the various channels available such as the official Flare Network Discord server. Before you post a question, make a quick search as quite often you’ll find your question has already been answered.

On a final note, it is easy to participate as a data provider, but to become a leader in the field will prove to be a difficult feat.

I hope you’ve found this information useful and look forward to seeing you accepting the FTSO Data Provider challenge!

How To Become An FTSO Data Provider | Flare Network