Metodología de Puntuación de Proveedor FTSO

Versión de algoritmo: v4.11 · Última actualización: 2026-07-04

FlareWatch asigna a cada proveedor de datos FTSO una puntuación compuesta de 0–100 en 12 dimensiones puntuadas. La matemática es determinista, los datos de entrada son públicos en blockchain y datos del ecosistema Flare[Flaremetrics] [FSE] [Flare Explorer], y el mismo algoritmo se aplica a cada proveedor — incluyendo el proveedor FTSO de FlareWatch, que se puntúa por esta función exacta sin trato especial. Esta página documenta cada dimensión y umbral para que delegadores y operadores puedan ver exactamente cómo se calcula la puntuación y por qué se eligió cada valor. Cada afirmación aquí se vincula a su fuente primaria upstream — ver Fuentes y referencias en la parte inferior.

Alcance: esta página documenta la puntuación del proveedor FTSO — lo que ves en modo delegación en la página de validadores (delegando WFLR a proveedores de datos FTSO para la cuota de inflación FTSO). La puntuación del validador mostrada en modo staking (delegando FLR a un validador P-Chain para recompensas VRM + MIRROR) utiliza un algoritmo separado de 9 dimensiones enfocado en operaciones de validadores — tiempo de actividad, comisión, confiabilidad, etc. Son roles distintos en cadena con recompensas distintas, puntuados por separado. Consulta Metodología de Puntuación de Validador para el lado del staking.
Cobertura de cadena FLR / SGB: la pestaña Delegación en la página de validadores tiene un botón de alternancia FLR / SGB para carteras que tengan cualquier Songbird (SGB). Esta metodología documenta solo la puntuación del lado FLR. Los proveedores FTSO de Songbird se enumeran sin una puntuación compuesta — los mismos datos de precisión / consistencia / recompensas FSP que usamos para FLR aún no están integrados en nuestro pipeline de Songbird (Flaremetrics, nuestra fuente de datos FLR principal, no cubre Songbird). Lo que ven hoy los delegadores de SGB: nombre del proveedor + logo del registro de TowoLabs entre redes, peso actual (WSGB delegado, leído directamente del contrato WNat de Songbird a través de nuestro propio RPC de Songbird), y la URL del proveedor. Ordena por peso; un peso mayor es la señal proxy hasta que lleguen los datos de precisión. Cuando integremos el pipeline de precisión + tasa de recompensa del lado Songbird, se aplicará la misma fórmula de 13 dimensiones a proveedores SGB — no hay nuevo algoritmo de puntuación, solo la fórmula FLR calculada contra datos de Songbird. La puntuación de validador de FlareWatch (pestaña staking) no tiene equivalente en SGB en absoluto: el conjunto de validadores P-Chain de Songbird está restringido a entidades aprobadas por la Fundación Flare, por lo que la delegación P-Chain de SGB minorista es rara y la pestaña staking se mantiene solo para FLR.
Bandas de puntuación
90+Nivel superior — top ~10–20% de proveedores FTSO. Perfil típico: tasa de recompensa por encima de la mediana, alta precisión, participación completa en el protocolo V2 (FTSO Scaling + Fast Updates + FDC), comisión baja/cero, gran base de delegadores, nodos validadores que pagan MIRROR, marca nombrada. No se requiere una sola dimensión — los proveedores alcanzan el nivel superior acumulando fortaleza en la mayoría de categorías.
80–89Fuerte — cumple con la mayoría de puntos de referencia clave; una o dos dimensiones por debajo del nivel superior.
70–79Bueno — cumple con todos los criterios de línea base; sin brechas principales.
60–69Aceptable — utilizable pero no diferenciado.
<60Por debajo de la mediana — brechas significativas en una o más dimensiones. Un hecho matemático, no un juicio de calidad.
Dimensiones (pesos raw — suman 172, normalizados a 100)
"Activo" condiciona dos dimensiones (Comisión y Participación V2): un proveedor que no está en funcionamiento no debe acumular crédito por anunciar una comisión baja. Un proveedor se cuenta como activo si tiene una tasa de recompensa publicada o si los datos de recompensa del Protocolo de Sistemas Flare muestran que realizó pagos en al menos una época de la ventana de calificación. Hasta 2026-07-31 era solo la tasa de recompensa, que provenía de una única API de terceros — así que un proveedor que esa API no cubriera puntuaba cero en ambas dimensiones mientras distribuía recompensas visiblemente cada época. La actividad es una propiedad del proveedor, no de quién resulte listarlo.
Tasa de Recompensa25 pts máx
Qué: La tasa de recompensa del proveedor por época, anclada a la mediana de la red.
Cómo: ratio = providerRate / medianRate. Lineal: ratio 1.0 (mediana) → 12.5 pts, ratio 2.0 → 25 pts (límite). Proveedor inactivo (rewardRate ≤ 0) → 0. v4.0 (2026-05-11): límite rebasado para que la mediana = la mitad de los puntos de la dimensión (no 40% como antes).
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).
Por qué: La tasa de recompensa es lo #1 que experimentan los delegadores. El anclaje a la mediana mantiene la puntuación honesta a medida que cambia la economía de recompensas de la red — un proveedor con 1.2× la mediana en una era de recompensas bajas se clasifica igual que uno con 1.2× en una era de recompensas altas. Los límites y filtros de anomalías evitan que valores atípicos de una sola época dominen.
Precisión25 pts máx
Qué: Precisión de precio FTSO de Flare Systems Explorer (FSE) — tasas de aterrizaje de bandas de recompensa primaria (IQR cerrada) y secundaria (más amplia).
Cómo: Una mezcla 40/60 de las tasas de aterrizaje de bandas de recompensa FTSO PRIMARIA (IQR cerrada) y SECUNDARIA (más amplia) (v4.8), reflejando la propia división de recompensa de Flare — FIP.11 paga recompensas de feed anclado 40% primaria / 60% secundaria. La secundaria usa la curva por tramos anterior (97% → 25 … 70% → 2); está casi saturada en todo el campo (95–99%), por lo que apenas diferencia. La primaria usa una curva lineal absoluta — 28% → 0 hasta 78% → completos 25 — así que la ingeniería de banda cerrada mucho más difícil, donde los proveedores realmente se extienden desde ~28% a ~80%, es lo que separa el campo. Anclajes fijos (no percentiles del campo), por lo que la puntuación permanece re-derivable a partir de las propias entradas del proveedor. Fallback de banda única cuando solo una está disponible; neutral 12.5 cuando no hay datos de 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
Por qué: Épocas perdidas = ingreso de recompensa perdido para delegadores. La precisión es lo que determina si los envíos del proveedor realmente cuentan para el consenso FTSO, y la métrica secundaria (que pondera más épocas recientes) es la que se mapea más limpiamente al desempeño actual.
Consistencia20 pts máx
Qué: Qué tan estable ha sido la tasa de recompensa del proveedor en sus épocas de ganancia más recientes.
Cómo: Volatilidad a la baja en los épocas de ganancia más recientes de un proveedor, medida solo entre épocas genuinamente consecutivas — una época en la que un proveedor no ganó nada no deja registro, y las dos épocas a cada lado de esa brecha nunca se comparan entre sí. Solo las CAÍDAS época a época cuentan — un aumento contribuye cero — por lo que una tasa estable o creciente obtiene una puntuación cercana al máximo y una recuperación eleva la puntuación conforme ocurre. Las caídas se agregan con RMS, por lo que una caída fuerte pesa más que una leve, y se ponderan hacia pares recientes (decay 0.8) para que una recuperación activa eleve la puntuación mientras que las caídas antiguas quedan obsoletas. cv = 0 → 20 pts; cv ≥ ~0.167 → 0. Neutral 10 cuando hay menos de 3 pares de épocas consecutivas en los últimos 12 épocas de ganancia.
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)
Por qué: Dos proveedores con la misma tasa de recompensa promedio pueden entregar experiencias muy distintas para los stakers: uno que cae fuertemente es peor que uno que se mantiene estable o sube. La consistencia recompensa lo que un delegador realmente desea — una tasa estable o en alza — y solo penaliza descensos, en proporción a su magnitud. Una tasa que SUBE nuevamente nunca se castiga (la medida simétrica anterior sí lo hacía, lo cual era contraproducente). Un descenso fuerte reciente obtiene baja puntuación y luego se recupera conforme envejece.
Participación en V215 pts máx
Qué: Si el proveedor está ejecutando el stack V2 moderno (FTSO Scaling + Fast Updates + FDC).
Cómo: Apilamiento por protocolo. Línea base activa (rewardRate > 0) +3, V1 parcial (envío + firma + votante) +4, cada protocolo V2 (FTSO Scaling / Fast Updates / FDC) +~2.67 cada uno, límite 15. Inactivo → 0. v4.0 (2026-05-11) dividió el nivel anterior de todo o nada (donde V1 parcial = V2 completo = 15 — sin incentivo para actualizar) en bonificaciones por protocolo que se apilan.
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)
Por qué: V2 es hacia dónde se dirige la red. El apilamiento por protocolo de v4.0 significa que actualizar de V1 parcial a V2 completo realmente mueve la puntuación (pre-corrección no lo hizo — V1 parcial y V2 completo ambos devolvían 15). Agregar cualquier protocolo V2 único ahora mejora la dimensión.
Comisión15 pts máx
Qué: La comisión que cobra el proveedor sobre las recompensas delegadas.
Cómo: Interpolación lineal en puntos de quiebre: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. Proveedor inactivo → 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
Por qué: La comisión reduce directamente lo que reciben los delegadores. La interpolación lineal (en lugar de cubetas) significa que una comisión del 7% puntúa entre 10% y 15% en lugar de hacer chasquidos a una cubeta — los operadores no reciben crédito por redondear su comisión hacia el límite de la siguiente cubeta.
Participación en MIRROR12 (+3 bonificación) pts máx
Qué: Si los nodos validadores P-Chain del operador pagan activamente la cuota de inflación FTSO a stakers, más una bonificación de desempeño superior.
Cómo: La puntuación base se escala linealmente con la fracción de nodeIDs del operador que pagan recompensas MIRROR. Todos los nodos activos → 12 pts. Parcial → proporcional. Ninguno → 0. A partir del 2026-05-11, la señal 'active' se lee de dos fuentes canónicas: eventos RewardClaimed(claimType=3) en cadena en V2 RewardManager Y asignaciones claimType=3 en el JSON Merkle oficial de FSP — cualquiera es suficiente. Antes de la actualización usábamos el flujo en cadena como la única señal, lo que producía falsos negativos para proveedores cuyo MIRROR se liquida a través de una ruta de reclamación no estándar. Más un bono de sobredesempeño de hasta +3 pts cuando los validadores del operador entregan consistentemente más del 100% del esperado (vrm + mirror) / esperado — contracción bayesiana con una puerta de acumulación de datos de 30 días y un mínimo de muestra de 3 stakes mantiene a operadores pequeños o nuevos de jugar el bono en algunas pocas lecturas afortunadas.
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
Por qué: La participación en MIRROR es lo que delega la parte de inflación de FTSO a tus stakers. Un proveedor activo en V2 cuyos nodos validadores no paguen MIRROR está enviando ~5–15% menos rendimiento a los delegadores que el mismo proveedor con nodos activos. El bono de sobredesempeño recompensa la entrega consistentemente mejor de lo esperado sin inflar operadores nuevos en muestras pequeñas — la contracción bayesiana y la puerta de acumulación de 30 días lo mantienen justo.
Recuento de Delegadores12 pts máx
Qué: Número de billeteras distintas que actualmente delegan a este proveedor, contadas desde el estado de la cadena.
Cómo: Escala logarítmica de 5 → 500 delegadores mapeados a 0 → 12. ≤5 → 0, ≥500 → 12 (límite). Coincide con el estilo de señal de recuento de la dimensión Trust del validador. v4.0 (2026-05-11): se corrigió un error real donde el esquema de depósito anterior tenía un incentivo perverso en exactamente 500 delegadores (pre-corrección: 500 → 14, 501 → 12 — ganar un delegador en esa frontera PERDÍA 2 puntos).
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
Por qué: El recuento de delegadores es una señal de confianza — independiente del tamaño del stake. Un proveedor con 200 delegadores ha sido elegido por 200 stakers independientes; uno con 5 ha sido elegido por casi su operador. La escala logarítmica proporciona retornos decrecientes después de ~50 delegadores sin nunca invertirse (la forma en que lo hacía la puntuación por depósito pre-v4.0).
Participación en Épocas10 pts máx
Qué: Si el proveedor está participando activamente en épocas.
Cómo: FSE marca el proveedor activo → 10. El proveedor tiene rewardRate > 0 (Flaremetrics) pero sin bandera activa FSE → 7 (activo según datos de mercado, confirmación FSE faltante). De lo contrario → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Por qué: Detecta proveedores cuyo flujo de recompensas se ha estancado incluso si Flaremetrics aún los enumera. Diferente de Precisión (que se trata de la corrección por época) — Participación es sobre presentarse en absoluto.
Estabilidad del Poder de Voto10 pts máx
Qué: Cambio porcentual día a día en el poder de voto del proveedor.
Cómo: Lineal por partes en cambio porcentual día a día absoluto. <1% → 10. Lineal de 1% → 3% (10 → 7). Lineal de 3% → 5% (7 → 4). Lineal de 5% → 10% (4 → 2). Continúa hacia 0 pasado el 10%. v4.0 (2026-05-11): linealizó los acantilados de depósito anteriores (eran hasta acantilados de 3 puntos en cada umbral).
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)
Por qué: Los grandes cambios día a día en el poder de voto a menudo indican una ola de delegador moviéndose dentro o fuera — los stakers que leen la tabla ven un objetivo en movimiento. Un poder de voto estable señala un proveedor establecido con delegadores pegajosos.
Cumplimiento10 pts máx
Qué: Si el proveedor fue pagado en cada época de recompensa DESDE que se activó en los datos de recompensas FSP.
Cómo: 10 puntos completos por cero épocas perdidas dentro de la ventana activa del proveedor. Cada época perdida deduce 3 pts (limitado a 0). Neutral 5 cuando no hay datos FSP disponibles. v4.4 (2026-06-30): las épocas perdidas ahora se cuentan solo desde la primera época participante del proveedor en adelante — un proveedor nuevo ya no es cobrado por épocas antes de que existiera (lo que previamente mantenía nodos nuevos-pero-limpios a 0/10 durante semanas).
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)
Por qué: Una época perdida en la distribución oficial de recompensas del Protocolo de Sistemas Flare significa que el proveedor no cumplió con el cumplimiento del protocolo para esa época — condiciones mínimas, política de firma, etc. Contar solo desde la primera participación mantiene la medida justa para proveedores nuevos mientras aún penaliza omisiones genuinas. Tres puntos por omisión es pronunciado, así que una omisión única es una señal notable pero recuperable; ~3 omisiones anulan la dimensión.
Identidad8 pts máx
Qué: Si el proveedor tiene un nombre de marca real o solo una dirección hex.
Cómo: Marca nombrada (≥4 caracteres, no comienza con 0x) → 8. Corta o anónima (<4 caracteres) → 4. Dirección hex pura / 0x como nombre → 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
Por qué: Un proveedor nombrado ha elegido ser localizable y responsable — pueden ser buscados, contactados y obligados a cumplir los compromisos publicados. Los proveedores anónimos por dirección son funcionales pero ofrecen menos señales de confianza a los delegadores que los evalúan.
Auto-Garantía7 pts máx
Qué: El bono de nodo P-Chain PROPIO del operador (skin in the game) — excluyendo stake que otros delegan al nodo. Una puerta de compromiso neutral en tamaño, no una clasificación de riqueza.
Cómo: Acreditado en el MAYOR de dos ejes saturantes: (1) alineación — bono propio como parte del stake total comprometido (≥10% → completo); o (2) absoluto — capital propio en riesgo, limitado a 5M FLR para que 5M y 80M puntúen igual. v4.4 (2026-06-30): re-originado del verdadero auto-bono P-Chain del operador (peso del validador referenciado cruzado por nodeID) — el campo Flaremetrics anterior que leía fue discontinuado, así que cada proveedor había puntuado 0. v4.5 (2026-06-30): agregó el eje absoluto + saturación para que un auto-bono grande a una proporción baja no puntúe por debajo de uno pequeño a una proporción alta, sin dejar que el tamaño gane o penalice operadores pequeños.
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)
Por qué: Skin in the game — un operador con su propio capital en riesgo está alineado con los delegadores. Pero el tamaño del auto-bono no es un proxy para la CALIDAD del operador (eso vive en las otras dimensiones), así que un operador pequeño completamente alineado y uno grande comprometido ambos obtienen puntuación completa. Solo un operador con poco de su propio capital comprometido — pequeña parte Y cantidad pequeña — puntúa por debajo del máximo.
Cómo puntuar 100/100 — un manual de FTSO para proveedores
La auditoría de equidad v4.0 fue específicamente diseñada para que maximizar cada dimensión de puntuación genuinamente te convierta en un mejor proveedor FTSO para tus delegadores. Mejorar tu puntuación no es jugar el sistema — es el sistema funcionando como se diseñó. Aquí está el manual por dimensión.
Tasa de Recompensa — 25 pts. Entregar ≥ 2× la tasa de recompensa FSP de la mediana de la red por época (después de tarifa, post-distribución de protocolo). Lineal de 0 a 2× mediana: mediana → 12.5, 2× mediana → 25. Por qué esto se alinea: esta es la cantidad en dólares realmente llegando a tus delegadores por época.
Precisión — 25 pts. Apunta a ≥97% de tasa de aterrizaje en banda secundaria en FSE para puntos completos. Lineal por partes, así que 95% → 18, 93% → 16, 90% → 13, etc. — cada mejora del 1% mueve la puntuación. Esta es la CALIDAD de precios, no la participación en épocas: mide qué fracción de precios enviados aterrizan dentro de la banda aceptada en cadena. Un proveedor con alta Precisión publica precios cercanos al consenso; uno con baja Precisión envía de manera confiable pero está fuera de consenso más a menudo. Por qué esto se alinea: los envíos fuera de banda producen recompensas de delegador más pequeñas incluso cuando el proveedor participa en cada época. La dimensión de Cumplimiento separada a continuación rastrea la participación en épocas.
Consistencia — 20 pts. Minimizar la varianza de tasa de recompensa por época (CV = desv.est/media en épocas recientes). CV = 0 → 20, CV = 0.2+ → 0. Por qué esto se alinea: dos proveedores con la misma tasa de recompensa media no son equivalentes — pagos predecibles vencen volátiles para UX de staker.
Participación V2 — 15 pts. Protocolos de pila adicionalmente: línea base activa + registro parcial V1 + cada protocolo V2 (Scaling, FastUpdates, FDC). V2 completo + activo + V1 registrado = 15. Por qué esto se alinea: V2 es hacia dónde va la red; cada protocolo adicional que adoptes es una inversión futura de la que se benefician tus delegadores.
Tarifa — 15 pts. Cobrar ≤ 5% por 13 pts, 0% por 15. Rampa lineal por partes a través de puntos de ruptura de 5%/10%/15%/20%/25% a 0. Por qué esto se alinea: tarifa más baja = más recompensa llega a tus delegadores directamente.
Participación MIRROR — 12 + hasta 3 bonificación. Ejecuta todos los nodos validadores P-Chain de tu operador como activos MIRROR (ya sea a través de eventos RewardClaimed en cadena O asignaciones Merkle JSON FSP — fuente dual v3.6). Sobredesempeño sostenido (relación mediana (vrm+mirror)/esperado por encima de 1.05) en ≥3 stakes pagados después de 30 días de observación gana hasta +3 bonificación. Por qué esto se alinea: MIRROR es la parte de tus delegadores de la inflación FTSO; los nodos que no pagan MIRROR envían ~5-15% menos rendimiento a los stakers.
Recuento de Delegadores — 12 pts. Escala logarítmica 5 → 500 delegadores mapeados a 0 → 12. Construye una base de stakers independientes, no solo algunos ballenas. Por qué esto se alinea: el recuento es una señal de confianza independiente del tamaño del stake; 200 delegadores eligiéndote significa 200 respaldos independientes.
Participación en Épocas — 10 pts. Presentarse en cada época con tasa de recompensa positiva y bandera FSE activa. Por qué esto se alinea: detecta flujos de recompensas estancados que las dimensiones por época podrían perder.
Estabilidad — 10 pts. Mantén el cambio de poder de voto día a día por debajo del 1%. Rampa lineal por tramos a partir de ahí. Por qué se alinea: el poder de voto estable señala delegadores asentados (comunidad pegajosa) en lugar de olas de ballenas transitorias.
Cumplimiento — 10 pts. Cero épocas de recompensa perdidas en los datos FSP. Cada pérdida cuesta 3 pts; ~3 pérdidas anulan la dimensión. Esto es PARTICIPACIÓN, no calidad de precio: cuenta épocas donde el proveedor fue penalizado por faltar condiciones mínimas, política de firma u otros requisitos del protocolo — distinto de la dimensión Precisión anterior que califica el aterrizaje de precio en banda. Por qué se alinea: una época perdida en la propia distribución de recompensas del protocolo significa que el proveedor incumplió condiciones mínimas y los delegadores no ganaron nada esa época. Un proveedor puede tener excelente Precisión en épocas participadas y aún así perder épocas completas.
Identidad — 8 pts. Registra un nombre de marca real (≥4 caracteres, no una dirección hex) en Flaremetrics o FSE. Proveedores anónimos por dirección puntúan 0; proveedores nombrados puntúan 8. Por qué se alinea: los proveedores nombrados son localizables y responsables; esa es la señal de confianza básica.
Auto-Garantía — 7 pts. Compromete tu propio bono de nodo P-Chain (no stake que otros deleguen para ti). Puntuación completa PARA UNO una porción significativa de tu stake total (≥10%) O una cantidad absoluta significativa (el eje absoluto se satura en 5M FLR, así que un operador grande no puede superar a uno pequeño en tamaño). Por qué se alinea: dinero en juego — operadores con su propio capital en riesgo comparten los resultados de rendimiento de sus delegadores. Es una puerta de compromiso neutral al tamaño, no una clasificación de riqueza: un operador pequeño totalmente alineado y uno grande comprometido ambos lo maximizan, y tu calidad operacional se juzga por las otras dimensiones.
Señales con compuerta de tiempo que no puedes atajar: La Consistencia necesita ≥3 épocas de historial. El bono de sobredesempeño MIRROR necesita 30 días de observación más ≥3 muestras de stake pagadas. El Cumplimiento necesita datos FSP abarcando suficientes épocas para contar. Construye un historial; la puntuación seguirá.
La puntuación bruta suma un máximo de 172 en las 12 dimensiones puntuadas y luego se normaliza a 100. Un rendimiento perfecto en los datos resulta en 172/172 → 100 mostrado. Se aplica una penalización por dilución de poder de voto de hasta −3 pts para proveedores muy grandes (>1.34B VP) como desempate.
Cómo verificar tu propia puntuación
Cada puntuación en la tabla de proveedores es reproducible a partir de datos públicos. Si eres operador y la matemática aquí no coincide con la puntuación que ves, lo correcto es verificarla tú mismo antes de asumir que cometimos un error. Paso a paso:
  1. Busca las estadísticas públicas de tu proveedor en flaremetrics.io (busca por nombre o pega tu dirección de delegación). Anota tu fspRewardRate, delegationFeePercentage, wNatWeight, y votePowerDailyChangePct.
  2. Verifica tu FTSO V2 + precisión en flare-systems-explorer.flare.network. Encuentra tu entidad. Revisa providersuccessrate.secondary para precisión, más los flags entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc para estado V2.
  3. Revisa tu participación MIRROR en el contrato V2 RewardManager a través de flare-explorer.flare.network. Busca eventos RewardClaimed con claimType=3 referenciando tus nodeIDs. Si no hay ninguno reciente para ninguno de tus nodos, aparecerás como MIRROR-inactivo en la puntuación.
  4. Introduce tus valores en las fórmulas arriba. El bloque de código de cada dimensión te dice exactamente qué aritmética ejecutar. Suma las dimensiones, divide por 172 (máximo raw), multiplica por 100, y tienes tu puntuación compuesta raw.
  5. Aplica la penalización de dilución si eres grande. Poder de voto por encima de 1.34B es −3, por encima de 1B es −1. La tarjeta de Puntuación Final abajo tiene los umbrales exactos.
  6. Compara con tu puntuación mostrada. La puntuación mostrada también refleja redistribución de peso dinámico — cuando la mayoría de proveedores se agrupan en una dimensión (desviación estándar baja en el conjunto activo), el peso de esa dimensión se redistribuye a dimensiones donde la dispersión es más amplia. El panel de desglose de puntuación en cada fila de proveedor muestra los valores actuales por dimensión.
  7. Si la matemática no suma, envía un correo a [email protected] con tu dirección de delegación, los inputs que usaste, y la puntuación que calculaste. Responderemos, y si cometimos un error la corregiremos públicamente.
