What Is Flare (FLR)? A Simple Explanation

What Is Flare (FLR)?

Flare is a Layer 1 blockchain. That means Flare is an independent blockchain network where transactions are processed and apps can run.

Flare was mainly built to give smart contracts access to data from outside its own network. Think of things like price data or information about transactions on other blockchains.

The network is EVM-compatible. EVM stands for Ethereum Virtual Machine. Because Flare is compatible with it, developers can use many tools and smart contracts that are also used in the Ethereum ecosystem.

Flare's native token is called FLR. Native means FLR is the network's own token. You use FLR, among other things, to pay transaction fees and help secure the network through staking.

FLR is also used for governance. That lets token holders vote on certain proposals and changes within the network.

For some functions, FLR can be converted one-to-one into WFLR. This is called wrapping. You still own the same underlying value, but in a form that can be used within certain smart contracts.

WFLR can, for example, be used for delegation to data providers of the Flare Time Series Oracle, or FTSO. These are parties that provide data, such as price data, to the network. With delegation, you do not give away your tokens, but only assign your voting power to such a data provider.

All transaction fees paid in FLR are burned. That means these tokens are permanently removed from circulation.

So an important part of Flare is making external data available for smart contracts. That allows apps on Flare to use information that is not directly stored on the Flare blockchain itself.

Key Takeaways

• Flare is an EVM-compatible Layer 1 for smart contracts and external data.
• FLR is the native token for transaction fees, staking, governance, and delegation.
• FTSO provides, among other things, price data for apps on Flare.
• FDC helps smart contracts verify data from outside Flare.
• Validator staking and FTSO delegation are two different ways FLR can be used.

How Does Flare Work?

Flare has two important environments. Smart contracts and apps run on the C-Chain. The P-Chain is used for staking and managing validators.

Flare uses Proof of Stake to secure the network. Validators lock up FLR and help verify transactions and blocks.

Flare's consensus protocol is called Snowman++. This protocol comes from the Avalanche family and helps validators agree on the order and validity of transactions and blocks.

In addition to this network layer, Flare has the Flare Systems Protocol. This system is used for Flare's built-in data protocols, including the Flare Time Series Oracle, or FTSO, and the Flare Data Connector, or FDC.

Data providers supply data for this. Their influence within the system depends in part on WFLR delegated to them and on FLR staked through validators on the P-Chain. FTSO delegation and staking are two different processes.

Flare (FLR) Overview

What Role Does FLR Play Within Flare?

FLR is the native token of the Flare network and has several functions within the ecosystem.

First, FLR is used to pay transaction fees on Flare. These fees are burned, which permanently removes the FLR used from circulation.

FLR also plays a role in securing the network. Validators lock up FLR on the P-Chain, and other users can delegate FLR to a validator. In return, they can receive staking rewards.

FLR is also used for governance and for delegation to data providers within the Flare network. For these uses, FLR can be wrapped one-to-one into WFLR.

That gives FLR a role in transactions, network security, data, and Flare's governance.

How Does Flare's Data Infrastructure Work?

Flare has data protocols built directly into the network. Two important parts are the Flare Time Series Oracle, usually called FTSO, and the Flare Data Connector, or FDC.

FTSO provides data that changes regularly, such as price data. Apps and smart contracts on Flare can use this data without having to collect data directly from external sources themselves.

FTSOv2 uses, among other things, block-latency feeds and anchor feeds.

Block-latency feeds are fast price feeds that update around every new block. Flare produces a block about every 1.8 seconds. That means new price data can become available very regularly. For each update, a selection of data providers is chosen to supply data.

Anchor feeds work more slowly and are meant to reach one shared value at fixed times. Data providers first submit their data without making it public right away. Later, they reveal which value they submitted. This is called commit-reveal and helps prevent providers from changing their submission after seeing others'.

After that, all valid submissions are combined into one value. Flare uses a weighted median for this. That means not every data provider has the same amount of influence. Providers with more voting power count more when determining the final value.

Anchor feeds are updated every 90 seconds. They also serve as a checkpoint for the faster block-latency feeds and help keep them accurate over the long term.

Data providers therefore play an important role within FTSO. Users can delegate the voting power of their WFLR to one or two of these providers. The tokens stay in their own wallet. This is called FTSO delegation.

The Flare Data Connector has a different job. FDC makes it possible to verify data from outside Flare before a smart contract uses it. That can include transactions and payments on other blockchains, for example.

After verification, the data is processed into a Merkle tree. Only the Merkle root is stored on Flare. With a Merkle proof, a smart contract can then check whether certain data was part of the verified dataset.

What Role Do FTSO and FAssets Play Within Flare?

FTSO makes sure apps on Flare have access to data such as price feeds. That data can then be used by other parts of the Flare ecosystem.

