Flare (FLR) sustainability report

Flare is present on the following networks: Flare.

Flare reaches agreement using Snowman++, the totally ordered member of the Avalanche family of protocols. Instead of a fixed committee exchanging a vote with every other member, each participating node repeatedly polls a small random sample of its peers and shifts toward whichever answer the samples keep returning. Confidence accumulates over successive rounds until the outcome is settled, and because every node talks to only a handful of others per round, the messaging burden on any one machine stays broadly flat as the participant count grows. Blocks arrive roughly every 1.8 seconds, and a block accepted through this polling process is treated as settled at the moment of acceptance rather than waiting on a separate confirmation stage. Safety is probabilistic in the formal sense, with the protocol parameters chosen so that the chance of two conflicting outcomes both being accepted is driven to a negligible level.

Resistance to identity forgery comes from stake. An operator joins the validating set by registering a node on the network's platform chain and bonding an amount of the native asset above a floor set through governance. Other holders can direct additional weight to that node without handing over custody, and the sum of the operator's own bond and the weight pointed at it determines how often the protocol picks the node as leader for a new block. Leader selection is randomized and proportional to that weight, so no operator holds a standing entitlement to produce blocks.

Two things set the design apart. The validating set is not confined to block production: the same operators supply the readings that the network's built-in oracle and external-data protocols publish, so consensus duty and data duty rest with one population. And a governance decision adopted in April 2026 started to separate block assembly from block verification, moving construction toward a designated builder in stages while validators remain the layer that checks correctness and keep their weight in the protocol's voting. Changes of this kind are trialed on the associated canary network before they reach Flare itself.

Flare is present on the following networks: Flare.

Reward on Flare flows through two separate channels, and a holder of the native asset may use either or both. The first is consensus staking: the asset is locked to a registered node on the platform chain for a chosen term, with a minimum lock of about two weeks, and earns a share of the issuance set aside for securing block production. The second is oracle delegation, which happens on the contract chain, carries no lock-up and no minimum, and works by wrapping the native asset one-for-one and pointing the resulting voting weight at a data provider. Delegated weight never leaves the holder's own address; what moves is the influence the chosen provider carries inside the data protocols.

Those data protocols are built into the chain rather than layered on top of it. A shared coordination layer runs a time-series oracle that publishes price feeds, updating by small increments with each block and anchoring to a full commit-and-reveal round every ninety seconds, alongside an external-data connector that lets contracts consume verified facts about events on other chains and which superseded the network's earlier attestation design during 2025. Protocol issuance is divided between the two, and the connector additionally collects a fee from whoever requests a piece of data, shared among the providers that answered. Entitlements accrue over reward periods of roughly three and a half days and must be claimed; anything left unclaimed for ninety days lapses and the corresponding amount is destroyed.

Discipline is applied by withholding reward rather than confiscating bonded principal. A node whose availability falls below the required threshold forfeits the period, a provider submitting poor or missing data can be suspended from earning, and because a validator's eligibility is tied to the performance of the data provider it is paired with, a failure on the data side removes the reward for that node and for everyone who delegated to it. A 2026 governance change weighted platform-chain stake more heavily than contract-chain delegation and set a floor on the commission an operator must retain.

Users pay ordinary gas, either in the legacy single-price form or the two-part form with a protocol-set base component and an optional tip. Both components are destroyed rather than paid out, so activity removes native units from circulation instead of transferring them to block producers.

Flare is present on the following networks: Flare.

The figure reported for this network is assembled from the machines that run it rather than read off a meter. The starting point is an estimate of how many nodes are actually operating: the validating set is observable through the protocol's own on-chain registry, and the wider population of machines that follow the chain without producing blocks is estimated from network crawling and publicly listed infrastructure. Because influence here is bought with stake rather than with computation, there is no incentive to add processing power in pursuit of reward, so the number of participating machines rather than any measure of work performed is what drives the result.

