The Flare network presents a distinctive approach to blockchain technology. While many blockchains exist in isolated silos, often competing with each other, Flare seeks to bridge the blockchain gap by offering unique interoperability opportunities, positioning itself as a blockchain for data.
At its foundational level, Flare's mission is to facilitate decentralised access to a wide array of data sources. This includes not only data from other blockchains but also from the broader internet, where the bounds of potential utility would only be restricted by the creativity of its particpants.
Such a capability can provide developers with a much broader palette of data to work with, enhancing the functionality and versatility of applications built within the Flare ecosystem.
Flare is a EVM based layer-1 blockchain that operates a proof-of-stake (PoS) consensus mechanism. This works by independent validator nodes coming to a consensus around the validity of new blocks, before they are added to the ledger.
Flare has a governance structure in place that gives all network participants the opportunity to collaborate in any decision making, particularly around policy changes.
Flare obtains data by leveraging it's two core protocols:
While both of these protocols have the same overarching goal, to bring external data into the Flare ecosystem, they differ somewhat in the type of data they look to acquire as well as their methods.
Where the State Connector focuses on information that is non-changing and verifiable, the FTSO covers time-series data that, by its very definition is interpretable and ever changing.
The approaches that each of these take to obtain the relevant information separates them out further, whilst also complementing each other.
The State Connector works on the basis of seeking out consensus between third party entities on the accuracy of information. Conversely, the FTSO system incentivises participants to compete against each to provide accurate information, in order to earn rewards.
In addition to the Flare main-net, the ecosystem has in place it's own canary network; Songbird, as well as two test networks; Coston and Coston 2. Songbird operates as it's own layer-1 production blockchain, carrying real-world value and utility, whereas both Coston networks are true test networks, used for developers to try out new things with low impact and cost.
The Flare network officially launched in July-22, when the first (Genesis) block was created. You can monitor the total amount of blocks and transactions that have been created since this time in our analytics pages. You can also view information directly on the Flare block explorer. The FTSO got up and running in September-22 and ran in observation mode until the initial token airdrop occurred and user can begin participating in the network. This happened in January-23 when, as part of the Token Distribution Event (TDE) users started to receive their tokens.
Although still a relatively new ecosystem, Flare continues to grow and thrive in todays crowded blockchain space. Scroll through the tabs on this page to learn more about some of the things touched on here. And, as always, if you need more information or have any specific questions, then don't hesitate to get in touch.
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.
