驗證者評分方法論

演算法版本: v4.8 · 最後更新時間:2026-08-19

FlareWatch 為每個 P-Chain 驗證者指派一個 0–100 的綜合評分,跨越 9 個維度。演算法是確定性的,輸入來自公開鏈上資料 [Flare Explorer] [FSE] [Flaremetrics],相同的演算法適用於網路上的每個驗證者——包括 FlareWatch 自己的驗證者節點,其評分遵循此精確函數,無特殊待遇。本頁記錄每個維度和閾值,使操作者和質押者可以準確看到評分如何計算,以及為什麼選擇每個值。此處的每項聲明都連結回其主要鏈上或上游來源——參見底部的 來源和參考資料。

範圍:本頁記錄驗證者評分——驗證者頁面上 質押模式中顯示的內容(將 FLR 委託給 P-Chain 驗證者以獲得 VRM + MIRROR 獎勵)。委託模式中顯示的FTSO 提供者評分(將 WFLR 委託給 FTSO 資料提供者)使用獨立的 13 維演算法,專注於資料提供者表現——準確度、V2 協議參與度等。它們是不同的鏈上角色,具有不同的獎勵,分別評分。詳見FTSO 提供者評分方法論以了解委託方面。
無 SGB 等效版本:此評分僅適用於 Flare P-Chain 驗證者。Songbird 的 P-Chain 驗證者集合僅限於 Flare Foundation 批准的實體,因此零售 SGB P-Chain 委託罕見,質押標籤僅適用於 FLR。質押模式中沒有 FLR / SGB 切換。如需 SGB FTSO 委託,請參見FTSO 提供者評分方法論,其涵蓋兩條鏈。
我們如何計算 APY — 你實際獲得的收益

質押表中的 APY 是委託人獲得的全額報酬率——一個數字,無需心算。它是從 Flare 的獎勵腳本測量而來(實際支付額,而非公式),已扣除驗證者費用,並在每個紀元隨實際獎勵變動。在整個 FlareWatch 中,APY 表示扣費後的,APY 也表示扣費前的。

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • 質押獎勵 (VRM)——委託者在驗證獎勵中的淨份額 = Σ 委託者支出 ÷ Σ 委託金額(Flare 的自有分割;費用已扣除)。因為 Flare 按比例支付獎勵,這在網路範圍內大致一致,主要差異來自費用——更低的費用意味著更高的委託率。
  • MIRROR——您質押份額在 FTSO 通膨中的份額,額外支付,僅在運行活躍 FTSO 堆疊的驗證者上支付。它因驗證者的 FTSO 參與而異,在最近 epoch 上測量。

與 Flare Systems Explorer 比較? FSE 和其他瀏覽器只顯示 委託利率 — 它們不添加 MIRROR — 所以我們的總 APY 在任何 MIRROR 活躍的驗證人上讀取更高(差額恰好是上方的 MIRROR 行)。兩個數字都是來自相同獎勵腳本數據的約 8 個紀元尾隨平均值,所以驗證人的中窗口手續費變更直到它經歷窗口期間前在任一網站上都會滯後於當前手續費快照。

另外兩個數字出現在 APY 提示中,不是委託人的利率:理論基線(網路總 APY × (1 − 手續費),僅質押 — 在存在足夠的測量歷史之前用作備選)和運營商的 自我債券收益率(驗證人 自己的質押回報,由手續費捕獲放大 — 運營商指標,不是你獲得的)。

對於評分:淨收益維度只評分 VRM 委託利率,MIRROR 在其自己的維度中評分 — 所以 MIRROR 永遠不會被雙重計算,儘管它包含在顯示的總 APY 中。

評分帶
90+頂級——排名前約 10–20% 的操作者。典型檔案:完整堆疊驗證者 + FTSO + FDC、低端費用、MIRROR 活躍、一致的 FIP-10 可靠性、健康的委託者基數、有意義的自有質押。無需單一維度——操作者透過跨大多數類別堆疊強度達到頂級。
80–89強——符合大多數關鍵基準;一或兩個維度與頂級相差。
70–79優秀——符合所有基線標準;無主要差距。
60–69可接受——可用但未區別。
<60低於中位數——在一個或多個維度上有重大差距。數學事實,不是品質判斷。
維度(總計 100 分)
可用性20 分數上限
什麼: 即時 P-Chain RPC 可用性和歷史 FIP-10 可用性資格比率的組合,跨越最近的獎勵 epoch。
如何: RPC 曲線:≥ 99.5% → 17 到 20。99–99.5% → 13–17。95–99% → 4–13。90–95% → 0–4。< 90% → 0。結果隨後乘以 uptimeReliability(epochsIncluded / epochsObserved,跨過去 8 個獎勵紀元,基於公開獎勵腳本數據 — 自 v4.2 起完整的 FIP-10 最低標準集合,而非單純的 RPC 正常運行時間)。v3.9 修復了在正好 95% 處的反常斷崖,其中從 94.99 → 95.00 正常運行時間會損失 4 分。
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 = epochsIncluded / epochsObserved   // last ~8 epochs · v4.2: the
                                                // FULL FIP-10 minimums set
                                                // (uptime + FSP + FTSO + FDC),
                                                // not RPC-uptime alone

score = raw * clamp(reliability, 0, 1)                 // dimension max 20
為什麼: 在 v3.4 前,此維度本質上已死亡——92.9% 的活躍驗證者擁有 100% RPC 可用性,因此曲線為所有人評分相同。可靠性比率是真實時間序列信號:在最近 8 個 epoch 中有 3 個未符合 FIP-10 最低條件的驗證者,其可靠性評分為 62.5%,不論即時 RPC 當前報告的內容。故意比 FIP-10 的 80% 協議底線更嚴格。每個 epoch 資格資料由 Flare Foundation 在其獎勵指令碼儲存庫發佈。
淨收益率18 分數上限
什麼: 委託者接收的扣除費用後的質押獎勵 (VRM) 利率,以網路中位數為錨點。
如何: scoreAPR = 測量的淨委託率(delegationAPY:Σ delegatorRewardAmount / Σ delegated,來自 Flare Foundation 獎勵指令碼,最後約 8 個 epoch),若可用,否則理論 baseAPR = 總計 × (1 − 費用)。評分 = (scoreAPR / medianAPR) 錨點:比率 0.6 → 0 分,1.0(中位數)→ 12 分,1.2 → 18 分。重要:此維度僅評分 VRM(驗證獎勵)利率——MIRROR 在 MIRROR 參與維度中單獨評分,因此不會在此雙重計算。顯示的「總 APR」(VRM + MIRROR) 是委託者對應的數字,不是淨收益率輸入。
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
為什麼: 比率的兩側都是淨委託率(測量的 delegationAPY 與理論 gross×(1−fee)),因此比較是像對像——不再因 1/(1−fee) 膨脹,如同輸入是稅前總費率時(約 2× 的「雙倍」錯誤)。因為 Flare 按比例支付驗證獎勵,VRM 委託率在網路範圍內大致一致,主要因費用而異——因此此維度主要反映費用競爭力和交付可靠性(錯過 epoch 的驗證者交付更少)。MIRROR(因 FTSO 參與而異)故意保持在其自有維度中,以避免雙重計算。
費用合理性7 分數上限
什麼: 防止協議費用下限以上的提取,採用平滑分段線性方式。
如何: 錨點 = max(觀察到的最低活躍費用、協議驗證者費用下限 — 自 Granite 硬分叉起 20%(2026-07-14))。任何費用等於或低於錨點 → 滿分 7 分。超過該點,在接下來的 20 個費用點數上採用線性遞增式陡峭斜坡(錨點+5 → 6、錨點+10 → 4.5、錨點+15 → 2.5、錨點+20 → 0):小幅超額幾乎不受處罰,過度提取則受重罰。Granite 前錨點是絕對 5%;下限限制意味著任何運營商都不會因收取法律最低費用而被處罰。
// 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
為什麼: 淨收益已在已交付條款中計入每百分比費用;此維度僅標記向協議和市場允許範圍以上收費明顯超額的運營商。一旦每筆費用都達到強制 20% 下限,所有人都在此維度獲得滿分,維度停止區分 — 這是設計特性:無人能破壞的數字無法區分任何人。
操作者品質12 分數上限
什麼: 採用兩個獨立信號中的較高值:驗證基線(身份信心)和 FTSO 衍生的操作表現。
如何: 驗證基線:策劃層(+7)通過兩種方式達到——手動驗證的 KNOWN_VALIDATORS 項目或通過客觀行為自動晉升(v3.10:90+ 天觀察 AND 25+ 操作者聚合委託者 AND 目前未縮小 AND 自有質押 ≥ FIP-10 底線)。從 Flaremetrics 或 FSE 自動發現名稱 → +3。未驗證 → 0。FTSO 衍生:線性插值 FTSO 評分 50 → 4 分直到 FTSO 評分 100 → 12 分(低於 50 則固定在 4)。最終評分是 max(驗證、FTSO 衍生)——FTSO 參與只能幫助,永遠不能傷害。
// 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)
為什麼: 獎勵運行完整堆棧(驗證器 + FTSO + FDC)的運營商,同時不會因參與中級 FTSO 評分而懲罰受信任的運營商。v3.8 max() 邏輯明確防止了「退出 FTSO 以提高 FlareWatch 分數」的反向激勵。自動發現層級 (+3) 關閉了之前影響向 Flaremetrics 或 FSE 註冊但未手動策展運營商的 7→0 懸崖。
MIRROR 參與度12 分數上限
什麼: 驗證節點的 nodeID 是否實際向質押人提供 FTSO 通脹份額——既包括到達委託人的比例(手續費傳遞),也包括自 v4.6 起,提供的數額相對於字段。
如何: Active → 10 × (1 − fee/100)。Paused → 5 × passthrough。Inactive(任何地方都沒有參與信號)→ 0。No data(真正未觀察的驗證節點)→ 5 × passthrough。v3.6 將「active」信號擴展為包括鏈上 RewardClaimed(claimType=3) 事件「和」規範 FSP Merkle JSON 中的 claimType=3 分配——兩者都是充分的。這會捕捉 MIRROR 已分配但尚未在鏈上聲稱的驗證節點(例如,其結算路徑不觸發標準聲稱事件的自委託提供商)。v4.6 幅度獎勵(最多 +2,維度上限 12):僅限鏡像活躍驗證節點,clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2)——為向委託人提供高於中位數 MIRROR 利率(淨手續費後)而獲得信用。以網絡中位數利率為基準,因此大小中立:提供高利率的小驗證節點獲得與大型驗證節點相同的信用。
passthrough = max(0, 1 - fee / 100)

