검증자 점수 방법론

알고리즘 버전: v4.8 · 마지막 업데이트: 2026-08-19

FlareWatch는 각 P-Chain 검증자에게 9개 차원에 걸쳐 0–100의 복합 점수를 할당합니다. 계산은 결정론적이고, 입력값은 공개 체인 데이터 [Flare Explorer] [FSE] [Flaremetrics]이며, 동일한 알고리즘이 FlareWatch의 자체 검증자 노드를 포함한 네트워크의 모든 검증자에게 적용됩니다(특별한 처우 없이 정확히 이 함수로 평가됨). 이 페이지는 모든 차원과 임계값을 문서화하여 운영자와 스테이킹 참여자가 점수 계산 방식과 각 값이 선택된 이유를 정확히 알 수 있도록 합니다. 여기의 모든 주장은 기본 온체인 또는 상위 소스로 다시 연결됩니다. 하단의 출처 및 참고자료를 참조하세요.

범위: 이 페이지는 검증자 점수를 문서화합니다. 검증자 페이지의 스테이킹 모드에서 표시되는 항목입니다(VRM + MIRROR 보상을 위해 FLR을 P-Chain 검증자에게 위임). 위임 모드에서 표시되는 FTSO 제공자 점수(WFLR을 FTSO 데이터 제공자에게 위임)는 데이터 제공자 성능(정확도, V2 프로토콜 참여 등)에 중점을 두는 별도의 13차원 알고리즘을 사용합니다. 이들은 서로 다른 온체인 역할이며 별도로 평가됩니다. 위임 측에 대해서는 FTSO 제공자 점수 방법론을 참조하세요.
SGB 동등 항목 없음: 이 평가는 Flare P-Chain 검증자에만 적용됩니다. Songbird의 P-Chain 검증자 집합은 Flare Foundation 승인 기관으로 제한되어 있으므로, 일반 SGB P-Chain 위임은 드물고 스테이킹 탭은 FLR 전용입니다. 스테이킹 모드에는 FLR / SGB 토글이 없습니다. SGB FTSO 위임의 경우 두 체인을 모두 다루는 FTSO 제공자 점수 방법론을 참조하세요.
APY 계산 방법 — 실제로 얻는 수익

스테이킹 테이블의 APY는 위임자가 받는 all-in rate입니다 — 하나의 수치로, 복잡한 계산이 필요 없습니다. 이는 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를 추가하지 않으므로 MIRROR 활성 검증자의 총 APY가 더 높게 표시됩니다(차이는 위의 MIRROR 라인과 정확히 일치합니다). 두 수치 모두 동일한 보상 스크립트 데이터의 약 8에포크 후행 평균이므로, 검증자의 중간 창 수수료 변경은 창을 통해 노화될 때까지 두 사이트의 현재 수수료 스냅샷에 지연됩니다.

APY 툴팁에 나타나는 두 개의 다른 수치는 위임자의 비율이 아닙니다: 이론적 기준선(네트워크 총 APY × (1 − 수수료), 스테이킹만 해당 — 충분한 측정 이력이 존재하기 전의 폴백으로 사용) 및 운영자의 자체 본드 수익률(검증자의 자신의 스테이크 반환, 수수료 포착으로 증대됨 — 운영자 메트릭이며 당신이 얻는 것이 아닙니다).

점수 지정의 경우: 순 수익률 차원은 VRM 위임 비율만 점수를 지정하고 MIRROR는 자신의 차원에서 점수를 지정합니다 — MIRROR가 표시된 총 APY에 포함되어 있더라도 MIRROR는 중복 계산되지 않습니다.

점수 대역
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 (지난 8개 보상 에포크에서 공개 reward-scripts 데이터의 epochsIncluded / epochsObserved, v4.2 이후 전체 FIP-10 최소값 기준, RPC 업타임만이 아님)를 곱합니다. v3.9는 정확히 95%에서의 역설적 절벽을 수정했으며, 여기서 94.99 → 95.00 업타임으로 가면 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 업타임을 가지므로 곡선이 모두에게 동일한 점수를 매겼습니다. 신뢰성 비율은 실제 시계열 신호입니다: 최근 8개 에포크 중 3개에서 FIP-10 최소 조건을 충족하지 못한 검증자는 순간적 RPC가 현재 무엇을 보고하든 상관없이 62.5%의 신뢰성 점수를 가집니다. FIP-10의 80% 프로토콜 바닥보다 의도적으로 더 엄격합니다. 에포크별 적격성 데이터는 Flare Foundation에 의해 보상 스크립트 저장소에 게시됩니다.
순 수익률18 최대 점수
정의: 위임자가 받는 수수료 차감 스테이킹 보상(VRM) 이자율이며, 네트워크 중앙값에 고정됨.
방법: scoreAPR = 측정된 순 위임 이자율(delegationAPY: Σ delegatorRewardAmount / Σ delegated, Flare Foundation 보상 스크립트에서, 최근 약 8 에포크) 또는 이론적 baseAPR = 총 × (1 − 수수료). 점수 = (scoreAPR / medianAPR) 고정: 비율 0.6 → 0 포인트, 1.0(중앙값) → 12 포인트, 1.2 → 18 포인트. 중요: 이 차원은 VRM(검증 보상) 이자율만 점수를 매기며, MIRROR은 MIRROR 참여 차원에서 별도로 평가되므로 여기서 이중 계산되지 않습니다. 표시된 '총 APR'(VRM + MIRROR)은 순 수익률 입력이 아닌 위임자 대상 수치입니다.
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%(2026-07-14)). 앵커 이하의 수수료 → 전체 7점. 이상인 경우, 다음 20포인트 수수료 범위에서 선형 상향곡선(앵커+5 → 6, 앵커+10 → 4.5, 앵커+15 → 2.5, 앵커+20 → 0): 소규모 초과는 거의 페널티 없음, 추출은 심하게 처벌됨. 그래나이트 이전에는 앵커가 절대값 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+ 일 관찰됨 AND 25+ 운영자 집계 위임자 AND 현재 축소 중 아님 AND 자체 자본 ≥ 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에 참여하는 신뢰할 수 있는 운영자에게 페널티를 주지 않습니다. v3.8 max() 로직은 'FTSO를 중단하여 FlareWatch 점수 개선'이라는 역효과적 인센티브를 명시적으로 방지합니다. 자동 발견 티어(+3)는 Flaremetrics 또는 FSE에 등록되었지만 아직 수동으로 선별되지 않은 운영자를 타격하던 이전의 7→0 절벽을 해소합니다.
MIRROR 참여12 최대 점수
정의: 검증자의 nodeID가 실제로 FTSO 인플레이션 공유를 스테이커에게 제공하는지 여부 — 위임자에게 도달하는 비율 (수수료 통과)과 v4.6 이후로는 필드에 상대적인 제공된 양.
방법: 활성 → 10 × (1 − fee/100). 일시 중지 → 5 × passthrough. 비활성 (어디서도 참여 신호 없음) → 0. 데이터 없음 (정말 관찰되지 않은 검증자) → 5 × passthrough. v3.6은 '활성' 신호를 온체인 RewardClaimed(claimType=3) 이벤트와 정규 FSP 머클 JSON의 claimType=3 할당 양쪽을 포함하도록 확대했습니다 — 둘 중 하나로 충분합니다. 이것은 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% 수수료 검증자가 '활성'이어도 위임자에게 $0을 전달합니다. 점수는 프로토콜 측 플래그 상태가 아닌 위임자가 실제로 받는 것을 반영합니다. v4.6 크기 보너스는 맹점을 해소합니다. 통과 비율만으로는 위임자에게 도달하는 비율을 측정했지만 양은 아니었으므로, 훨씬 높은 전달 MIRROR 비율을 지급하는 검증자는 이에 대한 추가 크레딧을 받지 못했습니다. 이제 받습니다 — 제한적이고 네트워크 중앙값 이상일 때만.
용량 프로필7 최대 점수
정의: 최적 활용률에서 피크에 도달하는 텐트 함수.
방법: 0% 활용 → 1.75. 70% 활용까지 선형 상승하여 7에 도달. 100% 활용까지 선형 하강하여 5.25 도달(상한). v3.7에서 새로운 Trust 궤적 컴포넌트 지원을 위해 8 → 7로 재조정.
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는 상한 검증자에 0/5 점수를 부여했습니다; v3는 이를 수정합니다. 최적 크기(입증된 매력 + 여유 공간)가 피크를 받습니다. v3.7은 차원 상한을 8 → 7로 조정하여 해방된 포인트가 Trust의 새로운 유지 + 자가 본딩 궤적 컴포넌트를 지원할 수 있도록 함.
커뮤니티 신뢰11 최대 점수
정의: 다중 신호: 위임자 수 + 스테이크 분산 건전성 + 장수성 + 운영자 셀프 본드 약속(비례 및 절대) + 30일 보유율 + 셀프 본드 궤적 + 다중 노드 운영자 집계.
방법: 카운트 신호 (최대 6, OPERATOR-AGGREGATED v3.7): 로그 스케일 [5, 500] 위임자 → [0, 6], 운영자의 모든 알려진 노드 전체 합산. 농축 조정 (±1): 소매 친화적 평균 스테이크 (<500K FLR) → +1, 고래 농축 (>50M FLR 평균) → −1. 장수성 보너스 (최대 +1, 와이프 면역 v3.6): 30일 관찰 시 +0.5, 90일 이상 +1 — 첫 번째 관찰된 KV가 제거된 경우 보상 스크립트 에포크 존재로 폴백. 셀프 본드 스킨 인 더 게임 (최대 +2 / 최소 −1, TWO-AXIS v4.7): 비례 배분 또는 절대 규모 중 더 나은 쪽으로 반영 — 비례 ≥10% → +2 / 5–10% → +1, 절대 = min(1, selfBond ÷ 20M) × 2, 네트워크 상위 십분위수 본드에서 포화; 신호는 두 신호의 최대값을 취하며, 여전히 +2로 제한. FIP-10 미만 바닥 (<1M FLR) → −1. 보유율 (최대 ±0.5, NEW v3.7): 위임된 FLR 30일 이상 +10% → +0.5, −15% → −0.5. 셀프 본드 궤적 (최대 ±0.5, NEW v3.7): 운영자의 셀프 본드 30일 이상 +20% → +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)
이유: 스킨 인 더 게임 셀프 본드는 우리가 놓친 진정한 공정성 신호입니다. 전체 스테이크의 10%를 셀프 본드로 보유한 검증자는 FIP-10 최소값으로 운영하는 검증자보다 훨씬 더 많은 인센티브 일치를 가집니다. v4.7은 이를 양측으로 만듭니다: 셀프 본드를 비율로만 읽으면 큰 절대 스테이크를 예치한 후 위임을 받은 운영자에게 페널티를 주었습니다. 비율을 희석하지만 실제 약속은 줄이지 않습니다. 희석된 비율의 20M 셀프 본드는 그 비율의 2M 미만 본드와 같은 점수를 받았습니다. 이제 신호는 비례 배분 또는 절대 규모 중 더 나은 쪽을 반영하며, 절대 규모는 네트워크 상단 본드에서 포화되므로 규모가 단순히 점수를 사지 못합니다. 이는 FTSO 제공자 점수가 이미 셀프 본드를 취급하는 방식과 일치하며; +2 상한선은 변경되지 않았으므로 대규모 약속된 운영자는 이제 이에 도달할 수 있지만 한계는 움직이지 않았습니다. 장수성은 입증된 실적을 보상하며 신규 진입자에게 페널티를 주지 않습니다 (상단의 작은 보너스, 아래 페널티 아님). 농축 위험은 위임자에게 중요합니다. 50M FLR의 1마리 고래를 보유한 검증자는 1M씩 50개의 소매와 구조적으로 다릅니다. 두 개의 v3.7 궤적 신호는 유기적 성장과 운영자 약속 증가에 보상을 줍니다. 합성 상한선은 11입니다 (자금을 지원하기 위해 v3.7의 10에서 상향), 단일 신호가 지배하지 않습니다.
배송 안정성10 최대 점수
정의: 실제로 전달된 순 위임 비율(VRM)과 이론적 기준선의 비율로, 일관되지 않은 지급에 대한 분산 페널티. 양쪽 모두 수수료를 차감하므로 비율은 실제 배송을 측정합니다 — 수수료가 아닙니다.
방법: 구간 선형 배송 비율: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → 0을 향한 선형 경사. 분산 페널티: 변동 계수 × 0.5, −30% 상한. 신뢰 감쇠기는 샘플 크기 < 3 에포크일 때 중립 5로 혼합. v3.9는 이전의 버킷 임계값을 선형화했습니다 — 최대 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
이유: 약속 대 배송은 스테이커를 위한 가장 직접적인 책임 신호입니다. v3.3은 두 가지 개선 사항을 추가했습니다: (1) 헤드라인 비율은 지수 시간 가중 평균을 사용하므로(최근 에포크가 더 중요), 이전에 잘 배송했지만 최근에 하락한 검증자는 올바르게 페널티를 받습니다; (2) 분산 페널티는 일관된 95% 배송자를 95% 주변에서 진동하는 배송자와 구별하며, 후자가 예측 가능한 수익을 고려하는 스테이커에게 더 많은 위험을 안기기 때문입니다.
남은 시간5 최대 점수
정의: 검증자의 P-Chain 스테이크 종료까지의 일수.
방법: < 14일 → 0(FIP-10에서 본질적으로 사용 불가). 14-30일 → 선형 0→2. 30-60일 → 선형 2→3. 60-120일 → 선형 3→5. 120일+ → 5. v3.9는 이전의 버킷 임계값을 선형화했습니다 — 경계 절벽(예: 13.99일 → 0, 14일 → 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일 이내인 검증자는 새 위임을 수락할 수 없습니다(FIP-10 최소 잠금은 14일), 따라서 효과적으로 언스테이킹할 수 없습니다. 점수 = 0은 '지금 바로 언스테이킹 불가능'을 '곧 풀다운 중'과 구별합니다.
활성 중단 페널티(v4.3)(공제) 최대 점수
정의: 검증자가 연속 여러 보상 에포크를 놓칠 때 긍정 차원 위에 적층된 정액 공제. 대칭 Uptime 안정성 승수와는 다릅니다 — 만성 불안정성이 아닌 활성 중단을 포착합니다.
방법: 캐시:fsp-validator-participation 레코드에서 검증자의 인접한 !eligible 접두사를 확인합니다(공개 reward-scripts nodes-data.json의 최신 우선 에포크 목록). 0–1 연속 놓침 → 0점(분산 범위 내 / 단일 일시적 놓침). 2 연속 → −3점(개발 중단). 3 연속 → −6점(지속됨 — 운영자 부주의). 4+ 연속 → −10점(활성 장시간 중단). 복합 점수는 공제 후 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)
이유: v4.3 이전 모델은 전적으로 대칭 uptimeReliability 승수에 의존했습니다 — 24개 에포크에 흩어진 5개 놓침은 연속 5개 놓침과 같은 비용이 들었습니다. 운영적으로 이들은 매우 다른 신호입니다. 흩어진 놓침은 위임자에게 만성 불안정성을 알립니다; 연속은 검증자가 지금 고장났음을 알립니다. 2026-05-14의 Luganodes 사건 — 위임자가 활발히 수백만 FLR을 커밋하고 있는 동안 연속 여러 놓친 에포크 — 은 v4.3 릴리스가 다루는 특정 사례입니다: 활성 중단 신호를 표면화하여 더 날카로운 점수 영향으로 위임자가 커밋 전에 진행 중인 오류를 피할 수 있도록 합니다. 계층화된 곡선은 단일 일시적 놓침에 과잉 반응하는 것을 피하면서(일반적) 지속된 연속을 날카롭게 플래그합니다(드물고 중요).
극단적 수수료 페널티 (v4.5)(최대 −점수의 75%) 최대 점수
정의: Fee 차원의 범위를 초과하는 수수료에 대한 비례 공제입니다. Fee 차원은 수수료가 기준점을 20포인트 초과하면 0/7로 하한선에 도달합니다. 그 이후로는 복합 점수가 수수료에 더 이상 반응하지 않으므로, 수수료가 100%인 검증자(위임자가 아무것도 얻지 못함)는 여전히 가동시간 및 MIRROR 같은 수수료 무관 차원에서 40점대의 점수를 받을 수 있습니다.
방법: 50% 이하의 수수료에서는 0입니다. Fee 차원이 이미 해당 범위에 가격을 책정했으므로 이중 계산이 없습니다. 50% 초과에서는 공제가 수수료와 함께 선형으로 상승하며, 100% 수수료에서 검증자의 긍정적 점수의 75%에 도달합니다. 점수 자체와 함께 스케일링되므로, 정교한 프라이빗 노드와 방치된 노드 모두 자신의 위치에 도달합니다: 위임자 대상 순위의 하단입니다.
// 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)
이유: 이것은 위임자를 위한 점수입니다. 위임자가 얻은 모든 보상을 유지하는 검증자는 가동시간이 아무리 좋아도 위임 후보가 아니며, 점수는 이를 명확히 나타내야 합니다. 온체인 수수료의 순수 함수로, 우리 노드를 포함하여 모든 노드에 동일하게 적용됩니다.
100/100을 얻는 방법 — 검증자 플레이북
v4.0을 생성한 감사 사이클은 모든 차원을 최대화하는 것이 진정으로 위임자에게 더 나은 검증자가 되도록 설계되었습니다. 점수를 개선하는 것은 시스템을 게이밍하는 것이 아닙니다 — 시스템이 설계대로 작동하는 것입니다. 여기 차원별 명시적 플레이북이 있습니다.
Uptime — 20점 지속적으로 ≥99.5% RPC 업타임 유지 및 모든 보상 에포크에서 FIP-10 최소 조건 통과(공개 놓치지 않음, 중앙값 배송 적중). 두 신호는 곱해집니다 — 100% RPC × 7/8 에포크 적격 = 17.5/20, 20이 아닙니다. 위임자 정렬 이유: FIP-10에서 실패하는 모든 에포크, 위임자는 그 에포크의 보상을 손실합니다.
순 수익률 — 18점. 위임자에게 네트워크 중앙값 APY의 ≥1.2배를 제공합니다(수수료 후). 최선의 경로: 낮은 수수료 + 완전한 FIP-10 적격성으로 위임자가 전체 지분을 받습니다. 이것이 일치하는 이유: 이것은 문자 그대로 당신의 몫을 제외한 후 위임자에게 도달하는 금액입니다.
수수료 합리성 — 7점. 그래나이트 하드포크 이후 프로토콜은 20% 최소 위임 수수료를 강제하며, 채점 앵커(관찰된 시장 최소값과 그 기준선 중 더 큰 값) 이하의 수수료는 전체 7점을 획득합니다. 이상의 가격 책정은 가속 상향곡선에서 포인트를 소비합니다 — 앵커+10 → 4.5점, 앵커+20 → 0. 왜 이것이 일치하는가: 기준선은 수수료 경쟁을 종식시켰으므로, 이 차원은 이제 법적 최소값 이상의 추출로부터 위임자만 보호합니다. 당신의 실제 우위는 전달된 순수익률에 있습니다.
운영자 품질 — 12점 최고 경로: FTSO 데이터 제공자로 등록하고 고품질 스택(FTSO + FDC + 서명) 운영 — FlareWatch 운영자 품질 점수는 FTSO 점수에서 나오며, FTSO 100에서 최대. FTSO 점수 없으면: +7 검증 기준선을 v3.10 자동 승격(90일 이상 관찰, 25+ 위임자, 유지 하락 없음, FIP-10 규정 자가 본딩) 또는 KNOWN_VALIDATORS에 기관 인프라로 추가(수동 고속 트랙)되어 유지. 점수는 max(검증, FTSO 파생) — 참여는 절대 해를 끼칠 수 없습니다. 정렬 이유: 완전 스택 운영자는 더 많은 생태계 가치 제공; 검증 기준선은 위임자에게 더 명확한 신원 신호를 제공합니다.
MIRROR 참여 — 10점 일관되게 FSP 가격 피드 제출, 에포크별 프로토콜 최소값 충족(서명 정책에 등록, 청구 임계값 충족, 공개 놓침 없음). 적절한 수수료 청구 — 점수는 (1 − 수수료/100)로 곱해지므로, 완벽하게 MIRROR 활성인 100% 수수료 검증자도 0을 점수하지만 MIRROR가 위임자에게 도달하지 않기 때문입니다. 정렬 이유: MIRROR는 위임자의 FTSO 인플레이션 쉐어입니다. 낮은 수수료 = 더 많은 부분이 그들에게 도달합니다.
용량 프로필 — 7점 ~70% 활용률 목표(최적 크기: 입증된 매력 + 새 위임자를 위한 여유 공간). 빈 검증자는 1.75 점수; 상한 검증자는 5.25 점수. 정렬 이유: 점수를 읽는 새 위임자는 실제로 위임할 수 있기를 원합니다; 최적 크기는 사회 증명과 가용성을 신호합니다.
커뮤니티 신뢰 — 11점 최대화할 6개 컴포넌트:
  • 운영자 통합 500+ 위임자 구축(최대 개수 신호: +6점).
  • 위임자당 소매 친화적 평균 스테이크 < 500K FLR 유지(집중도 보너스: +1).
  • 네트워크에 ≥ 90일 유지하여 장수성 보너스 받기(+1) — reward-scripts 현재로 초기화 면제.
  • 큰 셀프 본드 보유 — 비례로 ≥ 10% 또는 네트워크 상단 절대 스테이크 (~20M FLR) 중 더 나은 쪽 (일치 보너스: +2).
  • 30일 기간 총 위임 FLR을 ≥ 10% 성장(유지: +0.5).
  • 30일 동안 자체 보드를 ≥ 20% 증가 (궤적: +0.5).
이것이 일치하는 이유: 모든 구성 요소는 위임자가 원하는 행동을 보상합니다 — 운영자 skin-in-the-game, 유기적 성장, 장기성, 광범위한 커뮤니티 참여. 멀티 노드 운영자는 카운트 + 농도 신호에 대해 집계됩니다 (v3.7).
전달 신뢰성 — 10점. 위임자에게 예상 APY가 약속하는 것을 지급하세요 (전달 비율 1.00). 에포크별 분산을 최소화하세요 — 예측 가능한 지급이 높은 스프레드를 가진 동일한 평균을 이깁니다 (분산 페널티 최대 −30%). 완전한 신뢰도 가중치를 위해 8개 이상의 에포크 샘플 크기를 구축하세요. 이것이 일치하는 이유: 당신이 약속한 것을 일관되게 전달하고 있습니까? 그것이 가장 직접적인 책임 신호입니다.
남은 시간 — 5점. 스테이크 종료 날짜를 ≥ 120일 떨어져 있게 유지하세요. 만료되기 훨씬 전에 갱신하세요; < 14일 대역으로 미끄러지게 하지 마세요 (FIP-10에 따라 14일 이내에 들어가면 새로운 위임을 수락할 수 없습니다). 이것이 일치하는 이유: 더 긴 약정은 위임자에게 당신이 장기를 위해 여기 있다는 신호를 보냅니다.
단축할 수 없는 시간 게이트 신호: 장기성 보너스 (90일 관찰됨), 자동 큐레이션 티어 (90일 + 25 위임자 + 비감소 보유 + FIP-10 자체 보드), 보유 신호 (30일 위임 기록), 전달 샘플 크기 (8 보상 에포크). 좋은 소식: 다른 행동을 유지하면 자동으로 시간이 지남에 따라 이것들이 누적됩니다.
스무딩 윈도우는 단기적으로 중요합니다: 표시된 점수는 마지막 4개 cron 스냅샷의 지수 가중 평균입니다 (0.5 / 0.3 / 0.15 / 0.05), 따라서 입력에서 완벽한 100도 완전히 반영되려면 ~20분의 연속적인 완벽한 cron 실행이 필요합니다. 정상 상태 완벽한 입력 = 100; 일시적 개선은 스무딩에 포함됩니다. 갑작스러운 변화 페널티 (수수료 점프, 자체 보드 낙하, 가동 시간 충돌)도 감지 후 몇 개의 cron 사이클 동안 최대 10점을 공제할 수 있습니다.
요약하면: 모든 차원은 측정하는 것에 대해 정직합니다. 당신의 검증자가 100/100에 있다면, 점수는 또한 당신의 위임자들에게 네트워크의 최고 버전의 검증자를 받고 있다고 말합니다 — 그것이 설계 의도입니다.
자신의 점수를 확인하는 방법
검증자 테이블의 모든 점수는 공개 데이터에서 재현할 수 있습니다. 당신이 운영자이고 여기 수학이 당신이 보는 점수와 일치하지 않는다면, 우리가 오류를 범했다고 가정하기 전에 스스로 확인하는 것이 올바른 조치입니다.
가장 빠른 검사는 자동으로 실행됩니다. 검증자의 점수 행을 확장하면 "브라우저에서 확인됨" 패널이 해당 점수를 로컬로 재계산합니다 — cron이 사용한 정확한 점수 함수와 사용한 정확한 입력을 통해, 우리 서버에 다시 호출하지 않고. 모든 검증자가 노드 ID에 대한 용어가 없는 동일한 함수로 점수가 매겨지므로, 이것은 또한 누구나 우리 자체 노드가 숨겨진 이점을 얻지 못한다는 것을 확인할 수 있는 방법입니다. 아래 수동 연습은 손으로 같은 것을 합니다:
  1. 검증자의 공개 통계 조회 flaremetrics.io에서 (운영자 이름으로 검색하거나 위임 주소 붙여넣기). delegationFee, selfBond, delegatedStake 및 FTSO 점수 (데이터 제공자인 경우)를 기록하세요.
  2. 마지막 8개 보상 에포크 각각에 대해 FIP-10 적격성 확인 github.com/flare-foundation/reward-scripts에서 generated-files/reward-epoch-N/nodes-data.json 아래. nodeID가 uptimeEligible: true인 에포크 개수를 세세요. 그 비율이 Uptime 차원 승수를 확인합니다.
  3. V2 RewardManager 계약에서 MIRROR 참여 확인 flare-explorer.flare.network을 통해. RewardClaimed 이벤트에서 claimType=3을 찾아 nodeID를 참조하세요. 최근의 것이 없으면 MIRROR-inactive로 표시됩니다.
  4. 입력을 위의 공식에 연결하세요. 각 차원의 코드 블록은 실행할 정확한 산술을 알려줍니다. 차원을 합산하고 100으로 고정하면 원시 cron 계산 점수가 있습니다.
  5. 표시된 점수와 비교하세요. 표시된 점수는 v3.5의 마지막 4개 cron 스냅샷에 걸친 지수 이동 평균을 포함합니다 (현재 0.5 가중, 이전 0.3 등) — 따라서 단일 실행의 계산 점수는 표시된 점수와 약간 다를 것입니다. 각 검증자 행의 점수 분석 패널은 기여한 지속된 차원 값을 보여줍니다.
  6. 수학이 맞지 않으면, [email protected]로 이메일 보내기 nodeID, 사용한 입력 및 계산한 점수. 우리가 응답할 것이고, 오류를 범했다면 공개적으로 수정할 것입니다.
프로그래밍 방식 액세스: 모든 활성 검증자의 경우, GET /api/validators/{nodeID}/score-breakdown을 히트하여 지속된 분석을 검색합니다 — 모든 차원의 값, 그것을 생성한 알고리즘 버전 및 최근 점수 기록 — JSON으로. UI의 점수 분석 패널은 동일한 소스에서 읽습니다.
일반적인 운영자 우려
나는 100% RPC 가동 시간에 있습니다 — 내 Uptime 점수가 20/20 미만인 이유는 무엇입니까?
Uptime 차원은 RPC 곡선 출력값에 에포크 적격성 비율(지난 8개 보상 에포크의 epochsIncluded / epochsObserved, v4.2 이후 전체 FIP-10 최소값 기준, RPC 업타임만이 아님)을 곱합니다. 해당 에포크 중 어느 하나에서도 FIP-10 최소 조건을 충족하지 못한 경우(아무리 짧더라도) 신뢰성 비율이 1.0 미만으로 떨어지며 Uptime 점수가 비례적으로 조정됩니다. v3.4 이전에는 이 차원이 100% RPC 업타임을 가진 모든 검증자에게 역사적 적격성 여부와 관계없이 20점을 부여했습니다. 이제는 차별화됩니다.
나는 MIRROR를 전달합니다 — FlareWatch가 나를 MIRROR-inactive로 표시하는 이유는 무엇입니까?
v3.6부터 MIRROR 참여는 두 가지 정규 소스에서 감지됩니다: V2 RewardManager의 체인상 RewardClaimed(claimType=3) 이벤트 및 공식 FSP Merkle JSON의 claimType=3 할당 (게시된 보상 배포 데이터). 어느 소스에나 표시되는 nodeID는 활성으로 계산됩니다. Pre-v3.6에서는 온체인 스트림을 유일한 신호로 사용했으며, 이는 비표준 청구 경로를 통해 MIRROR가 정산되는 자체 위임 제공자에 대해 거짓 음수를 생성했습니다. 또한 v3.6에서 수정됨: nodeID가 아직 우리 큐레이션된 이름 목록에 없을 때 온체인 인덱서가 ~95명의 검증자가 hex20 (nodeID의 bytes20 형식)에서 미러 통계 항목을 작성한 키 형식 버그 — 모든 UI 조회는 cb58 NodeID로 키를 만들었습니다. 이 항목들은 존재했고 정확했습니다; 그들은 단지 디스플레이 레이어에 표시되지 않았을 뿐입니다. 조회는 이제 모든 소비자 (검증자 테이블, 점수 분석 패널, 공개 미러 통계 API, 수율 페이지 Staking Positions 카드, FTSO 제공자 패널)에서 두 형식을 정규화합니다. nodeID가 v3.6 스윕 후에도 여전히 비활성으로 표시되면 가능한 원인은: (a) nodeID가 실제로 해당 에포크에 대한 FSP 서명 정책에 등록되지 않음, (b) 에포크 게시 사이에 있음 (Merkle 데이터는 에포크별로 업데이트, ~3.5일). NodeID를 포함하여 이메일을 보내면 두 가지 정규 소스를 교차 검사할 것입니다.
내 점수가 하룻밤 사이에 10점 떨어졌습니다 — 무엇이 바뀌었습니까?
세 가지 중 하나: (1) v3.5 갑작스러운 변화 감지가 nodeID의 수수료 점프, 자체 보드 낙하 또는 가동 시간 충돌을 플래그 지정했습니다 — 10점 페널티는 감지된 실행에 적용되고 새로운 상태가 안정화될 때 다음 3개 실행에 걸쳐 감소합니다; (2) 스무딩 윈도우는 평균을 낮춘 이전 스냅샷을 포함했습니다; (3) 우리는 알고리즘 버전 범프를 배송했습니다 (기록의 algorithmVersion 필드에서 볼 수 있음 — 아래 버전 카드 참조). 점수 분석 패널은 현재 차원 값을 보여줍니다; 이전 실행과 비교하세요.
높은 수수료 검증자가 다른 모든 것이 유사한 낮은 수수료 검증자보다 낮은 점수를 얻는 이유는 무엇입니까?
순 수익률 차원(최대 18점)은 수수료에 민감합니다 — 0% 수수료 검증인은 네트워크 중앙값 APY의 약 1.25배를 제공하여 거의 최대 점수를 받고, 20% 수수료 검증인은 중앙값의 약 80%를 제공하여 더 낮은 점수를 받습니다. 또한 수수료 합리성(7점)은 v3.9 이후 구간별 선형입니다(버킷 없음): ≤5%는 만점 7점을 받고, 그 이후 곡선은 가파른 기울기로 하강합니다 — 10% → 6, 15% → 4.5, 20% → 2.5, 25%+ → 0 (예를 들어 16% 수수료는 고정된 버킷 값이 아닌 약 4.1점을 받습니다). 따라서 5점의 수수료 차이는 점수에서 약 5~8점의 차이로 나타납니다. 이는 의도된 것입니다 — 위임자들은 수수료를 직접적으로 중요하게 생각합니다.
나는 FTSO 점수가 없는 완전히 새로운 검증자입니다. Operator Quality가 12/12 중 7/12인 이유는 무엇입니까?
Operator Quality (최대 12점)는 풀 스택 운영자를 보상합니다 — 최고 FTSO 데이터 제공자 스택 (FTSO + FDC + 서명)도 실행하는 검증자. 스테이킹만 하는 경우, +7 기준선은 두 가지 방법으로 도달할 수 있습니다: (1) 우리 KNOWN_VALIDATORS 목록에 수동 포함 — 신뢰할 수 있는 인프라 운영자 (Ankr, InfStones, Kiln 등)를 위한 제도적 빠른 추적; (2) v3.10 객관적 행동에 기반한 자동 승격 — 90+ 일 관찰됨 AND 25+ 운영자 집계 위임자 AND 비감소 보유 AND FIP-10 준수 자체 보드. 자동 승격은 완전히 자동이며, 이메일이 필요하지 않습니다. 아직 자동 기준을 충족하지 않으면 +3 (자동 발견 티어, Flaremetrics 또는 FSE 엔티티 프로필 필요)으로 시작하고 추적 기록이 구축될 때 +7로 성장합니다. 가속화하려면: FTSO 데이터 제공자로 등록하고 V2 프로토콜을 실행하세요 — 당신의 점수는 FTSO 100에서 최대 12를 가진 FTSO 파생 분기에서 나옵니다. v3.8: FTSO 참여는 도움이 될 수 있으며, 결코 해를 끼치지 않습니다 — FTSO 점수가 확인 기준선 아래면, 당신은 기준선을 유지합니다.
나는 로고를 가지고 있지만 내 이름은 잘린 NodeID로 표시됩니다. 왜입니까?
당신의 운영자 엔티티는 Flaremetrics에 존재합니다 (우리가 당신을 위한 로고를 가진 이유) 하지만 당신의 제공자 프로필에는 '이름' 필드가 설정되어 있지 않습니다. 우리는 이름을 만들지 않습니다. Flaremetrics 또는 Flare Systems Explorer 엔티티 레지스트리에서 profile.name을 설정하면, 다음 cron 실행에서 선택할 것입니다. 또는 우리에게 확인 가능한 청구 (예: 위임 주소에서 서명된 메시지)를 이메일 보내면, 우리는 당신을 KNOWN_VALIDATORS에 수동으로 추가할 것입니다.
내 검증자는 FIP-10 최대 위임에 있습니다. Capacity가 7/7로 점수를 매기지 않는 이유는 무엇입니까?
Capacity는 70% 이용률에서 정점을 이루는 천막 함수 (7점)이며, 100%에서 5.25점으로 내려갑니다. 정점은 100%이 아닙니다 — 한계에 있다는 것은 위임자가 원하더라도 더 많은 스테이크를 추가할 수 없다는 의미이며, 이는 테이블을 읽는 새로운 위임자를 위한 중립에서 약간 음수 신호입니다. Pre-v3에서는 우리가 한계 검증자에게 0/5를 점수 매겼습니다 (성공에 대한 페널티); v3은 이를 한계에서의 중립 값으로 수정했으며, v3.7은 전체 차원을 8 → 7 max로 재조정했습니다 (Trust 궤적 신호를 위해 1점 해제), 따라서 오늘날 한계 점수는 5.25/7입니다. 우수하게 크기 조정된 검증자 (증명된 매력적 AND 성장할 여지가 있음, 70% 이용률에서 정점)는 전체 7을 얻습니다.
나는 실제 운영자이지만 검증자 목록에 없습니다. 무엇입니까?
검증자 목록은 라이브 P-Chain RPC의 getCurrentValidators 결과에서 구축됩니다. 거기에 없으면, 당신은 현재 P-Chain에서 활성화되지 않았거나, 당신의 스테이크가 방금 만료되었거나, 우리 측에 P-Chain RPC 문제가 있습니다. cron은 5분마다 실행됩니다 — 당신의 스테이크를 활성화한 후 1-2 사이클 내에 표시되어야 합니다. 1시간 동안 활성화되었는데도 자신을 보지 못하면, nodeID와 함께 이메일을 보내세요.
내 점수에 항소하거나 수동 검토를 요청할 수 있습니까?
예. [email protected]로 이메일 보내기 nodeID 및 구체적인 우려. 우리는 모든 운영자에게 응답합니다. 우리가 행동할 것들: KNOWN_VALIDATORS 추가, MIRROR 분류 수정, 로고/이름 수정, 차원별 수학 오류. 우리가 행동하지 않을 것들: 알고리즘 외부의 점수를 수동으로 올리기를 요청, 경쟁자를 제외하거나 순위를 내리도록 요청.
우리가 할 것과 하지 않을 것
점수 운영 방식에 대한 모호성을 제거하기 위해, 명시적 약속이 있습니다. 우리가 이 중 하나를 위반한다면, 문서화하고 [email protected]로 이메일 보내세요 — 우리는 공개적으로 수정할 것입니다.
✓
우리는 더 높은 점수, 후원 배치 또는 어떤 종류의 우호적 처우를 받지 않을 것입니다. 점수는 공개 체인 데이터에서 결정적으로 계산됩니다.
✓
우리는 검증자당 수동 범프를 손코딩하지 않을 것입니다. 코드 어디에도 "X는 우리가 좋아해서 +5를 받습니다"라는 줄은 없습니다. 동일한 알고리즘이 FlareWatch의 고유 노드를 포함한 모든 검증자에게 적용되며, 이는 이 정확한 함수로 점수가 매겨집니다.
✓
우리는 공개되지 않은 이유로 검증인을 제외하지 않습니다. 목록은 라이브 P-Chain RPC에서 소싱되며, 우리의 디스플레이는 모든 활성 검증인을 포함합니다. KNOWN_VALIDATORS에 대한 큐레이션된 추가는 디스플레이 이름만 채우며, 가시성을 제한하지 않습니다.
✓
우리는 알고리즘 변경사항을 공개합니다. 모든 버전 업데이트(v3 → v3.1 → v3.2 → ...)는 이 페이지의 Versions 카드에 근거와 함께 변경 내용과 함께 기록됩니다. 주요 변경사항은 앱의 changelog 페이지에서 확인할 수 있는 추가 changelog 항목을 받습니다.
✓
우리는 검증인 이메일에 응답합니다. [email protected]로 자신의 점수에 대한 실질적인 우려를 이메일로 보내는 모든 검증인은 몇 영업일 내에 실제 응답을 받습니다.
✓
우리는 공개적으로 우리의 실수를 수정합니다. 알고리즘에서 버그, 데이터 소스 오류 또는 방법론 간격을 발견하면 수정 사항을 배포하고 문서화합니다. 조용히 다시 순위를 매기지 않습니다.
✗
우리는 발신자의 허가 없이 이메일 내용을 공개적으로 공유하거나, 검증인 이메일을 해당 이메일을 생성한 점수 대화 이외의 목적으로 사용하지 않습니다.
✗
우리는 알고리즘 변경의 향후 계획을 특정 검증인과 미리 공유하지 않습니다 — 모든 버전은 모든 사람에게 동시에 배포됩니다.
제한사항 — 이 점수가 무엇이고 무엇이 아닌가
복합 점수는 유용한 요약이지, 객관적 진실이 아닙니다. 저희 점수는 투명하고, 버전 관리되며, 저희 자신을 포함한 모든 검증인에게 동일하게 적용되고, 브라우저에서 공개된 입력값으로부터 다시 도출할 수 있습니다. 하지만 여전히 편집상의 판단을 담고 있으며, 방법이 갖지 못한 정밀도를 암시하기보다는 정확히 어디에 그 판단이 있는지 보여주는 것이 낫다고 생각합니다.
차원 가중치는 저희의 판단입니다. 업타임이 20점이고 수수료가 7점인 이유는 대부분의 위임자에게 몇 포인트의 수수료보다 안정성이 더 중요하다고 저희가 결정했기 때문이지, 공식이 이를 증명했기 때문이 아닙니다. 합리적인 사람이라면 이들을 다르게 가중치할 것입니다. 가중치는 고정되고 공개되어 있으므로 저희가 정확히 무엇을 선택했는지 볼 수 있고, 분석 결과에서 이를 정신적으로 다시 가중치할 수 있습니다.
순수익률은 결과이지, 미덕이 아닙니다. 이는 위임자가 실제로 버는 것을 측정하며, 네트워크 중앙값에 기준을 두므로, 운영자의 통제 밖의 요소(네트워크 인플레이션, 유치한 위임 규모)에 의해 부분적으로 형성되고, 나머지 필드가 움직일 때 함께 움직입니다. 규율 있는 운영자가 공정하지만 더 높은 수수료를 청구하면 여기서는 낮은 점수를 받으면서도 훌륭할 수 있습니다. 이를 "운영자가 얼마나 좋은가"가 아닌 "나는 얼마를 벌 것인가"로 읽으세요.
FTSO 연계 차원은 풀스택 운영자를 선호합니다. MIRROR 참여와 운영자 품질의 일부는 또한 상위 FTSO 데이터 제공자 스택을 운영하는 검증인에게 보상합니다. 이것은 의도적입니다. 위임자로서 FTSO 활성 검증인으로부터 MIRROR를 통해 실제로 더 많이 벌기 때문입니다. 하지만 이는 순수 스테이킹만 하는 훌륭한 검증인이 이 보드의 맨 위에 올 수 없다는 의미입니다. 선택에 의해 스테이킹만 하는 경우라면, 자신을 위해 이러한 차원을 낮게 가중치하세요.
모델은 덧셈식입니다. 차원이 더해지므로, 강점이 약점을 상쇄할 수 있습니다. 탁월한 업타임이 더 높은 수수료를 적정한 점수로 이끌 수 있습니다. 진정한 실격 사유(FIP-10 최소값 미충족, 약탈적 수수료)는 별도로 관문이 설정되어 완전히 가려질 수 없습니다. 매 에포크마다 최소값을 미충족하거나 100% 수수료를 청구하는 검증인은 다른 차원에 관계없이 보드 하단 근처에 위치합니다. 하지만 핵심은 거부권 시스템이 아닌 가중 합입니다.
한 숫자가 아홉 개의 판단을 숨깁니다. 단일 0-100 수치는 시작점이지, 최종 판정이 아닙니다. 1점 차이가 나는 두 검증인은 의미 있게 다르지 않습니다. 분석 결과를 열고 자신에게 중요한 차원에 가중치를 두세요. 이 숫자는 비교를 더 빠르게 만들기 위해 존재하지, 비교를 대체하기 위해 존재하는 것이 아닙니다.
저희는 방법을 드물게 변경하고, 공개적으로 변경합니다. 모든 변경에는 버전 번프, 서면 근거, 필드 전체 비교 전후가 함께 제공되므로, 무엇이 변했고 왜 변했는지 감시할 수 있습니다. 저희의 자동화된 감시가 저희 숫자의 불일치를 포착할 때(이는 발생합니다), 저희는 이를 수정하고 알립니다.
최종 점수(차원을 결합하는 방식)
모든 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: 검증인 목록, 작동 시간, 자기 자본금, 위임된 스테이크, 수수료, 종료 시간, 위임자 수.
V2 RewardManager(claimType=3 이벤트): 검증인 nodeID당 온체인 청구된 MIRROR 배포. 유형 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): 최신 N 보상 에포크에 대한 검증인당 전달된 APY. Delivery 차원을 주도합니다.
FlareWatch 큐레이션: KNOWN_VALIDATORS 맵(~110 항목). 신뢰할 수 있는 인프라 검증인의 이름 + 운영자 품질 기준선.
점수에 포함되지 않은 것
• 자가 홍보 또는 유료 배치. 어떤 검증인도 더 높은 점수를 위해 비용을 지불하거나 후원할 수 없습니다.
• 손으로 코딩된 검증인별 상향 조정. "우리가 그들을 좋아하기 때문에 X는 +5를 받습니다"라는 라인이 코드의 어디에도 없습니다. FlareWatch의 자체 노드를 포함한 모든 검증인에게 동일한 알고리즘이 적용되며, 이는 이 정확한 함수로 점수화됩니다.
• 주관적 인프라 품질. 우리는 가동 시간 SLA, 지리적 분산 또는 하드웨어 사양을 평가하려고 시도하지 않습니다. 인프라 등급을 주장하려면 최상위 FTSO + FDC 스택을 실행하면 운영자 품질 차원이 이를 반영합니다.
• FlareWatch에 대한 잠금 또는 약속. FlareWatch 대 다른 도구를 사용하는 스테이커의 유리한 점수 없음.
운영자 피드백
검증인의 점수에서 뭔가 이상한 점을 보셨나요? [email protected]로 NodeID와 우려사항을 이메일로 보내주세요. 우리는 모든 검증인에게 응답합니다. 우리가 행동할 일반적인 요청:
  • KNOWN_VALIDATORS에 검증인 추가(검증 포함).
  • 오류가 있다고 생각하는 경우 MIRROR 비활성 분류 검토.
  • 로고 / 디스플레이 이름 수정.
  • 일반 알고리즘 비평.
소스 및 참고자료
점수의 모든 입력은 공개되고 검증 가능한 Flare 생태계 소스에서 나옵니다. 누구나 이 1차 소스에 대한 우리의 주장을 교차 검증하고 원본 데이터에서 수학을 재현할 수 있습니다. 이 페이지와 업스트림 소스가 말하는 것 사이의 불일치를 발견하면 [email protected]로 이메일을 보내주면 수정하겠습니다.
Flare Network 프로토콜 문서 ↗https://docs.flare.network
권위 있는 프로토콜 문서. FTSO V2, FSP, P-Chain 검증, FAssets 및 Flare 스택의 나머지를 다룹니다.
Flare 거버넌스 포털(FIPs) ↗https://proposals.flare.network
Flare 개선 제안 — FIP-05(위임 요소), FIP-10(검증인 최소 조건: 100만 FLR 자기 자본금 하한선, 80% 작동 시간 하한선, 14일 최소 잠금) 및 이 페이지에서 인용된 모든 기타 규칙의 진실의 원천입니다.
Flare Systems Explorer(FSE) ↗https://flare-systems-explorer.flare.network
FTSO 데이터 공급자, 엔티티 주소, P-Chain nodeID 연결 및 FIP-10 최소 조건 플래그의 공식 Flare 운영 레지스트리입니다. 우리의 운영자 품질 및 신뢰성 데이터의 주요 소스입니다.
Flaremetrics ↗https://flaremetrics.io
독립적인 Flare 생태계 메트릭 공급자입니다. FTSO 공급자 점수, 보상 비율, 정확도 메트릭, V2 프로토콜 참여 플래그 및 검증인-엔티티 주소 매핑의 소스입니다. 우리는 공개 REST API를 사용합니다.
Flare Foundation reward-scripts 저장소 ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation에서 발행한 보상 에포크별 JSON으로 검증인별 적격성, 작동 시간 적격성 및 전달된 보상을 보여줍니다. Delivery 신뢰성 차원과 Uptime에 대한 v3.4 에포크 적격성 비율을 주도합니다.
Flare Block Explorer ↗https://flare-explorer.flare.network
온체인 상태의 읽기 전용 브라우저입니다. 누구나 V2 RewardManager의 RewardClaimed 이벤트(MIRROR의 claimType=3), 검증자 스테이크 총액, 수수료 변경 및 기타 사항을 확인할 수 있습니다.
Flare Portal(스테이킹) ↗https://portal.flare.network/staking
공식 스테이킹 인터페이스입니다. 현재 자체 본딩/위임 스테이크 금액 및 P-Chain RPC 읽기에 적용되는 검증자 종료 시간의 신뢰할 수 있는 출처입니다.
Flaremetrics 공개 API(FTSO 제공자) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
우리의 크론이 소비하는 정확한 엔드포인트로, 엔티티 프로필, FTSO 점수, 수수료 및 16진수 형식의 nodeId를 반환합니다. 누구나 직접 접근할 수 있습니다.
Flaremetrics 공개 API(노드 등록) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
16진수 → cb58 NodeID 변환 테이블입니다. 이를 페이지네이션하여 모든 cb58 형식 소비자를 구동하는 엔티티-NodeID 조회를 구축합니다.
개인 데이터 없음, 폐쇄형 모델 없음. 스코어링 알고리즘은 FlareWatch 코드베이스의 services/validators/scoring.ts에 구현되어 있습니다. 구현을 직접 검사하거나(위의 설명 + 수식을 읽는 대신), 자신의 용도로 포크하려는 운영자 또는 연구자는 [email protected]로 이메일을 보내 접근을 요청할 수 있습니다. 실제 수요가 있으면 이 파일을 독립형 오픈소스 패키지로 공개할 예정입니다.
점수 업데이트 방식
/api/cron/refresh-validators의 크론은 모든 활성 검증자의 점수를 매 5분마다 다시 계산합니다. 입력값(P-Chain RPC 읽기, Flaremetrics, FSE, 보상 스크립트)은 매 실행마다 새로 가져옵니다.
v3.5에서는 마지막 4개 크론 스냅샷에 대한 스무싱(가중치: 0.5 / 0.3 / 0.15 / 0.05)을 추가했으므로 표시된 점수가 일시적 입력 노이즈에 의해 급변하지 않습니다. 원본 크론 계산 점수는 향후 스무싱 계산을 위해 유지되며, 점수 분석 패널은 모든 차원의 현재 값을 표시하므로 변경된 사항을 확인할 수 있습니다.
알고리즘 버전은 캐시된 모든 점수 레코드에 기록됩니다. 새 버전을 배포하면 모든 점수에 새 태그가 지정됩니다. 아래 Versions 카드는 모든 변경 사항을 문서화합니다.
Flare의 페널티 모델

Flare는 검증자 스테이크를 삭감하지 않습니다. 검증자 부정행위에 대한 전체 페널티 메커니즘은 보상 몰수와 FIP-10 패스 시스템입니다. 더블 서명 삭감, 동의어 삭감, 추적해야 할 스테이크 소실 이벤트가 없습니다. FIP-10 최소 조건을 충족하지 못한 검증자는 해당 에포크의 보상을 잃습니다(패스가 0이면 전부 몰수, 아니면 실패한 프로토콜당 패스 1개 손실). 스테이크된 원금은 변하지 않습니다.

즉, 점수에는 '삭감 이력' 차원이 없습니다. 추적할 그러한 이력이 없기 때문입니다. 우리가 추적하는 것은 모든 최소 실패의 결과입니다. 즉, 검증자가 그 에포크에서 0을 벌었으며, 이는 epochsIncluded / epochsObserved에 기록됩니다. 2026-05-14의 v4.2 업데이트는 점수의 신뢰성 배수를 전체 FIP-10 최소 집합(가동시간, FSP 서명, FTSO 제출 비율, FDC 참여)에 걸친 비율을 사용하도록 확대했으므로 어느 축이 실패했든 상관없이 최소값을 실패한 검증자는 가동시간 차원에서 비례적으로 페널티를 받습니다.

FIP-10 최소 임계값(출처: dev.flare.network/network/fsp/rewarding): 스테이킹은 80% 가동시간 + 100만 FLR 활성 자체 본딩 필요. FTSO 앵커 피드는 추정값이 80%의 라운드에서 합의 중앙값의 0.5% 이내여야 함. FTSO 블록 지연 피드는 예상 업데이트의 80% 제출 필요. FDC는 투표 라운드의 60% 참여 필요. 80% 가동시간 + 100만 자체 본딩 기준을 충족하지만 300만 / 1,500만 수익 임계값 미만인 검증자는 여전히 보상을 받지만 패스를 축적할 수 없습니다. 회색 영역은 이 카드의 passEligibility: "at-risk" 분류를 통해 표시됩니다.

