Validator Score Methodology

Algorithm version: v4.5 · Last updated: 2026-07-04

FlareWatch assigns each P-Chain validator a 0–100 composite score across 9 dimensions. The math is deterministic, the inputs are public chain data [Flare Explorer] [FSE] [Flaremetrics], and the same algorithm applies to every validator on the network — including FlareWatch's own validator node, which is scored by this exact function with no special treatment. This page documents every dimension and threshold so operators and stakers can see exactly how the score is computed and why each value was chosen. Every claim here links back to its primary on-chain or upstream source — see Sources & references at the bottom.

Scope: this page documents the validator score — what you see in staking mode on the validators page (delegating FLR to a P-Chain validator for VRM + MIRROR rewards). The FTSO provider score shown in delegation mode (delegating WFLR to FTSO data providers) uses a separate 13-dimension algorithm focused on data-provider performance — accuracy, V2 protocol participation, etc. They're distinct on-chain roles with distinct rewards, scored separately. See FTSO Provider Score Methodology for the delegation side.
No SGB equivalent: this scoring applies to Flare P-Chain validators only. Songbird's P-Chain validator set is restricted to Flare Foundation-approved entities, so retail SGB P-Chain delegation is rare and the staking tab is FLR-only. There's no FLR / SGB toggle in staking mode. For SGB FTSO delegation see FTSO Provider Score Methodology, which covers both chains.
How we compute APR — what you actually earn

The Net APR on the staking table is the all-in rate a delegator receives — one number, no mental math. It is measured from Flare's reward-scripts (actual payouts, not a formula), net of the validator's fee, and it moves each epoch with real rewards.

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • Staking rewards (VRM) — a delegator's net share of validation rewards = Σ delegator payout ÷ Σ delegated (Flare's own split; the fee is already removed). Because Flare pays proportional to stake, this is roughly uniform network-wide and differs mainly by fee — a lower fee means a higher delegation rate.
  • MIRROR — your stake's share of FTSO inflation, paid on top, only on validators running an active FTSO stack. It varies by the validator's FTSO participation and is measured over the most recent epochs.

Comparing to Flare Systems Explorer? FSE and other explorers show the delegation rate only — they don't add MIRROR — so our Total APR reads higher on any MIRROR-active validator (the gap is exactly the MIRROR line above). Both figures are ~8-epoch trailing averages from the same reward-scripts data, so a validator's mid-window fee change lags a current-fee snapshot on either site until it ages through the window.