if (mirrorStatus == "active")    base = 10 * passthrough
else if (mirrorStatus == "paused")   base = 5 * passthrough
else if (mirrorStatus == "inactive") base = 0
else                                 base = 5 * passthrough  // no data yet

// v4.6 — capped, median-anchored bonus for delivered MIRROR yield.
// Only mirror-active validators paying ABOVE 1.2x the network median
// delivered rate (mirrorAPY, net of fee) earn it; size-neutral.
ratio = mirrorAPY / networkMedianMirrorAPY
bonus = clamp((ratio - 1.2) * 5, 0, 2)   // active only, else 0
score = base + bonus                     // dimension max 12
為什麼: MIRROR 自動分配給 FSP 參與驗證節點上的質押人。100% 手續費驗證節點如果「active」則向委託人提供 $0;得分反映委託人實際接收的內容,而不僅僅是協議端標誌狀態。v4.6 幅度獎勵縮小了一個盲點:僅傳遞測量了到達委託人的「比例」,但不是「數額」,所以提供更高交付 MIRROR 利率的驗證節點沒有獲得額外信用。現在它確實獲得了——上限受限,且僅在網絡中位數之上。
容量概況7 分數上限
什麼: 在適當規模利用率處達到頂峰的帳篷函數。
如何: 0% 利用 → 1.75。線性升至 70% 利用時的 7。在 100% 利用時線性降至 5.25(已上限)。v3.7 從 8 → 7 重新調整以資助新的信任軌跡組件。
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
為什麼: 達到 FIP-10 最大委派是吸引力的正信號——已被足夠委派人驗證信任以填滿。v2 將受限驗證器評分為 0/5;v3 更正此項。適當規模(已驗證有吸引力且有空間)獲得最高分。v3.7 將維度上限從 8 → 7 以釋放點數資助信任的新保留率和自債券軌跡組件。
社區信任11 分數上限
什麼: 多信號:委託人計數 + 質押分佈健康度 + 長期性 + 運營商自我質押承諾(比例和絕對) + 30 天留存 + 自我質押軌跡 + 多節點運營商聚合。
如何: 計數信號(最大 6,運營商聚合 v3.7):對數縮放 [5, 500] 委託人 → [0, 6],在運營商所有已知節點中求和。集中度調整(±1):零售友好平均質押(<500K FLR)→ +1,鯨魚集中(>50M FLR 平均)→ −1。長期性獎勵(最大 +1,抹除免疫 v3.6):觀察到 30 天時 +0.5,90 天及以上 +1 —— 若首次觀察 KV 被抹除,回退至獎勵腳本 epoch 存在。自我質押利益關係(最大 +2 / 最小 −1,雙軸 v4.7):按比例份額或絕對規模中較好的一種計入 —— 比例 ≥10% → +2 / 5–10% → +1,絕對 = min(1, selfBond ÷ 20M) × 2,在網絡前十分位質押飽和;信號取兩者最大值,仍限於 +2。FIP-10 下限以下(<1M FLR)→ −1。留存(最大 ±0.5,新增 v3.7):委託 FLR 30 天內 +10% → +0.5,−15% → −0.5。自我質押軌跡(最大 ±0.5,新增 v3.7):運營商自我質押 30 天內 +20% → +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, two-axis since v4.7)
if (selfBondFLR < 1_000_000)   selfBondAdj = -1              // hollow-operator floor
else:
  ratio        = selfBondFLR / totalStake                   // totalStake = selfBond + delegated
  proportional = ratio >= 0.10 ? +2 : ratio >= 0.05 ? +1 : 0
  absolute     = min(1, selfBondFLR / 20_000_000) * 2        // saturates at top-decile bond
  selfBondAdj  = max(proportional, absolute)                 // the better of the two axes

