FTSO プロバイダースコア方法論

アルゴリズムバージョン: v4.11 · 最終更新日:2026-07-04

FlareWatchは各FTSOデータプロバイダーに対して12の評価対象ディメンションの0~100の合成スコアを割り当てます。数学は決定論的で、入力はFlareエコシステムのオンチェーンおよび公開データです。[Flaremetrics] [FSE] [Flare Explorer]、同じアルゴリズムはすべてのプロバイダー(FlareWatch 独自の FTSO プロバイダーを含む)に適用され、特別な扱いはありません。このページはすべての次元と閾値をドキュメント化し、委任者と運用者はスコアの計算方法と各値の選択理由を正確に確認できます。ここのすべてのクレームは、その主要なアップストリームソースにリンク返します。ソースと参照 下部にあります。

スコープ: このページはFTSOプロバイダースコアを説明しています。これは、バリデータページの委任モードで表示されるスコア(WFLRをFTSOデータプロバイダーに委任してFTSOインフレーション共有を受け取る場合)です。ステーキングモードで表示されるバリデータスコア(FLRをP-Chainバリデータに委任してVRM + MIRRORリワードを受け取る場合)は、バリデータ運用に焦点を当てた別の9次元アルゴリズムを使用します。稼働率、手数料、信頼性など異なるオンチェーン役割で、異なるリワード構造を持ち、個別にスコアリングされます。ステーキング側についてはバリデータスコアメソドロジーを参照してください。
FLRおよびSGBチェーンカバレッジ: バリデータページの委任タブには、Songbird(SGB)を保有するウォレット向けのFLR / SGBトグルがあります。このメソドロジーはFLR側スコアのみを記述しています。Songbird FTSOプロバイダーは複合スコアなしでリストされています。FLRで使用する精度・一貫性・FTSOリワードデータと同じデータがSongbirdパイプラインにまだ接続されていません(当社の主要なFLRデータソースであるFlareMetricsはSongbirdをカバーしていません)。SGBデリゲータが現在表示するもの:TowoLabsクロスネットワークレジストリからのプロバイダー名とロゴ、現在のウェイト(委任されたWSGB。Songbirdの当社RPCを経由してWNatコントラクトから直読)、およびプロバイダーのURL。ウェイト順でソート。精度データが利用可能になるまでは、より大きいウェイトがプロキシシグナルです。Songbird側の精度およびリワードレートパイプラインを接続する際、同じ13次元フォーミュラがSGBプロバイダーに適用されます。新しいスコアリングアルゴリズムではなく、Songbirdデータに対して計算されたFLRフォーミュラです。FlareWatchバリデータスコアリング(ステーキングタブ)にはSGB同等物はありません:SongbirdのP-Chainバリデータセットはflare Foundation承認エンティティのみに制限されているため、小売SGB P-Chain委任は稀であり、ステーキングタブはFLRのみです。
スコアバンド
90+トップティア — FTSOプロバイダーのトップ約10~20%。典型的プロファイル:平均以上のリワードレート、高い精度、V2プロトコル完全対応(FTSO Scaling + Fast Updates + FDC)、手数料ゼロ/低い、大規模デリゲータベース、MIRRORペイヤーバリデータノード、認知ブランド。単一の次元は必須ではありません。プロバイダーはほとんどのカテゴリにおいて強みを積み重ねることでトップティアに到達します。
80~89強力 — ほとんどの主要ベンチマークを満たします。1~2次元でトップティアに届きません。
70~79良好 — すべてのベースライン基準を満たします。大きなギャップはありません。
60~69許容範囲 — 利用可能ですが、差別化されていません。
<60中央値未満 — 1つ以上の次元で大きなギャップがあります。数学的事実であり、品質判定ではありません。
次元(生の重み — 合計172、100に正規化)
「アクティブ」は2つのディメンション(手数料とV2参加)をゲートします。実行していないプロバイダーは低い手数料を広告する信用を得るべきではありません。プロバイダーが公開されたリワードレートを持つか、Flare Systems Protocolのリワードデータがスコアリング期間内の少なくとも1つのエポックで支払ったことを示している場合、プロバイダーはアクティブとしてカウントされます。2026-07-31までは、単一のサードパーティAPIから取得したリワードレートのみでした。そのため、そのAPIがカバーしていないプロバイダーは両ディメンションで0スコアでしたが、毎エポック報酬を配布しているのが見えていました。アクティビティはプロバイダーのプロパティであり、それをリストアップする者のプロパティではありません。
リワードレート25 ポイント最大
内容: プロバイダーのエポックあたりリワードレート。ネットワーク中央値に固定。
方法: 比率 = プロバイダーレート / 中央値レート。線形:比率1.0(中央値)→ 12.5ポイント、比率2.0 → 25ポイント(上限)。非アクティブプロバイダー(リワードレート ≤ 0)→ 0。v4.0(2026-05-11):上限を再構成し、中央値が次元ポイントの半分となる(従来は40%)。
if (rate <= 0 || medianRate <= 0): score = 0
else:
  ratio = rate / medianRate
  score = min(25, round(ratio * 12.5 * 10) / 10)   // 1 decimal place

// Anomaly detection: providers > 3× the median are capped at
// median × 3 for scoring purposes (prevents data outliers from
// distorting the linear curve).
理由: リワードレートはデリゲータが最も経験する要素です。中央値固定は、ネットワークのリワード経済学が変化するときもスコアを正確に保ちます。低リワード時代に中央値の1.2倍のプロバイダーも、高リワード時代に中央値の1.2倍のプロバイダーも同じランクになります。上限と異常値フィルタにより、単一エポックのアウトライアがスコアを支配するのを防ぎます。
精度25 ポイント最大
内容: Flare Systems Explorer(FSE)からのFTSO価格精度—プライマリ(タイト四分位範囲)とセカンダリ(広い)報酬バンドのランディング率。
方法: FTSOプライマリ(タイト四分位範囲)とセカンダリ(広い)バンドランディング率の40/60ブレンド(v4.8)。Flareの独自報酬分割を反映—FIP.11はアンカーフィード報酬に40% primary / 60% secondaryで支払います。セカンダリは以前の区分曲線を使用(97% → 25 … 70% → 2)。フィールド全体でほぼ飽和(95–99%)しているため、ほとんど区別できません。プライマリは絶対線形曲線を使用—28% → 0から78% → 完全25まで。プロバイダーが実際に~28%から~80%に分散する、より難しいタイト帯域エンジニアリングがフィールドを分別します。固定アンカー(フィールドパーセンタイルではない)により、スコアはプロバイダーの独自入力から再算出可能です。利用可能な場合は単一バンドのフォールバック。FSEデータがない場合はニュートラル12.5。
if (fseAccuracySecondary > 0):
  pct = fseAccuracySecondary / 100
  if (pct >= 97) score = 25
  elif (pct >= 95) score = 18 + (pct - 95) * 3.5     // 95 → 18,  97 → 25
  elif (pct >= 93) score = 16 + (pct - 93) * 1       // 93 → 16,  95 → 18
  elif (pct >= 90) score = 13 + (pct - 90) * 1       // 90 → 13,  93 → 16
  elif (pct >= 85) score = 10 + (pct - 85) * 0.6     // 85 → 10,  90 → 13
  elif (pct >= 80) score = 6  + (pct - 80) * 0.8     // 80 → 6,   85 → 10
  else              score = max(0, 2 + (pct - 70) * 0.4)
