Методология оценки FTSO Provider

Версия алгоритма: v4.11 · Последнее обновление: 04.07.2026

FlareWatch присваивает каждому поставщику данных FTSO комплексный рейтинг 0–100 по 12 оцениваемым параметрам. Расчёты детерминированы, входные данные публичны в блокчейне Flare и данных экосистемы Flare.[Flaremetrics] [FSE] [Flare Explorer], и один и тот же алгоритм применяется к каждому поставщику — включая собственного поставщика FTSO FlareWatch, который оценивается по этой точной функции без специальной обработки. Эта страница документирует каждое измерение и порог, чтобы делегаторы и операторы могли видеть ровно, как вычисляется оценка и почему было выбрано каждое значение. Каждое утверждение здесь ссылается на его основной источник выше — см. Источники и ссылки внизу.

Область охвата: на этой странице документируется оценка поставщика FTSO — то, что вы видите в режиме делегирования на странице валидаторов (делегирование WFLR поставщикам данных FTSO для получения доли инфляции FTSO). Оценка валидатора, показанная в режиме стейкинга (делегирование FLR валидатору P-Chain для вознаграждений VRM + MIRROR), использует отдельный алгоритм из 9 измерений, сосредоточенный на операциях валидатора — аптайм, комиссия, надежность и т. д. Это различные роли в блокчейне с различными вознаграждениями, оценивается отдельно. Смотрите Методология оценки валидатора для стороны стейкинга.
Покрытие цепей FLR / SGB: вкладка Delegation на странице валидаторов содержит переключатель FLR / SGB для кошельков, которые содержат любые Songbird (SGB). Эта методология документирует только оценку на стороне FLR. Поставщики FTSO Songbird указаны без составной оценки — те же данные по точности / консистентности / вознаграждениям FSP, которые мы используем для FLR, еще не подключены к нашему конвейеру Songbird (Flaremetrics, наш основной источник данных FLR, не охватывает Songbird). Что видят делегаторы SGB сегодня: имя поставщика + логотип из реестра TowoLabs между сетями, текущий вес (делегировано WSGB, считано непосредственно из контракта WNat цепи Songbird через наш собственный Songbird RPC) и URL поставщика. Сортировка по весу; больший вес — это сигнал-прокси, пока не поступят данные по точности. Когда мы подключим конвейер точности + вознаграждения на стороне Songbird, та же формула из 13 измерений будет применена к поставщикам SGB — никакого нового алгоритма подсчета очков, просто формула FLR, вычисленная по данным Songbird. Оценка валидатора FlareWatch (вкладка стейкинга) вообще не имеет эквивалента SGB: набор валидаторов P-Chain в Songbird ограничен одобренными Flare Foundation объектами, поэтому розничное делегирование SGB P-Chain редко встречается, и вкладка стейкинга остается только для FLR.
Диапазоны оценок
90+Топовый уровень — топ ~10–20% поставщиков FTSO. Типичный профиль: выше среднего уровень вознаграждений, высокая точность, полное участие в протоколе V2 (FTSO Scaling + Fast Updates + FDC), низкая/нулевая комиссия, большая база делегаторов, узлы валидаторов, выплачивающие MIRROR, известный бренд. Ни одно измерение не требуется — поставщики достигают топового уровня, накапливая силу в большинстве категорий.
80–89Сильные — соответствуют большинству ключевых ориентиров; одно или два измерения не хватает до топового уровня.
70–79Хорошие — соответствуют всем базовым критериям; нет значительных пробелов.
60–69Приемлемые — используемые, но не дифференцированные.
<60Ниже среднего — значительные пробелы в одном или нескольких измерениях. Математический факт, а не оценка качества.
Измерения (сыр. веса — сумма к 172, нормализовано к 100)
«Активный» контролирует два измерения (комиссия и участие V2): провайдер, который не работает, не должен получать кредит за объявление низкой комиссии. Провайдер считается активным, если он имеет опубликованную ставку вознаграждения или если данные Flare Systems Protocol показывают, что он выплачивал вознаграждение как минимум в одну эпоху окна оценки. До 2026-07-31 это была только ставка вознаграждения из одного API третьей стороны — поэтому провайдер, который не охватывался этим API, получал нулевую оценку по обоим измерениям, несмотря на видимое распределение вознаграждений каждую эпоху. Активность — это свойство провайдера, а не того, кто его указывает.
Уровень вознаграждений25 макс. баллов
Что: Уровень вознаграждений поставщика за эпоху, привязанный к медиане сети.
Как: отношение = providerRate / medianRate. Линейное: отношение 1.0 (медиана) → 12.5 баллов, отношение 2.0 → 25 баллов (максимум). Неактивный поставщик (rewardRate ≤ 0) → 0. v4.0 (2026-05-11): максимум пересчитан так, чтобы медиана = половина баллов измерения (а не 40% как раньше).
if (rate <= 0 || medianRate <= 0): score = 0
else:
  ratio = rate / medianRate
  score = min(25, round(ratio * 12.5 * 10) / 10)   // 1 decimal place

