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:

  1. Take the most recent up-to-4 epochs with a valid combined rate for the node (newest first).
  2. Smooth with a simple moving average (SMA) over that window.
  3. 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.

1

Anchor feeds FTSO Scaling

Submit prices close to the consensus median (within a 0.5% band) in at least 80% of voting rounds.

2

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.

3

Data connector FDC

Participate successfully in at least 60% of rewarded rounds.

4

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.

Caveat: earning passes
To earn a pass, an entity must also hold at least 3M FLR self-bond and 15M FLR total active stake. This applies only to earning passes. Meeting the minimal staking condition itself still only requires 1M FLR self-bond.

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.

Burns apply to all rewards
A provider that doesn't meet minimum conditions and has no passes left will have all of their rewards burned, not just for the individual protocols they failed. This includes delegation to the data provider and validator delegations.
Tip: look at the history
It is typically okay for a provider to lose a pass from time to time. What matters more is the provider's history of minimum conditions. Each entity page on Flare Metrics has a Minimum Conditions tab showing this history, and the provider/validator tables show current Passes Held.