FTSO-Provider-Score-Methodologie

Algorithmus-Version: v4.11 · Letztes Update: 04.07.2026

FlareWatch weist jedem FTSO-Datenprovider einen Composite-Score von 0–100 über 12 bewertete Dimensionen zu. Die Mathematik ist deterministisch, die Eingaben sind öffentliche On-Chain- und Flare-Ökosystem-Daten.[Flaremetrics] [FSE] [Flare Explorer], und der gleiche Algorithmus wird auf jeden Provider angewendet — einschließlich FlareWatch's eigenem FTSO-Provider, der durch diese genaue Funktion ohne Spezialbehandlung bewertet wird. Diese Seite dokumentiert jede Dimension und Schwelle, sodass Delegatoren und Operatoren genau sehen können, wie der Score berechnet wird und warum jeder Wert gewählt wurde. Jeder Anspruch hier verlinkt zurück zu seiner primären Upstream-Quelle — siehe Quellen und Referenzen am unteren Ende.

Umfang: diese Seite dokumentiert die FTSO-Provider-Bewertung — was Sie im Delegierungsmodus auf der Validatoren-Seite sehen (Delegierung von WFLR an FTSO-Datenprovider für den FTSO-Inflationsanteil). Die Validator-Bewertung, die im Staking-Modus angezeigt wird (Delegierung von FLR an einen P-Chain-Validator für VRM + MIRROR Rewards), verwendet einen separaten 9-Dimensions-Algorithmus, der sich auf Validator-Betrieb konzentriert — Verfügbarkeit, Gebühren, Zuverlässigkeit usw. Sie sind unterschiedliche On-Chain-Rollen mit unterschiedlichen Rewards und werden separat bewertet. Siehe Validator Score Methodology für die Staking-Seite.
FLR / SGB Chain-Abdeckung: die Delegierungs-Registerkarte auf der Validatoren-Seite hat einen FLR / SGB Umschalter für Wallets, die Songbird (SGB) halten. Diese Methodik dokumentiert nur die FLR-seitige Bewertung. Songbird FTSO Provider werden ohne zusammengesetzte Bewertung aufgelistet — die gleichen Genauigkeits- / Konsistenz- / FSP-Rewards-Daten, die wir für FLR verwenden, sind in unsere Songbird-Pipeline noch nicht integriert (Flaremetrics, unsere primäre FLR-Datenquelle, deckt Songbird nicht ab). Das sehen SGB-Delegierer heute: Provider-Name + Logo aus der netzwerkübergreifenden TowoLabs-Registry, aktuelles Gewicht (WSGB delegiert, direkt aus dem WNat-Vertrag von Songbird über unser eigenes Songbird RPC gelesen) und die Provider-URL. Nach Gewicht sortieren; größeres Gewicht ist das Proxy-Signal, bis Genauigkeitsdaten verfügbar sind. Wenn wir die Songbird-seitige Genauigkeits- + Reward-Rate-Pipeline integrieren, wird die gleiche 13-Dimensions-Formel auf SGB Provider angewendet — kein neuer Scoring-Algorithmus, nur die FLR-Formel auf Songbird-Daten angewendet. Die FlareWatch-Validator-Bewertung (Staking-Registerkarte) hat gar kein SGB-Äquivalent: Der P-Chain-Validator-Satz von Songbird ist auf von der Flare Foundation genehmigte Entitäten beschränkt, daher ist Retail SGB P-Chain-Delegierung selten und die Staking-Registerkarte bleibt nur FLR.
Bewertungsstufen
90+Oberste Stufe — obere ~10–20% der FTSO Provider. Typisches Profil: überdurchschnittliche Reward-Rate, hohe Genauigkeit, vollständige V2-Protokollteilnahme (FTSO Scaling + Fast Updates + FDC), niedrige/keine Gebühr, große Delegierer-Basis, MIRROR-zahlende Validator-Knoten, etablierte Marke. Keine einzelne Dimension erforderlich — Provider erreichen die oberste Stufe, indem sie Stärke über die meisten Kategorien verteilen.
80–89Stark — erfüllt die meisten Schlüsselbenchmarks; eine oder zwei Dimensionen unter der obersten Stufe.
70–79Gut — erfüllt alle Basis-Kriterien; keine großen Lücken.
60–69Akzeptabel — brauchbar, aber nicht differenziert.
<60Unter Mittelwert — erhebliche Lücken in einer oder mehreren Dimensionen. Mathematische Tatsache, keine Qualitätsbewertung.
Dimensionen (Rohgewichte — Summe 172, normalisiert auf 100)
"Aktiv" regelt zwei Dimensionen (Gebühr und V2-Beteiligung): Ein Anbieter, der nicht läuft, sollte keine Gutschrift für die Bewerbung einer niedrigen Gebühr erhalten. Ein Anbieter gilt als aktiv, wenn er einen veröffentlichten Belohnungssatz hat oder wenn die Belohnungsdaten des Flare Systems Protocol zeigen, dass er in mindestens einer Epoche des Bewertungsfensters ausgezahlt hat. Bis 2026-07-31 war es nur der Belohnungssatz, der von einer einzelnen API eines Drittanbieters stammte – daher erhielt ein Anbieter, den diese API nicht abdeckte, bei beiden Dimensionen null Punkte, während er sichtbar jeden Epoch Belohnungen verteilte. Aktivität ist eine Eigenschaft des Anbieters, nicht davon, wer ihn gerade auflistet.
Reward-Rate25 Pkt. max
Was: Die Reward-Rate des Providers pro Epoche, verankert am Netzwerk-Mittelwert.
Wie: Verhältnis = providerRate / medianRate. Linear: Verhältnis 1,0 (Median) → 12,5 Pkt., Verhältnis 2,0 → 25 Pkt. (Obergrenze). Inaktiver Provider (rewardRate ≤ 0) → 0. v4.0 (2026-05-11): Obergrenze neu basiert, so dass Median = halbe Punkte der Dimension (nicht 40% wie zuvor).
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).
Warum: Die Reward-Rate ist das Wichtigste, das Delegierer erleben. Der Mittelwert-Anker hält die Bewertung ehrlich, wenn sich die Reward-Ökonomie des Netzwerks verschiebt — ein Provider beim 1,2× Median in einer Ära niedriger Rewards rankt gleich wie einer beim 1,2× in einer Ära hoher Rewards. Obergrenzen und Anomaliefilter verhindern, dass einzelne Epochen-Ausreißer dominieren.
Genauigkeit25 Pkt. max
Was: FTSO-Preisgenauigkeit aus Flare Systems Explorer (FSE) — primäre (enge IQR) und sekundäre (breitere) Belohnungsband-Landequoten.
Wie: Eine 40/60-Mischung der FTSO-PRIMÄREN (enge IQR) und SEKUNDÄREN (breitere) Band-Landequoten (v4.8), die Flares eigene Belohnungsaufteilung widerspiegelt — FIP.11 bezahlt Ankerfutter-Belohnungen 40% primär / 60% sekundär. Sekundär verwendet die vorherige stückweise Kurve (97% → 25 … 70% → 2); sie ist über das Feld hinweg fast gesättigt (95–99%), daher unterscheidet sie kaum. Primär verwendet eine absolute lineare Kurve — 28% → 0 bis 78% → voll 25 — sodass die weit schwierigere enge-Band-Ingenieursarbeit, wo Anbieter tatsächlich von ~28% bis ~80% verteilt sind, das ist, was das Feld trennt. Feste Ankerpunkte (keine Feldpercentile), daher bleibt der Score aus den eigenen Eingaben eines Anbieters re-ableitbar. Single-Band-Fallback, wenn nur einer verfügbar ist; neutral 12,5 ohne FSE-Daten.
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
Warum: Fehlende Epochen = fehlende Reward-Einnahmen für Delegierer. Genauigkeit bestimmt, ob die Provider-Einreichungen tatsächlich für FTSO-Konsens zählen, und das sekundäre Metrik (das neuere Epochen stärker gewichtet) ist diejenige, die am saubersten auf aktuelle Leistung abbildet.
Konsistenz20 Pkt. max
Was: Wie stabil die Reward-Rate des Providers über seine letzten verdienenden Epochen gewesen ist.
Wie: Abwärtsvolatilität über die neuesten Verdienstepochen eines Anbieters hinweg, gemessen nur zwischen Epochen, die wirklich aufeinanderfolgend sind — eine Epoche, in der ein Anbieter nichts verdient hat, hinterlässt keinen Eintrag, und die beiden Epochen auf beiden Seiten dieser Lücke werden nie miteinander verglichen. Nur Epoch-zu-Epoch-RÜCKGÄNGE zählen — ein Anstieg trägt null bei — daher erhält eine stabile oder steigende Rate nahezu volle Punkte und eine Erholung hebt die Punktzahl beim Eintreten an. Rückgänge werden mit RMS aggregiert, sodass ein starker Rückgang mehr wiegt als ein leichter, und sind auf aktuelle Paare gewichtet (Decay 0,8), sodass eine aktive Erholung die Punktzahl anhebt, während alte Rückgänge auslaufen. cv = 0 → 20 Pkt.; cv ≥ ~0,167 → 0. Neutral 10, wenn weniger als 3 aufeinanderfolgende Epochenpaare in den letzten 12 Verdienstepochen vorhanden sind.
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)
Warum: Zwei Anbieter mit derselben durchschnittlichen Belohnungsrate können sehr unterschiedliche Staker-Erfahrungen liefern: einer, der stark abfällt, ist schlechter als einer, der stabil bleibt oder steigt. Konsistenz belohnt das, was ein Delegator tatsächlich möchte — eine stabile oder steigende Rate — und bestraft nur Rückgänge, proportional zur Tiefe. Eine Rate, die WIEDER ANSTEIGT, wird niemals bestraft (das frühere symmetrische Maß tat dies, was verkehrt war). Ein kürzlicher starker Einbruch erhält eine niedrige Bewertung und erholt sich dann, während er veraltet.
V2-Teilnahme15 Pkt. max
Was: Ob der Provider den modernen V2-Stack (FTSO Scaling + Fast Updates + FDC) ausführt.
Wie: Pro-Protokoll-Stacking. Aktive Basis (rewardRate > 0) +3, V1 teilweise (Submit + Signing + Voter) +4, jedes V2-Protokoll (FTSO Scaling / Fast Updates / FDC) +~2,67 jeweils, Obergrenze 15. Inaktiv → 0. v4.0 (2026-05-11) teilt das vorherige Alles-oder-Nichts-Tier (wobei V1 teilweise = V2 vollständig = 15 — kein Anreiz zum Upgrade) in pro-Protokoll-Boni auf, die stapelbar sind.
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)
Warum: V2 ist die Richtung des Netzwerks. Das Per-Protokoll-Stacking von v4.0 bedeutet, dass ein Upgrade von V1 teilweise zu V2 vollständig die Bewertung tatsächlich erhöht (vor Fix es nicht — V1 teilweise und V2 vollständig ergaben beide 15). Das Hinzufügen eines einzelnen V2-Protokolls verbessert nun die Dimension.
Gebühr15 Pkt. max
Was: Die Gebühr, die der Provider auf delegierte Rewards erhebt.
Wie: Lineare Interpolation über Breakpoints: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. Inaktiver Provider → 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
Warum: Die Gebühr reduziert direkt, was Delegierer erhalten. Lineare Interpolation (statt Buckets) bedeutet, dass eine 7% Gebühr zwischen 10% und 15% bewertet wird, anstatt zu einem Bucket zu schnappen — Betreiber bekommen keinen Credit dafür, ihre Gebühr auf die nächste Bucket-Grenze abzurunden.
MIRROR-Teilnahme12 (+3 Bonus) Pkt. max
Was: Ob die P-Chain-Validator-Knoten des Betreibers aktiv den FTSO-Inflationsanteil an Staker zahlen, plus einem Überleistungsbonus.
Wie: Der Basisscore skaliert linear mit dem Anteil der nodeIDs des Betreibers, die MIRROR-Belohnungen zahlen. Alle Knoten aktiv → 12 Pkt. Teilweise → proportional. Keine → 0. Ab 2026-05-11 liest das 'aktiv'-Signal aus zwei kanonischen Quellen: RewardClaimed(claimType=3)-Events on-chain auf dem V2 RewardManager UND claimType=3-Zuordnungen im offiziellen FSP Merkle JSON — einer reicht aus. Vor dem Update verwendeten wir den On-Chain-Stream als alleiniges Signal, was zu falsch-negativen Ergebnissen für Anbieter führte, deren MIRROR sich über einen nicht-standardisierten Claim-Pfad abwickelt. Plus ein Überleistungsbonus von bis zu +3 Pkt, wenn die Validatoren des Betreibers konsistent über 100% der erwarteten (vrm + mirror) / erwarteten liefern — Bayes'sches Schrumpfen mit einem 30-Tage-Akkumulierungstor und einem Minimum von 3 Stakes verhindert, dass kleine oder neue Betreiber den Bonus bei wenigen Glückstreffern spielen können.
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
Warum: Die MIRROR-Teilnahme delegiert den FTSO-Inflationsanteil an Ihre Staker. Ein V2-aktiver Anbieter, dessen Validatorknoten nicht MIRROR zahlen, liefert etwa 5–15% weniger Rendite an Delegatoren als derselbe Anbieter mit aktiven Knoten. Der Überleistungsbonus belohnt konsistent besser als erwartet liefer, ohne neue Betreiber auf kleine Stichproben aufzublasen — Bayes'sches Schrumpfen und das 30-Tage-Akkumulierungstor halten es fair.
Anzahl der Delegatoren12 Pkt. max
Was: Anzahl der unterschiedlichen Wallets, die derzeit an diesen Provider delegieren, gezählt aus der Chain-State.
Wie: Log-skaliert von 5 → 500 Delegatoren abgebildet auf 0 → 12. ≤5 → 0, ≥500 → 12 (Obergrenze). Entspricht dem Count-Signal-Stil der Validator Trust-Dimension. v4.0 (2026-05-11): behoben einen echten Fehler, bei dem das vorherige Bucket-Schema bei genau 500 Delegatoren einen pervertierten Anreiz hatte (vor dem Fix: 500 → 14, 501 → 12 — das Hinzugewinnen eines Delegators über diese Grenze VERLOR 2 Punkte).
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
Warum: Die Delegatorenanzahl ist ein Vertrauenssignal — unabhängig von der Größe des Stakes. Ein Anbieter mit 200 Delegatoren wurde von 200 unabhängigen Stakern gewählt; einer mit 5 wurde von nah beim Betreiber selbst gewählt. Log-Skalierung gibt über ~50 Delegatoren hinaus sinkende Renditen, ohne jemals rückgängig zu werden (wie das Bucket-Scoring vor v4.0 es tat).
Epoch-Teilnahme10 Pkt. max
Was: Ob der Anbieter aktiv an Epochs teilnimmt.
Wie: FSE markiert den Anbieter als aktiv → 10. Anbieter hat rewardRate > 0 (Flaremetrics), aber kein FSE aktives Flag → 7 (aktiv per Marktdaten, FSE-Bestätigung fehlt). Ansonsten → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Warum: Erfasst Anbieter, deren Belohnungsstrom zum Erliegen gekommen ist, auch wenn Flaremetrics sie noch auflistet. Unterschied zu Accuracy (geht um pro-Epoch-Korrektheit) — Participation geht darum, überhaupt zu erscheinen.
Stabilität der Abstimmungskraft10 Pkt. max
Was: Prozentuale Veränderung der Abstimmungskraft des Anbieters von Tag zu Tag.
Wie: Stückweise linear in absoluter prozentualer Veränderung von Tag zu Tag. <1% → 10. Linear von 1% → 3% (10 → 7). Linear von 3% → 5% (7 → 4). Linear von 5% → 10% (4 → 2). Setzt sich gegen 0 fort über 10%. v4.0 (2026-05-11): linearisiert die vorherigen Bucket-Klippen (waren bis zu 3-Punkt-Klippen bei jedem Schwellenwert).
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)
Warum: Große tägliche Schwankungen der Abstimmungskraft deuten oft auf eine Delegatorwelle hin, die herein- oder herausfließt — Staker, die die Tabelle lesen, sehen ein bewegliches Ziel. Eine stabile Abstimmungskraft signalisiert einen etablierten Anbieter mit anhaftenden Delegatoren.
Compliance10 Pkt. max
Was: Ob der Anbieter in jeder Reward-Epoch bezahlt wurde, SEITDEM er in den FSP-Reward-Daten aktiv wurde.
Wie: Volle 10 Punkte für null verpasste Epochs innerhalb des aktiven Fensters des Anbieters. Jede verpasste Epoch zieht 3 Pkt ab (bei 0 begrenzt). Neutral 5, wenn keine FSP-Daten verfügbar sind. v4.4 (2026-06-30): verpasste Epochs werden jetzt nur ab der ersten teilnehmenden Epoch des Anbieters an gezählt — ein neuer Anbieter wird nicht mehr für Epochs vor seiner Existenz belastet (was zuvor neue, aber saubere Knoten für Wochen bei 0/10 hielt).
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)
Warum: Eine verpasste Epoch in der offiziellen Flare Systems Protocol-Reward-Verteilung bedeutet, dass der Anbieter die Protokoll-Compliance für diese Epoch nicht erfüllt hat — Mindestbedingungen, Signaturrichtlinie usw. Das Zählen nur ab der ersten Teilnahme hält die Messung für neue Anbieter fair, während sie immer noch echte Misses bestrafen. Drei Punkte pro Miss ist steil, also ist ein Miss ein erkennbares Signal, aber erholbar; ~3 Misses nullen die Dimension.
Identität8 Pkt. max
Was: Ob der Anbieter einen echten Markennamen oder nur eine Hex-Adresse hat.
Wie: Benannte Marke (≥4 Zeichen, nicht mit 0x beginnen) → 8. Kurz oder anonym (<4 Zeichen) → 4. Pure Hex / 0x-Adresse als Name → 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
Warum: Ein benannter Anbieter hat sich dafür entschieden, auffindbar und rechenschaftspflichtig zu sein — er kann gesucht, kontaktiert und auf die veröffentlichten Verpflichtungen verpflichtet werden. Anonyme Anbieter nach Adresse sind funktional, bieten aber weniger Vertrauenssignale für Delegatoren, die sie bewerten.
Eigenkapital-Bindung7 Pkt. max
Was: Die EIGENE P-Chain-Knoten-Bindung des Betreibers (Risikobeteiligung) — ausschließlich Stakes, die andere an den Knoten delegieren. Ein größenunabhängiges Commitment-Tor, keine Vermögensrangliste.
Wie: Gutgeschrieben auf der GRÖSSEREN von zwei sättigenden Achsen: (1) Ausrichtung — eigene Bindung als Anteil der gesamten committed Stakes (≥10% → vollständig); oder (2) absolut — eigenes Kapital auf dem Spiel, begrenzt auf 5M FLR, so dass 5M und 80M die gleiche Bewertung erhalten. v4.4 (2026-06-30): neu beschafft von der wahren P-Chain-Selbst-Bindung des Betreibers (Validator-Gewicht kreuzreferenziert nach nodeID) — das vorherige Flaremetrics-Feld, das es las, wurde eingestellt, so dass jeder Anbieter 0 bewertet hatte. v4.5 (2026-06-30): addierte die absolute Achse + Sättigung, so dass eine große Selbst-Bindung bei niedriger Quote nicht unter einer kleinen bei hoher Quote bewertet wird, ohne dass Größe gewinnt oder kleine Betreiber bestraft werden.
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)
Warum: Risikobeteiligung — ein Betreiber mit eigenem Kapital auf dem Spiel ist mit Delegatoren ausgerichtet. Aber die Größe der Selbst-Bindung ist kein Proxy für die Betreiber-QUALITÄT (die in den anderen Dimensionen liegt), also verdienen ein kleiner vollständig ausgerichteter Betreiber und ein großer engagierter volle Marks. Nur ein Betreiber mit wenig eigenem Kapital committed — kleine Quote UND kleiner Betrag — bewertet unterhalb von voll.
Wie man 100/100 erreicht — ein FTSO-Anbieter-Leitfaden
Das v4.0-Fairness-Audit war speziell so konzipiert, dass das Maximieren jeder Score-Dimension Sie wirklich zu einem besseren FTSO-Anbieter für Ihre Delegatoren macht. Ihre Score zu verbessern ist kein Gaming des Systems — das System funktioniert wie geplant. Hier ist der Pro-Dimension-Leitfaden.
Belohnungsrate — 25 Pkt. Liefern Sie ≥ 2× die Netzwerk-Median FSP-Belohnungsrate pro Epoch (nach Gebühren, nach Protokoll-Verteilung). Linear von 0 bis 2× Median: Median → 12,5, 2× Median → 25. Warum das ausgerichtet ist: Das ist der Dollarbetrag, der Ihren Delegatoren pro Epoch tatsächlich erreicht.
Genauigkeit — 25 Pkt. Ziel ≥97% Secondary-Band-Landetarif auf FSE für volle Punkte. Stückweise linear, so 95% → 18, 93% → 16, 90% → 13, usw. — jede 1%-Verbesserung bewegt die Score. Das ist Preis-QUALITÄT, nicht Epoch-Teilnahme: Es misst, welcher Anteil eingereichter Preise innerhalb des On-Chain-akzeptierten Bands landet. Ein Anbieter mit hoher Genauigkeit veröffentlicht Preise nah am Konsens; einer mit niedriger Genauigkeit reicht zuverlässig ein, ist aber häufiger off-Konsens. Warum das ausgerichtet ist: Off-Band-Einreichungen liefern kleinere Delegator-Belohnungen, auch wenn der Anbieter in jeder Epoch teilnimmt. Die separate Compliance-Dimension unten verfolgt die Epoch-Teilnahme.
Konsistenz — 20 Pkt. Minimieren Sie die Pro-Epoch-Belohnungsrate-Varianz (KV = Stdabw./Mittelwert über jüngste Epochs). KV = 0 → 20, KV = 0,2+ → 0. Warum das ausgerichtet ist: Zwei Anbieter mit derselben durchschnittlichen Belohnungsrate sind nicht äquivalent — vorhersagbare Auszahlungen schlagen volatile für Staker UX.
V2-Teilnahme — 15 Pkt. Stapeln Sie Protokolle additiv: aktive Baseline + V1 teilweise Registrierung + jedes V2-Protokoll (Scaling, FastUpdates, FDC). Volle V2 + aktiv + V1 registriert = 15. Warum das ausgerichtet ist: V2 ist, wohin sich das Netzwerk bewegt; jedes zusätzliche Protokoll, das Sie einführen, ist eine Vorwärtsinvestition, von der Ihre Delegatoren profitieren.
Gebühr — 15 Pkt. Berechnen Sie ≤ 5% für 13 Pkt, 0% für 15. Stückweise lineare Rampe durch 5%/10%/15%/20%/25%-Schwellenwerte auf 0. Warum das ausgerichtet ist: Niedrigere Gebühr = mehr Belohnung erreicht Ihre Delegatoren direkt.
MIRROR-Teilnahme — 12 + bis zu 3 Bonus. Betreiben Sie alle P-Chain-Validatorknoten Ihres Betreibers als MIRROR-aktiv (entweder über On-Chain RewardClaimed Events ODER FSP Merkle JSON-Zuordnungen — v3.6 Dual-Source). Anhaltend überleisten (Median (vrm+mirror)/erwartet Verhältnis über 1,05) auf ≥3 bezahlten Stakes nach 30 Tagen Beobachtung verdient bis zu +3 Bonus. Warum das ausgerichtet ist: MIRROR ist der Anteil Ihrer Delegatoren an der FTSO-Inflation; Knoten, die MIRROR nicht zahlen, liefern ~5-15% weniger Rendite an Staker.
Delegatorenanzahl — 12 Pkt. Log-skaliert 5 → 500 Delegatoren abgebildet auf 0 → 12. Bauen Sie eine Basis unabhängiger Staker auf, nicht nur ein paar Wale. Warum das ausgerichtet ist: Count ist ein Vertrauenssignal unabhängig von der Stake-Größe; 200 Delegatoren, die Sie wählen, bedeutet 200 unabhängige Befürwortungen.
Epoch-Teilnahme — 10 Pkt. Erscheinen Sie in jeder Epoch mit positiver Belohnungsrate und aktivem FSE-Flag. Warum das ausgerichtet ist: erfasst steckengebliebene Belohnungsströme, die die Pro-Epoch-Dimensionen möglicherweise vermissen.
Stabilität — 10 Pkte. Halten Sie die tägliche Änderung der Abstimmungskraft unter 1%. Stückweise linearer Anstieg danach. Warum dies passt: Stabile Abstimmungskraft signalisiert etablierte Delegatoren (klebrige Gemeinschaft) statt flüchtiger Wal-Wellen.
Compliance — 10 Pkte. Null verpasste Reward-Epochen in den FSP-Daten. Jeder Fehlschlag kostet 3 Pkte; ~3 Fehlschläge setzen die Dimension auf null. Dies ist PARTIZIPATION, nicht Preisqualität: Es zählt Epochen, in denen der Anbieter für das Nichterfüllen von Mindestbedingungen, Signierungsrichtlinien oder anderen Protokollanforderungen sanktioniert wurde – unterschiedlich von der obigen Accuracy-Dimension, die die In-Band-Preislandung bewertet. Warum dies passt: Eine verpasste Epoche in der eigenen Reward-Verteilung des Protokolls bedeutet, dass der Anbieter Mindestbedingungen nicht erfüllt hat und Delegatoren in dieser Epoche nichts verdient haben. Ein Anbieter kann großartige Accuracy bei teilgenommenen Epochen haben und dennoch Epochen komplett verpassen.
Identität — 8 Pkte. Registrieren Sie einen echten Markennamen (≥4 Zeichen, keine Hex-Adresse) auf Flaremetrics oder FSE. Anonyme Anbieter (nur Adresse) erhalten 0 Pkte; benannte Anbieter erhalten 8 Pkte. Warum dies passt: Benannte Anbieter sind auffindbar und rechenschaftspflichtig; das ist das grundlegende Vertrauenssignal.
Selbstbeteiligung — 7 Pkte. Verpflichten Sie Ihren eigenen P-Chain-Node-Bond (nicht Stake, den andere an Sie delegieren). Volle Punktzahl für ENTWEDER einen signifikanten Anteil Ihres gesamten Stakes (≥10%) ODER einen signifikanten absoluten Betrag (die absolute Achse sättigt sich bei 5M FLR, sodass ein großer Betreiber einen kleinen nicht übertrumpfen kann). Warum dies passt: Haut im Spiel – Betreiber mit eigenem Kapital auf dem Spiel teilen die Rendite-Ergebnisse ihrer Delegatoren. Es ist ein größen-neutrales Commitment-Gate, kein Vermögensranking: Ein vollständig ausgerichteter kleiner Betreiber und ein großer verpflichteter maximieren beide, und Ihre Betriebsqualität wird von den anderen Dimensionen bewertet.
Zeitgesteuerte Signale, die man nicht abkürzen kann: Konsistenz benötigt ≥3 Epochen Historie. MIRROR-Outperformance-Bonus benötigt 30 Tage Beobachtung plus ≥3 bezahlte Stake-Samples. Compliance benötigt FSP-Daten über genügend Epochen zum Zählen. Bauen Sie eine Track Record auf; der Score wird folgen.
Der Rohscore summiert sich auf maximal 172 über alle 12 bewerteten Dimensionen und wird dann auf 100 normalisiert. Eine perfekte Ausführung bei Eingaben ergibt 172/172 → 100 angezeigt. Eine Abstimmungsleistungs-Verdünnungspenalty von bis zu −3 Punkten gilt für sehr große Provider (>1,34 Mrd. VP) als Tiebreaker.
So verifizieren Sie Ihren eigenen Score
Jeder Score in der Anbietertabelle ist aus öffentlichen Daten reproduzierbar. Wenn Sie ein Betreiber sind und die hier dargestellte Mathematik nicht mit dem Score übereinstimmt, den Sie sehen, ist der richtige Schritt, ihn selbst zu verifizieren, bevor Sie davon ausgehen, dass wir einen Fehler gemacht haben. Anleitung:
  1. Schlagen Sie die öffentlichen Statistiken Ihres Anbieters nach auf flaremetrics.io (suchen Sie nach Name oder fügen Sie Ihre Delegationsadresse ein). Notieren Sie Ihren fspRewardRate, delegationFeePercentage, wNatWeight und votePowerDailyChangePct.
  2. Verifizieren Sie Ihre FTSO V2 + Genauigkeit auf flare-systems-explorer.flare.network. Suchen Sie Ihre Entität. Überprüfen Sie providersuccessrate.secondary für Genauigkeit, plus die entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc Flaggen für V2-Status.
  3. Überprüfen Sie Ihre MIRROR-Partizipation auf dem V2 RewardManager-Vertrag über flare-explorer.flare.network. Suchen Sie nach RewardClaimed Events mit claimType=3, die Ihre nodeIDs referenzieren. Wenn es keine neueren für irgendwelche Ihrer Knoten gibt, werden Sie auf dem Score als MIRROR-inaktiv angezeigt.
  4. Geben Sie Ihre Eingaben in die obigen Formeln ein. Der Code-Block jeder Dimension sagt Ihnen genau, welche Arithmetik auszuführen ist. Addieren Sie die Dimensionen, teilen Sie durch 172 (Rohmaximum), multiplizieren Sie mit 100, und Sie haben Ihren Raw-Composite-Score.
  5. Wenden Sie die Verdünnungsstrafe an, wenn Sie groß sind. Abstimmungskraft über 1,34B ist −3, über 1B ist −1. Die Karte Final Score unten hat die genauen Schwellenwerte.
  6. Vergleichen Sie mit Ihrem angezeigten Score. Der angezeigte Score spiegelt auch dynamische Gewichtsumverteilung wider – wenn die meisten Anbieter sich in einer Dimension gruppieren (niedrige Standardabweichung über den aktiven Satz), wird das Gewicht dieser Dimension auf Dimensionen mit größerem Spread umverteilt. Die Score-Breakdown-Anzeige in jeder Anbieterreihe zeigt die aktuellen pro-Dimensions-Werte.
  7. Wenn die Mathematik nicht aufgeht, schreiben Sie eine E-Mail an [email protected] mit Ihrer Delegationsadresse, den von Ihnen verwendeten Eingaben und dem von Ihnen berechneten Score. Wir antworten, und wenn wir einen Fehler gemacht haben, korrigieren wir ihn öffentlich.