elif (fseAccuracyPrimary > 0):
  // Primary fallback: similar piecewise linear curve.
else:
  score = WEIGHT_ACCURACY / 2   // Neutral — no FSE data
理由: ミスエポック = デリゲータにとってリワード収入の喪失。精度はプロバイダーの提出がFTSOコンセンサスに実際にカウントされるかを決定し、二次メトリック(より最近のエポックに重みを付ける)は現在のパフォーマンスに最もクリーンにマップされます。
一貫性20 ポイント最大
内容: プロバイダーのリワードレートが最近のリワード獲得エポック全体でどの程度安定しているか。
方法: プロバイダーの直近の獲得エポック間でのダウンサイドボラティリティ。本当に連続しているエポック間のみ測定されます — プロバイダーが何も獲得しなかったエポックはレコードに残らず、そのギャップの両側にあるエポックは相互に比較されません。エポック間の下落のみがカウント対象 — 上昇はゼロ — なため、安定もしくは上昇するレートはほぼ満点を獲得し、回復が起こるにつれてスコアが上がります。下落は RMS 集計されるため強い下げが微弱な下げより大きく重み付けられ、最近のペアへのウェイト付け(減衰 0.8)により積極的な回復がスコアを引き上げている間に古い下落は消えます。cv = 0 → 20 点; cv ≥ ~0.167 → 0。直近 12 獲得エポック内に連続するエポックペアが 3 組未満の場合、ニュートラル 10 点。
earned = last 12 epochs where rewardRate > 0, keyed by epochId
pairs  = [earned[i-1], earned[i]] where epochId[i] - epochId[i-1] == 1
if (pairs.length < 3) return 10        // Neutral — too few consecutive pairs

// DOWNSIDE volatility only: rises never hurt, so a stable or RISING
// rate scores near full and a recovery lifts the score. Only drops
// between CONSECUTIVE epochs count, in proportion to depth (RMS),
// weighted toward recent pairs so an active recovery pulls the score up.
drops[i] = max(0, (prev - cur) / prev)     // rise -> 0
w[i]     = 0.8 ^ (age of pair)             // newest pair = highest
cv       = sqrt( sum(w[i] * drops[i]^2) / sum(w[i]) )
score    = max(0, round((1 - min(1, cv * 6)) * 20 * 10) / 10)
理由: 同じ平均報酬レートを持つ 2 つのプロバイダーは、まったく異なるステイカー体験を提供できます。大きく低下するプロバイダーは、安定的または上昇し続けるプロバイダーより悪いです。一貫性は委任者が実際に望むもの — 安定的または上昇するレート — を報酬とし、低下のみを深さに比例して罰します。レートが上昇に戻すことは決して罰されません (以前の対称的な測定は罰しており、それは逆でした)。最近の大きな低下はスコアが低くなり、時間の経過とともに回復するにつれてスコアが上がります。
V2参加15 ポイント最大
内容: プロバイダーがモダンV2スタック(FTSO Scaling + Fast Updates + FDC)を実行しているかどうか。
方法: プロトコルごとのスタッキング。アクティブベースライン(リワードレート > 0)+3、V1部分的(提出 + 署名 + 投票者)+4、各V2プロトコル(FTSO Scaling / Fast Updates / FDC)+約2.67各、上限15。非アクティブ → 0。v4.0(2026-05-11)前の全か無かティア(部分的V1 = 完全V2 = 15 — アップグレード動機なし)を、プロトコルごとのボーナスに分割してスタックできるようにしました。
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
理由: V2はネットワークが向かう方向です。v4.0のプロトコルごとのスタッキングはV1部分から完全V2へのアップグレードがスコアを移動することを意味します(修正前はV1部分と完全V2は両方15を返しました)。どの単一V2プロトコルを追加してもこの次元が改善されます。
手数料15 ポイント最大
内容: プロバイダーが委任リワードに対して課す手数料。
方法: ブレークポイント全体の線形補間:0% → 15、5% → 13、10% → 10、15% → 7、20% → 4、≥25% → 0。非アクティブプロバイダー → 0。
anchor = max(lowest active fee observed, protocol fee floor)
// FIP-16 sets a 20% minimum entity fee. All 98 providers charge
// exactly 20%, so the anchor is 20% and nobody is docked for
// charging the only fee the protocol permits. Same curve and
// same anchor the validator page's Fee dimension uses.

if (!isActive) score = 0
d = fee - anchor              // distance ABOVE the best real offer
if (d <= 0)  score = 15       // at or below the anchor → full marks
elif (d <= 5)  score = 15 - d * 0.43
elif (d <= 10) score = 12.9 - (d - 5) * 0.64
elif (d <= 15) score = 9.6 - (d - 10) * 0.86
elif (d <= 20) score = 5.4 - (d - 15) * 1.07
else: score = 0               // extractive
理由: 手数料はデリゲータが受け取る額を直接減らします。線形補間(バケットではなく)は7%手数料が10%と15%の間でスコアされることを意味します。次のバケット境界に手数料を切り下げてもオペレータはクレジットを得られません。
MIRROR参加12(+3ボーナス) ポイント最大
内容: オペレータのP-ChainバリデータノードがアクティブにステイカーにFTSOインフレーション共有を支払うかどうか、およびオーバーパフォーマンスボーナス。
方法: 基本スコアは、MIRRORリワードを支払うオペレーターのnodeIDの割合に比例してスケーリングされます。すべてのノードが活動中 → 12ポイント。部分的 → 比例配分。なし → 0。2026-05-11時点では、「活動中」シグナルは2つの標準ソースから読み込まれます:V2 RewardManager上のオンチェーンRewardClaimed(claimType=3)イベントと公式FSP Merkle JSONのclaimType=3割り当て — どちらかで十分です。アップデート前は、オンチェーンストリームを唯一のシグナルとして使用していましたが、これにより非標準的なクレームパスを介してMIRRORを決済するプロバイダーに対して偽陰性を生じさせました。さらに、オペレーターのバリデーターが期待値(vrm + mirror)/ 期待値の100%を超える配信を一貫して実現する場合、最大+3ポイントのオーバーパフォーマンスボーナスがあります。ベイズ縮小と30日間のデータ蓄積ゲートおよび3ステーク最小サンプルにより、小規模なまたは新規オペレーターは少数の幸運な読み込みでボーナスをゲームしないようになります。
if (no fseNodeIDs) score = 0
if (mirrorStatsMap empty) score = 12 / 2 = 6   // Neutral seed before data lands

activeCount = nodes_with_status_active
fraction = activeCount / fseNodeIDs.length
base = 12 * fraction

// Overperformance bonus per node, applied only when ALL gates pass:
//   - >= 30 days observed since first reading (firstObservedAtMs)
//   - >= 3 paid stake observations
//   - finite medianOverpaymentRatio
// Bayesian shrinkage with prior k=5 toward 1.0 (neutral):
//   shrunken = (observedRatio * N + 1.0 * 5) / (N + 5)
// Bucketed bonus from shrunken:
//   < 1.05 → 0    < 1.15 → 1    < 1.30 → 2    >= 1.30 → 3