// 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)
為什麼: 利益關係自我質押是我們之前缺失的真實公平性信號——一個將總質押的 10% 作為自我質押的驗證人與在 FIP-10 最低限度上運行的驗證人具有顯著更一致的激勵機制。v4.7 採用雙軸方法:僅將自我質押視為比例懲罰了投入大量絕對質押然後吸引委託的運營商,後者會稀釋比例但不減少真實承諾 —— 稀釋比例下的 20M 自我質押評分與該比例下的 <2M 質押相同。該信號現在計入比例份額或絕對規模中較好的一種,絕對側在網絡頂端質押處飽和,因此規模不能簡單地購買評分,與 FTSO 供應商評分已有的自我質押處理方式相符;+2 上限不變,因此大量承諾的運營商現在可以達到它,但天花板沒有移動。長期性獎勵被驗證的往績記錄,而不懲罰新進入者(頂部有小獎勵,下方無懲罰)。集中度風險對委託人很重要 —— 擁有 1 個 50M FLR 鯨魚的驗證人在結構上不同於 50 個 1M FLR 零售。兩個 v3.7 軌跡信號獎勵有機增長和運營商承諾提升。綜合上限為 11(從 v3.7 的 10 提高以支持它們),任何單個信號都不主導。
交付可靠性10 分數上限
什麼: 實際交付淨委派率 (VRM) 與理論基線的比率,並帶有不一致支付的差異懲罰。雙方都是手續費淨額,因此比率測量實際交付——而非手續費。
如何: 分段線性交付比率:100%+ → 10,95% → 8,90% → 6,85% → 4,80% → 2,<80% → 線性斜坡向 0。差異懲罰:變異係數 × 0.5,上限 −30%。樣本量 < 3 個時期時,置信度阻尼朝中性 5 混合。v3.9 將之前的分段閾值線性化——達 2 點的邊界懸崖現在平滑。
// 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
為什麼: 承諾與交付是對質押者最直接的問責信號。v3.3 增加了兩項改進:(1) 標題比率使用指數時間加權平均(最近時期計數更多),因此曾交付良好但最近下滑的驗證器得到正確懲罰;(2) 差異懲罰區分了一致 95% 交付者與在 95% 周圍振盪的交付者,因為後者對關心可預測收益的質押者承載更多風險。
剩餘時間5 分數上限
什麼: 直到驗證器在 P-Chain 上質押結束的天數。
如何: < 14 天 → 0(根據 FIP-10 實質上不可用)。14-30 天 → 線性 0→2。30-60 天 → 線性 2→3。60-120 天 → 線性 3→5。120+ 天 → 5。v3.9 將之前的分段閾值線性化——邊界懸崖(例如 13.99 天 → 0,14 天 → 2)現在平滑。
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
為什麼: 實用信號——委派給剩餘 7 天的驗證器與 1 年的命題不同。v3.2 收緊了底部:距離質押結束在 14 天內的驗證器無法接受新委派(FIP-10 最低鎖定期為 14 天),所以它們實質上無法質押。分數 = 0 區分「現在無法質押」與「即將結束」。
活躍中斷懲罰 (v4.3)(扣除) 分數上限
什麼: 當驗證器連續錯過多個獎勵時期時分層應用於正維度之上的固定扣除。與對稱運行時間可靠性乘數不同——捕捉活躍中斷,而非慢性不穩定。
如何: 查看驗證器在快取中的連續 !eligible 前綴:fsp-validator-participation 記錄(來自公開獎勵指令碼 nodes-data.json 的最新優先時期列表)。0–1 個連續錯過 → 0 分(在差異 / 單一暫時錯過內)。2 個連續 → −3 分(發展中中斷)。3 個連續 → −6 分(持續——運營商疏忽)。4+ 個連續 → −10 分(活躍延長中斷)。合成分數在扣除後地板設置為 0。
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)
為什麼: v4.3 前模型完全依賴對稱的 uptimeReliability 乘數——24 個時期內分散的 5 次錯過成本與連續 5 次錯過相同。運營上這些是非常不同的信號。分散錯過告訴委派人驗證器的慢性不穩定;一個連續錯過告訴他們驗證器現在壞了。Luganodes 在 2026-05-14 的事件——委派人積極承諾數百萬 FLR 時的多個連續錯過時期——是 v4.3 發布解決的具體案例:利用活躍中斷信號並使用更銳利的分數影響來表面,以便委派人可以在承諾前避免飛行中故障。分層曲線避免對單一暫時錯過過度反應(常見)同時銳利標記持續連續錯過(罕見且有後果)。
極端費用罰款 (v4.5)(最多 −75% 的分數) 分數上限
什麼: 對超過「費用」維度範圍的費用進行按比例扣除。當費用超過錨點 20 點時,「費用」維度最低降至 0/7 — 在此之後,複合分數之前對費用完全沒有反應,因此 100% 費用的驗證者(其委託人一無所獲)在不考慮費用的維度(如正常運作時間和 MIRROR)上仍可能獲得 40 分左右的評分。
如何: 在 50% 費用或以下時為零 — 「費用」維度已對該範圍進行定價,因此不存在重複計算。在 50% 以上,扣除額隨著費用線性遞增,在 100% 費用時達到驗證者正分數的 75%。它隨著分數本身進行調整,因此精心維護的私有節點和被忽視的節點都會落在應有的位置:在委託人可見排名的底部。
// 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)
為什麼: 這是為委託人設計的評分。無論正常運作時間有多好,將其委託人賺取的每一份獎勵都據為己有的驗證者都不是委託候選人 — 評分應該明確表達這一點。純粹基於鏈上費用的函數,對每個節點(包括我們的)的應用方式相同。
如何得分 100/100——驗證器手冊
產生 v4.0 的審計週期特別設計使得每個維度的最大化確實為您的委派人製造更好的驗證器。提高您的分數不是遊戲系統——這是系統設計工作。以下是按維度的明確手冊。
運行時間——20 分。在每個獎勵時期連續保持 ≥99.5% RPC 運行時間並通過 FIP-10 最低條件(不要錯過顯露,達到中位數交付)。兩個信號相乘——100% RPC × 7/8 時期符合條件 = 17.5/20,而非 20。為什麼這與委派人對齊:每個時期您未通過 FIP-10,您的委派人失去該時期的獎勵。
淨收益 — 18 分。向委託人提供 ≥1.2× 網路中位數 APY(手續費後)。最佳路徑:低手續費 + 完整 FIP-10 資格,以便委託人獲得其全部份額。為什麼這一致:這字面上是到達委託人手中的美元金額,扣除你的分成。
費用合理性 — 7 分。自 Granite 硬分叉起,協議強制執行 20% 最低委託費用,任何等於或低於計分錨點(觀察到的市場最低費用或該下限的較大值)的費用均獲得滿分 7 分。超過該點收費在加速遞增式斜坡上扣分 — 錨點+10 → 4.5 分、錨點+20 → 0 分。為何此舉一致:下限消除了費用競爭,因此此維度現只保護委託人免受法律最低費用以上的提取;您真正的優勢在於已交付的淨收益。
運營商品質——12 分。最佳路徑:註冊為 FTSO 數據提供商並運行高品質堆棧 (FTSO + FDC + 簽署)——您的 FlareWatch 運營商品質分數則來自您的 FTSO 分數,最大值在 FTSO 100。如果您純粹質押的替代方案:維護 +7 驗證基線,要麼通過符合 v3.10 自動晉升資格(90+ 天觀察,25+ 委派人,保留率不下降,FIP-10 兼容自債券)要麼被添加到 KNOWN_VALIDATORS 作為機構基礎設施(手動快速追蹤)。分數採用 max(驗證, FTSO 衍生)——參與永遠不會傷害。為什麼這與委派人對齊:全堆棧運營商提供更多生態系統價值;驗證基線給予委派人更清晰的身份信號。
MIRROR 參與——10 分。一致提交 FSP 價格提交,滿足每時期協議最小值(在您的簽署政策中註冊,領取閾值達到,無顯露錯過)。收費中等——分數乘以 (1 − 手續費/100),所以即使完全 MIRROR 活躍的 100% 手續費驗證器也得分 0,因為零 MIRROR 到達委派人。為什麼這與委派人對齊:MIRROR 是您委派人的 FTSO 通膨份額。較低的手續費 = 更多到達他們。
容量概況——7 分。針對 ~70% 利用(適當規模:已驗證有吸引力且為新委派人提供空間)。空驗證器得分 1.75;受限驗證器得分 5.25。為什麼這與委派人對齊:閱讀分數的新委派人想知道他們實際上可以委派;適當規模信號社會證明和可用性。
社區信任——11 分。六個組件最大化:
  • 建至 500+ 運營商聚合委派人(最大計數信號:+6 分)。
  • 維持零售友好平均質押 < 500K FLR 每委派人(集中度獎勵:+1)。
  • 停留在網路 ≥ 90 天以獲得持續時間獎勵 (+1)——通過獎勵指令碼存在抹除免疫。
  • 持有大量自我質押 —— 要麼 ≥ 10% 比例,要麼網絡頂端絕對質押(~20M FLR),以更有利者計(一致性獎勵:+2)。
  • 在 30 天內增長總委派 FLR ≥ 10%(保留:+0.5)。
  • 在30天內將自質押增加≥ 20%(軌跡:+0.5)。