Häufige Bedenken von Betreibern
Meine Reward-Rate liegt über dem Median, aber mein Reward-Rate-Score ist nicht 25/25 – warum?
Reward Rate ist linear im Verhältnis zum Median: Score = Verhältnis × 12,5, daher ist 1,0× Median = 12,5/25 und Sie benötigen ein Verhältnis von 2,0×, um die Kappe zu erreichen. Ein Anbieter bei 1,2× des Medians erhält 15 Pkte, bei 1,5× etwa 18,8, bei 2,0× erhält die vollen 25. Die Kappe (plus der 3×-Median-Anomalie-Filter) existiert, damit eine einzelne anomal hohe Reward-Epoche die Dimension nicht dominieren kann; wenn Ihre Rate durchgehend im oberen Dezil liegt, belohnt der Score sie immer noch stark.
Ich habe gerade auf V2 aktualisiert – wann wird mein V2-Score aktualisiert?
V2-Status kommt von FSEs entityminimalconditionslatest-Flaggen (ftso_scaling, ftso_fast_updates, fdc). Ab v4.0 stapelt sich die Dimension pro Protokoll: aktive Baseline +3, V1-Registrierung (submit + signing + voter) +4, und jedes V2-Protokoll +~2,67. Ein Voter-registrierter Anbieter mit submit- und signing-Adressen, aber keinem der drei V2-Protokolle erhält 7/15, und jedes einzelne V2-Protokoll, das Sie aktivieren, bewegt den Score – alle drei live erhalten Sie die vollen 15. Änderungen landen beim nächsten FlareWatch-Cron-Durchlauf (alle 5 Minuten) nachdem FSE sie widerspiegelt.
Meine Genauigkeit auf FSE ist 96%, aber ich scor e niedriger als erwartet.
Die Accuracy-Dimension verwendet FSEs sekundäre Genauigkeitsmetrik (höhere Auflösung im 94–97%-Band, wo die meisten Anbieter sich clustern). 95–96% entspricht 18 Pkte; Sie benötigen ≥97% für die vollen 25. Die Buckets sind oben eng, weil einige Zehntel Prozent im 95–97%-Band echte Leistungstrennung zwischen Anbietern darstellen.
Ich liefere MIRROR – warum zeigt FlareWatch mich als MIRROR-inaktiv auf meinem Provider-Score?
Ab 2026-05-11 wird MIRROR-Partizipation aus ZWEI Quellen erkannt: On-Chain RewardClaimed(claimType=3)-Events auf dem V2 RewardManager UND claimType=3-Zuweisungen im offiziellen FSP Merkle JSON. Eine nodeID, die in einer der beiden Quellen angezeigt wird, zählt als aktiv. Für Multi-Node-Betreiber verwendet der Score den Anteil Ihrer Knoten, die aktiv sind (1/3 aktiv = 4/12 Basis, etc.). Wenn ein Knoten aktiv sein sollte, aber nicht nach dem nächsten Scan-Zyklus, schreiben Sie uns eine E-Mail mit der nodeID und der spezifischen Epoche, in der Sie sie erwarten – wir werden beide Quellen überprüfen.
Meine Abstimmungskraft ist gestern um 8% gestiegen – warum liegt mein Stability-Score bei ~2,8/10?
Vote Power Stability ist stückweise linear in absoluter täglicher Veränderung (linearisiert in v4.0 – keine Bucket-Klippen): <1% → 10, ramping 1→3% runter auf 7, 3→5% runter auf 4, 5→10% runter auf 2, dann gegen 0 über 10%. Eine 8%-Bewegung landet auf der 5–10%-Rampe bei 4 − (8 − 5) × 0,4 = 2,8. Die Absicht ist, Anbieter mit erheblichem Delegator-Turnover zu kennzeichnen, damit Staker es in der Tabelle sehen. Der Score erholt sich, sobald Ihre Abstimmungskraft stabilisiert; ein volatiler Tag verankert Sie nicht dauerhaft niedrig.
Mein Anbieter hat einen Namen mit meiner Entity-Adresse (0x…). Warum liegt mein Identity-Score bei 0?
Identity vergibt 8 Pkte für einen echten Markennamen (≥4 Zeichen, nicht mit 0x oder nur hexadezimal) und 0 für einen reinen Adressnamen. Wir können keinen Namen erfinden – setzen Sie Ihren profile.name auf Flaremetrics und wir holen ihn uns beim nächsten Cron-Durchlauf. Wenn Ihre Entität ein Profil hat, aber das Namensfeld leer ist, gilt das gleiche.
Ich habe eine kleine, aber engagierte Delegator-Basis – warum ist mein Delegator-Count-Score begrenzt?
Delegator Count verwendet echte Zählwerte: Jedes Wallet, das WFLR hält, wird on-chain auf seine aktuellen Delegationen überprüft, und die unterschiedlichen Delegatoren jedes Providers werden gezählt (aktualisiert alle ~6 Stunden, cross-checked mit einem unabhängigen Event Ledger). Seit v4.0 ist es logarithmisch skaliert von 5 → 500 Delegatoren auf 0 → 12 Punkte abgebildet, mit Obergrenze bei 500 (≤5 ergeben 0 Punkte). Logarithmische Skalierung bedeutet, dass kleinere Provider mit starkem Wachstum bei der Delegatorenzahl am schnellsten klettern; nach ~50 Delegatoren bewirken zusätzliche Delegatoren eine geringere Bewegung – aber die Kurve ist monoton, daher kann das Gewinnen eines Delegators den Score niemals senken (die Pre-v4.0-Buckets konnten das).
Mein Score fiel, nachdem ich einen Knoten hinzufügte – was ist passiert?
Wenn der neue Knoten noch keine claimType=3 MIRROR-Events anzeigt, fällt Ihre MIRROR-Fraktion (z.B. von 1/1 = 100% auf 1/2 = 50%), wodurch der MIRROR-Partizipations-Basis-Score reduziert wird. Sobald der neue Knoten anfängt, MIRROR zu zahlen (normalerweise innerhalb einer oder zwei Reward-Epochen nach Aktivierung), erholt sich die Fraktion und der Score klettert zurück.
Kann ich meinen Score anfechten oder eine manuelle Überprüfung anfordern?
Ja. Schreiben Sie an [email protected] mit Ihrer Delegationsadresse und einem spezifischen Bedenken. Wir antworten auf jeden Betreiber. Dinge, bei denen wir handeln werden: MIRROR-Klassifikationskorrektionen, dimensions-spezifische Mathematikfehler, Name/Logo-Korrektionen über Flaremetrics. Dinge, bei denen wir nicht handeln werden: Anfragen zum manuellen Erhöhen eines Scores außerhalb des Algorithmus, Anfragen zum Ausschließen oder Herabstufen eines Konkurrenten.
Was wir tun und nicht tun
Um Mehrdeutigkeiten darüber zu beseitigen, wie wir den Score betreiben, sind hier explizite Zusagen. Wenn wir jemals eine davon verletzen, dokumentieren Sie es und schreiben an [email protected] – wir werden es öffentlich korrigieren.
✓
Wir akzeptieren keine Zahlungen für höhere Scores, gesponserte Platzierungen oder bevorzugte Behandlung jeglicher Art. Der Score wird deterministisch aus öffentlichen Daten berechnet.
✓
Wir werden keine pro-Anbieter-Bumps hand-codieren. Es gibt nirgends in dem Code eine Zeile "X bekommt +5, weil wir sie mögen". Der gleiche Algorithmus gilt für jeden Anbieter, einschließlich FlareWatch's eigenem Anbieter, der von dieser genauen Funktion bewertet wird.
✓
Wir werden Anbieter nicht aus der Tabelle ausschließen aus nicht-öffentlichen Gründen. Die Liste wird aus Flaremetrics + FSE bezogen; unsere Anzeige umfasst jeden aktiven Anbieter, den diese Quellen zeigen.
✓
Wir werden Algorithmusänderungen veröffentlichen. Jede Versionsbumpy ist in der Versions-Karte auf dieser Seite mit Begründung und Änderungen dokumentiert. Große Änderungen erhalten einen zusätzlichen Changelog-Eintrag, der auf der Changelog-Seite der App sichtbar ist.
✓
Wir werden auf E-Mails von Operatoren antworten. Jeder Operator, der [email protected] mit einem substantiellen Anliegen zu seinem Score schreibt, erhält innerhalb weniger Werktage eine echte Antwort.
✓
Wir werden unsere Fehler öffentlich korrigieren. Wenn wir einen Bug im Algorithmus, einen Datenquellen-Fehler oder eine Methodenlücke entdecken, liefern wir einen Fix und dokumentieren ihn. Wir führen keine stillen Neubewertungen durch.
✗
Wir werden nicht E-Mail-Inhalte öffentlich teilen ohne die Genehmigung des Absenders, und werden Operator-E-Mails nicht für etwas anderes als die Score-Konversation verwenden, die sie verursacht hat.
✗
Wir werden nicht unsere zukünftigen Pläne für eine Algorithmusänderung mit ausgewählten Operatoren im Voraus teilen — jede Version geht gleichzeitig für alle live.
Endscore (wie Dimensionen kombiniert werden)
Alle 12 bewerteten Dimensionen summieren sich zu einer Rohkomposite (max. 172). Die Rohkomposite wird auf eine Skala von 0–100 normalisiert und dann wird eine dynamische Gewichtungsumverteilung angewendet, um die endgültig angezeigte Bewertung zu erzeugen.
// 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)
Die Nähe zur Obergrenze ist ein Anzeigesignal, keine Bewertungsabzug. Bis v4.9 zog die Bewertung auch einen festen Abzug von 1–3 Punkten von sehr großen Anbietern ab, aber das war eine Doppelzählung – ein Provider über der Obergrenze erzielt bereits eine unter dem Median liegende realisierte Rendite, die die mediangebundene Reward-Rate-Dimension einmalig bewertet. Der Strafpunkt wurde daher entfernt. Jeder Anbieter zeigt nun an, wie viel der FSP-Obergrenze (2,5% der aktiven Gesamtabstimmungskraft des WNat-Vertrags) er ausfüllt, als neutrales Grenzdelegationssignal: je näher bei 100%, desto mehr wird eine neue Delegation verwässert.
Display-Layer-Ausreißer-Flag: Ein Provider, dessen aktuelle Belohnungsrate mehr als drei robuste Abweichungen (Median Absolute Deviation, skaliert ×1,4826) über dem Feldmedian liegt – und mindestens 50% darüber – trägt ein Ausreißer-Badge in der Provider-Tabelle. Das Badge ändert den Score nicht; der Score selbst begrenzt durch eine separate Anomalie-Schutzmaßnahme Raten, die über dem 3-fachen Median liegen, vor der Bewertung. Annualisierte Epoch-Raten-Spitzen entstehen normalerweise durch sehr geringe Stimmkraft und normalisieren sich innerhalb einer Epoch.
Datenquellen (jede Eingabe ist öffentlich)
,Flare-Verträge, direkt on-chain gelesen: die registrierte Anbieterliste (VoterRegistry), Entity → Delegationsadresse und nodeID-Verknüpfungen plus Submit-/Signieradressenregistrierung (EntityManager), delegierte Stimmkraft (WNat) und Delegationsgebühr (WNatDelegationFee). Dies macht die Anbieterliste unabhängig von einem einzigen Index: Bei Reward-Epoche 420 enthielt die Blockchain 98 registrierte Anbieter gegenüber 80 in der Drittanbieter-Listung, und die 18 in der Lücke fehlten dieser Website zuvor völlig.
Flaremetrics öffentliche API: Reward-Rate, Delegationsgebühr, Stimmkraft, tägliche Stimmkraftänderung, gesperrte Stimmkraft (Self-Bond), Profilname + Logo + Region, fspRewardRate.
Flare Systems Explorer (FSE): FTSO-Genauigkeit (primär + sekundär), V2-Statusflags (ftso_scaling, ftso_fast_updates, fdc), Entitätsadressenverknüpfung, Vorhandensein von Signing-/Submit-Adressen, Wählerregistrierung, P-Chain-NodeID-Verknüpfung und die Pro-Entitäts-Delegationsvergütungsrate (reward_rate_wnat). Die Vergütungsrate wird absichtlich aus BEIDEN FSE und Flaremetrics bezogen: Sie veröffentlichen dieselbe Zahl in verschiedenen Einheiten (FSE dezimal, Flaremetrics prozentual – verifiziert identisch über alle 72 Provider mit beiden Quellen, auf fünf Dezimalstellen), und FSE deckt 154 Entitäten gegen Flaremetrics' 80 ab. Eine einzelne Quelle allein würde Provider ohne eigenes Verschulden ohne Rate hinterlassen.
Flare Systems Protocol Rewards-Daten (FSP): Pro-Epoche Reward-Verteilung pro Provider, verwendet für die Compliance-Dimension (zählt Epochen ohne Rewards) und als autoritative Quelle für Delegations-Reward-Summen.
V2 RewardManager (claimType=3 Events): On-Chain beanspruchte MIRROR-Verteilung pro Validator-NodeID. Streng gefiltert auf Typ 3 — keine Vermischung mit VRM, FTSO-Delegation oder DIRECT-Rewards. FlareWatch's eigener Indexer stellt diese für die MIRROR-Partizipations-Dimension zur Verfügung.
FSP Merkle JSON (claimType=3 Zuordnungen): kanonischer veröffentlichter Datensatz, wer MIRROR pro Epoche schuldet (dieselben Daten, die Flares eigenes Signaturwerkzeug liest). Hinzugefügt als zweite autoritative Quelle 2026-05-11 — erfasst Validatoren, deren MIRROR zugeordnet aber noch nicht On-Chain beansprucht ist.
FlareWatch historische Snapshots: Pro-Epoche Reward-Raten speisen den Consistency CV; Pro-Validator Paid-Stake-Beobachtungen speisen den MIRROR-Überleistungsbonus (mit dem 30-Tage-Daten-Akkumulierungstor).
Was NICHT im Score enthalten ist
• Selbstförderung oder bezahlte Platzierung. Kein Provider kann einen höheren Score zahlen oder sponsern.
• Hardcodierte Provider-spezifische Bumps. Keine "X erhält +5, weil wir sie mögen"-Zeilen irgendwo im Code. Der gleiche Algorithmus gilt für jeden Provider, einschließlich FlareWatch's eigenem Provider, der von dieser exakten Funktion bewertet wird.
• Subjektive Infrastrukturqualität. Wir versuchen nicht, Uptime-SLAs, geografische Verteilung oder Hardware-Spezifikationen über das hinaus zu bewerten, was FSE und Flaremetrics als öffentliche Daten darstellen.
• Sperren oder Zusicherungen an FlareWatch. Keine bevorzugte Bewertung für Staker, die FlareWatch vs. ein anderes Tool verwenden.
• Zukünftige Signale noch nicht verdrahtet. Community-Präsenz (verifizierte Soziale, Governance-Beteiligung), historisches Slashing, Antwortlatenz und Pro-Epoche-Trendlinien sind für zukünftige Versionen vorgesehen, aber nicht in v3 heute. Keine sind gewichtet geheim.
Operator-Feedback
Sehen Sie etwas Falsches im Score Ihres Providers? Schreiben Sie [email protected] mit Ihrer Delegationsadresse und Anliegen. Wir antworten auf jeden Operator. Häufige Anfragen, auf die wir handeln werden:
  • MIRROR-Klassifizierungskorrektionen (claimType=3 Zuordnung zu Ihren NodeIDs).
  • Dimensionsspezifische Mathematikfehler mit den verwendeten Eingaben.
  • Name- / Logo- / Profilkorrektionen über Flaremetrics oder FSE.
  • Allgemeine Algorithmuskritik.