// Anomaly detection: providers > 3× the median are capped at
// median × 3 for scoring purposes (prevents data outliers from
// distorting the linear curve).
Почему: Уровень вознаграждений — это главное, что испытывают делегаторы. Привязка к медиане держит оценку честной, когда экономика вознаграждений сети смещается — поставщик на уровне 1.2× медианы в эру низких вознаграждений ранжируется так же, как один на 1.2× в эру высоких вознаграждений. Максимумы и фильтры аномалий предотвращают доминирование единичной эпохи.
Точность25 макс. баллов
Что: Точность цены FTSO из Flare Systems Explorer (FSE) — первичные (плотные IQR) и вторичные (более широкие) частоты попаданий в полосы вознаграждения.
Как: Смесь 40/60 первичной (плотная IQR) и вторичной (более широкая) полос попаданий FTSO (v4.8), отражающая собственное распределение вознаграждений Flare — FIP.11 платит якорные вознаграждения 40% первичные / 60% вторичные. Вторичная использует предыдущую кусочно-линейную кривую (97% → 25 … 70% → 2); она почти насыщена по всему полю (95–99%), поэтому плохо различает. Первичная использует абсолютную линейную кривую — 28% → 0 до 78% → полные 25 — поэтому намного более сложная инженерия плотной полосы, где провайдеры действительно распределяются от ~28% до ~80%, это то, что разделяет поле. Фиксированные якоря (не процентили поля), поэтому оценка остаётся воспроизводимой из собственных входных данных провайдера. Резервный вариант для одной полосы когда доступна только одна; нейтральный 12.5 когда нет данных 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
Почему: Пропущенные эпохи = пропущенные доходы от вознаграждений для делегаторов. Точность определяет, будут ли отправки поставщика действительно учитываться для консенсуса FTSO, и вторичная метрика (которая взвешивает более свежие эпохи) — это то, что чище отображается на текущую производительность.
Консистентность20 макс. баллов
Что: Насколько стабильным был уровень вознаграждений поставщика в течение его последних эпох с доходом.
Как: Волатильность в худшую сторону на протяжении последних периодов получения вознаграждений провайдера, измеряется только между периодами, которые действительно являются последовательными — период, в котором провайдер ничего не заработал, не оставляет записи, и два периода по обе стороны от этого разрыва никогда не сравниваются между собой. Учитываются только падения курса в период — повышение не дает никакого вклада — поэтому стабильный или растущий курс получает близкий к максимальному результат, а восстановление повышает оценку по мере его происхождения. Падения агрегируются по RMS, поэтому резкое падение учитывается больше, чем незначительное, и взвешивается в сторону недавних пар (decay 0.8), поэтому активное восстановление повышает оценку, тогда как старые падения выходят из расчетов. cv = 0 → 20 пт; cv ≥ ~0.167 → 0. Нейтрально 10, когда в последних 12 периодах получения вознаграждений существует менее 3 последовательных пар периодов.
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)
Почему: Два провайдера с одинаковой средней ставкой вознаграждения могут обеспечить совершенно разный опыт делегатора: тот, что падает резко, хуже, чем тот, что остается стабильным или растет. Согласованность вознаграждает то, что на самом деле хочет делегатор — стабильную или растущую ставку — и штрафует только понижения пропорционально их глубине. Рост ставки НИКОГДА не наказывается (предыдущая симметричная мера это делала, что было неправильно). Недавнее сильное падение дает низкий балл, а затем восстанавливается по мере старения.
Участие в V215 макс. баллов
Что: Запущен ли поставщик на современном стеке V2 (FTSO Scaling + Fast Updates + FDC).
Как: Накопление за протокол. Активная базовая линия (rewardRate > 0) +3, V1 частичный (submit + signing + voter) +4, каждый протокол V2 (FTSO Scaling / Fast Updates / FDC) +~2.67 каждый, максимум 15. Неактивный → 0. v4.0 (2026-05-11) разделило предыдущий режим все-или-ничего (где V1 частичный = V2 полный = 15 — никакого стимула к обновлению) на бонусы за протокол, которые накапливаются.
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
Почему: V2 — это то, куда идет сеть. Per-протокольное накопление v4.0 означает, что обновление с частичного V1 на полный V2 действительно перемещает оценку (до исправления этого не было — V1 частичный и V2 полный оба возвращали 15). Добавление любого одного протокола V2 теперь улучшает измерение.
Комиссия15 макс. баллов
Что: Комиссия, которую поставщик берет на делегированные вознаграждения.
Как: Линейная интерполяция через контрольные точки: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. Неактивный поставщик → 0.
anchor = max(lowest active fee observed, protocol fee floor)
// FIP-16 sets a 20% minimum entity fee. All 98 providers charge
// exactly 20%, so the anchor is 20% and nobody is docked for
// charging the only fee the protocol permits. Same curve and
// same anchor the validator page's Fee dimension uses.

if (!isActive) score = 0
d = fee - anchor              // distance ABOVE the best real offer
if (d <= 0)  score = 15       // at or below the anchor → full marks
elif (d <= 5)  score = 15 - d * 0.43
elif (d <= 10) score = 12.9 - (d - 5) * 0.64
elif (d <= 15) score = 9.6 - (d - 10) * 0.86
elif (d <= 20) score = 5.4 - (d - 15) * 1.07
else: score = 0               // extractive
Почему: Комиссия напрямую уменьшает то, что получают делегаторы. Линейная интерполяция (а не дискретные диапазоны) означает, что комиссия в 7% набирает баллы между 10% и 15%, а не прыгает в один диапазон — операторы не получают кредит за округление своей комиссии до следующей границы диапазона.
Участие в MIRROR12 (+3 бонус) макс. баллов
Что: Выплачивают ли узлы валидаторов P-Chain оператора активно долю инфляции FTSO стейкерам, плюс бонус за перевыполнение.
Как: Базовая оценка масштабируется линейно в зависимости от доли nodeID оператора, выплачивающих вознаграждения MIRROR. Все узлы активны → 12 pts. Частично → пропорционально. Ни один → 0. По состоянию на 2026-05-11 сигнал 'active' считывается из двух канонических источников: событиях on-chain RewardClaimed(claimType=3) на V2 RewardManager И распределениях claimType=3 в официальном JSON Merkle FSP — достаточно либо одного. До обновления мы использовали поток on-chain как единственный сигнал, который давал ложные отрицания для провайдеров, чья выплата MIRROR осуществляется через нестандартный путь требования. Плюс бонус перевыполнения до +3 pts, когда валидаторы оператора постоянно доставляют свыше 100% ожидаемого (vrm + mirror) / expected — байесовское сжатие с вратой накопления данных в 30 дней и минимумом в 3 stake предотвращает игроизацию бонуса мелкими или новыми операторами на нескольких удачных показаниях.
if (no fseNodeIDs) score = 0
if (mirrorStatsMap empty) score = 12 / 2 = 6   // Neutral seed before data lands

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

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

avgBonus = sum_per_node(bonus) / fseNodeIDs.length
score = round((base + avgBonus) * 10) / 10
Почему: Участие в MIRROR — это делегирование доли инфляции FTSO вашим стейкерам. Провайдер, активный в V2, чьи узлы валидатора не выплачивают MIRROR, доставляет примерно 5–15% меньше доходности делегаторам, чем тот же провайдер с активными узлами. Бонус перевыполнения вознаграждает постоянно лучшую, чем ожидалось, доставку без завышения оценки новых операторов на малых выборках — байесовское сжатие и врата накопления в 30 дней сохраняют справедливость.
Количество делегаторов12 макс. баллов
Что: Количество уникальных кошельков, в настоящее время делегирующих этому провайдеру, подсчитанное на основе данных блокчейна.
Как: Логарифмическая шкала от 5 → 500 делегаторов, отображённые в 0 → 12. ≤5 → 0, ≥500 → 12 (потолок). Соответствует стилю сигнала подсчёта размера доверия валидатора. v4.0 (2026-05-11): исправлена реальная ошибка, при которой предыдущая схема корзин создавала извращённый стимул ровно на 500 делегаторов (до исправления: 500 → 14, 501 → 12 — добавление делегатора через эту границу ПОТЕРЯЛО 2 очка).
if (count <= 5)   score = 0
elif (count >= 500) score = 12
else:
  ratio = log(count / 5) / log(100)   // maps [5, 500] → [0, 1]
  score = round(min(12, max(0, ratio * 12)) * 10) / 10
