Flare Time Series Oracle Is Evolving To Support More Sophisticated Web3 dApps

Table of Contents

• FTSO In A Nutshell
• How Do They Work Together? 
• Why is A Change Necessary?
• How Flare Will Scale
• Phased Rollout
• More Utility For Web3 dApps

If its recently announced governance proposal comes to pass, the popular Flare Time Series Oracle will become even faster and more reliable, providing support for more data types and laying the groundwork for a newer generation of more sophisticated decentralized applications. 

The FTSO can be thought of as a constantly updating, decentralized time series data stream that sends valid off-chain information to dApps built on the Flare Network. It solves the challenge of delivering off-chain data to dApps in a way that doesn’t rely on the honesty of centralized services, which requires too much trust from users. 

Time-series data refers to information that changes over time, such as currency pairs in FTX. At present, the FTSO is focused solely on crypto price pairs such as BTC/USD, with a feed that updates once every three minutes. It also provides price feeds for tokens such as ADA, ARB, AVAX, BNB, ETH, FLR, SGB, LTC, SOL, USDC, USDT and XRP, among others. 

However, time-series data can also be other things, such as commodity prices, the weather, sports results, inflation data, interest rates, stock prices, housing starts and just about anything else. 

Flare is proposing to expand its protocol through an FTSO Scaling proposal, that would see it able to support thousands of different data streams, making it far more useful to dApp developers. 

FTSO In A Nutshell

Web3 wants to be fully decentralized, and that means dApps cannot rely on centralized data sources for off-chain data. To solve this challenge, Flare created a system that relies on four components. 

The first are the data providers, which are independent oracles that collect data, report it to the FTSO and earn rewards for their efforts. Second are the delegators, or FLR token holders who delegate tokens to individual data providers they believe are trustworthy, in order to earn a share of the rewards they generate. Third are the dApps built atop of Flare that utilize FTSO’s data streams, and fourth is the FTSO itself, which is based on a set of smart contacts that enable the above three participants to interact with it. 

How Do They Work Together? 

The data providers are what make FTSO decentralized. Because each one is an independent entity, not influenced by Flare in any way, they can create their own systems for collecting accurate data. They can either use external sources or create their own methods for gathering this information, which is then submitted to the FTSO. Should the FTSO deem their data to be accurate enough, they’ll earn FLR tokens as rewards for this work. 

FTSO’s ecosystem is made up of hundreds of data providers who all compete with one another, and that is what makes things competitive. Data providers are challenged to ensure their data is as accurate as can be. Once every data provider submits their data, the top and bottom 25% of submitted prices is removed, with the rewards allocated to those whose information was closer to the median of all of the submitted prices. The exact amount of rewards earned by each data provider is weighted according to the volume of FLR tokens delegated by token holders. 

The delegators therefore play a critical role in incentivizing the data providers to ensure the information they submit is accurate. The system rewards those that provide higher-quality information, and as a data provider becomes more consistent, it will attract more delegators, thus increasing its rewards. Meanwhile, data providers that are less accurate will lose delegators, meaning they earn fewer rewards. 

Why is A Change Necessary?

The aim of the FTSO Scaling proposal is to support new use cases that require more consistent updates and a wider range of off-chain data. The proposal will enable data providers to submit more than 1,000 data feeds every 90 seconds, and they will no longer be limited to crypto prices only. 

To improve on efficiency and reduce gas, the FTSO Scaling proposal will enable data providers to perform their calculations off-chain and post a “rolled-up” version of their results in the form of a Merkle Root hash. This is far more scalable than the existing process, where calculations are performed and each individual asset price is stored on-chain

Initially, the update will result in 25 new cryptocurrency price pairs being added to the FTSO’s feed, with more prices added for assets such as stocks, bonds, commodities, forex pairs and so on, based on user demand. 

How Flare Will Scale

Under the proposal, the role of the data provider will be expanded. They’ll continue to submit data via a commit and reveal process, where they first submit their information in secrecy, before revealing it all at once to prevent cheating. However, there will be two new steps in the process, known as the Sign Phase and the Finalization Phase. 

The first allows data providers to filter out reveals that do not match their commits, allowing for only valid reveals to be used in the calculation of median values and reward distributions. Then, in the Finalization Phase, once a sufficient number of signatures is submitted for voting purposes, any participant is free to collect these and submit them for voting. The system will integrate checks that verify a sufficient threshold of signatures has been submitted, amounting to 50% of the total weight of eligible data providers. Once successful the Merkle Root will be published within the voting contract and made available to all other data providers, who can use it to verify the calculations are correct. 

There will be changes to the rewards distribution process too. Instead of data providers keeping all of the rewards for the data provision process, instead this will be limited to just 80% of the rewards, with the remaining 20% split between those who participate in the Submit and Finalization phases. So 10% of the rewards will be distributed to anyone who submits a single, valid signature, and 10% to the first five entities that process finalization accurately. 

Under the proposed changes, the length of the Commit phase will remain the same, at 90 seconds, but the other three phases can be much shorter, depending on how quickly data providers can perform submissions. Essentially, they’re being incentivized to speed up the process to ensure more frequent updates are possible. 

Data providers will be penalized in the event that they’re unable to verify that the hash of the revealed data matches the hash of their committed data. Such incidents are known as “reveal withholding” and are basically an attempt by the data provider to cheat, hence the need for penalties to be applied. 

Double-signing will also be penalized. Should a data provider post an invalid signature or sign for more than one result in the same voting round, they will be penalized by 30-times their expected share of the rewards in that voting round when they’re paid out at the end of the current epoch. The dedicated amounts will be burned in both cases. 

Phased Rollout

If approved by the Flare community, the FTSO Scaling proposal will be rolled out in three phases, giving data providers time to adapt to the new process. 

The first will be the trial phase, during which current data providers will be able to receive 100% of all FLR rewards, while updated data providers won’t earn anything. That will change in the beta phase, when the rewards will be split 50/50 between current data providers and updated data providers. Finally, when the depreciation phase kicks in, only upgraded data providers will be entitled to earn rewards, sharing 100% of the distribution between themselves.

More Utility For Web3 dApps

The proposal is a big step for Flare, paving the way for it to support many more data types, beyond what it has traditionally provided. It will no longer be restricted to just a few token prices, but instead expand to cater to almost any kind of data that might feasibly be used by a dApp. For instance, FTSO would be able to provide soccer results that can be utilized by blockchain-based betting applications, or weather reports used by a weather forecasting app. It could provide data on interest rates for real estate-focused dApps. There are thousands of possibilities.  

If Web3 is to go mainstream, it needs more user applications and real-world utility, and that means being able to access off-chain data. Through its evolution, FTSO will be able to support high-integrity data in a secure, reliable and scalable way, both from other decentralized networks and also real-world sources, creating a foundation for this new generation of dApps. 

This improved data acquisition will benefit developers, especially those focused on Web2 to Web3 composability. It will also support advances in decentralized autonomous organizations, artificial intelligence applications, DeFi dApps, NFTs and more.

Data oracles will play a vital role in helping dApps to achieve broader utility and solve more real-world problems, and FTSO is blazing a trail for that to happen. 

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.