Flare (FLR)

What Flare is

Flare is a layer-1 blockchain whose defining feature is that two oracles are built into the protocol itself rather than bolted on afterwards. FLR is the native currency of its main network. Flare's developer documentation describes the platform as "four EVM-compatible, permissionless networks designed for different stages of application and protocol development," with FLR on the main network and C2FLR or CFLR on the test networks (source: Flare developer documentation, network overview, read September 2026).

The two enshrined systems are the Flare Time Series Oracle, which publishes price and other time-series feeds, and the Flare Data Connector, which attests to facts about other blockchains and about ordinary web endpoints. Flare's documentation states that its validators act as data providers for both, so the same set that produces blocks also produces the data. A smart contract on Flare reads a price feed the way it reads any other on-chain value, rather than paying a separate oracle network for it.

For where to buy Flare from your country or state, see the availability tables on this site and the venues listed at Exchanges.

How it works

Flare runs Snowman++, the consensus protocol from Avalanche, which its documentation describes as delivering "high-throughput, totally ordered consensus with fast finality." Blocks arrive roughly every 1.8 seconds and reach single-slot finality, meaning a block is final once it has been accepted through consensus rather than after some number of later confirmations (source: Flare developer documentation, network overview). Sybil resistance is proof of stake: block proposers are selected at random, weighted by total stake.

Delegation happens inside the protocol rather than through a separate contract. Token holders delegate stake to validators, and a validator must meet a minimum self-bond set by governance before it can take part in consensus and earn rewards as a block proposer. Every transaction fee on the network is burned rather than paid to a validator, which ties the burn rate directly to how busy the chain is.

Flare is fully Ethereum-compatible at the execution layer. Its documentation says the network supports all EVM opcodes up to and including the Cancun hard fork, so Solidity and Vyper contracts deploy without modification.

The Flare Time Series Oracle is described in the documentation as "an enshrined oracle that provides decentralized data feeds to the Flare network." Around 100 independent data providers support each FTSOv2 feed, and users choose between them by delegating stake, which gives a misbehaving provider something to lose. Which provider is selected is decided by a stake-weighted verifiable random function, so a provider's chance of selection matches its share of stake.

FTSOv2 publishes two kinds of feed. Block-latency feeds update with every new block, roughly every 1.8 seconds, using incremental delta updates at a precision of one part in 2^13, about 0.0122% per step, with each update moving up, down, or not at all. The documentation states this mechanism captures "over 99% of all price movements under normal market conditions," and that block-latency feeds are free to read on-chain. Anchor feeds update once per 90-second voting epoch through a full commit-reveal process across all data providers, with an interquartile range band used to check the result. Providers are rewarded when their block-latency feed sits inside the primary reward band of the anchor feed. FTSOv2 supports up to 1,000 feeds across equities, commodities and cryptocurrencies, with two weeks of history available.

The Flare Data Connector is the second enshrined oracle, described as "designed to validate external data for Flare's EVM state." It supports seven attestation types: AddressValidity, EVMTransaction, Web2Json, Payment, ConfirmedBlockHeightExists, BalanceDecreasingTransaction and ReferencedPaymentNonexistence. During a voting round, providers submit BitVectors in a choose phase running from 90 to 135 seconds into the round, and once signatures representing more than 50% of weight are collected the Merkle root is submitted to the Relay contract. Only that root is stored on-chain; the full attestation data is served off-chain through a Data Availability Layer, and contracts verify individual claims against the root with a merkle tree proof. The connector reads EVM chains including Ethereum, Flare and Songbird, and non-EVM chains including Bitcoin, Dogecoin and XRP. For most chain-data attestation types the underlying data may be at most 14 days old.

Supply and tokenomics

Flare's developer documentation covers network parameters in detail but does not publish an FLR supply cap or issuance schedule on the pages read for this entry. Those figures are therefore left out here rather than estimated. What the documentation does state precisely is how fees, delegation and rewards behave.

Delegating FLR to a data provider and staking FLR with a validator are separate acts with separate reward paths, and the documentation treats them as such. Neither is a fixed rate: what a delegator receives depends on the provider's accuracy relative to the anchor feed and on the reward parameters governance sets.

History

Flare's design starts from a specific complaint about how blockchains get data. Most chains treat oracles as an application-layer problem, so a lending protocol pays an external network for prices and inherits that network's assumptions. Flare instead makes the oracle part of the chain, funded by the same validator set and secured by the same stake.

The two systems address different halves of that problem. FTSO answers questions about continuously changing values, which is why it publishes on a block cadence and uses a statistical band rather than a single agreed number. FDC answers questions about discrete events elsewhere, which is why it uses a commit-and-vote round producing a Merkle root that contracts can check a claim against.

Songbird, referred to in the documentation as one of the four networks and supported as a data source by the Data Connector, serves as the canary network where changes run before reaching the main network.

Risks and what to watch

Oracle concentration is the risk specific to this design. With roughly 100 providers per feed and stake-weighted selection, a feed is only as honest as the distribution of stake behind it. Watch how delegation is spread rather than how many providers are registered.

The 14-day maximum data age on most Data Connector attestation types is a boundary worth knowing before building on it. So is the Data Availability Layer: the chain stores only the Merkle root, so anyone verifying a claim depends on the off-chain layer serving the underlying data.

Validator concentration matters here as it does on any proof of stake chain, and it matters twice on Flare, because the same operators secure blocks and supply data.

Frequently asked questions

What makes Flare different from other EVM chains?

Its oracles are part of the protocol. The Flare Time Series Oracle and the Flare Data Connector are run by the same validators that produce blocks, so contracts read price feeds and cross-chain attestations as native chain state rather than buying them from an external network.

How fast does Flare produce blocks?

Roughly one every 1.8 seconds, with single-slot finality, meaning a block is final once accepted through consensus rather than after a number of confirmations.

What happens to Flare transaction fees?

They are burned. Flare's documentation states that all fees are burned rather than redistributed to validators, so the burn rate scales with network activity.

How often do Flare price feeds update?

Block-latency feeds update with every block, about every 1.8 seconds, using small incremental steps at roughly 0.0122% precision. Anchor feeds update once per 90-second voting epoch through a commit-reveal process across all data providers.

Where can you buy Flare?

Availability depends on your country or US state. See where to buy Flare for the exchanges serving your jurisdiction, and Exchanges to compare fees, kyc requirements and payment methods.