Redistribution of unearned Rewards
(Rewards that are otherwise burned)
Overview
Within the core protocols of the Flare Network, certain actions by data providers can result in penalties whereby rewards are burned rather than distributed. Consequently, a significant amount of value is effectively removed from the ecosystem – a trend that has increased following the introduction of the new reward structure, which includes an inflationary allocation to the Flare Data Connector (FDC) protocol. Following FIP.11 and SIP.05, the Flare Foundation proposes reallocating a portion of these rewards to reinforce the core protocols that drive the network’s functionality, rather than permanently burning them.
Rationale for Reallocation
Rather than eliminating these FLR tokens from circulation, we propose to redirect them towards initiatives that enhance protocol efficiency, stability, and overall network performance. Importantly, this reallocation ensures that the funds continue to flow to data providers and their delegators, reinforcing their role in securing the network.
At this time, the Flare Foundation identified the following primary areas that would benefit from this approach:
- Block-latency Feeds (Fast Updates Protocol)
- The Fast Updates protocol relies on timely updates from data providers to ensure accurate and resilient price feeds.
- Price feeds update in discrete steps, at an average rate of 1.5 updates per block on Flare (and 1 update per block on Songbird).
- Both the price update step size and the average number of price updates can be increased by providing volatility incentives.
- By reallocating the rewards that would otherwise be burned, the network can fund these volatility-based incentives, motivating data providers to deliver more frequent updates during periods of high market volatility.
- This reallocation redistributes the otherwise burned funds back to the data providers and their delegators, while improving the accuracy and responsiveness of the Flare Time Series Oracle (FTSO) without introducing additional inflation.
- Flare Data Connector – Attestation Requests
- The FDC protocol relies on a continuous influx of attestation requests to function optimally and to ensure that data providers are eligible for inflationary rewards.
- To ensure that all FDC rewards are distributed to the community, an FDC request must be submitted in every voting epoch. If no request is made during a given round, the rewards allocated for that round will be burned. Consequently, in the early phases of the protocol, it is essential to initiate a request each round to activate the reward mechanism.
- By repurposing these burned rewards to subsidize attestation request fees, the network can ensure a steady flow of requests without relying solely on Foundation intervention.
- Again, these fees ultimately return to data providers and their delegators, reinforcing their role in securing and maintaining Flare’s data integrity.
Process
To ensure transparency and accountability, the reallocation of funds will follow a structured process:
- Allocation Mechanism:
- Funds that would be burned are instead sent to a dedicated wallet managed by the Flare Foundation. This wallet acts as a central repository for the reallocated rewards.
- Based on the current protocol parameters, the Foundation estimates that approximately 60,000 FLR (or SGB, respectively) are required each month for issuing attestation requests for every voting epoch. Additionally, approximately 30–50,000 FLR (SGB, respectively) are currently used monthly for FTSO volatility incentives. In total, ~110,000 FLR (SGB, respectively) are estimated for these initiatives.)
- Note that any excess rewards held in this dedicated wallet will be permanently burned.
- Additionally, the Flare Foundation is continuously working to improve the core protocols, which may lead to adjustments in these estimates over time.
- Future Use Cases:
The Foundation may identify future use cases for the reallocated rewards that provide tangible benefits to the network and its participants, which will be presented to the Management Group of data providers and will be implemented accordingly.
Voting Process
~ The 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 Flare and Songbird for MG members to cast on-chain votes either for or against the redistribution of unearned rewards as outlined in this proposal
~ If voting reaches quorum for both, then the Foundation will proceed with the reallocation of these unearned rewards on both Flare and Songbird