Методология оценки валидаторов

Версия алгоритма: v4.8 · Последнее обновление: 2026-08-19

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

Область применения: эта страница документирует оценку валидатора — то, что вы видите в режиме staking на странице валидаторов (делегирование FLR валидатору P-Chain за награды VRM + MIRROR). Оценка поставщика FTSO, показанная в режиме delegation (делегирование WFLR поставщикам данных FTSO), использует отдельный 13-мерный алгоритм, ориентированный на производительность поставщика данных — точность, участие в протоколе V2 и т.д. Это различные роли в сети с отдельными наградами, оцениваемые отдельно. См. Методология оценки поставщика FTSO для стороны делегирования.

Нет эквивалента SGB: эта оценка применяется только к валидаторам P-Chain Flare. Набор валидаторов P-Chain Songbird ограничен утвёрждёнными Flare Foundation сущностями, поэтому делегирование розничных SGB P-Chain редко и вкладка staking только для FLR. В режиме staking нет переключателя FLR / SGB. Для делегирования SGB FTSO см. Методология оценки поставщика FTSO, которая охватывает обе цепи.

Как мы вычисляем APY — ваш реальный доход

APY в таблице стейкинга — это реальная ставка, которую получает делегатор — одна цифра, без ментальной математики. Это измеряется по скриптам вознаграждений Flare (фактические выплаты, не формула), за вычетом комиссии валидатора, и она меняется каждый эпох с реальными вознаграждениями. Везде на FlareWatch APY означает после комиссии и APY означает до комиссии.

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)

Награды за стейкинг (VRM) — чистая доля делегатора в наградах за валидацию = Σ выплата делегатору ÷ Σ делегировано (собственное распределение Flare; комиссия уже вычтена). Поскольку Flare платит пропорционально стейку, это примерно одинаково по всей сети и отличается в основном по комиссии — более низкая комиссия означает более высокий уровень делегирования.
MIRROR — доля вашего стейка в инфляции FTSO, выплачиваемая дополнительно, только на валидаторах с активным стеком FTSO. Она варьируется в зависимости от участия валидатора в FTSO и рассчитывается за последние эпохи.

Сравнение с Flare Systems Explorer? FSE и другие обозреватели показывают только ставку делегирования — они не добавляют MIRROR — поэтому наш Total APY читается выше на любом MIRROR-активном валидаторе (разница точно равна строке MIRROR выше). Обе цифры — это ~8-эпох усредняющие значения из одних и тех же данных скриптов вознаграждений, поэтому изменение комиссии валидатора в середине окна отстает от снимка текущей комиссии на обоих сайтах, пока оно не пройдет через окно.

Две другие цифры появляются в подсказке APY и не являются ставкой делегатора: теоретический базовый уровень (валовой APY сети × (1 − комиссия), только стейкинг — используется как резерв перед достаточной измеренной историей), и доход от самозалога оператора (возврат собственного залога валидатора, усиленный захватом комиссии — метрика оператора, а не то, что вы зарабатываете).

Для оценки: измерение Net Yield оценивает только ставку делегирования VRM, и MIRROR оценивается в своем собственном измерении — поэтому MIRROR никогда не учитывается дважды, даже если он включен в отображаемый Total APY.

Группы оценок

90+	Верхний уровень — верхние ~10–20% операторов. Типичный профиль: полнофункциональный валидатор + FTSO + FDC, низкая комиссия, активный MIRROR, постоянная надёжность FIP-10, здоровая база делегаторов, значительное собственное связывание. Ни одно измерение не требуется — операторы достигают верхнего уровня, накапливая силу по большинству категорий.
80–89	Сильный — соответствует большинству ключевых критериев; одно или два измерения ниже верхнего уровня.
70–79	Хороший — соответствует всем базовым критериям; нет серьёзных пробелов.
60–69	Приемлемый — пригоден, но не дифференцирован.
<60	Ниже среднего — значительные пробелы в одном или нескольких измерениях. Математический факт, не суждение о качестве.

Измерения (сумма 100)

Бесперебойность20 макс пт

Что: Комбинация мгновенной доступности P-Chain RPC И исторического коэффициента приемлемости доступности FIP-10 на недавних эпохах вознаграждений.

Как: RPC кривая: ≥ 99,5% → 17–20. 99–99,5% → 13–17. 95–99% → 4–13. 90–95% → 0–4. < 90% → 0. Результат затем умножается на uptimeReliability (epochsIncluded / epochsObserved за последние 8 эпох награды из публичных данных reward-scripts — полный набор минимумов FIP-10 с версии v4.2, не только RPC-uptime). v3.9 исправила порог в точности 95%, где переход от 94,99 → 95,00 uptime приводил к потере 4 пунктов.

if (uptime >= 99.5)   raw = 17 + (uptime - 99.5) * 6
else if (uptime >= 99) raw = 13 + (uptime - 99)   * 8
else if (uptime >= 95) raw = 4 + (uptime - 95) * 2.25    // v3.9: was (u - 95) * 3.25 starting at 0
else                   raw = max(0, uptime - 90) * 0.8   // 90 → 0, 95 → 4 (continuity)
raw = clamp(raw, 0, 20)

reliability = epochsIncluded / epochsObserved   // last ~8 epochs · v4.2: the
                                                // FULL FIP-10 minimums set
                                                // (uptime + FSP + FTSO + FDC),
                                                // not RPC-uptime alone

score = raw * clamp(reliability, 0, 1)                 // dimension max 20

Почему: До v3.4 это измерение было в основном неживым — 92,9% активных валидаторов имеют 100% RPC доступность, поэтому кривая оценивала всех одинаково. Коэффициент надёжности — это реальный сигнал временного ряда: валидатор, который не соответствовал минимальным условиям FIP-10 в 3 из 8 недавних эпох, имеет 62,5% оценку надёжности, независимо от того, что сообщает мгновенный RPC. Строже, чем протокольный уровень 80% FIP-10 специально. Данные приемлемости по эпохам публикуются Flare Foundation в их репозитории скриптов вознаграждений.

Чистая доходность18 макс пт

Что: Чистая ставка вознаграждения за стейкинг (VRM), которую получает делегатор, привязанная к медиане сети.

Как: scoreAPR = измеренный чистый уровень ДЕЛЕГИРОВАНИЯ (delegationAPY: Σ delegatorRewardAmount / Σ делегировано, из скриптов вознаграждений Flare Foundation, последние ~8 эпох), если доступно, иначе теоретический baseAPR = валовой × (1 − комиссия). Оценка = (scoreAPR / medianAPR) привязано: отношение 0,6 → 0 пт, 1,0 (медиана) → 12 пт, 1,2 → 18 пт. ВАЖНО: это измерение оценивает ТОЛЬКО уровень VRM (награды за валидацию) — MIRROR оценивается отдельно в измерении MIRROR Participation, поэтому здесь он не учитывается дважды. Отображаемый 'Total APR' (VRM + MIRROR) — это число, ориентированное на делегатора, а не вход Net Yield.

scoreAPR = delegationAPY > 0 ? delegationAPY : baseAPR   // VRM, net of fee
medianAPR = median(scoreAPR across all validators)
cappedAPR = min(scoreAPR, 25)                  // APY_DISPLAY_CAP

if (medianAPR > 0):
  ratio = cappedAPR / medianAPR
  score = clamp(((ratio - 0.6) / 0.6) * 18, 0, 18)
else:
  score = min(18, (cappedAPR / 8) * 18)        // fallback: BASE_APY = 8

Почему: Обе стороны отношения — это ЧИСТЫЙ уровень делегирования (измеренный delegationAPY в сравнении с теоретическим валовым×(1−комиссия)), поэтому сравнение — как для подобных — больше не раздувается на 1/(1−комиссия), как это было, когда входом была предварительная валовая ставка (приблизительно в 2× 'дублирование' баг). Поскольку Flare платит награды за валидацию пропорционально стейку, уровень делегирования VRM примерно одинаков по всей сети и варьируется в основном по комиссии — поэтому это измерение в основном отражает конкурентоспособность комиссии и надёжность доставки (валидатор, который пропускает эпохи, доставляет меньше). MIRROR (который варьируется в зависимости от участия FTSO) специально находится в собственном измерении, чтобы избежать двойного учёта.

Разумность комиссии7 макс пт

Что: Защита от извлечения выше минимального комиссионного сбора протокола, плавный кусочно-линейный.

Как: Якорь = max(наблюдаемая минимальная активная комиссия, минимальная комиссия валидатора протокола — 20% с момента хардфорка Granite, 2026-07-14). Любая комиссия на уровне якоря или ниже → полные 7 баллов. Выше — линейный рост с всё более крутыми склонами на следующих 20 пунктах комиссии (якорь+5 → 6, якорь+10 → 4,5, якорь+15 → 2,5, якорь+20 → 0): небольшие превышения штрафуются слабо, извлечение наказывается жёстко. До Granite якорь был абсолютным 5%; ограничение минимума означает, что ни один оператор никогда не будет наказан за взимание законного минимума.

// anchor = max(observed minimum active fee, 20% protocol floor)
d = fee - anchor                                  // distance above market best
if (d <= 0)       score = 7                       // at/below best available
else if (d <= 5)  score = 7   - d * 0.2           //  0 → 5 over: 7 → 6
else if (d <= 10) score = 6   - (d - 5)  * 0.3    //  5 → 10 over: 6 → 4.5
else if (d <= 15) score = 4.5 - (d - 10) * 0.4    // 10 → 15 over: 4.5 → 2.5
else if (d <= 20) score = 2.5 - (d - 15) * 0.5    // 15 → 20 over: 2.5 → 0
else              score = 0
// fees > anchor+20 saturate at 0/7 — the v4.5 extreme-fee
// penalty below takes over from there

Почему: Net Yield уже учитывает комиссию за процент в доставленных условиях; это измерение только отмечает операторов, взимающих существенно выше того, что разрешают протокол и рынок. Как только все комиссии будут на обязательном уровне 20%, все получат полные баллы здесь и это измерение перестанет различать — по замыслу: число, которое никто не может занизить, не может дифференцировать кого-либо.

Качество оператора12 макс пт