Почему: Количество делегаторов — сигнал доверия, независимый от размера stake. Провайдер со 200 делегаторами был выбран 200 независимыми стейкерами; один с 5 — выбран почти только оператором. Логарифмическая шкала даёт убывающую отдачу после примерно 50 делегаторов, но никогда не разворачивается (так происходило с букетной системой подсчёта до v4.0).
Участие в эпохах10 макс. баллов
Что: Активно ли провайдер участвует в эпохах.
Как: FSE отмечает провайдера активным → 10. Провайдер имеет rewardRate > 0 (Flaremetrics), но без флага активности FSE → 7 (активен по рыночным данным, отсутствует подтверждение FSE). Иначе → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Почему: Выявляет провайдеров, чей поток вознаграждения прекратился, даже если Flaremetrics всё ещё их указывает. Отличается от Точности (которая касается корректности за эпоху) — Участие касается самого появления.
Стабильность силы голоса10 макс. баллов
Что: Процентное изменение силы голоса провайдера день за день.
Как: Кусочно-линейная в абсолютном проценте изменения день за день. <1% → 10. Линейно от 1% → 3% (10 → 7). Линейно от 3% → 5% (7 → 4). Линейно от 5% → 10% (4 → 2). Продолжает движение к 0 сверх 10%. v4.0 (2026-05-11): линеаризованы предыдущие обрывы корзин (были обрывы до 3 очков на каждом пороге).
change = abs(votePowerDailyChangePct * 100)
if (change < 1)  score = 10
elif (change < 3) score = 10 - (change - 1) * 1.5     // 1 → 10, 3 → 7
elif (change < 5) score = 7  - (change - 3) * 1.5     // 3 → 7,  5 → 4
elif (change < 10) score = 4 - (change - 5) * 0.4     // 5 → 4, 10 → 2
else               score = max(0, 2 - (change - 10) * 0.1)
Почему: Большие колебания силы голоса день за день часто указывают на волну делегаторов, входящих или выходящих — стейкеры, читающие таблицу, видят движущуюся цель. Стабильная сила голоса сигнализирует об устоявшемся провайдере с приверженными делегаторами.
Соответствие10 макс. баллов
Что: Был ли провайдер оплачен в каждой эпохе вознаграждения С МОМЕНТА его активизации в данных вознаграждений FSP.
Как: Полные 10 очков за нулевые пропущенные эпохи в пределах окна активности провайдера. Каждая пропущенная эпоха вычитает 3 pts (ограничено на 0). Нейтральные 5, когда данные FSP недоступны. v4.4 (2026-06-30): пропущенные эпохи теперь считаются только с первой участвующей эпохи провайдера — новый провайдер больше не штрафуется за эпохи до его существования (что ранее держало новые, но чистые узлы на 0/10 неделями).
if (no fspData OR totalEpochs <= 0) score = 5

