The Flare Network whitepaper introduced the Spark token (FLR) and the Flare Time Series Oracle (FTSO) as the decentralised on-chain mechanism providing time series estimates to the network. But, what exactly does this mean? And how does it work? These are some of the questions that this blog post will address.
Refresher: the Flare Network and Spark token
The Flare Network is the first Turing complete Federated Byzantine Agreement (FBA) network. Nodes run the Avalanche consensus protocol with a key adaptation to the FBA consensus topology. Furthermore, the network leverages the Ethereum Virtual Machine (EVM), enabling the network to run Turing complete smart contracts. FLR is the network’s native token.
If this means nothing, that’s ok. The key takeaway is the following. Network safety does not rely on the native token, FLR, for safety. Hence FLR can be used to create utility.
What is the FTSO?
The FTSO provides externally sourced data estimates to the Flare Network in a decentralised manner. It does so by leveraging the distributed nature of the network and its participants.
For example, the FXRP system requires the FLR/XRP price. A centralised system would for instance take this price from an exchange, updating the price at regular time intervals. But, a decentralised system relying on a centralised data feed would essentially render it centralised itself. The FTSO provides a decentralised solution to this problem.
For example, the FTSO might output four data time series: the XRP/USD, FLR/XRP, FLR/BTC & FLR/LTC prices.
Creating a data time series
A time series is how we refer to a specific data feed, such as for example, the spot (current) price of XRP, that has already been processed by the FTSO. This data point is now available for use by smart contracts.
For example, the FLR/XRP price is updated at regular and prescribed time intervals, thus resulting in a time series. The price is updated by taking price estimates from both holders of Spark and holders of FXRP. By virtue of holding either FXRP or FLR, both these groups have an implicit stake in the system i.e. an incentive to act honestly, as accurate pricing maintains the systems integrity and utility.
At regular time intervals, FLR and FXRP token holders submit their estimates to the FTSO, from which the FLR/XRP price is computed.
This document concentrates on the FLR/XRP price. The methodology is replicable across all potential F-assets, such that if Litecoin is represented on Flare as (FLTC) then the contributors to the FLR/LTC price in the FTSO would be the holders of FLR and FLTC.
Constructing price distributions
Each address submits their vote, which results in a weighted distribution over prices at a given time, where the weight is related to the amount of tokens held by a given address (this is where it gets interesting, see voting power and delegation below). Next, the top and bottom 25% of these votes are deleted, resulting in a truncated distribution. The oracle estimate is computed as the median of this truncated distribution. This, is the FTSO FLR/XRP price for this given round.
For example, say Alice, Bob, Charlie and Eve choose to participate in a round of voting and that respectively own 1, 2, 3 and 2 tokens. They submit the following prices: Alice a 3, Bob a 4, Charlie a 5 and Eve a 6. These submitted votes are weighted by their token holdings.
Weighted by token holdings, Alice effectively submits one vote for 3, Bob two votes for 4, Charlie three votes for 5 and Eve two votes for 6.
This effectively corresponds to a total of 8 votes. The top 25% are then discarded i.e. the upper and lower two votes, resulting in the truncated price distribution.
One of Bob’s votes and all of Charlie’s votes survive the truncation, and will thus contribute to the oracle price estimate.
Finally, the oracle estimate can be computed as the median of the resulting distribution i.e. 5. This price is the output of the oracle for this voting round.
Why vote?
Because if the provided estimate is close enough to the oracle output, then a reward is earned. This allows participants to actively gain FLR, and incentivises them to not only provide data estimates, but to provide good estimates!
More specifically, FLR holders that submitted an estimate that remained in the distribution after truncation are compensated. The precise amount of FLR tokens minted for reward is a network governance parameter, which is initially set at 10% of FLR tokens in circulation per annum. This is the award rate, and is spread out over the voting rounds in a year. The amount earned by an address essentially depends on the normalised fraction of tokens held by (or delegated to) the address which contribute to the price. This is easier to understand by example.
In the previous example, 50% of Bob’s tokens contributed to the final price and 100% of Charlie’s tokens contributed. Thus Bob would earn 0.5/(0.5+1) =1/3rd of the award and Charlie would earn 1/(0.5+1)=2/3rds of it (see whitepaper for specifics).
FXRP holders can participate, they do not automatically get compensated. Instead, FXRP holders are incentivised to vote to ensure the integrity of the XRP/Spark price. Importantly this does not mean that FXRP holders (more generally F-asset holders) cannot get compensated. It is likely that parties that make it their business to earn FLR through the FTSO will provide a return to F-asset holders in return for those holders delegating their votes to them. This would in turn provide a yield to holding an F-asset.
Beyond the XRP/Spark price
FXRP is an example of an F-asset, and the governance system allows for many other types of F-assets to be created. Holders of both FLR and the F-asset can then potentially submit price estimates to the FTSO, thus resulting in a variety of different time series.
Thus, more generally, the FTSO may give rise to n data time series at each round. FLR token holders can provide estimates for each of these i.e. they can submit up to n data estimates, whereas F-assets would provide estimates as determined by governance.
Compensation
In the case where there are n data feeds, a FLR holder can submit n data estimates at a given round. At each round, a number between 1 and n is drawn, and addresses whose estimates were close to the output of the oracle will be rewarded with a given amount of FLR tokens (a governance parameter).
For example, let’s say there are 10 time series. Each FLR holder can submit 10 estimates, one for each time series. Then, a number between 1 and 10 is drawn, say 4. FLR holders who contributed to the 4th time series are then compensated, according to the mechanism previously described.
Thus, the Flare Oracle acts as an inflation mechanism for the network, increasing the FLR token supply and rewarding FLR token holders who provide good estimates to the FTSO. In this sense, it is the equivalent of mining. Furthermore, it acts as an economical incentive for FLR token holders to act honestly.
Crucially, it transfers value from people who do not participate in the system or who participate in a malicious fashion, to people who provide utility to the network.
Choosing data estimates
Submitting honest data estimates at each round provides two main advantages. First, it allows for the token holder to potentially earn a reward and increase their FLR token holdings. Second, it ensures that the oracle outputs correct prices, which ensures the stability of both FLR and the F-assets. Thus, it is in the interest of FLR as well as F-asset token holders to submit good estimates at each voting round.
It is natural that token holders may want to delegate this task to an entity who they believe will do a good job. More generally, the votes for the oracle (and the votes for the governance) can be delegated i.e. bestowed some or all of these to another address without transferring the tokens themselves.
Delegation corresponds to an address on Flare assigning its own Spark (FLR) token votes (or F-Asset votes) and any votes already assigned to it, to another address on Flare.
This can be done or undone at any time. Furthermore, delegation can be done multiple times. The number of non-delegated tokens held by an address plus any tokens delegated to that address, that are themselves not further delegated give the addresses voting power.
This results in the potential for an ecosystem of data providers to the FTSO, who would retain a fraction of the award won in exchange for providing good signals.
A marketplace for signal providers
Any FLR or F-asset holder could choose to delegate their votes to whoever they believe will provide honest votes. In return, the oracle signal provider might take a fraction of the earned reward in exchange for their service.
Votes can be delegated to oracle signal providers, thus creating a competitive ecosystem for signals submitted to the FTSO.
Prices are computed based on votes associated with both FLR and F-asset addresses. Thus, signal providers might choose to also reward F-asset holders for the delegation of their votes, in order to contribute more significantly to the oracle estimates.
This gives rise to the potential for a marketplace of signal providers, with various different FTSO signal providers, acting on behalf of token holders, each submitting prices according to their own methodology. Furthermore, such an ecosystem could be further leveraged by any decentralised application on Flare.
For further news & updates make sure to follow us on Twitter.