Что: Принимает наибольший из двух независимых сигналов: базовая линия проверки (уверенность в личности) и производительность, полученная из FTSO.

Как: Базовая линия проверки: кураторский уровень (+7) достигается двумя способами — запись KNOWN_VALIDATORS с ручной проверкой ИЛИ автоматическое повышение благодаря объективному поведению (v3.10: 90+ дней наблюдаемых И 25+ агрегированных делегаторов оператора И в настоящее время не сокращаются И собственное связывание ≥ минимум FIP-10). Автоматически обнаруженное имя из Flaremetrics или FSE → +3. Непроверенный → 0. На основе FTSO: линейная интерполяция оценка FTSO 50 → 4 пт до оценки FTSO 100 → 12 пт (ниже 50 ограничено на 4). Финальная оценка — max(проверка, на основе FTSO) — участие в FTSO может только помочь, никогда не навредить.

// Verification baseline (v3.10 hybrid)
isCurated = (in KNOWN_VALIDATORS) OR (
  daysObserved >= 90 AND
  operatorDelegatorCount >= 25 AND
  retention30d >= -15% AND
  selfBondFLR >= 1_000_000
)

if (isCurated)                       verification = 7
else if (name auto-discovered)      verification = 3
else                                verification = 0

// FTSO-derived (only when ftsoOperatorScore is a number)
clamped = clamp(ftsoOperatorScore, 50, 100)
ftsoDerived = 4 + (clamped - 50) * (8/50)   // FTSO 50 → 4, FTSO 100 → 12

// Final score
score = max(verification, ftsoDerived)

Почему: Вознаграждает операторов, запускающих полный стек (валидатор + FTSO + FDC) без штрафования доверенных операторов за участие в FTSO со средней оценкой. Логика max() в v3.8 явно предотвращает извращённый стимул «отказаться от FTSO, чтобы улучшить оценку FlareWatch». Автоматически обнаруженный уровень (+3) закрывает предыдущий cliff 7→0, который поражал операторов, зарегистрированных в Flaremetrics или FSE, но ещё не прошедших ручную курацию.

Участие в MIRROR12 макс пт

Что: Доставляет ли nodeID валидатора фактически долю инфляции FTSO стейкерам — как долю, которая достигает делегаторов (прохождение комиссии), так и, с версии 4.6, доставленную сумму относительно поля.

Как: Active → 10 × (1 − fee/100). Paused → 5 × passthrough. Inactive (нет сигнала участия нигде) → 0. No data (действительно ненаблюдаемый валидатор) → 5 × passthrough. v3.6 расширил сигнал 'active' на оба типа: и события RewardClaimed(claimType=3) на цепи И распределения claimType=3 в каноническом JSON FSP Merkle — достаточно одного. Это ловит валидаторы, у которых MIRROR было распределено, но еще не заявлено на цепи (например, провайдеры с самоделегированием, чей путь расчета не запускает стандартное событие заявления). v4.6 бонус за величину (макс +2, потолок измерения 12): только для зеркально-активных валидаторов, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2) — кредит за доставку выше-медианной ставки MIRROR (за вычетом комиссии) делегаторам. Привязано к сетевой медианной ставке, поэтому это нейтрально по размеру: малый валидатор, доставляющий высокую ставку, получает такой же кредит, как и крупный.

passthrough = max(0, 1 - fee / 100)

if (mirrorStatus == "active")    base = 10 * passthrough
else if (mirrorStatus == "paused")   base = 5 * passthrough
else if (mirrorStatus == "inactive") base = 0
else                                 base = 5 * passthrough  // no data yet

// v4.6 — capped, median-anchored bonus for delivered MIRROR yield.
// Only mirror-active validators paying ABOVE 1.2x the network median
// delivered rate (mirrorAPY, net of fee) earn it; size-neutral.
ratio = mirrorAPY / networkMedianMirrorAPY
bonus = clamp((ratio - 1.2) * 5, 0, 2)   // active only, else 0
score = base + bonus                     // dimension max 12

Почему: MIRROR распределяется автоматически стейкерам на валидаторах с участием FSP. Валидатор со 100% комиссией, который 'active', доставляет $0 делегаторам; оценка отражает то, что делегаторы действительно получают, а не просто статус флага на уровне протокола. Бонус v4.6 за величину закрывает слепое пятно: прохождение комиссии одно измеряло ДОЛЮ, достигающую делегаторов, но не СУММУ, поэтому валидатор, платящий намного более высокую доставленную ставку MIRROR, не получал за это никакого дополнительного кредита. Теперь получает — ограниченно, и только выше сетевой медианы.

Профиль ёмкости7 макс пт

Что: Функция палатки, достигающая пика при оптимальном использовании.

Как: 0% utilized → 1.75. Линейный подъём до 7 при 70% utilized. Линейный спад до 5.25 при 100% (capped). Пересчитано в v3.7 с 8 → 7 для финансирования новых компонентов траектории Trust.

utilization = clamp(1 - freeSpaceFLR / maxDelegationFLR, 0, 1)

if (utilization <= 0.70):
  score = 1.75 + (utilization / 0.70) * 5.25     // 1.75 → 7 ramp
else:
  score = 7 - ((utilization - 0.70) / 0.30) * 1.75 // 7 → 5.25 ramp

Почему: Нахождение на максимальных делегированиях FIP-10 — ПОЛОЖИТЕЛЬНЫЙ сигнал привлекательности — доказано доверено достаточным количеством делегаторов, чтобы заполнить. v2 оценивал capped валидаторов 0/5; v3 исправляет это. Правильный размер (доказано привлекательно И есть место) получает пик. v3.7 обрезал лимит измерения 8 → 7, чтобы освобождённый пункт мог финансировать новые компоненты траектории Trust для retention и self-bond.

Доверие сообщества11 макс пт

Что: Множественные сигналы: количество делегаторов + здоровье распределения стейка + долголетие + обязательство оператора через self-bond (доля и абсолютный размер) + 30-дневное удержание + траектория self-bond + агрегация мультиузловых операторов.

Как: Сигнал количества (макс 6, OPERATOR-AGGREGATED v3.7): логарифмическая шкала [5, 500] делегаторов → [0, 6], суммировано по всем известным узлам оператора. Корректировка концентрации (±1): retail-дружественный средний стейк (<500K FLR) → +1, whale-концентрированный (>50M FLR средний) → −1. Бонус долголетия (макс +1, wipe-immune v3.6): +0.5 при 30 днях наблюдения, +1 при 90+ днях — откатывается на epoch presence в скриптах вознаграждения если первое KV было стёрто. Skin-in-the-game self-bond (макс +2 / мин −1, TWO-AXIS v4.7): учитывается по ЛУЧШЕМУ из доли ИЛИ абсолютного размера — доля ≥10% → +2 / 5–10% → +1, и абсолютный = min(1, selfBond ÷ 20M) × 2 насыщающийся при top-decile bond сети; сигнал берёт max из двух, ограничено до +2. Ниже FIP-10 минимума (<1M FLR) → −1. Удержание (макс ±0.5, NEW v3.7): делегированный FLR +10% за 30 дней → +0.5, −15% → −0.5. Траектория self-bond (макс ±0.5, NEW v3.7): self-bond оператора +20% за 30 дней → +0.5, −10% → −0.5.

// Count signal (max 6)
if (delegatorCount <= 5)        countScore = 0
else if (delegatorCount >= 500) countScore = 6
else  countScore = clamp(log(delegatorCount / 5) / log(100) * 6, 0, 6)

// Concentration adjustment (-1 to +1) — skip if <3 delegators
avgFLR = delegatedFLR / delegatorCount
if (avgFLR < 500_000)        concentrationAdj = +1
else if (avgFLR < 5_000_000)   concentrationAdj = +0.5
else if (avgFLR > 50_000_000)  concentrationAdj = -1
else if (avgFLR > 20_000_000)  concentrationAdj = -0.5
else                           concentrationAdj = 0

// Longevity bonus (0 to +1)
daysObserved = (now - firstObservedAtMs) / 86400000
if (daysObserved >= 90)      longevityBonus = +1
else if (daysObserved >= 30) longevityBonus = +0.5
else                         longevityBonus = 0

// Self-bond alignment (-1 to +2, two-axis since v4.7)
if (selfBondFLR < 1_000_000)   selfBondAdj = -1              // hollow-operator floor
else:
  ratio        = selfBondFLR / totalStake                   // totalStake = selfBond + delegated
  proportional = ratio >= 0.10 ? +2 : ratio >= 0.05 ? +1 : 0
  absolute     = min(1, selfBondFLR / 20_000_000) * 2        // saturates at top-decile bond
  selfBondAdj  = max(proportional, absolute)                 // the better of the two axes

// Retention (-0.5 to +0.5, v3.7) — skip if no 30-day baseline yet
delta = (delegatedFLR - delegatedFLR30dAgo) / delegatedFLR30dAgo
if (delta >= +0.10)      retentionAdj = +0.5
else if (delta <= -0.15) retentionAdj = -0.5
else                     retentionAdj = 0

// Self-bond trajectory (-0.5 to +0.5, v3.7) — skip if no baseline
sbDelta = (selfBondFLR - selfBondFLR30dAgo) / selfBondFLR30dAgo
if (sbDelta >= +0.20)      selfBondTrajectoryAdj = +0.5
else if (sbDelta <= -0.10) selfBondTrajectoryAdj = -0.5
else                       selfBondTrajectoryAdj = 0

score = clamp(countScore + concentrationAdj + longevityBonus + selfBondAdj
            + retentionAdj + selfBondTrajectoryAdj, 0, 11)

Почему: Skin-in-the-game self-bond — это реальный сигнал справедливости, который нам не хватало — валидатор с 10% общего стейка в качестве self-bond имеет значительно более согласованные интересы, чем работающий на минимуме FIP-10. v4.7 делает это двухосевым: рассмотрение self-bond только как доли наказывало операторов, которые вложили большую абсолютную ставку и затем привлекли делегирование, что разбавило долю без снижения реального обязательства — 20M self-bond при разбавленной доле оценивался так же как sub-2M bond при такой доле. Сигнал теперь учитывает ЛУЧШЕЕ из доли или абсолютного размера, абсолютная сторона насыщается при top-of-network bond так что размер не может просто купить оценку, совпадая с тем, как FTSO provider score уже трактует self-bond; cap +2 неизменен, поэтому крупные обязанные операторы теперь могут его достичь но потолок не поднялся. Долголетие награждает доказанную историю без штрафования новичков (малый бонус сверху, не штраф снизу). Концентрационный риск имеет значение для делегаторов — валидатор с 1 whale при 50M FLR структурно отличается от 50 retail при 1M каждый. Два сигнала траектории v3.7 награждают органический рост и растущее обязательство оператора. Общий cap 11 (повышен с 10 в v3.7 для их финансирования), ни один сигнал не доминирует.