// active window = epochs from the provider's first paid epoch to now
missed = (active-window epochs) - (epochs the provider was paid)
score = max(0, 10 - missed * 3)
Почему: Пропущенная эпоха в официальном распределении вознаграждений Flare Systems Protocol означает, что провайдер не соответствовал соответствию протоколу для этой эпохи — минимальные условия, политика подписи и т. д. Подсчёт только с первого участия сохраняет справедливость для новых провайдеров, одновременно штрафуя подлинные пропуски. Три очка за пропуск — это круто, поэтому один пропуск — заметный сигнал, но поправимый; примерно 3 пропуска обнуляют размерность.
Идентичность8 макс. баллов
Что: Имеет ли провайдер реальное название бренда или просто шестнадцатеричный адрес.
Как: Названный бренд (≥4 символов, не начинающийся с 0x) → 8. Короткий или анонимный (<4 символов) → 4. Чистый hex / адрес 0x как имя → 0.
if (no name) score = 0
elif (name starts with 0x or matches hex regex) score = 0
elif (name.length < 4) score = 4
else score = 8
Почему: Названный провайдер выбрал быть узнаваемым и подотчётным — его можно найти, связаться и потребовать соответствия опубликованным обязательствам. Анонимные по адресу провайдеры функциональны, но предоставляют меньше сигналов доверия делегаторам, оценивающим их.
Собственная ставка7 макс. баллов
Что: Собственный облигационный узел P-Chain оператора (деньги в игре) — исключая stake, который другие делегируют узлу. Размер-нейтральные обязательства ворот, не ранжирование богатства.
Как: Зачисляется по БОЛЬШЕМУ из двух насыщающихся осей: (1) выравнивание — собственная облигация как доля от общей обязанной stake (≥10% → полная); или (2) абсолютная — собственный капитал в опасности, ограниченный 5M FLR, поэтому 5M и 80M получают одинаковую оценку. v4.4 (2026-06-30): переисточено из истинной облигации самопроизвольной цепи оператора P-Chain (вес валидатора, перекрёстно ссылаемый по nodeID) — предыдущее поле Flaremetrics, которое оно читало, было прекращено, поэтому каждый провайдер получил оценку 0. v4.5 (2026-06-30): добавлена абсолютная ось + насыщение, так что большая собственная ставка при низком коэффициенте не оценивается ниже малой при высоком коэффициенте, без предоставления победы размеру или наказания мелких операторов.
ownBond      = operator's own P-Chain node bond (FLR)
total        = ownBond + delegated WFLR vote power
alignment    = piecewise-linear ratio curve (0% → 0 … ≥10% → 7)
absolute     = min(7, ownBond / 5,000,000 * 7)   // saturates at 5M FLR
score        = max(alignment, absolute)
Почему: Деньги в игре — оператор с собственным капиталом в опасности выравнен с делегаторами. Но размер собственной ставки не является прокси для КАЧЕСТВА оператора (это находится в других размерностях), поэтому мелкий полностью выравненный оператор и крупный обязанный оба получают полные баллы. Только оператор с малым собственным капиталом — малая доля И малая сумма — получает баллы ниже полных.
Как набрать 100/100 — руководство провайдера FTSO
Аудит справедливости v4.0 был специально разработан так, чтобы максимизирование каждого размерения оценки действительно сделало вас лучшим провайдером FTSO для своих делегаторов. Улучшение вашей оценки — это не игроизация системы — это система, работающая так, как задумано. Вот руководство по размерностям.
Ставка вознаграждения — 25 pts. Доставляйте ≥ 2× сетевой медианной ставкой вознаграждения FSP за эпоху (после комиссии, после распределения протокола). Линейно от 0 к 2× медиане: медиана → 12.5, 2× медиана → 25. Почему это выравнивается: это долларовая сумма, фактически достигающая ваших делегаторов за эпоху.
Точность — 25 pts. Нацеливайтесь на ≥97% коэффициента приземления вторичной полосы на FSE для полных очков. Кусочно-линейно, поэтому 95% → 18, 93% → 16, 90% → 13 и т. д. — каждое улучшение на 1% перемещает оценку. Это качество ЦЕНЫ, а не участие в эпохе: оно измеряет, какая доля представленных цен попадает в пределы полосы, принятой в цепи. Провайдер с высокой точностью публикует цены близко к консенсусу; один с низкой точностью надёжно участвует, но чаще не совпадает с консенсусом. Почему это выравнивается: предложения вне полосы приносят меньше вознаграждения делегаторам, даже когда провайдер участвует в каждой эпохе. Отдельное размерение Соответствия ниже отслеживает участие в эпохе.
Последовательность — 20 pts. Минимизируйте дисперсию ставки вознаграждения за эпоху (CV = stddev/mean по последним эпохам). CV = 0 → 20, CV = 0.2+ → 0. Почему это выравнивается: два провайдера с одинаковой среднией ставкой вознаграждения не эквивалентны — предсказуемые выплаты лучше волатильных для UX стейкера.
V2 участие — 15 pts. Штакируйте протоколы адитивно: активная базовая линия + V1 частичная регистрация + каждый протокол V2 (Масштабирование, FastUpdates, FDC). Полный V2 + активный + V1 зарегистрирован = 15. Почему это выравнивается: V2 — это то, куда идёт сеть; каждый дополнительный протокол, который вы принимаете, — это будущая инвестиция, от которой выигрывают ваши делегаторы.
Комиссия — 15 pts. Взимайте ≤ 5% за 13 pts, 0% за 15. Кусочно-линейный пандус по ориентирам 5%/10%/15%/20%/25% к 0. Почему это выравнивается: более низкая комиссия = больше вознаграждения напрямую достигает ваших делегаторов.
MIRROR участие — 12 + до 3 бонусов. Запустите все узлы валидатора P-Chain вашего оператора как MIRROR-активные (либо через события on-chain RewardClaimed, либо распределения FSP Merkle JSON — двойной источник v3.6). Устойчивое перевыполнение (медианное соотношение (vrm+mirror)/expected выше 1.05) на ≥3 оплаченных stakes после 30 дней наблюдения приносит до +3 бонуса. Почему это выравнивается: MIRROR — это доля ваших делегаторов в инфляции FTSO; узлы, не выплачивающие MIRROR, доставляют примерно 5-15% меньше доходности стейкерам.
Количество делегаторов — 12 pts. Логарифмическая шкала 5 → 500 делегаторов, отображённые в 0 → 12. Постройте базу независимых стейкеров, а не просто нескольких китов. Почему это выравнивается: количество — это сигнал доверия, независимый от размера stake; 200 делегаторов, выбирающих вас, означает 200 независимых одобрений.
Участие в эпохе — 10 pts. Появляйтесь в каждой эпохе с положительной ставкой вознаграждения и активным флагом FSE. Почему это выравнивается: выявляет прерванные потоки вознаграждений, которые размерности за эпоху могут пропустить.
Стабильность — 10 баллов. Изменение мощности голосов день-к-дню должно оставаться ниже 1%. Линейный градиент от этого значения. Обоснование: стабильная мощность голосов указывает на установившихся делегаторов (липкое сообщество), а не на волны китов-спекулянтов.
Соответствие — 10 баллов. Нулевые пропущенные периоды вознаграждений в данных FSP. Каждый пропуск стоит 3 балла; ~3 пропуска обнуляют измерение. Это УЧАСТИЕ, а не качество цены: считаются периоды, когда поставщик был наказан за пропуск минимальных условий, политики подписи или других требований протокола — отличается от измерения Точности выше, которое оценивает попадание цены в диапазон. Обоснование: пропущенный период в собственном распределении вознаграждений протокола означает, что поставщик не выполнил минимальные условия, и делегаторы не получили ничего в этом периоде. Поставщик может иметь отличную точность в периодах участия и всё равно полностью пропустить периоды.
Идентичность — 8 баллов. Зарегистрируйте реальное имя бренда (≥4 символов, не шестнадцатеричный адрес) на Flaremetrics или FSE. Анонимные поставщики (по адресу) получают 0; именованные поставщики получают 8. Обоснование: именованные поставщики легко найти и они несут ответственность; это базовый сигнал доверия.
Самостоятельный залог — 7 баллов. Подтвердите собственный залог узла P-Chain (не ставку, которую другие делегируют вам). Полные баллы за ЛИБОзначительную часть вашей общей ставки (≥10%), ЛИБОзначительный абсолютный размер (абсолютная шкала достигает максимума в 5M FLR, поэтому крупный оператор не может превзойти малого по размеру). Обоснование: риск денежных средств — операторы со своим капиталом на кону разделяют результаты доходности своих делегаторов. Это размерно-нейтральные ворота обязательства, а не ранжирование по богатству: полностью согласованный малый оператор и крупный обязанный получают оба полные баллы, а ваше операционное качество оценивается другими измерениями.
Сигналы с временными воротами, которые нельзя обойти: Согласованность требует ≥3 периодов истории. Бонус переработки MIRROR требует 30 дней наблюдения плюс ≥3 оплаченных образцов ставок. Соответствие требует данных FSP, охватывающих достаточно периодов для подсчёта. Создавайте трек-рекорд; баллы последуют.
Суммарный сырой рейтинг достигает максимум 172 по всем 12 оцениваемым параметрам и затем нормализуется к 100. Идеальное выполнение всех условий даёт 172/172 → 100 отображаемых. Штраф за размывание голосующей мощи до −3 пкт применяется для очень крупных поставщиков (>1,34 млрд VP) как механизм разрешения ничьих.
Как проверить собственный счёт
Каждый счёт в таблице поставщиков воспроизводим из открытых данных. Если вы оператор и математика здесь не совпадает со счётом, который вы видите, правильный ход — проверить это самостоятельно перед тем, как предположить, что мы ошиблись. Пошаговое руководство:
  1. Поищите публичную статистику вашего поставщика на flaremetrics.io (поиск по имени или вставьте адрес делегирования). Запомните fspRewardRate, delegationFeePercentage, wNatWeight и votePowerDailyChangePct.
  2. Проверьте FTSO V2 + точность на flare-systems-explorer.flare.network. Найдите вашу сущность. Проверьте providersuccessrate.secondary на точность, плюс флаги entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc на статус V2.
  3. Проверьте участие в MIRROR на контракте V2 RewardManager через flare-explorer.flare.network. Ищите события RewardClaimed с claimType=3, ссылающиеся на ваши nodeID. Если недавних нет ни для одного из ваших узлов, вы будете отображаться как неактивный MIRROR.
  4. Подставьте ваши входные данные в формулы выше. Блок кода каждого измерения точно говорит вам, какую арифметику выполнять. Суммируйте измерения, разделите на 172 (сыр. макс), умножьте на 100, и у вас будет ваша сыр. композитная оценка.
  5. Применить штраф за разбавление, если вы крупные. Мощность голоса выше 1.34B составляет −3, выше 1B составляет −1. Карточка Final Score ниже содержит точные пороги.
  6. Сравните с отображаемым счётом. Отображаемый счёт также отражает динамическое перераспределение весов — когда большинство поставщиков кластеризуются в одном измерении (низкое стандартное отклонение по активному набору), вес этого измерения перераспределяется на измерения, где разброс шире. Панель разбивки счёта в каждой строке поставщика показывает текущие значения по измерениям.
  7. Если математика не сходится, отправьте письмо на [email protected] с вашим адресом делегирования, использованными входными данными и вычисленным счётом. Мы ответим, и если мы ошиблись, мы её исправим публично.