Preocupaciones comunes del operador
Mi tasa de recompensa está por encima de la mediana pero mi puntuación de Tasa de Recompensa no es 25/25 — ¿por qué?
La Tasa de Recompensa es lineal en ratio-a-mediana: puntuación = ratio × 12.5, así que 1.0× mediana = 12.5/25 y necesitas un ratio de 2.0× para alcanzar el límite. Un proveedor en 1.2× la mediana puntúa 15, en 1.5× puntúa ~18.8, en 2.0× puntúa los 25 completos. El límite (más el filtro de anomalía 3×-mediana) existe para que una única época de recompensa anómalamente alta no domine la dimensión; si tu tasa es consistentemente en el decil superior, la puntuación aún la recompensa fuertemente.
Acabo de actualizar a V2 — ¿cuándo se actualiza mi puntuación V2?
El estado V2 viene de los flags entityminimalconditionslatest de FSE (ftso_scaling, ftso_fast_updates, fdc). Desde v4.0 la dimensión se apila por protocolo: línea de base activa +3, registro V1 (submit + signing + voter) +4, y cada protocolo V2 +~2.67. Entonces un proveedor registrado como voter con direcciones submit + signing pero ninguno de los tres protocolos V2 puntúa 7/15, y cada protocolo V2 individual que enciendas mueve la puntuación — los tres en vivo obtienen los 15 completos. Los cambios llegan en la siguiente ejecución cron de FlareWatch (cada 5 minutos) después de que FSE las refleje.
Mi precisión en FSE es 96% pero estoy puntuando más bajo de lo esperado.
La dimensión Precisión usa la métrica de precisión secundaria de FSE (resolución más alta en la banda 94–97% donde se agrupan la mayoría de proveedores). 95–96% se mapea a 18 pts; necesitas ≥97% para los 25 completos. Los buckets son ajustados en la parte superior porque unos pocos décimos de porcentaje en la banda 95–97% representan verdadera separación de desempeño entre proveedores.
Entrego MIRROR — ¿por qué FlareWatch me muestra como MIRROR-inactivo en mi puntuación de proveedor?
A partir de 2026-05-11, la participación MIRROR se detecta de DOS fuentes: eventos on-chain RewardClaimed(claimType=3) en RewardManager V2, Y asignaciones claimType=3 en el JSON Merkle FSP oficial. Un nodeID que aparezca en cualquiera de las fuentes cuenta como activo. Para operadores multi-nodo la puntuación usa la fracción de tus nodos que están activos (1/3 activo = 4/12 base, etc.). Si un nodo debería clasificarse como activo pero no aparece después del siguiente ciclo de barrido, envíanos un correo con el nodeID y la época específica que esperarías ver — verificaremos ambas fuentes.
Mi poder de voto se movió 8% ayer — ¿por qué la puntuación de Estabilidad es ~2.8/10?
La Estabilidad del Poder de Voto es lineal por tramos en cambio absoluto día a día (linealizada en v4.0 — sin acantilados de buckets): <1% → 10, rampa 1→3% bajando a 7, 3→5% bajando a 4, 5→10% bajando a 2, luego hacia 0 pasado 10%. Un movimiento del 8% aterrizja en la rampa 5–10% en 4 − (8 − 5) × 0.4 = 2.8. La intención es señalar proveedores que experimentan rotación significativa de delegadores para que los stakers puedan verlo en la tabla. La puntuación se recupera tan pronto como tu poder de voto se estabilice; un día volátil no te ancla permanentemente bajo.
Mi proveedor está nombrado con mi dirección de entidad (0x…). ¿Por qué la puntuación de Identidad es 0?
Identidad otorga 8 pts por un nombre de marca real (≥4 caracteres, no comenzando con 0x o solo hex) y 0 por un nombre puro-dirección. No podemos fabricar un nombre — establece tu profile.name en Flaremetrics y lo recogeremos en la siguiente ejecución cron. Si tu entidad tiene un perfil pero el campo de nombre está vacío, se aplica lo mismo.
Tengo una base de delegadores pequeña pero comprometida — ¿por qué mi puntuación de Conteo de Delegadores está limitada?
Delegator Count utiliza recuentos reales: cada billetera que contiene WFLR se verifica en cadena para sus delegaciones actuales, y los delegadores distintos de cada proveedor se cuentan (actualizado cada ~6 horas, verificado contra un libro mayor de eventos independiente). Desde v4.0 utiliza escala logarítmica de 5 → 500 delegadores mapeados a 0 → 12 pts, con límite en 500 (≤5 puntuación 0). La escala logarítmica significa que proveedores más pequeños con fuerte crecimiento en recuento de delegadores suben más rápido; pasados ~50 delegadores, delegadores adicionales mueven menos el indicador, pero la curva es monótona, por lo que ganar un delegador nunca puede reducir la puntuación (los buckets anteriores a v4.0 podían).
Mi puntuación bajó después de agregar un nodo — ¿qué sucedió?
Si el nodo nuevo aún no muestra eventos MIRROR claimType=3, tu fracción MIRROR baja (p.ej., de 1/1 = 100% a 1/2 = 50%), reduciendo la puntuación base de Participación MIRROR. Una vez que el nodo nuevo comienza a pagar MIRROR (típicamente dentro de una o dos épocas de recompensa de la activación), la fracción se recupera y la puntuación sube de nuevo.
¿Puedo apelar mi puntuación o solicitar una revisión manual?
Sí. Envía un correo a [email protected] con tu dirección de delegación y una preocupación específica. Respondemos a cada operador. Cosas en las que actuaremos: correcciones de clasificación MIRROR, errores matemáticos específicos de dimensión, correcciones de nombre/logo a través de Flaremetrics. Cosas en las que no actuaremos: solicitudes para elevar manualmente una puntuación fuera del algoritmo, solicitudes para excluir o desclasificar a un competidor.
Qué haremos y no haremos
Para eliminar ambigüedad sobre cómo operamos la puntuación, aquí hay compromisos explícitos. Si alguna vez violamos uno de estos, documéntalo y envía un correo a [email protected] — corregiremos públicamente.
✓
No aceptaremos pago por puntuaciones más altas, colocación patrocinada o tratamiento favorable de ningún tipo. La puntuación se calcula determinísticamente a partir de datos públicos.
✓
No codificaremos manualmente aumentos por proveedor. No hay ninguna línea "X obtiene +5 porque nos gusta" en ningún lugar del código. El mismo algoritmo se aplica a cada proveedor incluyendo el proveedor de FlareWatch, que se puntúa por esta función exacta.
✓
No excluiremos proveedores de la tabla por razones no públicas. La lista se obtiene de Flaremetrics + FSE; nuestra pantalla incluye cada proveedor activo que esas fuentes proporcionan.
✓
Publicaremos cambios en el algoritmo. Cada actualización de versión está documentada en la tarjeta de Versiones en esta página con la lógica y qué cambió. Los cambios importantes reciben una entrada adicional en el registro de cambios visible desde la página de registro de cambios de la aplicación.
✓
Responderemos a los correos electrónicos de los operadores. Cada operador que envíe un correo electrónico a [email protected] con una preocupación sustancial sobre su puntuación recibe una respuesta real dentro de unos pocos días hábiles.
✓
Corregiremos públicamente nuestros errores. Si descubrimos un error en el algoritmo, un error de fuente de datos o una brecha metodológica, implementamos una corrección y la documentamos. No reclasificamos silenciosamente.
✗
No compartiremos el contenido de los correos electrónicos públicamente sin el permiso del remitente, ni usaremos los correos electrónicos de los operadores para nada que no sea la conversación de puntuación que los produjo.
✗
No compartiremos nuestros planes futuros para un cambio de algoritmo con operadores seleccionados con anticipación — cada versión se pone en vivo para todos simultáneamente.
Puntuación final (cómo se combinan las dimensiones)
Las 12 dimensiones puntuadas suman un compuesto bruto (máximo 172). El compuesto bruto se normaliza a una escala 0–100, y luego se aplica redistribución de pesos dinámicos para producir la puntuación final mostrada.
// 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 proximidad al límite es una señal de visualización, no una deducción de puntuación. Hasta la v4.9 la puntuación también restaba un monto fijo de 1–3 puntos a proveedores muy grandes, pero eso contaba doble — un proveedor fuera del límite ya genera una tasa de recompensa realizada por debajo de la mediana, que la dimensión Tasa de Recompensa anclada a la mediana puntúa una sola vez. Por eso se eliminó la penalización. Ahora cada proveedor muestra cuánto del límite FSP (2,5% del poder de voto total en vivo del contrato WNat) ocupa, como una señal neutral de delegación marginal: cuanto más cerca del 100%, más se diluye una nueva delegación.
Bandera atípica a nivel de visualización: un proveedor cuya tasa de recompensa actual se sitúa más de tres desviaciones robustas (desviación absoluta mediana, escalada ×1,4826) por encima de la mediana del campo — y al menos 50% por encima de ella — lleva una insignia Atípico en la tabla de proveedores. La insignia no cambia la puntuación; la propia guardia de anomalías de la puntuación limita por separado las tasas por encima de 3× la mediana antes de puntuar. Los picos de tasa de época anualizada usualmente provienen de un poder de voto muy pequeño y se normalizan dentro de una época.
Fuentes de datos (cada entrada es pública)
notic.wallets.watched act". dúo dimensions de activación de puertas (Fee y V2 Participation): un proveedor que no esté en funcionamiento no debe cobrar crédito por anunciar una tarifa baja. Un proveedor se cuenta como activo si tiene una tasa de recompensa publicada o si los datos de recompensa del Flare Systems Protocol muestran que realizó pagos en al menos una época de la ventana de puntuación. Hasta el 2026-07-31 fue solo la tasa de recompensa, que provenía de una única API de terceros — entonces un proveedor que esa API no cubriera puntuaba cero en ambas dimensiones mientras distribuía visiblemente recompensas cada época. La actividad es una propiedad del proveedor, no de quién lo registra.
API pública de Flaremetrics: tasa de recompensa, tarifa de delegación, poder de voto, cambio diario de poder de voto, poder de voto bloqueado (auto-garantía), nombre del perfil + logo + región, fspRewardRate.
Flare Systems Explorer (FSE): precisión FTSO (primaria + secundaria), marcas de estado V2 (ftso_scaling, ftso_fast_updates, fdc), vinculación de direcciones de entidades, presencia de direcciones de firma/envío, registro de votantes, vinculación de nodeID de P-Chain, y la tasa de recompensa de delegación por entidad (reward_rate_wnat). La tasa de recompensa se obtiene deliberadamente de AMBAS fuentes, FSE y Flaremetrics: publican la misma cifra en unidades diferentes (FSE decimal, Flaremetrics porcentaje — verificadas idénticas en los 72 proveedores que tienen ambas, hasta cinco decimales), y FSE cubre 154 entidades contra las 80 de Flaremetrics. Cualquier fuente sola deja proveedores sin tasa sin culpa propia.
Datos de recompensas del Flare Systems Protocol (FSP): distribución de recompensas por época por proveedor, utilizado para la dimensión de Cumplimiento (cuenta épocas sin recompensas) y como fuente autoritaria para los totales de recompensas de delegación.
V2 RewardManager (eventos claimType=3): distribución MIRROR reclamada en cadena por nodeID de validador. Filtrado estrictamente en tipo 3 — sin confusión con VRM, delegación de FTSO o recompensas DIRECT. El indexador propio de FlareWatch expone estos para la dimensión de Participación MIRROR.
JSON de Merkle de FSP (asignaciones claimType=3): registro publicado canónico de quién tiene derecho a MIRROR por época (los mismos datos que lee la herramienta de firma propia de Flare). Añadido como segunda fuente autoritaria 2026-05-11 — detecta validadores cuyo MIRROR está asignado pero aún no reclamado en cadena.
Instantáneas históricas de FlareWatch: las tasas de recompensa por época alimentan el CV de Consistencia; las observaciones de participación pagada por validador alimentan la bonificación de sobredesempeño MIRROR (con la compuerta de acumulación de datos de 30 días).
Qué NO está en la puntuación
• Autopromoción o colocación pagada. Ningún proveedor puede pagar o patrocinar una puntuación más alta.
• Impulsos específicos de proveedor codificados a mano. Ninguna línea "X obtiene +5 porque nos cae bien" en ninguna parte del código. El mismo algoritmo se aplica a cada proveedor, incluido el proveedor propio de FlareWatch, que se califica con esta función exacta.
• Calidad de infraestructura subjetiva. No intentamos evaluar SLA de tiempo de actividad, distribución geográfica o especificaciones de hardware más allá de lo que FSE y Flaremetrics exponen como datos públicos.
• Bloqueos o compromisos con FlareWatch. Sin puntuación favorable para los apostadores que utilizan FlareWatch frente a otra herramienta.
• Señales futuras aún no conectadas. Presencia en la comunidad (redes sociales verificadas, participación en gobernanza), castigos históricos, latencia de respuesta y líneas de tendencia por época están dentro del alcance para versiones futuras pero no están en v3 hoy. Ninguna está ponderada en secreto.
Comentarios del operador
¿Ve algo incorrecto en la puntuación de su proveedor? Envíe un correo electrónico a [email protected] con su dirección de delegación y preocupación. Respondemos a cada operador. Solicitudes comunes en las que actuaremos:
  • Correcciones de clasificación MIRROR (atribución de claimType=3 a sus nodeIDs).
  • Errores matemáticos específicos de la dimensión con las entradas que utilizó.
  • Correcciones de nombre / logo / perfil a través de Flaremetrics o FSE.
  • Crítica general del algoritmo.