A representative machine profile is then inferred from what the client software asks for in order to stay in step with the chain, covering processor class, memory and storage. Power draw for equipment matching that profile is taken from controlled bench measurement rather than from manufacturer nameplate ratings, and the draw of a machine that is switched on but lightly loaded is counted too, since a node consumes electricity continuously whether or not it happens to be proposing a block. Multiplying the per-machine figure across the estimated population over the reporting period produces the annualized total.

Several limits belong on the record. The node count reflects what can be seen from the public network, and machines behind private infrastructure are not directly visible. The hardware mix is inferred from stated software requirements, so operators running heavier equipment than the client demands are not captured individually. The network's data protocols also place work on the same machines that validate, and that additional load is absorbed into the per-machine profile rather than modelled as a separate system. Where evidence is thin, the assumption chosen is the one that yields the larger number, so the result is more likely to sit above the true value than below it. Figures are restated as observation improves and as the client software and the size of the participating population change.

Flare is present on the following networks: Flare.

The renewable share attributed to this network follows from where its machines sit, not from any purchasing claim made by the people running them. Node addresses visible on the public network are resolved to a country or region using routing data and publicly listed hosting information, which produces a distribution of the estimated node population across jurisdictions. Where part of the population cannot be placed, because it sits behind private networking or announces no usable location, the gap is filled with the geographic spread observed on chains that are structurally alike, meaning chains where the requirements for taking part and the reasons an operator would choose one location over another are broadly the same.

That distribution is weighted by the energy each part of it is estimated to consume and matched against published statistics for the generating mix of the corresponding grids. The result is the proportion of the network's electricity generated from renewable sources, understood as the average character of the grids supplying its infrastructure across the reporting period. It is not an assertion that any individual operator has contracted for renewable supply, and it takes no account of on-site generation or of certificates bought separately from the electricity itself.

Energy intensity rests on a different basis from the annual total. It expresses the extra energy associated with one more transaction being processed, which on a stake-weighted network is small, because the machines draw power continuously regardless of how full the blocks are. The figure therefore describes the marginal cost of usage rather than an average obtained by dividing the yearly total by transaction count, and it moves with how heavily the network is used even when underlying consumption barely shifts.

Grid generation data is drawn from Share of electricity generated by renewables, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy. Country coverage and reporting lags in that data set carry through into the result, and the location estimate itself remains the largest single source of uncertainty in the calculation.

Flare is present on the following networks: Flare.

Emissions are derived from the energy estimate rather than measured directly, by applying the carbon characteristics of the electricity the network's machines consume. The jurisdictional distribution used for the energy mix serves as the input here as well: each share of estimated consumption is assigned to a grid, each grid carries a published figure for the greenhouse gases released per unit of electricity generated there, and summing across the distribution gives the annual total. Results are expressed in carbon dioxide equivalent so that gases other than carbon dioxide enter on a warming-equivalent basis.

The two scopes are reported separately because they describe different things. Scope 1 covers releases from sources the operators own or control directly, such as combustion on the premises, standby generation or refrigerant loss. For a network of this kind it is ordinarily nil or close to it, since operators run computing equipment in facilities they typically do not own and burn no fuel of their own in the course of validating. Scope 2 covers the indirect releases embodied in the electricity purchased to run that equipment, and essentially the whole footprint sits there. Emissions further up the chain, from manufacturing the hardware or constructing the facilities, fall outside the boundary used here.

Greenhouse gas intensity is expressed per transaction on the same marginal basis as energy intensity: the additional emissions associated with processing one more transaction, rather than the yearly total divided by throughput. Because the machines run continuously, that marginal quantity is small and is sensitive to how busy the network happens to be.

Carbon intensity values come from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy and made available under the Creative Commons Attribution 4.0 license. Those values are annual national averages, so short-term and within-country variation in the generating mix is not reflected, and any error in placing the nodes passes straight through into the emissions figure.