Общие проблемы операторов
Мой уровень вознаграждения выше медианы, но мой балл за ставку вознаграждений не 25/25 — почему?
Ставка вознаграждений линейна в отношении к медиане: баллы = отношение × 12.5, поэтому 1.0× медиана = 12.5/25 и вам нужно отношение 2.0× для достижения максимума. Поставщик с 1.2× медианы получает 15 баллов, с 1.5× получает ~18.8, с 2.0× получает полные 25. Максимум (плюс фильтр аномалий 3×-медиана) существует, чтобы один аномально высокий период вознаграждения не доминировал в измерении; если ваша ставка постоянно в топ-дециле, баллы всё равно её сильно вознаграждают.
Я только что обновился до V2 — когда обновляется мой V2 балл?
Статус V2 поступает из флагов entityminimalconditionslatest FSE (ftso_scaling, ftso_fast_updates, fdc). С v4.0 измерение складывается по протоколам: активная базовая линия +3, регистрация V1 (submit + signing + voter) +4, и каждый протокол V2 +~2.67. Поэтому поставщик, зарегистрированный избирателем с адресами submit + signing, но без трёх протоколов V2, получает 7/15, и каждый отдельный протокол V2, который вы включите, движет баллы — все три в сети даёт вам полные 15. Изменения появляются при следующем запуске FlareWatch cron (каждые 5 минут) после отражения в FSE.
Моя точность на FSE составляет 96%, но я получаю меньше баллов, чем ожидал.
Измерение точности использует вторичную метрику точности FSE (более высокое разрешение в диапазоне 94–97%, где кластеризуется большинство поставщиков). 95–96% соответствует 18 баллам; вам нужно ≥97% для полных 25. Интервалы плотные вверху, потому что несколько десятых процента в диапазоне 95–97% представляют реальное разделение производительности между поставщиками.
Я доставляю MIRROR — почему FlareWatch показывает меня как неактивного MIRROR в моём счёте поставщика?
По состоянию на 2026-05-11 участие MIRROR выявляется из ДВУ источников: события RewardClaimed(claimType=3) в цепи на V2 RewardManager И распределения claimType=3 в официальном JSON Merkle FSP. NodeID, появляющийся в любом источнике, считается активным. Для операторов с несколькими узлами счёт использует долю активных узлов (1/3 активных = 4/12 базовых и т.д.). Если узел должен быть классифицирован как активный, но не показывается после следующего цикла сканирования, отправьте нам письмо с nodeID и конкретным периодом, который вы ожидаете увидеть — мы перепроверим оба источника.
Моя мощность голоса вчера переместилась на 8% — почему баллы стабильности около 2.8/10?
Стабильность мощности голоса — линейна в абсолютном изменении день-к-дню (линеаризована в v4.0 — без скальпов в интервалах): <1% → 10, рамп 1→3% вниз до 7, 3→5% вниз до 4, 5→10% вниз до 2, затем к 0 более 10%. Движение на 8% приземляется на рамп 5–10% в 4 − (8 − 5) × 0.4 = 2.8. Намерение — отметить поставщиков, переживающих значимый оборот делегаторов, чтобы ставщики могли видеть это в таблице. Баллы восстанавливаются, как только ваша мощность голоса стабилизируется; один волатильный день не якорит вас низко навсегда.
Мой поставщик назван адресом моей сущности (0x…). Почему баллы идентичности 0?
Идентичность награждает 8 баллов за реальное имя бренда (≥4 символов, не начинающиеся с 0x или только шестнадцатеричные) и 0 за имя с чистым адресом. Мы не можем придумать имя — установите profile.name на Flaremetrics и мы его подберём при следующем запуске cron. Если ваша сущность имеет профиль, но поле name пусто, то же самое.
У меня небольшая, но приверженная база делегаторов — почему мой баллы за количество делегаторов ограничены?
Delegator Count использует реальные подсчёты: каждый кошелёк, хранящий WFLR, проверяется в цепи на предмет текущих делегаций, и уникальные делегаторы каждого провайдера подсчитываются (обновление каждые ~6 часов с перекрёстной проверкой по независимому журналу событий). Начиная с версии 4.0 используется логарифмическое масштабирование: 5 → 500 делегаторов соответствуют 0 → 12 пт, максимум 500 (≤5 дают 0 пт). Логарифмическое масштабирование означает, что более мелкие провайдеры с сильным ростом числа делегаторов растут быстрее всех; после ~50 делегаторов каждый дополнительный делегатор меньше влияет на шкалу — но кривая монотонна, поэтому добавление делегатора никогда не снизит оценку (в версии до 4.0 такие скачки были возможны).
Мой баллы упали после добавления узла — что произошло?
Если новый узел ещё не показывает события MIRROR claimType=3, ваша доля MIRROR падает (например, с 1/1 = 100% на 1/2 = 50%), снижая базовый баллы участия MIRROR. Как только новый узел начнёт платить MIRROR (обычно в течение одного или двух периодов вознаграждения после активации), доля восстановится и баллы вырастут.
Могу ли я обжаловать мой баллы или запросить ручное рассмотрение?
Да. Отправьте письмо на [email protected] с вашим адресом делегирования и конкретным вопросом. Мы отвечаем каждому оператору. Вещи, на которые мы действуем: исправления классификации MIRROR, ошибки математики конкретного измерения, исправления имени/логотипа через Flaremetrics. Вещи, на которые мы не действуем: запросы вручную повысить баллы вне алгоритма, запросы исключить или дерангировать конкурента.
Что мы будем и не будем делать
Чтобы устранить неясность о том, как мы работаем со счётом, вот явные обязательства. Если мы когда-нибудь нарушим одно из них, задокументируйте это и отправьте письмо на [email protected] — мы его публично исправим.
✓
Мы не будем принимать платежи за более высокие баллы, спонсируемое размещение или благоприятное обращение любого рода. Баллы рассчитываются детерминистически из открытых данных.
✓
Мы не будем кодировать бонусы для отдельных поставщиков вручную. Нигде в коде нет строки "X получает +5, потому что нам он нравится". Один и тот же алгоритм применяется к каждому поставщику, включая собственного поставщика FlareWatch, который оценивается этой точной функцией.
✓
Мы не будем исключать поставщиков из таблицы по закрытым причинам. Список получается из Flaremetrics + FSE; наше отображение включает каждого активного поставщика, которого выявляют эти источники.
✓
Мы будем публиковать изменения алгоритма. Каждое обновление версии задокументировано в карточке «Версии» на этой странице с обоснованием и описанием изменений. Крупные изменения получают дополнительную запись в журнале изменений, видимую на странице журнала изменений приложения.
✓
Мы будем отвечать на письма операторов. Каждый оператор, отправивший письмо на [email protected] с обоснованным вопросом о своем рейтинге, получит реальный ответ в течение нескольких рабочих дней.
✓
Мы будем публично исправлять наши ошибки. Если мы обнаружим ошибку в алгоритме, ошибку в источнике данных или пробел в методологии, мы выпустим исправление и задокументируем его. Мы не переранжируем молча.
✗
Мы не будем публиковать содержание писем без разрешения отправителя или использовать письма операторов для чего-либо, кроме разговора о рейтинге, который их произвел.
✗
Мы не будем делиться своими планами на изменение алгоритма с отдельными операторами заранее — каждая версия выходит для всех одновременно.
Итоговый рейтинг (как объединяются измерения)
Все 12 оцениваемых параметров суммируются в сырой составной показатель (макс. 172). Сырой составной показатель нормализуется на шкалу 0–100, затем применяется динамическое перераспределение весов для получения финальной отображаемой оценки.
// Step 1 — Raw composite (sum of 12 dimensions, max 172)
raw = rewardRate + accuracy + consistency + v2 + fee + mirror
    + delegators + participation + stability + compliance
    + identity + selfBond

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

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

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