avgBonus = sum_per_node(bonus) / fseNodeIDs.length
score = round((base + avgBonus) * 10) / 10
理由: MIRROR参加は、FTSOインフレーションシェアをあなたのステーカーに委譲するものです。V2アクティブなプロバイダーで、バリデーターノードがMIRRORを支払わない場合、同じプロバイダーでアクティブなノードを持つ場合と比べて、委譲者に対して約5~15%少ないリターンを配信しています。オーバーパフォーマンスボーナスは、期待を超える配信を一貫して報酬しますが、小さなサンプルで新しいオペレーターを膨らませることはありません — ベイズ縮小と30日間の蓄積ゲートがそれを公平に保ちます。
委譲者数12 ポイント最大
内容: このプロバイダーに現在委任している個別ウォレットの数。チェーン状態から集計されます。
方法: 5 → 500委譲者を0 → 12にマッピングする対数スケーリング。≤5 → 0、≥500 → 12(キャップ)。バリデーター信頼度次元のカウントシグナルスタイルと一致します。v4.0(2026-05-11):前のバケットスキームが正確に500委譲者で逆説的なインセンティブを持っていた実際のバグを修正しました(修正前:500 → 14、501 → 12 — その境界を越えて委譲者を獲得することで2ポイント失いました)。
if (count <= 5)   score = 0
elif (count >= 500) score = 12
else:
  ratio = log(count / 5) / log(100)   // maps [5, 500] → [0, 1]
  score = round(min(12, max(0, ratio * 12)) * 10) / 10
理由: 委譲者数は信頼シグナルです — ステーク規模とは無関係です。200人の委譲者を持つプロバイダーは200人の独立したステーカーに選ばれており、5人を持つプロバイダーはオペレーター自身の近くに選ばれています。対数スケーリングは~50委譲者を超えて減少するリターンを提供しますが、修正前のバケット化スコアリングのような逆転は決して起こりません。
エポック参加10 ポイント最大
内容: プロバイダーがエポックに積極的に参加しているかどうか。
方法: FSEはプロバイダーをアクティブとしてマーク → 10。プロバイダーはrewardRate > 0(Flaremetrics)を持っていますが、FSEアクティブフラグなし → 7(マーケットデータでアクティブですが、FSE確認なし)。その他 → 0。
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
理由: Flaremetricsが引き続きリストしている場合でも、リワードストリームが失速しているプロバイダーをキャッチします。精度(エポックごとの正確性について)とは異なります — 参加は表示されるかどうかについてです。
投票力の安定性10 ポイント最大
内容: プロバイダーの投票力の日次パーセンテージ変化。
方法: 絶対値の日次パーセンテージ変化の区分的線形。<1% → 10。1% → 3%で線形(10 → 7)。3% → 5%で線形(7 → 4)。5% → 10%で線形(4 → 2)。10%を超えて0に向かって継続します。v4.0(2026-05-11):前のバケットの崖を線形化しました(各しきい値で最大3ポイントの崖)。
change = abs(votePowerDailyChangePct * 100)
if (change < 1)  score = 10
elif (change < 3) score = 10 - (change - 1) * 1.5     // 1 → 10, 3 → 7
elif (change < 5) score = 7  - (change - 3) * 1.5     // 3 → 7,  5 → 4
elif (change < 10) score = 4 - (change - 5) * 0.4     // 5 → 4, 10 → 2
else               score = max(0, 2 - (change - 10) * 0.1)
理由: 投票力の大きな日次変動は、委譲者の波が出入りしていることを示すことが多くあります — テーブルを読むステーカーは移動する目標を見ます。安定した投票力は、スティッキーな委譲者を持つ落ち着いたプロバイダーを示しています。
コンプライアンス10 ポイント最大
内容: プロバイダーがFSPリワードデータでアクティブになってからすべてのリワードエポックで支払われたかどうか。
方法: プロバイダーのアクティブなウィンドウ内でゼロミスエポックの場合、完全な10ポイント。各ミスエポックは3ポイントを控除します(0でクランプ)。FSPデータが利用できない場合は5で中立。v4.4(2026-06-30):ミスエポックは現在、プロバイダーの最初の参加エポックからのみカウントされます — 新しいプロバイダーは、以前存在しなかったエポックでもう課金されなくなります(以前は、新しいが清潔なノードを数週間0/10に保っていました)。
if (no fspData OR totalEpochs <= 0) score = 5