Fuentes y referencias
Cada entrada en la puntuación proviene de fuentes públicas y verificables del ecosistema Flare. Cualquiera puede verificar cruzadamente nuestras afirmaciones contra estas fuentes primarias y reproducir las matemáticas a partir de datos sin procesar. Si detecta una discrepancia entre esta página y lo que dicen las fuentes anteriores, envíe un correo electrónico a [email protected] y lo corregiremos.
Documentos de protocolo autoritarios. Cubre FTSO V2, FSP, validación de P-Chain, FAssets y el resto de la pila de Flare.
Portal de gobernanza de Flare (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — la fuente de verdad para las condiciones mínimas de protocolo V2, mecánica de tarifas y cambios en la economía de recompensas que alimentan esta puntuación.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Registro oficial operado por Flare de proveedores de datos FTSO, direcciones de entidades, vinculaciones de nodeID de P-Chain y banderas de condiciones mínimas. Fuente primaria para nuestras dimensiones de Precisión, V2 y Participación.
Flaremetrics ↗https://flaremetrics.io
Proveedor de métricas del ecosistema Flare independiente. Fuente de tasas de recompensa, tarifas, poder de voto, cambio diario de poder de voto, poder de voto bloqueado, nombres de perfil + logos y la métrica fspRewardRate.
Explorador de bloques de Flare ↗https://flare-explorer.flare.network
Navegador de solo lectura de todo el estado en cadena. Permite a cualquiera verificar los eventos RewardClaimed del V2 RewardManager (claimType=3 para MIRROR), transiciones de épocas de recompensa y más.
Repositorio reward-scripts de Flare Foundation ↗https://github.com/flare-foundation/reward-scripts
JSON publicado por época de recompensa por la Flare Foundation mostrando recompensas entregadas por validador. Entrada indirecta — alimenta el cálculo de bonificación de sobredesempeño MIRROR a través del indexador de observación de participación por estaca de FlareWatch.
API pública de Flaremetrics (proveedores FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
El endpoint exacto que consume nuestro cron, devolviendo perfiles de entidades, tasas de recompensa, comisiones y poder de voto. Cualquiera puede acceder directamente.
API pública de Flaremetrics (registros de nodos) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Tabla de conversión de Hex → cb58 NodeID. Paginamos esto para construir la búsqueda de entidad-a-NodeID que impulsa la dimensión MIRROR Participation.
Sin datos privados, sin modelos de código cerrado. El algoritmo de puntuación está implementado en services/ftso/scoring.ts en el repositorio de FlareWatch. Operadores o investigadores que quieran inspeccionar la implementación directamente (en lugar de leer la prosa + fórmulas anteriores) — o que quieran bifurcarlo para su propio uso — pueden enviar un correo a [email protected] para solicitar acceso. Publicaremos el archivo como un paquete de código abierto independiente si hay demanda real.
Cómo se actualizan las puntuaciones
La puntuación del proveedor FTSO se ejecuta como una pasada dentro del cron en /api/cron/refresh-validators, que recalcula la puntuación de cada proveedor activo cada 5 minutos (la misma ejecución que rescores los validadores de P-Chain). Las entradas (Flaremetrics, FSE, recompensas FSP, eventos de V2 RewardManager) se obtienen nuevamente en cada ejecución.
Consistency CV utiliza el historial reciente de épocas — la dimensión puede cambiar cuando se desplaza la ventana móvil. Los proveedores nuevos con menos de 3 épocas históricas puntúan el neutro 10 hasta que se acumulen suficientes datos.
La redistribución dinámica de pesos se recalcula en cada ejecución basada en el conjunto de proveedores activos actual. Cuando los proveedores se desplazan (por ejemplo, una onda de nuevas actualizaciones V2) la dimensión que se vuelve no discriminante cambia; la redistribución se adapta automáticamente.
La versión del algoritmo se marca en el encabezado de esta página. Cuando enviamos una nueva versión, la cadena de versión aquí cambia y la tarjeta Versiones abajo documenta qué cambió.
Versiones
v4.8 (2026-08-20) — La Precisión ahora recompensa la banda de recompensa DIFÍCIL. Utilizaba solo la banda secundaria (más amplia) FTSO, donde casi todos los proveedores serios alcanzan 95–99% — así que la dimensión era casi un plano 25/25 en lo alto del campo, casi no midiendo nada. La banda PRIMARIA (IQR cerrada) es la ingeniería genuinamente difícil y extiende proveedores ~28–80%. Flare recompensa estas bandas 40% primaria / 60% secundaria (FIP.11, en vivo desde 2024, con aumentos adicionales de banda secundaria señalados), así que la Precisión ahora refleja eso: una mezcla 40/60. La secundaria mantiene su curva anterior; la primaria usa una curva absoluta (28% → 0, 78% → completos 25), fija para que la puntuación permanezca re-derivable a partir de las propias entradas del proveedor. Antes/después completo en los 100 proveedores puntuados, archivado antes del envío: el reorden rastrea la fortaleza de la banda primaria — proveedores que hacen el trabajo de banda cerrada difícil se elevan, proveedores que navegan en un número secundario fácil caen. La misma regla se aplica a nuestro propio proveedor, que tiene una banda primaria débil hoy: cae de 84 a 77 y desciende varios lugares. Enviado de todas formas — una puntuación que recompensa la ingeniería real, incluso la de un competidor e incluso a nuestro propio costo, es el único tipo que vale la pena publicar.
v4.7 (2026-07-31) — La lista de proveedores dejó de depender de un único índice, y la puntuación dejó de penalizar nuestras propias brechas de datos. (1) La lista ahora se construye a partir del conjunto de votantes registrados en cadena y se rellena donde el índice de terceros carece de entidades: 98 proveedores contra los 80 mostrados anteriormente, así que 18 proveedores reales que eran insearchables e indelegables desde aquí ahora aparecen. (2) "Activo" había significado "tiene una tasa de recompensa de ese índice", que ponía en cero las dimensiones Comisión (15) y V2 (15) para cada proveedor rellenado incluso cuando nuestros propios datos FSP mostraban que pagaban cada época; ahora acepta evidencia de distribución. (3) Una tasa de recompensa faltante ya no puntúa 0 contra el denominador completo — el peso de 25 puntos deja el denominador en su lugar, así que un proveedor se puntúa sobre lo que medimos en lugar de cobrarle por lo que no pudimos. (4) La dimensión Comisión todavía se puntuaba en la curva previa a FIP-16, donde una comisión del 0% ganaba puntuación máxima. FIP-16 hace que el 20% sea la comisión mínima legal de entidad y cada uno de los 98 proveedores cobra exactamente eso, así que la dimensión otorgaba 4.00/15 a todo el campo sin varianza — 11 puntos que nadie podía ganar, valiendo aproximadamente 4.3 puntos menos en cada puntuación publicada incluyendo la más alta. Comisión ahora se ancla a max(comisión más baja observada, piso de protocolo), de la misma forma que la página de validadores lo ha anclado desde el fork Granite: cobrar el mínimo legal gana puntuación máxima, y solo las comisiones POR ENCIMA se penalizan, por distancia. Esto eleva cada puntuación por una cantidad similar y no cambia el ranking. Los proveedores con una tasa publicada no se ven afectados por los cambios (1) a (3). Ninguna tasa de recompensa se estima o infiere: esas filas leen "No hay datos". (5) La tasa de recompensa ya no depende de un único índice. Se leía solo de Flaremetrics, así que un proveedor que ese índice dejó de cubrir perdió su APR Neto y Bruto y puntuó 0/25 en Tasa de Recompensa — una penalización de 25 puntos por una brecha de cobertura de otra persona. Flare Systems Explorer publica el mismo número y cubre más entidades, así que ahora llena cualquier brecha; una tasa activa de Flaremetrics nunca se sobrescribe. El día que se implementó esto restauró una tasa publicada a 15 proveedores que no la tenían.
v4.6 (2026-07-01) — Consistency sin sesgo para nodos nuevos. Era media/desviación estándar de la tasa de recompensa en todo el historial de 30 épocas, por lo que la primera época de ganancia inflada por rampa de un nodo nuevo (peso de voto pequeño → tasa alta por unidad, que luego se normaliza) actuaba como un valor atípico que mantenía el CV alto — puntuando 0 — durante meses hasta que envejecía. Ahora usa una ventana móvil (últimas 12 épocas de ganancia) y una dispersión robusta de mediana/MAD, por lo que esa época de rampa es un valor atípico inofensivo mientras que la volatilidad genuina en curso aún puntúa bajo.
v4.5 (2026-06-30) — Self-Bond neutralizado por tamaño. La curva de solo relación podría puntuar un auto-bono absoluto grande a una relación baja POR DEBAJO de un auto-bono pequeño a una relación alta. Self-Bond ahora acredita el mayor de una relación de alineación o una cantidad absoluta saturante (limitada a 5M FLR), por lo que un operador grande comprometido y uno pequeño totalmente alineado ganan puntos completos — recompensa el compromiso, no la riqueza, y la calidad del validador permanece en las otras dimensiones.
v4.4 (2026-06-30) — Dos correcciones de errores reales. (1) Self-Bond era una dimensión MUERTA: leía un campo de Flaremetrics que la API había abandonado, por lo que cada proveedor puntuaba 0/7. Re-abastecido del verdadero auto-bono de nodo P-Chain del operador (referenciado cruzado del conjunto de validadores por nodeID). (2) Compliance dejó de penalizar épocas antes de que un proveedor estuviera activo — un nodo nuevo ganando limpiamente desde que fue lanzado fue previamente cargado por cada época anterior a él, manteniéndolo en 0/10 durante semanas. Las épocas perdidas ahora se cuentan solo dentro de la ventana activa de cada proveedor.
v4.3 (2026-06-03) — Clarificación de metodología, sin cambio en las matemáticas de puntuación. La dimensión Accuracy ahora se define explícitamente como la tasa de aterrizaje de banda secundaria en cadena (calidad de PRECIO — qué fracción de precios presentados caen dentro de la banda aceptada), distinta de la dimensión Compliance, que cuenta épocas de recompensa perdidas (PARTICIPACIÓN FSP). Esta página y las descripciones emergentes de la tabla de validadores se reescribieron para hacer la distinción explícita, y se agregó una columna Compliance junto a Accuracy. Ambas dimensiones mantienen sus pesos anteriores (25 y 10) e entradas (fseAccuracySecondary y epochsWithoutRewards).
v4.2 (2026-05-20) — Dimensión Rewards Distributed reparada. Estaba conectada a un campo de distribución de recompensas de Flaremetrics que la API v3 del proveedor abandonó, por lo que la dimensión leía 0 para cada proveedor y no contribuía nada. Reconectada a totales de recompensas de delegación FSP en cadena — los mismos datos de reclamación de recompensas que la dimensión Compliance ya agrega — por lo que la dimensión diferencia de nuevo.
v4.1 (2026-05-20) — Dimensión Compliance fijada. epochsWithoutRewards podría llegar negativo porque el cron de recompensas FSP acumuló su conteo de presencia de época más allá de la ventana móvil, lo que permitió que Compliance excediera su límite de 10 puntos (observado hasta ~58) e impulsó el compuesto más allá de su máximo — saturando aproximadamente el 70% de proveedores en un 100 plano. Compliance ahora está fijado a su peso, y el cron FSP recalcula resúmenes de recompensas sin estado por ventana para que el conteo no pueda desviarse.
v4.0 (2026-05-11) — Auditoría de equidad completa equivalente a la versión v4.0 de la puntuación del validador. Dos errores reales corregidos: (1) Delegator Count tenía un incentivo perverso en 500 — pre-corrección el depósito de 500 delegados devolvió 14 pts pero el límite >500 devolvió el WEIGHT_DELEGATORS subyacente (12), por lo que ganar un delegado a través de ese límite PERDIÓ 2 puntos. Ahora escala logarítmica de 5 → 500, monotónica hacia arriba. (2) Los niveles de V2 Participation estaban colapsados — el registro parcial de V1 y V2 completo (Scaling + FastUpdates + FDC) ambos devolvieron 15, por lo que actualizar de V1 parcial a V2 completo proporcionó cero mejora de puntuación. Ahora apilamiento por protocolo (activo +3, V1 +4, cada protocolo V2 +~2.67). Acantilados de límite eliminados en Accuracy (tenía un acantilado de 7 pts en 97%), Stability y Self-Bond Ratio — todos linealizados con valores preservados en los límites del depósito. Curva de Reward Rate reequilibrada para que mediana = mitad de los puntos de la dimensión (era 40%). Reconciliadas cadenas de documentación de dimensión obsoletas con valores de peso real. Efecto neto: cada dimensión es monotónica ascendente en el eje de entrada, y ningún proveedor puede bajar su puntuación de FlareWatch mejorando una métrica operativa real.
v3 (2026-05-09 → 2026-05-11) — Puntuación de 13 dimensiones con redistribución dinámica de pesos y penalización por dilución de poder de voto. MIRROR Participation introducido como una dimensión de primer nivel (12 base + hasta +3 bonificación de desempeño superior con encogimiento bayesiano y puerta de acumulación de datos de 30 días). Identity y Self-Bond agregados como dimensiones discretas. Reward Rate pasado a anclado en mediana. Accuracy utiliza métrica secundaria FSE para la banda de alta resolución. Consistency utiliza CV en épocas recientes.
v2 y versiones anteriores — Las versiones anteriores a v3 no están documentadas aquí; utilizaban un subconjunto más simple de dimensiones y preceden a la redistribución dinámica de pesos. Versiones retiradas en favor del modelo actual.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.