FTSOv2
The Flare Time Series Oracle (FTSO) is an enshrined oracle that provides decentralized data feeds to the Flare network. Since the release of FTSOv1 two years ago, users and applications on Flare have enjoyed consistent and reliable pricing, with zero downtime or failures. FTSOv2 builds on the robust foundation laid by its predecessor, offering several enhancements:
-
Secure. Enshrined into Flare's core protocol, every oracle feed in FTSOv2 inherits the economic security of the entire network.
-
Fast. FTSOv2 features block-latency feeds, updating with each new block on Flare, every ≈1.8 seconds.
-
Scalable. FTSOv2 supports up to 1000 feeds across various asset classes including equities, commodities, and cryptocurrencies, with access to 2 weeks of historical data.
-
Decentralized. Each FTSOv2 feed is supported by around 100 independent data providers, who are selected by Flare users through their delegated stake, imposing a strict economic cost for misbehavior.
-
Cost-effective. Block-latency feeds in FTSOv2 are completely free to query. Feeds from Scaling are also free to query and verify locally, with minimal gas costs for onchain verification.
Architecture
FTSOv2 ensures fast, secure, and manipulation-resistant feeds by using a stake-weighted verifiable randomness function (VRF) to select a sample of data providers for incremental delta updates. These updates maintain long-term accuracy by anchoring to Scaling feeds, which use a full commit-reveal process and update every 90 seconds. During high market volatility, volatility incentives can increase the sample size of data providers for a quicker response to market conditions.
The FTSOv2 architecture consists of four key components:
-
Verifiably Random Selection: Each block on Flare triggers the selection of data providers to deliver the next feed update using a stake-weighted Verifiable Randomness Function. This ensures fairness and resistance to manipulation.
-
Incremental Delta Update: Selected data providers submit new feed updates as fixed incremental deltas applied to the previous feed value. This maintains reliable and continuous updates, ensuring integrity and accuracy.
-
Volatility Incentive Mechanism: To handle periods of high market volatility, FTSOv2 introduces volatility incentives, temporarily increasing the sample size of selected data providers in exchange for a fee. This permissionless mechanism ensures a faster response to significant price movements.
-
Anchoring to Scaling Feeds: Scaling feeds, which employ a full commit-reveal process across all data providers, act as anchors to ensure long-term accuracy.
For a detailed explanation of the FTSOv2 mechanism, read the FTSOv2 whitepaper.
Verifiably Random Selection
Every block on Flare, generated approximately every 1.8 seconds, initiates the selection of a sample of data providers to deliver the next feed update. This selection process leverages a stake-weighted verifiable randomness function (VRF), where the likelihood of each data provider being chosen is proportional to their stake. The expected sample size is one, and data providers have no control over, nor knowledge of, when they will be selected.
In detail, each block has a unique seed value, used by FTSOv2 data providers to generate a personal random score. This score, coupled with a cryptographic proof, ensures its authenticity and verifiability, preventing prediction or manipulation by others. Data providers are chosen based on their scores: those with scores below a certain threshold are selected to make updates. The selection probability is proportional to the data provider's stake, allowing for weighted sampling where participants with a higher stake have a greater chance of being selected. This mechanism ensures fairness and resistance to manipulation.
To maintain security, the seed value itself evolves pseudo-randomly. This approach balances security and randomness, preventing adversaries from influencing the selection process. The system is designed to be statistically robust, ensuring a reliable and continuous selection of participants to uphold the integrity and accuracy of updates.
Incremental Delta Update
The selected data providers submit the new feed update, which is a fixed incremental delta applied to the previous feed value. The base increment size for all updates is 1/2^13 ≈ 0.0122%
, a value determined through extensive market analysis and approved by Flare governance. The delta can be in one of three directions:
- Up (+): The new feed value is incrementally increased from the previous value.
- Down (–): The new feed value is incrementally decreased from the previous value.
- Unchanged (0): The new feed value remains the same as the previous value.
The mathematics of incremental delta updates.
The FTSOv2 protocol utilizes block-latency feeds, denoted as , which are continuously updated following the formula,
where,
- is the protocol parameter named precision, and
- is the update provided by a data provider, with being one of the three options .
The precision parameter is set to a default value of , which has been rigorously tested against price feeds from centralized exchanges. Another key protocol parameter is the average number of updates submitted per block, with a default value of . The average number of updates submitted per block can be temporarily increased in exchange for a fee using the volatility incentive mechanism.
Volatility Incentive Mechanism
From statistical analysis, FTSOv2's mechanism is capable of capturing over 99% of all price movements under normal market conditions. However, during periods of high market volatility, the small size of each increment may be slower to reflect large price movements. To address this, FTSOv2 introduces volatility incentives, which allows for a temporary increase in the sample size of data providers in exchange for a fee. The volatility incentive mechanism is permissionless, enabling anyone on Flare to trigger it by paying the required fee.
Typically, the expected sample size is one. With volatility incentives, this sample size is temporarily increased, allowing for more updates and quicker responses to large price movements. Importantly, only the expected sample size increases, not the actual sample size, which further helps protect the protocol against various statistical attacks.
Anchoring to Scaling
FTSOv2's block-latency feeds are designed to be statistically self-correcting. To further ensure their long-term accuracy, FTSOv2 uses the anchor feeds from Scaling. Anchor feeds utilize a full commit-reveal process across all data providers with an inter-quartile range (IQR) band calculation, and update once every voting epoch (i.e. 90 seconds). Data providers are only rewarded if the block-latency feeds converge to within ±0.25%
of the anchor feeds every voting epoch.