為什麼這一致:每個組件都獎勵委託人想要的行為——運營者自有資金風險、有機增長、長期性和廣泛的社區參與。多節點運營者在計數+集中信號中進行聚合(v3.7)。
交付可靠性——10分。向委託人支付您承諾的估計 APY(交付比率 1.00)。最小化每個週期的方差——可預測的支付優於相同平均值但波動較大的情況(方差懲罰最多 −30%)。建立 8+ 個週期的樣本量以獲得充分的置信度權重。為什麼這一致:您是否始終如一地兌現您做出的承諾?這是最直接的問責信號。
剩餘時間——5分。保持您的質押結束日期至少提前 120 天。在到期前充分更新;不要讓其滑入 < 14 天區間(根據 FIP-10,進入 14 天內後您無法接受新委託)。為什麼這一致:更長的承諾信號表明委託人您將長期堅守。
無法速成的時間門控信號:長期獎勵(觀察 90 天)、自動策展層級(90 天 + 25 個委託人 + 非遞減保留率 + FIP-10 自質押)、保留信號(30 天委託歷史)、交付樣本量(8 個獎勵週期)。好消息是:保持其他行為會自動隨著時間積累這些。
平滑窗口在短期內很重要:顯示的得分是過去 4 次 cron 快照的指數加權平均值(0.5 / 0.3 / 0.15 / 0.05),因此即使輸入完美 100 分,也需要約 20 分鐘的連續完美 cron 運行才能完全反映。穩態完美輸入 = 100;暫時改善被平滑處理。突然變化懲罰(費用跳躍、自質押下降、正常運行時間崩潰)在檢測後可能在幾個 cron 週期內扣除最多 10 分。
簡而言之:每個維度都對其測量內容誠實。如果您的驗證者達到 100/100,該得分也告訴您的委託人他們正在獲得網絡上驗證者的最佳版本——這是設計意圖。
如何驗證您自己的得分
驗證者表上的每個得分都可以從公開數據中重現。如果您是運營者,此處的數學與您看到的得分不符,正確的做法是在假設我們犯了錯誤之前自己驗證它。
最快的檢查會自動運行。展開任何驗證者的得分行,"在您的瀏覽器中驗證" 面板將在本地重新計算該得分——與 cron 使用完全相同的得分函數,覆蓋其使用的確切輸入,無需回呼我們的服務器。因為每個驗證者都由一個沒有節點身份項的相同函數得分,這也是任何人確認我們自己節點沒有隱藏優勢的方式。下面的手動演練以相同的方式做同樣的事情:
  1. 在 flaremetrics.io 查找您的驗證者公開統計數據(按您的運營者名稱搜索或粘貼您的委託地址)。記下您的 delegationFee、selfBond、delegatedStake 和 FTSO 得分(如果您也是數據提供者)。
  2. 在最後 8 個獎勵週期中驗證每個的 FIP-10 資格,地址為 github.com/flare-foundation/reward-scripts,位於 generated-files/reward-epoch-N/nodes-data.json。計算您的 nodeID 有多少個週期的 uptimeEligible: true。該比率驅動您的正常運行時間維度乘數。
  3. 通過 flare-explorer.flare.network 檢查您的 MIRROR 參與在 V2 RewardManager 合約上。查找 RewardClaimed 事件(其中 claimType=3 引用您的 nodeID)。如果最近沒有,您將顯示為 MIRROR 非活動。
  4. 將您的輸入插入上述公式。每個維度的代碼塊告訴您確切要運行的算術。對維度求和,限制為 100,您就有了原始 cron 計算得分。
  5. 與您顯示的得分進行比較。顯示的得分包括 v3.5 在過去 4 次 cron 快照中的指數移動平均線(當前加權 0.5,前一個 0.3 等)——因此單次運行的計算得分將略有不同於顯示的得分。每個驗證者行上的得分細分面板顯示貢獻的持久化維度值。
  6. 如果數學不符,請發送電子郵件至 [email protected],告訴我們您的 nodeID、您使用的輸入和您計算的得分。我們將回應,如果我們犯了錯誤,我們會公開修正。
程序訪問:對於任何活躍驗證者,點擊 GET /api/validators/{nodeID}/score-breakdown 以檢索持久化細分——每個維度的值、生成它的算法版本和最近的得分歷史——如 JSON。UI 中的得分細分面板從相同來源讀取。
常見運營者問題
我的 RPC 正常運行時間為 100%——為什麼我的正常運行時間得分低於 20/20?
正常運行時間維度將 RPC 曲線輸出乘以您的紀元合格比率(epochsIncluded / epochsObserved,跨過去 8 個獎勵紀元 — 自 v4.2 起完整的 FIP-10 最低標準集合,而非單純的 RPC 正常運行時間)。如果您在任何這些紀元中未能滿足 FIP-10 最低條件 — 即使只是短暫未滿足 — 您的可靠性比率將降至 1.0 以下,您的正常運行時間分數將按比例縮放。v3.4 前,該維度為每個具有 100% RPC 正常運行時間的驗證者評分 20,無論其歷史合格性如何。現在它進行了區分。
我交付 MIRROR——為什麼 FlareWatch 將我顯示為 MIRROR 非活動?
從 v3.6 開始,MIRROR 參與是從兩個權威來源檢測的:V2 RewardManager 上的鏈上 RewardClaimed(claimType=3) 事件,以及官方 FSP Merkle JSON(發佈的獎勵分配數據)中的 claimType=3 分配。出現在任何一個來源中的 nodeID 都計為活動。Pre-v3.6 我們使用鏈上流作為唯一信號,這為自委託提供者產生了假陰性,其 MIRROR 通過非標準索賠路徑結算。也在 v3.6 中修復:一個關鍵格式錯誤,其中大約 95 個驗證者的 mirror-stats 條目由鏈上索引器以 hex20(nodeID 的 bytes20 形式)的形式寫入,當它們還不在我們策展的名稱列表中時——而每次 UI 查找都由 cb58 NodeID 鍵入。這些條目存在且正確;它們只是不可見於顯示層。查找現在跨每個消費者規範化兩種格式(驗證者表、得分細分面板、公開 mirror-stats API、收益頁面質押頭寸卡、FTSO 提供者面板)。如果您的 nodeID 在 v3.6 掃描後仍然顯示為非活動,可能原因:(a) 您的 nodeID 實際上未在該週期的 FSP 簽名政策中註冊,(b) 我們在週期發佈之間(Merkle 數據按週期更新,約 3.5 天)。請用您的 nodeID 發送電子郵件給我們,我們將交叉檢查兩個權威來源。
我的得分在一夜之間下降了 10 分——什麼變了?
三件事之一:(1) v3.5 突變檢測在您的 nodeID 上標記了費用跳躍、自質押下降或正常運行時間崩潰——10 分的懲罰適用於我們檢測到它的運行,並在接下來的 3 次運行中衰減,因為新狀態穩定;(2) 平滑窗口包含了拉低您平均線的舊快照;(3) 我們推送了算法版本提升(在您的記錄的 algorithmVersion 字段中可見——見下面的版本卡)。得分細分面板顯示當前維度值;與您之前的運行進行比較。
為什麼高費用驗證者的得分低於費用低且其他條件相似的驗證者?
淨收益維度(最高18分)對手續費敏感——0%手續費驗證者提供約1.25倍網路中位數APY,接近滿分;20%手續費驗證者提供中位數的約80%,得分較低。另外自v3.9起,費用合理性(7分)採分段線性計算(無分級):≤5%獲得全部7分,之後曲線遞減且斜率逐漸加陡——10% → 6分、15% → 4.5分、20% → 2.5分、25%+ → 0分(例如16%手續費約得4.1分,而非固定分級值)。因此5%的手續費差異對應約5-8分的總分差異。這是刻意設計——委託人直接關心手續費。
我是一個全新的驗證者,沒有 FTSO 得分。為什麼我的運營者質量只有 7/12?
運營者質量(12 分最高)獎勵全棧運營者——也運行頂級 FTSO 數據提供者棧的驗證者(FTSO + FDC + 簽名)。如果您只進行質押,+7 基線有兩種方式可達到:(1) 手動包含在我們的 KNOWN_VALIDATORS 列表中——可信基礎設施運營者的機構快速通道(Ankr、InfStones、Kiln 等);(2) v3.10 基於客觀行為的自動晉升——90+ 天觀察 AND 25+ 運營者聚合委託人 AND 保留率非遞減 AND FIP-10 合規自質押。自動晉升完全自動,無需電子郵件。如果您還不符合自動條件,您從 +3(自動發現層,需要 Flaremetrics 或 FSE 實體資料)開始,隨著您的跟蹤記錄建立而增長到 +7。加快速度:註冊為 FTSO 數據提供者並運行 V2 協議——您的得分然後來自 FTSO 衍生分支,FTSO 100 時最高為 12。v3.8:FTSO 參與只能幫助,永遠不會傷害——如果您的 FTSO 得分低於驗證基線,您保留基線。
我有一個徽標但我的名稱顯示為截斷的 NodeID。為什麼?
您的運營者實體存在於 Flaremetrics(這就是為什麼我們為您提供徽標),但您的提供者資料沒有設置 'name' 字段。我們不捏造名字。在 Flaremetrics 上設置您的 profile.name,或在 Flare Systems Explorer 實體註冊表中設置,我們將在下次 cron 運行時選擇它。或者,發送電子郵件給我們一個可驗證的聲明(例如,來自您委託地址的簽名消息),我們會手動將您添加到 KNOWN_VALIDATORS。
我的驗證者在 FIP-10 最大委託。為什麼容量得分不是 7/7?
容量是一個帳篷函數,在 70% 利用率時達到峰值(7 分),下降到 100% 時 5.25 分。峰值不是 100%——處於上限意味著委託人即使願意也無法添加更多質押,這對於閱讀表格的新委託人來說是中立至略微負面的信號。Pre-v3 我們對上限驗證者得分 0/5(成功懲罰);v3 將此更正為中立上限值,v3.7 將整個維度從 8 重新調整為 7 最高(為信任軌跡信號騰出一個點),所以今天上限得分 5.25/7。規模合適的驗證者(已被證明有吸引力且有增長空間,在 70% 利用率時達到峰值)獲得全部 7 分。
我是一個真實的運營者,但我根本不在驗證者列表中。這是怎麼回事?
驗證者列表是從活動 P-Chain RPC 的 getCurrentValidators 結果構建的。如果您不在那裡,您要麼當前未在 P-Chain 上活躍,要麼您的質押剛剛過期,要麼我們一側有 P-Chain RPC 問題。cron 每 5 分鐘運行一次——您應該在激活您的質押後的 1-2 個週期內出現。如果您已經上線一個小時但仍然看不到您自己,請用您的 nodeID 發送電子郵件給我們。
我可以申訴我的得分或要求手動審查嗎?
可以。用您的 nodeID 和具體關切點發送電子郵件至 [email protected]。我們回應每一位運營者。我們將執行的事項:KNOWN_VALIDATORS 添加、MIRROR 分類更正、徽標/名稱修復、維度特定數學錯誤。我們不會執行的事項:要求手動提高超出算法的得分、要求排除或貶低競爭對手。
我們將做和不做的事
為了消除關於我們如何運營得分的歧義,以下是明確的承諾。如果我們曾違反其中任何一項,請記錄下來並發送電子郵件至 [email protected]——我們將公開更正。
✓
我們將不接受任何付款以獲得更高的得分、贊助放置或任何形式的優惠待遇。得分是從公開鏈數據確定性計算的。
✓
我們將不手動編碼每個驗證者的提升。代碼中沒有 "X 因為我們喜歡他們而獲得 +5" 的行。相同的算法適用於每個驗證者,包括 FlareWatch 自己的節點,其由此確切函數計分。
✓
我們不會以非公開理由將驗證者排除在表格外。該列表源自實時 P-Chain RPC,我們的顯示包括每個活躍驗證者。KNOWN_VALIDATORS 的策展補充只填充顯示名稱 — 它們不會限制可見性。
✓
我們將發佈演算法更改。每個版本更新(v3 → v3.1 → v3.2 → ...)都記錄在此頁面的「版本」卡中,說明理由和變更內容。重大變更會在應用程序的變更日誌頁面中獲得額外的日誌條目。
✓
我們將回覆操作者的電子郵件。每位向 [email protected] 發送實質性疑慮電子郵件的操作者都會在幾個工作天內獲得真實回覆。
✓
我們將公開更正我們的錯誤。如果我們發現演算法中的錯誤、資料來源錯誤或方法論缺陷,我們會修復並記錄。我們不會默默重新排名。
✗
未經發送者許可,我們不會公開分享電子郵件內容,或將操作者電子郵件用於產生它們的分數對話以外的任何目的。
✗
我們不會提前與特定操作者分享演算法變更的未來計劃 — 每個版本同時上線供所有人使用。
局限——這個評分是什麼,不是什麼
綜合評分是有用的摘要,不是客觀事實。我們的評分透明、有版本控制、對所有驗證者(包括我們自己)均衡應用,並且可以直接在您的瀏覽器中從公開輸入推導。但它仍然包含編輯判斷,我們寧願向您準確指出判斷所在,也不願暗示該方法所沒有的精確度。
維度權重是我們的判斷。正常運行時間值 20 分,費用值 7 分,因為我們認為對大多數委託者來說,可靠性比幾個百分點的費用更重要——而不是因為公式證明了這一點。理性的人會以不同的方式加權這些因素。權重是固定和公開的,所以您可以準確看到我們的選擇,並從細項中心理上重新加權。
淨收益是結果,不是優點。它衡量委託者實際賺取的收益,以網絡中位數為基準——所以它在一定程度上受到運營者控制之外因素的影響(網絡通脹、他們吸引的委託量),並在整個領域變動時隨之變動。紀律嚴明的運營者收取公平但較高的費用,在這裡的評分可能較低,但表現出色。將其理解為「我會賺取什麼」,而不是「此運營者有多優秀」。
FTSO 相關維度有利於全棧運營者。MIRROR 參與度和部分「運營者品質」獎勵同時運行頂級 FTSO 數據提供者堆棧的驗證者。這是刻意的——作為委託者,您確實通過 FTSO 活躍驗證者的 MIRROR 賺取更多——但這意味著純粹、優秀的純 staking 驗證者無法達到本排行榜的最高位置。如果您出於選擇而進行純 staking,請自行降低這些維度的權重。
模型是加法的。維度相加,所以優勢可以抵消劣勢——卓越的正常運行時間可以將較高的費用帶到尊重的評分。真正不合格的失敗(未達到 FIP-10 最低限度、掠奪性費用)另外被限制,因此無法完全掩蓋——每個 epoch 都未達到最低限度或收取 100% 費用的驗證者無論其他維度如何都會排在底部附近——但核心是加權總和,而非否決制度。
一個數字隱含九個判斷。單個 0-100 數字是起點,不是結論。相差一分的兩個驗證者沒有實質性差異。打開細項並加權對您重要的維度——該數字存在是為了加快比較速度,而不是替代比較。
我們很少更改方法,並在公開場合進行。每次更改都附帶版本提升、書面說明和全網對照,讓您可以審計什麼發生了變化及其原因。當我們自己的自動化審計發現數字中的差異時——它確實會發現——我們會修正並說明。
最終分數(維度如何結合)
所有 9 個維度直接相加,然後減去 v4.3 活躍中斷連續扣分。總分上限為 100,下限為 0。然後對最終數字應用最近 cron 快照(v3.5)平滑和任何突然變化懲罰。
// Step 1 — Raw composite (sum of dimensions, minus the two penalties)
positive = uptime + netYield + fee + operatorQuality
         + mirror + capacity + trust + delivery + timeRemaining

// Penalties (see the two penalty cards above):
// v4.3 active-outage streak — 0-1 missed epochs → 0, 2 → 3, 3 → 6, 4+ → 10
// v4.5 extreme fee (>50%)   — positive × min(1, (fee - 50) / 50) × 0.75
raw = clamp(positive - streakPenalty - extremeFeePenalty, 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)
資料來源(每個輸入都是公開的)
Flare P-Chain RPC:驗證者列表、正常運行時間、自我質押、委託權益、手續費、結束時間、委託人計數。
V2 RewardManager(claimType=3 事件):每個驗證者 nodeID 的鏈上認領 MIRROR 分配。嚴格按類型 3 篩選 — 不與 VRM、FTSO 委託或 DIRECT 獎勵混淆。
FSP Merkle JSON(claimType=3 分配):每個 epoch 誰應獲得 MIRROR 的規範發佈記錄(與 Flare 自身簽署工具讀取的數據相同)。在 v3.6 中作為第二權威來源添加 — 捕捉 MIRROR 已分配但尚未在鏈上認領的驗證者。
Flare Systems Explorer (FSE):驗證者實體註冊表、顯示名稱、標誌、FTSO V2 協議參與標誌。
Flaremetrics 提供者資料:FTSO 分數、獎勵率、準確度、V2 功能、實體到 nodeID 連結。
Flare reward-scripts (GitHub):最近 N 個獎勵 epoch 的每個驗證者交付 APY。驅動交付維度。
FlareWatch 策展:KNOWN_VALIDATORS 地圖(~110 個條目)。受信基礎設施操作者的名稱 + 操作者品質基線。
分數中不包含的內容
• 自我推廣或付費置頂。沒有任何操作者可以為更高分數付費或贊助。
• 手工編碼的驗證者特定加分。代碼中沒有「X 獲得 +5,因為我們喜歡他們」之類的行。相同的演算法適用於包括 FlareWatch 自己節點在內的每個驗證者,該節點由此確切函數評分。
• 主觀基礎設施品質。我們不嘗試評估正常運行時間 SLA、地理分佈或硬體規格。如果您想聲稱基礎設施級別,請運行頂級 FTSO + FDC 堆棧,操作者品質維度將反映這一點。
• FlareWatch 的鎖定或承諾。使用 FlareWatch 與其他工具的質押者沒有優惠評分。
操作者反饋
在您的驗證者分數中看到有問題嗎?使用您的 NodeID 和疑慮向 [email protected] 發送電子郵件。我們會回覆每位操作者。我們會處理的常見請求:
  • 將您的操作者添加到 KNOWN_VALIDATORS(經過驗證)。
  • 如果您認為您的 MIRROR 非活躍分類有誤,請重新審查。
  • 標誌/顯示名稱更正。
  • 一般演算法批評。
