Blockchain governance, particularly on-chain governance enables a form of direct-democracy. At it's core, it is designed to put the responsibility of any future changes to the network in the hands of its users.
Proposed changes are typically presented by either a foundation or the community itself. Proposals are then voted on, with each native token of the network entitling its owner to participate in the vote.
On-chain voting is done directly via the in-built protocols and governed by a set of pre-defined rules.
Different blockchains will have their own specific nuances around structure and consensus detail, however their general principles and goals remain closely aligned.
The idea of introducing this type of democratic approach, whereby the community decides the fate of the network is very exciting and something core to the Flare mission.
Let's look at some specifics around the Flare and Songbird governance structures.
There are two types of proposal within the Flare ecosystem:
Currently, only the Flare Foundation are able to initiate these proposals, however there are plans in the future to allow community members to also initiate proposals.
FIP proposals are voted for on Flare and STP proposals on Songbird. To participate in either, you must wrap your native tokens into $WFLR and $WSGB respectively.
For any new proposal, the Flare Foundation will publish it and give the community a notice period of one week before voting commences. The proposal is shared across all social media channels, to ensure it get as much exposure amongst community members as possible.
During this period a snapshot of all addresses is taken at a random block that is used to determine eligible votes.
After the week-long notice period, the proposal is formally submitted on-chain and voting is open. Votes can be cast on Flare Portal or directly on-chain, via the explorer.
Voting periods last one week, during which time the portal will display the live results. Once the voting period is over, the final results are displayed.
In the following days (for approved proposals), the Flare Foundation will share further updates on the planned implementation of the changes.
"Available votes depend on the amount of valid wrapped tokens you have, not the native tokens. Therefore, remember to wrap your tokens."
For an FIP to be accepted, a simple majority of the votes cast must be in favour of it. No minimum quorum is required. Therefore, an FIP will be rejected only if less than half of the cast votes are for it.
Voting on STPs is rejection-based. For an STP to be rejected, both of the following conditions must be true:
Therefore, an STP will be accepted if the quorum threshold is not reached or if less than half of the cast votes are against it.
A data provider's role is to gather information from real-world sources and submit it to the FTSO.
If the FTSO deems this information accurate, in relation to other submissions, then the provider is rewarded, along with any token holders who have delegated votes to them.
Data providers can obtain the required data from any source they wish. With regards to crypto price data, typical sources would be exchanges, price aggregators and other oracles.
It's important to have access to many different sources, as the data obtained may differ considerably.
Building out reliable and resilient infrastructure is critical to the success of any data provider.
Often providers choose to run their infrastructure using a cloud based solution, such as AWS, or Google Cloud.
A typical provider setup can include dedicated nodes, a price submitter tool, a database to organise and an application to process the data.
Once data has been gathered, it needs to be analysed and processed in some way before being submitted to the FTSO.
The data needs to validated and checks made to ensure any 'bad' data is excluded. This can all be done automatically, based on pre-defined conditions.
Each provider should create their own unique algorithms, that process the data in a way that ensures the final output represents what they themselves deem to be accurate.
Once data has been gathered, it needs to be analysed and processed in some way before being submitted to the FTSO.
The data needs to validated and checks made to ensure any 'bad' data is excluded. This can all be done automatically, of course, based on pre-defined conditions.
Each provider should create their own unique algorithms, that process the data in a way that ensures the final output represents what they themselves deem to be accurate.
Accurate submissions lead to more rewards, which in turn should lead to a provider gaining more vote power.
There is a cap on the maximum vote power any one provider can obtain, before the rewards their delegators receive are diluted.
Some providers also offer other incentives to gain additional vote power. This includes building useful tools for the community and NFT giveaways, amongst other things.
Data providers charge a fee for the service they offer. It's how they are able to fund the operation of their service.
The FTSO system gives a provider the freedom to set any fee they choose; however the higher the fee they charge, the less rewards their delegators will receive, which could drive them to delegate to a alternative provider.
