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.
Before we get into specifics around the FTSO, let's start by first taking a look at blockchain oracles in general, how they operate and what problem they are trying to solve.
Blockchains are isolated networks that are unable to natively access information from external systems. As the majority of use cases built around blockchain technology require access to real-world information, a solution is needed. This is where oracles come in.
Blockchain oracles are entities that can supply external information to the blockchain. They can come in many different shapes and sizes, with some being centralised than others, however they are all inherently designed to solve this same problem; the Oracle Problem.
Flare's native oracle is called the Flare Time Series Oracle, or FTSO for short. It relies on a set of independent data providers, who gather data from external sources and submit to the blockchain what they deem to be an accurate representation of the requested data. Both Flare and Songbird networks currently supports up to 100 data providers, who compete for rewards from an inflation pool, by providing accurate information. Token holders can delegate vote power to data providers to receive a share of the available rewards.
Read on to learn more about how the FTSO operates.
If you're new to Flare, you may have heard the term epoch used and be a little unsure what it means. An epoch simply refers to a period of time. In the context of the FTSO, an epoch is used to define two distinct time periods; price epoch and reward epoch.
Every three minutes, data providers gather their interpretation of all required time-series data and submit it to the FTSO. Each of these three-minute windows is called a price epoch. They run continuously, 24/7/365, with each one given it's own unique and consecutive number.
Price epochs are grouped together in what are referred to as a reward epoch. Each reward epoch lasts 3.5 days on Flare and 7 days on Songbird, consisting of 1,680 and 3,360 price epochs, respectively.
As with price epochs, reward epochs run continuously without pause; a new one starting immediately after the previous one has ended.
”When the FTSO was initially designed, it supported only cryptocurrency price pairs. Now, it supports all types of data, however smart contract names and methods still refer to prices, as does some of the terminology used.”
A data provider can submit data to the FTSO at any point during a price epoch, although to ensure their data is as current and accurate as possible, most will typically submit sometime within the final 30 seconds of the epoch.
When submissions have been made, they are initially hidden from view, to avoid providers copying and submitting data sourced by another provider.
All submissions are then published on-chain within the following 90 seconds. The overarching process is called commit-and-reveal.
Each data provider carries a weight, based on its allocated vote power. For each piece of time-series submission, the FTSO system takes the data providers weight, along with the submitted price from all providers and determines a single price, using a weighted median calculation.
This finalised price is subsequently published and made available for use by on-chain applications (called dApps) for a period of five price epochs (15 minutes).
"All data produced by the FTSO is publicly available on the Flare and Songbird networks."
70% of the total network inflation is allocated to the FTSO rewards pool, which is shared between data providers and their delegators, whose submissions meet the reward criteria.
Rewards can be distributed in the respective chains native token; $FLR / $SGB or it's wrapped equivalent.
Any submission that falls within a 50% range of the calculated median is considered to be accurate and eligible for rewards; however, each price epoch, only one price series is selected (at random) to be actually rewarded.
Therefore, rewards will only be earned if the data provider your votes are delegated to send accurate prices for the specific piece of data that is selected, regardless of how accurate the others were.
There are a number of factors that will determine the amount of rewards you earn.
This includes the performance of the data provider you delegated to, their system availability, what fee they charge and whether or not they are above the vote cap.
"A vote-power cap limits the influence of individual data providers to 2.5% of the total vote power on both Flare and Songbird. Any vote power above this cap is ignored."
Blockchains have undoubtedly revolutionised our approach to data, trust, and decentralisation. But in their quest for security and autonomy, they've also become isolated fortresses.
These isolated entities face difficulties in achieving seamless communication with other blockchains or accessing external data from the open internet.
This limitation restricts the potential of decentralised applications that could thrive on interconnected data sources.
Let's take a look at how Flare's State Connector looks to solve this problem.
Whilst recognising the challenges that emerge from these isolated blockchains, the State Connector aims to offer a decentralised solution to help simplify the flow of data. Here's how:
The State Connector relies on specific entities, known as attestation providers, to vouch for the accuracy and integrity of this data. These providers act as intermediaries that verify and attest to the correctness of external data before it is integrated into Flare.
The attestation process initiates with a request. This request could come from a user, a smart contract, or any part of the Flare network that requires data from an external source.
Upon receiving the request, attestation providers spring into action to retrieve the required data, from third party sources.
Once the data has been retrieved, the attestation providers each provide their data to the State Connector smart contract, in what is called a commit-and-reveal method. This is done to ensure that each provider sources their own data and is not influenced by the data from other providers.
With multiple attestation providers in the ecosystem, it's essential to have a unanimous agreement on the data's validity. If more than half of the attestation providers submit the same information to the smart contract, then it is made public. If a consensus is not reached then the attestation has failed and would need to be re-submitted, if needed.
"The answers are stored in the State Connector smart contract for a week, where anybody can read them, including the original requester."
By bridging the gap between isolated blockchains and the broader internet, the State Connector unlocks a plethora of innovative use cases for decentralised applications (DApps). Some examples could include:
By harnessing the power of the State Connector, DApps can transcend the limitations of single blockchains and offer users a richer, more integrated experience, all while maintaining the core principles of decentralisation and trust.
The term canary network is typically used to refer to a production blockchain that is specifically designed to allow new features to be built and tested under real-world conditions, before making them available on it's parent network.
Canary networks, although considered a testing playground for developers, are actually live environments, with their tokens having have real-world value.
So, where does the term come from? It originated from coal mining and specifically the term canary in the coal mine, where real canaries would be used as an early warning sign, to detect toxic gases.
In the context of software testing and deployment, it refers to the practice of rolling out a new software release or feature to a small subset of users before deploying it to a broader user base. This allows the development team to monitor and identify any potential issues with the new release in a controlled environment. If problems arise with this canary group, it can serves as an early warning sign of issues that may need to be resolved before releasing to a wider group of users.
Flare's canary network is called Songbird.
Songbird has played a crucial role in allowing developers to build and test the core protocols in a live production environment, ahead of launching on Flare.
Read on to discover more about Songbird and it's role within the Flare ecosystem.
Songbird launched almost one year before Flare, in September-2021, with its FTSO system up and running a month later. The second core component, the State Connector went live in March-2022.
Songbird's native token is $SGB and it's wrapped version $WSGB. You can find out more details about network inflation, token supply and distribution by clicking each of these links.
Songbird has three core goals:
Since it's inception we have seen many dApps built on Songbird, some of which have since been released on Flare. There are DeFi product suites, NFT marketplaces and decentralised exchanges to name a few, with the list growing daily. There are some valuable resources available to help you find out more about the types of applications being built on Songbird (and Flare, of course). Flare Builders has a comprehensive list and is certainly worth checking out.
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.
Every blockchain needs to have a system of consensus around the general state of the network. Proof-of-Stake (PoS) is a consensus mechanism that is designed to incentivise honest participants who prioritise network security.
A validator is an entity in a PoS blockchain responsible for validating transactions and generating new blocks, typically in return for fees or rewards.
Each validator entity is required to run and maintain their own node, which must be in constant communication with other nodes, ensuring their copies of the ledger remain consistent as new data is added.
To become a validator, the entity must lock up a specific amount of the network’s native token; a process called staking. This approach helps limit the chance of bad actors attacking the network.
Flare uses a consensus protocol from Avalanche, called Snowman++
Let's get into some detail around the Flare validator and staking model.
Following the initial launch of Flare, in July 2022, network validators consisted of a closed group of 20 professional infrastructure providers. This was considered an initial state, with the ultimate goal being to decentralise this approach over time, and when safe to do so, move towards a staking model.
During this initial period, data providers were focused solely on providing time-series data to the FTSO system.
"In line with Flare’s mission of providing data as a public good through building the network for data at scale, Flare will transition to a staking model whereby the validators of the network are also responsible for providing data to the network."
The Flare network is composed of two independent blockchains: The platform chain (P-chain) and the contract chain (C-chain). The P-chain manages platform-handling operations, like validator staking, whereas the C-chain implements the EVM and runs all the smart contracts.
During each validation round, a validator is randomly selected to act as the leader and propose new blocks to be added to the ledger, which are then validated by the rest of nodes.
With its vision to be the blockchain for data, Flare adds the FTSO data provider and attestation provider roles to validators, creating a single infrastructure entity.
When fully operational, these decentralised infrastructure entities are responsible for:
In this way, the stake required to operate these entities secures all three functions.
Infrastructure entities are rewarded for each one of these roles, a process that involves staking on the P-chain and rewards that are calculated on smart contracts running on the C-chain.
In July 2023 the process of moving towards a staking model began. It was broken down into three phases.
On July 2023 a network fork enabled Avalanche's proof-of-stake mechanism. From this moment, validation was open to everybody. At the same time, all the stake from the original validators expired.
At this stage the Flare Foundation loaned funds to a batch of 33 data providers to enable them to deploy validation nodes and act as validators.
Once FTSO data providers have gathered enough stake to ensure the network's continued working, all stake loaned by the Flare Foundation to the validators in the initial state will be withdrawn. Professional validators are expected to cease operating at this point, unless they provide their own stake.
After secure communication between the P- and C-chains is available, staking rewards will be managed entirely on-chain. The goal is that funds staked on the P-chain will have the same rights as wrapped $FLR on the C-chain, opening the possibility to earn FTSO rewards, FlareDrops and participate in governance.
There is a minimum amount of stake each entity has to lock-up, in order to become a validator. This self-bond is set at 1m $FLR.
In addition to this self-bond, any $FLR token holder can stake to a validator, however there is a maximum amount any one validator can have staked against it. This amount is calculated as a factor of 15x the value of the self-bond.
When staking tokens to a validator, there is a minimum lock-up period of two weeks.
"Validator uptime must be above 80% to receive rewards."
As highlighted in the Tokenomics page, 30% of the inflation rewards pool is dedicated to validation rewards, with validators receiving rewards based on: