バリデータースコア方法論

アルゴリズムバージョン: v4.8 · 最終更新日: 2026-08-19

FlareWatchは各P-Chainバリデーターに9つのディメンション全体で0~100の複合スコアを割り当てます。数式は確定的で、入力はパブリックチェーンデータ[Flare Explorer] [FSE] [Flaremetrics]であり、ネットワーク上のすべてのバリデーター(FlareWatch自身のバリデーターノードを含む)に同じアルゴリズムが適用されます。このページは、オペレーターとステーカーがスコアの計算方法と各値が選ばれた理由を正確に確認できるよう、すべてのディメンションとしきい値を文書化しています。ここで行われているすべての主張は、一次的なオンチェーンまたはアップストリームソースにリンク戻されています。下部のソースと参考文献を参照してください。

スコープ:このページはバリデータースコアを文書化しています。バリデーターページのステーキングモードに表示される内容(FLRをP-Chainバリデーターにデリゲートしており、VRM + MIRRORリワードを受け取る場合)です。デリゲーションモードに表示されるFTSOプロバイダースコア(WFLRをFTSOデータプロバイダーにデリゲート)は、データプロバイダーのパフォーマンス、V2プロトコル参加などに焦点を当てた独立した13ディメンションアルゴリズムを使用します。これらはディメンション上で区別されるオンチェーンロールであり、個別にスコア化されます。デリゲーション側については、FTSOプロバイダースコア方法論を参照してください。
SGB相当なし:このスコアリングはFlare P-Chainバリデーターにのみ適用されます。SongbirdのオンチェーンバリデーターセットはFlare Foundationが承認したエンティティに限定されているため、小売SGB P-Chainデリゲーションはまれで、ステーキングタブはFLRのみです。ステーキングモードにはFLR / SGBトグルはありません。SGB FTSOデリゲーションについては、FTSOプロバイダースコア方法論を参照してください。これは両チェーンをカバーしています。
APY の計算方法 — 実際に獲得するもの

ステーキング・テーブルのAPYは、デリゲーターが受け取るオールイン・レート — 1つの数値、暗算不要。Flare の報酬スクリプトから測定(公式ではなく実際のペイアウト)、バリデーターの手数料控除後で、エポックごとに実際の報酬で変動。FlareWatch 全体で、APY は手数料後、APY は手数料前を意味します。

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • ステーキングリワード(VRM) - デリゲーターの検証リワードの純シェア = Σ デリゲーターペイアウト ÷ Σ デリゲート額(Flareの独自の分配; フィーは既に除去されている)。Flareが比例的にステーキングに支払うため、これはネットワーク全体でほぼ均一で、主にフィーによって異なります。より低いフィーはより高いデリゲーション率を意味します。
  • MIRROR - あなたのステーキングのFTSOインフレーションシェア(追加で支払われる)。アクティブなFTSOスタックを実行しているバリデーターでのみ支払われます。バリデーターのFTSO参加によって異なり、最近のエポック上で測定されます。

Flare Systems Explorer と比較? FSE および他のエクスプローラーはデリゲーション・レートのみを表示します — MIRROR は追加されません — したがって Total APY は MIRROR 対応バリデーターで高く読み取られます(差はちょうど上記の MIRROR 行です)。両図は同じ報酬スクリプト・データからの約8エポック遅行平均であるため、バリデーターの中盤の窓での手数料変更はウィンドウを通じてエージングされるまで、どちらのサイトでも現在の手数料スナップショットに遅れます。

APY ツールチップに表示される他の2つの図は、デリゲーターのレートではありません。理論的ベースライン(ネットワーク総APY × (1 − 手数料)、ステーキングのみ — 十分な測定履歴が存在する前の代替として使用)、およびオペレーターのセルフボンド利回り(バリデーターの自身のステーク・リターン、手数料キャプチャで増幅 — オペレーター・メトリック、あなたが得るものではありません)。

スコア作成のため。Net YieldディメンションはVRMデリゲーション・レートのみをスコア、MIRROR は独自ディメンションでスコア — したがって MIRROR は、表示される Total APY に含まれていても、決して二重計算されません。

スコアバンド
90+トップティア - オペレーターの上位約10~20%。典型的なプロフィール: フルスタックバリデーター + FTSO + FDC、低いフィー、MIRROR-アクティブ、一貫したFIP-10信頼性、健全なデリゲーターベース、有意義なセルフボンド。単一のディメンションは必須ではありません。オペレーターはほとんどのカテゴリー全体で強みを積み重ねることでトップティアに到達します。
80–89強力 - ほとんどの主要なベンチマークを満たします。トップティアまでの1~2ディメンション不足です。
70–79優良 - すべてのベースライン基準を満たします。大きなギャップなし。
60–69許容可能 - 使用可能だが、差別化されていない。
<60中央値以下 - 1つ以上のディメンションに大きなギャップ。数学的事実であり、品質判断ではありません。
ディメンション(合計100)
稼働時間20 ポイント最大
内容: 瞬間的なP-Chain RPCアップタイムと、最近のリワードエポック全体の履歴FIP-10アップタイム適格比率の組み合わせ。
方法: RPC曲線: ≥ 99.5% → 17〜20。99–99.5% → 13–17。95–99% → 4–13。90–95% → 0–4。< 90% → 0。この結果にuptimeReliability(公開reward-scriptsデータから過去8リワードエポック全体のepochsIncluded / epochsObserved。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エポックのうち3エポックでFIP-10最小条件に失敗したバリデーターは、瞬間的なRPCが現在何を報告しているかに関係なく、62.5%の信頼性スコアを持ちます。FIP-10の80%プロトコルフロアより意図的により厳しい。エポックごとの適格データはFlare Foundationによってリワードスクリプトリポジトリで公開されます。
ネット利回り18 ポイント最大
内容: デリゲーターが受け取るネットフィー後のステーキングリワード(VRM)レート、ネットワーク中央値に固定。
方法: scoreAPR = 測定ネットデリゲーション率(delegationAPY: Σ delegatorRewardAmount / Σ デリゲート額、Flare Foundation リワードスクリプトから、最後の約8エポック)利用可能な場合、そうでなければ理論的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対理論的総×(1-フィー))。比較は一対一です。以前は事前フィー総レートが入力だったときのような1/(1-フィー)によるインフレーションはもはや行われていません(~2倍の「倍増」バグ)。Flareは比例的にステーキングに検証リワードを支払うため、VRMデリゲーション率はネットワーク全体でほぼ均一で、主にフィーによって異なります。したがって、このディメンションはほぼフィー競争力と配信信頼性を反映しています(エポックを逃すバリデーターは少なく配信)。MIRROR(FTSO参加によって異なる)は意図的に独自のディメンションに保持され、二重計算を回避します。
フィー妥当性7 ポイント最大
内容: プロトコル手数料フロア以上の抽出に対する対抗策。スムーズな区分線形形式。
方法: アンカー = max(観察された最小アクティブ手数料、プロトコルバリデータ手数料フロア — Graniteハードフォーク以降20%、2026-07-14)。アンカー以下の手数料 → 満点7pt。これより上では、次の20ptの手数料にわたって線形スロープが増加(アンカー+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
理由: Net Yieldはすでに配信条件のパーセント単位の手数料を考慮しています。このディメンションはプロトコルと市場が許可する金額を大幅に上回る手数料を請求するオペレータにのみフラグを立てます。すべての手数料が強制される20%フロアに固定されたら、誰もがここで満点を獲得し、設計上、このディメンションは差別化を停止します。誰も切り下げることができない数値は誰も区別することはできません。
オペレーター品質12 ポイント最大
内容: 2つの独立したシグナルの高い方を取ります: 検証ベースライン(アイデンティティ信頼度)とFTSO派生オペレーショナルパフォーマンス。
方法: 検証ベースライン: キュレーションティア(+7)は2つの方法で到達: 手動審査済みKNOWN_VALIDATORSエントリまたは客観的行動によるオートプロモーション(v3.10: 90日以上観察 かつ 25人以上のオペレーター集約デリゲーター かつ 現在収縮していない かつ セルフボンド ≥ 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。データなし(実際に観測されないバリデーター) → 5 × passthrough。v3.6はオンチェーンRewardClaimed(claimType=3)イベントと正規FSP Merkle JSONのclaimType=3割り当ての両方を含めるように'active'シグナルを拡大しました。どちらでも十分です。これは、MIRRORが割り当てられたがまだオンチェーンで請求されていないバリデーター(例えば、標準クレームイベントをトリガーしないセルフデリゲーションプロバイダー)をキャッチします。v4.6マグニチュードボーナス(最大+2、ディメンション上限12): mirror-activeバリデーターのみ対象、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 まで直線下降(キャップ)。新しい Trust 軌跡コンポーネント資金調達のため 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 最大委任にあることは魅力度の POSITIVE シグナル — 十分な委任者から満杯になるほど信頼されていると実証。v2 はキャップされたバリデータを 0/5 とスコア付け;v3 はこれを修正。適正規模(魅力度が実証され、かつ余裕あり)がピークを取得。v3.7 はディメンションキャップを 8 → 7 にトリミングし、解放されたポイントを Trust の新しい retention + self-bond 軌跡コンポーネントに充当。
コミュニティ信頼11 ポイント最大
内容: マルチシグナル:デリゲータ数+ステーキング分布の健全性+稼働期間+オペレータセルフボンドコミットメント(比例および絶対)+30日リテンション+セルフボンド推移+マルチノードオペレータ集約
方法: カウントシグナル(最大6、OPERATOR-AGGREGATED v3.7):[5、500]デリゲータの対数スケーリング→[0、6]、オペレータの全既知ノードで合算。濃度調整(±1):小売フレンドリー平均ステーキング(<500K FLR)→+1、クジラ集中(>50M FLR平均)→−1。稼働期間ボーナス(最大+1、ワイプ免疫v3.6):30日間観察で+0.5、90日以上で+1。最初に観察されたKVがワイプされた場合はリワードスクリプトのエポック存在にフォールバック。セルフボンドスキンゲーム(最大+2/最小−1、2軸v4.7):比例シェアまたは絶対規模のいずれか大きいほうでクレジット。比例≥10%→+2/5~10%→+1、絶対= min(1, selfBond ÷ 20M) × 2でネットワークトップ十分位ボンドで飽和。シグナルは2つの最大値を取得し、依然+2でキャップ。FIP-10未満フロア(<1M FLR)→−1。リテンション(最大±0.5、NEW v3.7):デリゲートFLR 30日間で+10%→+0.5、−15%→−0.5。セルフボンド推移(最大±0.5、NEW 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は2軸にします:セルフボンドを比率としてのみ読み取ると、大きな絶対ステーキングを投下してから委譲を引きつけたオペレータ(比率を薄める一方、実質的なコミットメントは減らない)がペナルティを受けました。2000万のセルフボンドが薄められた比率では200万未満のボンドと同じスコアでした。シグナルは比例シェアまたは絶対規模のいずれか大きいほうをクレジットし、絶対側面はトップネットワークボンドで飽和するため、規模だけではスコアを買えず、FTSOプロバイダースコアがセルフボンドを既に扱う方法と一致し、+2キャップは変わらないため、大きなコミットされたオペレータが今それに到達できるようになっても天井は動きません。稼働期間は実績のあるトラックレコードを報酬として実績なしの者にペナルティを課さず(上部に小さなボーナス、下部にペナルティなし)。濃度リスクはデリゲータにとって重要です。50M FLRの1クジラを持つバリデータは100万ずつの50小売とは構造的に異なります。2つのv3.7推移シグナルは有機成長とオペレータコミットメント増加を報酬とします。複合キャップは11です(v3.7から10に引き上げ)、単一シグナルは優位ではありません。
配達信頼性10 ポイント最大
内容: 実際に配信された net 委任レート(VRM)と理論的ベースラインの比率、一貫性のない支払いに対する分散ペナルティ。両側は手数料ネット、したがって比率は実際の配信を測定 — 手数料ではない。
方法: Piecewise linear 配信比率:100%+ → 10、95% → 8、90% → 6、85% → 4、80% → 2、<80% → 0 に向けた直線ラップ。Variance ペナルティ:変動係数 × 0.5、−30% でキャップ。Confidence dampener はサンプルサイズ < 3 epochs 時に neutral 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
理由: Promised vs. delivered は委任者にとって最も直接的な説明責任シグナル。v3.3 は 2 つの改善を追加:(1) ヘッドライン比率は指数時間加重平均を使用(最近の epoch がより多くをカウント)、したがって以前はよく配信したが最近スリップしたバリデータは正しく罰せられる;(2) variance ペナルティは一貫した 95% 配信者と 95% の周りで振動する配信者を区別、後者はより多くのリスクを委任者に持つため。
残り時間5 ポイント最大
内容: バリデータの P-Chain での stake-end までの日数。
方法: < 14 日 → 0(FIP-10 では実質的に利用不可)。14-30d → linear 0→2。30-60d → linear 2→3。60-120d → linear 3→5。120d+ → 5。v3.9 は以前のバケット化されたしきい値を線形化 — 境界崖(例 13.99d → 0、14d → 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
理由: 実用的なシグナル — stake-end までの残り時間が 7 日のバリデータへの委任は 1 年と異なる提案。v3.2 はボトムをタイト化:stake-end まで 14 日以内のバリデータは新しい委任を受け入れられない(FIP-10 最小ロック 14 日)、したがって本質的にアンステーク不可。Score = 0 は「今すぐアンステーク不可」を「すぐにウィンドダウン」から区別。
アクティブ停止ペナルティ(v4.3)(控除) ポイント最大
内容: バリデータが複数の報酬 epoch を連続して逃すときに、ポジティブなディメンションの上に層状化された定額控除。対称 Uptime 信頼性乗数と異なる — 慢性的な不安定性ではなく、アクティブな停止をキャプチャ。
方法: キャッシュ:fsp-validator-participation レコード内のバリデータの連続 !eligible プレフィックスを確認(公開報酬スクリプト nodes-data.json からの最新優先 epoch リスト)。0–1 連続ミス → 0 pts(分散内 / 単一の一時的なミス)。2 連続 → −3 pts(開発中の停止)。3 連続 → −6 pts(継続 — 操作者の不注意)。4+ 連続 → −10 pts(アクティブな延長停止)。複合スコアは控除後 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)
理由: pre-v4.3 モデルは対称 uptimeReliability 乗数に全面的に依存 — 24 epoch にわたる 5 個の分散ミスは連続 5 個のミスと同じコスト。運用的にはこれらは非常に異なるシグナル。分散ミスは委任者に慢性的な不安定性を告げる;ストリークは、バリデータが RIGHT NOW で壊れていることを告げる。2026-05-14 の Luganodes インシデント — 委任者が何百万 FLR をアクティブにコミットしている間の複数の連続ミス epoch — は v4.3 リリースが対応する特定のケース:アクティブ停止シグナルをより鋭いスコア影響でサーフェス化し、委任者がコミット前に飛行中の失敗を回避できるようにする。層状曲線は単一の一時的なミスへの過剰反応を回避(一般的)しながら、継続ストリーク(稀で重要)を鋭くフラグ化。
Extreme-Fee ペナルティ (v4.5)(スコアの最大 −75%) ポイント最大
内容: 手数料ディメンションの範囲を超える手数料に対する比例減額。Fee ディメンションは手数料がアンカーを20ポイント超過するとスコア 0/7 で下限に達します。それ以降、複合スコアは手数料に完全に応答しなくなるため、100% の手数料バリデーター(デリゲーターが何ももらえない)であっても、アップタイムや MIRROR といった手数料非依存ディメンションで40点台のスコアを獲得することができました。
方法: 手数料が50%以下の場合はゼロ — Fee ディメンションがその範囲の価格設定を既に行っているため、二重計算はありません。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 を生成した監査サイクルは、すべてのディメンションをマックスアウトすることが委任者にとってより良いバリデータになるよう明示的に設計された。スコアを改善することはシステムをゲーミングしていない — それはシステムが設計通りに機能している。ディメンションごとの明示的なプレイブック。
Uptime — 20 pts。 ≥99.5% RPC アップタイムを継続的に維持 AND 各報酬 epoch で FIP-10 最小条件を満たす(reveal を逃さない、median 配信に到達)。2 つのシグナルは乗算 — 100% RPC × 7/8 epochs eligible = 17.5/20、20 ではない。これが委任者と一致する理由:FIP-10 に失敗するすべての epoch、委任者はその epoch のリワードを失う。
Net Yield — 18 pts. デリゲーターに≥1.2×ネットワーク中央値APY(手数料後)を提供。ベスト・パス: 低手数料 + 完全FIP-10適格性、デリゲーターが完全シェアを受け取ります。なぜこれが一致するのか。これはあなたのカットの後にデリゲーターに到達する実際のドル金額です。
手数料の妥当性 — 7ptGraniteハードフォーク以降、プロトコルは20%の最小委任手数料を強制し、スコアリングアンカー(観察された市場最小値とそのフロアのいずれか大きい方)以下の手数料は満点7を獲得します。これを超える請求は加速ランプでポイントが減少します — アンカー+10 → 4.5pt、アンカー+20 → 0。配置の理由:フロアが手数料競争を排除したため、このディメンションは法的最低限以上の抽出から委任者を保護するだけです。真の競争力はNet Yieldで配信します。
Operator Quality — 12 pts。 最適なパス:FTSO データプロバイダーとして登録し、高品質スタック(FTSO + FDC + signing)を運用 — FlareWatch Operator Quality スコアは FTSO スコアから来て、FTSO 100 でマックス。Alternative if staking-only:v3.10 自動昇格の資格取得(90+ 日観測、25+ 委任者、retention 低下なし、FIP-10 準拠の self-bond)または KNOWN_VALIDATORS に institutional infrastructure として追加(manual fast-track)のいずれかで +7 verification ベースラインを維持。スコアは max(verification、FTSO-derived) を取得 — participation はハートを傷つけられない。これが委任者と一致する理由:フルスタック操作者はエコシステムのより多くの価値を提供;verification ベースラインは委任者にクリアなアイデンティティシグナルを与える。
MIRROR Participation — 10 pts。 FSP 価格フィードを一貫して送信、epoch ごとプロトコル最小値を満たす(signing policy に登録、claim threshold 達成、reveal ミスなし)。中程度の手数料を請求 — スコアは (1 − fee/100) で乗算、したがって完璧に MIRROR-active 100% 手数料バリデータでも 0 スコア(zero MIRROR は委任者に到達)。これが委任者と一致する理由:MIRROR は委任者の FTSO インフレーション シェア。低手数料 = 彼らに到達する。
Capacity Profile — 7 pts。 ~70% 使用率(適正規模:魅力度が実証され、AND 新しい委任者のための余裕あり)を目標。空のバリデータは 1.75 でスコア;キャップされたバリデータは 5.25 でスコア。これが委任者と一致する理由:スコアを読んでいる新しい委任者は、彼らが実際に委任できることを知りたい;適正規模は社会的証明と可用性の両方を通知。
Community Trust — 11 pts。 マックスするための 6 つのコンポーネント:
  • 500+ operator-aggregated 委任者にビルド(最大 count シグナル:+6 pts)。
  • 委任者ごと retail-friendly 平均ステーク < 500K FLR を維持(concentration ボーナス:+1)。
  • longevity ボーナスのためネットワーク上に ≥ 90 日間滞在(+1)— reward-scripts プレゼンスで wipe-immune。
  • 大きなセルフボンドを保有してください。≥10%比例的またはトップネットワーク絶対ステーキング(~20M FLR)のいずれか大きいほう(アラインメントボーナス:+2)。
  • 30 日で total 委任 FLR を ≥ 10% 増やす(retention:+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が使用する正確な同じスコアリング関数、それが使用した正確な入力上で、サーバーへのコールバックなしで。すべてのバリデーターがノードIDの用語を持たない1つの同一の関数でスコアリングされるため、これはまた誰でも私たち自身のノードが隠れた利点を得ていないことを確認する方法でもあります。以下の手動ウォークスルーは手動で同じことを行います:
  1. バリデーターの公開統計を確認してくださいflaremetrics.io(オペレーター名で検索またはデリゲーションアドレスを貼り付ける)。あなたのdelegationFee、selfBond、delegatedStake、およびFTSOスコア(データプロバイダーの場合)に注意してください。
  2. 各リワードエポックについてFIP-10適格性を検証してくださいgithub.com/flare-foundation/reward-scriptsのgenerated-files/reward-epoch-N/nodes-data.json。最後の8つのエポックのうち、あなたのnodeIDがuptimeEligible: trueだったエポックの数をカウントしてください。その比率があなたのアップタイム次元乗数を駆動します。
  3. V2 RewardManagerコントラクトでのMIRROR参加を確認してくださいflare-explorer.flare.network。RewardClaimedイベント(claimType=3付き)であなたのnodeIDを参照するものを探してください。最近のものがない場合、MIRROR非アクティブとして表示されます。
  4. 入力を上記の式に挿入してください。各次元のコードブロックは、実行する正確な算術を教えてくれます。次元を合計し、100にクランプして、rawなcron計算スコアを得てください。
  5. 表示されているスコアと比較してください。表示されているスコアはv3.5の最後の4つのcronスナップショット(現在0.5、前0.3など)にわたる指数移動平均を含みます——したがって、単一の実行の計算されたスコアは表示されたものとわずかに異なります。各バリデーター行のスコア分解パネルは、貢献した永続化された次元値を示します。
  6. 計算が合致しない場合、[email protected]にメールしてください。あなたのnodeID、使用した入力、計算したスコアを含めてください。対応し、エラーを犯した場合は公開修正します。
プログラマティックアクセス:アクティブなバリデーターの場合、GET /api/validators/{nodeID}/score-breakdownにアクセスしてパーシスト分解を取得してください——すべての次元の値、それを生成したアルゴリズムバージョン、最近のスコア履歴——JSON形式で。UIのスコア分解パネルは同じソースから読み込みます。
一般的なオペレーターの懸念
私は100%のRPCアップタイムを持っています——なぜ私のアップタイムスコアは20/20未満ですか?
Uptime次元はRPC曲線の出力にエポック適格比率(過去8リワードエポック全体のepochsIncluded / epochsObserved。v4.2以降の完全なFIP-10最小基準。RPC稼働率のみではない)を乗算します。これらのエポックのいずれかでFIP-10最小条件を満たさなかった場合(わずかな期間でも)、信頼性比率は1.0を下回り、Uptimeスコアはそれに応じてスケーリングされます。v3.4以前は、この次元はRPC稼働率100%のすべてのバリデータに対して過去の適格性に関わらず20をスコアしていました。現在は差別化されています。
I deliver MIRROR——なぜFlareWatchは私をMIRROR非アクティブとして表示していますか?
v3.6以降、MIRROR参加は2つの正規ソースから検出されます:V2 RewardManagerの構内RewardClaimed(claimType=3)イベント、および公式FSPマークルJSON(公開されたリワード配分データ)のclaimType=3割当。どちらかのソースに表示されるnodeIDはアクティブとしてカウントされます。v3.6以前は、オンチェーンストリームを唯一のシグナルとして使用していました。これにより、非標準クレームパスを通じてMIRRORが決済されるセルフデリゲートプロバイダーに偽陰性を生じさせました。v3.6でも修正されました:約95のバリデーターが、オンチェーンインデクサーによってhex20(nodeIDのbytes20形式)下に書き込まれたミラー統計エントリを持っていたキーフォーマットバグ。彼らはまだ私たちのキュレーションされた名前リストになかった——一方、すべてのUIルックアップはcb58 NodeIDでキー設定されました。これらのエントリは存在し、正確でした;彼らはただ表示層に表示されませんでした。ルックアップは現在すべてのコンシューマー全体で両方の形式を正規化します(バリデーターテーブル、スコア分解パネル、公開ミラー統計API、イールドページステーキングポジションカード、FTSOプロバイダーパネル)。v3.6スイープ後もあなたのnodeIDがまだ非アクティブと表示されている場合、考えられる原因:(a)あなたのnodeIDが実際にはそのエポックのFSP署名ポリシーに登録されていない、(b)エポック公開の間(マークルデータはエポックごたに更新されます、約3.5日)。あなたのnodeIDを含めてメールしてください。私たちは両方の正規ソースを相互確認します。
私のスコアは一晩で10ポイント低下しました——何が変わりましたか?
3つのことのいずれか:(1)v3.5の急激な変更検出が手数料ジャンプ、セルフボンド低下、またはあなたのnodeIDのアップタイム低下にフラグを立てました——10ポイントペナルティは検出を実行して適用され、新しい状態が安定するにつれて次の3つの実行にわたって減衰します;(2)スムージングウィンドウは古いスナップショットを組み込み、平均を引き下げました;(3)アルゴリズムバージョンバンプを提供しました(あなたの記録のalgorithmVersionフィールドで表示されます——下記のバージョンカードを参照)。スコア分解パネルは現在の次元値を表示します;以前のrun と比較してください。
なぜ高手数料のバリデーターは、他がすべて類似している低手数料のバリデーターより低くスコアしますか?
純利回り次元(最大18ポイント)はフィー依存であり、0%フィーのバリデーターはネットワーク中央値APYの約1.25倍を提供し、ほぼ最高得点を獲得します。20%フィーのバリデーターは中央値の約80%を提供し、より低い得点となります。さらに手数料妥当性(7ポイント)はv3.9以降区分的に線形です(バケットなし):≤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ベースラインは2つの方法で到達可能です:(1)当社のKNOWN_VALIDATORSリストへの手動包含——信頼できるインフラストラクチャオペレーター(Ankr、InfStones、Kiln等)向けの制度的ファストトラック;(2)v3.10自動昇進客観的な行動に基づく——90日以上観察 AND 25以上のオペレーター集計デリゲーター AND 低下しない保持 AND FIP-10準拠のセルフボンド。自動昇進は完全に自動、メールは不要です。まだ自動基準を満たしていない場合、+3(自動発見ティア、Flaremetricsまたはシステムエクスプローラエンティティプロファイルが必要)で開始し、トラックレコードが構築されるにつれて+7に成長します。加速するには:FTSOデータプロバイダーとして登録し、V2プロトコルを実行してください——あなたのスコアはその後、FTSOスコア100で最大12のFTSO派生ブランチから来ます。v3.8:FTSO参加は役に立つだけで、決して害をありません——FTSOスコアが検証ベースラインを下回っている場合、ベースラインを保持します。
I have a logo but my name shows as a truncated NodeID. Why?
あなたのオペレーターエンティティはFlaremetricsに存在します(これが私たちがあなたのロゴを持っている理由)、しかしあなたのプロバイダープロフィールは「name」フィールドセットを持っていません。私たちは名前を作成しません。Flaremetricsまたはシステムエクスプローラエンティティレジストリであなたのprofile.nameを設定してください。次のcronの実行時にそれを選択します。または、検証可能なクレーム(例えば、デリゲーションアドレスからの署名されたメッセージ)をメールしていただければ、手動でKNOWN_VALIDATORSに追加します。
My validator is at FIP-10 max delegations. Why doesn't Capacity score 7/7?
容量はテント関数で70%使用率でピークします(7ポイント)、100%で5.25ポイントにランプダウンします。ピークは100%ではありません——アット・キャップはデリゲーターが望んでもより多くのステークを追加できないことを意味し、テーブルを読むニューデリゲーターにとってニュートラルからわずかにネガティブなシグナルです。v3以前は、キャップ化されたバリデーター0/5(成功のペナルティ)をスコアリングしました。v3はこれを-キャップの中立値に修正し、v3.7は次元全体を8から7に再スケーリングしました(最大、トラスト軌道シグナル向けにポイントを解放する)、今日キャップされたスコア5.25/7。右にサイズされたバリデーター(証明されたアトラクティブAND成長する余地がある、70%使用で最大)は完全な7を得ます。
I'm a real operator but I'm not in the validator list at all. What gives?
バリデーターリストはライブP-Chain RPCのgetCurrentValidatorsの結果から構築されます。そこにいない場合、あなたはP-Chainで現在アクティブではない、あなたのステークは期限切れになったばかり、またはP-Chain RPC問題があります。cronは5分ごとに実行されます——ステークをアクティブ化してから1~2サイクル以内に表示されるはずです。1時間ライブしていてもまだ自分を見ていない場合、メールしてください。
Can I appeal my score or request a manual review?
はい。[email protected]にあなたのnodeIDと具体的な懸念事項を含めてメールしてください。すべてのオペレーターに対応します。私たちが行動するもの:KNOWN_VALIDATORS追加、MIRROR分類修正、ロゴ/名前修正、次元固有の数学エラー。私たちが行動しないもの:アルゴリズム外のスコアを手動で引き上げるリクエスト、競争相手を除外または下げるリクエスト。
私たちが行うこと、行わないこと
スコアの操作方法について曖昧さを取り除くために、ここに明示的なコミットメントがあります。これらのいずれかに違反した場合は、文書化してメール[email protected]——公開修正します。
✓
より高いスコア、スポンサー配置、またはあらゆるの好意的な扱いのためにお支払いを受け入れません。スコアは公開チェーンデータから決定論的に計算されます。
✓
バリデーターごとの手動コード化されたバンプを行いません。「Xは彼らを好むから+5を得る」の行はコードのどこにもありません。同じアルゴリズムはFlareWatchの独自のノードを含むすべてのバリデーターに適用されます。これは正確にこの関数でスコアリングされます。
✓
バリデータを非公開の理由で表から除外することはありません。リストはライブP-Chain RPCから取得され、ディスプレイにはすべてのアクティブなバリデータが含まれます。KNOWN_VALIDATORSへのキュレーション追加は表示名のみを入力し、可視性をゲートしません。
✓
アルゴリズムの変更を公開します。すべてのバージョンアップ(v3→v3.1→v3.2→...)は、このページのVersionsカードで根拠と変更内容とともに文書化されます。主要な変更はアプリのchangelogページから表示される追加のchangelog entryを取得します。
✓
オペレーターのメールに対応します。[email protected]にスコアに関する実質的な懸念についてメールしたすべてのオペレーターには、数営業日以内に実際の返答を受け取ります。
✓
私たちは公開で誤りを正します。アルゴリズムのバグ、データソースエラー、またはMethodologyギャップを発見した場合、修正を配信し、文書化します。サイレントで再ランク付けはしません。
✗
送信者の許可なしにメールの内容を公開で共有したり、オペレーターのメールをそれを生成したスコア会話以外の目的で使用することはありません。
✗
アルゴリズム変更の今後の計画を選定されたオペレーターに事前に共有することはありません——すべてのバージョンは同時にライブになります。
制限事項 — このスコアが何であり、何でないか
複合スコアは有用な要約であり、客観的な真実ではありません。当スコアは透明性があり、バージョン管理され、すべてのバリデーター(当社含む)に同じように適用され、ブラウザ内で公開されている入力から再導出可能です。しかし、それでも編集上の判断を含んでおり、当手法が持たない精度を暗示するより、正確にどこに存在するかをお見せしたいと考えています。
ディメンション重みは当社の判断です。アップタイムが20ポイント、手数料が7ポイントであるのは、ほとんどのデリゲータにとって数ポイントの手数料差より信頼性の方が重要だと当社が判断したためであり、数式が証明したからではありません。異なる重み付けを行う人もいるでしょう。重みは固定で公開されているため、当社の選択を正確に確認し、内訳から精神的に再重み付けできます。
ネット利回りはアウトカムであり、美徳ではありません。デリゲータが実際に得る報酬をネットワークの中央値を基準に測定します。そのため、オペレータの管理外の要因(ネットワークインフレーション、獲得したデリゲーション額)により一部が形作られ、フィールドの他の動きに応じて変動します。公正でありながらやや高い手数料を請求する規律あるオペレータは、優秀であっても、ここではより低いスコアになることもあります。「私は何を稼ぐか」として読み、「このオペレータはどの程度優秀か」ではありません。
FTSO関連ディメンションはフルスタックオペレータを優遇します。MIRROR参加度およびオペレータ品質の一部は、トップのFTSOデータプロバイダスタックも実行するバリデータに報酬を与えます。これは意図的です — デリゲータとして、あなたはFTSOアクティブなバリデータからMIRRORを通じてより多く稼ぎます — しかしこれは、純粋で優秀なステーキング専用バリデータがこのボードの最上位に達することができないことを意味します。ステーキング専用を選択している場合、これらのディメンションの重みを自分で下げてください。
モデルは加法的です。ディメンションが加算されるため、強みが弱みを相殺できます — 優れたアップタイムは、より高い手数料を合格スコアまで引き上げることができます。本当に失格となるエラー(FIP-10最小値の不達成、略奪的手数料)は別途ゲートされているため、完全には隠蔽されません — 毎エポック最小値に不達するバリデータや100%手数料を請求するバリデータは、他のディメンションがいかに優秀でも下位近くにランクされます — コアは拒否権システムではなく、重み付き合計です。
1つの数字が9つの判断を隠しています。単一の0-100の数字は、スタートポイントであり、判定ではありません。1ポイント離れた2つのバリデータに意味のある違いはありません。内訳を開いて、あなたにとって重要なディメンションに重みを付けてください — この数字は比較を高速化するために存在し、それを置き換えるためではありません。
当社は方法をめったに変更しません。そして公開で行います。すべての変更にはバージョンバンプ、書かれた根拠、フィールド全体の前後が付属しているため、何が動き、なぜ動いたかを監査できます。当社の自動監査が当社の数字の矛盾を検出した場合 — それは行われます — 当社は修正してそう述べます。
最終スコア(ディメンションの組み合わせ方)
すべての9つのディメンションが直接合計され、その後v4.3のactive-outageストリーク控除が差し引かれます。総計は100でキャップし、0でフロアします。最近のcronスナップショット(v3.5)とsudden-changeペナルティにわたるスムージングが最終数値に適用されます。
// 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配置):エポックごとにMIRRORを返すべき人の正規公開記録(Flareの独自署名ツールが読む同じデータ)。v3.6で2番目の権威あるソースとして追加——MIRRORが割り当てられているがまだオンチェーンでクレイムされていないバリデータをキャッチします。
Flare Systems Explorer(FSE):バリデータエンティティレジストリ、表示名、ロゴ、FTSO V2プロトコル参加フラグ。
FlareMetricsプロバイダデータ:FTSOスコア、報酬レート、精度、V2機能、エンティティからnodeIDへのリンク。
Flare reward-scripts(GitHub):最新のN報酬エポックのバリデータごとの配信APY。Deliveryディメンションを駆動します。
FlareWatch curation:KNOWN_VALIDATORSマップ(~110エントリ)。信頼できるインフラストラクチャオペレーターの名前+オペレーターQualityベースライン。
スコアに含まれていないもの
• 自己宣伝または有料配置。オペレーターはより高いスコアを支払ったりスポンサーしたりすることはできません。
• 手動コード化されたバリデータ固有のバンプ。「Xは+5です、私たちはそれが好きだから」という行はコードのどこにもありません。同じアルゴリズムはFlareWatchの独自ノードを含むすべてのバリデータに適用され、この正確な関数でスコア付けされます。
• 主観的インフラストラクチャの品質。稼働時間SLA、地理的分散、またはハードウェア仕様を評価しようとはしません。インフラストラクチャグレードを要求する場合は、トップFTSO+FDCスタックを実行し、Operator Qualityディメンションがそれを反映します。
• FlareWatchへのロックアップまたはコミットメント。FlareWatchと別のツールを使用するステーカーの有利なスコアリングはありません。
オペレーターフィードバック
バリデータのスコアに何か問題がありますか?NodeIDと懸念事項を含む[email protected]にメールしてください。すべてのオペレーターに対応します。対応可能な一般的なリクエスト:
  • オペレーターをKNOWN_VALIDATORSに追加(検証付き)。
  • MIRROR非アクティブ分類をレビュー(エラーだと思う場合)。
  • ロゴ/表示名の修正。
  • 一般的なアルゴリズム批評。
ソースと参考資料
スコアへのすべての入力は、公開可能で検証可能なFlareエコシステムソースから来ています。誰もがこれらのプライマリソースに対して私たちの主張をクロスチェックし、生データから数学を再現できます。このページが上流ソースが何を言っているかとの間に矛盾を見つけた場合は、[email protected]にメールしてください。修正します。
権威あるプロトコルドキュメント。FTSO V2、FSP、P-Chainバリデーション、FAssets、およびFlareスタックの残りの部分をカバーしています。
Flare governance portal(FIP) ↗https://proposals.flare.network
Flare Improvement Proposals——FIP-05(デリゲーションファクター)、FIP-10(バリデーター最小条件:100万FLR自己担保フロア、80%稼働時間フロア、14日間の最小ロック)、およびこのページで引用されているすべてのその他のルールの真実の源。
Flare Systems Explorer(FSE) ↗https://flare-systems-explorer.flare.network
FTSOデータプロバイダー、エンティティアドレス、P-Chain nodeIDリンク、およびFIP-10最小条件フラグの公式Flareオペレーションレジストリ。オペレーターQualityと信頼性データの主要ソース。
Flaremetrics ↗https://flaremetrics.io
独立したFlareエコシステムメトリクスプロバイダー。FTSOプロバイダースコアリング、報酬レート、精度メトリクス、V2プロトコル参加フラグ、およびバリデーターからエンティティアドレスへのマッピングのソース。公開REST APIを使用します。
Flare Foundation reward-scripts repo ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation によって公開されたレポートエポックごとのJSONで、バリデータごとの適格性、稼働時間適格性、および配信報酬を示します。Delivery Reliabilityディメンションとv3.4のエポック適格性比率を駆動します。
Flare Block Explorer ↗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 スコア、手数料、16 進形式の nodeId を返します。誰でも直接アクセスできます。
Flaremetrics パブリック API(ノード登録) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
16 進 → cb58 NodeID 変換テーブル。このテーブルをページネーションして、cb58 形式のすべてのコンシューマーを駆動するエンティティ対 NodeID ルックアップを構築します。
プライベートデータなし、クローズドソースモデルなし。スコアリングアルゴリズムは FlareWatch コードベースの services/validators/scoring.ts に実装されています。実装を直接検査したい(上記の説明と数式を読む代わりに)、または独自の用途のためにフォークしたい運用者や研究者は、[email protected] にメールしてアクセスをリクエストしてください。本当に需要があれば、このファイルをスタンドアロンのオープンソースパッケージとして公開します。
スコアの更新方法
/api/cron/refresh-validators の cron は 5 分ごとに全アクティブバリデーターのスコアを再計算します。入力(P-Chain RPC リード、Flaremetrics、FSE、報酬スクリプト)はすべて実行のたびに最新で取得されます。
v3.5 では 最後の 4 つの cron スナップショット全体での平滑化(重み:0.5 / 0.3 / 0.15 / 0.05)が追加され、表示スコアが一時的な入力ノイズで急変しません。生の cron 計算スコアはまだ将来の平滑化数学のために保持され、スコア分析パネルは各次元の現在値を表示してどこが変わったかを確認できます。
アルゴリズムバージョンは、キャッシュされたすべてのスコアレコードにスタンプされます。新しいバージョンをリリースする際、すべてのスコアに新しいタグが付きます。下のバージョンカードはすべての変更をドキュメント化しています。
Flare のペナルティモデル

Flare はバリデーターステーキングをスラッシュしません。バリデーターの不正行為に対するペナルティメカニズム全体は報酬の没収と FIP-10 パス制です。ダブルサイニングスラッシュ、二重検証スラッシュ、追跡が必要なステーク破壊イベントはありません。FIP-10 最小条件を満たさないバリデーターはそのエポックの報酬を失い(パスがゼロの場合は完全没収、それ以外は失敗したプロトコルごとに 1 パス失う)、ステーク元本は保たれます。

つまり、スコアに「スラッシング履歴」次元はありません。追跡する履歴は存在しません。追跡するのは最小失敗の結果です。バリデーターはそのエポックでゼロを獲得し、これは epochsIncluded / epochsObserved に記録されます。2026-05-14 の v4.2 更新では、スコアの信頼性乗数を FIP-10 最小値セット全体(アップタイム、FSP 署名、FTSO 提出率、FDC 参加)にわたるその比率を使用するよう拡張したため、最小値を失敗するバリデーターはどの軸で失敗したかに関係なくアップタイム次元で比例的にペナルティを受けます。

FIP-10 最小閾値(出典:dev.flare.network/network/fsp/rewarding):ステーキングは 80% のアップタイム + 1M FLR のアクティブセルフボンドが必要。FTSO アンカーフィード(推定値はコンセンサス中央値の 0.5% 以内で 80% のラウンドが必要)。FTSO ブロック遅延フィード(期待される更新の 80% を提出)。FDC(投票ラウンドの 60% に参加)。80% アップタイム + 1M セルフボンドフロアを満たしているが 3M / 15M 獲得閾値以下のバリデーターはまだ報酬を受け取りますがパスを累積できません。このカードの passEligibility: "at-risk" 分類を通じて表示されるグレーゾーン。

バージョン
v4.8 (2026-09-17) — リワードエポックを実際の長さで年率換算。すべての測定バリデータレート(配信APR、デリゲーション、MIRROR、オペレーターセルフボンド利回り)は3.19日のリワードエポックで年率換算されていました。この値は2026-04-04に追加されたもので、ブロックタイムスタンプから測定されたとされていますが、実際には測定されていません。Flareのリワードエポックは正確に3.5日間です。FlareSystemsManagerのrewardEpochDurationSecondsは302,400を返し、すべてのエポック開始時はオンチェーンで3.500日間隔になっています。そのため、各測定レートは約5.5ヶ月間、9.7%高く読まれていました(当社独自のものを含む)。長さはそのコントラクトから読み込まれるようになりました。すべての測定APRは同じ係数で低下します:3.19 ÷ 3.5(ネットワーク中央値9.08% → 8.28%;FlareWatch 8.17% → 7.45%)。スコア:Delivery Reliabilityのみが移動します。これはバリデータの手数料の理論的レートと測定レートを比較するためです。インフレ側は91%のバリデータを1.0キャップに配置していました。つまり、技術的に可能な以上の支払いを行っているように見えます。実際のエポック長では、中央値の配信対理論比は0.990です。配信前に測定データのある168バリデータでシミュレーション:中央値−0.32ポイント、146が1ポイント未満の減少、13は既に手数料が示唆するレート以下で配信されており2~3.5ポイント失敗。Community Trustの耐久性フォールバックはエポックを同じ長さの日数に変換し、これも修正されます。30日ステップのいずれかの場合でも、最大8エポック(28日)が表示されるため、スコアは移動しません。署名されたパフォーマンス証明書は同じ間違った長さを使用していました。再計算仕様はrev.3に改訂され、rev.2はエラー開示で逐語的に保持されます。
v4.7(2026-08-19)— Community Trust次元での2軸セルフボンド。Trustは従来、オペレータセルフボンドを比率としてのみ評価していました(セルフボンド÷全ステーキング)。そのため、大きなセルフボンドが委譲により薄められると、その比率での小さなボンドと同じスコアになり、実際にコミットされた資本をスコアは認識していませんでした。ライブネットワークで178バリデータのうち61個は≥10Mセルフボンドを<10%の比率で保有していたため、フィールド全体の3分の1がアンダークレジットされていました。v4.7は比例シェア(≥10%→+2、5~10%→+1、変更なし)または絶対規模(min(1, selfBond ÷ 20M) × 2でネットワークトップ十分位P-chainボンドで飽和)のいずれか大きいほうでセルフボンドをクレジットし、最大値を取得して依然部分シグナルを+2でキャップします。Trustキャップ(11)と複合キャップ(100)は変わらず、FIP-10未満空白フロア(<1M FLR→−1)も変わりません。FTSOプロバイダースコアが既に使用している2軸セルフボンドをミラーします。出荷前にアーカイブされた全178バリデータのビフォー・アフター:58個が上昇、なし下降、1ポイント以上の上昇なし、リーダーボード上位は変わりなし。当社ノードは1ポイント上昇(83→84)、他のすべての十分に資本化されたオペレータと同じルール。当社を命名または異なる扱いをする式の項目はありません。
v4.6(2026-08-13) — MIRROR配分マグニチュードボーナス。MIRRORディメンションはパススルー(デリゲーターに到達するMIRRORの割合、= 1 − fee)と参加ステータスのみでスコアしていました。配分額には盲目でした。フィールドより大幅に高い配分MIRROR利回り(mirrorAPY、フィー控除後)を支払っているバリデーターはそれに対するクレジットを得られず、より高い利回りのノードはより低い利回りのノードより利回りディメンションでランク付けされることがありました。v4.6は小さく、キャップされた、中央値固定ボーナスを追加します。mirror-activeバリデーターのみ対象、clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2)。ネットワーク中央値利回りの1.2倍を超える配分のみがそれを獲得し、最大+2で、MIRRORディメンション上限を10から12に引き上げます(複合は依然100で上限)。ボリュームではなくネットワーク中央値利回りに固定されているため、構成上サイズニュートラルです。ライブフィールド全体ではボーナスはセルフボンドと負の相関を示します(大規模な方ではなく、高い利回りを配分する小規模バリデーターを優遇)。全アクティブバリデーター全体のフィールド全体の変更前後分析は出荷前にアーカイブされました。ほとんどのバリデーターは動きませんが、リーダーボードトップは変わりません。同じ公式は全てのバリデーター、私たちのノードを含めて適用されます。
v4.5(2026-07-16)— 極端な手数料の実行可能性ペナルティ。Fee Reasonableness次元は、手数料がマーケットアンカー + 20ポイント(Granite後で約40%)を超えると0/7で飽和します。そこから100%手数料まで、合成スコアは手数料に全く反応しなくなったため、委任者が何も得られない100%手数料バリデータでも、手数料ブラインド次元では40点台のスコアが得られていました。委任者向けスコアではその結果は準適格レベルではなく、中位です。v4.5は正次元合計の割合として適用される合成ペナルティを追加します:50%手数料以下ではゼロ(Fee次元が既に価格設定している範囲では二重計上なし)。その後100%手数料で100点中75%にまで線形に増加します。100%手数料ノードは100中約10点に着地します。まだリストアップされ、ランク付けされていますが、明らかに委任先候補ではありません。これはオンチェーン手数料の純粋な関数で、すべてのバリデータで同じです。当社ノードも含めて。
v4.4(2026-07-11) — Graniteフロア対応手数料アンカー。Graniteハードフォーク(Flare、2026-07-14)は20%の最小バリデータ委任手数料を強制します。手数料の妥当性アンカーはmax(観察された最小アクティブ手数料、プロトコルフロア)になります。法的最小限以下のすべての手数料は満点を獲得し、それ以上の手数料だけが距離で処罰されます。理由:インフライトステークスの適格化が上流で不指定の場合、2%の適格化(またはfork前の0%)の遺産にアンカーを固定することは、プロトコル準拠の20%オペレータをほぼ抽出的とスコアリングし、Net Yieldがすでに配信条件で価格設定している手数料デルタをダブルカウントしていたでしょう。他のディメンションは変更されていません。コホート全体がフロアに達したら、このディメンションは一様に満点を授与します — 誰も競争できないと手数料がカウントされなくなります。
v4.3(2026-05-14)— アクティブ障害ペナルティが次元ごとの控除として追加されました。既存の uptimeReliability 乗数は対称で、24 エポック全体に散在した 5 つのミスは 5 つ連続したミスと同じコストがかかります。ただし運用的には非常に異なります:散在したミスは慢性的な不安定さを意味し、連続したものはバリデーターが今すぐ壊れていることを意味します。v4.3 はバリデーターの最近の参加履歴の先頭にある !eligible エポックの連続実行を読み取り、0–1 の連続ミスで 0 ポイント(通常の変動/単一の一時的ミス)、2 で 3 ポイント(発展中の障害)、3 で 6 ポイント(継続的な障害)、4+ で 10 ポイント(アクティブな拡張障害)を控除し、複合は 0 でフロアされます。信頼性乗数の置き換えではなく上に重ねられるため、両者は異なるリスクを記録します。トリガー:2026-05-14 の Luganodes クラスのインシデント、複数の最近のエポックが連続してミスされ、委任者がアクティブにステーキングをコミットしていた。ストリーク信号により、委任者はコミット前に飛行中の障害を確認できます。ペナルティはスコア分析パネルの独自セクションとしてレンダリングされ、9 つのポジティブ次元は依然として 100 に合計されます。
v4.2(2026-05-14)— 2 つの関連した修正。Luganodes のスコアに関する公開訂正に応じて、AU(@aucc_official)からの修正に対応して一緒にリリースされました。(1) deliveredAPY 計算は、エポックあたりのレートに `epochsIncluded / epochsObserved` を乗算するため、表示される APR は委任者が観察ウィンドウで実際に受け取る有効レートを反映します(バリデーターが FIP-10 最小値を失敗したときのゼロ獲得エポック含む)。以前の実装は獲得エポックのみを平均化し、バリデーターの良好エポックレートを表示し、最小値の失敗をマスクしました。(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)— Net Yield 次元は理論 APR(数式:gross_APR × (1 − fee))から Flare Foundation 報酬スクリプトの測定 deliveredAPY に切り替わり、測定履歴が存在しない場合のみバリデーターごとの理論フォールバック。トリガー:FIP-16 のインフレーション削減(5% → 3%)は 2026-05-14 にライブになり、理論数式の適格ステーク分母がオンチェーン現実から逸脱して、理論 APR はネットワーク全体で実際に配信された利回りを ~2 倍過小報告しました。測定ファースト。理論出力ではなく実際に配信されたレートに基づく。networkMedianAPR アンカーも同じ測定ファースト方法論を使用して再計算されたため、比率比較は両側で一貫性を保ちます。スコアはほぼ安定していることが期待される(ネットワーク中央値のバリデーターはまだ ~12/18 にスコアされている)が、数式出力ではなく実際の配信レートに基づいています。
v4.0(2026-05-11)— メジャーバージョン。v3.7–v3.10 サイクルは累積的にスコアリングシステムの構造的な書き直しを構成し、バンプを保証するほど十分に大きい。要約:2 つの次元のキャップが変更(Trust 10→11、Capacity 8→7)。Operator Quality の数式は max(verification, FTSO-derived) に書き直され、参加は害を与えません。4 つの残りの分類次元(アップタイム、手数料、配信、残り時間)は線形化され、境界崖を排除。3 つの新しいスコアコンポーネント(30 日委任保持、30 日セルフボンド軌跡、キュレーション階層への自動昇格)。マルチノード運用者集約が Trust 数 + 濃度に導入。長寿は報酬スクリプトエポック存在を通じてワイプ耐性。2 つの異常な動機が排除(Operator Quality FTSO 参加ペナルティとアップタイム 95% 反転 V 崖)。スコアへのすべての入力は外的に検証可能です。編集上の決定は重荷ではありません。バリデーターは +7 キュレーション運用者ベースラインを観測可能な動作(90+ 日間観測、25+ 委任者、保持は低下していない、FIP-10 準拠セルフボンド)を通じて獲得でき、メール送信は不要です。下の v3.7–v3.10 エントリを参照して、このリリースを構成する詳細な変更を確認してください。
v3.10(2026-05-11)— スコアの最後のキュレーション的なギャップを閉じました。Operator Quality の +7 キュレーション運用者ベースラインは以前、当社の KNOWN_VALIDATORS リストへの手動含有が必要でしたが、これは v3.7–v3.9 監査サイクル後に唯一の意味のある編集上の決定でした。v3.10 は客観的な自動昇格パスを追加します。FlareWatch 観測が 90+ 日間、25+ 運用者集約委任者、保持が低下していない(30 日降下 ≤ 15%)、および FIP-10 準拠セルフボンドのいずれかのバリデーターは、手動レビューなしで +7 ベースラインに自動的に適合します。KNOWN_VALIDATORS は 90 日ウィンドウをまだ蓄積していない制度的運用者の高速トラック(打ち上げデーの Ankr または Kiln エントリを考える)として残りますが、典型的なケースは完全に自動化されています。4 つのすべての基準はオンチェーン派生またはオンチェーン近い(委任者数、保持、セルフボンド)および当社自身の観察タイムスタンプです。主観的なもの、メール送信ゲーティングはありません。正味の効果:バリデーターは動作だけで +7 階層を獲得できます。ネットワーク上のほとんどの確立された運用者は今日すでに基準を満たしています。
v3.9(2026-05-11)— スコアのすべての部分の公正性監査後、残りの 4 つの分類次元全体での境界崖のクリーンアップ。修正:(1) アップタイム曲線の 94.99% → 95.00% のアップタイム行き、逆転 V 崖が 95% であり、4 ポイントを失った(95–99% ブランチは 0 で開始し、下位ブランチの最大 4 と一致せず)。Operator Quality (v3.8)で修正したばかりの同じ形の後方動機。(2) 手数料妥当性閾値は線形化。v3.9 より前、0.01% の手数料増加はバケット境界全体で最大 2.5 ポイント失う可能性がありました。現在、境界で段階値を保持する区間線形(低手数料はほとんどペナルティなし、略奪的な手数料は厳しくペナルティ)。(3) 配信信頼性 deliveryRatio 閾値は線形化。同じパターン、最大 2 ポイント崖を排除。(4) 残り時間バケット閾値は線形化。小さい崖(14 日境界で最大 2 ポイント)はまだ存在しますが、小さい次元に。現在は滑らか。Net Yield、MIRROR Participation、Capacity Profile は監査され、公正として確認(すでに線形/継続)。総キャップは 100 で変更なし。設計上、スコア回帰なし。スコアが移動する唯一のバリデーターは以前のバケット境界に正確に座っていた人です。
v3.8(2026-05-11)— 公正性レビュー後、Operator Quality 次元を監査および書き直し。3 つの修正が一緒にリリース。(1) 異常な動機を排除。キュレーション運用者が mid-tier FTSO スコア(例 50)を持つ 4 ポイント スコア、ただし同じ運用者が FTSO を完全にドロップアウトすると 7 ポイント スコア。v3.8 では、スコア max(verification baseline, FTSO-derived) なため、FTSO 参加は助けだけでき、害は与えません。(2) 中間検証階層を導入。Flaremetrics または FSE から自動発見された名前を持つ運用者(ただしキュレーション KNOWN_VALIDATORS マップに含まれていない)は、以前の 7→0 崖を柔らかくする代わりに +3 を得ます。(3) 検証が低い FTSO スコア(例「Curated operator · FTSO 45」)に勝つ場合、分析パネルの詳細に両方の信号を表示して、運用者は自分のスコアがどこから来ているかを正確に理解します。12 ポイント キャップは変更なし。変更は上部を変更せずに下部のスコア分布を拡張するだけなので(部分的な検証に報い)、リバランスは不要。
v3.7(2026-05-11)— 運用者公正性レビュー後、Community Trust 次元を監査および拡張。3 つの追加:(1) マルチノード運用者集約。複数の P-Chain ノードを実行する運用者(AU、FlareBus、Aureus Ox、Kiln など)は、委任者数と総ステークが Trust 数 + 濃度信号に集約されるため、同じ委任者ベースを複数のノード全体に分散させるためにペナルティを受けません。(2) 30 日委任保持信号(±0.5 ポイント)。スライディングウィンドウ比較を使用して、成長/安定/縮小バリデーターを区別します。v3.7 より前のスナップショットのみの Trust 次元はこれらを区別できませんでした。(3) 30 日セルフボンド軌跡(±0.5 ポイント)。時間の経過とともにセルフボンドを増加させる運用者に報い、静かに非ボンディングしている人にペナルティを与えます。単一の大きなドロップのみをキャッチする突然の変更ペナルティとは異なります。キャップ再調整:Trust 10 → 11、Capacity 8 → 7。監査からのバグ修正:(a) ゼロセルフボンド子 FIP-10 ペナルティを正しくヒット(以前の `selfBondFLR > 0` ゲートは正確に 0 セルフボンドがペナルティをエスケープすることを許可)。(b) FIP-10 フロアと 5% 間の小さいセルフボンド比は、運用者が +1/+2 階層へのギャップを閉じるものを見えるよう分析パネルで実際のパーセンテージをレンダリング。(c) 長寿ボーナスはワイプ耐性。最初に観測された KV が人工的に新しい場合、報酬スクリプトエポック存在にフォールバック。
v3.6(2026-05-11)— MIRROR 検出への 2 つの修正。一緒にリリース。(a) 検出は 2 つの標準ソースから読み取ります:V2 RewardManager からのオンチェーン RewardClaimed(claimType=3) イベント AND公式 FSP Merkle JSON の claimType=3 割り当て(Flare 独自の署名ツールが消費するのと同じデータ)。どちらかの信号で十分です。MIRROR が割り当てられているがまだオンチェーンで請求されていないバリデーターをキャッチ。(b) Merkle に対するクロスチェックは別のキー形式バグを明らかにしました:validators:mirror-stats はバリデーターがキュレーション名リストにまだ含まれていない場合、16 進キーと cb58 NodeID キー(オンチェーンインデクサーは 16 進を書き込んだ)が混在していた一方、すべての UI コンシューマーは cb58 のみで検索しました。~95 バリデーターのステータスはディスプレイに見えなくなりました。ルックアップは validators テーブル、スコア分析パネル、mirror-stats パブリック API、Yield ページ Staking Positions カード、FTSO プロバイダーパネルなど、すべてのフォーマットを正規化します。影響を受けたバリデーターは、次の cron サイクルで MIRROR Participation + Operator Quality 次元と総 FlareWatch スコアが 9–10 ポイント上昇しました。FTSO プロバイダーレポート(FlareBus、2026-05-11)を通じて発見。彼らのフィードバックはすべての委任者のネットワーク表示を物質的に改善し、自分のスコアだけではありません。
v3.5(2026-05-09)— Net Yield はネットワーク APR に対して中央値アンカー(ネットワーク中央値のバリデーターは 12/18 スコア、トップパフォーマーは 18 に到達、下位四分位は 0 に低下)。Trust 次元はセルフボンドアラインメントを 4 番目のコンポーネント(比例セルフボンドは皮膚のゲームで報い、sub-FIP-10 フロアは小さいペナルティを取る)として吸収。新しい「NEW Xd」バッジはステーカーが追跡記録が薄いときに FlareWatch が <30 日間のみ観測したバリデーターを表示します。
v3.4(2026-05-09)— アップタイム次元は、現在の RPC アップタイムと履歴 FIP-10 エポック適格性比率をブレンドします。v3.4 より前は、次元は非差別化(92.9% のバリデーターが 100% RPC アップタイムを持っていた)。信頼性比率は最後の 8 報酬スクリプトエポック全体の epochsUptimeEligible / epochsObserved から派生。時系列信号は、FIP-10 最小条件を時々失敗するバリデーターとそうしないバリデーターを意味のある区別。
v3.3(2026-05-09)— 配信次元は現在、指数関数的にタイムウェイト化された平均レート(最近のエポックのカウント、減衰定数 0.85)を使用し、分散ペナルティを適用(変動係数 × 0.5、最大 −30%)。エポックごとの報酬スクリプトデータから計算。サンプルサイズは既存の信頼性ダンペナーとして実行します。
v3.2(2026-05-09)— マルチシグナル Community Trust(数 + 濃度 + 長寿)。FlareWatch によって最初に観察されたトラッキングが KV に長寿ボーナスのために保持。ステーク終了エッジケース(バリデーター、有効期限まで 14 日以内、時間残数で 0 スコア、FIP-10 で新しい委任を受け入れできない);方法論ページはパブリック;運用者フィードバックチャネル表面;アルゴリズムバージョンはキャッシュされたすべてのスコアレコードにスタンプ。
v3.1(2026-05-09)— 報酬スクリプトデータから配信次元を配線。Operator Quality(線形補間)、Capacity(テント関数)、Trust(ログスケール)を滑らか;FSP-known + ゼロ claimType=3 を MIRROR「非アクティブ」として再分類「データなし」の代わりに。scoreBreakdown をサーバー側で保持して、クライアントは完全な入力なしで再計算しません。
v3(2026-05-09)— バイナリ ID ボーナスを連続 Operator Quality で置き換え。MIRROR Participation を専用次元として追加、手数料パススルー付き。キャップされた容量を 0 ポイントペナルティではなく中立的に作成。APY / 手数料ダブルカウントを Net Yield を介して削除。バンドを再キャリブレーション(Top tier 90+、Strong/Good/Acceptable/Below median)。
v2(2026-05-09 前)— 元の 8 次元スコア(アップタイム / APY / 手数料 / ID / 容量 / Trust / 時間 / 配信)。APY / 手数料ダブルカウント、バイナリ ID ペナルティ、キャップされた容量ペナルティ、MIRROR 次元なしによる退職。歴史的参照のため文書化。
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.