|Songbird Improvement Proposal
|50% (required) 98.4 % (obtained)
|Accepted on 28-Mar-2023
|31-Mar-2023 Deployment started on Coston.
4-Apr-2023 Deployment started on Songbird.
19-Apr-2023 Deployment complete.
The purpose of the Songbird network is to act as a canary network for the Flare network. To achieve this goal, the different smart contracts are first deployed on Songbird, and, once proven to operate well, they are deployed on Flare.
However, because the FIP.01 proposal required voting infrastructure to be available immediately after the token distribution event, some smart contracts were deployed on Flare before doing so on Songbird first.
This proposal will deploy on Songbird the most recent version of some smart contracts like the
FtsoRewardManager. This update will align the Songbird network more closely with Flare. The effects of this deployment are described in the Technical Description section. No changes will be made to the Flare network.
The list of contracts to be deployed on Songbird can be found in the next section. This deployment will have the following impact on the Songbird network:
Smart contract alignment: These smart contracts will have the same code on both networks, greatly simplifying their maintenance and freeing Flare Foundation development resources to work on other parts of the code. Application writers will be able to support both Songbird and Flare networks with less effort.
Add autoclaiming facilities: The ability to nominate executors that can claim rewards on the user’s behalf is already deployed and working on Flare and is documented here. This proposal will bring this functionality to Songbird too.
Add Personal Delegation Accounts: PDAs can temporarily receive and store rewards to track which funds are from rewards, for example, for personal or tax purposes. This functionality is already available on Flare and is documented here. This proposal will bring this functionality to Songbird too.
Unclaimed FTSO reward burning: FTSO delegation rewards that have not been claimed in 90 days are currently redistributed in the following reward epoch on Songbird, whereas on Flare these unclaimed rewards are burned. This proposal will align both networks and burn unclaimed FTSO rewards on Songbird too, which has the added benefit of reducing inflation.
This change will not affect the length of the Songbird FTSO reward epoch, which continues to be 7 days.
This change will not affect unclaimed rewards from previous epochs, which will still be claimable through the current
FtsoRewardManagercontract until they expire.
Please note that the above effects are already present on the Flare network.
The smart contracts deployed on Songbird will use the same source code as the ones on Flare, namely, the
The exact contracts deployed and their source code links are:
Applications should start using the new address once the new contract is deployed, since the current
FtsoRewardManagerwill stop accruing rewards. Use the
FlareContractRegistrycontract to retrieve addresses as explained in the documentation.
Applications should also continue checking the current
FtsoRewardManagerfor unclaimed rewards from previous epochs.
Deployment of the new contracts on the Coston network is expected to start shortly after the voting finishes and be completed quickly.
Within a month, if no problems are detected the new contracts will be deployed on Songbird.
To pass, the proposal requires a simple majority of votes in favor of it.
One week after the proposal is published in the Flare Portal.
|Clarify effects on the