// active window = epochs from the provider's first paid epoch to now
missed = (active-window epochs) - (epochs the provider was paid)
score = max(0, 10 - missed * 3)
理由: 公式Flare Systems Protocolリワード配布でミスエポックはプロバイダーがそのエポックのプロトコルコンプライアンスに失敗したことを意味します — 最小条件、署名ポリシー、など。最初の参加からのみカウントすることで、新しいプロバイダーに対して公平な測定を維持しながら、本当のミスをペナルティします。ミスあたり3ポイントは急勾配であるため、1回のミスは顕著なシグナルですが回復可能です。約3ミスはこの次元をゼロにします。
識別性8 ポイント最大
内容: プロバイダーが実在のブランド名を持っているか、単なる16進数アドレスであるかどうか。
方法: 名前付きブランド(≥4文字、0xで開始しない) → 8。短いまたは匿名(<4文字) → 4。純粋な16進数 / 0xアドレスを名前として → 0。
if (no name) score = 0
elif (name starts with 0x or matches hex regex) score = 0
elif (name.length < 4) score = 4
else score = 8
理由: 名前付きプロバイダーは検索可能で説明責任があることを選択しています — 検索、連絡、公開された約束に保持することができます。アドレスによって匿名のプロバイダーは機能していますが、委譲者がそれらを評価する際に提供する信頼シグナルが少なくなります。
自己ボンド7 ポイント最大
内容: オペレーター自身のP-Chainノードボンド(ゲームのスキン) — 他のユーザーがノードに委譲するステーク除外。サイズ中立的なコミットメントゲート、富の順位付けではありません。
方法: 2つの飽和軸のGREATERで認識されます:(1)整合性 — 総コミットメントステーク(≥10% → 完全)の割合としての自己ボンド;または(2)絶対 — 危険にさらされている自己資本、5M FLRでキャップされるため5MおよびSK80M FLRは同じスコアです。v4.4(2026-06-30):オペレーターの真のP-Chainの自己ボンド(nodeIDでクロスリファレンスされたバリデーターウェイト)から再ソース化 — 以前にそれが読んでいたFlaremetricsフィールドは廃止されたため、すべてのプロバイダーが0でスコアされていました。v4.5(2026-06-30):絶対軸+飽和を追加したため、低比率での大きな自己ボンドは高比率での小さなボンド未満でスコアされず、サイズが勝つことも小さなオペレーターをペナルティしることもありません。
ownBond      = operator's own P-Chain node bond (FLR)
total        = ownBond + delegated WFLR vote power
alignment    = piecewise-linear ratio curve (0% → 0 … ≥10% → 7)
absolute     = min(7, ownBond / 5,000,000 * 7)   // saturates at 5M FLR
score        = max(alignment, absolute)
理由: ゲームのスキン — 自らの資本がリスクにさらされているオペレーターは委譲者と整合しています。しかし、自己ボンドサイズはオペレーター品質の代理ではありません(それは他の次元に存在します)。ため、完全に整合した小さなオペレーターと大きなコミットメント済みのオペレーターの両方が完全なマークを獲得します。自らの資本コミットメントがわずかなオペレーター — 小さな割合と小さな額 — のみが完全以下でスコアされます。
100/100を獲得する方法 — FTSOプロバイダープレイブック
v4.0公正性監査は、すべてのスコア次元を最大化することが本当にあなたを委譲者にとってより良いFTSOプロバイダーにすることを確認するために特別に設計されました。スコアを改善することはシステムをゲームしていません — それはシステムが設計通りに機能しています。以下は次元ごとのプレイブックです。
リワードレート — 25ポイント。エポックあたりネットワークの中央値FSPリワードレートの≥2倍を配信します(手数料後、プロトコル配布後)。0から2倍の中央値までの線形:中央値 → 12.5、2倍の中央値 → 25。これが整合する理由:これはエポックあたり委譲者に実際に到達するドル額です。
精度 — 25ポイント。完全なポイントのためFSE上≥97%の2次バンドランディング率をターゲット。区分的線形なので95% → 18、93% → 16、90% → 13など — すべての1%改善はスコアを移動します。これはエポック参加ではなく価格品質です:投稿された価格のうち、オンチェーンで受け入れられたバンド内にランディングする割合を測定します。精度の高いプロバイダーはコンセンサスに近い価格を公開し;精度の低いプロバイダーは確実に提出していますがオフコンセンサスが多くあります。これが整合する理由:オフバンド提出は、プロバイダーがすべてのエポックに参加していても、委譲者のリワードが少なくなります。下記の別のコンプライアンス次元はエポック参加を追跡します。
一貫性 — 20ポイント。エポックごとのリワードレート分散を最小化します(CV = 最近のエポック全体の標準偏差/平均)。CV = 0 → 20、CV = 0.2+ → 0。これが整合する理由:同じ平均リワードレートを持つ2つのプロバイダーは同等ではありません — 予測可能な支払いはステーカーUXにとって変動性があるものより優れています。
V2参加 — 15ポイント。スタックプロトコルは追加的に:アクティブベースライン + V1部分登録 + 各V2プロトコル(スケーリング、FastUpdates、FDC)。完全V2 +アクティブ+ V1登録 = 15。これが整合する理由:V2はネットワークが向かっている場所です。採用する追加のプロトコルはそれぞれ、委譲者が利益を得る前方への投資です。
手数料 — 15ポイント。≤5%で13ポイント、0%で15ポイント。5%/10%/15%/20%/25%のしきい値を超えて0に対する区分的線形ランプ。これが整合する理由:より低い手数料 = より多くのリワードが委譲者に直接到達します。
MIRROR参加 — 12 +最大3ボーナス。オペレーターのすべてのP-Chainバリデーターノードをミラーアクティブとして実行します(オンチェーンRewardClaimedイベントまたはFSP Merkle JSON割り当てのいずれかを介して — v3.6デュアルソース)。30日間の観測後に≥3の支払いステーク上で継続的なオーバーパフォーマンス(中央値(vrm+mirror)/期待比率が1.05を超える)は最大+3ボーナスを獲得します。これが整合する理由:MIRRORはあなたの委譲者のFTSOインフレーションシェアです。MIRRORを支払わないノードはステーカーに5-15%少ないリターンを配信します。
委譲者数 — 12ポイント。対数スケーリング5 → 500委譲者を0 → 12にマッピング。くじラの小数に依存せずに独立したステーカーのベースを構築してください。これが整合する理由:カウントはステーク規模と無関係な信頼シグナル;200人の委譲者があなたを選ぶことは200の独立した推奨を意味します。
エポック参加 — 10ポイント。すべてのエポックに正のリワードレートとアクティブなFSEフラグで表示されます。これが整合する理由:エポックごとの次元が見逃す可能性がある失速したリワードストリームをキャッチします。
安定性 — 10 点 日単位の投票力の変化を1%未満に保つ。それ以降は段階的な線形増加。整合性:安定した投票力は安定した委任者(粘着性のあるコミュニティ)を示し、一時的なクジラの波ではなく。
コンプライアンス — 10 点 FSPデータでのミスされた報酬エポック。各ミスは3点のコスト;約3ミスでディメンションはゼロになります。これは参加です、価格品質ではありません:プロバイダーが最小条件、署名ポリシー、またはその他のプロトコル要件を見落としたペナルティを受けたエポックをカウントします。これは上記の精度ディメンション(インバンド価格着地をスコア化)とは異なります。整合性:プロトコルの独自の報酬配布でミスされたエポックは、プロバイダーが最小条件を失敗し、委任者がそのエポックで何も獲得しなかったことを意味します。プロバイダーは参加されたエポックで優れた精度を持ち、それでもエポック全体をミスすることができます。
身元確認 — 8 点 FlaremetricsまたはFSEに実際のブランド名(≥4文字、16進アドレスではない)を登録します。アドレス別の匿名プロバイダーは0、命名されたプロバイダーは8スコアです。整合性:命名されたプロバイダーは検索可能で説明責任があります。これが基本的な信頼シグナルです。
自己ボンド — 7 点 自分のP-チェーンノードボンド(他のボンドされた賭けではない)をコミットします。総賭けの意味のあるシェア(≥10%)OR意味のある絶対額(絶対軸は5M FLRで飽和するため、大規模なオペレーターは規模で小さいものを上回ることはできません)のいずれかで満点。整合性:スキン・イン・ザ・ゲーム — 独自の資本をリスクに晒すオペレーターは、委任者の利回り結果を共有します。これは関連は誰もが最大化でき、運用品質は他のディメンションで判断されるため、規模ニュートラルなコミットメントゲート(富ランキングではありません)。小さなオペレーターと大規模にコミットされたもの両方。
時間制限されたシグナル:ショートカットできません: 一貫性は≥3エポックの履歴が必要です。MIRRORオーバーパフォーマンスボーナスは30日間の観察と≥3払い済みステークサンプルが必要です。コンプライアンスはエポックをカウントするのに十分なFSPデータが必要です。実績を構築する;スコアが続く。
生スコアは12の評価対象ディメンション全体で最大172に合計され、その後100に正規化されます。完全な入力実行は172/172 → 100と表示されます。投票力希釈ペナルティは最大-3ポイントで、非常に大規模なプロバイダー(>1.34B VP)に対してタイブレーカーとして適用されます。
独自のスコアを検証する方法
プロバイダーテーブルのすべてのスコアは公開データから再現可能です。あなたがオペレーターであり、ここでの数学がで見たスコアと一致しない場合、正しい動きはあなたがエラーを犯したと仮定する前にそれを自分で検証することです。ウォークスルー:
  1. プロバイダーの公開統計を検索 flaremetrics.io(名前で検索または委任アドレスを貼り付け)。fspRewardRate、delegationFeePercentage、wNatWeight、votePowerDailyChangePctをメモします。
  2. FTSO V2 + 精度を検証 flare-systems-explorer.flare.networkにて。エンティティを見つけます。精度に関してはprovidersuccessrate.secondaryをチェック、V2ステータスに関してはentityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdcフラグをチェックします。
  3. MIRROR参加を確認 V2 RewardManagerコントラクト上 flare-explorer.flare.network経由。claimType=3でRewardClaimedイベントを見つけ、nodeIDを参照します。最近いずれかのノード向けのなくない場合は、スコアでMIRROR非アクティブとして表示されます。
  4. 上記の式に入力を代入してください。各次元のコードブロックは、実行するべき正確な演算を示しています。次元を合計し、172(生の最大値)で除算し、100を掛けると、生の複合スコアが得られます。
  5. 大きい場合は希釈ペナルティを適用。1.34B上の投票力は−3、1B上は−1。以下のファイナルスコアカードに正確なしきい値があります。
  6. 表示されたスコアと比較。表示されたスコアは動的重み再配分を反映します — ほとんどのプロバイダーがディメンションでクラスタリングされる場合(アクティブセット全体で低い標準偏差)、そのディメンションの重みは広がりが広いディメンションに再配分されます。各プロバイダー行のスコア分解パネルは現在のディメンションごとの値を示します。
  7. 数学が追加されない場合、 メール [email protected] 委任アドレス、使用した入力、および計算したスコアとともに。対応します。エラーを犯した場合は、公開で修正します。
