FIP.05: Update Services, Limits, and Rewards Required for Staking

Type Flare Improvement Proposal
Author Flare Foundation
Created 16-Aug-2023
Revision 2
Document Status Final
Majority Condition 50% (required)
Voting Outcome Accepted on 8-Sep-2023
Timeline 22-Sep-2023 Deployed on Coston2.
25-Sep-2023 Deployed on Flare.

1. Brief Description

The Flare Network is transitioning to a proof of stake consensus mechanism as explained in the Validator Nodes documentation page. This transition requires:

  • Implementing necessary infrastructure services.
  • Modifying the current staking limits.
  • Increasing the portion of inflation destined to validation rewards.

This proposal executes all the above changes, as detailed next.

2. Technical Description

2.1 New Infrastructure Service

In a manner similar to Avalanche, the Flare network is composed of two independent blockchains: The platform chain (P-chain) and the contract chain (C-chain). The P-chain manages platform-handling operations, like validator staking, whereas the C-chain implements the EVM and runs all the smart contracts.

Because validators stake on the P-chain and rewards are distributed through smart contracts on the C-chain, a mirroring service will be developed. This service will track, in a secure and decentralized manner, the amounts staked on the P-chain in a contract on the C-chain. This service will enable validators to claim their validation rewards in the same way FTSO rewards are claimed, for example, and benefit from facilities like automatic claiming.

2.2 New Staking Limits

To simplify the onboarding of as many validators as possible, the following staking settings will be changed.

Note that some of these settings require changing the P-chain configuration and hence a network fork.

Some other settings affect only the mirroring service and are described here for the first time. All limits enforced by the P-chain will also be enforced by the mirroring service.

Setting Current value Proposed value
Minimum self-bond amount 10M $FLR 1M $FLR
Minimum delegation amount 10M $FLR 50K $FLR
Minimum stake duration 2 weeks 2 months
Minimum delegation duration 2 weeks 2 weeks
Stake delay 11 days immediate
Delegation factor 5 times 15 times
Maximum total stake 50M $FLR 200M $FLR
Maximum validators per infrastructure entity N/A 4

Setting descriptions:

  • Minimum self-bond amount: Minimum stake that an entity must provide to become a validator. This setting reduces staking requests, which frees network resources.

  • Minimum delegation amount: Validators can accept stake delegations from any $FLR holder, so their stake and validation rewards are increased. The specified value is the minimum stake amount that can be delegated. This setting reduces delegation requests, which frees network resources.

    Validators can set a staking fee and will earn staking rewards for its own self-bond and a fee on any stake delegated on them.

    This stake delegation is not related to FTSO delegation nor governance delegation.

  • Minimum stake duration: Minimum amount of time that self-bond funds must remain staked, and therefore locked.

  • Minimum delegation duration: Minimum amount of time that delegated funds must remain staked, and therefore locked. This setting does not change. It is included in this list for clarity.

  • Stake delay: Duration that passes between the time when funds are staked and the time when they become effective. During this period funds are locked. This delay provided added security when staking was enabled for the first time and stakes were small, since any suspicious stake could be analyzed before it became effective. Now that larger stakes are in place this restriction will be lifted to simplify onboarding of new validators.

    Note that there is no such delay involved when withdrawing staked funds once the staking period expires.

  • Delegation factor: The total amount that can be staked to a validator is limited to its self-bond times this factor. For example, with the proposed value of 15, if a validator has a self-bond stake of 1M $FLR, the total sum of all stakes, including delegations, cannot exceed 15M $FLR. This allows for 14M $FLR of delegations.

  • Maximum total stake: Maximum stake per validator, including self-bond and delegations.

  • Maximum validators per infrastructure entity: A single infrastructure entity can include up to this amount of validators.

    Infrastructure entities also include FTSO data providers. For example, a single FTSO data provider can create up to 4 validators, each one with its own stake, and claim the validation rewards for all of them.

    This restriction is not enforced by the P-chain staking mechanism but by the mirroring service, and will not take effect until phase 3.

    If an infrastructure entity has more than one validator, each of the validators must fulfill the above requirements.

2.3 New Validation Rewards Distribution

The yearly inflation is used to reward FTSO data providers and validators in the following manner:

Provider Current value Proposed value
FTSO data providers 80% 70%
Validators 20% 30%

Staking rewards will:

  • Take into account validator uptime, which can be publicly monitored, and existing validator security measures. Uptime must be above 80% to receive rewards.
  • Take into account staked amount, including self-bond and delegations.
  • Require that the FTSO data provider is constantly rewarded for providing good enough prices.
  • Be manually calculated off-chain using a public script and then distributed on-chain.

GitHub Pull Request #18 on the flare-foundation/go-flare repository.

4. Proposed Implementation Date Range

If the voting passes, deployment of the new code will start immediately.

5. Voting Details

To pass, the proposal requires a simple majority of votes in favor of it.

6. Deadline for Voting

  • Notice period: 25-Aug-2023 to 31-Aug-2023
  • Voting period: 1-Sep-2023 to 8-Sep-2023

7. Interaction with the FTSO Management Group

FIP.02, approved on March 2023, introduced the FTSO Management Group with the goal of “reporting possible infractions by FTSO data providers and collectively determine whether punitive actions should be taken”.

Section 5 of FIP.02 states that:

The FTSO management group will operate under the proposed conditions only until a staking mechanism for data providers is implemented.

However, the management group has proved to be such a useful tool that it is proposed to continue its operation, as an additional security measure.

8. Revision History

Revision Changes
1 Initial document.
2 Set minimum uptime to receive rewards to 80% (Clause 2.3).
Add link to code repository (Clause 3).