Portal.Flare.Network

The Flare Portal is an app giving users access to all Flare and Songbird services without needing to interact with smart contracts. The Portal is initially launching on Songbird with the governance feature activated ahead of the first Songbird Test Proposal vote. This will also provide a ‘test run’ before the Flare Improvement Proposal 01 voting goes live in 2023.

The portal’s web interface already allows users to:

• Review governance proposals.
• Wrap and delegate tokens in preparation for voting.
• Vote.

Users can learn more about the Songbird Test Proposal 01 (STP.01) on Flare’s proposal repository and will be able to vote on the portal.flare.network site, once the vote starts in week commencing 26 December 2022. In order to participate, users must wrap SGB tokens in advance of this date. A detailed walkthrough is available in the technical documentation.

Every SGB token holder will be able to participate. Voting will be weighted proportionally according to the size of the voter’s SGB holdings. SGB holders will also have the option to transfer their votes to another account if they don’t wish to participate directly. The portal is also being implemented for Coston2, Flare’s public test network.

Songbird Governance Process

To avoid inundating the community with voting requests, Songbird Test Proposals (STPs) are approved by default unless enough SGB holders vote against them.

Initially, the Flare Foundation will be the only permissioned entity to suggest test proposals. In future community participants will also be able to submit their proposals.

1. A proposal is published on Flare’s proposal repository and announced publicly.
2. During a notice period of typically 1 week, users need to wrap SGB tokens into WSGB, since they will receive one vote per WSGB token. If tokens are already wrapped, even if delegated to the FTSO system, then there is no action needed.
3. The block selection period is required for security reasons and will typically last for a few days. Please keep your tokens wrapped during this period. Learn more in the documentation.
4. Finally, the proposal is submitted to the portal and voting can commence. The voting period lasts for a week.
5. When voting concludes, results can be automatically implemented. In the case of STPs, proposals are automatically accepted unless two conditions are met: More than 75% of the total possible votes were cast & more than 50% of the cast votes were against the proposal.
6. The portal also supports other types of proposals with different acceptance criteria, to be used in the future.

Songbird Test Proposal 01

The first Songbird proposal aims to reduce the vote cap per FTSO data provider from 10% to 2.5%, allowing more FTSOs to compete for rewards and making it harder for attackers to collude.

The Flare Time Series Oracle (FTSO) is a highly decentralized system for providing dapps on Flare with continuously updated data, such as cryptocurrency prices. Decentralization is accomplished by enlisting a large number of independent data providers, who supply the system with updated price data for every supported chain every three minutes. The system then uses this data from all data providers to calculate a weighted mean price for each token pair, taking the burden of risk off the user and affording data providers an opportunity for rewards.

Data providers earn rewards in freshly minted SGB or FLR tokens based on the proximity of the data they provided to the weighted median, incentivising accuracy. They share these rewards with token holders who have delegated their FLR or SGB to them. The more delegations they have, the higher their vote power and the larger their influence in the calculation of the median.

Currently, the Songbird vote power has a cap set to 10%, which means that an individual data provider can have up to 10% of the total vote power, including all delegated tokens. In theory, six or more of the top data providers could collude to guarantee rewards or control the data output of the FTSO system. Lowering the vote power cap to 2.5% will incentivize further decentralization and help protect the network.

If STP.01 is passed, SGB holders delegating their tokens to a data provider with vote power greater than 2.5% of the total will need to move their delegation to a different data provider in order to maximize their returns. More data providers will receive a share of the rewards and so be incentivized to provide the most accurate price data possible.

More information is available on the STP.01 proposal page. The timeline for this first governance process is as follows:

• Dec 17: STP.01 live on Github
• Dec 21: Portal.Flare.Network live
• Dec 23: Deadline for wrapping of SGB tokens to participate in the vote
• Dec 24: Block selection period commences
• w/c Dec 26: Voting commences, exact date to be announced
• w/c Jan 2: Voting concludes one week later