一般的なオペレータの懸念
私の報酬レートは中央値を上回っていますが、報酬レートスコアは25/25ではありません — なぜですか?
報酬レートは中央値への比率で線形です:スコア = 比率×12.5、したがって1.0×中央値 = 12.5/25で、キャップを達成するには2.0×比率が必要です。中央値の1.2倍のプロバイダーは15でスコアリング、1.5倍はスコア〜18.8で、2.0倍は完全な25でスコアリングします。キャップ(および3×中央値の異常フィルター)は、単一の異常に高い報酬エポックがディメンションを支配できないため存在します。レートが一貫して上位10分位数の場合、スコアは引き続き大きく報われます。
V2にアップグレードしたばかり — V2スコアはいつ更新されますか?
V2ステータスはFSEのentityminimalconditionslatest フラグ(ftso_scaling、ftso_fast_updates、fdc)から来ています。v4.0以降、ディメンションはプロトコル単位でスタック:アクティブベースライン+3、V1登録(送信+署名+投票者)+4、および各V2プロトコル+〜2.67。投票者登録されたプロバイダーは、送信+署名アドレスを持ちますが、3つのV2プロトコルのいずれでもないスコア7/15、およびあなたがすべてのV2プロトコルを有効にするすべての個々のV2プロトコル — すべての3つのライブは完全な15を取得します。変更は、FSEがそれらを反映した後の次のFlareWatch cron実行(5分ごと)に引き継がれます。
FSEでの精度は96%ですが、期待よりも低くスコアリングしています。
精度ディメンションはFSEの二次精度メトリック(94–97%帯で高い解像度、ほとんどのプロバイダーがクラスタリング)を使用します。95–96%は18 pts;完全な25のために≥97%が必要です。バケットは、95–97%帯のわずかな何パーセントが、プロバイダー間の実際のパフォーマンス分離を表すため、上部で厳しい。
MIRRORを提供します — FlareWatchなぜプロバイダースコアでMIRROR非アクティブとして表示されますか?
2026-05-11の時点で、MIRROR参加は2つのソースから検出されます:V2 RewardManager上のオンチェーン RewardClaimed(claimType=3)イベント、AND公式FSP Merkle JSONのclaimType=3割り当て。いずれかのソースに表示されるnodeIDはアクティブなカウントとして機能します。複数ノードオペレーターの場合、スコアはアクティブなノードの割合を使用します(1/3アクティブ = 4/12ベースなど)。次のスイープサイクル後に分類される必要があるノード。メールボックス最後にnodeIDと特定のエポックが表示されると予想されます — 両方のソースをクロスチェックします。
昨日、投票力が8%移動しました — なぜ安定性スコアが〜2.8/10ですか?
投票力の安定性は、絶対的な日単位の変化で線形(v4.0で線形化 — バケットの崖なし):<1% → 10、1→3%を7にランプ、3→5%を4に、5→10%を2に、その後10%を超えて0に向かう。8%の移動は5–10%のランプに4 − (8 − 5)×0.4 = 2.8で着地します。意図は、意味のある委任者の変動を経験しているプロバイダーにフラグを立てることで、ステーカーはテーブルでそれを見ることができます。投票力が安定するとすぐにスコアが回復します。1つの揮発性の日はあなたを永遠に低く固定しません。
プロバイダーはエンティティアドレス(0x…)で名前が付けられています。身元確認スコアが0なのはなぜですか?
身元確認は、実際のブランド名(≥4文字、0xで始まるまたは16進数のみではない)で8 pts、純粋アドレス名で0を授与します。名前を製造できません — Flaremetricsでprofile.nameを設定すると、次のcron実行で取得します。エンティティにプロフィールがあるが、名前フィールドが空の場合も同じです。
小さいがコミットされた委任者ベースを持っています — なぜ委任者カウントスコアが上限に達しているのですか?
デリゲーター数は実際の数を使用します。WFLRを保有する全ウォレットをオンチェーンで確認し、現在の委任状況を確認して、各プロバイダーの個別デリゲーター数を集計します(約6時間ごとに更新、独立したイベント台帳と照合)。v4.0以降は、5 → 500デリゲーター を 0 → 12ポイント に対数スケーリングし、500でキャップされています(≤5は0スコア)。対数スケーリングにより、デリゲーター数成長の強い小規模プロバイダーが最速で上昇します。約50デリゲーターを超えると、追加のデリゲーターはダイヤルの動きを抑制します。ただし曲線は単調であるため、デリゲーターを獲得してもスコアが低下することはありません(v4.0以前のバケットは低下の可能性がありました)。
ノードを追加した後、スコアが低下しました — 何が起こったのですか?
新しいノードがまだclaimType=3 MIRRORイベントを表示していない場合、MIRROR分数がドロップします(例:1/1 = 100%から1/2 = 50%)、MIRROR参加ベーススコアを削減します。新しいノードがMIRRORの支払いを開始したら(通常、アクティベーション後1〜2つの報酬エポック内)、分数が回復し、スコアが登る。
スコアに異議を唱えるか、手動レビューをリクエストできますか?
はい。メール [email protected] 委任アドレスと特定の懸念とともに。すべてのオペレーターに対応します。我々は行動を起こします:MIRROR分類の修正、ディメンション固有の数学エラー、Flaremetrics経由の名前/ロゴ修正。我々が行動しないもの:アルゴリズムの外側でスコアを手動で上げるリクエスト、競合他社を除外またはダウンランク化するリクエスト。
すること/しないこと
スコアの操作方法の曖昧性を削除するために以下は明示的なコミットメントです。これらのいずれかを違反することがあれば、ドキュメント化してメール [email protected] — 公開で修正します。
✓
スコアが高い、スポンサー配置、または好意的な取り扱いの支払いを受け入れません。スコアは公開データから決定論的に計算されます。
✓
手描きのプロバイダーバンプを編成しません。「Xは+5を取得します。彼らが好きだから」行がコードのどこにもありません。同じアルゴリズムがFlareWatchの独自のプロバイダーを含むすべてのプロバイダーに適用され、この正確な関数によってスコア付けされます。
✓
非公開の理由でプロバイダーを除外しません。リストはFlaremetrics + FSEに由来します。当社の表示には、これらのソースが表示するすべてのアクティブプロバイダーが含まれています。
✓
アルゴリズムの変更を公開します。バージョンが更新されるたびに、このページのバージョンカードに変更内容と理由が記載されます。大きな変更の場合は、アプリのチェンジログページからアクセスできる追加のチェンジログエントリが表示されます。
✓
オペレーターのメールに対応します。スコアに関する実質的な懸念を[email protected]にメールで送信するすべてのオペレーターには、数営業日以内に実際の対応を行います。
✓
当社の誤りを公開で訂正します。アルゴリズムのバグ、データソースのエラー、または方法論のギャップが発見された場合、修正を実施し記録します。黙ったままランキングを変更することはありません。
✗
送信者の許可なくメールの内容を公開で共有することはなく、オペレーターのメールはそのメールが生み出したスコア会話以外に使用しません。
✗
アルゴリズム変更の将来計画を特定のオペレーターに事前に共有することはなく、すべてのバージョンは同時にすべてのユーザーに公開されます。
最終スコア(次元の組み合わせ)
スコア対象の12項目すべてが合計され、生の複合スコア(最大172)が得られます。生の複合スコアは0~100スケールに正規化され、その後、動的ウェイト再分配が適用されて最終表示スコアが算出されます。
// Step 1 — Raw composite (sum of 12 dimensions, max 172)
raw = rewardRate + accuracy + consistency + v2 + fee + mirror
    + delegators + participation + stability + compliance
    + identity + selfBond

