Documentation
Metrics
How key rates and APRs on Flare Metrics are defined and calculated.
Reward Rate
The Reward Rate (displayed as fspRewardRate) represents the FTSO Scaling Provider reward rate derived from WNAT (Wrapped Native Asset Token) claims.
It reflects how effectively a data provider is earning rewards relative to the delegation it receives. A higher reward rate indicates stronger provider performance over the measured period.
Values greater than or equal to 1 are considered anomalous and are displayed as -- in the UI. Valid reward rates are shown to four decimal places.
The Reward Rate CV (coefficient of variation) measures the consistency of a provider's reward rate across epochs. A lower CV indicates more stable, predictable performance.
Staking APR
The Staking APR estimates the annualised return for delegators staking to a specific validator node. Each node is calculated independently. APRs are never averaged across the nodes of an entity, so node-level configuration (fees, uptime) is fully visible.
Per-epoch reward rate
For each reward epoch and validator node, two reward rates are computed and summed:
normalRate = nodeRewardAfterFee / totalStakeAtEpochEnd × 100 mirrorRate = mirrorClaimPool / stakeWeightAtVotePowerBlock × 100 combinedRate = normalRate + mirrorRate
- normalRate: the node’s reward (after the validator fee is deducted) divided by its total stake at epoch end. A node with a 100% fee contributes 0 here.
- mirrorRate: the MIRROR claim pool for that node divided by the stake weight at the vote-power block (a separate snapshot). The denominator is intentionally different from normalRate’s, since MIRROR rewards are paid to a different stake basis.
If combinedRate is 0 or has no valid inputs for the epoch, the rate for that node/epoch is treated as missing and excluded from downstream smoothing.
Annualisation
To turn the per-epoch rate into the APR shown on the validator table:
- Take the most recent up-to-4 epochs with a valid combined rate for the node (newest first).
- Smooth with a simple moving average (SMA) over that window.
- Annualise by multiplying the SMA by
epochsPerYear, derived dynamically from the actual elapsed time between the last two reward epochs (≈ 104 for 3.5-day epochs; falls back to 104 when fewer than two epochs are available).
The single-epoch rate (latest), the smoothed rate (SMA), and the annualised value (SMA × epochsPerYear) are all persisted on each stake using only that stake’s own validator’s metrics.
Notes
- Closed or expired stakes (end time in the past) have all three APR fields cleared.
- Actual returns vary as reward amounts, fees, and delegation totals change each epoch.
- Nodes with a 100% delegation fee (or otherwise no rewards in any of the last 4 epochs) show “no data” rather than a literal 0% APR.
Data source: flare-foundation/reward-scripts
FSP APR
The FSP APR (FTSO Scaling Provider APR) represents the estimated annualised return for delegators based on FTSO reward distributions.
To filter out unreliable outliers, FSP APR values exceeding 15% are hidden from the UI and displayed as --.
Minimum Conditions & Passes
How passes work, what the four conditions require, and when rewards are burned.
Why It Matters
Minimum conditions are one of the most overlooked metrics costing Flare stakers and delegators rewards. The system arrived with a major FTSO update and has been in place for some time, yet many people staking to Flare validators or delegating to providers are still unaware of it.
Every reward epoch, each entity (data provider / validator) is graded on its performance and either earns or loses passes. This system decides whether the entity and their delegators keep their rewards. If you're delegating FLR, understanding these conditions and their impact on your rewards is crucial.
The Four Conditions
Each reward epoch, entities are judged on four protocols (conditions). Failing to meet any one of them costs a pass.
Anchor feeds FTSO Scaling
Submit prices close to the consensus median (within a 0.5% band) in at least 80% of voting rounds.
Block-latency feeds FTSO Fast Updates
Submit at least 80% of expected updates, based on the entity’s weight.
Entities with less than 0.2% of total weight are exempt.
Data connector FDC
Participate successfully in at least 60% of rewarded rounds.
Staking Validators
Maintain at least 80% validator uptime and a self-bond of at least 1M FLR.
How Passes Work
Passes act like “get out of jail free” cards. An entity can hold at most 3 passes at a time.
- •All entities start with 0 passes.
- +Meeting all four conditions in a reward epoch earns 1 pass (up to the maximum of 3).
- −Failing any one condition costs 1 pass.
- •Rewards are safe as long as the entity finishes the epoch with 0 or more passes.
In other words, an entity holding 3 passes may fail at most 3 of the conditions and still be eligible for rewards. Rewards are not at risk so long as the entity finishes a reward epoch with at least 0 passes.
When Rewards Are Burned
An entity's rewards are burned for a reward epoch when it fails more conditions than it has passes to absorb. The rewards for that epoch are burned, including their delegators' share.
How many failures that takes depends on the passes held. An entity with no passes burns on a single failed condition. With 2 passes, failing 3 conditions in an epoch is enough. Even at the maximum of 3 passes, failing all 4 conditions still burns.