Méthodologie du score des fournisseurs FTSO

Version de l'algorithme : v4.11 · Dernière mise à jour : 2026-07-04

FlareWatch attribue à chaque fournisseur de données FTSO un score composite de 0–100 sur 12 dimensions notées. Les mathématiques sont déterministes, les entrées sont des données publiques on-chain et de l'écosystème Flare.[Flaremetrics] [FSE] [Flare Explorer], et le même algorithme s'applique à chaque fournisseur — y compris le propre fournisseur FTSO de FlareWatch, qui est marqué par cette fonction exacte sans traitement particulier. Cette page documente chaque dimension et seuil afin que les délégateurs et les opérateurs puissent voir exactement comment le score est calculé et pourquoi chaque valeur a été choisie. Chaque affirmation ici se lie à sa source en amont principale — voir Sources et références en bas.

Portée : cette page documente le score du fournisseur FTSO — ce que vous voyez en mode délégation sur la page des validateurs (délégation de WFLR aux fournisseurs de données FTSO pour la part d'inflation FTSO). Le score du validateur affiché en mode staking (délégation de FLR à un validateur P-Chain pour les récompenses VRM + MIRROR) utilise un algorithme distinct à 9 dimensions axé sur les opérations du validateur — disponibilité, frais, fiabilité, etc. Ce sont des rôles on-chain distincts avec des récompenses distinctes, notés séparément. Consultez Méthodologie du score du validateur pour le côté staking.
Couverture chaîne FLR / SGB : l'onglet Délégation sur la page des validateurs dispose d'un bouton bascule FLR / SGB pour les portefeuilles détenant du Songbird (SGB). Cette méthodologie documente le score côté FLR uniquement. Les fournisseurs FTSO Songbird sont listés sans score composite — les mêmes données de précision / cohérence / récompenses FSP que nous utilisons pour FLR ne sont pas encore intégrées dans notre pipeline Songbird (Flaremetrics, notre source de données FLR principale, ne couvre pas Songbird). Ce que les délégateurs SGB voient aujourd'hui : nom du fournisseur + logo du registre cross-réseau TowoLabs, poids actuel (WSGB délégué, lu directement du contrat WNat de Songbird via notre propre RPC Songbird), et l'URL du fournisseur. Triez par poids ; un poids plus élevé est le signal de proxy jusqu'à ce que les données de précision arrivent. Lorsque nous intégrerons le pipeline de précision + taux de récompense côté Songbird, la même formule 13 dimensions s'appliquera aux fournisseurs SGB — aucun nouvel algorithme de notation, juste la formule FLR calculée par rapport aux données Songbird. La notation des validateurs FlareWatch (onglet staking) n'a pas d'équivalent SGB du tout : l'ensemble des validateurs P-Chain de Songbird est restreint aux entités approuvées par la Flare Foundation, la délégation P-Chain SGB de détail est rare et l'onglet staking reste FLR uniquement.
Bandes de score
90+Tier supérieur — top ~10–20 % des fournisseurs FTSO. Profil typique : taux de récompense supérieur à la médiane, haute précision, participation complète au protocole V2 (FTSO Scaling + Fast Updates + FDC), frais faibles ou nuls, grande base de délégateurs, nœuds validateurs payant MIRROR, marque nommée. Aucune dimension unique requise — les fournisseurs atteignent le tier supérieur en accumulant la force dans la plupart des catégories.
80–89Fort — répond à la plupart des critères clés ; une ou deux dimensions en deçà du tier supérieur.
70–79Bon — répond à tous les critères de base ; aucune lacune majeure.
60–69Acceptable — utilisable mais non différencié.
<60Sous la médiane — lacunes significatives dans une ou plusieurs dimensions. Fait mathématique, non un jugement de qualité.
Dimensions (poids bruts — somme 172, normalisés à 100)
« Active » conditionne deux dimensions (Fee et V2 Participation) : un fournisseur qui n'est pas opérationnel ne devrait pas recevoir de crédit pour annoncer des frais réduits. Un fournisseur est considéré comme actif s'il a un taux de récompense publié ou si les données de récompense du protocole Flare Systems montrent qu'il a distribué des récompenses lors d'au moins une epoch de la fenêtre de scoring. Jusqu'au 2026-07-31, il s'agissait uniquement du taux de récompense, provenant d'une seule API tierce — ainsi un fournisseur non couvert par cette API obtenait un score de zéro sur les deux dimensions alors qu'il distribuait visiblement des récompenses chaque epoch. L'activité est une propriété du fournisseur, non de celui qui le liste.
Taux de récompense25 pts max
Quoi : Le taux de récompense du fournisseur par époque, ancré à la médiane du réseau.
Comment : ratio = providerRate / medianRate. Linéaire : ratio 1,0 (médiane) → 12,5 pts, ratio 2,0 → 25 pts (cap). Fournisseur inactif (rewardRate ≤ 0) → 0. v4.0 (2026-05-11) : cap rebasé de sorte que la médiane = la moitié des points de la dimension (non 40 % comme avant).
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).
Pourquoi : Le taux de récompense est la #1 chose que les délégateurs expérimentent. L'ancrage à la médiane garde le score honnête à mesure que l'économie des récompenses du réseau évolue — un fournisseur à 1,2× la médiane dans une ère de faibles récompenses se classe de la même manière qu'un à 1,2× dans une ère de récompenses élevées. Les caps et filtres d'anomalies empêchent les valeurs aberrantes d'une seule époque de dominer.
Précision25 pts max
Quoi : Précision des prix FTSO provenant de Flare Systems Explorer (FSE) — taux d'atterrissage des bandes de récompense primaire (IQR étroit) et secondaire (plus large).
Comment : Un mélange 40/60 des taux d'atterrissage des bandes PRIMAIRE (IQR étroit) et SECONDAIRE (plus large) FTSO (v4.8), reflétant la propre répartition des récompenses de Flare — FIP.11 paie les récompenses des flux d'ancrage 40% primaire / 60% secondaire. La bande secondaire utilise la courbe par morceaux antérieure (97% → 25 … 70% → 2) ; elle est presque saturée dans le champ (95–99%), donc elle différencie à peine. La bande primaire utilise une courbe linéaire absolue — 28% → 0 jusqu'à 78% → 25 complet — donc l'ingénierie de bande étroite véritablement plus difficile, où les fournisseurs se répartissent réellement de ~28% à ~80%, c'est ce qui sépare le champ. Ancres fixes (pas des percentiles du champ), donc le score reste redérivable à partir des entrées propres d'un fournisseur. Fallback bande unique quand une seule est disponible ; neutre 12.5 sans données FSE.
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
Pourquoi : Les époques manquées = revenu de récompense manqué pour les délégateurs. La précision est ce qui détermine si les soumissions du fournisseur comptent réellement pour le consensus FTSO, et la métrique secondaire (qui pondère davantage les époques récentes) est celle qui cartographie le plus proprement aux performances actuelles.
Cohérence20 pts max
Quoi : La stabilité du taux de récompense du fournisseur au cours de ses dernières époques de gain.
Comment : Volatilité à la baisse sur les dernières périodes de gains d'un prestataire, mesurée uniquement entre les périodes véritablement consécutives — une période au cours de laquelle un prestataire n'a rien gagné ne laisse aucune trace, et les deux périodes de part et d'autre de cet écart ne sont jamais comparées l'une à l'autre. Seules les BAISSES d'une période à l'autre comptent — une hausse contribue zéro — donc un taux stable ou en hausse score près du maximum et une reprise améliore le score au fur et à mesure qu'elle se produit. Les baisses sont agrégées en RMS, donc un creux important pèse plus qu'une légère baisse, et pondérées vers les paires récentes (décroissance 0,8) pour qu'une reprise active remonte le score tandis que les anciennes baisses s'estompent. cv = 0 → 20 pts ; cv ≥ ~0,167 → 0. Neutre 10 quand moins de 3 paires de périodes consécutives existent dans les 12 dernières périodes de gains.
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)
Pourquoi : Deux fournisseurs avec le même taux de récompense moyen peuvent offrir des expériences très différentes aux stakers : l'un qui baisse fortement est pire qu'un qui reste stable ou grimpe. La cohérence récompense ce qu'un délégant souhaite réellement — un taux stable ou croissant — et ne pénalise que les baisses, proportionnellement à leur amplitude. Un taux remontant À LA HAUSSE n'est jamais pénalisé (la mesure symétrique antérieure le faisait, ce qui était à l'envers). Une forte baisse récente obtient une note basse puis se récupère au fil du temps.
Participation V215 pts max
Quoi : Si le fournisseur exécute la pile V2 moderne (FTSO Scaling + Fast Updates + FDC).
Comment : Empilement par protocole. Ligne de base active (rewardRate > 0) +3, V1 partiel (soumettre + signer + votant) +4, chaque protocole V2 (FTSO Scaling / Fast Updates / FDC) +~2,67 chacun, cap à 15. Inactif → 0. v4.0 (2026-05-11) a divisé le tier précédent tout ou rien (où V1 partiel = V2 complet = 15 — aucune incitation à mettre à niveau) en bonus par protocole qui s'empilent.
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)
Pourquoi : V2 est où le réseau se dirige. L'empilement par protocole de v4.0 signifie que la mise à niveau de V1 partiel à V2 complet déplace réellement le score (pré-correction, cela n'a pas — V1 partiel et V2 complet retournaient tous deux 15). L'ajout d'un seul protocole V2 améliore désormais la dimension.
Frais15 pts max
Quoi : Les frais que le fournisseur charge sur les récompenses déléguées.
Comment : Interpolation linéaire entre les points de rupture : 0 % → 15, 5 % → 13, 10 % → 10, 15 % → 7, 20 % → 4, ≥25 % → 0. Fournisseur inactif → 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
Pourquoi : Les frais réduisent directement ce que les délégateurs reçoivent. L'interpolation linéaire (plutôt que des buckets) signifie un frais de 7 % score entre 10 % et 15 % plutôt que de s'accrocher à un bucket — les opérateurs ne reçoivent pas de crédit pour arrondir leurs frais jusqu'à la limite du bucket suivant.
Participation MIRROR12 (+3 bonus) pts max
Quoi : Si les nœuds validateurs P-Chain de l'opérateur paient activement la part d'inflation FTSO aux stakers, plus un bonus de surperformance.
Comment : Le score de base s'ajuste linéairement avec la fraction des nodeIDs de l'opérateur payant les récompenses MIRROR. Tous les nœuds actifs → 12 pts. Partiel → proportionnel. Aucun → 0. Depuis le 2026-05-11, le signal « actif » provient de deux sources canoniques : événements RewardClaimed(claimType=3) on-chain sur le V2 RewardManager ET allocations claimType=3 dans le JSON Merkle officiel FSP — l'une ou l'autre suffit. Avant la mise à jour, nous utilisions le flux on-chain comme seul signal, ce qui produisait des faux négatifs pour les fournisseurs dont MIRROR se règle via un chemin de réclamation non standard. Plus un bonus de surperformance pouvant atteindre +3 pts lorsque les validateurs de l'opérateur livrent constamment plus de 100% de (vrm + mirror) / expected — le rétrécissement bayésien avec une porte d'accumulation de données de 30 jours et un minimum d'échantillon de 3 enjeux empêche les petits ou nouveaux opérateurs de manipuler le bonus sur quelques lectures chanceuses.
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
Pourquoi : La participation MIRROR est ce qui délègue la part d'inflation FTSO à vos stakers. Un fournisseur V2-actif dont les nœuds validateurs ne paient pas MIRROR livre ~5–15 % de rendement inférieur aux délégateurs par rapport au même fournisseur avec des nœuds actifs. Le bonus de surperformance récompense une livraison constamment meilleure que prévu sans gonfler les nouveaux opérateurs sur de petits échantillons — le rétrécissement bayésien et la porte d'accumulation de 30 jours le maintiennent équitable.
Nombre de délégateurs12 pts max
Quoi : Nombre de portefeuilles distincts actuellement délégués à ce fournisseur, comptabilisés à partir de l'état de la chaîne.
Comment : Mise à l'échelle logarithmique de 5 → 500 délégateurs mappés à 0 → 12. ≤5 → 0, ≥500 → 12 (plafond). Correspond au style du signal de compte de la dimension Trust du validateur. v4.0 (2026-05-11) : correction d'un vrai bug où le schéma de panier précédent avait une incitation perverse exactement à 500 délégateurs (avant la correction : 500 → 14, 501 → 12 — gagner un délégateur à travers cette limite PERDAIT 2 points).
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
Pourquoi : Le nombre de délégateurs est un signal de confiance — indépendant de la taille de l'enjeu. Un fournisseur avec 200 délégateurs a été choisi par 200 stakers indépendants ; l'un avec 5 l'a été par près de son opérateur. L'échelle logarithmique donne des rendements décroissants au-delà de ~50 délégateurs sans jamais s'inverser (comme le faisait la notation par panier avant la v4.0).
Participation aux époque10 pts max
Quoi : Si le fournisseur participe activement aux époques.
Comment : FSE marque le fournisseur comme actif → 10. Le fournisseur a rewardRate > 0 (Flaremetrics) mais pas de drapeau actif FSE → 7 (actif selon les données du marché, confirmation FSE manquante). Sinon → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Pourquoi : Détecte les fournisseurs dont le flux de récompenses s'est arrêté même si Flaremetrics les liste toujours. Différent de la Précision (qui porte sur la correction par époque) — la Participation concerne le simple fait de se présenter.
Stabilité de la puissance de vote10 pts max
Quoi : Variation quotidienne en pourcentage de la puissance de vote du fournisseur.
Comment : Linéaire par morceaux en variation quotidienne absolue en pourcentage. <1% → 10. Linéaire de 1% → 3% (10 → 7). Linéaire de 3% → 5% (7 → 4). Linéaire de 5% → 10% (4 → 2). Continue vers 0 au-delà de 10%. v4.0 (2026-05-11) : a linéarisé les falaises de panier précédentes (jusqu'à 3 points de falaises à chaque seuil).
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)
Pourquoi : Les grands mouvements quotidiens de la puissance de vote indiquent souvent une vague de délégateurs entrante ou sortante — les stakers lisant le tableau voient une cible mouvante. Une puissance de vote stable signale un fournisseur établi avec des délégateurs fidèles.
Conformité10 pts max
Quoi : Si le fournisseur a été payé dans chaque époque de récompense DEPUIS qu'il est devenu actif dans les données des récompenses FSP.
Comment : 10 points complets pour zéro époque manquée dans la fenêtre active du fournisseur. Chaque époque manquée déduit 3 pts (limité à 0). Neutre 5 lorsqu'aucune donnée FSP n'est disponible. v4.4 (2026-06-30) : les époques manquées sont désormais comptabilisées uniquement à partir de la première époque de participation du fournisseur — un nouveau fournisseur n'est plus facturé pour les époques avant son existence (ce qui maintenait auparavant les nouveaux nœuds propres à 0/10 pendant des semaines).
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)
Pourquoi : Une époque manquée dans la distribution officielle des récompenses du Flare Systems Protocol signifie que le fournisseur n'a pas respecté la conformité du protocole pour cette époque — conditions minimales, politique de signature, etc. Compter uniquement à partir de la première participation maintient la mesure équitable pour les nouveaux fournisseurs tout en pénalisant les manquements authentiques. Trois points par manquement est abrupt, donc un seul manquement est un signal notable mais récupérable ; ~3 manquements annulent la dimension.
Identité8 pts max
Quoi : Si le fournisseur a un vrai nom de marque ou juste une adresse hexadécimale.
Comment : Marque nommée (≥4 caractères, ne commençant pas par 0x) → 8. Court ou anonyme (<4 caractères) → 4. Adresse hexadécimale pure / 0x comme nom → 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
Pourquoi : Un fournisseur nommé a choisi d'être trouvable et responsable — il peut être recherché, contacté et tenu de respecter les engagements publiés. Les fournisseurs anonymes par adresse sont fonctionnels mais offrent moins de signaux de confiance aux délégateurs les évaluant.
Self-Bond7 pts max
Quoi : L'obligation de nœud P-Chain PROPRE de l'opérateur (peau en jeu) — excluant l'enjeu que d'autres délèguent au nœud. Une porte d'engagement neutre en taille, pas un classement de richesse.
Comment : Crédité sur le PLUS GRAND des deux axes saturants : (1) alignement — propre obligation en tant que part de l'enjeu total engagé (≥10% → complète) ; ou (2) absolu — capital propre en jeu, plafonné à 5M FLR donc 5M et 80M obtiennent le même score. v4.4 (2026-06-30) : ré-approvisionné à partir du vrai self-bond P-Chain de l'opérateur (poids validateur croisé référencé par nodeID) — le champ Flaremetrics antérieur qu'il lisait a été discontinué, donc chaque fournisseur avait marqué 0. v4.5 (2026-06-30) : ajout de l'axe absolu + saturation pour qu'un grand self-bond à faible ratio ne soit pas noté en dessous d'un petit à haut ratio, sans laisser la taille gagner ou pénaliser les petits opérateurs.
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)
Pourquoi : Peau en jeu — un opérateur avec son propre capital à risque est aligné avec les délégateurs. Mais la taille du self-bond n'est pas un substitut pour la QUALITÉ de l'opérateur (qui vit dans les autres dimensions), donc un petit opérateur totalement aligné et un grand opérateur engagé obtiennent tous deux la note complète. Seul un opérateur avec peu de son propre capital engagé — petite part ET petit montant — marque en dessous du complet.
Comment marquer 100/100 — un playbook de fournisseur FTSO
L'audit d'équité v4.0 a été spécifiquement conçu pour que maximiser chaque dimension de score vous rend vraiment un meilleur fournisseur FTSO pour vos délégateurs. Améliorer votre score n'est pas manipuler le système — c'est le système fonctionnant comme prévu. Voici le playbook par dimension.
Taux de récompense — 25 pts. Livrez ≥ 2× le taux de récompense FSP médian du réseau par époque (après frais, post-distribution du protocole). Linéaire de 0 à 2× médian : médian → 12,5, 2× médian → 25. Pourquoi cela s'aligne : c'est le montant en dollars atteignant réellement vos délégateurs par époque.
Précision — 25 pts. Ciblez ≥97% de taux d'atterrissage en bande secondaire sur FSE pour les points complets. Linéaire par morceaux donc 95% → 18, 93% → 16, 90% → 13, etc. — chaque amélioration de 1% bouge le score. Ceci est la QUALITÉ des prix, pas la participation aux époques : cela mesure quelle fraction des prix soumis atterrissent à l'intérieur de la bande acceptée on-chain. Un fournisseur avec une haute Précision publie des prix proches du consensus ; l'un avec une basse Précision soumet de manière fiable mais est hors consensus plus souvent. Pourquoi cela s'aligne : les soumissions hors bande produisent des récompenses plus petites pour les délégateurs même lorsque le fournisseur participe à chaque époque. La dimension Conformité distincte ci-dessous suit la participation aux époques.
Cohérence — 20 pts. Minimisez la variance du taux de récompense par époque (CV = écart-type/moyenne sur les époques récentes). CV = 0 → 20, CV = 0,2+ → 0. Pourquoi cela s'aligne : deux fournisseurs avec le même taux de récompense moyen ne sont pas équivalents — des paiements prévisibles battent les volatiles pour l'UX du staker.
Participation V2 — 15 pts. Accumulez les protocoles additivement : ligne de base active + enregistrement V1 partiel + chaque protocole V2 (Scaling, FastUpdates, FDC). V2 complet + actif + V1 enregistré = 15. Pourquoi cela s'aligne : V2 est vers où le réseau va ; chaque protocole supplémentaire que vous adoptez est un investissement futur dont vos délégateurs bénéficient.
Frais — 15 pts. Facturez ≤ 5% pour 13 pts, 0% pour 15. Rampe linéaire par morceaux à travers les seuils 5%/10%/15%/20%/25% vers 0. Pourquoi cela s'aligne : frais moins élevés = plus de récompense atteint directement vos délégateurs.
Participation MIRROR — 12 + jusqu'à 3 bonus. Exécutez tous les nœuds validateurs P-Chain de votre opérateur comme MIRROR-actifs (soit via des événements RewardClaimed on-chain SOIT via les allocations JSON Merkle FSP — source duale v3.6). La surperformance soutenue (ratio (vrm+mirror)/expected médian au-dessus de 1,05) sur ≥3 enjeux payés après 30 jours d'observation gagne jusqu'à +3 bonus. Pourquoi cela s'aligne : MIRROR est la part de vos délégateurs de l'inflation FTSO ; les nœuds ne payant pas MIRROR livrent ~5-15 % de rendement inférieur aux stakers.
Nombre de délégateurs — 12 pts. Mis à l'échelle logarithmiquement 5 → 500 délégateurs mappés à 0 → 12. Construisez une base de stakers indépendants, pas juste quelques baleines. Pourquoi cela s'aligne : le compte est un signal de confiance indépendant de la taille de l'enjeu ; 200 délégateurs vous choisissant signifie 200 approbations indépendantes.
Participation aux époque — 10 pts. Présentez-vous à chaque époque avec un taux de récompense positif et un drapeau FSE actif. Pourquoi cela s'aligne : détecte les flux de récompenses bloqués que les dimensions par époque pourraient manquer.
Stabilité — 10 pts. Maintenir la variation de la puissance de vote jour après jour en dessous de 1 %. Rampe linéaire par morceaux à partir de là. Pourquoi c'est pertinent : une puissance de vote stable signale des délégants établis (communauté fidèle) plutôt que des vagues de baleines transitoires.
Conformité — 10 pts. Zéro époque de récompense manquée dans les données FSP. Chaque manque coûte 3 pts ; ~3 manques annulent la dimension. C'est la PARTICIPATION, pas la qualité du prix : elle compte les époques où le prestataire a été pénalisé pour non-respect des conditions minimales, de la politique de signature ou d'autres exigences du protocole — distinct de la dimension Précision ci-dessus qui évalue le prix en bande. Pourquoi c'est pertinent : une époque manquée dans la distribution des récompenses du protocole lui-même signifie que le prestataire n'a pas respecté les conditions minimales et que les délégants n'ont rien gagné cette époque. Un prestataire peut avoir une grande Précision sur les époques auxquelles il a participé et manquer des époque entières.
Identité — 8 pts. Enregistrer un vrai nom de marque (≥4 caractères, pas une adresse hex) sur Flaremetrics ou FSE. Les prestataires anonymes par adresse obtiennent 0 ; les prestataires nommés obtiennent 8. Pourquoi c'est pertinent : les prestataires nommés sont trouvables et responsables ; c'est le signal de confiance baseline.
Auto-engagement — 7 pts. Engager votre propre obligation de nœud P-Chain (pas du stake que d'autres délèguent à vous). Pleins points pour SOIT une part significative de votre stake total (≥10 %) SOIT un montant absolu significatif (l'axe absolu sature à 5M FLR, donc un grand opérateur ne peut pas surclasser un petit sur la taille). Pourquoi c'est pertinent : avoir de la peau en jeu — les opérateurs ayant leur propre capital à risque partagent les résultats de rendement de leurs délégants. C'est une porte d'engagement neutre en taille, pas un classement de richesse : un petit opérateur parfaitement aligné et un grand opérateur engagé maximisent tous les deux cette dimension, et votre qualité opérationnelle est jugée par les autres dimensions.
Signaux à délai : vous ne pouvez pas les contourner : La cohérence nécessite ≥3 époques d'historique. Le bonus de surperformance MIRROR nécessite 30 jours d'observation plus ≥3 échantillons de stake payés. La conformité nécessite que les données FSP couvrent suffisamment d'époques pour compter. Construisez un palmarès ; le score suivra.
Le score brut totalise un maximum de 172 sur les 12 dimensions notées et est ensuite normalisé à 100. Une performance parfaite sur les entrées donne 172/172 → 100 affiché. Une pénalité de dilution du pouvoir de vote allant jusqu'à −3 pts s'applique pour les très gros fournisseurs (>1,34 Mds VP) comme bris d'égalité.
Comment vérifier votre propre score
Chaque score du tableau des prestataires est reproductible à partir de données publiques. Si vous êtes un opérateur et que les mathématiques ici ne correspondent pas au score que vous voyez, la bonne approche est de le vérifier vous-même avant de supposer que nous nous sommes trompés. Procédure :
  1. Recherchez les statistiques publiques de votre prestataire sur flaremetrics.io (recherchez par nom ou collez votre adresse de délégation). Notez votre fspRewardRate, delegationFeePercentage, wNatWeight et votePowerDailyChangePct.
  2. Vérifiez votre FTSO V2 + précision sur flare-systems-explorer.flare.network. Trouvez votre entité. Vérifiez providersuccessrate.secondary pour la précision, plus les drapeaux entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc pour le statut V2.
  3. Vérifiez votre participation MIRROR sur le contrat V2 RewardManager via flare-explorer.flare.network. Recherchez les événements RewardClaimed avec claimType=3 faisant référence à vos nodeIDs. S'il n'y en a pas de récents pour l'un de vos nœuds, vous apparaîtrez comme inactif MIRROR sur le score.
  4. Insérez vos entrées dans les formules ci-dessus. Le bloc de code de chaque dimension vous indique exactement l'arithmétique à effectuer. Additionnez les dimensions, divisez par 172 (max brut), multipliez par 100, et vous avez votre score composite brut.
  5. Appliquez la pénalité de dilution si vous êtes grand. La puissance de vote au-dessus de 1,34B est −3, au-dessus de 1B est −1. La carte du score final ci-dessous a les seuils exacts.
  6. Comparez à votre score affiché. Le score affiché reflète également la redistribution dynamique des poids — lorsque la plupart des prestataires se regroupent dans une dimension (faible écart type dans l'ensemble actif), le poids de cette dimension est redistribué aux dimensions où l'écart est plus large. Le panneau de répartition des scores sur chaque ligne de prestataire affiche les valeurs par dimension actuelles.
  7. Si les mathématiques ne correspondent pas, envoyez un e-mail à [email protected] avec votre adresse de délégation, les paramètres que vous avez utilisés et le score que vous avez calculé. Nous répondrons, et si nous avons fait une erreur, nous la corrigerons publiquement.
Préoccupations courantes des opérateurs
Mon taux de récompense est au-dessus de la médiane mais mon score Taux de récompense n'est pas 25/25 — pourquoi ?
Le taux de récompense est linéaire au rapport par rapport à la médiane : score = ratio × 12,5, donc 1,0× médiane = 12,5/25 et vous avez besoin d'un ratio de 2,0× pour atteindre le plafond. Un prestataire à 1,2× la médiane score 15, à 1,5× score ~18,8, à 2,0× score les 25 complets. Le plafond (plus le filtre d'anomalie 3×-médiane) existe pour qu'une seule époque de récompense anormalement élevée ne puisse pas dominer la dimension ; si votre taux est constamment dans le top décile, le score le récompense toujours lourdement.
Je viens de passer à V2 — quand mon score V2 se met-il à jour ?
Le statut V2 provient des drapeaux entityminimalconditionslatest de FSE (ftso_scaling, ftso_fast_updates, fdc). Depuis la v4.0, la dimension s'empile par protocole : baseline active +3, inscription V1 (submit + signature + voter) +4, et chaque protocole V2 +~2,67. Un prestataire inscrit comme voteur avec des adresses de soumission et de signature mais aucun des trois protocoles V2 score 7/15, et chaque protocole V2 individuel que vous activez déplace le score — les trois en direct vous obtient les 15 complets. Les modifications apparaissent à la prochaine exécution cron de FlareWatch (toutes les 5 minutes) après que FSE les reflète.
Ma précision sur FSE est 96 % mais je score inférieur à ce que j'attendais.
La dimension Précision utilise la métrique de précision secondaire de FSE (résolution plus élevée dans la bande 94–97 % où la plupart des prestataires se regroupent). 95–96 % correspond à 18 pts ; vous avez besoin de ≥97 % pour les 25 complets. Les seaux sont serrés au sommet car quelques dixièmes de pour cent dans la bande 95–97 % représentent une véritable séparation de performance entre les prestataires.
Je fournis MIRROR — pourquoi FlareWatch me montre-t-il comme inactif MIRROR sur mon score de prestataire ?
Depuis 2026-05-11, la participation MIRROR est détectée à partir de DEUX sources : les événements RewardClaimed(claimType=3) on-chain sur le V2 RewardManager, ET les allocations claimType=3 dans le JSON Merkle officiel du FSP. Un nodeID apparaissant dans l'une ou l'autre source compte comme actif. Pour les opérateurs multi-nœuds, le score utilise la fraction de vos nœuds qui sont actifs (1/3 actif = 4/12 de base, etc.). Si un nœud devrait être classé actif mais ne l'est pas après le prochain cycle de balayage, envoyez-nous un e-mail avec le nodeID et l'époque spécifique où vous vous attendriez à le voir — nous vérifierons les deux sources.
Ma puissance de vote a changé de 8 % hier — pourquoi le score Stabilité est ~2,8/10 ?
La stabilité de la puissance de vote est linéaire par morceaux dans la variation jour après jour absolue (linéarisée en v4.0 — aucune falaise de seau) : <1 % → 10, rampe 1→3 % jusqu'à 7, 3→5 % jusqu'à 4, 5→10 % jusqu'à 2, puis vers 0 au-delà de 10 %. Un mouvement de 8 % atterrit sur la rampe 5–10 % à 4 − (8 − 5) × 0,4 = 2,8. L'intention est de signaler les prestataires connaissant un renouvellement significatif de délégants afin que les jalonneurs puissent le voir sur le tableau. Le score se rétablit dès que votre puissance de vote se stabilise ; un jour volatil ne vous ancre pas en bas de manière permanente.
Mon prestataire est nommé avec mon adresse d'entité (0x…). Pourquoi le score Identité est 0 ?
L'identité attribue 8 pts pour un vrai nom de marque (≥4 caractères, ne commençant pas par 0x ou hex uniquement) et 0 pour un nom d'adresse pure. Nous ne pouvons pas fabriquer un nom — définissez votre profile.name sur Flaremetrics et nous le récupérerons à la prochaine exécution cron. Si votre entité a un profil mais que le champ nom est vide, la même chose s'applique.
J'ai une petite base de délégants mais engagée — pourquoi mon score Nombre de délégants est-il plafonné ?
Delegator Count utilise des comptages réels : chaque portefeuille détenant WFLR est vérifié on-chain pour ses délégations actuelles, et les délégateurs distincts de chaque fournisseur sont additionnés (actualisés toutes les ~6 heures, recoupés par rapport à un journal d'événements indépendant). Depuis v4.0, il utilise une échelle logarithmique de 5 → 500 délégateurs mappés à 0 → 12 pts, plafonnée à 500 (≤5 marque 0). L'échelle logarithmique signifie que les petits fournisseurs avec une croissance forte du nombre de délégateurs montent le plus vite ; passé ~50 délégateurs, les délégateurs supplémentaires déplacent moins l'aiguille — mais la courbe est monotone, donc ajouter un délégateur ne peut jamais diminuer le score (les anciens buckets pré-v4.0 le pouvaient).
Mon score a baissé après avoir ajouté un nœud — qu'est-ce qui s'est passé ?
Si le nouveau nœud n'affiche pas encore les événements MIRROR claimType=3, votre fraction MIRROR baisse (par ex., de 1/1 = 100 % à 1/2 = 50 %), réduisant le score de base de participation MIRROR. Une fois que le nouveau nœud commence à payer MIRROR (généralement dans une ou deux époques de récompense après l'activation), la fraction se rétablit et le score remonte.
Puis-je faire appel de mon score ou demander un examen manuel ?
Oui. Envoyez un e-mail à [email protected] avec votre adresse de délégation et une préoccupation spécifique. Nous répondons à chaque opérateur. Les choses sur lesquelles nous agirons : corrections de classification MIRROR, erreurs mathématiques spécifiques à une dimension, correctifs de nom/logo via Flaremetrics. Les choses sur lesquelles nous n'agirons pas : demandes de relever manuellement un score en dehors de l'algorithme, demandes d'exclure ou de déclasser un concurrent.
Ce que nous ferons et ne ferons pas
Pour lever l'ambiguïté sur notre façon d'exploiter le score, voici des engagements explicites. Si nous violons jamais l'un d'entre eux, documentez-le et envoyez un e-mail à [email protected] — nous le corrigerons publiquement.
✓
Nous n'accepterons pas de paiement pour des scores plus élevés, un placement sponsorisé ou un traitement favorable d'aucune sorte. Le score est calculé de manière déterministe à partir de données publiques.
✓
Nous ne codifierons pas les augmentations par prestataire. Il n'y a pas de ligne « X obtient +5 parce que nous l'aimons » n'importe où dans le code. Le même algorithme s'applique à chaque prestataire, y compris le prestataire propre de FlareWatch, qui est noté par cette fonction exacte.
✓
Nous n'exclurons pas les prestataires du tableau pour des raisons non publiques. La liste est tirée de Flaremetrics + FSE ; notre affichage inclut chaque prestataire actif que ces sources révèlent.
✓
Nous publierons les modifications d'algorithme. Chaque mise à jour de version est documentée dans la carte Versions de cette page avec la justification et les changements apportés. Les modifications majeures reçoivent une entrée de journal de modifications supplémentaire visible à partir de la page du journal de modifications de l'application.
✓
Nous répondrons aux e-mails des opérateurs. Tout opérateur qui envoie un e-mail à [email protected] avec une préoccupation substantielle concernant son score reçoit une réponse réelle dans quelques jours ouvrables.
✓
Nous corrigerons publiquement nos erreurs. Si nous découvrons un bug dans l'algorithme, une erreur de source de données ou une lacune méthodologique, nous livrons un correctif et le documentons. Nous ne reclassons pas silencieusement.
✗
Nous ne partagerons pas le contenu des e-mails publiquement sans la permission de l'expéditeur, ni n'utiliserons les e-mails des opérateurs pour autre chose que la conversation de score qui les a produits.
✗
Nous ne partagerons pas nos plans futurs pour une modification d'algorithme avec certains opérateurs à l'avance — chaque version est mise en direct pour tout le monde simultanément.
Score final (comment les dimensions se combinent)
Les 12 dimensions notées se combinent en une composite brute (max 172). La composite brute est normalisée sur une échelle 0–100, puis une redistribution dynamique des poids est appliquée pour produire le score final affiché.
// 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)
La proximité de la limite est un signal d'affichage, non une déduction du score. Jusqu'à la v4.9, le score soustrayait également un forfait de 1–3 points des très grands fournisseurs, mais cela créait un double comptage — un fournisseur dépassant la limite génère déjà un taux de rendement réalisé inférieur à la médiane, que la dimension Taux de rendement ancrée à la médiane note une seule fois. La pénalité a donc été supprimée. Chaque fournisseur affiche désormais quelle portion de la limite FSP (2,5% de la puissance de vote totale en direct du contrat WNat) il remplit, comme signal neutre de délégation marginale : plus le pourcentage est proche de 100%, plus une nouvelle délégation est diluée.
Indicateur d'anomalie au niveau de l'affichage : un fournisseur dont le taux de récompense actuel dépasse de plus de trois écarts robustes (écart absolu médian, multiplié par ×1,4826) la médiane du réseau — et d'au moins 50% au-dessus — porte un badge Anomalie dans le tableau des fournisseurs. Le badge ne modifie pas le score ; la protection contre les anomalies du score lui-même plafonne séparément les taux au-dessus de 3× la médiane avant le calcul du score. Les augmentations de taux d'époque annualisées proviennent généralement d'une très faible puissance de vote et se normalisent au cours d'une époque.
Sources de données (chaque entrée est publique)
Contrats Flare, lus directement on-chain : l'ensemble des fournisseurs enregistrés (VoterRegistry), les liens entité → adresse de délégation et nodeID plus enregistrement de l'adresse de soumission/signature (EntityManager), la puissance de vote déléguée (WNat) et les frais de délégation (WNatDelegationFee). C'est ce qui rend la liste des fournisseurs indépendante d'un seul index : à l'epoch de récompense 420, la chaîne contenait 98 fournisseurs enregistrés contre 80 dans le listing tiers, et les 18 manquants étaient auparavant absents de ce site.
API publique Flaremetrics : taux de récompense, frais de délégation, pouvoir de vote, changement quotidien du pouvoir de vote, pouvoir de vote verrouillé (auto-cautionnement), nom du profil + logo + région, fspRewardRate.
Flare Systems Explorer (FSE) : précision FTSO (primaire + secondaire), drapeaux de statut V2 (ftso_scaling, ftso_fast_updates, fdc), liaison d'adresse d'entité, présence d'adresse de signature/soumission, inscription d'électeur, liaison de nodeID P-Chain, et le taux de récompense de délégation par entité (reward_rate_wnat). Le taux de récompense est volontairement sourcé de FSE ET Flaremetrics : ils publient le même chiffre dans des unités différentes (FSE décimal, Flaremetrics pourcentage — vérifiés identiques sur les 72 fournisseurs portant les deux, à cinq décimales), et FSE couvre 154 entités contre 80 de Flaremetrics. Une source seule laisse les fournisseurs sans taux sans faute de leur part.
Données de récompenses du protocole Flare Systems (FSP) : distribution de récompenses par époque par fournisseur, utilisée pour la dimension Conformité (compte les époques sans récompenses) et comme source faisant autorité pour les totaux de récompenses de délégation.
V2 RewardManager (événements claimType=3) : distribution MIRROR réclamée sur chaîne par nodeID validateur. Filtrée strictement sur le type 3 — pas de confusion avec VRM, délégation FTSO ou récompenses DIRECT. L'indexeur propre de FlareWatch expose ceux-ci pour la dimension Participation MIRROR.
JSON FSP Merkle (allocations claimType=3) : enregistrement publié canonique de qui doit recevoir MIRROR par époque (les mêmes données que l'outil de signature de Flare lit). Ajouté comme deuxième source faisant autorité le 2026-05-11 — détecte les validateurs dont MIRROR est alloué mais pas encore réclamé sur chaîne.
Snapshots historiques FlareWatch : les taux de récompense par époque alimentent le CV de Cohérence ; les observations de stake payé par validateur alimentent le bonus de surperformance MIRROR (avec la porte d'accumulation de données de 30 jours).
Ce qui ne figure PAS dans le score
• Auto-promotion ou placement payant. Aucun fournisseur ne peut payer ou parrainer un score plus élevé.
• Augmentations spécifiques au fournisseur codées à la main. Aucune ligne « X obtient +5 parce que nous l'aimons » nulle part dans le code. Le même algorithme s'applique à chaque fournisseur, y compris le fournisseur propre de FlareWatch, qui est noté par cette fonction exacte.
• Qualité subjective de l'infrastructure. Nous ne tentez pas d'évaluer les SLA de disponibilité, la distribution géographique ou les spécifications matérielles au-delà de ce que FSE et Flaremetrics exposent comme données publiques.
• Blocages ou engagements envers FlareWatch. Pas de notation favorable pour les jalonneurs utilisant FlareWatch par rapport à un autre outil.
• Signaux futurs pas encore connectés. La présence communautaire (réseaux sociaux vérifiés, participation à la gouvernance), l'historique de slashing, la latence de réponse et les lignes de tendance par époque sont prévus pour les versions futures mais ne sont pas dans v3 aujourd'hui. Aucun n'est pondéré secrètement.
Retour des opérateurs
Vous voyez quelque chose de mal dans le score de votre fournisseur ? Envoyez un e-mail à [email protected] avec votre adresse de délégation et votre préoccupation. Nous répondons à chaque opérateur. Les demandes courantes auxquelles nous agirons :
  • Corrections de classification MIRROR (attribution claimType=3 à vos nodeIDs).
  • Erreurs mathématiques spécifiques à la dimension avec les entrées que vous avez utilisées.
  • Corrections de nom / logo / profil via Flaremetrics ou FSE.
  • Critique générale de l'algorithme.
Sources et références
Chaque entrée du score provient de sources publiques et vérifiables de l'écosystème Flare. Quiconque peut vérifier nos affirmations par rapport à ces sources primaires et reproduire les mathématiques à partir de données brutes. Si vous repérez une discordance entre cette page et ce que les sources en amont indiquent, envoyez un e-mail à [email protected] et nous la corrigerons.
Documentation protocole faisant autorité. Couvre FTSO V2, FSP, validation P-Chain, FAssets et le reste de la pile Flare.
Portail de gouvernance Flare (FIP) ↗https://proposals.flare.network
Propositions d'amélioration Flare — la source de vérité pour les conditions minimales du protocole V2, la mécanique des frais et les changements d'économie de récompenses qui alimentent ce score.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Registre officiel opéré par Flare des fournisseurs de données FTSO, des adresses d'entités, des liaisons de nodeID P-Chain et des drapeaux de conditions minimales. Source primaire pour nos dimensions Précision, V2 et Participation.
Flaremetrics ↗https://flaremetrics.io
Fournisseur de métriques indépendant de l'écosystème Flare. Source des taux de récompense, des frais, du pouvoir de vote, du changement quotidien du pouvoir de vote, du pouvoir de vote verrouillé, des noms de profil + logos et de la métrique fspRewardRate.
Explorateur de blocs Flare ↗https://flare-explorer.flare.network
Navigateur en lecture seule de tous les états sur chaîne. Permet à quiconque de vérifier les événements RewardClaimed du V2 RewardManager (claimType=3 pour MIRROR), les transitions d'époque de récompense et le reste.
Dépôt reward-scripts de la Fondation Flare ↗https://github.com/flare-foundation/reward-scripts
JSON publié par époque de récompense par la Fondation Flare montrant les récompenses livrées par validateur. Entrée indirecte — alimente le calcul du bonus de surperformance MIRROR via l'indexeur d'observation par stake de FlareWatch.
API publique Flaremetrics (fournisseurs FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Le point de terminaison exact que notre cron consomme, renvoyant les profils d'entités, les taux de récompense, les frais et la puissance de vote. Quiconque peut l'appeler directement.
API publique Flaremetrics (enregistrements de nœuds) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Tableau de conversion Hex → cb58 NodeID. Nous paginons cela pour construire la recherche entité-à-NodeID qui alimente la dimension MIRROR Participation.
Aucune donnée privée, aucun modèle propriétaire. L'algorithme de notation est implémenté dans services/ftso/scoring.ts dans la base de code FlareWatch. Les opérateurs ou chercheurs qui souhaitent inspecter l'implémentation directement (plutôt que de lire la prose + les formules ci-dessus) — ou qui souhaitent le forker pour leur propre usage — peuvent envoyer un email à [email protected] pour demander l'accès. Nous publierons le fichier en tant que package open-source autonome s'il y a une réelle demande.
Comment les scores se mettent à jour
La notation des fournisseurs FTSO s'exécute comme une passe dans le cron à /api/cron/refresh-validators, qui recalcule le score de chaque fournisseur actif toutes les 5 minutes (la même exécution qui reclasse les validateurs P-Chain). Les entrées (Flaremetrics, FSE, récompenses FSP, événements V2 RewardManager) sont récupérées à neuf sur chaque exécution.
Le CV de cohérence utilise l'historique d'époque récent — la dimension peut se déplacer à mesure que la fenêtre glissante se décale. Les nouveaux fournisseurs ayant moins de 3 époques historiques reçoivent la note neutre de 10 jusqu'à ce que suffisamment de données s'accumulent.
La redistribution dynamique des poids est recalculée à chaque exécution en fonction de l'ensemble actuel des fournisseurs actifs. À mesure que les fournisseurs évoluent (par exemple, une vague de nouvelles mises à niveau V2), la dimension qui devient non-discriminante se décale ; la redistribution s'adapte automatiquement.
La version de l'algorithme est marquée dans l'en-tête de cette page. Lorsque nous livrons une nouvelle version, la chaîne de version ici change et la carte Versions ci-dessous documente ce qui a changé.
Versions
v4.8 (2026-08-20) — La Précision récompense désormais la bande de récompense DIFFICILE. Elle utilisait uniquement la bande secondaire FTSO (plus large), où presque chaque fournisseur sérieux arrive à 95–99% — donc la dimension était un 25/25 presque plat en haut du champ, proche de ne rien mesurer. La bande PRIMAIRE (IQR étroit) est l'ingénierie véritablement difficile et répartit les fournisseurs ~28–80%. Flare récompense ces bandes 40% primaire / 60% secondaire (FIP.11, en vigueur depuis 2024, avec augmentations supplémentaires de la bande secondaire signalées), donc la Précision reflète désormais cela : un mélange 40/60. La bande secondaire conserve sa courbe antérieure ; la bande primaire utilise une courbe absolue (28% → 0, 78% → 25 complet), fixée pour que le score reste redérivable à partir des entrées propres d'un fournisseur. Avant/après complet sur les 100 fournisseurs notés, archivé avant envoi : la réorganisation suit la force de la bande primaire — les fournisseurs qui font le travail difficile de bande étroite augmentent, les fournisseurs qui se reposent sur un numéro secondaire facile chutent. La même règle s'applique à notre propre fournisseur, qui a une bande primaire faible aujourd'hui : il chute de 84 à 77 et tombe de plusieurs places. Envoyé quand même — un score qui récompense l'ingénierie réelle, même celle d'un concurrent et même à nos dépens, est le seul type qui vaille la peine d'être publié.
v4.7 (2026-07-31) — La liste des fournisseurs a cessé de dépendre d'un seul index, et le score a cessé de pénaliser nos propres lacunes de données. (1) La liste est maintenant construite à partir de l'ensemble d'électeurs enregistrés on-chain et complétée là où l'index tiers manque d'entités : 98 fournisseurs contre les 80 précédemment affichés, donc 18 vrais fournisseurs qui étaient introuvables et non-délégables d'ici apparaissent maintenant. (2) « Actif » signifiait « dispose d'un taux de récompense de cet index », ce qui mettait à zéro les dimensions Frais (15) et V2 (15) pour chaque fournisseur complété même quand nos propres données FSP montraient qu'ils versaient à chaque époque ; il accepte maintenant des preuves de distribution. (3) Un taux de récompense manquant ne marque plus 0 contre le dénominateur complet — le poids de 25 points quitte le dénominateur à la place, donc un fournisseur est noté sur ce que nous avons mesuré plutôt que facturé pour ce que nous ne pouvions pas. (4) La dimension Frais était toujours notée sur la courbe pré-FIP-16, où un frais de 0 % gagnait le score maximal. FIP-16 établit 20 % comme frais d'entité légal minimum et chacun des 98 fournisseurs facture exactement cela, donc la dimension attribuait 4,00/15 à tout le domaine sans variance — 11 points que personne ne pouvait gagner, valant environ 4,3 points de chaque score publié incluant le plus haut. Les Frais sont maintenant ancrés à max(frais le plus bas observé, plancher du protocole), de la même manière que la page de validateur l'a ancré depuis le fork Granite : facturer le minimum légal gagne le score maximal, et seuls les frais AU-DESSUS sont pénalisés, par distance. Cela élève chaque score d'un montant similaire et ne change pas le classement. Les fournisseurs avec un taux publié ne sont pas affectés par les changements (1) à (3). Aucun taux de récompense n'est estimé ou déduit : ces lignes affichent « Aucune donnée ». (5) Le taux de récompense ne dépend plus d'un seul index. Il était lu de Flaremetrics seul, donc un fournisseur que cet index a cessé de couvrir a perdu son APR Net et Brut et a marqué 0/25 sur Taux de récompense — une pénalité de 25 points pour la lacune de couverture de quelqu'un d'autre. Flare Systems Explorer publie le même nombre et couvre plus d'entités, donc il remplit maintenant tout vide ; un taux Flaremetrics en direct n'est jamais écrasé. Le jour où cela a été déployé, il a restauré un taux publié à 15 fournisseurs qui n'en avaient pas.
v4.6 (2026-07-01) — Cohérence désbiaisée pour les nouveaux nœuds. C'était la moyenne/l'écart-type du taux de récompense sur l'historique complet de 30 époques, donc la première époque de ramp gonflée d'un nouveau nœud (petit poids de vote → taux élevé par unité, qui se normalise ensuite) agissait comme une valeur aberrante qui fixait le CV haut — notation de 0 — pendant des mois jusqu'à ce qu'il vieillit. Maintenant, il utilise une fenêtre glissante (12 dernières époques rémunérées) et une dispersion robuste médiane/MAD, de sorte que l'époque de ramp est une valeur aberrante inoffensive tandis que la volatilité continue génuine reçoit toujours une notation basse.
v4.5 (2026-06-30) — Auto-obligation rendue neutre en taille. La courbe basée sur le ratio seul pouvait noter une grande auto-obligation absolue à un ratio bas SOUS une petite auto-obligation à un ratio élevé. L'Auto-obligation crédite désormais le plus grand d'un ratio d'alignement ou d'un montant absolu saturant (plafonné à 5M FLR), de sorte qu'un grand opérateur engagé et un petit entièrement aligné gagnent tous les deux des points complets — cela récompense l'engagement, pas la richesse, et la qualité du validateur reste dans les autres dimensions.
v4.4 (2026-06-30) — Deux vrais correctifs de bugs. (1) L'Auto-obligation était une dimension MORTE : elle lisait un champ Flaremetrics que l'API avait supprimé, donc chaque fournisseur a obtenu un score de 0/7. Réapprovisionnée à partir de la véritable auto-obligation P-Chain de l'opérateur (référencée croisée à partir de l'ensemble de validateurs par nodeID). (2) La Conformité avait cessé de pénaliser les époques avant qu'un fournisseur ne soit actif — un nouveau nœud gagnant proprement depuis son lancement était auparavant imputé pour chaque époque qui le précédait, le maintenant à 0/10 pendant des semaines. Les époques manquées sont maintenant comptées uniquement dans la fenêtre active de chaque fournisseur.
v4.3 (2026-06-03) — Clarification méthodologique, aucun changement mathématique de notation. La dimension Accuracy est maintenant explicitement définie comme le taux d'atterrissage de bande secondaire sur chaîne (QUALITÉ de prix — quelle fraction des prix soumis atterrissent dans la bande acceptée), distinct de la dimension Conformité, qui compte les périodes de récompense manquées (PARTICIPATION FSP). Cette page et les info-bulles du tableau des validateurs ont été réécrites pour rendre la distinction explicite, et une colonne Conformité a été ajoutée à côté d'Accuracy. Les deux dimensions conservent leurs poids antérieurs (25 et 10) et leurs entrées (fseAccuracySecondary et epochsWithoutRewards).
v4.2 (2026-05-20) — Dimension Rewards Distributed réparée. Elle était câblée à un champ de distribution de récompenses Flaremetrics que l'API v3 du fournisseur a supprimé, donc la dimension lisait 0 pour chaque fournisseur et ne contribuait rien. Recâblée aux totaux de récompenses de délégation FSP sur chaîne — les mêmes données de réclamation de récompenses que la dimension Conformité agrège déjà — donc la dimension différencie à nouveau.
v4.1 (2026-05-20) — Dimension Conformité limitée. epochsWithoutRewards pouvait arriver négatif car le cron des récompenses FSP accumulait son compte de présence d'époque au-delà de la fenêtre glissante, ce qui permettait à la Conformité de dépasser son plafond de 10 points (observé jusqu'à ~58) et poussait le composite au-delà de son maximum — saturant environ 70% des fournisseurs à un 100 plat. La Conformité est maintenant limitée à son poids, et le cron FSP recalcule les résumés de récompenses sans état par fenêtre afin que le compte ne puisse plus dériver.
v4.0 (2026-05-11) — Passe complète d'audit d'équité équivalente à la sortie v4.0 du score validateur. Deux vrais bugs corrigés : (1) Delegator Count avait une incitation perverse à 500 — avant la correction, le seau de 500 délégants renvoyait 14 pts mais le plafond >500 renvoyait le WEIGHT_DELEGATORS sous-jacent (12), donc gagner un délégant à travers cette limite PERDAIT 2 points. Maintenant à l'échelle logarithmique de 5 → 500, monotone vers le haut. (2) Les niveaux V2 Participation étaient effondrés — l'enregistrement V1 partiel et la V2 complète (Scaling + FastUpdates + FDC) renvoyaient tous les deux 15, donc passer de V1 partiel à V2 complet n'offrait zéro amélioration de score. Maintenant par empilement de protocole (actif +3, V1 +4, chaque protocole V2 +~2.67). Falaises de limite éliminées en Accuracy (avait une falaise de 7 pts à 97%), Stability et Self-Bond Ratio — tous linéarisés avec les valeurs conservées aux limites des sceaux. Courbe Reward Rate rééquilibrée pour que la médiane = moitié des points de la dimension (était 40%). Réconciliés les docstrings de dimension obsolètes avec les valeurs de poids réelles. Effet net : chaque dimension est monotone vers le haut sur l'axe d'entrée, et aucun fournisseur ne peut réduire son score FlareWatch en améliorant une métrique opérationnelle réelle.
v3 (2026-05-09 → 2026-05-11) — Notation de 13 dimensions avec redistribution dynamique des poids et pénalité de dilution de puissance de vote. MIRROR Participation introduit comme dimension de première classe (12 de base + jusqu'à +3 bonus de surperformance avec rétrécissement bayésien et porte d'accumulation de données de 30 jours). Identity et Self-Bond ajoutés comme dimensions discrètes. Reward Rate déplacé vers median-anchored. Accuracy utilise la métrique secondaire FSE pour la bande haute résolution. Consistency utilise CV sur les périodes récentes.
v2 et antérieures — Les versions antérieures à v3 ne sont pas documentées ici ; elles utilisaient un sous-ensemble plus simple de dimensions et précédaient la redistribution dynamique des poids. Versions supprimées au profit du modèle actuel.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.