// An UNMEASURED reward rate is not a FAILED one. When a provider is
// demonstrably distributing but we hold no rate figure for it, the
// Reward Rate weight leaves the DENOMINATOR rather than scoring 0
// against it — we score what we measured, over what we could measure.
maxRaw = (rewardRate figure missing AND isActive) ? 172 - 25 : 172
normalized = round((raw / maxRaw) * 100)

// (The separate vote-power dilution penalty was REMOVED in v4.9. It
//  double-counted: an over-cap provider already earns a below-median
//  realized reward rate, so the median-anchored Reward Rate dimension
//  docks it for dilution once. Cap proximity is now a neutral DISPLAY
//  signal on every provider, not a second deduction in the score.)

// Step 2 — Dynamic weight redistribution
//   Across the active provider set, dimensions where everyone clusters
//   (stddev < 1.0) become non-discriminating. Their weight gets
//   redistributed evenly across dimensions where the spread is wider
//   (stddev >= 1.0). The redistribution recomputes the score:
//
//   for each dim d:
//     multiplier[d] = 1.0                 if stddev[d] < 1.0
//                   = (weight[d] + bonus) / weight[d]   otherwise
//   bonus = sum(weights of low-stddev dims) / count(high-stddev dims)
//
//   adjusted_raw = sum(breakdown[d] * multiplier[d])
//   adjusted_max = sum(weight[d]    * multiplier[d])
//   final = round((adjusted_raw / adjusted_max) * 100)

// Step 3 — Final score (capped at 100)
score = min(100, final)
キャップ接近度は表示シグナルであり、スコア減点ではありません。v4.9までは、スコアは非常に大きなプロバイダーから1~3ポイントを一律に減算していました。しかし、これは二重計算でした。キャップ超過プロバイダーは既に中央値以下の実現報酬率を得ており、これは中央値固定の報酬率ディメンションで一度スコア化されています。そのため、ペナルティは削除されました。現在、すべてのプロバイダーはFSPキャップ(WNatコントラクトのライブ総投票力の2.5%)をどの程度満たしているかを、ニュートラルな限界委任シグナルとして表示します。100%に近いほど、新しい委任がより希薄化します。
表示層の外れ値フラグ:現在のリワードレートがフィールド中央値より3倍以上のロバスト偏差(中央絶対偏差、スケール×1.4826)上にあり、かつ少なくとも50%以上高いプロバイダーは、プロバイダーテーブルに「外れ値」バッジを付与されます。このバッジはスコアを変更しません。スコア自体のアノマリーガードは、スコアリング前に3倍中央値を超えるレートを個別に制限します。アニュアライズされたエポックレートのスパイクは通常、投票力が非常に小さいことが原因であり、エポック内で正常化します。
データソース(すべての入力は公開)
Flareコントラクト、オンチェーンから直接読み取り:登録されたプロバイダーセット(VoterRegistry)、エンティティ→委任アドレスおよびnodeIDリンク、送信/署名アドレス登録(EntityManager)、委任投票力(WNat)、および委任手数料(WNatDelegationFee)。これにより、プロバイダーリストが単一のインデックスに依存しなくなります。リワードエポック420では、チェーンが98登録プロバイダーを保持していたのに対し、サードパーティリストでは80で、ギャップの18は以前このサイトから完全に欠落していました。
Flaremetrics公開API:報酬レート、委任手数料、投票力、投票力の日次変化、ロック済み投票力(自己ボンド)、プロファイル名+ロゴ+地域、fspRewardRate。
Flare Systems Explorer (FSE): FTSO精度(プライマリ+セカンダリ)、V2ステータスフラグ(ftso_scaling、ftso_fast_updates、fdc)、エンティティアドレスリンケージ、署名/送信アドレスの存在、投票者登録、P-Chain nodeIDリンケージ、およびエンティティごとの委任報酬率(reward_rate_wnat)。報酬率は意図的にFSEとFlaremetricsの両方から取得されています:両者は異なるユニット(FSE小数形式、Flaremetrics百分率形式)で同じ数字を公開しており、両方の形式を持つ72社全てで小数点以下5桁まで一致することが確認されており、FSEは154のエンティティをカバーしているのに対しFlaremetricsは80社です。いずれかのソース単独では、プロバイダーが責任なく報酬率を取得できないケースが生じます。
Flare Systems Protocolの報酬データ(FSP):エポックごと、プロバイダーごとの報酬配分。Compliance次元で使用(報酬なしのエポックをカウント)し、委任報酬合計の信頼できるソースとして機能します。
V2 RewardManager(claimType=3イベント):バリデーターノードIDごとにオンチェーンで請求されたMIRROR配分。タイプ3に厳密にフィルタリング。VRM、FTSO委任、またはDIRECT報酬との混同なし。FlareWatchの独自インデクサーがMIRROR Participation次元に対してこれらを表示します。
FSP Merkle JSON(claimType=3配分):エポックごとにMIRRORを受け取る資格がある人の正規の公表記録(Flareの署名ツール自身が読み込むのと同じデータ)。2026-05-11に第2の信頼できるソースとして追加。MIRRORが配分されているがまだオンチェーンで請求されていないバリデーターをキャッチします。
FlareWatchの履歴スナップショット:エポックごとの報酬レートがConsistency CVに供給され、バリデーターごとの支払いステーク観測がMIRRORの過剰実績ボーナスに供給されます(30日のデータ蓄積ゲート付き)。
スコアに含まれていないもの
• 自己宣伝または有料掲載。プロバイダーは報酬を支払ったりスポンサーしたりしてより高いスコアを取得することはできません。
• 手動でコード化されたプロバイダー固有の加算。「Xは好きだから+5」のような行はコードの任意の場所にもありません。FlareWatchの独自プロバイダーを含め、すべてのプロバイダーに同じアルゴリズムが適用され、このまさに同じ関数でスコア付けされます。
• 主観的なインフラストラクチャの品質。FSEとFlaremetricsが公開データとして表示する内容を超えた稼働時間SLA、地理的分散、またはハードウェアスペックの評価は試みません。
• FlareWatchへのロックアップまたはコミットメント。FlareWatchと別のツールを使用するステーカーに対して利利用に対する好意的なスコアリングはありません。
• まだ接続されていない将来のシグナル。コミュニティの存在(確認済みのソーシャル、ガバナンス参加)、過去のスラッシング、応答レイテンシー、エポックごとのトレンドラインは将来のバージョンの対象範囲ですが、v3では含まれていません。秘密に重み付けされているものはありません。
オペレーターのフィードバック
プロバイダーのスコアに何か異なる点がありますか?[email protected]に委任アドレスと懸念事項をメールで送信してください。すべてのオペレーターに対応します。対応する一般的なリクエスト:
  • MIRROR分類の修正(claimType=3によるノードIDへの帰属)。
  • 使用した入力に対する次元固有の数学エラー。
  • FlaremetricsまたはFSE経由での名前/ロゴ/プロファイル修正。
  • アルゴリズムに対する一般的な批評。