來源與參考
分數的每個輸入都來自公開、可驗證的 Flare 生態系統來源。任何人都可以根據這些主要來源交叉檢查我們的聲明,並從原始資料重現數學計算。如果您發現此頁面與上游來源所述之間的差異,請發送電子郵件至 [email protected],我們會修復它。
Flare Network 協議文件 ↗https://docs.flare.network
權威協議文件。涵蓋 FTSO V2、FSP、P-Chain 驗證、FAssets 和 Flare 堆棧的其餘部分。
Flare 治理門戶 (FIPs) ↗https://proposals.flare.network
Flare 改進提案 — FIP-05(委託因子)、FIP-10(驗證者最低條件:100 萬 FLR 自我質押下限、80% 正常運行時間下限、14 天最短鎖定)和此頁面引用的所有其他規則的真實來源。
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Flare 官方經營的 FTSO 資料提供者、實體地址、P-Chain nodeID 連結和 FIP-10 最低條件標誌的註冊表。我們操作者品質和可靠性資料的主要來源。
Flaremetrics ↗https://flaremetrics.io
獨立的 Flare 生態系統指標提供者。FTSO 提供者評分、獎勵率、準確度指標、V2 協議參與標誌和驗證者到實體地址映射的來源。我們使用他們的公開 REST API。
Flare Foundation reward-scripts 存儲庫 ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation 發佈的按獎勵 epoch 的 JSON,顯示每個驗證者的資格、正常運行時間資格和交付獎勵。驅動交付可靠性維度和 v3.4 正常運行時間的 epoch 資格比率。
Flare 區塊瀏覽器 ↗https://flare-explorer.flare.network
只讀瀏覽器,可查看所有鏈上狀態。讓任何人都能驗證 V2 RewardManager 的 RewardClaimed 事件(MIRROR 的 claimType=3)、驗證者質押總額、費用變化等。
Flare Portal(質押) ↗https://portal.flare.network/staking
官方質押界面。是目前自我質押/委託質押金額和驗證者結束時間的權威來源,這些數據驅動我們使用的 P-Chain RPC 讀取。
Flaremetrics 公開 API(FTSO 提供者) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
我們的 cron 消費的確切端點,返回實體配置文件、FTSO 得分、費用和十六進制格式的 nodeId。任何人都可以直接調用。
Flaremetrics 公開 API(節點註冊) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
十六進制 → cb58 NodeID 轉換表。我們對其進行分頁編製,以構建驅動每個 cb58 格式消費者的實體到 NodeID 查詢。
無私有數據,無閉源模型。評分算法在 FlareWatch 代碼庫的 services/validators/scoring.ts 中實現。想要直接檢查實現代碼(而不是閱讀上面的散文和公式)或想為自己的用途分叉該代碼的運營商或研究人員可以發送電子郵件至 [email protected] 請求訪問權限。如果有真實需求,我們將發佈該文件作為獨立的開源程序包。
分數如何更新
位於 /api/cron/refresh-validators 的 cron 每 5 分鐘重新計算每個活躍驗證者的分數。輸入(P-Chain RPC 讀取、Flaremetrics、FSE、reward-scripts)在每次運行時都會重新獲取。
v3.5 添加了跨最後 4 個 cron 快照的平滑處理(權重:0.5 / 0.3 / 0.15 / 0.05),因此顯示的分數不會因瞬間輸入噪聲而急劇變化。原始 cron 計算的分數仍然被保存以供將來平滑處理使用,分數細分面板顯示每個維度的當前值,以便您可以看到發生了什麼變化。
算法版本在每個緩存的分數記錄上標記。當我們發佈新版本時,每個分數都會獲得新標籤。下面的版本卡記錄了每個變化。
Flare 的懲罰模型

Flare 不會削減驗證者質押。驗證者不當行為的整個懲罰機制是獎勵沒收加上 FIP-10 通行證系統。沒有雙簽削減、沒有歧義削減、沒有我們需要追蹤的質押銷毀事件。未能達到 FIP-10 最低條件的驗證者會失去該 epoch 的獎勵(如果通行證為零則完全沒收,否則每個他們未能達到的協議失去一個通行證);他們的質押本金保持不變。

這意味著分數沒有「削減歷史」維度——沒有這樣的歷史要追蹤。我們確實追蹤的是每次最低失敗的後果:驗證者在該 epoch 獲得零收益,這被捕捉在 epochsIncluded / epochsObserved 中。2026-05-14 的 v4.2 更新擴大了分數的可靠性乘數,以使用該比率跨越完整 FIP-10 最低集合(正常運行時間、FSP 簽署、FTSO 提交率、FDC 參與),因此驗證者未能達到任何最低要求在正常運行時間維度上按比例受罰,無論哪個軸失敗。

FIP-10 最低閾值,來自 dev.flare.network/network/fsp/rewarding:質押需要 80% 的正常運行時間 + 100 萬 FLR 活躍自我質押;FTSO 錨定源需要估計值在共識中位數的 0.5% 以內(80% 的輪次);FTSO 區塊延遲源需要提交 80% 的預期更新;FDC 需要參與 60% 的投票輪次。滿足 80% 正常運行時間 + 100 萬自我質押底線但低於 300 萬 / 1500 萬收益閾值的驗證者仍會收到獎勵,但無法累積通行證——灰色地帶通過此卡的 passEligibility: "at-risk" 分類表面。