Надёжность доставки10 макс пт

Что: Отношение фактически доставленного чистого коэффициента делегирования (VRM) к теоретическому базовому значению с штрафом дисперсии за несогласованные выплаты. Обе стороны чистые от комиссии, поэтому отношение измеряет реальную доставку — не комиссию.

Как: Кусочно-линейное отношение доставки: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → линейный спад к 0. Variance penalty: coefficient of variation × 0.5, capped at −30%. Confidence dampener смешивает к нейтральной 5, когда sample size < 3 epochs. v3.9 линеаризовал ранее bucketed thresholds — boundary cliffs до 2 пунктов теперь гладкие.

// Time-weighted rate is computed upstream from per-epoch
// reward-scripts data with decay = 0.85 per epoch back.
r = deliveryRatio   // capped at 1.0

if (r >= 1.00)      base = 10
else if (r >= 0.97) base = 9  + (r - 0.97) * (1 / 0.03)   // 0.97 → 9, 1.00 → 10
else if (r >= 0.95) base = 8  + (r - 0.95) * (1 / 0.02)   // 0.95 → 8, 0.97 → 9
else if (r >= 0.90) base = 6  + (r - 0.90) * (2 / 0.05)   // 0.90 → 6, 0.95 → 8
else if (r >= 0.85) base = 4  + (r - 0.85) * (2 / 0.05)   // 0.85 → 4, 0.90 → 6
else if (r >= 0.80) base = 2  + (r - 0.80) * (2 / 0.05)   // 0.80 → 2, 0.85 → 4
else                base = max(0, r * 2.5)                 // 0 → 0, 0.80 → 2

// Variance penalty (CoV = std-dev / mean across per-epoch rates)
variancePenalty = min(0.30, coefficientOfVariation * 0.5)
score = base * (1 - variancePenalty)

// Sample-size confidence dampener for < 3 epochs
if (totalStakesCompleted < 3):
  confidence = totalStakesCompleted / 3
  score = 5 + (score - 5) * confidence

Почему: Обещано vs. доставлено — самый прямой сигнал ответственности для держателей. v3.3 добавил два уточнения: (1) основное отношение использует экспоненциально времени-взвешенное среднее (недавние epochs считаются больше), поэтому валидатор, который раньше доставлял хорошо, но недавно упал, правильно наказан; (2) penalty дисперсии различает consistent 95% deliverers от oscillating-around-95% deliverers, так как последние несут больше риска для держателей, заботящихся о предсказуемой доходности.

Оставшееся время5 макс пт

Что: Дней до конца stake валидатора на P-Chain.

Как: < 14 дней → 0 (по сути недоступно под FIP-10). 14-30d → линейный 0→2. 30-60d → линейный 2→3. 60-120d → линейный 3→5. 120d+ → 5. v3.9 линеаризовал ранее bucketed thresholds — boundary cliffs (например 13.99d → 0, 14d → 2) теперь гладкие.

daysLeft = (endTimeMs - now) / 86_400_000

if (daysLeft < 14)       score = 0
else if (daysLeft < 30)  score = 0 + (daysLeft - 14) * (2 / 16)    // 14 → 0, 30 → 2
else if (daysLeft < 60)  score = 2 + (daysLeft - 30) * (1 / 30)    // 30 → 2, 60 → 3
else if (daysLeft < 120) score = 3 + (daysLeft - 60) * (2 / 60)    // 60 → 3, 120 → 5
else                     score = 5

Почему: Практический сигнал — делегирование валидатору с 7 днями осталось — это другое предложение, чем 1 год. v3.2 затянул дно: валидаторы в течение 14 дней до конца stake не могут принять новые делегирования (минимальная блокировка FIP-10 — 14 дней), поэтому они фактически unstakeable. Score = 0 отличает 'unstakeable прямо сейчас' от 'выветривается вскоре'.

Штраф активного отключения (v4.3)(вычет) макс пт

Что: Плоский вычет, наложенный поверх положительных измерений, когда валидатор пропускает несколько reward epochs подряд. Отличается от симметричного multiplier Uptime reliability — захватывает активные отключения, а не хроническую ненадёжность.

Как: Посмотрите на contiguous !eligible prefix валидатора в записи cache:fsp-validator-participation (список epochs newest-first из public reward-scripts nodes-data.json). 0–1 consecutive misses → 0 pts (в пределах дисперсии / одиночный transient miss). 2 consecutive → −3 pts (развивающееся отключение). 3 consecutive → −6 pts (sustained — невнимательность оператора). 4+ consecutive → −10 pts (active extended outage). Composite score floored at 0 после вычета.

consecutiveMisses = 0
for entry in participation.recent (newest-first):
  if entry.eligible: break
  consecutiveMisses++

if consecutiveMisses < 2:  penalty = 0
elif consecutiveMisses == 2: penalty = 3
elif consecutiveMisses == 3: penalty = 6
else:                        penalty = 10                  // 4+

score = max(0, positiveDimensionsSum - penalty)

Почему: Pre-v4.3 модель полагалась полностью на symmetric uptimeReliability multiplier — 5 scattered misses за 24 epochs стоят столько же, сколько 5 misses подряд. Операционно это очень разные сигналы. Scattered misses сообщают делегаторам о хронической ненадёжности; streak сообщает им, что валидатор СЛОМАН ПРЯМО СЕЙЧАС. Инцидент Luganodes 2026-05-14 — несколько consecutive missed epochs пока делегаторы активно коммитили миллионы FLR — был конкретным случаем, который рассматривает релиз v4.3: поверхностный сигнал active-outage с более острым воздействием на оценку, чтобы делегаторы могли избежать in-flight failure перед коммитом. Tiered curve избегает overreacting на single transient misses (обычные) пока резко flagging sustained streaks (редкие и consequential).

Штраф за экстремальный размер комиссии (v4.5)(до −75% оценки) макс пт

Что: Пропорциональное снижение за комиссии, выходящие за пределы диапазона размерности Fee. Размерность Fee достигает минимума 0/7 при превышении якоря на 20 пунктов — после этого композитная оценка перестала реагировать на комиссию полностью, поэтому валидатор со 100%-комиссией (его делегаторы ничего не получают) всё ещё мог иметь оценку в 40+ баллов по размерностям, независимым от комиссии, таким как анвтайм и MIRROR.

Как: Нулевое значение при комиссии 50% или ниже — размерность Fee уже учитывает этот диапазон, поэтому двойного учёта нет. Выше 50% вычет растёт линейно с размером комиссии, достигая 75% положительной оценки валидатора при 100%-комиссии. Масштабируется самой оценкой, так что опрятный приватный ноэд и запущенный оказываются на своих местах: в низу рейтинга, видимого делегаторам.

// v4.5 — fees beyond the Fee dimension's range (anchor+20)
if fee <= 50:  penalty = 0
else:          fraction = min(1, (fee - 50) / 50) * 0.75
               penalty  = positiveDimensionsSum * fraction

// fee 50% → no change · 75% → −37.5% of score · 100% → −75%
score = max(0, positiveDimensionsSum - outagePenalty - penalty)

Почему: Это оценка для делегаторов. Валидатор, который присваивает себе каждое вознаграждение, заработанное его делегаторами, не является кандидатом на делегирование, несмотря на хороший анвтайм — оценка должна это ясно указать. Чистая функция от on-chain комиссии, применяемая одинаково ко всем нодам, включая нашу.

Как набрать 100/100 — руководство валидатора

Цикл аудита, который произвёл v4.0, был специально разработан так, чтобы максимизация каждого измерения действительно делала вас лучшим валидатором для ваших делегаторов. Улучшение вашей оценки — это не gaming система — это система, работающая как предусмотрено. Вот явное руководство, по измерению.

Uptime — 20 пт. Поддерживайте ≥99.5% RPC uptime непрерывно И пройдите минимальные условия FIP-10 в каждом reward epoch (не пропускайте reveals, попадите в median delivery). Два сигнала перемножаются — 100% RPC × 7/8 epochs eligible = 17.5/20, не 20. Почему это соответствует делегаторам: каждый epoch, когда вы не пройдёте FIP-10, ваши делегаторы теряют их награды за этот epoch.

Net Yield — 18 пт. Доставляйте ≥1,2× медианный APY сети вашим делегаторам (после комиссии). Лучший путь: низкая комиссия + полное соответствие FIP-10, чтобы делегаторы получали свою полную долю. Почему это выравнивается: это буквально сумма денег, поступающая делегатору после вашего вычета.

Разумность комиссии — 7 баллов. С момента хардфорка Granite протокол обеспечивает минимальную комиссию делегирования 20%, и любая комиссия на уровне якоря оценки (максимум из наблюдаемого рыночного минимума и этого минимума) получает полные 7 баллов. Взимание выше этого стоит баллов на ускоряющемся графике — якорь+10 → 4,5 баллов, якорь+20 → 0. Почему это согласуется: минимум убил конкуренцию по комиссиям, поэтому это измерение теперь только защищает делегатов от извлечения выше законного минимума; ваше истинное преимущество заключается в доставленной Net Yield.

Качество оператора — 12 пт. Лучший путь: зарегистрируйтесь как поставщик данных FTSO и запустите высокое качество stack (FTSO + FDC + signing) — ваша оценка FlareWatch Operator Quality затем берётся из вашей FTSO оценки, с max на FTSO 100. Альтернатива, если вы только staking: поддерживайте baseline верификации +7 либо квалифицируясь для v3.10 auto-promotion (90+ дней наблюдения, 25+ делегаторов, retention не снижается, FIP-10-compliant self-bond), либо будучи добавленным в KNOWN_VALIDATORS как institutional infrastructure (manual fast-track). Оценка принимает max(verification, FTSO-derived) — участие никогда не навредит. Почему это соответствует: full-stack операторы предоставляют больше экосистемной ценности; baseline верификации даёт делегаторам более ясный сигнал идентичности.

