Two key governance proposals, FIP.10 (Flare Improvement Proposal) and SIP.04 (Songbird Improvement Proposal), will soon be open for voting.
Both proposals aim to introduce a pass-based incentive structure to enhance provider participation in all Flare protocols. This is an opportunity for Flare users to shape the ecosystem’s future.
FIP.10: https://proposals.flare.network/FIP/FIP_10.html
- Notice period: October 14 – October 17, 2024
- Voting period: October 18 – October 24, 2024
SIP.04: https://proposals.flare.network/SIP/SIP_4.html
- Notice period: October 14 – October 20, 2024
- Voting period: October 21 – October 27, 2024
All token holders, except for the Flare Foundation and Flare VC Fund, are eligible to vote at Flare Portal.
What should Flare Data Providers know about the new proposals?
The proposals establish an incentive structure where data providers can gain or lose passes based on their participation across Flare and Songbird protocols. This system encourages consistent, broader participation and penalizes inactivity, with defined minimum participation requirements for existing protocols.
New Incentive Structure
- Pass-based incentive structure applies to all existing Flare and Songbird protocols.
- Data providers must meet the set of minimum requirements for participating in all existing protocols
- Providers start with zero passes, earning a pass each time they meet all minimum requirements during a reward epoch (3 passes max).
- Providers lose a pass per protocol for which they fail to meet requirements.
- If a provider would lose a pass but doesn’t have any, they lose all rewards for the epoch.
- Future Flare and Songbird protocols will be given minimum participation requirements.
Minimum Participation Requirements
Each Flare protocol will implement the minimum participation requirements, defined across each reward epoch independently. For existing protocols, the requirements are defined as follows:
FIP.10 (Flare):
- FTSO anchor feeds: Providers must submit value estimates within a 0.5% band of the consensus median in at least 80% of voting rounds during a reward epoch.
- FTSO block-latency feeds: Providers must submit at least 80% of expected updates per reward epoch, unless they have a very low weight (below 0.2% of the total active weight).
- Staking: Providers need 80% uptime with a minimum of 1M FLR in active self-bond. To earn passes, they must hold at least 3M FLR in active self-bond and 15M in active stake. Providers with sufficient uptime but less stake do not gain or lose passes but still earn rewards.
SIP.04 (Songbird):
- FTSO anchor feeds and block-latency feeds: Same requirements as FIP.10.
- No staking requirements apply.
Note: These requirements apply specifically to the FTSOv2 protocol, as FTSOv1 will soon be deprecated.
How will rewards work?
The rewards structure proposed in both FIP.10 and SIP.04 are the same, outlined below.
- Failing to meet minimum requirements for a protocol during a reward epoch will result in losing a pass.
- Providers with no passes remaining that fail to meet minimum protocol requirements in a reward epoch will forfeit all rewards for that epoch.
- Providers will earn one pass per reward epoch by meeting all minimal criteria for protocols. This is so that only providers who aren’t consistently participating are penalized.
How will the proposals benefit the Flare community?
If approved, the proposals will benefit the Flare ecosystem by:
- Improving FTSO feed accuracy and security through incentivized consistent and accurate data submissions.
- Encouraging honest behavior by rewarding high-integrity data and penalizing dishonesty.
- Enhancing network stability and security by promoting active participation and penalizing inactivity.
Voting on FIP.10 and SIP.04 is a great opportunity for community members to take active roles in building Flare’s future and keeping the network decentralized and secure. Please review this article again or refer to the full FIP.10 and SIP.04 proposals before casting your votes during the voting periods.