STP.07: Add Support for FTSO Fast Updates

Type Songbird Test Proposal
Author Flare Foundation
Created 9-Apr-2024
Document Status Final
Threshold Condition 75% (required to reject) 4.09% (obtained)
Majority Condition 50% (required to reject) 1.25% (obtained)
Voting Outcome Accepted on 18-May-2024

1. Brief Description

Flare’s FTSO system, including its Scalability upgrade, gathers input from several data providers before producing an outcome, which results in safe values but with a low throughput. This proposal introduces FTSO Fast Updates, a protocol that allows a smaller number of randomly-selected data providers to submit a separate stream of updates in each block, resulting in a much higher rate. The values from this separate stream (stream values) do not affect the regular FTSO results (anchor values), which continue to be produced in the same way and at the same rate.

The downside of the increased throughput is diminished stability of the fast updates, because a smaller number of data providers, typically one, are participating in each update. However, the following circumstances limit the extent of this drawback:

  • The providers of each update are randomly selected in each block, making it very difficult to take advantage of a submission to manipulate prices.
  • Subsequent updates are submitted by different providers and will likely correct any error introduced by previous submissions.
  • Providers of fast updates are rewarded if their submissions are close enough to the anchor values, keeping both streams aligned.

This proposal rewards fast update submissions from the same FTSO reward pool as submissions of anchor values. Since this is a change in the way the current FTSO system works, a governance vote is necessary.

The following sections describe in more detail the proposed changes.

2. Technical Description

The FTSO version 2 was introduced in a whitepaper, which describes both the FTSO Scalability protocol voted on STP.06, and the FTSO Fast Updates protocol proposed in this STP. This STP highlights the features of the Fast Updates protocol that affect the current FTSO system and therefore require a governance vote. For the technical details, please refer to the whitepaper.

2.1 Changes to FTSO Rewarding

As of STP.05, A portion of the Songbird network’s yearly inflation is reserved for rewarding FTSO data providers. STP.06 further refined how these FTSO rewards are split among participants in the FTSO Scaling protocol. STP.07 proposes to split the total FTSO rewards between participants in FTSO Scaling and FTSO Fast Updates.

This STP proposes that the total FTSO rewards are divided in the following manner:

  • 70% to participants in the FTSO Scaling protocol, as described in STP.06.
  • 30% to participants in the FTSO Fast Updates protocol, as described in the FTSO v2 whitepaper.

Additionally, consumers of the FTSO data feeds can choose to offer additional rewards to increase the rate and magnitude of the fast updates, resulting in better volatility protection. These additional rewards are pooled together and evenly distributed among providers, allowing more frequent updates to be submitted, and their value to be bigger so that they can better adjust to sudden value changes.

All rewards for the FTSO Fast Updates protocol are evenly distributed among all data feeds.

2.2 Deployment Strategy

Enabling the FTSO Fast Updates protocol does not require a hard fork of the network. Instead, the new contracts listed in the next section will be deployed, and the inflation allocation updated as previously described.

During the 90 days following the deployment, the Flare Foundation may change some of the system’s parameters to fine-tune it.

4. Proposed Implementation Date Range

If the vote passes, the following actions will be taken:

Change Date
Deploy on the Songbird network Early June
No more configuration changes allowed 90 days after deployment

5. Voting Details

An STP is rejection-based, meaning that it is accepted unless certain conditions are met, namely, that the quorum threshold (75%) is reached and at least half of the votes are against it. (See Governance.)

6. Deadline for Voting

  • Notice period: 14-May-2024 to 17-May-2024
  • Voting period: 20-May-2024 to 26-May-2024