Documentation

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.

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

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 --.

The Reliability Score is a 0-100 grade of an entity over the last 26 reward epochs (about 90 days). It is shown on the entity profile. The score is null until that window is complete, unless the entity has no FTSO history and only a terminal validator.

Calculation starts at 100, then subtracts:

• 1 point per strike in minimum-conditions data.
• Ineligible or not registered epochs: the nth consecutive miss costs (1+2+…+n)×5 (5, then 15, then 30, and so on). An eligible epoch resets the streak. A missing minimum-conditions row in the window counts as not registered.
• Terminal validators: -100 × (bricked / total) on unique nodes that have not expired. A node is bricked when observed connected time is below 50%, or it failed the last finalized uptime vote. Lifetime P-chain uptime is not used for this, because it can stay high after a node dies. The penalty clears when that stake expires.

The just-ended epoch is ignored until its minimum-conditions file is published, so a new epoch does not give every provider a miss.

Entities that still have delegated WFLR but have left FTSO registration and no longer run a validator are marked Inactive on the profile. That badge is shown immediately rather than waiting for the score to fall through consecutive misses.

The result is clamped to 0-100. Colouring is 90+ healthy, 70-89 watch, and below 70 poor.

Until 26 epochs of history exist, the profile shows how many epochs have been observed so far instead of a number.

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.

Each reward epoch, entities are judged on four protocols (conditions). Failing to meet any one of them costs a pass.

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.

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.

FIRE has three revenue streams.

• FDC (FLR): 90% of confirmed Flare Data Connector request fees, claimed to the FIRE pool as RewardClaimed.
• Minting tags (FLR): reservation fees paid when a minting tag is reserved. The fee and recipient come from MintingTagManager config at that block.
• Direct mint (FXRP): minting fees on Core Vault direct mints. Agent, executor, and pool fees are excluded.

Accrued is a live estimate from submitted FDC attestation requests: floor(submittedFees * 9000 / 10000) per voting round. Duplicate submissions of the same request bytes are summed, then the 90% FIRE share is taken on that round total. This assumes the requests confirm. Unconfirmed or malformed request fees are burned, so accrued can sit slightly above claimed.

Claimed is what actually landed: on-chain RewardClaimed paid DIRECT to the FIRE pool. Use claimed as the payout on a settled epoch. The current epoch stays at claimed 0 until that reward vote is claimed. Daily charts are accrued only, because claims have no day split. Tag and direct-mint streams have no RewardClaimed path.

The staking rewards tool looks up a reward-owner address against Flare Metrics stake history, then joins each overlapping epoch with official reward-scripts amounts and that node’s eligibility.

Search with a C-chain 0x address or a P-chain flare1 address. The tool matches the P-chain reward owner on the stake, not whoever later claims or receives the payout.

• Staking is the amount reward-scripts calculated for that owner on that node in that epoch. This is the normalRate pot in staking APR.
• Mirror is this row’s stake times that node’s MIRROR rate for the epoch, the same mirrorRate used in staking APR. On-chain, MIRROR is a node-level FSP pool, not a per-delegator reward-scripts line.
• Total is staking plus MIRROR for this row.
• APR is this address’s actual staking plus MIRROR, divided by this stake, then annualised over the epoch length. It is not the validator table APR, which uses a node-level rate.
• Node / uptime decide whether that node’s stakers were paid the Staking column. Below 80% uptime forfeits that pot for that node. MIRROR is a separate FSP claim and can still pay.
• Provider conditions are the entity’s FTSO / FDC / FSP score. They do not decide the Staking column. They can burn FSP rewards, including MIRROR.

If you run a node and also delegate extra FLR to that same node, the tool shows two rows for the same epoch: one Node owner row and one Extra stake row.

Official rewards pay both as one node-owner amount. The extra row stays at 0 in Staking and is flagged See node-owner row. That is not a missed reward. Mirror can still show on the extra row.

If the node restakes during an epoch, the old period and the new period are separate rows. Official rewards sit on the later self-bond. The old row is flagged Replaced mid-epoch. APR stays the same as the later payout so leftover stake does not look like a worse rate.

None calculated means official reward-scripts listed no staking amount for this owner on this node. It is not a node forfeit. Green node and uptime only mean the validator was eligible to pay stakers who were in that epoch’s snapshot.

The tool lists any stake that overlapped the epoch dates. Rewards are calculated from who was active at the epoch snapshot, usually the start. A delegation that starts mid-epoch can show a row with none calculated, then pay from the next epoch.

Use Export to download a CSV of the same lookup. Pick columns and either an epoch range or a date range (epochs whose start falls in that UTC day range). Leave the range empty for every overlapping epoch. The C-chain reward owner is included by default. You can also add the P-chain owner, and the stake address when it differs from the reward owner.

The same file is available from GET /staking-rewards/{address}/csv. Query params: columns (comma-separated, or all; cChain, pChain, staker), minEpoch, maxEpoch, minDate, maxDate (YYYY-MM-DD), and nodeId.