Infrastructure Providers

Select role

Providing infrastructure to the Flare ecosystem.

The role of Infrastructure Provider can be separated into three core parts.

  1. FTSO Data Provider
  2. Network Validator
  3. State Connector Attestation Provider

Currently, only the first two roles are fully operational, however as Flare and in particularly the State Connector matures and evolves, the Attestation Provider role will become more relevant.

Let's explore each of these areas in more detail, to help understand more about the life of a Infrastructure Provider.

Bringing decentralised time-series data on-chain.

Data providers are tasked with the problem of getting accurate and reliable time-series information from the outside world into the Flare ecosystem.

The Flare Time Series Oracle (FTSO) protocol ensures that this is done in as decentralised a way as possible, incentivising up to 100 data providers to compete for rewards from an inflation pool, by providing accurate information.

Each token on both Flare and Songbird comes with a vote that can be delegated to a data provider, in-turn earning a share of the rewards from the inflation pool, based on the providers' data accuracy.

Browse through the sections below to get a understanding of some of the key things to consider when either delegating your votes to a data provider, or even operating your own.

Select category

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 sourcing

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.​ Others may choose to run their own servers locally. There are, of course pro's and con's to each approach and each provider will have their own ideas on the optimal setup.

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, 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. These can include providing educational content, building useful tools for the community and NFT giveaways, amongst other things. 

Service fees

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.

Data Sourcing
Smart Contracts
Service Fees

Securing the Flare network, one block at a time.

A network validator is responsible for validating transactions and generating new blocks within a blockchain ecosystem. They typically do this in return for fees or rewards, which incentivises the prioritisation of network security.

On Flare, part of the overall inflation pool is allocated to reward users who stake their tokens against a high performing network validator.

There are a number of things to consider when participating in Flare's staking process. Read on to learn more.


Network validators are tasked with verifying transactions and maintaining consensus of the state of the network.

They play a critical role in the ongoing security to the network, helping to protect against various attacks, by ensuring that only valid transactions are added to the blockchain.

Their role is to maintain the trust and consensus among network participants while being rewarded for their efforts.


Each validator entity is required to run and maintain their own Flare node. This node must be in constant communication with other nodes to ensure their copies of the ledger remain consistent as new data is added.

Given sufficient technical knowledge, anyone is able setup and deploy a validator node.


Flare operates a proof-of-stake (PoS) consensus model and has two types of staking.

Self-bonding refers to the stake that an infrastructure provider is required to lock up, in order to operate as a network validator.

Additionally, any $FLR holder can stake their tokens against a network validator.

Both of these approaches are subject to their own pre-defined limits and lock-up periods.

Anyone who stakes their tokens becomes eligible for a portion of the rewards, made available from the inflation pool.


There are a number of factors to consider when it comes to staking.

Infrastructure Providers are required to self-bond a minimum of 1m $FLR and anyone staking to a validator is subject to a minimum staking value of 50k $FLR.

There are also some caps in place around the amount of stake per validator. Any single validator entity can only obtain a maximum of 15x their own self-bond amount. This is additionally capped at a total of 200m $FLR.

Any single infrastructure provider is allowed to setup four validator entities, providing they can meet the defined criteria for each validator node they operate, again subject to the limits and lock-up periods set-out.


Whilst your tokens are not at risk when staked against a validator, there is a period where your tokens are locked in a smart contract and cannot be accessed.

The minimum duration in which tokens must remain staked for is two weeks. Infrastructure Providers' self-bonded tokens have a different lock-up period, which is a set to a minimum of two months.


30% of the annual network inflation is allocated to the staking rewards pool.

Validation rewards are earned from this pool, and split amongst validators and participants, based on validator uptime and total staked amount.

Service fees

Infrastructure Providers charge a fee for the validator services they offer. It's how they are able to fund the operation of their service.

As with the FTSO system​, Infrastructure Providers are able to set any validator fee they choose; however, the higher the fee they charge, the less rewards participants staking against their validator will receive, which could drive them to staking to an alternative Infrastructure Provider.

Fees are locked in place for the duration of a validators self-bonding phase.

Validating non-changeable data through consensus.

Attestation providers are independent entities who fetch non-changing and verifiable information from the real-world and deliver it to the Flare network.

Leveraging Flare's State Connector protocol, once the majority of providers come to a consensus over the accuracy of the data, it is published on-chain.

At some point in the near future, this role will fall under the wider banner of Infrastructure Provider.