One example is FAssets. FAssets are overcollateralized representations of assets from other blockchains. Overcollateralized means that more value is held as collateral than the value of the issued FAssets.

FAssets are meant to make assets from networks with limited smart contract functionality usable within apps on Flare.

Right now, FXRP, the FAsset version of XRP, is live. The FAssets system is designed to support other assets without extensive smart contract functionality in the future as well.

An FAsset is not the same as the original asset on its own blockchain. FXRP, for example, is a token on Flare that represents XRP. Users can use FXRP within the Flare ecosystem and redeem it through the FAssets protocol for XRP on the XRP Ledger.

Several parts of Flare are needed for FAssets to work. FTSO provides price data, and FDC helps verify transactions on the underlying blockchain. In addition, collateral is used to back the issued FAssets.

The collateral consists of different types of collateral. Agents use approved tokens for this, while FLR can be used as extra collateral in collateral pools.

FAssets therefore depend on multiple parts of the system and are not the same as directly holding the original asset.

How Do Staking and Delegation Work on Flare?

Validator staking and FTSO delegation are two different ways to use FLR within the Flare network.

With validator staking, you lock up FLR for a certain period to support a validator on the P-Chain. Validators help secure the network and process transactions and blocks.

To delegate FLR directly to a validator, you need at least 50,000 FLR. These tokens are locked for at least 14 days. To run a validator yourself, a self-bond of at least 1 million FLR is required, with a minimum term of 60 days.

Staking rewards are determined per reward epoch and depend in part on the performance of the chosen validator. On Flare Mainnet, a reward epoch lasts about 3.5 days.

FTSO delegation works differently. For this, you wrap FLR on the C-Chain one-to-one into WFLR. Then you can delegate the voting power of your WFLR to one or two FTSO data providers.

You do not transfer your WFLR to the data provider. The tokens stay in your own wallet, while the delegated voting power counts for the chosen provider.

FTSO data providers can keep part of the rewards as a fee. How much a delegator receives therefore depends in part on the provider's performance and the fee set.

How Did Flare Start?

Flare was founded in 2019 by Hugo Philion, Sean Rowan, and Naïri Usher. The project initially focused on making smart contract functionality and external data available for applications across different blockchain networks.

Flare mainnet genesis took place on July 14, 2022. The network first started in an observation phase then. The public Token Distribution Event, where FLR was distributed to users, followed on January 9, 2023.

At genesis, the first block of the network, 100 billion FLR were created. FLR has 18 decimals.

After a change to the token distribution through FIP.01, part of the FLR was spread out over 36 months through FlareDrops. This distribution ended on January 30, 2026.

The end of FlareDrops did not mean all rewards stopped. Protocol rewards for things like staking and FTSO delegation still exist after that.

What Are the Benefits of Flare?

• Smart contracts and data in one network: Flare combines an EVM-compatible environment with built-in protocols for price feeds and verifying external data.

• Fast and periodic price feeds: FTSOv2 offers block-latency feeds that update around every new block and anchor feeds that periodically determine a shared value. That lets apps use different kinds of price data.

• Verifiable data from other blockchains: FDC can verify data from supported networks, including Bitcoin, Dogecoin, XRP Ledger and Ethereum.

• Using assets from other networks: FAssets are designed to make overcollateralized representations of assets from other blockchains usable within apps on Flare.

• Delegation without transferring tokens: With FTSO delegation, you can delegate the voting power of your WFLR to data providers while the tokens stay in your own wallet.

What Are the Downsides of Flare?

• Extra steps for validator staking: For direct staking to a validator, FLR must be moved from the C-Chain to the P-Chain. Afterward, the FLR must be moved back to the C-Chain if you want to use the tokens there.

• High barrier for validator delegation: Direct delegation to a validator requires at least 50,000 FLR and comes with a minimum lock-up of 14 days. That makes this form of staking less accessible for smaller holders.

• FAssets depend on multiple parts: The system uses agents, collateral, price feeds, and data from the underlying blockchain, among other things. Problems with any of these parts can affect how FAssets work.

• Dependence on data providers: FTSO and FDC use multiple data providers to supply and verify data. Apps that use this data therefore remain dependent on the availability and proper functioning of these systems.

• Delegation rewards are not fixed: The return from FTSO delegation depends in part on the performance and fee of the chosen data provider.

Conclusion

Flare is an EVM-compatible Layer 1 blockchain that combines smart contracts with built-in infrastructure for external data. FLR is the native token of the network and is used for transaction fees, staking, governance, and delegation.

Two important parts are FTSO and FDC. FTSO provides, among other things, price data, while FDC lets smart contracts verify data from outside Flare. FAssets build on this by making representations of assets from other networks usable within Flare.

There are also risks and extra steps involved. Validator staking requires a lock-up and moving FLR to the P-Chain. FTSO delegation and FAssets also depend on different parts and participants within the Flare network.