Участие в MIRROR — 10 пт. Последовательно отправляйте FSP price feeds, соответствуйте per-epoch protocol minimums (зарегистрированы в вашей signing policy, claim threshold met, нет reveal misses). Взимайте умеренную комиссию — оценка перемножена на (1 − fee/100), поэтому даже идеально MIRROR-active валидатор со 100%-комиссией набирает 0, потому что нулевой MIRROR достигает делегаторов. Почему это соответствует: MIRROR — доля вашего делегатора в инфляции FTSO. Более низкая комиссия = больше достигает их.

Профиль ёмкости — 7 пт. Целевое ~70% utilization (правильный размер: доказано привлекательно И есть место для новых делегаторов). Empty валидаторы набирают 1.75; capped валидаторы набирают 5.25. Почему это соответствует: новые делегаторы, читающие оценку, хотят знать, что они действительно могут делегировать; правильный размер сигнализирует как social proof, так и доступность.

Доверие сообщества — 11 пт. Шесть компонентов для максимизации:

Постройте до 500+ operator-aggregated делегаторов (max count signal: +6 пт).
Поддерживайте retail-friendly avg stake < 500K FLR за делегатора (concentration bonus: +1).
Оставайтесь в сети ≥ 90 дней для longevity bonus (+1) — wipe-immune через reward-scripts presence.
Держите большой self-bond — либо ≥ 10% по доле ИЛИ top-of-network абсолютную ставку (~20M FLR), что даст лучший результат (бонус за согласование: +2).
Растите total delegated FLR на ≥ 10% за 30 дней (retention: +0.5).
Увеличьте self-bond на ≥ 20% за 30 дней (траектория: +0.5).

Почему это согласуется: каждый компонент вознаграждает поведение, которое хотят делегаторы — наличие инвестиций оператора, органический рост, долговечность, широкое участие сообщества. Операторы с несколькими узлами агрегированы для сигналов подсчета и концентрации (v3.7).

Надежность доставки — 10 баллов. Выплачивайте делегаторам то, что обещает ваш прогнозируемый APY (коэффициент доставки 1.00). Минимизируйте дисперсию за эпоху — предсказуемые выплаты лучше той же средней с высоким разбросом (штраф за дисперсию до −30%). Соберите выборку из 8+ эпох для полной уверенности в взвешивании. Почему это согласуется: вы выполняете обещание, которое дали, последовательно? Это самый прямой сигнал подотчетности.

Оставшееся время — 5 баллов. Держите дату окончания stake ≥ 120 дней. Продлевайте задолго до истечения; не позволяйте ей скатиться в полосу < 14 дней (согласно FIP-10 вы не можете принимать новые делегирования, если находитесь в пределах 14 дней). Почему это согласуется: более длительное обязательство сигнализирует делегаторам, что вы здесь надолго.

Временные сигналы, которые нельзя обойти: бонус за долговечность (наблюдается 90 дней), уровень автокурирования (90 дней + 25 делегаторов + без снижения удержания + FIP-10 self-bond), сигнал удержания (30 дней истории делегирования), размер выборки доставки (8 эпох вознаграждения). Хорошая новость: поддержание других поведений автоматически накапливает эти сигналы со временем.

Окно сглаживания имеет значение в краткосрочной перспективе: отображаемый балл — это экспоненциально взвешенное среднее последних 4 снимков cron (0.5 / 0.3 / 0.15 / 0.05), поэтому даже идеальные 100 на входах требуют ~20 минут последовательного идеального выполнения cron для полного отражения. Идеальные входы в стационарном состоянии = 100; переходные улучшения сглаживаются. Штрафы за внезапные изменения (скачки комиссий, падение self-bond, сбой uptime) также могут снизить балл на 10 баллов в течение нескольких циклов cron после обнаружения.

Вкратце: каждое измерение честно о том, что оно измеряет. Если ваш валидатор на уровне 100/100, балл также говорит вашим делегаторам, что они получают лучшую версию валидатора в сети — именно такова цель дизайна.

Как проверить ваш собственный балл

Каждый балл в таблице валидаторов воспроизводим из открытых данных. Если вы оператор и математика здесь не совпадает с баллом, который вы видите, правильный ход — проверить это самостоятельно, прежде чем предполагать, что мы допустили ошибку.

Самая быстрая проверка работает автоматически. Раскройте строку балла любого валидатора, и панель "Verified in your browser" пересчитает этот балл локально — точную ту же функцию подсчета баллов, которую использует cron, с точными входными данными, которые он использовал, без обратного вызова к нашему серверу. Поскольку каждый валидатор оценивается одной идентичной функцией, которая не содержит термина для идентичности узла, это также то, как каждый может подтвердить, что наш собственный узел не получает скрытого преимущества. Пошаговое руководство ниже делает то же самое вручную:

Посмотрите публичную статистику вашего валидатора на flaremetrics.io (найдите по имени оператора или вставьте адрес делегирования). Обратите внимание на delegationFee, selfBond, delegatedStake и FTSO score (если вы также поставщик данных).
Проверьте вашу приемлемость FIP-10 за каждую из последних 8 эпох вознаграждения на github.com/flare-foundation/reward-scripts в разделе generated-files/reward-epoch-N/nodes-data.json. Посчитайте, сколько эпох ваш nodeID имел uptimeEligible: true. Это отношение определяет множитель вашего измерения Uptime.
Проверьте вашу MIRROR participation в контракте V2 RewardManager через flare-explorer.flare.network. Ищите события RewardClaimed с claimType=3, ссылающиеся на ваш nodeID. Если таких недавно, вы будете показаны как MIRROR-inactive.
Подставьте ваши входные данные в формулы выше. Блок кода каждого измерения точно говорит вам, какую арифметику выполнить. Суммируйте измерения, ограничьте до 100, и вы получите ваш вычисленный cron балл.
Сравните с вашим отображаемым баллом. Отображаемый балл включает экспоненциальное скользящее среднее v3.5 за последние 4 снимка cron (текущий взвешен 0.5, предыдущий 0.3 и т.д.) — поэтому балл, вычисленный за один прогон, будет немного отличаться от отображаемого. Панель разбора баллов в каждой строке валидатора показывает сохраненные значения измерений, которые внесли свой вклад.
Если математика не совпадает, отправьте письмо на [email protected] с вашим nodeID, входными данными, которые вы использовали, и баллом, который вы вычислили. Мы ответим, и если мы допустили ошибку, мы исправим ее публично.

Программный доступ: для любого активного валидатора обратитесь к GET /api/validators/{nodeID}/score-breakdown, чтобы получить сохраненный разбор — значение каждого измерения, версию алгоритма, которая его произвела, и недавнюю историю баллов — в формате JSON. Панель разбора баллов в пользовательском интерфейсе считывает из того же источника.

Общие опасения операторов

Я на 100% RPC uptime — почему мой балл Uptime ниже 20/20?

Размерность Uptime умножает выход RPC-кривой на ваше отношение доступности эпох (epochsIncluded / epochsObserved за последние 8 эпох награды — полный набор минимумов FIP-10 с версии v4.2, не только RPC-uptime). Если вы не выполнили минимальные условия FIP-10 в любой из этих эпох — даже кратковременно — ваш коэффициент надёжности падает ниже 1,0 и ваш балл Uptime масштабируется пропорционально. До версии v3.4 размерность выставляла 20 баллов каждому валидатору со 100% RPC-uptime независимо от исторической доступности. Теперь она дифференцирует.

Я поставляю MIRROR — почему FlareWatch показывает меня как MIRROR-inactive?

Начиная с v3.6, участие MIRROR обнаруживается из двух канонических источников: on-chain RewardClaimed(claimType=3) события в V2 RewardManager и allocations claimType=3 в официальном FSP Merkle JSON (опубликованные данные распределения вознаграждений). NodeID, появляющийся в любом источнике, считается активным. До v3.6 мы использовали on-chain поток как единственный сигнал, который давал ложные отрицания для самодделегирующихся провайдеров, чей MIRROR рассчитывается через нестандартный путь требования. Также исправлено в v3.6: ошибка формата ключа, при которой ~95 валидаторов имели записи mirror-stats, написанные под hex20 (bytes20 форма nodeID) on-chain индексером, когда они еще не находились в нашем отобранном списке имен — в то время как каждый UI lookup ключифицировал cb58 NodeID. Те записи существовали и были правильными; они просто не были видны слою отображения. Lookup теперь нормализует оба формата во всех потребителях (таблица валидаторов, панель разбора баллов, публичный API mirror-stats, карта Staking Positions на странице Yield, панель FTSO providers). Если ваш nodeID все еще показывает inactive после v3.6 sweep, возможные причины: (a) ваш nodeID фактически не зарегистрирован в вашей FSP signing policy для той эпохи, (b) мы находимся между публикациями эпох (Merkle данные обновляются за эпоху, ~3.5 дней). Отправьте нам письмо с вашим nodeID и мы перепроверим оба канонических источника.

Мой балл упал на 10 баллов за ночь — что изменилось?

Одно из трех: (1) обнаружение внезапных изменений v3.5 отметило скачок комиссии, падение self-bond или сбой uptime на вашем nodeID — штраф в 10 баллов применяется при запуске обнаружения и затухает в течение следующих 3 запусков, когда новое состояние стабилизируется; (2) окно сглаживания включило более старый снимок, который снизил ваше среднее; (3) мы выпустили обновление версии алгоритма (видно в поле algorithmVersion вашей записи — см. карту Versions ниже). Панель разбора баллов показывает текущие значения измерений; сравните с предыдущими запусками.

Почему валидатор с высокой комиссией получает более низкий балл, чем валидатор с низкой комиссией и всем остальным одинаковым?