버전
v4.8 (2026-09-17) — Reward epochs annualized at their real length. Every measured validator rate (delivered APR, delegation, MIRROR, operator self-bond yield) was annualized with a 3.19-day reward epoch, a value added on 2026-04-04 and described as measured from block timestamps although nothing measured it. Flare reward epochs are exactly 3.5 days — FlareSystemsManager's rewardEpochDurationSeconds returns 302,400 and every epoch start on-chain is 3.500 days apart — so each measured rate read about 9.7% high for five and a half months, our own included. The length is now read from that contract. Every measured APR falls by the same factor, 3.19 ÷ 3.5 (network median 9.08% → 8.28%; FlareWatch 8.17% → 7.45%). Scores: only Delivery Reliability moves, because it compares the measured rate with the theoretical rate for the validator's fee. The inflated side had put 91% of validators at the 1.0 cap, i.e. apparently paying more than is possible; with the real epoch length the median delivered-to-theoretical ratio is 0.990. Simulated over the 168 validators with measured data before shipping: median −0.32 points, 146 lose under 1 point, 13 already delivering below their fee-implied rate lose 2–3.5. The Community Trust longevity fallback converts epochs to days with the same length and is corrected too; it moves no score, because it sees at most 8 epochs (28 days), below its 30-day step either way. Signed performance attestations used the same wrong length; the recompute spec is revised to rev.3 and rev.2 is kept verbatim with the error disclosed.
v4.7 (2026-08-19) — Community Trust 차원의 양축 셀프 본드. Trust는 운영자 셀프 본드를 비율로만 반영했습니다 (자신의 본드 ÷ 전체 스테이크). 따라서 위임으로 희석된 큰 셀프 본드는 그 비율의 작은 본드와 같은 점수를 받았습니다. 스코어는 실제 약속된 자본을 놓쳤습니다. 현재 네트워크에서 178개의 검증자 중 61개가 <10% 비율에서 ≥10M 셀프 본드를 보유했으므로, 현장의 3분의 1이 과소 평가받았습니다. v4.7은 비례 배분 (≥10% → +2, 5–10% → +1, 변경 없음) 또는 절대 규모 (min(1, selfBond ÷ 20M) × 2, 네트워크 상위 십분위수 P-chain 본드에서 포화) 중 더 나은 쪽으로 셀프 본드를 반영하고, 최대값을 취하며 서브 신호를 여전히 +2로 제한합니다. Trust 상한선 (11)과 합성 상한선 (100)은 변경되지 않았으며, FIP-10 미만 빈 바닥 (<1M FLR → −1)은 변경되지 않았습니다. FTSO 제공자 점수가 이미 사용하는 양축 셀프 본드를 반영합니다. 배포 전에 보관된 모든 178개 검증자에 대한 현장 전체 전후: 58개는 상승하고, 없음은 하락하며, 점수 상승이 1포인트를 초과하지 않으며, 리더보드의 상단은 변경되지 않았습니다. 우리 노드는 1포인트 상승 (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 차원은 수수료가 시장 앵커 + 20포인트(Granite 후 약 40%)를 초과하면 0/7에서 포화되며, 그 이상 100% 수수료까지 복합 점수가 수수료에 더 이상 반응하지 않으므로, 위임자가 아무것도 얻지 못하는 100% 수수료 검증자도 수수료 무관 차원에서 40점대를 획득했습니다. 위임자 중심의 점수에서는 그러한 결과가 중위 수준이 아닌 거의 탈락 수준입니다. v4.5는 양의 차원 합계의 일부로 적용되는 복합 페널티를 추가합니다: 50% 수수료 이하에서는 0(Fee 차원이 이미 계산한 범위에서 이중 계산 없음), 100% 수수료에서 점수의 75%까지 선형으로 증가합니다. 100% 수수료 노드는 약 10/100에 착지하며, 여전히 나열되고 순위가 매겨지지만 명백하게 위임 후보가 아닙니다. 온체인 수수료의 순수 함수이며 모든 검증자(우리 노드 포함)에 대해 동일합니다.
v4.4 (2026-07-11) — 그래나이트 기준선 인식 수수료 앵커. 그래나이트 하드포크(Flare, 2026-07-14)는 20% 최소 검증자 위임 수수료를 강제합니다. 수수료 합리성 앵커는 max(관찰된 최소 활성 수수료, 프로토콜 기준선)이 됩니다: 법적 최소값 이하의 모든 수수료는 만점을 획득하며, 이상의 수수료만 거리에 따라 페널티를 받습니다. 근거: 업스트림에서 진행 중인 스테이크의 할아버지 조항이 명시되지 않은 상태에서, 할아버지 조항이 포함된 2%(또는 포크 전 0%) 유산에 앵커를 두면 프로토콜 준수 20% 운영자를 거의 추출적으로 평가했을 것이고, 순수익률이 이미 전달된 용어로 책정한 수수료 차이를 이중 계산했을 것입니다. 다른 차원은 변경되지 않았습니다. 전체 집단이 기준선에 도달하면, 차원은 균등하게 만점을 부여합니다 — 아무도 수수료로 경쟁할 수 없으면 수수료는 더 이상 계산되지 않습니다.
v4.3(2026-05-14) — 활성 중단 페널티가 차원 후 고정 공제로 추가되었습니다. 기존 uptimeReliability 배수는 대칭적입니다. 24개 에포크에서 산발적인 5개 실패는 연속적인 5개 실패와 동일한 비용이 들지만, 운영상 이들은 매우 다른 신호입니다. 산발적 실패는 만성적 불안정을 의미하고, 연속은 검증자가 지금 바로 손상되었음을 의미합니다. v4.3은 검증자의 최근 참여 이력의 시작 부분에서 연속된 !eligible 에포크를 읽고 0-1개 연속 실패(정상 분산 / 단일 일시적 실패)에 대해 0포인트, 2(발전하는 중단)에 대해 3포인트, 3(지속된 중단)에 대해 6포인트, 4+(활성 연장 중단)에 대해 10포인트를 공제하며, 복합은 0으로 내림합니다. 신뢰성 배수 위에 계층화되고(교체가 아님) 두 신호가 다른 위험을 포착하기 때문입니다. 트리거: 2026-05-14의 Luganodes 클래스 인시던트로, 여러 최근 에포크가 위임자들이 적극적으로 스테이크를 커밋하는 동안 연속으로 실패함. 연속 신호를 통해 위임자는 커밋 전에 진행 중인 실패를 볼 수 있습니다. 페널티는 점수 분석 패널의 자체 섹션으로 렌더링되므로 9개의 긍정 차원은 여전히 100으로 합산됩니다.
v4.2(2026-05-14) — 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(2026-05-14) — 순수익 차원은 이론적 APR(공식: gross_APR × (1 − 수수료))에서 Flare Foundation 보상 스크립트의 측정된 deliveredAPY로 전환되었으며, 측정 이력이 없을 때만 검증자별 이론적 폴백입니다. 트리거: FIP-16의 인플레이션 감소(5% → 3%)는 2026-05-14에 시행되었고, 이론적 공식의 적격 스테이크 분모는 온체인 현실에서 벗어나서 이론적 APR이 네트워크 전체에서 전달된 수익을 약 2배 과소 보고했습니다. 측정된 우선으로 전환하면 점수 입력을 실제 스테이커가 받는 것과 정렬됩니다. networkMedianAPR 앵커도 동일한 측정 우선 방법론을 사용하여 다시 계산되었으므로 비율 비교는 양쪽에서 일관성을 유지합니다. 점수는 대략 안정적이어야 합니다(네트워크 중앙값의 검증자는 여전히 ~12/18으로 점수 매김). 단지 공식 출력이 아닌 실제 전달된 비율을 기반으로 합니다.
v4.0(2026-05-11) — 주요 버전입니다. v3.7-v3.10 사이클은 누적적으로 스코어링 시스템의 구조적 재작성을 구성하며, 범프를 정당화할 만큼 충분히 큽니다. 요약: 두 차원의 상한이 변경되었습니다(Trust 10→11, Capacity 8→7). 운영자 품질의 공식은 max(verification, FTSO-derived)로 재작성되었으므로 참여는 손상될 수 없습니다. 남은 4개의 버킷형 차원(가동시간, 수수료, 배달, 남은 시간)은 선형화되어 경계 절벽을 제거했습니다. 3개의 새로운 점수 구성 요소가 추가되었습니다(30일 위임 보유, 30일 자체 본딩 궤적, 큐레이팅된 티어로 자동 승격). 다중 노드 운영자 집계는 Trust 개수 + 농도를 위해 도입되었습니다. 수명은 이제 보상 스크립트 에포크 존재를 통해 초기화 방지입니다. 2가지 역효과적 인센티브가 제거되었습니다(운영자 품질 FTSO 참여 페널티 및 가동시간 95% 역 V자형 절벽). 점수의 모든 입력은 이제 외부에서 검증 가능합니다. 편집상 결정은 부하 저장이 아닙니다. 검증자는 관찰 가능한 행동을 통해 큐레이팅된 운영자 기준 +7을 벌 수 있습니다(90+ 일 관찰, 25+ 위임자, 보유율 감소 없음, FIP-10 호환 자체 본딩). 아래의 v3.7-v3.10 항목에서 이 릴리스를 구성하는 세분화된 변경 사항을 참조하십시오.
v3.10(2026-05-11) — 마지막 큐레이션 격차를 폐쇄했습니다. 운영자 품질의 +7 큐레이팅된 운영자 기준은 이전에 우리의 KNOWN_VALIDATORS 목록에 대한 수동 포함을 필요로 했으며, 이는 v3.7-v3.9 감사 사이클 후 남은 유일한 의미 있는 편집 결정이었습니다. v3.10은 객관적 자동 승격 경로를 추가합니다. FlareWatch 관찰이 90+ 일, 운영자 집계 위임자 25+, 보유율이 감소하지 않음(30일 하락 ≤ 15%), FIP-10 호환 자체 본딩을 갖춘 모든 검증자는 +7 기준에 자동으로 적격이 됩니다. 수동 검토가 필요하지 않습니다. KNOWN_VALIDATORS는 아직 90일 기간을 축적하지 못한 기관 운영자를 위한 빠른 추적으로 유지됩니다(출시일 Ankr 또는 Kiln 진입을 생각해 보세요). 그러나 일반적인 경우는 이제 완전히 자동화됩니다. 4가지 기준 모두 온체인 파생 또는 근처 온체인입니다(위임자 개수, 보유율, 자체 본딩) + 우리 자신의 관찰 타임스탬프입니다. 주관적인 것은 없고, 이메일 팀으로 게이팅 없습니다. 순효과: 검증자는 행동만으로 +7 티어를 벌 수 있습니다. 네트워크의 대부분의 기존 운영자는 이미 오늘 기준을 충족합니다.
v3.9(2026-05-11) — 공정성을 위해 점수의 모든 부분을 감사한 후 나머지 4개의 버킷형 차원 전체에서 경계 절벽 정리. 수정: (1) 가동시간 곡선의 역 V자형 절벽을 95%에서 수정했습니다. 가동시간이 94.99% → 95.00%로 증가하면 4포인트를 잃습니다(95-99% 분기는 0에서 시작했으며 낮은 분기의 최대값인 4와 일치하지 않습니다). 우리가 방금 운영자 품질(v3.8)에서 수정한 것과 동일한 역효과적 인센티브 형태입니다. (2) 수수료 합리성 임계값이 선형화되었습니다. v3.9 이전에는 버킷 경계를 넘는 0.01% 수수료 인상으로 최대 2.5포인트를 잃을 수 있었습니다. 이제 조각별 선형이며 경계의 버킷 값을 유지하는 점점 더 가파른 기울기(낮은 수수료는 거의 페널티 없음, 추출적 수수료는 매우 처벌됨). (3) 배달 신뢰성 deliveryRatio 임계값이 선형화되었습니다. 동일한 패턴으로 최대 2포인트 절벽이 제거됩니다. (4) 남은 시간 버킷 임계값이 선형화되었습니다. 더 작은 절벽(14일 경계에서 최대 2포인트)이 있지만 작은 차원에 여전히 있습니다. 이제 부드럽습니다. 순수익, MIRROR 참여 및 용량 프로필은 감사되었으며 그대로 공정한 것으로 확인됨(이미 선형/연속). 총 상한은 100으로 변경되지 않습니다. 설계상 점수 회귀 없음. 점수가 움직이는 유일한 검증자는 정확히 이전 버킷 경계에 앉아 있던 검증자들입니다.
v3.8(2026-05-11) — 공정성 검토 후 운영자 품질 차원이 감사되고 재작성되었습니다. 3가지 수정이 함께 배포됩니다. (1) 역효과적 인센티브를 제거했습니다. 중간 티어 FTSO 점수(예: 50)를 가진 알려진 운영자는 4포인트였지만, FTSO에서 완전히 탈퇴한 동일한 운영자는 7포인트였습니다. v3.8에서 점수는 max(verification baseline, FTSO-derived)이므로 FTSO 참여는 도움만 될 수 있고, 절대 손상되지 않습니다. (2) 중간 검증 티어를 도입했습니다. Flaremetrics 또는 FSE(하지만 아직 큐레이팅된 KNOWN_VALIDATORS 맵에 없는)에서 자동 발견된 이름을 가진 운영자는 0 대신 +3을 얻으므로 이전 7→0 절벽이 완화됩니다. (3) 검증이 낮은 FTSO 점수를 이기면 양쪽 신호를 분석 상세에 표시합니다(예: "Curated operator · FTSO 45"). 운영자는 점수가 정확히 어디에서 나오는지 이해할 수 있습니다. 12포인트 상한은 변경되지 않습니다. 변경은 상단을 변경하지 않고 하단에서만 점수 분포를 확대하므로(부분 검증 보상) 리밸런싱이 필요하지 않습니다.
v3.7(2026-05-11) — 운영자 공정성 검토 후 Community Trust 차원이 감사되고 확대되었습니다. 3가지 추가: (1) 다중 노드 운영자 집계 — 여러 P-Chain 노드를 실행하는 운영자(AU, FlareBus, Aureus Ox, Kiln 등)는 이제 Trust 개수 + 농도 신호에 대해 위임자 개수와 총 스테이크가 집계되므로 동일한 위임자 기반을 여러 노드에 분배한다고 해서 페널티를 받지 않습니다. (2) 30일 위임 보유 신호(±0.5 포인트) — 슬라이딩 윈도우 비교를 사용하여 성장 / 안정 / 축소 검증자를 구별합니다. v3.7 이전의 스냅샷 전용 Trust 차원은 이들을 구별할 수 없었습니다. (3) 30일 자체 본딩 궤적(±0.5 포인트) — 시간 경과에 따라 자체 본딩을 증가시키는 운영자를 보상하고, 조용히 본딩 해제하는 운영자를 페널티합니다. 단일 대규모 하락만 감지하는 갑작스런 변경 페널티와 다릅니다. 상한 리밸런싱: Trust 10 → 11, Capacity 8 → 7. 감사의 버그 수정: (a) 0 자체 본딩은 이제 sub-FIP-10 페널티를 올바르게 적중합니다(이전에는 `selfBondFLR > 0` 게이트가 정확히 0 자체 본딩이 페널티를 피하도록 허용). (b) FIP-10 기준과 5% 사이의 작은 자체 본딩 비율은 이제 분석 패널에서 실제 백분율을 렌더링하므로 운영자는 +1 / +2 티어로 닫히는 것을 볼 수 있습니다. (c) 수명 보너스는 이제 초기화 방지입니다. 초기 관찰 KV가 인위적으로 신선할 때 보상 스크립트 에포크 존재로 폴백합니다.
v3.6(2026-05-11) — 2가지 MIRROR 탐지 수정이 함께 배포되었습니다. (a) 탐지는 이제 2개의 정규 출처에서 읽습니다. 온체인 RewardClaimed(claimType=3) 이벤트(V2 RewardManager의) 및 공식 FSP Merkle JSON의 claimType=3 할당(Flare의 자신의 서명 도구가 소비하는 동일한 데이터). 어느 신호든 충분합니다. 온체인에서 아직 청구되지 않은 MIRROR가 할당된 검증자를 포착합니다. (b) Merkle에 대한 상호 확인은 별도의 키 형식 버그를 드러냈습니다. validators:mirror-stats는 혼합된 hex20/cb58 NodeID 키를 가졌습니다(온체인 인덱서는 검증자가 아직 큐레이팅된 이름 목록에 없을 때 16진수를 작성). 모든 UI 소비자는 cb58으로만 조회했습니다. ~95개 검증자의 상태는 디스플레이에 표시되지 않았습니다. 조회는 이제 validators 테이블, 점수 분석 패널, mirror-stats 공개 API, Yield 페이지 스테이킹 포지션 카드 및 FTSO 제공자 패널 전체에서 양쪽 형식을 정규화합니다. 영향을 받은 검증자는 다음 크론 사이클에서 MIRROR 참여 + 운영자 품질 차원과 전체 FlareWatch 점수가 9-10포인트 상승한 것을 봤습니다. FTSO 제공자 보고서(FlareBus, 2026-05-11)를 통해 발견됨. 피드백에 감사합니다. 그들의 피드백은 자신의 점수만이 아니라 모든 위임자의 네트워크 보기를 크게 개선했습니다.
v3.5(2026-05-09) — 순수익은 이제 네트워크 APR에 대해 중앙값 앵커됩니다(중앙값의 검증자는 18/18 중 12를 점수 매김, 상위 성과자는 18에 도달, 하위 4분위는 0으로 하락). Trust 차원은 자체 본딩 정렬을 4번째 구성 요소로 흡수했습니다(비례 자체 본딩은 게임 스킨 보상. sub-FIP-10 기준은 작은 페널티). 새로운 "NEW Xd" 배지는 FlareWatch가 <30 일 동안만 관찰한 검증자를 표시하므로 스테이커는 기록이 얇을 때를 볼 수 있습니다.
v3.4(2026-05-09) — 가동시간 차원은 이제 즉각적인 RPC 가동시간과 역사적 FIP-10 에포크 적격성 비율을 혼합합니다. v3.4 이전에는 차원이 판별이 없었습니다(92.9%의 검증자는 100% RPC 가동시간을 가졌습니다). 신뢰성 비율은 지난 8개 보상 스크립트 에포크에서 epochsUptimeEligible / epochsObserved에서 파생됩니다. 시계열 신호로 FIP-10 최소 조건을 가끔 실패하는 검증자를 그렇지 않은 검증자와 의미 있게 구별합니다.
v3.3(2026-05-09) — 배달 차원은 이제 지수 시간 가중 평균 비율을 사용합니다(최근 에포크는 더 크고, 감소 상수 0.85) 분산 페널티를 적용합니다(변동 계수 × 0.5, 최대 −30%). 에포크별 보상 스크립트 데이터에서 계산됨. 표본 크기는 기존 신뢰도 감마기로 이어집니다.
v3.2(2026-05-09) — 다중 신호 Community Trust(개수 + 농도 + 수명). FlareWatch에서 처음 관찰된 추적이 KV에 유지됨. 수명 보너스. 스테이크 엔드 엣지 케이스(14일 내 만료 검증자는 남은 시간에서 0점, FIP-10 아래 새 위임을 받을 수 없음). 방법론 페이지 공개됨. 운영자 피드백 채널 표시됨. 알고리즘 버전은 모든 캐시된 점수 레코드에 기록됨.
v3.1(2026-05-09) — 배달 차원을 보상 스크립트 데이터에 연결. 운영자 품질(선형 보간), 용량(텐트 함수), Trust(로그 스케일) 스무싱. FSP 알려진 + 0 claimType=3을 MIRROR "inactive" 대신 "no data"로 재분류. scoreBreakdown을 서버 측에 유지하므로 클라이언트는 전체 입력 없이 재계산되지 않습니다.
v3(2026-05-09) — 이진 ID 보너스를 연속 운영자 품질로 교체. MIRROR 참여를 전용 차원으로 추가. 상한 용량을 0포인트 페널티 대신 중립으로 만들었습니다. APY/수수료 이중 계산 제거(순수익 통해). 밴드 재조정(상위 티어 90+, 강력/양호/수용 가능/중앙값 이하).
v2(2026-05-09 이전) — 원본 8차원 점수(가동시간 / APY / 수수료 / ID / 용량 / Trust / 시간 / 배달). APY/수수료 이중 계산, 이진 ID 페널티, 상한 용량 페널티, MIRROR 차원 없음으로 인해 폐지됨. 역사적 참조를 위해 문서화됨.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.