Select category

The blockchain for data.

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 Fundamentals

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.

Data Acquisition

Flare obtains data by leveraging it's two core protocols:

  1. State Connector
  2. Flare Time Series Oracle (FTSO)

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.

More Information

The beating heart of the Flare network.

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.

What is an epoch?

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.

Price 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.

Reward epoch

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."
Inflation Pool

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.

Reward Criteria

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."
Additional resources

Where isolation ends and integration begins.

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.

Why the State Connector?

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:

  • Decentralised Consensus: Unlike other bridging solutions that might rely on centralised parties, the State Connector takes a decentralised approach to achieve consensus on external data, whether it's from another blockchain or the open internet.
  • Broad Compatibility: The State Connector doesn't force other blockchains to adapt to its standards. Instead, it's designed to be flexible, integrating with a multitude of blockchain protocols without requiring them to alter their core code.
  • Trustworthiness: By utilising a robust attestation mechanism, the State Connector ensures that the data it integrates is accurate, reliable, and has been validated by independent entities.
  • Enhanced Data Flow: The State Connector facilitates the flow of data across chains, enabling smart contracts on Flare to access real-time data from other chains or the wider internet. This capability opens the door to a myriad of applications that can leverage these data sources.
Attestation providers

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.

How it works
1. Request

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.

2. Retrieve

Upon receiving the request, attestation providers spring into action to retrieve the required data, from third party sources.

3. Attest

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.

4. Consensus

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."
Use cases

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:

  • Cross-chain Financial Operations: DApps can facilitate seamless financial transactions across multiple blockchains, enabling users to easily swap, lend, or borrow assets without relying on centralised exchanges or intermediaries.
  • Real-time Data Access: DApps involved in sectors like finance, agriculture, or logistics can access real-time data from the broader internet, enabling functionalities like price feeds, weather updates, or shipment tracking within the decentralised framework.
  • Interoperable Gaming: Imagine a decentralised gaming platform where assets and achievements from one game can be used or showcased in another. The State Connector can make such cross-game interoperability a reality.
  • Decentralized Identity Verification: DApps offering services that require identity verification can use the State Connector to access and validate user data from different blockchains, all while ensuring data privacy and security.
  • Supply Chain Management: DApps in the supply chain sector can trace products across multiple stages and blockchains, ensuring authenticity and transparency from production to delivery.

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.

More information

Canary down the mine.

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.

Brief History

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:

  • Test Flare technology in a live environment prior to deployment on Flare.
  • Provide dApp builders with a live testing environment. Whilst it is good practice for teams to launch their products on Songbird first, it's worth pointing out that there are no rules making this mandatory.
  • Serve as the lower house in a bicameral governance structure, thus giving the community the ability to submit and vote for proposals on Songbird so that, when approved, they may be considered by the Flare Foundation for inclusion on the Flare network.
Real Usage

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.

More Information

Decentralising the decision making.

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.

Governance Types

There are two types of proposal within the Flare ecosystem:

  • Songbird Test Proposals (STP)
  • Flare Improvement Proposals (FIP)

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.

Proposal Initiation

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:

  • Threshold condition: The minimum quorum is at least 75% of all $SGB tokens circulation (excluding the Flare Foundation's tokens) at the vote count block.
  • Majority condition: More than 50% of the votes cast, must be against the proposal.

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.

More Information

Securing the Flare network, one block at a time.

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."
Validation Protocol

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.

Infrastructure Providers

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:

  • Securing the network through proof-of-stake consensus.
  • Providing continuous data to the FTSO system.
  • Answering the State Connector's queries for attestations.

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.

Staking Phases

In July 2023 the process of moving towards a staking model began. It was broken down into three phases.

Phase 1

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.

Phase 2

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.

Phase 3

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.

Staking Limits

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:

  • Validator uptime
  • Total staked amount
  • FTSO data accuracy
More Information