The Flare Network is transitioning to a proof of stake consensus mechanism as explained in the Validator Nodes documentation page. This transition requires:
This proposal executes all the above changes.
Following requests from the Flare and Songbird communities, this proposal updates the price pairs currently provided by the FTSO system.
All prices are against the USD currency. The current 12 price pairs are ADA, ALGO, BCH, BTC, DGB, DOGE, ETH, FIL, FLR, LTC, XLM, and XRP.
The proposed changes are as follows:
After those pairs are added or removed, the list of supported price pairs is: ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, FLR, LTC, MATIC, SOL, USDC, USDT, XDC, XLM, and XRP.
Please note that, due to current network limitations, some pairs need to be removed to free the network bandwidth for the new ones. The Flare Foundation is working to overcome these limitations. Similar voting was conducted and accepted on Songbird for STP.04.
Here is a quick explanation of the inflation behaviours that STP.05 proposes to improve:
As it can be seen, some of the proposed changes for Songbird are already present on Flare, but some others, like the ones proposed in sections 2.1 and 2.6, are not. After testing on Songbird these changes will be added to Flare through the corresponding FIP.
The Flare Time Series Oracle (FTSO) is a smart contract running on the Flare network that provides continuous estimations for different types of data. It does so in a decentralized manner (no single party is in control of the process) and securely (it takes a lot of effort to disrupt the process).
To ensure decentralization and security, a set of independent data providers retrieves data from external sources, like centralized and decentralized exchanges, and supplies the data to the FTSO system. This information is then weighted according to each provider’s voting power, and the median is calculated to produce the final estimate.
The current FTSO system rewards data submissions that are close to the median price, resulting in extremely tight reward bands where only about 25% of the submissions are typically rewarded. The low number of providers that have access to the rewards put the rest at risk of not being able to cover their infrastructure costs, which in turn poses a centralization risk to the network.
This proposal adds a second, wider reward band aiming at increasing the number of data providers that get rewarded, while still giving a higher allocation to submissions closer to the vote-power-weighted median value.
A version of this proposal for Songbird was implemented in March 2023. Since then, the Flare Analytics Team conducted a study to evaluate its impact on the system. As explained in the report, results show that the secondary reward band significantly bolsters decentralization by increasing the percentage of rewarded data providers without negatively impacting the quality of the data.
This proposal successfully illustrates the central purpose of the Songbird network, where the experiment to test the effects of another reward band was run before the band was added on the Flare network.
Following requests from the Flare and Songbird communities, this proposal updates the price pairs currently provided by the FTSO system.
All prices are against the USD currency. The current 12 price pairs are ADA, ALGO, BCH, BTC, DGB, DOGE, ETH, FIL, LTC, SGB, XLM, and XRP.
The proposed changes are as follows:
After those pairs are added or removed, the list of supported price pairs is: ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, LTC, MATIC, SGB, SOL, USDC, USDT, XDC, XLM, and XRP.
Please note that, due to current network limitations, some pairs need to be removed to free the network bandwidth for the new ones. The Flare Foundation is working to overcome these limitations.
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.
This proposal will create a self-policing FTSO committee, called the FTSO Management Group, to report possible infractions by FTSO data providers and collectively determine whether punitive actions should be taken.
Infractions are purposely undefined. The group will decide on a case-by-case basis whether an infraction has occurred, but this proposal aims to prevent behaviour that impairs the FTSO ecosystem as a whole, including, but not limited to:
Any member of the management group can propose a provider to be chilled. A chilled provider will not be able to operate for some time, causing it economic loss. A second chilling will cause the provider to be banned forever.
Chill proposals will then be voted by all group members and, when approved, will be implemented by governance.
The management group will be formed by upstanding FTSO data providers, meaning that they need to be actively submitting data and earning rewards, and not have been punished recently, either by being chilled themselves or by failing to perform their duties in the management group.
This proposal will create a self-policing FTSO committee, called the FTSO Management Group, to report possible infractions by FTSO data providers and collectively determine whether punitive actions should be taken.
Infractions are purposely undefined. The group will decide on a case-by-case basis whether an infraction has occurred, but this proposal aims to prevent behavior that impairs the FTSO ecosystem as a whole, including, but not limited to:
Any member of the management group can propose a provider to be chilled. A chilled provider will not be able to operate for some time, causing it economic loss. A second chilling will cause the provider to be banned forever.
Chill proposals will then be voted by all group members and, when approved, will be implemented by governance.
The management group will be formed by upstanding FTSO data providers, meaning that they need to be actively submitting data and earning rewards, and not have been punished recently, either by being chilled themselves or by failing to perform their duties in the management group.
The Flare Time Series Oracle (FTSO) is a smart contract running on the Songbird network that provides continuous estimations for different types of data. It does so in a decentralized manner (no single party is in control of the process) and securely (it takes a lot of effort to disrupt the process).
To ensure decentralization and security, a set of independent data providers retrieves data from external sources, like centralized and decentralized exchanges, and supplies the data to the FTSO system. This information is then weighted according to each provider’s voting power, and the median is calculated to produce the final estimate.
The current FTSO system rewards data submissions that are close to the median price, resulting in extremely tight reward bands where only about 25% of the submissions are typically rewarded. The low number of providers that have access to the rewards put the rest at risk of not being able to cover their infrastructure costs, which in turn poses a centralization risk to the network.
This proposal adds a second, wider reward band aiming at increasing the number of data providers that get rewarded, while still giving a higher allocation to submissions closer to the vote-power-weighted median value.
When Flare Networks began, it offered a single utility to a single community. Since then, Flare has expanded to deliver robust protocols that enable developers to build applications that can use data from other blockchains and the internet.
Recently during this time of expansion, Flare successfully delivered 15% of the original FLR airdrop to eligible recipients to reward them for their support and incentivize them to continue participating with the network.
Now, Flare wants to continue developing the ecosystem with the help from more communities, while still rewarding in equal measure the original airdrop recipients.
Additionally, Flare wants to grant airdrop recipients more independence from exchanges and other token custodians, since this has proven a delicate topic in the past.
To achieve these objectives, this proposal changes the method of supplying the remaining 85% of the public token distribution and the inflation rate.
The Flare Time Series Oracle (FTSO) system is used to obtain time series data (signals) from data providers in a decentralized manner. A vote power cap is used to limit the impact of an individual data provider in the final decision for the median price thus helping to enforce decentralization. Currently, the vote power cap is set to 10% of the total vote power, which in practice means that six or more of the top data providers can decide to collude with the goal of guaranteeing rewards for all of them or to control the data produced by the FTSO system.
As the number of reliable data providers has grown, we propose to lower the vote power cap to 2.5%. This will provide further decentralization and a better safeguard against the mentioned threat. Although it will impact the rewards earned by the seven data providers that currently have the most vote power, it will not affect their delegators, since there are a lot of other data providers with similar reward rates to choose from. Moreover, the reward rates of most of the other data providers will increase, further contributing to the diversification of delegations among data providers.
The Songbird network is the canary network for the Flare network. That is, upgrades to Flare that require testing will be tested on Songbird first.
Where upgrades to Flare are governed by the Flare Improvement Proposal (FIP) process, upgrades to Songbird are governed by the Songbird Improvement Proposal (SIP) process and the Songbird Test Proposal (STP) process.
The Flare Network is transitioning to a proof of stake consensus mechanism as explained in the Validator Nodes documentation page. This transition requires:
This proposal executes all the above changes.
Following requests from the Flare and Songbird communities, this proposal updates the price pairs currently provided by the FTSO system.
All prices are against the USD currency. The current 12 price pairs are ADA, ALGO, BCH, BTC, DGB, DOGE, ETH, FIL, FLR, LTC, XLM, and XRP.
The proposed changes are as follows:
After those pairs are added or removed, the list of supported price pairs is: ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, FLR, LTC, MATIC, SOL, USDC, USDT, XDC, XLM, and XRP.
Please note that, due to current network limitations, some pairs need to be removed to free the network bandwidth for the new ones. The Flare Foundation is working to overcome these limitations. Similar voting was conducted and accepted on Songbird for STP.04.
Here is a quick explanation of the inflation behaviours that STP.05 proposes to improve:
As it can be seen, some of the proposed changes for Songbird are already present on Flare, but some others, like the ones proposed in sections 2.1 and 2.6, are not. After testing on Songbird these changes will be added to Flare through the corresponding FIP.
The Flare Time Series Oracle (FTSO) is a smart contract running on the Flare network that provides continuous estimations for different types of data. It does so in a decentralized manner (no single party is in control of the process) and securely (it takes a lot of effort to disrupt the process).
To ensure decentralization and security, a set of independent data providers retrieves data from external sources, like centralized and decentralized exchanges, and supplies the data to the FTSO system. This information is then weighted according to each provider’s voting power, and the median is calculated to produce the final estimate.
The current FTSO system rewards data submissions that are close to the median price, resulting in extremely tight reward bands where only about 25% of the submissions are typically rewarded. The low number of providers that have access to the rewards put the rest at risk of not being able to cover their infrastructure costs, which in turn poses a centralization risk to the network.
This proposal adds a second, wider reward band aiming at increasing the number of data providers that get rewarded, while still giving a higher allocation to submissions closer to the vote-power-weighted median value.
A version of this proposal for Songbird was implemented in March 2023. Since then, the Flare Analytics Team conducted a study to evaluate its impact on the system. As explained in the report, results show that the secondary reward band significantly bolsters decentralization by increasing the percentage of rewarded data providers without negatively impacting the quality of the data.
This proposal successfully illustrates the central purpose of the Songbird network, where the experiment to test the effects of another reward band was run before the band was added on the Flare network.
Following requests from the Flare and Songbird communities, this proposal updates the price pairs currently provided by the FTSO system.
All prices are against the USD currency. The current 12 price pairs are ADA, ALGO, BCH, BTC, DGB, DOGE, ETH, FIL, LTC, SGB, XLM, and XRP.
The proposed changes are as follows:
After those pairs are added or removed, the list of supported price pairs is: ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, LTC, MATIC, SGB, SOL, USDC, USDT, XDC, XLM, and XRP.
Please note that, due to current network limitations, some pairs need to be removed to free the network bandwidth for the new ones. The Flare Foundation is working to overcome these limitations.
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.
This proposal will create a self-policing FTSO committee, called the FTSO Management Group, to report possible infractions by FTSO data providers and collectively determine whether punitive actions should be taken.
Infractions are purposely undefined. The group will decide on a case-by-case basis whether an infraction has occurred, but this proposal aims to prevent behaviour that impairs the FTSO ecosystem as a whole, including, but not limited to:
Any member of the management group can propose a provider to be chilled. A chilled provider will not be able to operate for some time, causing it economic loss. A second chilling will cause the provider to be banned forever.
Chill proposals will then be voted by all group members and, when approved, will be implemented by governance.
The management group will be formed by upstanding FTSO data providers, meaning that they need to be actively submitting data and earning rewards, and not have been punished recently, either by being chilled themselves or by failing to perform their duties in the management group.
This proposal will create a self-policing FTSO committee, called the FTSO Management Group, to report possible infractions by FTSO data providers and collectively determine whether punitive actions should be taken.
Infractions are purposely undefined. The group will decide on a case-by-case basis whether an infraction has occurred, but this proposal aims to prevent behavior that impairs the FTSO ecosystem as a whole, including, but not limited to:
Any member of the management group can propose a provider to be chilled. A chilled provider will not be able to operate for some time, causing it economic loss. A second chilling will cause the provider to be banned forever.
Chill proposals will then be voted by all group members and, when approved, will be implemented by governance.
The management group will be formed by upstanding FTSO data providers, meaning that they need to be actively submitting data and earning rewards, and not have been punished recently, either by being chilled themselves or by failing to perform their duties in the management group.
The Flare Time Series Oracle (FTSO) is a smart contract running on the Songbird network that provides continuous estimations for different types of data. It does so in a decentralized manner (no single party is in control of the process) and securely (it takes a lot of effort to disrupt the process).
To ensure decentralization and security, a set of independent data providers retrieves data from external sources, like centralized and decentralized exchanges, and supplies the data to the FTSO system. This information is then weighted according to each provider’s voting power, and the median is calculated to produce the final estimate.
The current FTSO system rewards data submissions that are close to the median price, resulting in extremely tight reward bands where only about 25% of the submissions are typically rewarded. The low number of providers that have access to the rewards put the rest at risk of not being able to cover their infrastructure costs, which in turn poses a centralization risk to the network.
This proposal adds a second, wider reward band aiming at increasing the number of data providers that get rewarded, while still giving a higher allocation to submissions closer to the vote-power-weighted median value.
When Flare Networks began, it offered a single utility to a single community. Since then, Flare has expanded to deliver robust protocols that enable developers to build applications that can use data from other blockchains and the internet.
Recently during this time of expansion, Flare successfully delivered 15% of the original FLR airdrop to eligible recipients to reward them for their support and incentivize them to continue participating with the network.
Now, Flare wants to continue developing the ecosystem with the help from more communities, while still rewarding in equal measure the original airdrop recipients.
Additionally, Flare wants to grant airdrop recipients more independence from exchanges and other token custodians, since this has proven a delicate topic in the past.
To achieve these objectives, this proposal changes the method of supplying the remaining 85% of the public token distribution and the inflation rate.
The Flare Time Series Oracle (FTSO) system is used to obtain time series data (signals) from data providers in a decentralized manner. A vote power cap is used to limit the impact of an individual data provider in the final decision for the median price thus helping to enforce decentralization. Currently, the vote power cap is set to 10% of the total vote power, which in practice means that six or more of the top data providers can decide to collude with the goal of guaranteeing rewards for all of them or to control the data produced by the FTSO system.
As the number of reliable data providers has grown, we propose to lower the vote power cap to 2.5%. This will provide further decentralization and a better safeguard against the mentioned threat. Although it will impact the rewards earned by the seven data providers that currently have the most vote power, it will not affect their delegators, since there are a lot of other data providers with similar reward rates to choose from. Moreover, the reward rates of most of the other data providers will increase, further contributing to the diversification of delegations among data providers.
The Songbird network is the canary network for the Flare network. That is, upgrades to Flare that require testing will be tested on Songbird first.
Where upgrades to Flare are governed by the Flare Improvement Proposal (FIP) process, upgrades to Songbird are governed by the Songbird Improvement Proposal (SIP) process and the Songbird Test Proposal (STP) process.