Измерение Net Yield (максимум 18 баллов) чувствительно к комиссиям — валидатор с комиссией 0% доставляет примерно 1,25× медианный APY сети, набирая близко к максимуму; валидатор с комиссией 20% доставляет примерно 80% медианы, набирая меньше. Плюс Fee Reasonableness (7 баллов) с версии 3.9 линеен по частям (без бакетов): ≤5% получает все 7 баллов, затем кривая спадает с усиливающимся градиентом — 10% → 6, 15% → 4,5, 20% → 2,5, 25%+ → 0 (например, комиссия 16% набирает ~4,1, а не фиксированное значение бакета). Таким образом, разница в 5 пунктов комиссии переводится в ~5-8 пунктов разницы оценки. Это намеренно — делегаторы напрямую заботятся о комиссии.

Я совершенно новый валидатор без FTSO score. Почему мое Operator Quality только 7/12?

Operator Quality (макс 12 баллов) вознаграждает операторов full-stack — валидаторов, которые также запускают top FTSO data-provider stack (FTSO + FDC + signing). Если вы только staking, базовое значение +7 достижимо двумя способами: (1) ручное включение в наш список KNOWN_VALIDATORS — institutional fast-track для надежных операторов инфраструктуры (Ankr, InfStones, Kiln и т.д.); (2) v3.10 auto-promotion на основе объективного поведения — 90+ дней наблюдаются AND 25+ оператор-агрегированных делегаторов AND удержание не снижается AND FIP-10-compliant self-bond. Auto-promotion полностью автоматический, письмо не требуется. Если вы еще не соответствуете критериям auto-promotion, вы начинаете с +3 (auto-discovered tier, требует профиль сущности на Flaremetrics или FSE) и растете в +7 по мере того, как ваш track record строится. Для ускорения: зарегистрируйтесь как FTSO data provider и запустите V2 протоколы — ваш балл затем приходит из FTSO-derived ветви с максимумом 12 при FTSO 100. v3.8: участие FTSO может только помочь, никогда не навредить — если ваш FTSO score ниже baseline проверки, вы сохраняете baseline.

У меня есть логотип, но мое имя отображается как усеченный NodeID. Почему?

Ваша сущность оператора существует в Flaremetrics (именно поэтому у нас есть логотип для вас), но ваш профиль провайдера не имеет установленного поля 'name'. Мы не выдумываем имена. Установите ваш profile.name на Flaremetrics или в реестре сущностей Flare Systems Explorer, и мы подберем его при следующем запуске cron. Или отправьте нам письмо с проверяемым заявлением (напр., подписанное сообщение с вашего адреса делегирования) и мы добавим вас в KNOWN_VALIDATORS вручную.

Мой валидатор находится на максимальном FIP-10 делегировании. Почему Capacity не набирает 7/7?

Capacity — это палаточная функция с пиком на 70% утилизации (7 баллов), спускающаяся на 5.25 баллов при 100%. Пик не 100% — быть на-cap означает, что делегаторы не могут добавить больше stake, даже если захотят, что является нейтральным или слегка отрицательным сигналом для новых делегаторов, читающих таблицу. До v3 мы оценивали capped валидаторов 0/5 (штраф за успех); v3 исправил это на нейтральное значение при-cap, и v3.7 переформатировал всю размерность с 8 → 7 макс (освободив точку для сигналов Trust траектории), поэтому сегодня capped набирает 5.25/7. Правильно размещенные валидаторы (проверенно привлекательные И с местом для роста, пик на 70% утилизации) получают полные 7.

Я реальный оператор, но я вообще не в списке валидаторов. Что это?

Список валидаторов построен из live P-Chain RPC's getCurrentValidators результата. Если вас там нет, вы либо не активны на P-Chain, ваш stake только что истек, либо на нашей стороне есть проблема с P-Chain RPC. Cron запускается каждые 5 минут — вы должны появиться в течение 1-2 циклов после активации вашей stake. Если вы live более часа и все еще не видите себя, отправьте нам письмо с вашим nodeID.

Могу ли я подать апелляцию по моему баллу или запросить ручное рассмотрение?

Да. Отправьте письмо на [email protected] с вашим nodeID и конкретным опасением. Мы отвечаем каждому оператору. Вещи, которые мы будем предпринимать: добавления KNOWN_VALIDATORS, исправления MIRROR-классификации, исправления логотипа/имена, ошибки математики измерения. Вещи, которые мы не будем предпринимать: запросы вручную повысить балл за пределы алгоритма, запросы исключить или de-rank конкурента.

Что мы будем и не будем делать

Чтобы устранить неоднозначность о том, как мы работаем с баллом, вот явные обязательства. Если мы когда-либо нарушим одно из этих, задокументируйте это и отправьте письмо на [email protected] — мы исправим это публично.

✓

Мы не будем принимать платежи за более высокие баллы, спонсируемое размещение или благоприятное отношение любого рода. Балл вычисляется детерминированно из открытых данных цепи.

✓

Мы не будем вручную кодировать per-validator bumps. Нет никакой линии "X получает +5, потому что нам нравится" в коде. Один и тот же алгоритм применяется к каждому валидатору, включая собственный узел FlareWatch, который оценивается этой точной функцией.

✓

Мы не будем исключать валидаторы из таблицы по неофициальным причинам. Список берётся из живого P-Chain RPC, и наш интерфейс показывает каждый активный валидатор. Проверенные добавления в KNOWN_VALIDATORS только заполняют отображаемые имена — они не ограничивают видимость.

✓

Мы будем публиковать изменения алгоритма. Каждое обновление версии (v3 → v3.1 → v3.2 → ...) документируется в карточке Versions на этой странице с объяснением причин и изменений. Крупные изменения также добавляются в changelog, доступный на странице changelog приложения.

✓

Мы будем отвечать на письма операторов. Каждый оператор, отправивший письмо на [email protected] с конкретными вопросами о своём рейтинге, получит реальный ответ в течение нескольких рабочих дней.

✓

Мы будем публично исправлять наши ошибки. Если мы обнаружим ошибку в алгоритме, ошибку источника данных или пробел в методологии, мы выпустим исправление и задокументируем его. Мы не переранжируем молча.

✗

Мы не будем публично делиться содержимым писем без разрешения отправителя, а также не будем использовать письма операторов ни для чего, кроме обсуждения рейтинга, которое их вызвало.

✗

Мы не будем делиться своими планами по изменению алгоритма с отдельными операторами заранее — каждая версия выходит для всех одновременно.

Ограничения — что этот рейтинг показывает и что нет

Композитный рейтинг — полезная сводка, а не объективная истина. Наш рейтинг прозрачен, версионирован, применяется одинаково ко всем валидаторам — включая наши собственные — и может быть воспроизведён из опубликованных данных прямо в вашем браузере. Но он всё равно отражает редакторское мнение, и мы предпочитаем показать вам точно, где оно проявляется, а не выдавать видимость точности, которой метод не обеспечивает.

Весовые коэффициенты измерений — это наше мнение. Безотказность оценена в 20 баллов, а комиссия в 7 баллов, потому что мы решили, что надёжность важнее большинству делегаторов, чем несколько пунктов комиссии — не потому, что это доказала какая-то формула. Разумные люди могли бы весить эти факторы иначе. Коэффициенты зафиксированы и открыты, так что вы видите точно, что мы выбрали, и можете мысленно пересчитать их на основе распределения.

Чистая доходность — это результат, а не достоинство. Она измеряет, что делегатор действительно зарабатывает, привязываясь к медиане сети — так что она частично формируется факторами вне контроля оператора (сетевая инфляция, объём привлеченной делегации) и движется вместе с остальным полем. Дисциплинированный оператор с честной, но более высокой комиссией может набрать меньше баллов здесь, оставаясь отличным. Читайте это как «сколько я бы заработал», а не «насколько хорош этот оператор».

Измерения, связанные с FTSO, благоприятствуют полнофункциональным операторам. MIRROR Participation и часть Operator Quality вознаграждают валидаторов, которые также запускают полный стек FTSO-провайдера данных. Это намеренно — как делегатор вы действительно зарабатываете больше через MIRROR от валидатора, активного в FTSO — но это означает, что чистый, превосходный валидатор только для стейкинга не может достичь самой вершины этого рейтинга. Если вы используете стейкинг исключительно по выбору, снизьте для себя вес этих измерений.

Модель аддитивна. Измерения складываются, поэтому сильная сторона может компенсировать слабость — превосходная безотказность может привести более высокую комиссию к приемлемому рейтингу. Действительно дисквалифицирующие отказы (невыполнение минимумов FIP-10, хищнические комиссии) учитываются отдельно, поэтому их нельзя полностью замаскировать — валидатор, не выполняющий минимумы каждый период или берущий 100% комиссию, попадает в конец рейтинга независимо от других измерений — но суть — это взвешенная сумма, а не система вето.

Одно число скрывает девять суждений. Единственное число от 0 до 100 — это отправная точка, а не вердикт. Два валидатора, отличающихся на один пункт, не отличаются значимо. Откройте распределение и взвесьте измерения, которые важны лично вам — число существует, чтобы сделать это сравнение быстрее, а не заменить его.

Мы меняем метод редко и публично. Каждое изменение выпускается с номером версии, письменным обоснованием и полевым сравнением до и после, чтобы вы могли проверить, что изменилось и почему. Когда наш собственный автоматизированный аудит обнаруживает расхождение в наших цифрах — а это происходит — мы исправляем это и об этом сообщаем.

Итоговый рейтинг (как объединяются измерения)

Все 9 измерений суммируются напрямую, затем вычитается штраф v4.3 за активные перебои. Итого ограничивается максимум 100 и минимум 0. Затем применяется сглаживание по недавним снимкам cron (v3.5) и любые штрафы за резкие изменения к финальному числу.

// Step 1 — Raw composite (sum of dimensions, minus the two penalties)
positive = uptime + netYield + fee + operatorQuality
         + mirror + capacity + trust + delivery + timeRemaining

// Penalties (see the two penalty cards above):
// v4.3 active-outage streak — 0-1 missed epochs → 0, 2 → 3, 3 → 6, 4+ → 10
// v4.5 extreme fee (>50%)   — positive × min(1, (fee - 50) / 50) × 0.75
raw = clamp(positive - streakPenalty - extremeFeePenalty, 0, 100)