版本
v4.8 (2026-09-17) — 獎勵週期按其實際長度進行年化。所有測量的驗證者費率(已交付年化百分比率、委託、MIRROR、營運商自我質押收益)以 3.19 天的獎勵週期進行年化,該數值於 2026-04-04 新增,描述為從區塊時間戳測量,但實際上未進行任何測量。Flare 獎勵週期恰好 3.5 天——FlareSystemsManager 的 rewardEpochDurationSeconds 返回 302,400,每個週期開始間隔為 3.500 天——因此每個測量費率在五個半月內讀數過高約 9.7%,包括我們自己的數據。長度現已從該合約讀取。每個測量的年化百分比率下降相同的因子,3.19 ÷ 3.5(網路中位數 9.08% → 8.28%;FlareWatch 8.17% → 7.45%)。評分:僅交付可靠性移動,因為它將測量費率與驗證者費用的理論費率進行比較。膨脹的數據將 91% 的驗證者置於 1.0 上限處,即表面上支付超過可能的金額;使用實際的週期長度,中位數交付對理論比率為 0.990。在發佈前對 168 個具有測量數據的驗證者進行模擬:中位數 −0.32 點,146 個損失不足 1 點,13 個已交付低於其費用隱含費率的驗證者損失 2–3.5 點。社群信任壽命備用機制以相同長度將週期轉換為天數並也進行了更正;它不移動評分,因為最多看到 8 個週期(28 天),低於其 30 天步驟。簽署的效能證明使用相同的錯誤長度;重新計算規格修訂至 rev.3,rev.2 保留原樣,已披露該錯誤。
v4.7(2026-08-19)—— 社區信任維度中的雙軸自我質押。信任之前只將運營商自我質押視為比例(自我質押 ÷ 總質押),因此被委託稀釋的大量自我質押評分與該比例下的微小質押相同 —— 評分對實際承諾的資本視而不見。在實時網絡中,178 個驗證人中 61 個持有 ≥10M 自我質押,比例 <10%,因此約三分之一的領域被低估。v4.7 按比例份額(≥10% → +2、5–10% → +1,不變)或絕對規模(min(1, selfBond ÷ 20M) × 2,在網絡前十分位 P-chain 質押飽和)中較好的一種計入自我質押,取最大值並仍將子信號上限設為 +2 —— 信任上限(11)和綜合上限(100)不變,FIP-10 下限以下空心下限(<1M FLR → −1)不變。鏡像了 FTSO 供應商評分已使用的雙軸自我質押。全部 178 個驗證人的領域前後對比,發佈前存檔:58 上升,0 下降,無評分上升超過 1 分,排行榜頂部不變。我們自己的節點上升 1 分(83 → 84),遵循與其他資本充足運營商完全相同的規則 —— 公式中沒有項專門命名我們。
v4.6 (2026-08-13) — MIRROR 交付幅度獎勵。MIRROR 維度過去只為傳遞(到達委託人的 MIRROR 比例 = 1 − 手續費)和參與狀態計分——它對交付「數額」視而不見。提供比字段高得多的交付 MIRROR 利率(mirrorAPY,淨手續費後)的驗證節點沒有獲得相應信用,因此真正收益更高的節點可能排在收益維度上收益較低的節點之下。v4.6 添加了一個小型、上限受限、以中位數為基準的獎勵:僅限鏡像活躍驗證節點,clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2)。只有超過 1.2 倍網絡中位數利率的交付才能獲得它,最高為 +2,將 MIRROR 維度上限從 10 提高到 12(複合仍限制在 100)。它以網絡中位數「利率」而非交易量為基準,因此在構造上大小中立:在實時字段中,獎勵與自身債券呈「負相關」(它有利於提供高利率的小驗證節點,而非大型節點)。在部署前對所有活躍驗證節點進行的全字段前後對比已存檔——大多數驗證節點不會移動,排行榜頂部保持不變。相同的公式適用於每個驗證節點,包括我們自己的節點。
v4.5(2026-07-16)— 極端費率可行性懲罰。費用合理性維度在費用超過市場錨點 + 20 點(~ Granite 後 40%)時飽和至 0/7;從那裡一直到 100% 費用,複合分數完全停止對費率的反應,因此一個 100% 費率驗證者 — 委託人什麼都得不到的驗證者 — 仍在其費率無關維度上得分在 40 多分。在委託人面向的分數上,這種結果幾乎是不符合資格的,而非中等水準。v4.5 增加了一個複合懲罰,應用為正面維度總和的一個分數:在 50% 費率或以下時為零(在費率維度已定價的範圍內沒有雙重計算),然後線性增加至 100% 費率時分數的 75%。100% 費率節點落在約 10/100 — 仍列出和排名,明顯不是委託候選者。它是鏈上費率的純函數,對每個驗證者相同,包括我們自己的節點。
v4.4(2026-07-11)— Granite 下限感知費用錨點。Granite 硬分叉(Flare,2026-07-14)強制執行 20% 最低驗證者委託費用。費用合理性錨點變為 max(觀察到的最低活躍費用、協議下限):每筆等於或低於法律最低費用的費用獲得滿分,只有超過該費用的部分被處罰(按距離)。理由:因上游未指定正在進行的權益的過渡條款,錨定至過渡的 2%(或分叉前 0%)遺留項將已給與協議相符的 20% 運營商評分為近似提取性質 — 並雙重計算了淨收益已在已交付條款中計價的費用差。沒有其他維度改變。當整個同群體達到下限時,該維度統一授予滿分 — 一旦無人能在費用上競爭,費用就停止計算。
v4.3(2026-05-14)—— 添加活躍中斷懲罰作為平面維度後扣除。現有的 uptimeReliability 乘數是對稱的——24 個 epoch 中散落的 5 次未能達到成本與連續的 5 次未能達到相同——但在操作上這些是非常不同的信號:散落的未能達到意味著慢性不穩定,連續失敗意味著驗證者現在就壞了。v4.3 讀取驗證者近期參與歷史前端的連續不符合資格 epoch 的運行,並為 0–1 個連續未能達到扣除 0 分(正常差異/單個瞬間未能達到),2 個時扣除 3 分(中斷發展),3 個時扣除 6 分(持續中斷),4 個或更多時扣除 10 分(活躍延長中斷),複合值下限為 0。分層在可靠性乘數之上——而不是替換——因為兩者捕捉不同的風險。觸發因素:2026-05-14 Luganodes 級別事件,多個最近 epoch 連續未能達到,而委託者正在積極承諾質押;連續信號讓委託者在承諾之前看到正在進行的失敗。懲罰在分數細分面板中呈現為自己的部分,因此 9 個正維度仍然加起來達到 100。
v4.2(2026-05-14)—— 兩個相關修復,一起發佈,以回應 AU (@aucc_official) 對 Luganodes 分數的公開更正。(1) deliveredAPY 計算現在將每獲利 epoch 的速率乘以 `epochsIncluded / epochsObserved`,因此顯示的 APR 反映委託者在觀察窗口內實際獲得的有效速率——包括驗證者未能達到 FIP-10 最低值時零收益的 epoch。之前的實現僅平均獲利 epoch 並顯示驗證者的優質 epoch 速率,掩蓋了最低失敗。(2) 正常運行時間維度的可靠性乘數從僅正常運行時間(epochsUptimeEligible / epochsObserved)擴大到完整 FIP-10 最低集合(epochsIncluded / epochsObserved)。具有 100% RPC 正常運行時間但未能達到 FSP 簽署或 FTSO 提交率的驗證者現在在正常運行時間維度上按比例受罰,無論他們未能達到哪個最低值。Luganodes 特定的淨效應:deliveredAPY 從 10.86% 下降到 ~5.43%(與實際半支付現實相符),正常運行時間可靠性從 1.0 下降到 0.5,分數實質性下降。相同的更正適用於每個 `epochsIncluded < epochsObserved` 的驗證者——在整個網絡上,這表面了以前隱藏的真實參與質量差距。
v4.1(2026-05-14)—— 淨收益維度從理論 APR(公式:gross_APR × (1 − 費用))切換到來自 Flare 基金會 reward-scripts 的測量 deliveredAPY,理論備選方案僅在不存在測量歷史時適用於每個驗證者。觸發因素:FIP-16 的通脹削減(5% → 3%)於 2026-05-14 上線,理論公式的符合資格質押分母從鏈上現實漂移,使得理論 APR 在整個網絡上少報交付收益約 2 倍。切換到測量優先將分數輸入與質押者實際接收的內容重新對齊。networkMedianAPR 錨點也使用相同的測量優先方法重新計算,因此比率比較在雙方保持一致——分數應該大致穩定(網絡中位數的驗證者仍然得分 ~12/18 等),只是基於實際交付的速率而不是公式輸出。
v4.0(2026-05-11)—— 主版本。v3.7-v3.10 週期共同構成評分系統的結構性重寫,足以保證提升。摘要:兩個維度的上限已變更(信任 10→11,容量 8→7);運營商質量的公式被重寫為 max(驗證、FTSO 衍生),因此參與無法造成傷害;四個剩餘的分桶維度(正常運行時間、費用、交付、剩餘時間)被線性化以消除邊界懸崖;添加了三個新分數組件(30 天委託保留、30 天自我質押軌跡、自動升級到精選層);為信任計數 + 集中引入了多節點運營商聚合;通過 reward-scripts epoch 存在使長壽命不受刪除影響;消除了兩個反向激勵(運營商質量 FTSO 參與懲罰和正常運行時間 95% 反向 V 懸崖)。分數的每個輸入都現在可以外部驗證——沒有編輯決策是負載承載的。驗證者可以通過可觀察行為(90+ 天觀察、25+ 委託者、保留無下降、FIP-10 合規自我質押)為 +7 精選運營商基線賺取,無需發送電子郵件給團隊。見下面的 v3.7-v3.10 條目,了解構成此版本的詳細更改。
v3.10(2026-05-11)—— 關閉了分數中的最後一個監管差距。運營商質量上的 +7 精選運營商基線以前需要手動包含在我們的 KNOWN_VALIDATORS 列表中,這是 v3.7-v3.9 審計週期後剩餘的唯一有意義的編輯決策。v3.10 添加了一個客觀的自動升級路徑:任何具有 90+ 天 FlareWatch 觀察、25+ 運營商聚合委託者、保留無下降(30 天跌幅 ≤ 15%)和 FIP-10 合規自我質押的驗證者自動符合 +7 基線資格——無需手動審查。KNOWN_VALIDATORS 保留為尚未累積 90 天窗口的機構運營商的快速通道(想想啟動日期 Ankr 或 Kiln 條目),但典型情況現在完全自動化。所有四個標準都是鏈上衍生或接近鏈上(委託者計數、保留、自我質押)加上我們自己的觀察時間戳——沒有主觀的,沒有發送電子郵件給團隊的門控。淨效應:驗證者可以通過行為單獨賺取 +7 層。網絡上大多數已建立的運營商已經符合今天的條件。
v3.9(2026-05-11)—— 在審計分數的每個部分以實現公平後,跨剩餘四個分桶維度的邊界懸崖清理。固定:(1) 正常運行時間曲線中 95% 的反向 V 懸崖——從 94.99% → 95.00% 的正常運行時間下降失去 4 分(95-99% 分支以 0 開始,而不是與較低分支的最大值 4 匹配)。我們剛剛在運營商質量 (v3.8) 中修復的反向激勵的形狀相同。(2) 費用合理性閾值線性化——v3.9 之前,跨分桶邊界的 0.01% 費用增加可能失去最多 2.5 分。現在分段線性,坡度越來越陡,保留邊界處的分桶值(低費用幾乎沒有懲罰,提取費用嚴厲懲罰)。(3) 交付可靠性 deliveryRatio 閾值線性化——相同模式,最多 2 點懸崖已消除。(4) 剩餘時間分桶閾值線性化——較小的懸崖(14 天邊界最多 2 分)但仍然存在於小維度中;現在光滑。淨收益、MIRROR 參與和容量配置文件已審計並確認按現狀公平(已是線性/連續)。總上限保持不變,為 100。按設計沒有分數回歸;唯一移動分數的驗證者是那些碰巧坐在之前分桶邊界上的。
v3.8(2026-05-11)—— 運營商質量維度在公平性審查後已審計並重寫。三個修復一起發佈。(1) 消除了反向激勵——具有中階 FTSO 得分(例如 50)的已知運營商得分 4 分,但同一運營商完全退出 FTSO 得分 7 分。在 v3.8 下,分數是 max(驗證基線、FTSO 衍生),因此 FTSO 參與只能幫助,永遠無法傷害。(2) 引入了中間驗證層——來自 Flaremetrics 或 FSE 的自動發現名稱的運營商(但尚未在精選 KNOWN_VALIDATORS 地圖中)得到 +3 而不是 0,軟化了之前的 7→0 懸崖。(3) 在驗證領先於低 FTSO 得分時在細分詳細中表面兩個信號(例如「精選運營商 · FTSO 45」),以便運營商準確了解他們的分數來自何處。12 分的上限保持不變;無需重新平衡,因為更改僅在底部擴大分數分佈(獎勵部分驗證)而不改變頂部。
v3.7(2026-05-11)—— 社區信任維度在運營商公平性審查後已審計並擴展。三項補充:(1) 多節點運營商聚合——運營多個 P-Chain 節點的運營商(AU、FlareBus、Aureus Ox、Kiln 等)現在已聚合其委託者計數和總質押以用於信任計數 + 集中信號,因此他們不會因將同一委託者基分佈到多個節點而受罰。(2) 30 天委託保留信號(±0.5 分)——使用滑動窗口比較區分增長/穩定/收縮驗證者。v3.7 之前的僅快照信任維度無法區分這些。(3) 30 天自我質押軌跡(±0.5 分)——獎勵隨著時間增加自我質押的運營商,懲罰那些安靜取消保證的。不同於只捕捉單個大額下降的突然變化懲罰。上限重新平衡:信任 10 → 11,容量 8 → 7。審計中的錯誤修復:(a) 零自我質押現在正確地受到低於 FIP-10 懲罰(之前 `selfBondFLR > 0` 門讓正好為 0 的自我質押逃脫 −1)。(b) FIP-10 底線和 5% 之間的小自我質押比率現在在細分面板中呈現實際百分比,以便運營商看到什麼關閉到 +1 / +2 層的差距。(c) 長壽命獎勵現在不受刪除影響——在首次觀察 KV 人工新鮮時回退到 reward-scripts epoch 存在。
v3.6(2026-05-11)—— 兩個 MIRROR 檢測修復,一起發佈。(a) 檢測現在從兩個規範來源讀取:來自 V2 RewardManager 的鏈上 RewardClaimed(claimType=3) 事件和官方 FSP Merkle JSON 中的 claimType=3 分配(Flare 自己的簽署工具消費的相同數據)。任一信號都足夠——捕捉 MIRROR 已被分配但尚未在鏈上申領的驗證者。(b) 與 Merkle 的交叉檢查揭示了一個單獨的鍵格式錯誤:validators:mirror-stats 具有混合十六進制20/cb58 NodeID 鍵(當驗證者尚未在我們的精選名單中時,鏈上索引器寫入十六進制),而每個 UI 消費者僅通過 cb58 查詢——因此 ~95 個驗證者的狀態對顯示不可見。查詢現在跨驗證者表、分數細分面板、mirror-stats 公開 API、收益頁面質押位置卡和 FTSO 提供者面板的兩種格式標準化。受影響的驗證者在下一個 cron 週期中看到其 MIRROR 參與 + 運營商質量維度和整體 FlareWatch 分數上升 9-10 分。通過 FTSO 提供者報告 (FlareBus, 2026-05-11) 發現——信用和感謝。他們的反饋實質性改進了每個委託者對網絡的看法,而不僅僅是他們自己的分數。
v3.5(2026-05-09)—— 淨收益現在以網絡 APR 為中位數錨點(中位數的驗證者得分 12/18,頂級表現者達到 18,下四分位跌至 0)。信任維度作為第四個組件吸收了自我質押對齊(按比例自我質押獎勵皮膚投入遊戲;低於 FIP-10 底線受到小懲罰)。新「NEW Xd」徽章表面 FlareWatch 僅觀察不到 30 天的驗證者,以便質押者可以看到什麼時候追蹤記錄較薄。
v3.4(2026-05-09)—— 正常運行時間維度現在將瞬時 RPC 正常運行時間與歷史 FIP-10 epoch 合格性比率混合。v3.4 之前該維度無區別性(92.9% 的驗證者具有 100% RPC 正常運行時間)。可靠性比率源自跨最後 8 個 reward-scripts epoch 的 epochsUptimeEligible / epochsObserved——一個時間序列信號,有意義地區分偶爾未能達到 FIP-10 最低條件的驗證者和不會的。
v3.3(2026-05-09)—— 交付維度現在使用指數時間加權平均速率(最近 epoch 計數更多,衰減常數 0.85)並應用方差懲罰(變異係數 × 0.5,上限 −30%)。從每個 epoch reward-scripts 數據計算——樣本大小作為現有置信度阻尼器進行。
v3.2(2026-05-09)—— 多信號社區信任(計數 + 集中 + 長壽命);FlareWatch 首次觀察跟蹤在 KV 中持久化以用於長壽命獎勵;質押結束邊界情況(驗證者在到期前 14 天內得分 0 分,因為他們在 FIP-10 下無法接受新委託);方法頁面公開;運營商反饋通道表面;算法版本在每個緩存分數記錄上標記。
v3.1(2026-05-09)—— 從 reward-scripts 數據連接交付維度;平滑運營商質量(線性插值)、容量(帳篷函數)和信任(對數刻度);將 FSP 已知 + 零 claimType=3 重新分類為 MIRROR「不活躍」而不是「無數據」;持久化 scoreBreakdown 服務器端,以便客戶端無需完整輸入即可重新計算。
v3(2026-05-09)—— 用連續運營商質量替換二進制身份獎勵。添加 MIRROR 參與作為專用維度,帶有費用傳遞。使上限容量中性而不是 0 分懲罰。通過淨收益移除 APY/費用重複計算。重新校準樂隊(頂級層 90+、強/良好/可接受/低於中位數)。
v2(2026-05-09 之前)—— 原始 8 維度評分(正常運行時間 / APY / 費用 / 身份 / 容量 / 信任 / 時間 / 交付)。由於 APY/費用重複計算、二進制身份懲罰、上限容量懲罰、無 MIRROR 維度而停用。為了歷史參考而記錄。
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.