ソースとリファレンス
スコアへのすべての入力は、公開で検証可能なFlareエコシステムソースから取得されます。誰でも、これらのプライマリソースに対する当社の主張をクロスチェックし、生データから数学を再現することができます。このページと上流のソースが言っていることの間に不一致を見つけた場合は、[email protected]にメールで送信してください。当社が修正します。
信頼できるプロトコルドキュメント。FTSO V2、FSP、P-Chain検証、FAssets、およびFlareスタックの他の部分をカバーしています。
Flareガバナンスポータル(FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals。V2プロトコルの最小条件、手数料メカニクス、およびこのスコアに関連する報酬経済学の変更の真実の源。
Flare Systems Explorer(FSE) ↗https://flare-systems-explorer.flare.network
FTSOデータプロバイダー、エンティティアドレス、P-ChainノードIDリンク、および最小条件フラグのFlare公式レジストリ。Accuracy、V2、およびParticipation次元の主要ソース。
Flaremetrics ↗https://flaremetrics.io
独立したFlareエコシステムのメトリクスプロバイダー。報酬レート、手数料、投票力、投票力の日次変化、ロック済み投票力、プロファイル名+ロゴ、およびfspRewardRateメトリクスのソース。
Flareブロックエクスプローラー ↗https://flare-explorer.flare.network
すべてのオンチェーン状態の読み取り専用ブラウザー。誰でもV2 RewardManagerのRewardClaimedイベント(MIRROR用claimType=3)、報酬エポックの遷移、およびその他を検証できます。
Flare Foundation報酬スクリプトリポジトリ ↗https://github.com/flare-foundation/reward-scripts
バリデーターごとに配分された報酬を示すFlare Foundationが公開するエポックごとのJSON。間接的な入力。FlareWatchのステーク別観測インデクサー経由のMIRROR過剰実績ボーナス計算を供給。
Flaremetrics 公開 API(FTSO プロバイダー) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
当社の cron が消費する正確なエンドポイント。エンティティプロフィール、報酬レート、手数料、投票力を返します。誰でも直接アクセスできます。
Flaremetrics 公開 API(ノード登録) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID 変換テーブル。このテーブルをページネーションして、MIRROR Participation ディメンションを駆動するエンティティ対 NodeID ルックアップを構築します。
プライベートデータなし、クローズドソースのモデルなし。スコアリングアルゴリズムは FlareWatch コードベースの services/ftso/scoring.ts に実装されています。実装を直接検査したい(上記の説明と公式だけを読む代わりに)か、独自の用途にフォークしたい場合は、[email protected] にメールを送信してアクセスをリクエストしてください。本当の需要があれば、ファイルをスタンドアロンのオープンソースパッケージとして公開します。
スコアの更新方法
FTSO プロバイダースコアリングは /api/cron/refresh-validators の cron 内のパスとして実行され、アクティブなすべてのプロバイダーのスコアを 5 分ごと に再計算します(P-Chain バリデーターの再スコア付けと同じ実行)。入力(Flaremetrics、FSE、FSP 報酬、V2 RewardManager イベント)は毎回の実行時に新しく取得されます。
Consistency CV は最近のエポック履歴を使用します — ローリングウィンドウがシフトすると、ディメンションは変動します。3 未満の履歴エポックを持つ新規プロバイダーは、十分なデータが蓄積されるまでニュートラルな 10 をスコアします。
動的ウェイト再配分は毎回の実行時に再計算されます。現在のアクティブプロバイダーセットに基づいて計算されます。プロバイダーが移動すると(例:V2 アップグレードの波)、非差別化になるディメンションがシフトし、再配分が自動的に適応します。
アルゴリズムのバージョンはこのページのヘッダーに記載されています。新しいバージョンをリリースすると、ここのバージョン文字列が変更され、下記の Versions カードが変更内容を記録します。
バージョン
v4.8(2026-08-20)—Accuracyは難しい報酬バンドに報酬を与えるようになりました。以前はFTSOセカンダリ(広い)バンドのみを使用していました。ほぼすべての実績のあるプロバイダーがランディング95–99%。そのため、この次元はフィールドのトップでほぼ25/25で、測定としてほぼ意味をなしていません。プライマリ(タイト四分位範囲)バンドは本当に難しいエンジニアリングで、プロバイダーを~28–80%に分散させます。Flareはこれらのバンドに40% primary / 60% secondary(FIP.11、2024年から稼働、さらなるセカンダリバンド増加が示唆)で報酬を与えるため、Accuracyは現在その40/60ブレンドを反映しています。セカンダリは以前の曲線を維持。プライマリは絶対曲線を使用(28% → 0、78% → 完全25)。スコアがプロバイダーの独自入力から再算出可能になるよう固定されています。スコア対象の全100プロバイダーの完全な前後比較を実施し、配信前にアーカイブされました。並べ替えはプライマリバンド強度を追跡—難しいタイト帯域作業をするプロバイダーは上昇。簡単なセカンダリ数で成功しているだけのプロバイダーは低下。同じルールは当社プロバイダーにも適用されます。現在プライマリバンドが弱い場合は、84から77に低下し、数段階下がります。それでも配信—エンジニアリングの実績に報酬を与えるスコア、たとえ競合他社のものであり、当社の負担であっても、公開する価値のあるスコアはそのような種類だけです。
v4.7(2026-07-31)— プロバイダーリストが単一インデックスへの依存を停止し、スコアが独自のデータギャップへのペナルティを停止しました。(1) リストはオンチェーン登録投票者セットから構築され、サードパーティインデックスがエンティティを欠いている場所でバックフィルされるようになりました:以前表示されていた80社に対して98社のプロバイダーとなり、従来検索不可能で委任元としてアクセス不可だった18社の実プロバイダーが表示されます。(2) 「アクティブ」は「そのインデックスから報酬率を持つ」を意味していたため、バックフィルされたすべてのプロバイダーについて、独自のFSPデータが毎エポック支払いを示していても、手数料(15)およびV2(15)ディメンションがゼロになっていました。現在は配分エビデンスを受け入れます。(3) 欠落している報酬率はもう全分母に対して0とスコアされず、25ポイントの重みは分母から除外されるため、プロバイダーは測定した内容でスコアされ、測定できなかった内容でペナルティを受けません。(4) 手数料ディメンションはFIP-16前曲線でスコアされていました。FIP-16は20%を最小法定エンティティ手数料にし、98社全てがちょうどそれを請求しているため、ディメンションは全体で4.00/15を付与し分散がゼロでした — 誰も得られない11ポイント、最高スコアを含むすべての公開スコアから約4.3ポイント相当が失われていました。手数料は現在max(観察された最低手数料, プロトコルフロア)にアンカーされ、Granite フォーク以降Validator ページと同じ方法です:法定最小値を請求すれば満点を得られ、それを超える手数料のみがペナルティされます。これにより各スコアが同程度上昇し、ランキングは変わりません。公開済み率を持つプロバイダーは(1)から(3)の変更の影響を受けません。報酬率は推定または推論されません:それらの行は「データなし」と表示されます。(5) 報酬率はもう単一インデックスに依存しません。Flaremetrics単独から読まれていたため、そのインデックスがカバーを停止したプロバイダーはNet/Gross APRを失い、報酬率で0/25をスコアされました — 他社のカバレッジギャップに対する25ポイントのペナルティ。Flare Systems Explorerは同じ数字を公開し、より多くのエンティティをカバーしているため、ギャップを埋めるようになりました;ライブのFlaremetrics率は上書きされません。これが公開された日に、報酬率がなかった15社のプロバイダーに公開済み率を復元しました。
v4.6(2026-07-01)— 新しいノード向けの Consistency 非バイアス化。従来は完全な 30 エポック履歴の報酬レートの平均/標準偏差でしたが、新しいノードのランプアップインフレした最初の稼ぎエポック(投票力が小さい→単位あたりのレートが高く、その後正規化される)は、それが古くなるまで数ヶ月間 CV を高く保つ(スコア 0)異常値として機能していました。現在は、トレーリングウィンドウ(最後の 12 稼ぎエポック)と堅牢な中央絶対偏差の分散を使用します。ランプアップエポックは無害な異常値のままですが、真の継続的なボラティリティはまだ低くスコアされます。
v4.5(2026-06-30)— Self-Bond をサイズニュートラル化。比率のみのカーブでは、低い比率での大きな絶対 self-bond が高い比率での小さな self-bond より低くスコアされる可能性がありました。Self-Bond は現在、アラインメント比率または飽和絶対金額(5M FLR 上限)のいずれか大きい方をクレジットします。大規模なコミットしたオペレーターと小規模な完全にアラインされたものの両方が満点を獲得します。これはコミットメントを報酬として与え、財力ではなく、バリデーター品質は他のディメンションに留まります。
v4.4(2026-06-30)— 2 つの本当のバグ修正。(1)Self-Bond は DEAD ディメンションでした:API がドロップしていた Flaremetrics フィールドを読み込んでいたため、すべてのプロバイダーは 0/7 をスコアしていました。オペレーターの真の P-Chain ノード self-bond から再ソース化されました(バリデーターセットから nodeID で相互参照)。(2)Compliance はプロバイダーがアクティブになる前のエポックにペナルティを与えなくなりました — 起動以降、きれいに稼いでいる新しいノードは、それより前のすべてのエポックでチャージされていたため、数週間は 0/10 のままでした。見落とされたエポックは現在、各プロバイダーのアクティブウィンドウ内でのみカウントされます。
v4.3(2026-06-03)— 方法論の明確化、スコアリング数学の変更なし。Accuracy ディメンションは現在、オンチェーンのセカンダリバンドランディングレート(価格品質 — 提出された価格のうちどの部分が受け入れられたバンド内に着地するか)として明示的に定義されており、Compliance ディメンションとは異なります。Compliance ディメンションは見落とされた報酬エポック(FSP PARTICIPATION)をカウントします。このページとバリデーターテーブルのツールチップは、区別を明示的にするために書き直されており、Accuracy と並んで Compliance 列が追加されました。両方のディメンションは以前のウェイト(25 および 10)と入力(fseAccuracySecondary および epochsWithoutRewards)を保持します。
v4.2(2026-05-20)— Rewards Distributed ディメンション修復。プロバイダーの v3 API がドロップしていた Flaremetrics 報酬配分フィールドに接続されていたため、ディメンションがすべてのプロバイダーについて 0 を読み取り、何も貢献していませんでした。オンチェーン FSP デリゲーション報酬合計に再接続されました — Compliance ディメンションが既に集約している同じ報酬クレームデータ — ディメンションが再度差別化されます。
v4.1(2026-05-20)— Compliance ディメンション固定。epochsWithoutRewards は FSP 報酬 cron がローリングウィンドウを過ぎてエポック存在カウントを蓄積するため負の値で到着する可能性があり、Compliance がその 10 ポイント上限を超える(約 58 に達するまで観測される)ことができ、複合体を最大値を超えて推し進めました — 約 70% のプロバイダーをフラット 100 で飽和させました。Compliance はそのウェイトに固定されており、FSP cron はウィンドウごとにステートレスに報酬サマリーを再計算して、カウントがドリフトしなくなります。
v4.0(2026-05-11)— バリデータースコアの v4.0 リリースと同等の完全な公平性監査パス。2 つの本当のバグ修正:(1)Delegator Count は 500 で逆インセンティブを持っていました — 修正前の 500 デリゲータバケットは 14 ポイントを返しましたが、>500 上限は基礎 WEIGHT_DELEGATORS(12)を返しました。そのため、その境界を越えてデリゲータを獲得することで 2 ポイント失われました。現在は 5 → 500 からログスケール化、単調上昇です。(2)V2 Participation ティアが崩壊しました — 部分的な V1 登録と完全な V2(Scaling + FastUpdates + FDC)の両方が 15 を返したため、部分から完全な V2 へアップグレードしても、スコア改善がありませんでした。現在、プロトコルごとのスタッキング(アクティブ +3、V1 +4、各 V2 プロトコル +約 2.67)です。Accuracy(97% で 7 ポイントの崖があった)、Stability、Self-Bond Ratio の境界崖を排除し、すべて線形化しました。バケット境界で値が保存されています。Reward Rate カーブが再バランスされたため、中央値 = ディメンションのポイントの半分(従来は 40%)。Reward Rate カーブが再バランスされたため、中央値 = ディメンションのポイントの半分。パッチを当てられたディメンションドキュメント文字列を実際のウェイト値と調整しました。ネット効果:すべてのディメンションが入力軸で単調に上昇し、プロバイダーが実際の運用メトリック向上させることで FlareWatch スコアを低下させることはできません。
v3(2026-05-09 → 2026-05-11)— 動的ウェイト再配分と投票力希釈ペナルティを備えた 13 ディメンションスコアリング。MIRROR Participation は第 1 クラスディメンションとして導入されました(12 ベース + ベイズ縮小を伴う最大 +3 オーバーパフォーマンスボーナスと 30 日間のデータ蓄積ゲート)。Identity と Self-Bond が個別のディメンションとして追加されました。Reward Rate は中央値アンカー付きに移動しました。Accuracy は高解像度バンド用に FSE セカンダリメトリックを使用します。Consistency は最近のエポック全体で CV を使用します。
v2 以前 — v3 より前のバージョンは記載されていません。これらはより単純なディメンションのサブセットを使用し、動的ウェイト再配分より前のものです。現在のモデルを支持して廃止されたバージョン。
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.