// Step 2 — Smooth across recent cron snapshots (v3.5)
// Weights: current 0.5, prev1 0.3, prev2 0.15, prev3 0.05
smoothed = 0.5*raw + 0.3*prev1 + 0.15*prev2 + 0.05*prev3

// Step 3 — Apply sudden-change penalty if flagged this run
// Triggers: fee +50% or +5pt jump, self-bond -20% drop, uptime -5% crash
// Magnitude: -10 pts on detection, decays -7, -4, -1 over 3 runs
suddenPenalty = -10 if any flag triggered else (decaying remainder)

// Step 4 — Final score
score = clamp(smoothed + suddenPenalty, 0, 100)

Источники данных (каждый входной параметр открыт)

Flare P-Chain RPC: список валидаторов, uptime, собственный залог, делегированный стейк, комиссия, время окончания, количество делегаторов.

V2 RewardManager (события claimType=3): на цепи заявленное распределение MIRROR на валидатор nodeID. Строго отфильтровано по типу 3 — без смешивания с VRM, делегированием FTSO или DIRECT вознаграждениями.

FSP Merkle JSON (выделения claimType=3): канонический опубликованный реестр того, кто получит MIRROR за эпоху (те же данные, что читает инструмент подписания Flare). Добавлено в v3.6 как второй авторитетный источник — отлавливает валидаторов, у которых MIRROR выделен, но ещё не заявлен на цепи.

Flare Systems Explorer (FSE): реестр сущностей валидаторов, отображаемые имена, логотипы, флаги участия в протоколе FTSO V2.

Данные провайдера Flaremetrics: FTSO рейтинг, ставка вознаграждения, точность, функции V2, связь сущность-nodeID.

Flare reward-scripts (GitHub): доставленный APY на валидатор для последних N эпох вознаграждений. Определяет измерение Delivery.

Курирование FlareWatch: карта KNOWN_VALIDATORS (~110 записей). Имена + базовая оценка операторского качества для надёжных операторов инфраструктуры.

Что НЕ входит в рейтинг

• Саморекламирование или платные размещения. Ни один оператор не может заплатить или спонсировать более высокий рейтинг.

• Ручные коды специфичные для валидаторов. Нет строк типа «X получает +5, потому что он нам нравится» в коде. Один и тот же алгоритм применяется ко всем валидаторам, включая собственный узел FlareWatch, который оценивается по этой же функции.

• Субъективное качество инфраструктуры. Мы не пытаемся оценивать SLA аптайма, географическое распределение или характеристики оборудования. Если вы хотите претендовать на инфраструктурный уровень, запустите top FTSO + FDC стек, и измерение Operator Quality это отразит.

• Блокировки или обязательства перед FlareWatch. Никакого благоприятного рейтинга для стейкеров, использующих FlareWatch вместо другого инструмента.

Обратная связь оператора

Заметили что-то странное в рейтинге вашего валидатора? Отправьте письмо на [email protected] с вашим NodeID и вопросом. Мы отвечаем каждому оператору. Типичные запросы, на которые мы реагируем:

Добавление вашего оператора в KNOWN_VALIDATORS (с проверкой).
Пересмотр вашей классификации как неактивного MIRROR, если вы считаете это ошибкой.
Исправления логотипа / отображаемого имени.
Общая критика алгоритма.

Источники и ссылки

Каждый вход в рейтинг поступает из открытых, проверяемых источников экосистемы Flare. Любой может перепроверить наши утверждения в этих первичных источниках и воспроизвести математику из исходных данных. Если вы обнаружили расхождение между этой страницей и тем, что говорят вышестоящие источники, отправьте письмо на [email protected], и мы это исправим.

Документация протокола Flare Network ↗https://docs.flare.network

Авторитетная документация протокола. Охватывает FTSO V2, FSP, валидацию P-Chain, FAssets и остальную сеть Flare.

Портал управления Flare (FIP) ↗https://proposals.flare.network

Flare Improvement Proposals — источник истины для FIP-05 (фактор делегирования), FIP-10 (минимальные условия валидатора: минимум 1M FLR собственного залога, 80% аптайма, минимум 14 дней блокировки) и всех других правил, упомянутых на этой странице.

Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network

Официальный реестр Flare провайдеров FTSO данных, адреса сущностей, связи P-Chain nodeID и флаги минимальных условий FIP-10. Первичный источник для наших данных по Operator Quality и надёжности.

Flaremetrics ↗https://flaremetrics.io

Независимый провайдер метрик экосистемы Flare. Источник оценки провайдеров FTSO, ставок вознаграждения, метрик точности, флагов участия в протоколе V2 и маппингов валидатор-адрес сущности. Мы потребляем их открытый REST API.

Репозиторий reward-scripts Flare Foundation ↗https://github.com/flare-foundation/reward-scripts

JSON по каждой эпохе вознаграждения, опубликованный Flare Foundation, показывающий адекватность каждого валидатора, адекватность аптайма и доставленные вознаграждения. Определяет измерение Delivery Reliability и отношение epoch-eligibility v3.4 для Uptime.

Flare Block Explorer ↗https://flare-explorer.flare.network

Доступный только для чтения браузер всех состояний в блокчейне. Позволяет любому пользователю проверить события RewardClaimed в V2 RewardManager (claimType=3 для MIRROR), общие объемы ставок валидаторов, изменения комиссий и прочее.

Flare Portal (staking) ↗https://portal.flare.network/staking

Официальный интерфейс для стейкинга. Авторитетный источник для текущих объемов собственной ставки / делегированной ставки и времени окончания валидаторов, которые используются в считываниях P-Chain RPC.

Flaremetrics public API (FTSO providers) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200

Точная конечная точка, которую использует наш крон, возвращающая профили сущностей, оценки FTSO, комиссии и nodeIds в шестнадцатеричном формате. Любой может обращаться к ней напрямую.

Flaremetrics public API (node registrations) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500

Таблица преобразования Hex → cb58 NodeID. Мы используем пагинацию для построения таблицы сопоставления сущность-NodeID, которая управляет каждым потребителем в формате cb58.

Без приватных данных, без закрытых моделей. Алгоритм оценки реализован в services/validators/scoring.ts в исходном коде FlareWatch. Операторы или исследователи, которые хотят проверить реализацию напрямую (вместо чтения текста и формул выше) или которые хотят создать форк для своего использования, могут отправить письмо на [email protected] для запроса доступа. Мы опубликуем файл как отдельный пакет с открытым исходным кодом, если будет реальный спрос.

Как обновляются оценки

Крон по адресу /api/cron/refresh-validators пересчитывает оценку каждого активного валидатора каждые 5 минут. Входные данные (считывания P-Chain RPC, Flaremetrics, FSE, reward-scripts) загружаются заново при каждом запуске.

В версии 3.5 добавлено сглаживание по последним 4 снимкам крона (веса: 0.5 / 0.3 / 0.15 / 0.05), поэтому отображаемая оценка не скачет из-за преходящих ошибок входных данных. Исходная оценка, вычисленная кроном, по-прежнему сохраняется для будущей математики сглаживания, а панель разбора оценки показывает текущее значение каждого измерения, чтобы вы могли видеть, что изменилось.

Версия алгоритма ставится на каждую кэшированную запись оценки. Когда мы выпускаем новую версию, каждая оценка получает новый тег. Карточка Версии ниже документирует каждое изменение.

Модель штрафов Flare

Flare не урезает ставку валидатора. Весь механизм штрафов за неправильное поведение валидатора — это конфискация вознаграждения плюс система проходов FIP-10. Нет штрафа за двойную подпись, нет штрафа за эквивокацию, нет события разрушения ставки, которое нам нужно отслеживать. Валидаторы, которые не соответствуют минимальным условиям FIP-10, теряют награды этой эпохи (полная конфискация при нулевых проходах, иначе теряют один проход за каждый протокол, который они не соответствовали); их основная ставка остается нетронутой.

Это означает, что оценка не имеет размерности «история штрафов» — нет такой истории для отслеживания. Что мы ОТСЛЕЖИВАЕМ — это последствие каждого минимального сбоя: валидатор заработал ноль в этой эпохе, что отражено в epochsIncluded / epochsObserved. Обновление версии 4.2 от 14.05.2026 расширило множитель надежности оценки, чтобы использовать это отношение по полному набору минимумов FIP-10 (аптайм, подписание FSP, частота отправки FTSO, участие FDC), поэтому валидатор, который не соответствует любому минимуму, пропорционально штрафуется в измерении Аптайм независимо от того, какая ось сбоя.

Пороги минимумов FIP-10, взятые из dev.flare.network/network/fsp/rewarding: стейкинг требует 80% аптайма + 1M FLR активной собственной ставки; каналы якоря FTSO требуют оценок в пределах 0.5% медианы консенсуса в 80% раундов; каналы задержки блоков FTSO требуют отправки 80% ожидаемых обновлений; FDC требует участия в 60% раундов голосования. Валидаторы, соответствующие полу 80% аптайма + 1M собственной ставки, но ниже порогов 3M / 15M заработков, все еще получают награды, но не могут накапливать пассы — серая зона, выявленная через классификацию passEligibility: "at-risk" этой карточки.

Версии

v4.8 (2026-09-17) — Периоды вознаграждений аннуализированы по их реальной длительности. Каждая измеренная ставка валидатора (доставленный APR, делегирование, MIRROR, доход собственного бонда оператора) была аннуализирована с периодом вознаграждения 3,19 дня, значение, добавленное 2026-04-04 и описанное как измеренное из временных меток блоков, хотя ничто его не измеряло. Периоды вознаграждений Flare составляют ровно 3,5 дня — rewardEpochDurationSeconds FlareSystemsManager возвращает 302 400, и каждый старт эпохи на цепи находится на расстоянии 3,500 дня друг от друга — поэтому каждая измеренная ставка читалась примерно на 9,7% выше в течение пяти с половиной месяцев, включая нашу собственную. Длительность теперь считывается из этого контракта. Каждый измеренный APR падает на одинаковый коэффициент, 3,19 ÷ 3,5 (сетевая медиана 9,08% → 8,28%; FlareWatch 8,17% → 7,45%). Оценки: движется только Delivery Reliability, так как она сравнивает измеренную ставку с теоретической ставкой для комиссии валидатора. Завышенная сторона поместила 91% валидаторов на лимит 1,0, то есть, по-видимому, платя больше, чем возможно; с реальной длительностью эпохи медианное отношение доставленного к теоретическому составляет 0,990. Смоделировано на 168 валидаторах с измеренными данными перед отправкой: медиана −0,32 пункта, 146 теряют менее 1 пункта, 13 уже доставляют ниже подразумеваемой их комиссией ставки, теряют 2–3,5. Резервный вариант долголетия Community Trust преобразует эпохи в дни с той же длительностью и также исправлен; он не движет оценку, потому что видит максимум 8 эпох (28 дней), ниже его шага в 30 дней в любом случае. Подписанные аттестации производительности использовали ту же неправильную длительность; спецификация пересчета пересмотрена на rev.3, а rev.2 сохранена без изменений с раскрытой ошибкой.

v4.7 (2026-08-19) — Двухосевый self-bond в измерении Community Trust. Trust учитывал self-bond оператора только как ДОЛЮ (own bond ÷ total stake), поэтому крупный self-bond разбавленный делегированием оценивался так же как крошечный bond при такой доле — оценка не видела фактический вложенный капитал. В сети 61 из 178 валидаторов держали ≥10M self-bond при <10% доле, поэтому треть поля недополучала кредит. v4.7 учитывает self-bond по ЛУЧШЕМУ из доли (≥10% → +2, 5–10% → +1, неизменно) ИЛИ абсолютного размера (min(1, selfBond ÷ 20M) × 2, насыщающийся при top-decile P-chain bond сети), берёт max и остаётся ограничено до +2 на подсигнале — cap Trust (11) и composite cap (100) неизменны, и sub-FIP-10 hollow floor (<1M FLR → −1) неизменен. Зеркалирует двухосевый self-bond который FTSO provider score уже использует. Результаты по сети до/после по всем 178 валидаторам, заархивировано перед запуском: 58 вверх, 0 вниз, ни одна оценка не возросла больше чем на один пункт, и верхушка рейтинга неизменна. Наш узел поднялся на один пункт (83 → 84) по тому же правилу как каждый другой хорошо капитализированный оператор — ни один член формулы нас не называет.

v4.6 (2026-08-13) — бонус за доставленную величину MIRROR. Измерение MIRROR раньше оценивало только прохождение комиссии (долю MIRROR, достигающую делегаторов, = 1 − fee) и статус участия — оно было слепо к доставленной СУММЕ. Валидатор, платящий намного более высокую доставленную ставку MIRROR (mirrorAPY, за вычетом комиссии), чем поле, не получал за это никакого кредита, поэтому ноде с действительно более высоким доходом могла находиться ниже ноды с более низким доходом в измерениях доходности. v4.6 добавляет небольшой, ограниченный, опорный на медиану бонус: только для зеркально-активных валидаторов, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2). Только доставка выше чем в 1,2 раза сетевая медианная ставка зарабатывает её, и максимум +2, поднимая потолок измерения MIRROR с 10 до 12 (составная оценка по-прежнему ограничена 100). Она привязана к сетевой медианной СТАВКЕ, а не объему, поэтому она нейтральна по размеру по построению: по всему живому полю бонус коррелирует ОТРИЦАТЕЛЬНО с собственным залогом (он благоприятствует малым валидаторам с высокими ставками, а не крупным). Анализ всего поля до/после всех активных валидаторов был сохранён перед развертыванием — большинство валидаторов не меняют позицию, и верх рейтинга остается неизменным. Одна и та же формула применяется к каждому валидатору, включая нашу ноду.

v4.5 (2026-07-16) — штраф за экстремальный размер комиссии. Размерность Fee Reasonableness насыщается на 0/7 как только комиссия превышает рыночный якорь + 20 пунктов (~40% после Granite); от этого до комиссии в 100% композит перестал вообще реагировать на комиссию, поэтому валидатор со 100% комиссией — тот, где делегаторы не получают ничего — всё ещё набирал баллы в 40-х на своих независимых от комиссии размерностях. Для обращённого к делегаторам рейтинга такой результат практически дисквалифицирует, а не является результатом середины таблицы. v4.5 добавляет композитный штраф, применяемый как доля от итога положительных размерностей: ноль при комиссии ≤ 50% (без двойного учёта в диапазоне, который уже ценит размерность Fee), затем линейный рост до 75% балла при 100% комиссии. Узел со 100% комиссией получает примерно 10/100 — всё ещё включён и ранжирован, явно не кандидат на делегирование. Это чистая функция от комиссии в блокчейне, одинаковая для каждого валидатора, включая наш собственный узел.

v4.4 (2026-07-11) — якорь комиссии, учитывающий минимум Granite. Хардфорк Granite (Flare, 2026-07-14) обеспечивает минимальную комиссию делегирования валидатора 20%. Якорь разумности комиссии становится max(наблюдаемая минимальная активная комиссия, минимум протокола): каждая комиссия на уровне законного минимума или ниже получает полные баллы, и только комиссии выше него штрафуются по расстоянию. Обоснование: при неуточненной грандфатерской защите текущих ставок якорирование к грандфатерской реликвии 2% (или к докрайовой 0%) привело бы к оценке операторов с соответствующей протоколу комиссией 20% как близких к извлечению — и двойному учёту дельты комиссии, которую Net Yield уже учитывает в доставленных условиях. Никакие другие измерения не изменились. Когда вся когорта достигнет минимума, это измерение будет присуждать полные баллы равномерно — комиссия перестаёт учитываться, как только никто не может конкурировать по ней.

v4.3 (14.05.2026) — Добавлен штраф за активный сбой как фиксированное вычитание после измерения. Существующий множитель uptimeReliability симметричен — 5 рассеянных сбоев на 24 эпохи стоят столько же, сколько 5 сбоев подряд — но операционно это очень разные сигналы: рассеянные сбои означают хроническую нестабильность, серия означает, что валидатор сломан ПРЯМО СЕЙЧАС. v4.3 читает непрерывный ряд неподходящих эпох в начале недавней истории участия валидатора и вычитает 0 пт за 0–1 последовательных сбоев (нормальная вариация / единичный преходящий сбой), 3 пт при 2 (развивающийся сбой), 6 пт при 3 (устойчивый сбой) и 10 пт при 4+ (активный расширенный сбой), с общей суммой ограниченной 0. Наслоено поверх — не заменяет — множитель надежности, так как оба захватывают разные опасности. Триггер: инцидент класса Luganodes от 14.05.2026, когда несколько последних эпох подряд не соответствовали требованиям, пока делегаторы активно поклялись в ставке; сигнал серии позволяет делегаторам увидеть отказ в полете перед поклятием. Штрафы отображаются как собственный раздел на панели разбора оценки, чтобы 9 положительных измерений по-прежнему суммировались до 100.

v4.2 (14.05.2026) — ДВА связанных исправления, выпущенные вместе в ответ на публичное исправление AU (@aucc_official) относительно оценки Luganodes. (1) Вычисление deliveredAPY теперь умножает ставку на эпоху заработков на `epochsIncluded / epochsObserved`, чтобы отображаемый APR отражал ЭФФЕКТИВНУЮ ставку, которую делегатор фактически получает за окно наблюдения — включая нулевые эпохи заработков, когда валидатор не соответствует минимумам FIP-10. Предыдущая реализация усредняла только эпохи заработков и показывала валидаторам их ставку за хорошие эпохи, скрывая сбои минимумов. (2) Множитель надежности измерения Аптайм расширен с только-аптайма (epochsUptimeEligible / epochsObserved) на полный набор минимумов FIP-10 (epochsIncluded / epochsObserved). Валидатор с 100% аптайма RPC, который не соответствует подписанию FSP или частоте отправки FTSO, теперь получает пропорциональный удар по измерению Аптайм независимо от того, какой минимум они не соответствовали. Чистый эффект на Luganodes конкретно: deliveredAPY падает с 10.86% до ~5.43% (совпадает с фактической полупостоянной реальностью), надежность аптайма падает с 1.0 до 0.5, оценка падает существенно. То же исправление применяется к каждому валидатору с `epochsIncluded < epochsObserved` — по сети это выявляет реальные пробелы качества участия, которые были ранее скрыты.

v4.1 (14.05.2026) — Измерение Net Yield переключено с теоретического APR (формула: gross_APR × (1 − fee)) на ИЗМЕРЕННЫЙ deliveredAPY из reward-scripts Flare Foundation, с теоретическим резервным вариантом на валидатор только, когда истории измерений нет. Триггер: снижение инфляции FIP-16 (5% → 3%) вступило в силу 14.05.2026, и знаменатель приемлемой ставки формулы теоретического отклонился от реальности блокчейна так, что теоретический APR недоотчитывал доставленные доходы примерно на 2× по всей сети. Переключение на измеренный первый повторно совмещает входную оценку с тем, что стейкеры действительно получают. Якорь networkMedianAPR также был пересчитан с использованием той же методологии измеренный-первый, поэтому сравнение соотношения остается последовательным с обеих сторон — оценки должны быть приблизительно стабильными (валидатор на сетевой медиане по-прежнему оценивается ~12/18 и т. д.), просто на основе реальных доставленных ставок вместо вывода формулы.

v4.0 (11.05.2026) — Крупная версия. Цикл v3.7-v3.10 кумулятивно составляет структурную переделку системы оценки, достаточно большую, чтобы оправдать скачок. Резюме: две измерения изменили свои крышки (Trust 10→11, Capacity 8→7); формула Operator Quality была переписана как max(verification, FTSO-derived), чтобы участие не могло навредить; четыре оставшихся разбитых на категории измерения (Uptime, Fee, Delivery, Time Remaining) были линеаризованы, чтобы устранить границы обрывов; три новых компонента оценки были добавлены (30-дневное удержание делегирования, 30-дневная траектория собственной ставки, автоматическое повышение до уровня curated); была введена агрегация многоузловых операторов для подсчета Trust + концентрации; долголетие теперь защищено от очистки через присутствие эпохи reward-scripts; и два извращенных стимула были устранены (штраф участия FTSO Operator Quality и обрыв перевернутой буквы V при аптайме 95%). Каждый вход в оценку теперь внешне проверяем — ни одно редакционное решение не несет нагрузки. Валидаторы могут получить исходный уровень +7 curated-оператора через наблюдаемое поведение (90+ дней наблюдается, 25+ делегаторов, удержание не снижается, соответствие FIP-10 self-bond), не требуется письмо команде. см. записи v3.7-v3.10 ниже для подробных изменений, составляющих этот выпуск.

v3.10 (11.05.2026) — Закрыт последний пробел курирования в оценке. Исходный уровень +7 curated-оператор на Operator Quality ранее требовал ручного включения в наш список KNOWN_VALIDATORS, который был единственным значительным редакционным решением после цикла аудита v3.7-v3.9. v3.10 добавляет объективный путь автоматического повышения: любой валидатор с 90+ днями наблюдения FlareWatch, 25+ делегаторами, агрегированными по операторам, удержанием, которое не снижается (30-дневное падение ≤ 15%), и соответствующей FIP-10 собственной ставкой автоматически квалифицируется для исходного уровня +7 — никакого ручного рассмотрения не требуется. KNOWN_VALIDATORS остается быстрым путем для институциональных операторов, которые еще не накопили 90-дневное окно (подумайте о записи Ankr или Kiln в день запуска), но типичный случай теперь полностью автоматизирован. Все четыре критерия получены из блокчейна или близки к блокчейну (количество делегаторов, удержание, собственная ставка) плюс наша собственная метка времени наблюдения — ничего субъективного, нет гейта требования письма команде. Чистый эффект: валидатор может получить уровень +7 через поведение в одиночку. Большинство установленных операторов в сети уже соответствуют критериям сегодня.

v3.9 (11.05.2026) — Очистка границ обрывов по оставшимся четырем разбитым на категории измерениям после аудита каждой части оценки на справедливость. Исправления: (1) извращенный обрыв перевернутой буквы V в кривой Аптайм при 95% — переход с 94.99% → 95.00% аптайма потерял 4 пункта (ветка 95-99% началась с 0 вместо совпадения с максимумом нижней ветки в 4). Такая же форма обратного стимула, который мы только что исправили в Operator Quality (v3.8). (2) Пороги Fee Reasonableness линеаризованы — до v3.9, увеличение комиссии 0.01% через границу ведра могло потерять до 2.5 пункта. Теперь кусочно-линейно с все более крутыми склонами, которые сохраняют значения ведра на границах (низкие комиссии почти не штрафуются, экстрактивные комиссии наказываются жестко). (3) Пороги deliveryRatio измерения Delivery Reliability линеаризованы — тот же паттерн, обрывы до 2 пункта устранены. (4) Пороги ведра Time Remaining линеаризованы — меньшие обрывы (макс 2 пункта на границе 14 дней), но все еще присутствуют в малом измерении; теперь плавно. Net Yield, MIRROR Participation и Capacity Profile прошли аудит и подтверждены как справедливые (уже линейные/непрерывные). Общая крышка неизменна в 100. Нет регрессий оценки по проектированию; единственные валидаторы, чьи оценки движутся — это те, кто оказался точно на предыдущей границе ведра.

v3.8 (11.05.2026) — Измерение Operator Quality проверено и переписано после проверки справедливости. Три исправления выпущены вместе. (1) Устранен извращенный стимул — известный оператор с оценкой FTSO среднего уровня (например, 50) набирал 4 пункта, но тот же оператор, полностью выходящий из FTSO, набирал 7 пункта. В v3.8 оценка составляет max(verification baseline, FTSO-derived), поэтому участие FTSO может только помочь, никогда не повредить. (2) Представлен промежуточный уровень проверки — операторы с автоматически обнаруженными именами из Flaremetrics или FSE (но еще не в куратском списке KNOWN_VALIDATORS) получают +3 вместо 0, смягчая предыдущий обрыв 7→0. (3) Выводит оба сигнала в деталь разбора, когда проверка превосходит низкую оценку FTSO (например, «Curated operator · FTSO 45»), чтобы операторы точно поняли, откуда исходит их оценка. Крышка в 12 пт неизменна; ребалансировка не требуется, потому что изменения только расширяют распределение оценки снизу (вознаграждают частичную проверку), не изменяя верх.

v3.7 (11.05.2026) — Измерение Community Trust проверено и расширено после рассмотрения справедливости операторов. Три дополнения: (1) Агрегация многоузловых операторов — операторы, работающие с несколькими узлами P-Chain (AU, FlareBus, Aureus Ox, Kiln и т. д.), теперь имеют количество делегаторов и общую ставку, агрегированные для сигналов подсчета доверия + концентрации, поэтому они не штрафуются за распределение одной и той же базы делегаторов по нескольким узлам. (2) 30-дневный сигнал удержания делегирования (±0.5 пт) — различает растущих / стабильных / сжимающихся валидаторов с использованием сравнения скользящего окна. Измерение только снимков доверия не могло их различить до v3.7. (3) 30-дневная траектория собственной ставки (±0.5 пт) — вознаграждает операторов, которые увеличивают свою собственную ставку со временем, наказывает тех, кто тихо отвязывается. Отличается от штрафа внезапного изменения, который только ловит одиночные крупные падения. Крышка ребалансирована: Trust 10 → 11, Capacity 8 → 7. Исправления ошибок из аудита: (a) нулевая собственная ставка теперь правильно попадает в штраф sub-FIP-10 (ранее ворота `selfBondFLR > 0` позволяли ровно-0 собственной ставке избежать −1). (b) малые отношения собственной ставки между полом FIP-10 и 5% теперь отображают фактический процент на панели разбора, чтобы операторы видели, что закрывает разрыв к уровням +1 / +2. (c) бонус долголетия теперь защищен от очистки — откатывается на присутствие эпохи reward-scripts, когда первое наблюдение KV искусственно свежее.

v3.6 (11.05.2026) — Два исправления обнаружения MIRROR, выпущенные вместе. (a) Обнаружение теперь читает из двух канонических источников: события RewardClaimed(claimType=3) в блокчейне из V2 RewardManager И распределения claimType=3 в официальном FSP Merkle JSON (те же данные, которые потребляет собственный инструмент подписи Flare). Любой сигнал достаточен — ловит валидаторов, чьи MIRROR были распределены, но еще не требуются в блокчейне. (b) Кросс-проверка против Merkle выявила отдельную ошибку формата ключа: валидаторы:mirror-stats имели смешанные ключи NodeID hex20/cb58 (индексатор блокчейна писал hex, когда валидатор еще не был в нашем куратском списке имен), в то время как каждый потребитель пользовательского интерфейса смотрел только по cb58 — так что статус ~95 валидаторов был невидим для дисплея. Поиск теперь нормализует оба формата по всей таблице валидаторов, панели разбора оценки, открытому API mirror-stats, карточке Staking Positions страницы Yield и панели FTSO providers. Затронутые валидаторы увидели рост своих измерений MIRROR Participation + Operator Quality и общий FlareWatch Score на 9-10 пункта в следующем цикле крона. Обнаружено через отчет FTSO-провайдера (FlareBus, 11.05.2026) — кредит и спасибо. Их обратная связь существенно улучшила представление каждого делегатора о сети, не только их собственные оценки.

v3.5 (09.05.2026) — Net Yield теперь привязан к медиане против сетевого APR (валидатор на медиане оценивается 12/18, лучшие исполнители достигают 18, нижний квартиль падает до 0). Измерение доверия поглотило выравнивание собственной ставки как четвертый компонент (пропорциональная собственная ставка вознаграждает кожу в игре; sub-FIP-10 floor получает небольшой штраф). Новый значок «NEW Xd» выявляет валидаторов, которых FlareWatch наблюдает только <30 дней, чтобы стейкеры видели, когда история записей тонка.

v3.4 (09.05.2026) — Измерение Аптайм теперь смешивает мгновенный аптайм RPC с историческим соотношением приемлемости эпохи FIP-10. До v3.4 измерение было недискриминирующим (92.9% валидаторов имели 100% аптайм RPC). Отношение надежности получено из epochsUptimeEligible / epochsObserved по последним 8 эпохам reward-scripts — сигнал временных рядов, который значимо различает валидаторов, которые иногда не соответствуют условиям минимума FIP-10, от тех, кто не соответствует.

v3.3 (09.05.2026) — Измерение Delivery теперь использует экспоненциально взвешенное по времени среднее значение (недавние эпохи учитываются больше, константа распада 0.85) и применяет штраф дисперсии (коэффициент вариации × 0.5, ограниченный −30%). Вычислено из данных per-epoch reward-scripts — размер выборки переносится как существующий гаситель уверенности.

v3.2 (09.05.2026) — Многосигнальное Community Trust (count + concentration + longevity); отслеживание первого наблюдения от FlareWatch, сохраненное в KV для бонуса долголетия; краевой случай окончания ставки (валидаторы в пределах 14 дней от истечения оценивают 0 по Time Remaining, так как они не могут принимать новые делегирования в соответствии с FIP-10); страница методологии сделана общедоступной; канал обратной связи оператора выявлен; версия алгоритма ставится на каждую кэшированную запись оценки.

v3.1 (09.05.2026) — Соединено измерение Delivery из данных reward-scripts; сглажено Operator Quality (линейная интерполяция), Capacity (функция палатки) и Trust (логарифмическая шкала); переклассифицировано FSP-known + zero claimType=3 как MIRROR «inactive» вместо «no data»; persisted scoreBreakdown на стороне сервера, чтобы клиент не пересчитывал без полных входов.

v3 (09.05.2026) — Заменены бинарные бонусы идентичности на непрерывное Operator Quality. Добавлено MIRROR Participation как отдельное измерение с пропусканием комиссии. Сделана кэппированная емкость нейтральной вместо штрафа 0-пт. Удаленный двойной подсчет APY/fee через Net Yield. Пересчитаны диапазоны (Top tier 90+, Strong/Good/Acceptable/Below median).

v2 (до 09.05.2026) — Исходная оценка с 8 измерениями (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). Прекращена из-за двойного подсчета APY/Fee, бинарного штрафа идентичности, штрафа кэппированной емкости, отсутствия измерения MIRROR. Документирована в исторических целях.