// Step 3 — Final score (capped at 100)
score = min(100, final)
Близость к лимиту — это сигнал отображения, а не штраф за оценку. До версии 4.9 оценка также вычитала фиксированные 1–3 очка у очень крупных провайдеров, но это было двойным счётом — превышающий лимит провайдер уже получает коэффициент реализованного вознаграждения ниже среднего, который измеряется один раз параметром Reward Rate, привязанным к медиане. Поэтому штраф был убран. Каждый провайдер теперь показывает, какую часть лимита FSP (2,5% от живой мощности голосования контракта WNat) он занимает, как нейтральный сигнал предельного делегирования: чем ближе к 100%, тем больше новое делегирование размывается.
Флаг выброса на уровне отображения: поставщик, текущая ставка вознаграждения которого более чем на три устойчивых отклонения (среднее абсолютное отклонение, масштабированное ×1.4826) выше медианы поля и по крайней мере на 50% выше её, имеет значок Выброса в таблице поставщиков. Значок не изменяет оценку; собственная защита от аномалий оценки отдельно ограничивает ставки выше 3× медианы перед оценкой. Годовые скачки ставок эпохи обычно возникают из-за очень малой мощности голоса и нормализуются в течение эпохи.
Источники данных (каждый вход открыт)
Контракты Flare, читаемые напрямую в блокчейне: зарегистрированный набор провайдеров (VoterRegistry), связи сущность → адрес делегирования и nodeID, регистрация адресов отправки и подписи (EntityManager), делегированная мощность голоса (WNat) и комиссия делегирования (WNatDelegationFee). Это делает список провайдеров независимым от любого одного индекса: в эпохе вознаграждения 420 блокчейн содержал 98 зарегистрированных провайдеров против 80 в списке третьей стороны, и 18 провайдеров из разницы ранее полностью отсутствовали на этом сайте.
Открытый API Flaremetrics: ставка награды, комиссия делегирования, голосующая мощность, ежедневное изменение голосующей мощности, заблокированная голосующая мощность (собственный залог), название профиля + логотип + регион, fspRewardRate.
Flare Systems Explorer (FSE): точность FTSO (основной + вторичный), флаги статуса V2 (ftso_scaling, ftso_fast_updates, fdc), связь адреса сущности, наличие адреса подписи/отправки, регистрация голосующего, связь P-Chain nodeID и ставка вознаграждения за делегирование на одну сущность (reward_rate_wnat). Ставка вознаграждения намеренно получается из FSE И Flaremetrics: они публикуют одну и ту же цифру в разных единицах (FSE десятичная дробь, Flaremetrics процент — проверено идентичное значение для всех 72 поставщиков с обоими источниками с точностью до пяти десятичных мест), и FSE охватывает 154 сущности против 80 Flaremetrics. Любой единственный источник оставляет поставщиков без ставки не по их вине.
Данные вознаграждений протокола Flare Systems (FSP): распределение вознаграждений за эпоху для каждого поставщика, используется для измерения соответствия (подсчитывает эпохи без вознаграждений) и как авторитетный источник для итоговых вознаграждений за делегирование.
V2 RewardManager (события claimType=3): распределение MIRROR, требуемое на цепи для каждого nodeID валидатора. Строго отфильтровано по типу 3 — без смешивания с VRM, FTSO делегированием или DIRECT вознаграждениями. Собственный индексатор FlareWatch выводит эти данные для измерения MIRROR Participation.
FSP Merkle JSON (распределение claimType=3): канонический опубликованный реестр того, кому причитается MIRROR за эпоху (те же данные, которые читает собственный инструмент подписания Flare). Добавлен как второй авторитетный источник 2026-05-11 — отлавливает валидаторов, у которых MIRROR распределен, но еще не требуется на цепи.
Исторические снимки FlareWatch: ставки награды за эпоху питают CV согласованности; наблюдения за уплаченной ставкой для каждого валидатора питают бонус за превышение производительности MIRROR (с проверкой накопления данных за 30 дней).
Что НЕ входит в рейтинг
• Самопродвижение или платное размещение. Ни один поставщик не может платить или спонсировать более высокий рейтинг.
• Вручную закодированные дополнения для конкретных поставщиков. Нет нигде в коде строк "X получает +5, потому что нам нравится". Одинаковый алгоритм применяется ко всем поставщикам, включая собственного поставщика FlareWatch, который оценивается этой же функцией.
• Субъективное качество инфраструктуры. Мы не пытаемся оценить SLA доступности, географическое распределение или характеристики оборудования сверх того, что выявляют FSE и Flaremetrics как открытые данные.
• Блокировки или обязательства перед FlareWatch. Никакого благоприятного рейтинга за использование стейкерами FlareWatch вместо другого инструмента.
• Будущие сигналы еще не подключены. Присутствие в сообществе (проверенные социальные сети, участие в управлении), историческое слешинг, задержка ответа и линии тренда за эпоху планируются для будущих версий, но не входят в v3 сегодня. Ни один из них не взвешивается втайне.
Отзыв операторов
Видите что-то неправильное в рейтинге вашего поставщика? Отправьте письмо на [email protected] с адресом вашего делегирования и вопросом. Мы отвечаем каждому оператору. Общие запросы, на которые мы будем действовать:
  • Исправления классификации MIRROR (атрибуция claimType=3 вашим nodeID).
  • Ошибки математики в измерениях с входными данными, которые вы использовали.
  • Исправления названия / логотипа / профиля через Flaremetrics или FSE.
  • Общая критика алгоритма.