Quellen & Referenzen
Jede Eingabe zum Score kommt aus öffentlichen, verifizierbaren Flare-Ökosystem-Quellen. Jeder kann unsere Ansprüche gegen diese primären Quellen überprüfen und die Mathematik aus Rohdaten reproduzieren. Wenn Sie einen Unterschied zwischen dieser Seite und dem, was die vorgelagerten Quellen sagen, entdecken, schreiben Sie [email protected] und wir werden es beheben.
Autoritative Protokoll-Dokumentation. Behandelt FTSO V2, FSP, P-Chain-Validierung, FAssets und den Rest des Flare-Stacks.
Flare Governance Portal (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — die maßgebliche Quelle für V2-Protokoll-Mindestbedingungen, Gebührenmechaniken und Reward-Ökonomie-Änderungen, die in diesen Score einfließen.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Offizielles von Flare betriebenes Verzeichnis von FTSO-Datenanbietern, Entity-Adressen, P-Chain-NodeID-Verknüpfungen und Mindestbedingungen-Flags. Primäre Quelle für unsere Accuracy-, V2- und Partizipations-Dimensionen.
Flaremetrics ↗https://flaremetrics.io
Unabhängiger Flare-Ökosystem-Metrik-Anbieter. Quelle für Reward-Raten, Gebühren, Stimmkraft, tägliche Stimmkraftänderung, gesperrte Stimmkraft, Profilnamen + Logos und die fspRewardRate-Metrik.
Flare Block Explorer ↗https://flare-explorer.flare.network
Schreibgeschützter Browser aller On-Chain-Status. Lässt jeden die RewardClaimed-Events des V2 RewardManager's überprüfen (claimType=3 für MIRROR), Reward-Epoche-Übergänge und den Rest.
Flare Foundation reward-scripts Repo ↗https://github.com/flare-foundation/reward-scripts
Pro-Reward-Epoche JSON veröffentlicht von der Flare Foundation zeigend pro-Validator gelieferte Rewards. Indirekte Eingabe — speist die MIRROR-Überleistungs-Bonus-Berechnung über FlareWatch's Per-Stake-Beobachtungs-Indexer.
Flaremetrics öffentliche API (FTSO-Provider) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Der genaue Endpunkt, den unser Cron konsumiert und der Entitätsprofile, Verzinsungssätze, Gebühren und Stimmanteile zurückgibt. Jeder kann ihn direkt aufrufen.
Flaremetrics öffentliche API (Node-Registrierungen) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID-Umrechnungstabelle. Wir paginieren diese, um die Entitäts-zu-NodeID-Zuordnung zu erstellen, die die MIRROR Participation-Dimension antreibt.
Keine privaten Daten, keine geschlossenen Modelle. Der Scoring-Algorithmus ist in services/ftso/scoring.ts in der FlareWatch-Codebasis implementiert. Operatoren oder Forscher, die die Implementierung direkt inspizieren möchten (anstatt die obige Prosa und Formeln zu lesen) – oder die sie für ihre eigene Nutzung forken möchten – können eine E-Mail an [email protected] senden, um Zugriff anzufordern. Wir werden die Datei als eigenständiges Open-Source-Paket veröffentlichen, wenn es echte Nachfrage gibt.
Wie Scores aktualisiert werden
FTSO-Provider-Scoring läuft als ein Pass im Cron bei /api/cron/refresh-validators, das den Score aller aktiven Provider alle 5 Minuten neu berechnet (derselbe Lauf, der P-Chain-Validatoren neu bewertet). Eingaben (Flaremetrics, FSE, FSP-Belohnungen, V2 RewardManager-Events) werden bei jedem Lauf frisch abgerufen.
Consistency CV verwendet die aktuelle Epochen-Historie – die Dimension kann sich ändern, während sich das rollende Fenster verschiebt. Neue Provider mit weniger als 3 historischen Epochen erhalten die neutrale Bewertung 10, bis genug Daten gesammelt sind.
Die dynamische Gewichtsumverteilung wird bei jedem Lauf neu berechnet basierend auf dem aktuellen aktiven Provider-Set. Wenn sich Provider verschieben (z. B. eine Welle von neuen V2-Upgrades), verschiebt sich die Dimension, die nicht diskriminierend wird; die Umverteilung passt sich automatisch an.
Die Algorithmus-Version ist in der Kopfzeile dieser Seite markiert. Wenn wir eine neue Version ausliefern, ändert sich die Versionsnummer hier und die Versions-Karte unten dokumentiert die Änderungen.
Versionen
v4.8 (2026-08-20) — Genauigkeit belohnt jetzt das SCHWIERIGE Belohnungsband. Sie verwendete nur das FTSO-Sekundärband (breiteres), wo fast jeder seriöse Anbieter 95–99% erreicht — die Dimension war also nahe an 25/25 über die Spitze des Feldes, kaum etwas messend. Das PRIMÄRBAND (enge IQR) ist die wirklich schwierige Ingenieursarbeit und verteilt Anbieter ~28–80%. Flare belohnt diese Bänder 40% primär / 60% sekundär (FIP.11, seit 2024 live, mit weiteren sekundärband-Erhöhungen signalisiert), daher spiegelt Genauigkeit jetzt das: eine 40/60-Mischung. Sekundär behält seine vorherige Kurve; Primär verwendet eine absolute Kurve (28% → 0, 78% → voll 25), fest damit der Score aus den eigenen Eingaben eines Anbieters re-ableitbar bleibt. Vollständiges Vorher/Nachher über alle 100 bewerteten Anbieter, archiviert vor dem Versand: die Umordnung verfolgt primärband-Stärke — Anbieter, die die schwierige enge-Band-Arbeit leisten, steigen, Anbieter, die auf einer einfachen Sekundärzahl schweben, fallen. Die gleiche Regel gilt für unseren eigenen Anbieter, der heute ein schwaches Primärband hat: er fällt von 84 auf 77 und fällt mehrere Plätze. Trotzdem ausgeliefert — ein Score, der echte Ingenieursarbeit belohnt, sogar die eines Konkurrenten und sogar auf unsere eigenen Kosten, ist die einzige Art, die es wert ist, veröffentlicht zu werden.
v4.7 (2026-07-31) — Die Providerliste hörte auf, von einem einzelnen Index abzuhängen, und die Bewertung hörte auf, unsere eigenen Datenlücken zu bestrafen. (1) Die Liste wird nun aus der On-Chain-registrierten Wählermenge erstellt und dort aufgefüllt, wo der Index von Drittanbietern Entitäten fehlen: 98 Provider gegen die zuvor gezeigten 80, also 18 echte Provider, die unsuchbar und nicht delegierbar von hier aus waren, erscheinen nun. (2) „Aktiv
v4.6 (2026-07-01) — Consistency entzerrt für neue Nodes. Es war Mittelwert/Standardabweichung der Verzinsungsrate über die gesamte 30-Epochen-Historie, daher fungierte die aufgeblasene erste Verdienst-Epoche eines neuen Nodes (winzige Stimmkraft → hohe Pro-Einheits-Rate, die sich dann normalisiert) als Ausreißer, der den CV hoch hielt – Bewertung 0 – für Monate bis zur Alterung. Jetzt nutzt es ein nachlaufendes Fenster (letzte 12 Verdienst-Epochen) und eine robuste Median/MAD-Dispersion, sodass die Aufblasungs-Epoche ein harmloser Ausreißer ist, während echte anhaltende Volatilität weiterhin niedrig bewertet wird.
v4.5 (2026-06-30) — Self-Bond größenneutral gemacht. Die reine Verhältnis-Kurve konnte eine große absolute Self-Bond mit niedrigem Verhältnis UNTERHALB einer kleinen Self-Bond mit hohem Verhältnis bewerten. Self-Bond berücksichtigt jetzt das Größere einer Alignment-Quote oder eines gesättigten absoluten Betrags (Obergrenze bei 5 Mio. FLR), daher erhalten sowohl ein großer verpflichteter Operator als auch ein kleiner vollständig ausgerichteter beide volle Punkte – es belohnt Verpflichtung, nicht Vermögen, und die Validator-Qualität bleibt in den anderen Dimensionen.
v4.4 (2026-06-30) — Zwei echte Bug-Fixes. (1) Self-Bond war eine TOTE Dimension: Sie las ein Flaremetrics-Feld, das die API gelöscht hatte, daher bewertete jeder Provider 0/7. Neu von der echten P-Chain Node-Self-Bond des Operators (Kreuzverweis aus dem Validator-Set nach nodeID). (2) Compliance hörte auf, Epochen vor der Aktivität eines Providers zu bestrafen – ein neuer Node, der seit seiner Aktivierung sauber verdient, wurde zuvor für jede Epoche belastet, die vor ihm lag, was ihn wochenlang bei 0/10 hielt. Verpasste Epochen werden jetzt nur innerhalb des aktiven Fensters jedes Providers gezählt.
v4.3 (2026-06-03) — Methodologie-Klärung, keine Scoring-Mathematik-Änderung. Die Accuracy-Dimension ist jetzt explizit als die On-Chain-Secondary-Band-Landequote definiert (Preis-QUALITÄT – welcher Anteil der eingereichten Preise landet innerhalb der akzeptierten Spanne), unterschieden von der Compliance-Dimension, die verpasste Belohnungs-Epochen zählt (FSP-TEILNAHME). Diese Seite und die Validatoren-Tabellen-Tooltips wurden umgeschrieben, um die Unterscheidung explizit zu machen, und eine Compliance-Spalte wurde neben Accuracy hinzugefügt. Beide Dimensionen behalten ihre bisherigen Gewichte (25 und 10) und Eingaben (fseAccuracySecondary und epochsWithoutRewards) bei.
v4.2 (2026-05-20) — Rewards Distributed-Dimension repariert. Sie war mit einem Flaremetrics-Belohnungsverteilungsfeld verdrahtet, das die v3-API des Providers gelöscht hatte, daher las die Dimension 0 für jeden Provider und trug nichts bei. Neu verdrahtet mit On-Chain-FSP-Delegations-Belohnungs-Summen – denselben Belohnungsanspruchs-Daten, die die Compliance-Dimension bereits aggregiert – daher differenziert die Dimension wieder.
v4.1 (2026-05-20) — Compliance-Dimension begrenzt. epochsWithoutRewards konnte negativ ankommen, da der FSP-Belohnungs-Cron seine Epochen-Präsenz-Zählung über das rollende Fenster hinaus akkumulierte, was Compliance sein 10-Punkte-Cap überschreiten ließ (beobachtet bis zu ~58) und das Composite über sein Maximum drückte – ungefähr 70% der Provider auf ein flaches 100 sättigend. Compliance ist jetzt auf sein Gewicht begrenzt, und der FSP-Cron berechnet Belohnungszusammenfassungen zustandslos pro Fenster neu, daher kann die Zählung nicht mehr abdriften.
v4.0 (2026-05-11) — Vollständiger Fairness-Audit-Pass äquivalent zur v4.0-Auslieferung des Validator-Scores. Zwei echte Bugs behoben: (1) Delegator Count hatte einen perversen Anreiz bei 500 – vor der Behebung gab das 500-Delegator-Bucket 14 Punkte zurück, aber die >500-Obergrenze gab das zugrunde liegende WEIGHT_DELEGATORS (12), daher verlor das Gewinnen eines Delegators über diese Grenze 2 Punkte. Jetzt logarithmisch skaliert von 5 → 500, monoton aufwärts. (2) V2 Participation-Ebenen waren zusammengebrochen – teilweise V1-Registrierung und vollständiges V2 (Scaling + FastUpdates + FDC) gaben beide 15, daher bot das Upgrade von teilweise zu vollem V2 null Verbesserung des Scores. Jetzt Pro-Protokoll-Stapelung (aktiv +3, V1 +4, jedes V2-Protokoll +~2,67). Grenzenklippen in Accuracy (hatte einen 7-Punkte-Cliff bei 97%), Stability und Self-Bond Ratio eliminiert – alle linearisiert mit Werten bei Bucket-Grenzen bewahrt. Reward Rate-Kurve neu gewogen, daher Median = Hälfte der Dimensionspunkte (war 40%). Abgestimmte veraltete Dimensions-Docstrings mit aktuellen Gewichtswerten. Netto-Effekt: jede Dimension ist monoton aufwärts auf der Eingabe-Achse, und kein Provider kann seinen FlareWatch-Score senken, indem er eine echte operationelle Metrik verbessert.
v3 (2026-05-09 → 2026-05-11) — 13-Dimensionen-Scoring mit dynamischer Gewichtsumverteilung und Stimmanteils-Verdünnungs-Strafe. MIRROR Participation als Dimension erster Klasse eingeführt (12 Basis + bis zu +3 Überperformance-Bonus mit Bayesianischer Schrumpfung und 30-Tage-Daten-Ansammlungs-Gate). Identity und Self-Bond als diskrete Dimensionen hinzugefügt. Reward Rate zum Median-verankert verschoben. Accuracy verwendet FSE-Sekundär-Metrik für die hochauflösende Spanne. Consistency verwendet CV über aktuelle Epochen.
v2 und früher — Versionen vor v3 sind hier nicht dokumentiert; sie verwendeten eine einfachere Teilmenge von Dimensionen und gehen der dynamischen Gewichtsumverteilung voraus. Versionen zugunsten des aktuellen Modells zurückgezogen.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.