Validators

Proposals

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.

Background

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."
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
Select category
Role

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.

Infrastructure

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.

Algorithms

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.

Algorithms

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.

Delegations

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. 

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.