Источники и ссылки
Каждый вход в рейтинг поступает из открытых, проверяемых источников экосистемы Flare. Любой может перепроверить наши утверждения по этим первичным источникам и воспроизвести математику из сырых данных. Если вы обнаружите расхождение между этой страницей и тем, что говорят вышестоящие источники, отправьте письмо на [email protected] и мы исправим это.
Авторитетная документация протокола. Охватывает FTSO V2, FSP, валидацию P-Chain, FAssets и остальную часть стека Flare.
Предложения по улучшению Flare — источник истины для минимальных условий протокола V2, механики комиссий и изменений экономики вознаграждений, которые питают этот рейтинг.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Официальный реестр поставщиков данных FTSO, адреса сущностей, связи nodeID P-Chain и флаги минимальных условий, управляемый Flare. Первичный источник для наших измерений Accuracy, V2 и Participation.
Flaremetrics ↗https://flaremetrics.io
Независимый поставщик метрик экосистемы Flare. Источник ставок награды, комиссий, голосующей мощности, ежедневного изменения голосующей мощности, заблокированной голосующей мощности, названий профилей + логотипов и метрики fspRewardRate.
Обозреватель блоков Flare ↗https://flare-explorer.flare.network
Браузер только для чтения всего состояния на цепи. Позволяет любому проверить события RewardClaimed V2 RewardManager (claimType=3 для MIRROR), переходы эпох вознаграждений и остальное.
Репозиторий reward-scripts Flare Foundation ↗https://github.com/flare-foundation/reward-scripts
JSON, опубликованный за эпоху вознаграждения Flare Foundation, показывающий доставленные вознаграждения для каждого валидатора. Косвенный ввод — питает расчет бонуса за превышение производительности MIRROR через индексатор наблюдений за ставкой FlareWatch.
Публичный API Flaremetrics (провайдеры FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Точная конечная точка, которую использует наш cron, возвращающая профили сущностей, ставки вознаграждения, комиссии и мощность голоса. Любой может обращаться к ней напрямую.
Публичный API Flaremetrics (регистрация узлов) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Таблица преобразования Hex → cb58 NodeID. Мы разбиваем это на страницы, чтобы построить поиск сущности по NodeID, который управляет измерением MIRROR Participation.
Без приватных данных, без закрытых моделей. Алгоритм скоринга реализован в services/ftso/scoring.ts в кодовой базе FlareWatch. Операторы или исследователи, которые хотят проверить реализацию напрямую (вместо чтения текста и формул выше) — или которые хотят форкировать её для собственного использования — могут отправить письмо на [email protected], чтобы запросить доступ. Мы опубликуем файл как отдельный пакет с открытым исходным кодом, если будет реальный спрос.
Как обновляются оценки
Скоринг провайдера FTSO запускается как проход внутри cron в /api/cron/refresh-validators, который пересчитывает оценку каждого активного провайдера каждые 5 минут (тот же запуск, который переоценивает валидаторы P-Chain). Входные данные (Flaremetrics, FSE, вознаграждения FSP, события V2 RewardManager) извлекаются свежими при каждом запуске.
Consistency CV использует историю недавних эпох — измерение может измениться при смещении скользящего окна. Новые провайдеры с менее чем 3 историческими эпохами получают нейтральную оценку 10, пока не накопится достаточно данных.
Динамическое перераспределение весов пересчитывается при каждом запуске на основе текущего набора активных провайдеров. По мере движения провайдеров (например, волна новых обновлений V2) измерение, которое перестаёт быть дифференцирующим, смещается; перераспределение адаптируется автоматически.
Версия алгоритма указана в заголовке этой страницы. Когда мы выпускаем новую версию, строка версии здесь изменяется, и карточка Versions ниже документирует изменения.
Версии
v4.8 (2026-08-20) — Точность теперь награждает СЛОЖНУЮ полосу вознаграждения. Она использовала только вторичную полосу FTSO (более широкую), где почти каждый серьёзный провайдер попадает на 95–99% — поэтому размер был почти плоским 25/25 по всей верхушке поля, близко к тому, чтобы ничего не измерять. Первичная полоса (плотная IQR) — это действительно сложная инженерия и распределяет провайдеров ~28–80%. Flare награждает эти полосы 40% первичной / 60% вторичной (FIP.11, активно с 2024 года, с дальнейшими увеличениями вторичной полосы сигнализировано), поэтому Точность теперь отражает это: смесь 40/60. Вторичная сохраняет свою предыдущую кривую; первичная использует абсолютную кривую (28% → 0, 78% → полные 25), фиксированную так что оценка остаётся воспроизводимой из собственных входных данных провайдера. Полный анализ «до и после» по всем 100 оцениваемым провайдерам, архивирован перед развёртыванием: переупорядочение отслеживает прочность первичной полосы — провайдеры, делающие сложную работу плотной полосы, поднимаются, провайдеры, плывущие на лёгком вторичном числе, падают. Одно и то же правило применяется к нашему собственному провайдеру, у которого слабая первичная полоса сегодня: он падает с 84 на 77 и падает на несколько позиций. Развёрнуто всё равно — оценка, которая награждает реальную инженерию, даже чужую и даже за наш счёт, это единственный вид оценки, стоящей публикации.
v4.7 (2026-07-31) — Список поставщиков перестал зависеть от одного индекса, а оценка перестала штрафовать наши собственные пробелы в данных. (1) Список теперь строится из зарегистрированного в блокчейне набора голосующих и заполняется там, где сторонний индекс упускает сущности: 98 поставщиков против 80 ранее показываемых, поэтому 18 реальных поставщиков, которые были невидимы в поиске и недоступны для делегирования отсюда, теперь появляются. (2) «Активный» означал «имеет ставку вознаграждения из этого индекса», что обнуляло размеры Fee (15) и V2 (15) для каждого заполняемого поставщика даже когда наши собственные данные FSP показывали, что они выплачивают каждую эпоху; теперь это принимает доказательство распределения. (3) Отсутствующая ставка вознаграждения больше не оценивается в 0 против полного знаменателя — вес в 25 пункты остаётся вне знаменателя, поэтому поставщик оценивается по тому, что мы измерили, а не штрафуется за то, что мы не могли измерить. (4) Размер Fee по-прежнему оценивался по кривой до FIP-16, где комиссия 0% получала полный балл. FIP-16 делает минимальную комиссию сущности 20% и все 98 поставщиков взимают ровно эту сумму, поэтому размер присваивал 4,00/15 всему полю без вариации — 11 пунктов, которые никто не мог заработать, стоимостью около 4,3 пунктов от каждой опубликованной оценки включая наивысшую. Fee теперь привязана к max(самая низкая наблюдаемая комиссия, порог протокола), точно так же как страница валидатора привязывает её с момента вилки Granite: взимание законного минимума получает полный балл, и штрафуются только комиссии ВЫШЕ, по расстоянию. Это повышает каждую оценку на аналогичную сумму и не изменяет ранжирование. Поставщики с опубликованной ставкой не затронуты изменениями (1)–(3). Ставка вознаграждения не оценивается и не выводится: эти строки читают «Нет данных». (5) Ставка вознаграждения больше не зависит от одного индекса. Она читалась только из Flaremetrics, поэтому поставщик, которого этот индекс прекратил освещать, терял свой Net и Gross APR и оценивался в 0/25 по Reward Rate — штраф в 25 пунктов за чьё-то другое упущение в охвате. Flare Systems Explorer публикует то же число и охватывает больше сущностей, поэтому теперь заполняет любой пробел; прямая ставка Flaremetrics никогда не перезаписывается. В день выпуска это восстановило опубликованную ставку для 15 поставщиков, которые её не имели.
v4.6 (2026-07-01) — Consistency исправлена для новых узлов. Это было mean/stddev ставки вознаграждения по всей 30-эпохной истории, поэтому раздутая первая эпоха заработка нового узла (малый вес голоса → высокая ставка за единицу, которая затем нормализуется) выступала выбросом, который фиксировал CV высоко — оценка 0 — на месяцы, пока она не устарела. Теперь используется скользящее окно (последние 12 эпох заработка) и надёжное разложение median/MAD, так что эпоха разгона — безвредный выброс, а подлинная постоянная волатильность всё ещё получает низкую оценку.
v4.5 (2026-06-30) — Self-Bond сделан независимым от размера. Кривая только по коэффициенту могла оценить большое абсолютное самообязательство при низком коэффициенте НИЖЕ малого самообязательства при высоком коэффициенте. Self-Bond теперь кредитует большее из коэффициента выравнивания или насыщающегося абсолютного количества (ограничено 5M FLR), поэтому крупный обязанный оператор и полностью выровненный малый оператор получают полные баллы — награждает обязательство, не богатство, и качество валидатора остаётся в других измерениях.
v4.4 (2026-06-30) — Два реальных исправления ошибок. (1) Self-Bond был МЁРТВЫМ измерением: он читал поле Flaremetrics, которое API отбросил, поэтому каждый провайдер получал 0/7. Переподключено к истинному самообязательству P-Chain узла оператора (перекрёстная ссылка из набора валидаторов по nodeID). (2) Compliance перестала штрафовать эпохи до активации провайдера — новый узел, зарабатывающий чистым образом с момента запуска, ранее был обвинён в каждой эпохе, которая ему предшествовала, что удерживало его на 0/10 в течение недель. Пропущенные эпохи теперь считаются только в пределах активного окна каждого провайдера.
v4.3 (2026-06-03) — Уточнение методологии, без изменений математики скоринга. Измерение Accuracy теперь явно определяется как внутри-цепочечный вторичный диапазонный коэффициент попадания (качество цены — какая доля отправленных цен попадает в допустимый диапазон), отличное от измерения Compliance, которое подсчитывает пропущенные эпохи вознаграждения (участие FSP). Эта страница и подсказки таблицы валидаторов были переписаны, чтобы сделать различие явным, и колонка Compliance была добавлена рядом с Accuracy. Оба измерения сохраняют свои предыдущие веса (25 и 10) и входные данные (fseAccuracySecondary и epochsWithoutRewards).
v4.2 (2026-05-20) — Измерение Rewards Distributed отремонтировано. Оно было подключено к полю распределения вознаграждений Flaremetrics, которое API v3 провайдера отбросил, поэтому измерение читало 0 для каждого провайдера и ничего не вносило. Переподключено к внутри-цепочечным итогам делегирования вознаграждений FSP — те же данные претензий на вознаграждение, которые уже агрегирует измерение Compliance — так что измерение снова дифференцирует.
v4.1 (2026-05-20) — Измерение Compliance зафиксировано. epochsWithoutRewards мог приходить отрицательным, поскольку cron вознаграждений FSP накапливал свой счёт присутствия эпохи за пределы скользящего окна, что позволяло Compliance превышать его максимум 10 точек (наблюдалось до ~58) и толкало композит за его максимум — насыщая примерно 70% провайдеров на плоский 100. Compliance теперь зафиксирован на его весе, и cron FSP пересчитывает резюме вознаграждений без состояния по окну, поэтому счёт больше не может дрейфовать.
v4.0 (2026-05-11) — Полный проход аудита справедливости, эквивалентный выпуску v4.0 оценки валидатора. Два реальных исправления ошибок: (1) Delegator Count имел извращённый стимул на 500 — до исправления бакет 500 делегаторов возвращал 14 пт, но крышка >500 возвращала базовый WEIGHT_DELEGATORS (12), поэтому получение делегатора через эту границу ТЕРЯЛО 2 точки. Теперь логарифмическая шкала от 5 → 500, монотонное возрастание. (2) Уровни V2 Participation были свёрнуты — частичная регистрация V1 и полная V2 (Scaling + FastUpdates + FDC) обе возвращали 15, поэтому обновление с частичной на полную V2 обеспечивало нулевое улучшение оценки. Теперь стекирование по протоколам (активный +3, V1 +4, каждый протокол V2 +~2,67). Граничные скалы исключены в Accuracy (был скал на 7 пт при 97%), Stability и Self-Bond Ratio — все линеаризованы со значениями сохранены на границах бакета. Кривая Reward Rate перебалансирована, так что медиана = половина очков измерения (было 40%). Согласованы устаревшие строки документации измерений с фактическими значениями весов. Чистый эффект: каждое измерение монотонно возрастает на оси входного значения, и ни один провайдер не может понизить свою оценку FlareWatch, улучшив реальную операционную метрику.
v3 (2026-05-09 → 2026-05-11) — 13-мерный скоринг с динамическим перераспределением весов и штрафом разбавления мощности голоса. MIRROR Participation введён как первоклассное измерение (12 базовых + до +3 бонуса переперформанса с байесовским сжатием и шлюзом накопления данных на 30 дней). Identity и Self-Bond добавлены как отдельные измерения. Reward Rate переместился на медиану-ориентированный. Accuracy использует вторичную метрику FSE для высокоразрешающегося диапазона. Consistency использует CV по недавним эпохам.
v2 и более ранние — Версии до v3 не документированы здесь; они использовали более простой подмножество измерений и предшествовали динамическому перераспределению весов. Версии отменены в пользу текущей модели.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.