Fast Updates Parameter Changes

Flare Foundation Proposal to the Infrastructure Provider Management Group to adjust parameters for Fast Updates on both Songbird and Flare

BACKGROUND

Proposed Changes for Flare-

Following FIP.11, the Flare Foundation proposes the following parameter changes involving the FTSO Fast Updates protocol:

  1. sampleSize: this parameter controls the expected number of updates per block. It is set to 1 by default for both Flare and Songbird. However, since the two networks have different block latency, the Foundation proposes an increase of the parameter value for Flare to 1.5.

  2. range: this parameter determines the precision (i.e. step size) of the feed updates, as a function of the expected sample size, through the formula

range = sampleSize * precision

Since the default sampleSize is set to 1, the default value of the range is 1/2^13. Note that due to the above formula, increasing the sampleSize also requires adjusting the range parameter. As such, the Foundation proposes increasing the range by the same factor.

  1. circularLength: this parameter determines the number of blocks during which a volatility incentive remains active. Currently, this is set to 8 blocks, which is roughly 14 seconds on Flare. The Foundation suggests an increase of this value to 17 blocks, which corresponds to roughly 30 seconds at the mean block production rate.

  2. rangeIncreaseLimit: this parameter restricts how much the range parameter can be increased by incentives. At the moment, this is set to 16, but a more conservative approach would be desirable. The Foundation proposes setting this to 5.

  3. rangeIncreasePrice: this parameter determines the cost of increasing the range parameter by 1, thus responsible for the fees of volatility incentives. The parameter is currently set to 10^6 (converted in FLR). The Foundation proposes reducing this parameter by a factor of 5.

Proposed Changes for Songbird-

Following SIP.05, the Flare Foundation proposes the following parameter changes involving the FTSO Fast Updates protocol:

  1. circularLength: currently, this is set to 8 blocks, which is roughly 8 seconds on Songbird. The Foundation suggests an increase of this value to 30 blocks, which corresponds to roughly 30 seconds at the mean block production rate.

  2. rangeIncreaseLimit: at the moment this is set to 16, as on Flare. The Foundation proposes setting this to 10.

  3. rangeIncreasePrice: this parameter is currently 3 times of the one for Flare. The Foundation proposes reducing this parameter by a factor of 15.

Appendix-

Current Values

Current parameter values can be found by calling the FastUpdatesIncentiveManager (or methods inherited from the IncreaseManager) contracts on Flare and Songbird, respectively.

  • getExpectedSampleSize() will return a value scaled by 2^120, as per the SampleSize type defined in the FixedPointArithmetic contract. By default, this call currently returns 1329227995784915872903807060280344576, which is precisely 2^120.

  • getRange() will return a Range type value, which is also scaled by 2^120. By default, this currently returns 162259276829213363391578010288128, which corresponds to 2^-13 = 0.000122.

  • getIncentiveDuration() will return the duration (as the number of blocks) of volatility incentives. The method returns 8.

  • rangeIncreaseLimit() will return a Range type value, which is scaled by 2^120. At the moment, this returns 2596148429267413814265248164610048, which is a factor of 16 larger than the default Range.

  • rangeIncreasePrice() will return a Fee type value, which is not scaled. On Flare, this currently returns 1000000000000000000000000, or 10^24 wei. As such, since 1 FLR = 10^18 wei, this can be converted to 10^6 FLR. Related to the default value of the range parameter of 2^-13, we can then see that doubling the current range costs 10^6/2^13 = 122 FLR. Note that on Songbird the price is 3 times that on Flare.

Variable type

The sampleSize parameter is defined in the IncreaseManager contract, being of FPA.SampleSize type, i.e. a custom type defined in the FixedPointArithmetic contract with 2^120 scaling. The parameter is initialized during the deployment of the FastUpdateIncentiveManager contract via the _ss parameter.

The range parameter is defined in the IncreaseManager contract, being of FPA.Range type, i.e. a custom type defined in the FixedPointArithmetic contract with 2^120 scaling. The parameter is initialized during the deployment of the FastUpdateIncentiveManager contract via the _r parameter.

The circularLength is defined in the CircularListManager contract, and initialized in the FastUpdateIncentiveManager contract via the _dur parameter)

The rangeIncreaseLimit parameter is defined in the FastUpdateIncentiveManager contract as an FPA.Range type variable, i.e. a custom type defined in the FixedPointArithmetic contract with 2^120 scaling.

The rangeIncreasePrice parameter is defined in the FastUpdateIncentiveManager contract as a FPA.Fee type variable, which is a custom type defined in the FixedPointArithmetic contract. The parameter is initialized during the deployment of the FastUpdateIncentiveManager via the _rip parameter.

PROCESS

~ An official request posted in open forum on Discourse for MG members to voice their support or raise any concerns

~ The Flare Team will then initiate transactions from the polling contracts on both Songbird and Flare for MG members to cast on-chain votes either for or against the proposed Fast Update changes

~ If voting reaches quorum on both Songbird and Flare, the Fast Update changes will be implemented on the respective chain(s)

2 Likes

I will be voting for this proposal.
Every change i see is there to improve this system.
Makes it a lot more affordable and usable in periods of high volatility to allow fast updates to catch up

Hi, I will vote for this improvement…

We will vote for it because:

  1. the purpose is to improve the system
  2. it will make the system better than the current one
  3. anything unexpected that may happen after will be discussed and if necessary fixed as always

I am in support of this proposal.

FTSO London supports this proposal