Two other figures appear in the APR tooltip and are not the delegator's rate: the theoretical baseline (network gross APR × (1 − fee), staking only — used as a fallback before enough measured history exists), and the operator's self-bond yield (the validator's own stake return, amplified by fee capture — an operator metric, not what you earn).

For scoring: the Net Yield dimension scores the VRM delegation rate only, and MIRROR is scored in its own dimension — so MIRROR is never double-counted, even though it's included in the displayed Total APR.

Score bands
90+Top tier — top ~10–20% of operators. Typical profile: full-stack validator + FTSO + FDC, low-end fee, MIRROR-active, consistent FIP-10 reliability, healthy delegator base, meaningful self-bond. No single dimension required — operators reach Top tier by stacking strength across most categories.
80–89Strong — meets most key benchmarks; one or two dimensions short of top tier.
70–79Good — meets all baseline criteria; no major gaps.
60–69Acceptable — usable but not differentiated.
<60Below median — significant gaps in one or more dimensions. Mathematical fact, not a quality judgment.
Dimensions (sum to 100)
Uptime20 pts max
What: Combination of instantaneous P-Chain RPC uptime AND historical FIP-10 uptime-eligibility ratio across recent reward epochs.
How: RPC curve: ≥ 99.5% → 17 to 20. 99–99.5% → 13–17. 95–99% → 4–13. 90–95% → 0–4. < 90% → 0. The result is then multiplied by uptimeReliability (epochsUptimeEligible / epochsObserved across the last 8 reward epochs from public reward-scripts data). v3.9 fixed a perverse cliff at exactly 95% where going from 94.99 → 95.00 uptime lost 4 points.
if (uptime >= 99.5)   raw = 17 + (uptime - 99.5) * 6
else if (uptime >= 99) raw = 13 + (uptime - 99)   * 8
else if (uptime >= 95) raw = 4 + (uptime - 95) * 2.25    // v3.9: was (u - 95) * 3.25 starting at 0
else                   raw = max(0, uptime - 90) * 0.8   // 90 → 0, 95 → 4 (continuity)
raw = clamp(raw, 0, 20)

reliability = epochsUptimeEligible / epochsObserved   // last 8 epochs

score = raw * clamp(reliability, 0, 1)                 // dimension max 20
Why: Pre-v3.4, this dimension was essentially dead — 92.9% of live validators have 100% RPC uptime, so the curve scored everyone the same. The reliability ratio is a real time-series signal: a validator who failed FIP-10 minimum conditions in 3 of 8 recent epochs has a 62.5% reliability score, regardless of what the instantaneous RPC currently reports. Stricter than FIP-10's 80% protocol floor on purpose. Per-epoch eligibility data is published by the Flare Foundation in their reward-scripts repo.
Net Yield18 pts max
What: The net-of-fee staking-reward (VRM) rate a delegator receives, anchored to the network median.
How: scoreAPR = measured net DELEGATION rate (delegationAPY: Σ delegatorRewardAmount / Σ delegated, from Flare Foundation reward-scripts, last ~8 epochs) when available, else theoretical baseAPR = gross × (1 − fee). Score = (scoreAPR / medianAPR) anchored: ratio 0.6 → 0 pts, 1.0 (median) → 12 pts, 1.2 → 18 pts. IMPORTANT: this dimension scores the VRM (validation-reward) rate ONLY — MIRROR is scored separately in the MIRROR Participation dimension, so it is not double-counted here. The displayed 'Total APR' (VRM + MIRROR) is a delegator-facing number, not the Net Yield input.
scoreAPR = delegationAPY > 0 ? delegationAPY : baseAPR   // VRM, net of fee
medianAPR = median(scoreAPR across all validators)
cappedAPR = min(scoreAPR, 25)                  // APY_DISPLAY_CAP

if (medianAPR > 0):
  ratio = cappedAPR / medianAPR
  score = clamp(((ratio - 0.6) / 0.6) * 18, 0, 18)
else:
  score = min(18, (cappedAPR / 8) * 18)        // fallback: BASE_APY = 8
Why: Both sides of the ratio are the NET delegation rate (measured delegationAPY vs theoretical gross×(1−fee)), so the comparison is like-for-like — no longer inflated by 1/(1−fee) as it was when the input was a pre-fee gross rate (the ~2× 'doubling' bug). Because Flare pays validation rewards proportional to stake, the VRM delegation rate is roughly uniform network-wide and varies mainly by fee — so this dimension mostly reflects fee competitiveness and delivery reliability (a validator that misses epochs delivers less). MIRROR (which varies by FTSO participation) is deliberately kept in its own dimension to avoid double-counting.
Fee Reasonableness7 pts max
What: Gate against extraction above the protocol fee floor, smooth piecewise linear.
How: Anchor = max(observed minimum active fee, protocol validator-fee floor — 20% since the Granite hard fork, 2026-07-14). Any fee at or below the anchor → full 7 pts. Above it, a linear ramp with increasingly steep slopes over the next 20 points of fee (anchor+5 → 6, anchor+10 → 4.5, anchor+15 → 2.5, anchor+20 → 0): small overages barely penalized, extraction punished hard. Pre-Granite the anchor was an absolute 5%; the floor clamp means no operator is ever penalized for charging the legal minimum.
// anchor = max(observed minimum active fee, 20% protocol floor)
d = fee - anchor                                  // distance above market best
if (d <= 0)       score = 7                       // at/below best available
else if (d <= 5)  score = 7   - d * 0.2           //  0 → 5 over: 7 → 6
else if (d <= 10) score = 6   - (d - 5)  * 0.3    //  5 → 10 over: 6 → 4.5
else if (d <= 15) score = 4.5 - (d - 10) * 0.4    // 10 → 15 over: 4.5 → 2.5
else if (d <= 20) score = 2.5 - (d - 15) * 0.5    // 15 → 20 over: 2.5 → 0
else              score = 0
// fees > anchor+20 saturate at 0/7 — the v4.5 extreme-fee
// penalty below takes over from there
Why: Net Yield already accounts for per-percent fee in delivered terms; this dimension only flags operators charging materially above what the protocol and market allow. Once every fee sits at the enforced 20% floor, everyone earns full marks here and the dimension stops discriminating — by design: a number nobody can undercut can't differentiate anyone.
Operator Quality12 pts max
What: Takes the higher of two independent signals: verification baseline (identity confidence) and FTSO-derived operational performance.
How: Verification baseline: curated tier (+7) reached two ways — manually-vetted KNOWN_VALIDATORS entry OR auto-promotion via objective behavior (v3.10: 90+ days observed AND 25+ operator-aggregated delegators AND not currently shrinking AND self-bond ≥ FIP-10 floor). Auto-discovered name from Flaremetrics or FSE → +3. Unverified → 0. FTSO-derived: linear interpolation FTSO score 50 → 4 pts up to FTSO score 100 → 12 pts (below 50 floors at 4). Final score is max(verification, FTSO-derived) — FTSO participation can only help, never hurt.
// Verification baseline (v3.10 hybrid)
isCurated = (in KNOWN_VALIDATORS) OR (
  daysObserved >= 90 AND
  operatorDelegatorCount >= 25 AND
  retention30d >= -15% AND
  selfBondFLR >= 1_000_000
)

if (isCurated)                       verification = 7
else if (name auto-discovered)      verification = 3
else                                verification = 0

// FTSO-derived (only when ftsoOperatorScore is a number)
clamped = clamp(ftsoOperatorScore, 50, 100)
ftsoDerived = 4 + (clamped - 50) * (8/50)   // FTSO 50 → 4, FTSO 100 → 12

// Final score
score = max(verification, ftsoDerived)
Why: Rewards operators who run a complete stack (validator + FTSO + FDC) without penalizing trusted operators for participating in FTSO with a mid-tier score. The v3.8 max() logic explicitly prevents the perverse incentive of 'dropping FTSO to improve your FlareWatch score.' Auto-discovered tier (+3) closes the previous 7→0 cliff that hit operators registered with Flaremetrics or FSE but not yet hand-curated.
MIRROR Participation10 pts max
What: Whether the validator's nodeID actually delivers FTSO inflation share to stakers, weighted by fee passthrough.
How: Active → 10 × (1 − fee/100). Paused → 5 × passthrough. Inactive (no participation signal anywhere) → 0. No data (genuinely unobserved validator) → 5 × passthrough. v3.6 broadened the 'active' signal to include both on-chain RewardClaimed(claimType=3) events AND claimType=3 allocations in the canonical FSP Merkle JSON — either is sufficient. This catches validators whose MIRROR has been allocated but not yet claimed on-chain (e.g., self-delegating providers whose settlement path doesn't trigger the standard claim event).
passthrough = max(0, 1 - fee / 100)

if (mirrorStatus == "active")    score = 10 * passthrough
else if (mirrorStatus == "paused")   score = 5 * passthrough
else if (mirrorStatus == "inactive") score = 0
else                                 score = 5 * passthrough  // no data yet
Why: MIRROR distributes automatically to stakers on FSP-participating validators. A 100%-fee validator who's 'active' delivers $0 to delegators; the score reflects what delegators actually receive, not just protocol-side flag status.
Capacity Profile7 pts max
What: Tent function peaking at right-sized utilization.
How: 0% utilized → 1.75. Linear ramp up to 7 at 70% utilized. Linear ramp down to 5.25 at 100% (capped). Rescaled in v3.7 from 8 → 7 to fund the new Trust trajectory components.
utilization = clamp(1 - freeSpaceFLR / maxDelegationFLR, 0, 1)

if (utilization <= 0.70):
  score = 1.75 + (utilization / 0.70) * 5.25     // 1.75 → 7 ramp
else:
  score = 7 - ((utilization - 0.70) / 0.30) * 1.75 // 7 → 5.25 ramp
Why: Being at FIP-10 max delegations is a POSITIVE signal of attractiveness — proven trusted by enough delegators to fill up. v2 scored capped validators 0/5; v3 corrects this. Right-sized (proven attractive AND has room) gets the peak. v3.7 trimmed the dimension cap 8 → 7 so the freed point could fund Trust's new retention + self-bond trajectory components.
Community Trust11 pts max
What: Multi-signal: delegator count + stake-distribution health + longevity + operator self-bond alignment + 30-day retention + self-bond trajectory + multi-node operator aggregation.
How: Count signal (max 6, OPERATOR-AGGREGATED v3.7): log-scaled [5, 500] delegators → [0, 6], summed across all of an operator's known nodes. Concentration adjustment (±1): retail-friendly avg stake (<500K FLR) → +1, whale-concentrated (>50M FLR avg) → −1. Longevity bonus (max +1, wipe-immune v3.6): +0.5 at 30 days observed, +1 at 90+ days — falls back to reward-scripts epoch presence if the first-observed KV was wiped. Self-bond alignment (max +2 / min −1): proportional self-bond ≥10% → +2, 5–10% → +1, sub-FIP-10 floor (<1M FLR) → −1. Retention (max ±0.5, NEW v3.7): delegated FLR +10% over 30 days → +0.5, −15% → −0.5. Self-bond trajectory (max ±0.5, NEW v3.7): operator's self-bond +20% over 30 days → +0.5, −10% → −0.5.
// Count signal (max 6)
if (delegatorCount <= 5)        countScore = 0
else if (delegatorCount >= 500) countScore = 6
else  countScore = clamp(log(delegatorCount / 5) / log(100) * 6, 0, 6)

// Concentration adjustment (-1 to +1) — skip if <3 delegators
avgFLR = delegatedFLR / delegatorCount
if (avgFLR < 500_000)        concentrationAdj = +1
else if (avgFLR < 5_000_000)   concentrationAdj = +0.5
else if (avgFLR > 50_000_000)  concentrationAdj = -1
else if (avgFLR > 20_000_000)  concentrationAdj = -0.5
else                           concentrationAdj = 0

// Longevity bonus (0 to +1)
daysObserved = (now - firstObservedAtMs) / 86400000
if (daysObserved >= 90)      longevityBonus = +1
else if (daysObserved >= 30) longevityBonus = +0.5
else                         longevityBonus = 0

// Self-bond alignment (-1 to +2)
selfBondRatio = selfBondFLR / (selfBondFLR + delegatedFLR)
if (selfBondFLR < 1_000_000)   selfBondAdj = -1
else if (selfBondRatio >= 0.10) selfBondAdj = +2
else if (selfBondRatio >= 0.05) selfBondAdj = +1
else                            selfBondAdj = 0

// Retention (-0.5 to +0.5, v3.7) — skip if no 30-day baseline yet
delta = (delegatedFLR - delegatedFLR30dAgo) / delegatedFLR30dAgo
if (delta >= +0.10)      retentionAdj = +0.5
else if (delta <= -0.15) retentionAdj = -0.5
else                     retentionAdj = 0

// Self-bond trajectory (-0.5 to +0.5, v3.7) — skip if no baseline
sbDelta = (selfBondFLR - selfBondFLR30dAgo) / selfBondFLR30dAgo
if (sbDelta >= +0.20)      selfBondTrajectoryAdj = +0.5
else if (sbDelta <= -0.10) selfBondTrajectoryAdj = -0.5
else                       selfBondTrajectoryAdj = 0

score = clamp(countScore + concentrationAdj + longevityBonus + selfBondAdj
            + retentionAdj + selfBondTrajectoryAdj, 0, 11)
Why: Skin-in-the-game self-bond is a real fairness signal we were missing — a validator with 10% of total stake as self-bond has materially more aligned incentives than one running on the FIP-10 minimum. Longevity rewards proven track records without penalizing newcomers (small bonus on top, not penalty below). Concentration risk matters for delegators — a validator with 1 whale at 50M FLR is structurally different from 50 retail at 1M each. The two v3.7 trajectory signals reward organic growth and growing operator commitment. Combined cap is 11 (raised from 10 in v3.7 to fund them), no single signal dominates.
Delivery Reliability10 pts max
What: Ratio of the actually-delivered net delegation rate (VRM) vs. the theoretical baseline, with a variance penalty for inconsistent payouts. Both sides are net of fee, so the ratio measures real delivery — not the fee.
How: Piecewise linear delivery ratio: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → linear ramp toward 0. Variance penalty: coefficient of variation × 0.5, capped at −30%. Confidence dampener blends toward neutral 5 when sample size < 3 epochs. v3.9 linearized the previously-bucketed thresholds — boundary cliffs of up to 2 points are now smooth.
// Time-weighted rate is computed upstream from per-epoch
// reward-scripts data with decay = 0.85 per epoch back.
r = deliveryRatio   // capped at 1.0

if (r >= 1.00)      base = 10
else if (r >= 0.97) base = 9  + (r - 0.97) * (1 / 0.03)   // 0.97 → 9, 1.00 → 10
else if (r >= 0.95) base = 8  + (r - 0.95) * (1 / 0.02)   // 0.95 → 8, 0.97 → 9
else if (r >= 0.90) base = 6  + (r - 0.90) * (2 / 0.05)   // 0.90 → 6, 0.95 → 8
else if (r >= 0.85) base = 4  + (r - 0.85) * (2 / 0.05)   // 0.85 → 4, 0.90 → 6
else if (r >= 0.80) base = 2  + (r - 0.80) * (2 / 0.05)   // 0.80 → 2, 0.85 → 4
else                base = max(0, r * 2.5)                 // 0 → 0, 0.80 → 2

// Variance penalty (CoV = std-dev / mean across per-epoch rates)
variancePenalty = min(0.30, coefficientOfVariation * 0.5)
score = base * (1 - variancePenalty)

// Sample-size confidence dampener for < 3 epochs
if (totalStakesCompleted < 3):
  confidence = totalStakesCompleted / 3
  score = 5 + (score - 5) * confidence
Why: Promised vs. delivered is the most direct accountability signal for stakers. v3.3 added two refinements: (1) the headline ratio uses an exponentially time-weighted mean (recent epochs count more), so a validator who used to deliver well but recently slipped is correctly penalized; (2) the variance penalty distinguishes consistent 95% deliverers from oscillating-around-95% deliverers, since the latter carry more risk for stakers who care about predictable yield.
Time Remaining5 pts max
What: Days until validator's stake-end on the P-Chain.
How: < 14 days → 0 (essentially unavailable under FIP-10). 14-30d → linear 0→2. 30-60d → linear 2→3. 60-120d → linear 3→5. 120d+ → 5. v3.9 linearized the previously-bucketed thresholds — boundary cliffs (e.g. 13.99d → 0, 14d → 2) are now smooth.
daysLeft = (endTimeMs - now) / 86_400_000

if (daysLeft < 14)       score = 0
else if (daysLeft < 30)  score = 0 + (daysLeft - 14) * (2 / 16)    // 14 → 0, 30 → 2
else if (daysLeft < 60)  score = 2 + (daysLeft - 30) * (1 / 30)    // 30 → 2, 60 → 3
else if (daysLeft < 120) score = 3 + (daysLeft - 60) * (2 / 60)    // 60 → 3, 120 → 5
else                     score = 5
Why: Practical signal — delegating to a validator with 7 days left is a different proposition than 1 year. v3.2 tightened the bottom: validators within 14 days of stake-end can't accept new delegations (FIP-10 minimum lock is 14 days), so they're effectively unstakeable. Score = 0 distinguishes 'unstakeable right now' from 'winding down soon.'
Active Outage Penalty (v4.3)(deduction) pts max
What: Flat deduction layered on top of the positive dimensions when a validator misses multiple reward epochs in a row. Distinct from the symmetric Uptime reliability multiplier — captures active outages, not chronic flakiness.
How: Look at the validator's contiguous !eligible prefix in the cache:fsp-validator-participation record (newest-first epoch list from the public reward-scripts nodes-data.json). 0–1 consecutive misses → 0 pts (within variance / single transient miss). 2 consecutive → −3 pts (developing outage). 3 consecutive → −6 pts (sustained — operator inattention). 4+ consecutive → −10 pts (active extended outage). Composite score is floored at 0 after the deduction.
consecutiveMisses = 0
for entry in participation.recent (newest-first):
  if entry.eligible: break
  consecutiveMisses++

if consecutiveMisses < 2:  penalty = 0
elif consecutiveMisses == 2: penalty = 3
elif consecutiveMisses == 3: penalty = 6
else:                        penalty = 10                  // 4+

score = max(0, positiveDimensionsSum - penalty)
Why: The pre-v4.3 model relied entirely on the symmetric uptimeReliability multiplier — 5 scattered misses across 24 epochs cost the same as 5 misses in a row. Operationally those are very different signals. Scattered misses tell delegators about chronic flakiness; a streak tells them the validator is broken RIGHT NOW. The Luganodes incident on 2026-05-14 — multiple consecutive missed epochs while delegators were actively committing millions of FLR — was the specific case the v4.3 release addresses: surface the active-outage signal with sharper score impact so delegators can avoid an in-flight failure before committing. Tiered curve avoids overreacting to single transient misses (common) while sharply flagging sustained streaks (rare and consequential).
Extreme-Fee Penalty (v4.5)(up to −75% of score) pts max
What: Proportional deduction for fees beyond the Fee dimension's range. The Fee dimension bottoms out at 0/7 once a fee exceeds the anchor by 20 points — past that, the composite previously stopped responding to fee entirely, so a 100%-fee validator (its delegators keep nothing) could still score in the 40s on fee-blind dimensions like uptime and MIRROR.
How: Zero at or below a 50% fee — the Fee dimension already prices that range, so there is no double-count. Above 50% the deduction ramps linearly with the fee, reaching 75% of the validator's positive score at a 100% fee. It scales with the score itself, so a polished private node and a neglected one both land where they belong: at the bottom of a delegator-facing ranking.
// v4.5 — fees beyond the Fee dimension's range (anchor+20)
if fee <= 50:  penalty = 0
else:          fraction = min(1, (fee - 50) / 50) * 0.75
               penalty  = positiveDimensionsSum * fraction

// fee 50% → no change · 75% → −37.5% of score · 100% → −75%
score = max(0, positiveDimensionsSum - outagePenalty - penalty)
Why: This is a score for delegators. A validator that keeps every reward its delegators earn is not a delegation candidate no matter how good its uptime is — the score should say so unmistakably. Pure function of the on-chain fee, applied identically to every node, ours included.
How to score 100/100 — a validator playbook
The audit cycle that produced v4.0 was specifically designed so that maxing every dimension genuinely makes you a better validator for your delegators. Improving your score is not gaming the system — it's the system working as designed. Here's the explicit playbook, per dimension.
Uptime — 20 pts. Maintain ≥99.5% RPC uptime continuously AND pass FIP-10 minimum conditions in every reward epoch (don't miss reveals, hit median delivery). The two signals are multiplied — 100% RPC × 7/8 epochs eligible = 17.5/20, not 20. Why this aligns with delegators: every epoch you fail FIP-10, your delegators lose their rewards for that epoch.
Net Yield — 18 pts. Deliver ≥1.2× network median APR to your delegators (post-fee). Best path: low fee + full FIP-10 eligibility so delegators receive their full share. Why this aligns: this is literally the dollar amount reaching the delegator after your cut.
Fee Reasonableness — 7 pts. Since the Granite hard fork the protocol enforces a 20% minimum delegation fee, and any fee at or below the scoring anchor (the greater of the observed market minimum and that floor) earns the full 7. Charging above it costs points on an accelerating ramp — anchor+10 → 4.5 pts, anchor+20 → 0. Why this aligns: the floor killed fee competition, so this dimension now only protects delegators from extraction above the legal minimum; your real edge lives in delivered Net Yield.
Operator Quality — 12 pts. Best path: register as an FTSO data provider and run a top-quality stack (FTSO + FDC + signing) — your FlareWatch Operator Quality score then comes from your FTSO score, with max at FTSO 100. Alternative if you're staking-only: maintain the +7 verification baseline either by qualifying for v3.10 auto-promotion (90+ days observed, 25+ delegators, retention not declining, FIP-10-compliant self-bond) or by being added to KNOWN_VALIDATORS as institutional infrastructure (manual fast-track). The score takes max(verification, FTSO-derived) — participation can never hurt. Why this aligns: full-stack operators provide more ecosystem value; the verification baseline gives delegators clearer identity signal.
MIRROR Participation — 10 pts. Submit FSP price feeds consistently, meet per-epoch protocol minimums (registered in your signing policy, claim threshold met, no reveal misses). Charge a moderate fee — score is multiplied by (1 − fee/100), so even a perfectly MIRROR-active 100%-fee validator scores 0 because zero MIRROR reaches delegators. Why this aligns: MIRROR is your delegators' share of FTSO inflation. Lower fee = more reaches them.
Capacity Profile — 7 pts. Target ~70% utilization (right-sized: proven attractive AND has room for new delegators). Empty validators score 1.75; capped validators score 5.25. Why this aligns: new delegators reading the score want to know they can actually delegate; right-sized signals both social proof and availability.
Community Trust — 11 pts. Six components to max:
  • Build to 500+ operator-aggregated delegators (max count signal: +6 pts).
  • Maintain retail-friendly avg stake < 500K FLR per delegator (concentration bonus: +1).
  • Stay on the network ≥ 90 days for the longevity bonus (+1) — wipe-immune via reward-scripts presence.
  • Hold ≥ 10% proportional self-bond (alignment bonus: +2).
  • Grow total delegated FLR by ≥ 10% over 30 days (retention: +0.5).
  • Grow self-bond by ≥ 20% over 30 days (trajectory: +0.5).
Why this aligns: every component rewards a behavior delegators want — operator skin-in-the-game, organic growth, longevity, broad community participation. Multi-node operators are aggregated for the count + concentration signals (v3.7).
Delivery Reliability — 10 pts. Pay delegators what your estimated APY promises (delivery ratio 1.00). Minimize per-epoch variance — predictable payouts beat the same mean with high spread (variance penalty up to −30%). Build a sample size of 8+ epochs for full confidence weighting. Why this aligns: are you delivering on the promise you made, consistently? That's the most direct accountability signal there is.
Time Remaining — 5 pts. Keep your stake-end date ≥ 120 days away. Renew well before expiration; don't let it slide into the < 14-day band (you can't accept new delegations under FIP-10 once you're inside 14 days). Why this aligns: longer commitment signals delegators that you're here for the long haul.
Time-gated signals you can't shortcut: longevity bonus (90 days observed), auto-curation tier (90 days + 25 delegators + non-declining retention + FIP-10 self-bond), retention signal (30 days of delegation history), delivery sample size (8 reward epochs). The good news: maintaining the OTHER behaviors automatically accrues these over time.
Smoothing window matters in the short term: the displayed score is an exponentially-weighted average of the last 4 cron snapshots (0.5 / 0.3 / 0.15 / 0.05), so even a perfect 100 on inputs takes ~20 minutes of consecutive perfect cron runs to fully reflect. Steady-state perfect inputs = 100; transient improvements get smoothed in. Sudden-change penalties (fee jumps, self-bond drops, uptime crashes) can also dock up to 10 pts for a few cron cycles after detection.
In short: every dimension is honest about what it measures. If your validator is at 100/100, the score is also telling your delegators they're getting the best version of a validator on the network — that's the design intent.
How to verify your own score
Every score on the validators table is reproducible from public data. If you're an operator and the math here doesn't match the score you see, the right move is to verify it yourself before assuming we made an error.
The fastest check runs automatically. Expand any validator's score row and the “Verified in your browser” panel recomputes that score locally — the exact same scoring function the cron uses, over the exact inputs it used, with no call back to our server. Because every validator is scored by one identical function that has no term for node identity, this is also how anyone can confirm our own node earns no hidden advantage. The manual walkthrough below does the same thing by hand:
  1. Look up your validator's public stats at flaremetrics.io (search by your operator name or paste your delegation address). Note your delegationFee, selfBond, delegatedStake, and FTSO score (if you're also a data provider).
  2. Verify your FIP-10 eligibility for each of the last 8 reward epochs at github.com/flare-foundation/reward-scripts under generated-files/reward-epoch-N/nodes-data.json. Count how many epochs your nodeID had uptimeEligible: true. That ratio drives your Uptime dimension multiplier.
  3. Check your MIRROR participation on the V2 RewardManager contract via flare-explorer.flare.network. Look for RewardClaimed events with claimType=3 referencing your nodeID. If there are none recent, you'll show as MIRROR-inactive.
  4. Plug your inputs into the formulas above. Each dimension's code block tells you exactly what arithmetic to run. Sum the dimensions, clamp to 100, and you have your raw cron-computed score.
  5. Compare to your displayed score. The displayed score includes v3.5's exponential moving average across the last 4 cron snapshots (current weighted 0.5, prev 0.3, etc.) — so a single run's computed score will be slightly different from the displayed one. The score-breakdown panel on each validator row shows the persisted dimension values that contributed.
  6. If the math doesn't add up, email hello@flarewatch.io with your nodeID, the inputs you used, and the score you computed. We'll respond, and if we made an error we'll fix it publicly.
Programmatic access: for any active validator, hit GET /api/validators/{nodeID}/score-breakdown to retrieve the persisted breakdown — every dimension's value, the algorithm version that produced it, and the recent score history — as JSON. The score-breakdown panel in the UI reads from the same source.
Common operator concerns
I'm at 100% RPC uptime — why is my Uptime score below 20/20?
The Uptime dimension v3.4+ multiplies the RPC-curve output by your epoch-eligibility ratio (epochsUptimeEligible / epochsObserved across the last 8 reward epochs). If you failed FIP-10 minimum conditions in any of those epochs — even briefly — your reliability ratio drops below 1.0 and your Uptime score scales proportionally. Pre-v3.4 the dimension scored 20 for every validator with 100% RPC uptime regardless of historical eligibility. Now it differentiates.
I deliver MIRROR — why does FlareWatch show me as MIRROR-inactive?
As of v3.6, MIRROR participation is detected from TWO canonical sources: on-chain RewardClaimed(claimType=3) events on the V2 RewardManager, AND claimType=3 allocations in the official FSP Merkle JSON (the published reward distribution data). A nodeID showing in either source counts as active. Pre-v3.6 we used the on-chain stream as the sole signal, which produced false negatives for self-delegating providers whose MIRROR settles through a non-standard claim path. Also fixed in v3.6: a key-format bug where ~95 validators had their mirror-stats entries written under hex20 (bytes20 form of the nodeID) by the on-chain indexer when they weren't yet in our curated name list — while every UI lookup keyed by cb58 NodeID. Those entries existed and were correct; they just weren't visible to the display layer. The lookup now normalizes both formats across every consumer (validators table, score-breakdown panel, public mirror-stats API, Yield page Staking Positions card, FTSO providers panel). If your nodeID is still showing inactive after the v3.6 sweep, possible causes: (a) your nodeID isn't actually enrolled in your FSP signing policy for that epoch, (b) we're between epoch publications (Merkle data updates per epoch, ~3.5 days). Email us with your nodeID and we'll cross-check both canonical sources.
My score dropped 10 points overnight — what changed?
One of three things: (1) v3.5 sudden-change detection flagged a fee jump, self-bond drop, or uptime crash on your nodeID — a 10-pt penalty applies the run we detect it and decays over the next 3 runs as the new state stabilizes; (2) the smoothing window incorporated an older snapshot that pulled your average down; (3) we shipped an algorithm version bump (visible in your record's algorithmVersion field — see the Versions card below). The score-breakdown panel shows current dimension values; compare against your prior runs.
Why does a high-fee validator score lower than a low-fee one with similar everything else?
Net Yield dimension (18 pts max) is fee-sensitive — a 0% fee validator delivers ~1.25× the network median APR, scoring near max; a 20% fee validator delivers ~80% of median, scoring lower. Plus Fee Reasonableness (7 pts) is piecewise linear since v3.9 (no buckets): ≤5% gets the full 7, then the curve ramps down with steepening slopes — 10% → 6, 15% → 4.5, 20% → 2.5, 25%+ → 0 (so e.g. a 16% fee scores ~4.1, not a flat bucket value). So a 5-pt fee difference translates to ~5-8 pts of score difference. That's intentional — delegators care directly about fee.
I'm a brand-new validator with no FTSO score. Why is my Operator Quality only 7/12?
Operator Quality (12 pts max) rewards full-stack operators — validators who also run a top FTSO data-provider stack (FTSO + FDC + signing). If you're staking-only, the +7 baseline is reachable two ways: (1) manual inclusion in our KNOWN_VALIDATORS list — institutional fast-track for trusted infrastructure operators (Ankr, InfStones, Kiln, etc.); (2) v3.10 auto-promotion based on objective behavior — 90+ days observed AND 25+ operator-aggregated delegators AND retention not declining AND FIP-10-compliant self-bond. Auto-promotion is fully automatic, no email needed. If you don't yet meet the auto-criteria you start at +3 (auto-discovered tier, requires a Flaremetrics or FSE entity profile) and grow into +7 as your track record builds. To accelerate: register as an FTSO data provider and run the V2 protocols — your score then comes from the FTSO-derived branch with a max of 12 at FTSO 100. v3.8: FTSO participation can only help, never hurt — if your FTSO score is below the verification baseline, you keep the baseline.
I have a logo but my name shows as a truncated NodeID. Why?
Your operator entity exists in Flaremetrics (which is why we have a logo for you) but your provider profile doesn't have a 'name' field set. We don't fabricate names. Set your profile.name on Flaremetrics or in the Flare Systems Explorer entity registry, and we'll pick it up on the next cron run. Alternatively, email us a verifiable claim (e.g., a signed message from your delegation address) and we'll add you to KNOWN_VALIDATORS by hand.
My validator is at FIP-10 max delegations. Why doesn't Capacity score 7/7?
Capacity is a tent function peaking at 70% utilization (7 pts), ramping down to 5.25 pts at 100%. The peak isn't 100% — being at-cap means delegators can't add more stake even if they want to, which is a neutral-to-mildly-negative signal for new delegators reading the table. Pre-v3 we scored capped validators 0/5 (penalty for success); v3 corrected this to a neutral at-cap value, and v3.7 rescaled the whole dimension from 8 → 7 max (freeing a point for the Trust trajectory signals), so today capped scores 5.25/7. Right-sized validators (proven attractive AND with room to grow, peak at 70% utilized) get the full 7.
I'm a real operator but I'm not in the validator list at all. What gives?
The validator list is built from the live P-Chain RPC's getCurrentValidators result. If you're not there, you're either not currently active on P-Chain, your stake just expired, or there's a P-Chain RPC issue on our side. The cron runs every 5 minutes — you should appear within 1-2 cycles of activating your stake. If you've been live for an hour and still don't see yourself, email us your nodeID.
Can I appeal my score or request a manual review?
Yes. Email hello@flarewatch.io with your nodeID and a specific concern. We respond to every operator. Things we'll act on: KNOWN_VALIDATORS additions, MIRROR-classification corrections, logo/name fixes, dimension-specific math errors. Things we won't act on: requests to manually raise a score outside the algorithm, requests to exclude or de-rank a competitor.
What we will and won't do
To remove ambiguity about how we operate the score, here are explicit commitments. If we ever violate one of these, document it and email hello@flarewatch.io — we will publicly correct it.
We will not accept payment for higher scores, sponsored placement, or favorable treatment of any kind. The score is computed deterministically from public chain data.
We will not hand-code per-validator bumps. There is no "X gets +5 because we like them" line anywhere in the code. The same algorithm applies to every validator including FlareWatch's own node, which is scored by this exact function.
We will not exclude validators from the table for non-public reasons. The list is sourced from the live P-Chain RPC and our display includes every active validator. Curated additions to KNOWN_VALIDATORS only fill in display names — they do not gate visibility.
We will publish algorithm changes. Every version bump (v3 → v3.1 → v3.2 → ...) is documented in the Versions card on this page with the rationale and what moved. Major changes get an additional changelog entry visible from the app's changelog page.
We will respond to operator emails. Every operator who emails hello@flarewatch.io with a substantive concern about their score gets a real response within a few business days.
We will publicly correct our mistakes. If we discover a bug in the algorithm, a data-source error, or a methodology gap, we ship a fix and document it. We don't silently re-rank.
We will not share email contents publicly without the sender's permission, or use operator emails for anything other than the score conversation that produced them.
We will not share our future plans for an algorithm change with select operators in advance — every version goes live for everyone simultaneously.
Final score (how dimensions combine)
All 9 dimensions sum directly, then the v4.3 active-outage streak deduction is subtracted. Total caps at 100 and floors at 0. Smoothing across recent cron snapshots (v3.5) and any sudden-change penalty are then applied to the final number.
// Step 1 — Raw composite (sum of dimensions, minus streak deduction)
positive = uptime + netYield + fee + operatorQuality
         + mirror + capacity + trust + delivery + timeRemaining

// v4.3 — active-outage streak penalty (see the dimension card above)
// 0-1 consecutive missed epochs → 0, 2 → 3, 3 → 6, 4+ → 10
raw = clamp(positive - streakPenalty, 0, 100)

// Step 2 — Smooth across recent cron snapshots (v3.5)
// Weights: current 0.5, prev1 0.3, prev2 0.15, prev3 0.05
smoothed = 0.5*raw + 0.3*prev1 + 0.15*prev2 + 0.05*prev3

// Step 3 — Apply sudden-change penalty if flagged this run
// Triggers: fee +50% or +5pt jump, self-bond -20% drop, uptime -5% crash
// Magnitude: -10 pts on detection, decays -7, -4, -1 over 3 runs
suddenPenalty = -10 if any flag triggered else (decaying remainder)

// Step 4 — Final score
score = clamp(smoothed + suddenPenalty, 0, 100)
Data sources (every input is public)
Flare P-Chain RPC: validator list, uptime, self-bond, delegated stake, fee, end time, delegator count.
V2 RewardManager (claimType=3 events): on-chain claimed MIRROR distribution per validator nodeID. Filtered strictly on type 3 — no conflation with VRM, FTSO delegation, or DIRECT rewards.
FSP Merkle JSON (claimType=3 allocations): canonical published record of who is owed MIRROR per epoch (the same data Flare's own signing tool reads). Added in v3.6 as a second authoritative source — catches validators whose MIRROR is allocated but not yet claimed on-chain.
Flare Systems Explorer (FSE): validator entity registry, display names, logos, FTSO V2 protocol participation flags.
Flaremetrics provider data: FTSO score, reward rate, accuracy, V2 features, entity-to-nodeID linkage.
Flare reward-scripts (GitHub): per-validator delivered APY for the most recent N reward epochs. Drives the Delivery dimension.
FlareWatch curation: KNOWN_VALIDATORS map (~110 entries). Names + Operator Quality baseline for trusted infrastructure operators.
What's NOT in the score
Self-promotion or paid placement. No operator can pay or sponsor a higher score.
Hand-coded validator-specific bumps. No "X gets +5 because we like them" lines anywhere in the code. The same algorithm applies to every validator including FlareWatch's own node, which is scored by this exact function.
Subjective infrastructure quality. We don't try to evaluate uptime SLAs, geographic distribution, or hardware specs. If you want to claim infrastructure-grade, run a top FTSO + FDC stack and the Operator Quality dimension will reflect it.
Lockups or commitments to FlareWatch. No favorable scoring for stakers using FlareWatch vs. another tool.
Operator feedback
See something off in your validator's score? Email hello@flarewatch.io with your NodeID and concern. We respond to every operator. Common requests we'll act on:
  • Adding your operator to KNOWN_VALIDATORS (with verification).
  • Reviewing your MIRROR-inactive classification if you believe it's in error.
  • Logo / display-name corrections.
  • General algorithm critique.
Sources & references
Every input to the score comes from public, verifiable Flare-ecosystem sources. Anyone can cross-check our claims against these primary sources and reproduce the math from raw data. If you spot a discrepancy between this page and what the upstream sources say, email hello@flarewatch.io and we'll fix it.
Authoritative protocol docs. Covers FTSO V2, FSP, P-Chain validation, FAssets, and the rest of the Flare stack.
Flare governance portal (FIPs)https://proposals.flare.network
Flare Improvement Proposals — the source of truth for FIP-05 (delegation factor), FIP-10 (validator minimum conditions: 1M FLR self-bond floor, 80% uptime floor, 14-day minimum lock), and all other rules cited on this page.
Flare Systems Explorer (FSE)https://flare-systems-explorer.flare.network
Official Flare-operated registry of FTSO data providers, entity addresses, P-Chain nodeID linkages, and FIP-10 minimum-conditions flags. Primary source for our Operator Quality and reliability data.
Flaremetricshttps://flaremetrics.io
Independent Flare-ecosystem metrics provider. Source of FTSO provider scoring, reward rates, accuracy metrics, V2 protocol participation flags, and validator-to-entity address mappings. We consume their public REST API.
Flare Foundation reward-scripts repohttps://github.com/flare-foundation/reward-scripts
Per-reward-epoch JSON published by the Flare Foundation showing per-validator eligibility, uptime-eligibility, and delivered rewards. Drives the Delivery Reliability dimension and the v3.4 epoch-eligibility ratio for Uptime.
Flare Block Explorerhttps://flare-explorer.flare.network
Read-only browser of all on-chain state. Lets anyone verify the V2 RewardManager's RewardClaimed events (claimType=3 for MIRROR), validator stake totals, fee changes, and the rest.
Flare Portal (staking)https://portal.flare.network/staking
Official staking interface. Authoritative source for current self-bond / delegated stake amounts and validator end-times that feed the P-Chain RPC reads we use.
Flaremetrics public API (FTSO providers)https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
The exact endpoint our cron consumes, returning entity profiles, FTSO scores, fees, and nodeIds in hex format. Anyone can hit it directly.
Flaremetrics public API (node registrations)https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID conversion table. We paginate this to build the entity-to-NodeID lookup that drives every cb58-format consumer.
No private data, no closed-source models. The scoring algorithm is implemented in services/validators/scoring.ts in the FlareWatch codebase. Operators or researchers who want to inspect the implementation directly (rather than reading the prose + formulas above) — or who want to fork it for their own use — can email hello@flarewatch.io to request access. We'll publish the file as a standalone open-source package if there's real demand.
How scores update
The cron at /api/cron/refresh-validators recomputes every active validator's score every 5 minutes. Inputs (P-Chain RPC reads, Flaremetrics, FSE, reward-scripts) are fetched fresh on every run.
v3.5 added smoothing across the last 4 cron snapshots (weights: 0.5 / 0.3 / 0.15 / 0.05), so the displayed score doesn't whipsaw on transient input noise. The raw cron-computed score is still persisted for future smoothing math, and the score-breakdown panel shows every dimension's current value so you can see what changed.
Algorithm version is stamped on every cached score record. When we ship a new version, every score gets the new tag. The Versions card below documents every change.
Flare's penalty model

Flare does not slash validator stake. The entire penalty mechanism for validator misbehavior is reward forfeiture plus the FIP-10 passes system. There is no double-signing slash, no equivocation slash, no stake-destruction event we need to track. Validators who fail FIP-10 minimum conditions lose that epoch's rewards (full forfeit if at zero passes, otherwise lose one pass per protocol they failed); their staked principal is untouched.

That means the score has no "slashing history" dimension — there is no such history to track. What we DO track is the consequence of every minimum failure: the validator earned zero in that epoch, which is captured in epochsIncluded / epochsObserved. The v4.2 update on 2026-05-14 widened the score's reliability multiplier to use that ratio across the full FIP-10 minimums set (uptime, FSP signing, FTSO submission rate, FDC participation) so a validator failing any minimum is proportionally penalized in the Uptime dimension regardless of which axis failed.

FIP-10 minimum thresholds, sourced from dev.flare.network/network/fsp/rewarding: staking requires 80% uptime + 1M FLR active self-bond; FTSO anchor feeds require estimates within 0.5% of consensus median in 80% of rounds; FTSO block-latency feeds require submitting 80% of expected updates; FDC requires participating in 60% of voting rounds. Validators meeting the 80% uptime + 1M self-bond floor but below the 3M / 15M earn thresholds still receive rewards but can't accumulate passes — the gray zone surfaced via this card's passEligibility: "at-risk" classification.

Versions
v4.4 (2026-07-11) — Granite floor-aware fee anchor. The Granite hard fork (Flare, 2026-07-14) enforces a 20% minimum validator delegation fee. The Fee Reasonableness anchor becomes max(observed minimum active fee, protocol floor): every fee at or below the legal minimum earns full marks, and only fees above it are penalized, by distance. Rationale: with grandfathering of in-flight stakes unspecified upstream, anchoring to a grandfathered 2% (or pre-fork 0%) relic would have scored protocol-compliant 20% operators as near-extractive — and double-counted a fee delta that Net Yield already prices in delivered terms. No other dimension changed. When the whole cohort reaches the floor, the dimension awards full marks uniformly — fee stops counting once nobody can compete on it.
v4.3 (2026-05-14) — Active Outage Penalty added as a flat post-dimension deduction. The existing uptimeReliability multiplier is symmetric — 5 scattered misses across 24 epochs cost the same as 5 misses in a row — but operationally those are very different signals: scattered misses mean chronic flakiness, a streak means the validator is broken RIGHT NOW. v4.3 reads the contiguous run of !eligible epochs at the head of the validator's recent participation history and deducts 0 pts for 0–1 consecutive misses (normal variance / single transient miss), 3 pts at 2 (developing outage), 6 pts at 3 (sustained outage), and 10 pts at 4+ (active extended outage), with the composite floored at 0. Layered on top of — not replacing — the reliability multiplier, since the two capture different hazards. Trigger: the Luganodes-class incident on 2026-05-14, where multiple recent epochs missed in a row while delegators were actively committing stake; the streak signal lets delegators see an in-flight failure before committing. Penalties render as their own section in the score-breakdown panel so the 9 positive dimensions still sum to 100.
v4.2 (2026-05-14) — TWO related fixes, shipped together in response to a public correction from AU (@aucc_official) about Luganodes' score. (1) deliveredAPY computation now multiplies the rate-per-earning-epoch by `epochsIncluded / epochsObserved` so the displayed APR reflects the EFFECTIVE rate a delegator actually receives over the observation window — including the zero-earning epochs when a validator fails FIP-10 minimums. The prior implementation averaged only earning epochs and showed validators their good-epoch rate, masking minimum failures. (2) The Uptime dimension's reliability multiplier widened from uptime-only (epochsUptimeEligible / epochsObserved) to the full FIP-10 minimums set (epochsIncluded / epochsObserved). A validator with 100% RPC uptime who fails FSP signing or FTSO submission rate now takes a proportional hit on the Uptime dimension regardless of which minimum they missed. Net effect on Luganodes specifically: deliveredAPY drops from 10.86% to ~5.43% (matching the actual half-paying reality), uptime reliability drops from 1.0 to 0.5, score drops materially. The same correction applies to every validator with `epochsIncluded < epochsObserved` — across the network this surfaces real participation-quality gaps that were previously hidden.
v4.1 (2026-05-14) — Net Yield dimension switched from theoretical APR (formula: gross_APR × (1 − fee)) to MEASURED deliveredAPY from Flare Foundation reward-scripts, with theoretical fallback per-validator only when no measurement history exists. Trigger: FIP-16's inflation reduction (5% → 3%) went live 2026-05-14, and the theoretical formula's eligible-stake denominator drifted from on-chain reality such that theoretical APR under-reported delivered yields by ~2× across the network. Switching to measured-first realigns the score input with what stakers actually receive. The networkMedianAPR anchor was also recomputed using the same measured-first methodology so the ratio comparison stays consistent on both sides — scores should be roughly stable (a validator at network median still scores ~12/18, etc.), just based on real delivered rates rather than formula output.
v4.0 (2026-05-11) — Major version. The v3.7-v3.10 cycle cumulatively constitutes a structural rewrite of the scoring system, large enough to warrant the bump. Summary: two dimensions had their caps changed (Trust 10→11, Capacity 8→7); Operator Quality's formula was rewritten to max(verification, FTSO-derived) so participation can't hurt; the four remaining bucketed dimensions (Uptime, Fee, Delivery, Time Remaining) were linearized to eliminate boundary cliffs; three new score components were added (30-day delegation retention, 30-day self-bond trajectory, auto-promotion to curated tier); multi-node operator aggregation was introduced for Trust count + concentration; longevity is now wipe-immune via reward-scripts epoch presence; and two perverse incentives were eliminated (the Operator Quality FTSO-participation penalty and the Uptime 95% inverted-V cliff). Every input to the score is now externally verifiable — no editorial decision is load-bearing. Validators can earn the +7 curated-operator baseline through observable behavior (90+ days observed, 25+ delegators, retention not declining, FIP-10-compliant self-bond), no email-the-team required. See v3.7-v3.10 entries below for the granular changes that compose this release.
v3.10 (2026-05-11) — Closed the last curatorial gap in the score. The +7 curated-operator baseline on Operator Quality previously required hand-inclusion in our KNOWN_VALIDATORS list, which was the only meaningful editorial decision left after the v3.7-v3.9 audit cycle. v3.10 adds an objective auto-promotion path: any validator with 90+ days of FlareWatch observation, 25+ operator-aggregated delegators, retention not in decline (30-day drop ≤ 15%), and FIP-10-compliant self-bond automatically qualifies for the +7 baseline — no manual review needed. KNOWN_VALIDATORS stays as a fast-track for institutional operators who haven't yet accrued the 90-day window (think a launch-day Ankr or Kiln entry), but the typical case is now fully automated. All four criteria are on-chain-derived or near-on-chain (delegator count, retention, self-bond) plus our own observation timestamp — nothing subjective, no email-the-team gating. Net effect: a validator can earn the +7 tier through behavior alone. Most established operators on the network already meet the criteria today.
v3.9 (2026-05-11) — Boundary-cliff cleanup across the remaining four bucketed dimensions, after auditing every part of the score for fairness. Fixed: (1) a perverse inverted-V cliff in the Uptime curve at 95% — going from 94.99% → 95.00% uptime lost 4 points (the 95-99% branch started at 0 instead of matching the lower branch's max of 4). Same shape of backward incentive we just fixed in Operator Quality (v3.8). (2) Fee Reasonableness thresholds linearized — pre-v3.9, a 0.01% fee increase across a bucket boundary could lose up to 2.5 points. Now piecewise linear with increasingly steep slopes that preserve the bucket values at boundaries (low fees barely penalized, extractive fees punished hard). (3) Delivery Reliability deliveryRatio thresholds linearized — same pattern, up to 2-point cliffs eliminated. (4) Time Remaining bucket thresholds linearized — smaller cliffs (max 2 points at the 14-day boundary) but still present in a small dimension; now smooth. Net Yield, MIRROR Participation, and Capacity Profile were audited and confirmed fair-as-is (already linear/continuous). Total cap unchanged at 100. No score regressions by design; the only validators whose scores move are those who happened to be sitting exactly on a previous bucket boundary.
v3.8 (2026-05-11) — Operator Quality dimension audited and rewritten after a fairness review. Three fixes shipped together. (1) Eliminated a perverse incentive — a known operator with a mid-tier FTSO score (e.g. 50) scored 4 pts, but the same operator dropping out of FTSO entirely scored 7 pts. Under v3.8 the score is max(verification baseline, FTSO-derived), so FTSO participation can only help, never hurt. (2) Introduced an intermediate verification tier — operators with auto-discovered names from Flaremetrics or FSE (but not yet in the curated KNOWN_VALIDATORS map) get +3 instead of 0, softening the previous 7→0 cliff. (3) Surfaces both signals in the breakdown detail when verification wins over a low FTSO score (e.g. “Curated operator · FTSO 45”) so operators understand exactly where their score is coming from. The 12-pt cap is unchanged; no rebalance needed because the changes only widen the score distribution at the bottom (rewarding partial verification) without changing the top.
v3.7 (2026-05-11) — Community Trust dimension audited and expanded after an operator-fairness review. Three additions: (1) Multi-node operator aggregation — operators running multiple P-Chain nodes (AU, FlareBus, Aureus Ox, Kiln, etc.) now have their delegator count and total stake aggregated for the Trust count + concentration signals, so they aren't penalized for distributing the same delegator base across multiple nodes. (2) 30-day delegation retention signal (±0.5 pt) — distinguishes growing / stable / shrinking validators using a sliding-window comparison. The snapshot-only Trust dimension couldn't tell these apart pre-v3.7. (3) 30-day self-bond trajectory (±0.5 pt) — rewards operators who increase their self-bond over time, penalizes those quietly un-bonding. Distinct from the sudden-change penalty which only catches single large drops. Cap rebalanced: Trust 10 → 11, Capacity 8 → 7. Bug fixes from the audit: (a) zero self-bond now correctly hits the sub-FIP-10 penalty (previously a `selfBondFLR > 0` gate let exactly-0 self-bond escape the −1). (b) small self-bond ratios between FIP-10 floor and 5% now render the actual percentage in the breakdown panel so operators see what closes the gap to the +1 / +2 tiers. (c) longevity bonus now wipe-immune — falls back to reward-scripts epoch presence when first-observed KV is artificially fresh.
v3.6 (2026-05-11) — Two fixes to MIRROR detection, shipped together. (a) Detection now reads from two canonical sources: on-chain RewardClaimed(claimType=3) events from the V2 RewardManager AND claimType=3 allocations in the official FSP Merkle JSON (the same data Flare's own signing tool consumes). Either signal is sufficient — catches validators whose MIRROR has been allocated but not yet claimed on-chain. (b) Cross-checking against the Merkle revealed a separate key-format bug: validators:mirror-stats had mixed hex20/cb58 NodeID keys (the on-chain indexer wrote hex when a validator wasn't yet in our curated name list), while every UI consumer looked up by cb58 only — so ~95 validators' status was invisible to the display. Lookup now normalizes both formats across the validators table, score-breakdown panel, mirror-stats public API, Yield page Staking Positions card, and FTSO providers panel. Affected validators saw their MIRROR Participation + Operator Quality dimensions and overall FlareWatch Score rise 9-10 points on the next cron cycle. Discovered via an FTSO-provider report (FlareBus, 2026-05-11) — credit and thanks. Their feedback materially improved every delegator's view of the network, not just their own scores.
v3.5 (2026-05-09) — Net Yield now median-anchored against network APR (a validator at the median scores 12/18, top performers reach 18, bottom-quartile drops to 0). Trust dimension absorbed self-bond alignment as a fourth component (proportional self-bond rewards skin-in-the-game; sub-FIP-10 floor takes a small penalty). New "NEW Xd" badge surfaces validators FlareWatch has only observed for <30 days so stakers can see when track record is thin.
v3.4 (2026-05-09) — Uptime dimension now blends instantaneous RPC uptime with historical FIP-10 epoch-eligibility ratio. Pre-v3.4 the dimension was non-discriminating (92.9% of validators had 100% RPC uptime). Reliability ratio derived from epochsUptimeEligible / epochsObserved across the last 8 reward-scripts epochs — a time-series signal that meaningfully differentiates validators who occasionally fail FIP-10 minimum conditions from those who don't.
v3.3 (2026-05-09) — Delivery dimension now uses exponentially time-weighted mean rate (recent epochs count more, decay constant 0.85) and applies a variance penalty (coefficient of variation × 0.5, capped at −30%). Computed from per-epoch reward-scripts data — sample size carries through as the existing confidence dampener.
v3.2 (2026-05-09) — Multi-signal Community Trust (count + concentration + longevity); first-observed-by-FlareWatch tracking persisted in KV for the longevity bonus; stake-end edge-case (validators within 14 days of expiry score 0 on Time Remaining since they can't accept new delegations under FIP-10); methodology page made public; operator feedback channel surfaced; algorithm version stamped on every cached score record.
v3.1 (2026-05-09) — Wired Delivery dimension from reward-scripts data; smoothed Operator Quality (linear interpolation), Capacity (tent function), and Trust (log scale); reclassified FSP-known + zero claimType=3 as MIRROR "inactive" instead of "no data"; persisted scoreBreakdown server-side so client doesn't recompute without full inputs.
v3 (2026-05-09) — Replaced binary identity bonus with continuous Operator Quality. Added MIRROR Participation as a dedicated dimension with fee passthrough. Made capped capacity neutral instead of a 0-pt penalty. Removed APY/fee double-count via Net Yield. Recalibrated bands (Top tier 90+, Strong/Good/Acceptable/Below median).
v2 (pre-2026-05-09) — Original 8-dimension score (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). Retired due to APY/Fee double-count, binary identity penalty, capped-capacity penalty, no MIRROR dimension. Documented for historical reference.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.