FTSO 제공자 점수 방법론

알고리즘 버전: v4.11 · 마지막 업데이트: 2026-07-04

FlareWatch는 각 FTSO 데이터 제공자에게 12개 채점 차원 전반에 걸쳐 0~100의 복합 점수를 할당합니다. 계산은 결정론적이며, 입력값은 공개적인 온체인 및 Flare 생태계 데이터입니다.[Flaremetrics] [FSE] [Flare Explorer]이며, 동일한 알고리즘이 FlareWatch의 자신의 FTSO 제공자를 포함한 모든 제공자에게 적용됩니다. 특별 취급 없음. 이 페이지는 모든 차원과 임계값을 문서화하므로 위임자와 운영자는 점수가 정확히 어떻게 계산되고 각 값을 선택한 이유를 볼 수 있습니다. 여기의 모든 주장은 주요 업스트림 출처로 다시 연결됩니다. 출처 및 참고 맨 아래에.

범위: 이 페이지는 FTSO 제공자 점수를 문서화합니다 — 검증자 페이지의 delegation mode에 표시되는 것(FTSO 데이터 제공자에게 WFLR을 위임하여 FTSO 인플레이션 공유). staking mode에 표시되는 검증자 점수(P-Chain 검증자에게 FLR을 위임하여 VRM + MIRROR 보상)는 검증자 운영(업타임, 수수료, 신뢰성 등)에 중점을 둔 별도의 9차원 알고리즘을 사용합니다. 이들은 별개의 온체인 역할로 서로 다른 보상을 지급받으며 별도로 점수가 매겨집니다. 스테이킹 측면에 대해서는 검증자 점수 방법론을 참조하세요.
FLR / SGB 체인 커버리지: 검증자 페이지의 위임 탭에는 Songbird(SGB)를 보유한 지갑용 FLR / SGB 토글이 있습니다. 이 방법론은 FLR 측 점수만 문서화합니다. Songbird FTSO 제공자는 복합 점수 없이 나열됩니다 — FLR에 사용하는 동일한 정확도 / 일관성 / FSP 보상 데이터가 Songbird 파이프라인에 아직 연결되지 않았습니다(Flare의 주요 FLR 데이터 소스인 Flaremetrics가 Songbird를 지원하지 않음). SGB 위임자가 현재 보는 것: 크로스 네트워크 TowoLabs 레지스트리의 제공자 이름 + 로고, 현재 weight(WSGB 위임, Songbird의 WNat 계약에서 당사의 Songbird RPC를 통해 직접 읽음), 제공자의 URL. 가중치로 정렬하세요; 더 큰 가중치는 정확도 데이터가 나올 때까지의 프록시 신호입니다. Songbird 측 정확도 + 보상율 파이프라인을 연결하면, 동일한 13차원 공식이 SGB 제공자에 적용됩니다 — 새로운 점수 매기기 알고리즘이 아니라 Songbird 데이터에 대해 계산된 FLR 공식입니다. FlareWatch 검증자 점수 매기기(스테이킹 탭)는 SGB에 해당하는 것이 없습니다: Songbird의 P-Chain 검증자 세트는 Flare Foundation 승인 엔티티로 제한되어 있어 소매 SGB P-Chain 위임은 드물고 스테이킹 탭은 FLR 전용입니다.
점수 대역
90+최상위 등급 — FTSO 제공자의 상위 ~10–20%. 전형적인 프로필: 중앙값 이상의 보상율, 높은 정확도, 완전한 V2 프로토콜 참여(FTSO Scaling + Fast Updates + FDC), 낮음/수수료 없음, 대규모 위임자 기반, MIRROR 지불 검증자 노드, 명명된 브랜드. 필수적인 단일 차원이 없습니다 — 제공자는 대부분의 범주에서 강점을 쌓아서 최상위 등급에 도달합니다.
80–89강함 — 대부분의 주요 벤치마크를 충족; 최상위 등급에서 1~2개 차원 부족.
70–79좋음 — 모든 기본 기준을 충족; 주요 격차 없음.
60–69수용 가능 — 사용 가능하지만 차별화되지 않음.
<60중앙값 이하 — 1개 이상의 차원에서 상당한 격차. 수학적 사실이지 품질 판단이 아닙니다.
차원 (원 가중치 — 합계 172, 정규화 100)
"Active"는 두 가지 차원(수수료 및 V2 참여)을 제어합니다: 실행 중이 아닌 공급자는 낮은 수수료 광고에 대해 크레딧을 수집하지 않아야 합니다. 공급자는 게시된 보상률이 또는 Flare Systems Protocol 보상 데이터에 따라 채점 기간의 최소 하나 에포크에서 지급을 수행한 경우 활성으로 간주됩니다. 2026-07-31까지는 단일 제3자 API에서 제공된 보상률만 사용되었으므로, 해당 API에서 다루지 않은 공급자는 모든 에포크에서 명시적으로 보상을 배포하는 동안 두 차원 모두에서 0으로 계산되었습니다. 활성화는 공급자의 특성이지, 이를 나열하는 사람의 특성이 아닙니다.
보상율25 최대 포인트
무엇: 네트워크 중앙값에 고정된 제공자의 에포크당 보상율.
어떻게: 비율 = providerRate / medianRate. 선형: 비율 1.0(중앙값) → 12.5 포인트, 비율 2.0 → 25 포인트(상한). 비활성 제공자(rewardRate ≤ 0) → 0. v4.0 (2026-05-11): 중앙값이 차원의 포인트의 절반이 되도록 상한을 재조정(이전에는 40%).
if (rate <= 0 || medianRate <= 0): score = 0
else:
  ratio = rate / medianRate
  score = min(25, round(ratio * 12.5 * 10) / 10)   // 1 decimal place

// Anomaly detection: providers > 3× the median are capped at
// median × 3 for scoring purposes (prevents data outliers from
// distorting the linear curve).
왜: 보상율은 위임자가 경험하는 #1 사항입니다. 중앙값 고정은 네트워크의 보상 경제가 변할 때 점수를 정직하게 유지합니다 — 낮은 보상 시대에 중앙값의 1.2배인 제공자는 높은 보상 시대에 1.2배인 제공자와 동일하게 순위가 매겨집니다. 상한과 이상 필터는 단일 에포크 이상치가 지배하는 것을 방지합니다.
정확도25 최대 포인트
무엇: Flare Systems Explorer(FSE)의 FTSO 가격 정확성 — 주요(타이트한 IQR) 및 보조(더 넓은) 보상 밴드 도달률.
어떻게: FTSO 주요(타이트한 IQR) 및 보조(더 넓은) 밴드 도달률의 40/60 혼합(v4.8), Flare 자체의 보상 분할 반영 — FIP.11은 앵커 피드 보상을 40% 주요 / 60% 보조로 지급합니다. 보조는 이전 구간별 곡선 사용(97% → 25 … 70% → 2); 거의 전체 필드에서 포화(95–99%)되어 거의 구분하지 못합니다. 주요는 절대 선형 곡선 사용 — 28% → 0에서 78% → 전체 25 — 공급자가 실제로 ~28%에서 ~80%로 분산되는 훨씬 더 어려운 타이트 밴드 엔지니어링이 필드를 구분합니다. 고정 앵커(필드 백분위수 아님)이므로 점수는 공급자 자신의 입력값에서 재도출 가능합니다. 하나만 사용 가능할 때 단일 밴드 폴백; FSE 데이터 없을 때 중립 12.5.
if (fseAccuracySecondary > 0):
  pct = fseAccuracySecondary / 100
  if (pct >= 97) score = 25
  elif (pct >= 95) score = 18 + (pct - 95) * 3.5     // 95 → 18,  97 → 25
  elif (pct >= 93) score = 16 + (pct - 93) * 1       // 93 → 16,  95 → 18
  elif (pct >= 90) score = 13 + (pct - 90) * 1       // 90 → 13,  93 → 16
  elif (pct >= 85) score = 10 + (pct - 85) * 0.6     // 85 → 10,  90 → 13
  elif (pct >= 80) score = 6  + (pct - 80) * 0.8     // 80 → 6,   85 → 10
  else              score = max(0, 2 + (pct - 70) * 0.4)
elif (fseAccuracyPrimary > 0):
  // Primary fallback: similar piecewise linear curve.
else:
  score = WEIGHT_ACCURACY / 2   // Neutral — no FSE data
왜: 놓친 에포크 = 위임자의 놓친 보상 수입. 정확도는 제공자의 제출이 실제로 FTSO 합의에 포함되는지 여부를 결정하는 것이고, 보조 메트릭(더 최근의 에포크에 더 큰 가중치를 부여)은 현재 성능에 가장 깔끔하게 매핑되는 메트릭입니다.
일관성20 최대 포인트
무엇: 최근의 수익 에포크 전반에 걸친 제공자의 보상율이 얼마나 안정적인지.
어떻게: 제공자의 가장 최근 수익 에포크 간의 하향 변동성을 측정합니다. 실제로 연속된 에포크 간에만 비교합니다 — 제공자가 아무것도 얻지 못한 에포크는 기록이 남지 않으며, 그 갭의 양쪽 에포크는 절대 비교하지 않습니다. 에포크 간 하락만 계산됩니다 — 상승은 0으로 계산됩니다 — 따라서 안정적이거나 상승하는 요율은 거의 만점에 가까운 점수를 받으며 회복은 발생할 때 점수를 올립니다. 하락은 RMS로 집계되므로 큰 낙폭이 작은 낙폭보다 더 가중되며, 최근 쌍에 가중됩니다 (감쇠 0.8). 따라서 활발한 회복은 점수를 올리고 오래된 낙폭은 제거됩니다. cv = 0 → 20 pts; cv ≥ ~0.167 → 0. 지난 12개 수익 에포크에서 연속된 에포크 쌍이 3개 미만일 때 중립값은 10입니다.
earned = last 12 epochs where rewardRate > 0, keyed by epochId
pairs  = [earned[i-1], earned[i]] where epochId[i] - epochId[i-1] == 1
if (pairs.length < 3) return 10        // Neutral — too few consecutive pairs

// DOWNSIDE volatility only: rises never hurt, so a stable or RISING
// rate scores near full and a recovery lifts the score. Only drops
// between CONSECUTIVE epochs count, in proportion to depth (RMS),
// weighted toward recent pairs so an active recovery pulls the score up.
drops[i] = max(0, (prev - cur) / prev)     // rise -> 0
w[i]     = 0.8 ^ (age of pair)             // newest pair = highest
cv       = sqrt( sum(w[i] * drops[i]^2) / sum(w[i]) )
score    = max(0, round((1 - min(1, cv * 6)) * 20 * 10) / 10)
왜: 평균 보상률이 같은 두 제공자도 매우 다른 스테이커 경험을 제공할 수 있습니다: 급격하게 하락하는 제공자는 안정적이거나 상승하는 제공자보다 나쁩니다. 일관성은 위임자가 실제로 원하는 것 — 안정적이거나 상승하는 환율 — 을 보상하며, 하락분에 대해서만 깊이에 비례하여 패널티를 줍니다. 환율이 다시 올라가는 것은 절대 벌점을 받지 않습니다(이전의 대칭적 측정은 그랬는데 그것은 역방향이었습니다). 최근의 급격한 하락은 낮은 점수를 받다가 시간이 지나면서 회복되면서 소거됩니다.
V2 참여15 최대 포인트
무엇: 제공자가 최신 V2 스택(FTSO Scaling + Fast Updates + FDC)을 실행 중인지 여부.
어떻게: 프로토콜별 스택. 활성 기본선(rewardRate > 0) +3, V1 부분(제출 + 서명 + 투표자) +4, 각 V2 프로토콜(FTSO Scaling / Fast Updates / FDC) +~2.67 각각, 최대 15. 비활성 → 0. v4.0 (2026-05-11) 이전의 올 또는 무 등급(부분 V1 = 전체 V2 = 15 — 업그레이드 인센티브 없음)을 프로토콜별 보너스로 분할하여 스택.
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
왜: V2는 네트워크가 가는 곳입니다. v4.0의 프로토콜별 스택은 부분 V1에서 전체 V2로 업그레이드하는 것이 실제로 점수를 이동시킵니다(사전 수정에서는 그렇지 않았습니다 — 부분 V1과 전체 V2 모두 15를 반환했습니다). 이제 단일 V2 프로토콜을 추가하면 차원이 향상됩니다.
수수료15 최대 포인트
무엇: 제공자가 위임된 보상에 대해 청구하는 수수료.
어떻게: 중단점 전반의 선형 보간: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. 비활성 제공자 → 0.
anchor = max(lowest active fee observed, protocol fee floor)
// FIP-16 sets a 20% minimum entity fee. All 98 providers charge
// exactly 20%, so the anchor is 20% and nobody is docked for
// charging the only fee the protocol permits. Same curve and
// same anchor the validator page's Fee dimension uses.

if (!isActive) score = 0
d = fee - anchor              // distance ABOVE the best real offer
if (d <= 0)  score = 15       // at or below the anchor → full marks
elif (d <= 5)  score = 15 - d * 0.43
elif (d <= 10) score = 12.9 - (d - 5) * 0.64
elif (d <= 15) score = 9.6 - (d - 10) * 0.86
elif (d <= 20) score = 5.4 - (d - 15) * 1.07
else: score = 0               // extractive
왜: 수수료는 위임자가 받는 것을 직접 감소시킵니다. 선형 보간(버킷보다는)은 7% 수수료가 한 버킷으로 스냅하지 않고 10%와 15% 사이에서 점수를 받는다는 의미입니다 — 운영자는 수수료를 다음 버킷 경계로 반올림해서 내린다는 신용을 받지 않습니다.
MIRROR 참여12 (+3 보너스) 최대 포인트
무엇: 운영자의 P-Chain 검증자 노드가 활발하게 FTSO 인플레이션 공유를 스테이커에게 지급하는지 여부, 그리고 초과 성과 보너스.
어떻게: 기본 점수는 MIRROR 보상을 지급하는 운영자의 노드ID 비율에 따라 선형으로 변합니다. 모든 노드 활성 → 12점. 부분 활성 → 비례 배분. 없음 → 0. 2026-05-11 현재 '활성' 신호는 두 가지 정규 소스에서 읽혀집니다: V2 RewardManager의 온체인 RewardClaimed(claimType=3) 이벤트와 공식 FSP Merkle JSON의 claimType=3 할당 — 둘 중 하나면 충분합니다. 업데이트 전에는 온체인 스트림만을 신호로 사용했으며, 이는 비표준 청구 경로를 통해 MIRROR가 정산되는 공급자들에게 거짓 음성을 생성했습니다. 또한 운영자의 검증자가 예상 (vrm + mirror) / 예상 대비 100% 이상의 성과를 지속적으로 전달할 때 최대 +3점의 초과 성과 보너스가 있습니다 — 30일 데이터 축적 게이트와 최소 3개 스테이크 샘플을 포함한 베이지안 축소는 소규모 또는 신규 운영자가 몇 가지 운이 좋은 데이터 포인트에서 보너스를 악용하는 것을 방지합니다.
if (no fseNodeIDs) score = 0
if (mirrorStatsMap empty) score = 12 / 2 = 6   // Neutral seed before data lands

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

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

avgBonus = sum_per_node(bonus) / fseNodeIDs.length
score = round((base + avgBonus) * 10) / 10
왜: MIRROR 참여는 FTSO 인플레이션 셰어를 스테이커에게 위임하는 것입니다. V2 활성 공급자가 검증자 노드에서 MIRROR를 지급하지 않으면 활성 노드가 있는 동일한 공급자보다 위임자에게 약 5–15% 적은 수익률을 제공합니다. 초과 성과 보너스는 예상보다 지속적으로 더 나은 성과를 보상하면서 소규모 샘플에서 신규 운영자를 부풀리지 않습니다 — 베이지안 축소와 30일 축적 게이트가 공정성을 유지합니다.
위임자 수12 최대 포인트
무엇: 현재 이 제공자에게 위임하고 있는 서로 다른 지갑의 개수이며, 블록체인 상태에서 집계된 수입니다.
어떻게: 5 → 500명의 위임자를 0 → 12점으로 매핑하는 로그 스케일입니다. ≤5 → 0, ≥500 → 12 (상한). 검증자 신뢰 차원의 카운트 신호 스타일과 일치합니다. v4.0 (2026-05-11): 이전 버킷 스키마가 정확히 500명의 위임자에서 역효과적인 인센티브를 가지고 있던 실제 버그를 수정했습니다 (수정 전: 500 → 14, 501 → 12 — 해당 경계를 넘어 위임자를 얻으면 2점이 감소했습니다).
if (count <= 5)   score = 0
elif (count >= 500) score = 12
else:
  ratio = log(count / 5) / log(100)   // maps [5, 500] → [0, 1]
  score = round(min(12, max(0, ratio * 12)) * 10) / 10
왜: 위임자 수는 신뢰 신호입니다 — 스테이크 크기와 무관합니다. 200명의 위임자가 있는 공급자는 200명의 독립적인 스테이커에 의해 선택되었습니다. 5명의 위임자가 있는 공급자는 거의 운영자에 의해 선택되었습니다. 로그 스케일은 약 50명 이상의 위임자 이후 수익을 감소시키지만 역방향으로 절대 변하지 않습니다 (v4.0 이전의 버킷 방식처럼).
에포크 참여10 최대 포인트
무엇: 공급자가 에포크에 적극적으로 참여하고 있는지 여부입니다.
어떻게: FSE가 공급자를 활성으로 표시 → 10. 공급자의 rewardRate > 0 (Flaremetrics)이지만 FSE 활성 플래그 없음 → 7 (시장 데이터에서 활성이지만 FSE 확인 누락). 그 외 → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
왜: Flaremetrics가 여전히 나열하고 있더라도 보상 스트림이 정체된 공급자를 포착합니다. 정확도와 다릅니다 (정확도는 에포크당 정확성에 관한 것입니다) — 참여는 모두 나타나는 것에 관한 것입니다.
투표력 안정성10 최대 포인트
무엇: 공급자의 투표력의 일일 변화율입니다.
어떻게: 절대 일일 변화율의 구간별 선형입니다. <1% → 10. 1% → 3% (10 → 7)에서 선형. 3% → 5% (7 → 4)에서 선형. 5% → 10% (4 → 2)에서 선형. 10% 이상에서 0을 향해 계속됩니다. v4.0 (2026-05-11): 이전 버킷 절벽을 선형화했습니다 (각 임계값에서 최대 3점의 절벽이 있었습니다).
change = abs(votePowerDailyChangePct * 100)
if (change < 1)  score = 10
elif (change < 3) score = 10 - (change - 1) * 1.5     // 1 → 10, 3 → 7
elif (change < 5) score = 7  - (change - 3) * 1.5     // 3 → 7,  5 → 4
elif (change < 10) score = 4 - (change - 5) * 0.4     // 5 → 4, 10 → 2
else               score = max(0, 2 - (change - 10) * 0.1)
왜: 투표력의 큰 일일 변동은 종종 위임자 물결이 들어오거나 나가는 것을 나타냅니다 — 테이블을 읽는 스테이커는 변하는 목표를 봅니다. 안정적인 투표력은 정착된 공급자와 고정된 위임자를 신호합니다.
규정 준수10 최대 포인트
무엇: 공급자가 FSP 보상 데이터에서 활성화된 이후 모든 보상 에포크에서 지급되었는지 여부입니다.
어떻게: 공급자의 활성 기간 내에서 놓친 에포크가 없으면 전체 10점입니다. 놓친 각 에포크는 3점을 차감합니다 (0에서 고정). FSP 데이터를 사용할 수 없을 때는 중립 5점입니다. v4.4 (2026-06-30): 놓친 에포크는 이제 공급자의 첫 번째 참여 에포크 이후부터만 계산됩니다 — 신규 공급자는 더 이상 존재하기 전의 에포크에 대해 청구되지 않습니다 (이전에는 신규 공급자가 깨끗하더라도 몇 주 동안 0/10에 머물렀습니다).
if (no fspData OR totalEpochs <= 0) score = 5

// active window = epochs from the provider's first paid epoch to now
missed = (active-window epochs) - (epochs the provider was paid)
score = max(0, 10 - missed * 3)
왜: 공식 Flare Systems Protocol 보상 배포에서 놓친 에포크는 공급자가 해당 에포크에서 프로토콜 규정 준수를 실패했다는 의미입니다 — 최소 조건, 서명 정책 등. 첫 번째 참여부터만 계산하면 신규 공급자에게 공정하면서도 실제 누락에 대해 여전히 페널티를 줍니다. 누락당 3점은 가파르므로 한 번의 누락은 눈에 띄는 신호이지만 회복 가능합니다. 약 3회 누락은 이 차원을 0으로 만듭니다.
신원8 최대 포인트
무엇: 공급자가 실제 브랜드 이름을 가지고 있는지 또는 단지 16진수 주소일 뿐인지 여부입니다.
어떻게: 명명된 브랜드 (≥4자, 0x로 시작하지 않음) → 8. 짧거나 익명 (<4자) → 4. 순수 16진수 / 0x 주소를 이름으로 → 0.
if (no name) score = 0
elif (name starts with 0x or matches hex regex) score = 0
elif (name.length < 4) score = 4
else score = 8
왜: 명명된 공급자는 찾을 수 있고 책임질 수 있기로 선택했습니다 — 검색, 연락 및 공개된 약속에 대한 책임을 물을 수 있습니다. 주소별 익명 공급자는 기능적이지만 공급자를 평가하는 위임자에게 더 적은 신뢰 신호를 제공합니다.
자체 보증금7 최대 포인트
무엇: 운영자의 자체 P-Chain 노드 보증금 (게임에 참여) — 다른 사람이 노드에 위임한 스테이크 제외. 크기 중립적 약정 게이트이지 부의 순위가 아닙니다.
어떻게: 두 가지 포화 축의 더 큰 값에 대해 인정됩니다: (1) 정렬 — 총 약정 스테이크의 공유로 자체 보증금 (≥10% → 완전) 또는 (2) 절대 — 위험에 처한 자체 자본이며 5M FLR로 제한되므로 5M과 80M이 동일하게 채점됩니다. v4.4 (2026-06-30): 운영자의 실제 P-Chain 자체 보증금 (nodeID로 교차 참조된 검증자 가중치)에서 다시 소싱되었습니다 — 이전에 읽었던 Flaremetrics 필드는 중단되어 모든 공급자가 0점을 받았습니다. v4.5 (2026-06-30): 절대 축 + 포화를 추가했으므로 낮은 비율의 큰 자체 보증금이 높은 비율의 작은 자체 보증금보다 낮게 채점되지 않으며, 크기가 이기거나 소규모 운영자를 처벌하지 않습니다.
ownBond      = operator's own P-Chain node bond (FLR)
total        = ownBond + delegated WFLR vote power
alignment    = piecewise-linear ratio curve (0% → 0 … ≥10% → 7)
absolute     = min(7, ownBond / 5,000,000 * 7)   // saturates at 5M FLR
score        = max(alignment, absolute)
왜: 게임에 참여하는 것 — 자신의 자본이 위험에 처한 운영자는 위임자와 정렬됩니다. 하지만 자체 보증금 크기는 운영자 품질의 대리인이 아닙니다 (그것은 다른 차원에 있습니다). 따라서 작은 완전 정렬 운영자와 큰 약정 운영자 모두 만점을 얻습니다. 자체 자본이 거의 없는 운영자만 — 작은 공유와 작은 양 — 만점 미만으로 채점됩니다.
100/100을 얻는 방법 — FTSO 공급자 플레이북
v4.0 공정성 감시는 모든 채점 차원을 최대화하면 위임자를 위한 더 나은 FTSO 공급자가 되도록 특별히 설계되었습니다. 점수를 개선하는 것은 시스템을 악용하는 것이 아니라 시스템이 의도대로 작동하는 것입니다. 차원별 플레이북은 다음과 같습니다.
보상 요금 — 25점. 에포크당 네트워크 중앙값 FSP 보상 요금의 ≥2배를 전달하십시오 (수수료 후, 프로토콜 배포 후). 0에서 2배 중앙값까지 선형: 중앙값 → 12.5, 2배 중앙값 → 25. 왜 이것이 정렬되는지: 이것은 실제로 에포크당 위임자에게 도달하는 달러 금액입니다.
정확도 — 25점. FSE에서 ≥97% 보조 대역 착륙률을 목표로 전체 점수를 획득하십시오. 구간별 선형이므로 95% → 18, 93% → 16, 90% → 13 등입니다 — 1% 개선마다 점수가 움직입니다. 이것은 가격 품질이지 에포크 참여가 아닙니다: 제출된 가격이 온체인 허용 대역 내에 착륙한 비율을 측정합니다. 높은 정확도를 가진 공급자는 합의에 가까운 가격을 게시합니다. 낮은 정확도를 가진 공급자는 안정적으로 제출하지만 합의에서 더 자주 벗어났습니다. 왜 이것이 정렬되는지: 대역 외 제출은 공급자가 모든 에포크에 참여하더라도 더 적은 위임자 보상을 생성합니다. 아래의 별도 규정 준수 차원은 에포크 참여를 추적합니다.
일관성 — 20점. 에포크별 보상 요금 분산을 최소화하십시오 (CV = 최근 에포크 전체의 표준 편차/평균). CV = 0 → 20, CV = 0.2+ → 0. 왜 이것이 정렬되는지: 동일한 평균 보상 요금을 가진 두 공급자는 동등하지 않습니다 — 예측 가능한 지급이 위험한 지급보다 스테이커 UX를 능가합니다.
V2 참여 — 15점. 프로토콜을 가산식으로 쌓으십시오: 활성 기본선 + V1 부분 등록 + 각 V2 프로토콜 (확장, FastUpdates, FDC). 전체 V2 + 활성 + V1 등록 = 15. 왜 이것이 정렬되는지: V2는 네트워크가 가는 곳입니다. 채택하는 각 추가 프로토콜은 위임자가 이익을 얻는 전방 투자입니다.
수수료 — 15점. 13점의 경우 ≤5%, 15점의 경우 0%를 청구하십시오. 5%/10%/15%/20%/25% 중단점을 통한 구간별 선형 경사로 0. 왜 이것이 정렬되는지: 낮은 수수료 = 더 많은 보상이 위임자에게 직접 도달합니다.
MIRROR 참여 — 12 + 최대 3 보너스. 운영자의 모든 P-Chain 검증자 노드를 MIRROR 활성으로 실행하십시오 (온체인 RewardClaimed 이벤트 또는 FSP Merkle JSON 할당을 통해 — v3.6 이중 소스). 30일 관찰 후 3개 이상의 지급된 스테이크에서 지속적인 초과 성과 (중앙값 (vrm+mirror)/예상 비율 1.05 이상)는 최대 +3 보너스를 얻습니다. 왜 이것이 정렬되는지: MIRROR는 위임자의 FTSO 인플레이션 몫입니다. MIRROR를 지급하지 않는 노드는 스테이커에게 약 5-15% 적은 수익률을 제공합니다.
위임자 수 — 12점. 로그 스케일 5 → 500명의 위임자가 0 → 12로 매핑됩니다. 소수의 고래가 아닌 독립적인 스테이커의 기반을 구축하십시오. 왜 이것이 정렬되는지: 수는 스테이크 크기와 무관한 신뢰 신호입니다. 200명의 위임자가 당신을 선택하면 200명의 독립적인 승인을 의미합니다.
에포크 참여 — 10점. 양수 보상 요금과 활성 FSE 플래그로 모든 에포크에 나타나십시오. 왜 이것이 정렬되는지: 에포크별 차원이 놓칠 수 있는 정체된 보상 스트림을 포착합니다.
안정성 — 10점 일일 투표력 변화를 1% 미만으로 유지하세요. 그 이상은 선형 증가합니다. 왜 이것이 중요한가: 안정적인 투표력은 정착된 위임자(충성도 높은 커뮤니티)를 나타내며, 일시적인 대량 거래자의 변동과는 다릅니다.
규정 준수 — 10점 FSP 데이터에서 보상 에포크 미달 기록이 없어야 합니다. 각 미달은 3점 감소; 약 3회 미달 시 이 항목이 0점됩니다. 이것은 참여도입니다, 가격 품질이 아닙니다: 최소 조건 미충족, 서명 정책 또는 기타 프로토콜 요구사항으로 인해 제공자가 페널티를 받은 에포크를 계산합니다 — 위의 정확도 항목과는 다르며, 그것은 참여 에포크 내 가격 도출을 점수로 합니다. 왜 이것이 중요한가: 프로토콜의 보상 분배에서 미달 에포크는 제공자가 최소 조건을 충족하지 못했으며 그 에포크 동안 위임자들이 아무 보상도 얻지 못했다는 의미입니다. 제공자는 참여한 에포크에서 뛰어난 정확도를 가질 수 있으면서도 전체 에포크를 놓칠 수 있습니다.
신원 — 8점 Flaremetrics 또는 FSE에서 실제 브랜드 이름(≥4자, 16진수 주소 아님)을 등록하세요. 익명 주소 제공자는 0점; 명명된 제공자는 8점입니다. 왜 이것이 중요한가: 명명된 제공자는 추적 가능하고 책임이 있습니다; 이것이 기본 신뢰 신호입니다.
자기자본금 — 7점 자신의 P-Chain 노드 본드를 커밋하세요(다른 사람들이 위임한 스테이크가 아님). 전체 스테이크의 의미 있는 비중(≥10%) 또는 의미 있는 절대 금액(절대 축은 500만 FLR에서 포화되므로 대규모 운영자가 크기로 소규모 운영자를 초과할 수 없음)에 대해 만점입니다. 왜 이것이 중요한가: 자신의 자본을 위험에 처한 운영자는 위임자들의 수익률 결과를 공유합니다. 이것은 규모 중립적 커밋먼트 게이트이지, 부의 순위가 아닙니다: 완전히 정렬된 소규모 운영자와 큰 커밋된 운영자 모두 최고점을 받으며, 운영 품질은 다른 항목들로 판단됩니다.
단축할 수 없는 시간 제한 신호: 일관성은 ≥3개 에포크의 기록이 필요합니다. MIRROR 초과 성과 보너스는 30일 관찰 기간 플러스 ≥3개 지불된 스테이크 샘플이 필요합니다. 규정 준수는 에포크를 계산할 수 있을 만큼 충분한 기간의 FSP 데이터가 필요합니다. 추적 기록을 구축하세요; 점수가 따를 것입니다.
원점수는 12개 채점 차원 전체에서 최대 172점으로 합산되며, 그 후 100으로 정규화됩니다. 입력값에 대한 완벽한 점수는 172/172 → 100으로 표시됩니다. 매우 큰 제공자(>1.34B VP)에 대해 투표력 희석 패널티 최대 −3점이 동점 결정자로 적용됩니다.
자신의 점수를 확인하는 방법
제공자 테이블의 모든 점수는 공개 데이터에서 재현 가능합니다. 운영자이고 여기의 수학이 표시되는 점수와 맞지 않으면, 올바른 조치는 우리가 실수했다고 가정하기 전에 직접 확인하는 것입니다. 단계별 설명:
  1. 제공자의 공개 통계를 확인하세요 flaremetrics.io에서 (이름으로 검색하거나 위임 주소를 붙여넣으세요). fspRewardRate, delegationFeePercentage, wNatWeight, 및 votePowerDailyChangePct를 기록해 두세요.
  2. FTSO V2 + 정확도를 확인하세요 flare-systems-explorer.flare.network에서. 엔티티를 찾으세요. 정확도는 providersuccessrate.secondary를 확인하고, V2 상태는 entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc 플래그를 확인하세요.
  3. MIRROR 참여를 확인하세요 V2 RewardManager 계약에서 flare-explorer.flare.network를 통해. RewardClaimed 이벤트를 찾으세요. claimType=3과 함께 nodeID를 참조합니다. 노드 중 최근에 없으면 점수에서 MIRROR 비활성으로 표시됩니다.
  4. 위의 공식에 입력값을 대입하세요. 각 차원의 코드 블록은 실행할 정확한 산술을 알려줍니다. 차원들을 합산하고, 172 (원 최댓값)로 나누고, 100을 곱하면 원 종합 점수를 얻습니다.
  5. 대규모 운영자라면 희석 페널티를 적용하세요. 투표력이 13.4억 이상이면 −3, 10억 이상이면 −1입니다. 아래의 최종 점수 카드에 정확한 임계값이 있습니다.
  6. 표시된 점수와 비교하세요. 표시된 점수는 또한 동적 가중치 재분배를 반영합니다 — 대부분의 제공자가 항목에 집중할 때(활성 집합 전체에서 표준편차가 낮을 때), 그 항목의 가중치는 스프레드가 더 넓은 항목으로 재분배됩니다. 각 제공자 행의 점수 분석 패널은 현재 항목별 값을 보여줍니다.
  7. 수학이 맞지 않으면, [email protected]로 위임 주소, 사용한 입력값, 계산한 점수와 함께 이메일을 보내세요. 우리가 응답하고, 오류가 있었다면 공개적으로 수정할 것입니다.
일반적인 운영자 관심사
내 보상율은 중간값보다 높지만 보상율 점수가 25/25가 아닙니다 — 왜인가요?
보상율은 중간값 대비 비율로 선형입니다: 점수 = 비율 × 12.5, 따라서 1.0× 중간값 = 12.5/25이고 상한을 적중하려면 2.0× 비율이 필요합니다. 중간값의 1.2배 제공자는 15점, 1.5×는 약 18.8점, 2.0×는 전체 25점을 얻습니다. 상한(플러스 3×-중간값 이상 필터)은 단일 이상적으로 높은 보상 에포크가 항목을 지배할 수 없도록 존재합니다; 보상율이 일관되게 상위 10분위수라면, 점수는 여전히 크게 보상합니다.
방금 V2로 업그레이드했습니다 — V2 점수는 언제 업데이트되나요?
V2 상태는 FSE의 entityminimalconditionslatest 플래그(ftso_scaling, ftso_fast_updates, fdc)에서 나옵니다. v4.0 이후 항목은 프로토콜당 스택됩니다: 활성 기본값 +3, V1 등록(제출 + 서명 + 투표자) +4, 각 V2 프로토콜 +약 2.67. 따라서 제출 + 서명 주소가 있지만 세 개의 V2 프로토콜이 없는 투표자 등록 제공자는 7/15를 얻고, 활성화하는 각 개별 V2 프로토콜이 점수를 이동시킵니다 — 세 개 모두 라이브이면 전체 15를 얻습니다. 변경사항은 FSE가 반영한 후 FlareWatch 크론 실행 시 적용됩니다(5분마다).
FSE에서 정확도는 96%이지만 예상보다 낮게 점수를 받고 있습니다.
정확도 항목은 FSE의 보조 정확도 메트릭을 사용합니다(94–97% 대역에서 더 높은 해상도, 대부분의 제공자가 집중된 곳). 95–96%는 18점에 매핑됩니다; 전체 25점을 받으려면 ≥97%이 필요합니다. 상단의 버킷은 95–97% 대역의 몇 십분의 1 퍼센트가 제공자 간의 실제 성과 분리를 나타내므로 타이트합니다.
MIRROR를 제공합니다 — FlareWatch는 왜 제 제공자를 MIRROR 비활성으로 표시하나요?
2026-05-11 현재, MIRROR 참여는 두 소스에서 감지됩니다: V2 RewardManager의 온체인 RewardClaimed(claimType=3) 이벤트, AND 공식 FSP Merkle JSON의 claimType=3 할당. 어느 소스에든 나타나는 nodeID는 활성으로 계산됩니다. 다중 노드 운영자의 경우 점수는 활성인 노드의 비율을 사용합니다(1/3 활성 = 4/12 기본값 등). nodeID가 활성이어야 하지만 다음 스윕 사이클 후 활성이 아니면, 노드ID와 나타낼 것으로 예상되는 특정 에포크와 함께 이메일을 보내세요 — 두 소스를 모두 확인하겠습니다.
어제 투표력이 8% 이동했습니다 — 안정성 점수가 약 2.8/10인 이유는?
투표력 안정성은 절대 일일 변화(v4.0에서 선형화 — 버킷 절벽 없음)에서 구간별 선형입니다: <1% → 10, 1→3% 램프 7로, 3→5% 4로, 5→10% 2로, 그 후 10% 이상은 0 방향으로 향합니다. 8% 이동은 5–10% 램프에 착지합니다 4 − (8 − 5) × 0.4 = 2.8. 의도는 의미 있는 위임자 이탈을 경험하는 제공자를 플래그하는 것이므로 스테이커는 테이블에서 이를 볼 수 있습니다. 투표력이 안정화되는 즉시 점수가 회복됩니다; 하나의 변동성 있는 날은 당신을 영구적으로 낮게 고정하지 않습니다.
제 제공자는 엔티티 주소(0x…)로 이름이 지어졌습니다. 신원 점수가 0인 이유는?
신원은 실제 브랜드 이름(≥4자, 0x로 시작하지 않거나 16진수만 아님)에 대해 8점을 부여하고 순수 주소 이름에 대해 0점을 부여합니다. 우리는 이름을 만들 수 없습니다 — Flaremetrics에서 profile.name을 설정하면 다음 크론 실행에서 선택됩니다. 엔티티에 프로필이 있지만 이름 필드가 비어 있으면, 동일하게 적용됩니다.
작지만 충성도 높은 위임자 기반이 있습니다 — 위임자 수 점수가 제한되는 이유는?
위임자 수는 실제 집계를 사용합니다: WFLR을 보유하고 있는 모든 지갑을 온체인에서 검사하여 현재 위임 상태를 확인하고, 각 제공자의 서로 다른 위임자 수를 집계합니다(약 6시간마다 새로고침되며, 독립적인 이벤트 원장과 상호 검증됨). v4.0부터 5 → 500명의 위임자가 0 → 12점으로 로그 스케일링되며 최대 500명으로 제한됩니다(≤5는 0점 획득). 로그 스케일링은 위임자 수 증가가 빠른 소규모 제공자가 가장 빠르게 상승함을 의미하며, 약 50명의 위임자 이후에는 추가 위임자가 점수에 미치는 영향이 적어집니다 — 다만 곡선은 단조증가하므로 위임자를 추가하면 절대 점수가 낮아질 수 없습니다(이전 v4.0의 구간 방식에서는 가능했음).
노드를 추가한 후 점수가 떨어졌습니다 — 무슨 일이 일어났나요?
새 노드가 아직 claimType=3 MIRROR 이벤트를 표시하지 않으면, MIRROR 비율이 떨어집니다(예: 1/1 = 100%에서 1/2 = 50%), MIRROR 참여 기본 점수를 줄입니다. 새 노드가 MIRROR 지불을 시작하면(일반적으로 활성화 후 1~2개 보상 에포크), 비율이 회복되고 점수가 올라갑니다.
점수에 항소하거나 수동 검토를 요청할 수 있나요?
네. [email protected]로 위임 주소와 구체적인 관심사를 함께 이메일을 보내세요. 모든 운영자에게 응답합니다. 우리가 조치할 사항: MIRROR 분류 수정, 항목별 수학 오류, Flaremetrics를 통한 이름/로고 수정. 우리가 조치하지 않을 사항: 알고리즘 외에서 점수를 수동으로 올려달라는 요청, 경쟁자를 제외하거나 순위를 내려달라는 요청.
하는 것과 하지 않는 것
점수 운영 방식에 대한 모호함을 제거하기 위해, 명시적 커밋먼트가 있습니다. 이 중 하나를 위반하면, 기록하고 [email protected]로 이메일을 보내세요 — 공개적으로 수정하겠습니다.
✓
더 높은 점수, 후원 배치 또는 어떤 종류의 유리한 대우에 대한 지불을 받지 않습니다. 점수는 공개 데이터에서 결정론적으로 계산됩니다.
✓
제공자별 수동 부스트를 코드하지 않습니다. 코드 어디에도 "X는 우리가 좋아해서 +5를 받음"라는 줄이 없습니다. 동일한 알고리즘이 FlareWatch 자신의 제공자를 포함한 모든 제공자에 적용되며, 이는 이 정확한 함수로 점수가 매겨집니다.
✓
비공개 이유로 테이블에서 제공자를 제외하지 않습니다. 목록은 Flaremetrics + FSE에서 소싱되며; 우리의 표시는 이 소스들이 표면화하는 모든 활성 제공자를 포함합니다.
✓
알고리즘 변경 사항을 공개합니다. 모든 버전 업데이트는 이 페이지의 버전 카드에 문서화되며, 주요 변경 사항은 앱의 변경 로그 페이지에서 볼 수 있는 추가 항목이 포함됩니다.
✓
운영자 이메일에 응답합니다. [email protected]로 점수에 대한 실질적 문제를 이메일로 보낸 모든 운영자는 영업일 기준 며칠 내에 실제 답변을 받습니다.
✓
우리의 실수를 공개적으로 수정합니다. 알고리즘의 버그, 데이터 소스 오류 또는 방법론 격차를 발견하면 수정 사항을 배포하고 문서화합니다. 조용히 순위를 변경하지 않습니다.
✗
발신자의 허락 없이 이메일 내용을 공개적으로 공유하거나, 운영자 이메일을 점수 대화 목적 이외의 다른 용도로 사용하지 않습니다.
✗
선택된 운영자에게 미리 알고리즘 변경 계획을 공유하지 않습니다 — 모든 버전은 동시에 모든 사용자에게 배포됩니다.
최종 점수(차원 조합 방식)
12개의 채점 항목이 모두 합산되어 원시 복합점수(최대 172)를 생성합니다. 원시 복합점수는 0–100 범위로 정규화되고, 최종 표시 점수를 도출하기 위해 동적 가중치 재분배가 적용됩니다.
// Step 1 — Raw composite (sum of 12 dimensions, max 172)
raw = rewardRate + accuracy + consistency + v2 + fee + mirror
    + delegators + participation + stability + compliance
    + identity + selfBond

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

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

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

// Step 3 — Final score (capped at 100)
score = min(100, final)
상한 근접도는 표시 신호이며, 점수 감점이 아닙니다. v4.9까지 점수는 매우 큰 제공자로부터 고정 1–3점을 차감했지만, 이는 중복 계산되었습니다. 상한을 초과한 제공자는 이미 중앙값 기준 중앙값 이하의 실현 보상률을 얻으며, 이는 중앙값 기준의 보상률 항목에서 이미 점수화됩니다. 따라서 이 감점은 제거되었습니다. 이제 모든 제공자는 FSP 상한(WNat 계약의 live 총 투표력의 2.5%)을 얼마나 차지하는지를 중립적인 한계 위임 신호로 표시합니다. 100%에 가까울수록 새로운 위임의 희석도 커집니다.
표시 계층 이상치 플래그: 현재 보상률이 필드 중앙값보다 강건 편차 3개 이상(중절대편차, ×1.4826 배율 적용) 높고 최소 50% 이상 높은 제공자는 제공자 테이블에 이상치 배지를 표시합니다. 배지는 스코어를 변경하지 않으며, 스코어의 자체 이상 탐지 기능은 스코어링 전에 중앙값의 3배 이상인 보상률을 별도로 제한합니다. 연간 에포크 보상률 급증은 보통 매우 작은 투표력에서 비롯되며 에포크 내에 정상화됩니다.
데이터 소스(모든 입력은 공개)
Flare 계약, 온체인에서 직접 읽음: 등록된 공급자 집합(VoterRegistry), 엔티티 → 위임 주소 및 nodeID 링크와 제출/서명 주소 등록(EntityManager), 위임된 투표력(WNat), 위임 수수료(WNatDelegationFee). 이것이 공급자 목록을 단일 인덱스와 무관하게 만드는 것입니다: 보상 에포크 420에서 체인은 제3자 목록의 80개 대비 등록된 공급자 98개를 유지했으며, 차이의 18개는 이전에 이 사이트에서 전혀 없었습니다.
Flaremetrics 공개 API: 보상률, 위임 수수료, 투표력, 투표력 일일 변화, 잠금된 투표력(자체 담보), 프로필 이름 + 로고 + 지역, fspRewardRate.
Flare Systems Explorer (FSE): FTSO 정확도(1차 + 2차), V2 상태 플래그(ftso_scaling, ftso_fast_updates, fdc), 엔티티 주소 연결, 서명/제출 주소 존재, 투표자 등록, P-Chain nodeID 연결, 엔티티별 위임 보상률(reward_rate_wnat). 보상률은 의도적으로 FSE와 Flaremetrics 두 곳에서 소싱됩니다. 이들은 서로 다른 단위(FSE 소수, Flaremetrics 백분율 - 두 소스를 모두 보유한 72개 제공자 모두에서 소수점 이하 5자리까지 동일함을 확인)로 동일한 수치를 게시하며, FSE는 Flaremetrics의 80개에 비해 154개 엔티티를 다룹니다. 단독 소스만으로는 제공자의 잘못이 아님에도 불구하고 보상률이 없는 제공자들을 남겨둡니다.
Flare Systems Protocol 보상 데이터(FSP): 제공자별 에포크별 보상 분배, Compliance 차원(보상 없는 에포크 계산)과 위임 보상 총액의 권한 있는 소스로 사용됩니다.
V2 RewardManager(claimType=3 이벤트): 검증자 nodeID별 청구된 MIRROR 분배(온체인). 유형 3에서 엄격히 필터링됨 — VRM, FTSO 위임 또는 DIRECT 보상과 혼동되지 않음. FlareWatch의 자체 인덱서가 MIRROR 참여 차원을 위해 이를 표시합니다.
FSP Merkle JSON(claimType=3 할당): 에포크별로 누가 MIRROR를 받을 자격이 있는지의 공식 발행 기록(Flare의 자체 서명 도구가 읽는 동일한 데이터). 2026-05-11에 두 번째 권한 있는 소스로 추가됨 — MIRROR가 할당되었지만 아직 온체인에서 청구되지 않은 검증자를 포착합니다.
FlareWatch 기록 스냅샷: 에포크별 보상률은 Consistency CV를 공급하고, 검증자별 지불된 스테이크 관찰은 MIRROR 초과성과 보너스를 공급합니다(30일 데이터 축적 게이트 포함).
점수에 포함되지 않는 것
• 자체 홍보 또는 유료 배치. 제공자가 더 높은 점수를 위해 비용을 지불하거나 후원할 수 없습니다.
• 수동으로 코딩된 제공자별 상향 조정. 코드의 어디에도 "X는 우리가 좋아하므로 +5"라는 라인이 없습니다. 동일한 알고리즘이 FlareWatch의 자체 제공자를 포함한 모든 제공자에게 적용되며, FlareWatch의 제공자는 이 정확한 함수로 점수가 매겨집니다.
• 주관적 인프라 품질. FSE 및 Flaremetrics가 공개 데이터로 표시하는 것 이상으로 가동 시간 SLA, 지리적 분포 또는 하드웨어 사양을 평가하려고 하지 않습니다.
• FlareWatch의 잠금 또는 약정. FlareWatch와 다른 도구를 사용하는 스테이커에 대한 유리한 점수 지정이 없습니다.
• 아직 연결되지 않은 향후 신호. 커뮤니티 존재(검증된 소셜, 거버넌스 참여), 역사적 슬래싱, 응답 지연 시간 및 에포크별 추세선은 향후 버전으로 계획되어 있지만 현재 v3에는 포함되어 있지 않습니다. 어느 것도 비밀리에 가중되지 않습니다.
운영자 피드백
제공자의 점수에서 이상한 점을 발견하신가요? 위임 주소와 문제를 [email protected]로 이메일로 보내주세요. 모든 운영자에게 응답합니다. 우리가 조치할 일반적인 요청:
  • MIRROR 분류 수정(nodeID에 대한 claimType=3 귀속).
  • 사용한 입력으로 인한 차원별 수학 오류.
  • Flaremetrics 또는 FSE를 통한 이름/로고/프로필 수정.
  • 일반 알고리즘 비평.
소스 및 참고 자료
점수에 대한 모든 입력은 공개되고 검증 가능한 Flare 생태계 소스에서 나옵니다. 누구나 이 주요 소스에 대해 우리의 주장을 교차 확인하고 원본 데이터로부터 수학을 재현할 수 있습니다. 이 페이지와 업스트림 소스가 말하는 것 사이의 불일치를 발견하면 [email protected]로 이메일을 보내고 우리가 수정하겠습니다.
Flare Network 프로토콜 문서 ↗https://docs.flare.network
권위 있는 프로토콜 문서. FTSO V2, FSP, P-Chain 검증, FAssets 및 나머지 Flare 스택을 다룹니다.
Flare 거버넌스 포털(FIPs) ↗https://proposals.flare.network
Flare 개선 제안 — V2 프로토콜 최소 조건, 수수료 역학 및 이 점수에 영향을 주는 보상 경제 변경의 진실 공급원입니다.
Flare Systems Explorer(FSE) ↗https://flare-systems-explorer.flare.network
FTSO 데이터 제공자, 엔티티 주소, P-Chain nodeID 연결 및 최소 조건 플래그의 공식 Flare 운영 레지스트리. 정확도, V2 및 참여 차원의 주요 소스입니다.
Flaremetrics ↗https://flaremetrics.io
독립적인 Flare 생태계 메트릭 제공자. 보상률, 수수료, 투표력, 투표력 일일 변화, 잠금된 투표력, 프로필 이름 + 로고 및 fspRewardRate 메트릭의 소스입니다.
Flare 블록 탐색기 ↗https://flare-explorer.flare.network
모든 온체인 상태의 읽기 전용 브라우저. V2 RewardManager의 RewardClaimed 이벤트(MIRROR용 claimType=3), 보상 에포크 전환 및 나머지를 확인할 수 있습니다.
Flare Foundation reward-scripts 저장소 ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation에서 발행한 에포크별 검증자 전달 보상을 보여주는 보상별 JSON입니다. 간접 입력 — FlareWatch의 스테이크별 관찰 인덱서를 통해 MIRROR 초과성과 보너스 계산을 공급합니다.
Flaremetrics 공개 API (FTSO 제공자) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
우리의 크론이 소비하는 정확한 엔드포인트로, 엔티티 프로필, 보상률, 수수료 및 투표력을 반환합니다. 누구나 직접 액세스할 수 있습니다.
Flaremetrics 공개 API (노드 등록) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID 변환 테이블. MIRROR Participation 차원을 주도하는 엔티티-to-NodeID 룩업을 구축하기 위해 페이지네이션합니다.
개인정보 없음, 비공개 모델 없음. 점수 알고리즘은 FlareWatch 코드베이스의 services/ftso/scoring.ts에 구현되어 있습니다. 구현을 직접 검토하거나 (위의 설명 및 공식을 읽는 대신) 자신의 사용을 위해 포크하려는 운영자 또는 연구자는 [email protected]로 이메일을 보내 액세스를 요청할 수 있습니다. 실제 수요가 있으면 파일을 독립형 오픈소스 패키지로 게시할 것입니다.
점수 업데이트 방식
FTSO 제공자 점수는 /api/cron/refresh-validators의 크론 내 패스로 실행되며, 활성 제공자의 점수를 5분마다 다시 계산합니다 (P-Chain 검증자를 다시 점수하는 동일한 실행). 입력값 (Flaremetrics, FSE, FSP 보상, V2 RewardManager 이벤트)은 매 실행마다 새로 가져옵니다.
일관성 CV는 최근 에포크 히스토리를 사용합니다 — 차원은 롤링 윈도우가 이동하면서 변할 수 있습니다. 3개 미만의 역사 에포크를 가진 신규 제공자는 충분한 데이터가 누적될 때까지 중립 10으로 점수가 매겨집니다.
동적 가중치 재분배는 매 실행마다 현재 활성 제공자 집합을 기반으로 다시 계산됩니다. 제공자가 이동하면 (예: V2 업그레이드 물결) 차별적이지 않은 차원이 변하고 재분배가 자동으로 조정됩니다.
알고리즘 버전은 이 페이지의 헤더에 표시됩니다. 새 버전을 출시하면 여기의 버전 문자열이 변경되고 아래의 Versions 카드에서 변경 사항을 문서화합니다.
버전
v4.8 (2026-08-20) — 정확성은 이제 어려운 보상 밴드를 보상합니다. 이전에는 오직 FTSO 보조(더 넓은) 밴드만 사용했으며, 거의 모든 진지한 공급자가 95–99%에 도달합니다 — 따라서 이 차원은 경쟁 상위권에서 거의 25/25로 평탄했으며, 거의 아무것도 측정하지 못했습니다. 주요(타이트한 IQR) 밴드는 정말 어려운 엔지니어링이며 공급자를 ~28–80%로 분산시킵니다. Flare는 이 밴드들에 40% 주요 / 60% 보조로 보상하며(FIP.11, 2024년부터 시행, 추가 보조 밴드 증가 신호됨), 따라서 정확성은 이제 그것을 반영합니다: 40/60 혼합. 보조는 이전 곡선 유지; 주요는 절대 곡선 사용(28% → 0, 78% → 전체 25), 점수가 공급자 자신의 입력값에서 재도출 가능하도록 고정. 배포 전에 점수가 매겨진 모든 100개 공급자에 대한 완전한 사전/사후, 배포 전 보관: 순서 변경은 주요 밴드 강도 추적 — 어려운 타이트 밴드 작업을 하는 공급자는 상승, 쉬운 보조 숫자에만 의존하는 공급자는 하락합니다. 동일한 규칙이 우리 자신의 공급자에게 적용되며, 현재 약한 주요 밴드를 가지고 있습니다: 84에서 77로 떨어지고 여러 순위 하락합니다. 어쨌든 배포했습니다 — 진정한 엔지니어링을 보상하는 점수, 경쟁사의 것이고 우리 비용이 드는 경우에도, 가 유일하게 공개할 가치가 있기 때문입니다.
v4.7 (2026-07-31) — 제공자 목록이 단일 인덱스에 대한 의존성을 제거했으며, 점수는 자체 데이터 누락을 더 이상 처벌하지 않습니다. (1) 목록은 이제 온체인 등록 투표자 집합에서 구축되고 제3자 인덱스가 엔티티를 누락한 곳에서 백필됩니다. 이전에 표시된 80개 대비 98개 제공자로, 이전까지 검색 불가능하고 여기서 위임 불가능했던 실제 제공자 18개가 이제 나타납니다. (2) "활성"은 "해당 인덱스로부터 보상률 보유"를 의미했으며, 자체 FSP 데이터가 매 에포크마다 지급을 보여주고 있었음에도 불구하고 모든 백필 제공자에 대해 수수료(15) 및 V2(15) 차원을 0으로 만들었습니다. 이제는 배포 증거를 수락합니다. (3) 누락된 보상률은 더 이상 전체 분모에 대해 0점을 받지 않습니다. 25포인트 가중치는 분모에서 벗어나므로 제공자는 측정한 항목에 대해 채점되며 측정할 수 없는 항목에 대해 페널티를 받지 않습니다. (4) 수수료 차원은 여전히 FIP-16 이전 곡선에서 채점되었으며, 0% 수수료는 만점을 얻었습니다. FIP-16은 20%를 최소 법정 엔티티 수수료로 설정하고 98개 제공자 모두 정확히 그만큼을 청구합니다. 따라서 이 차원은 전체 필드에 0 분산으로 4.00/15을 부여했습니다. 아무도 얻을 수 없는 11포인트는 최고 점수를 포함한 모든 공개 점수에서 약 4.3포인트를 뺍니다. 수수료는 이제 max(관찰된 최저 수수료, 프로토콜 하한선)에 고정됩니다. 이는 Granite 포크 이후 검증자 페이지가 고정한 방식과 동일합니다. 법정 최소값을 청구하면 만점을 받고, 그 이상의 수수료만 거리에 따라 페널티를 받습니다. 이는 모든 점수를 비슷한 정도로 올리고 순위를 변경하지 않습니다. 공개된 보상률이 있는 제공자는 변경 사항 (1)~(3)의 영향을 받지 않습니다. 보상률이 추정되거나 추론되지 않습니다. 해당 행은 "데이터 없음"으로 표시됩니다. (5) 보상률은 더 이상 단일 인덱스에 의존하지 않습니다. 이전에는 Flaremetrics에서만 읽혔으므로 해당 인덱스가 다루지 않는 제공자는 순이 및 총 APR을 잃고 보상률에서 0/25점을 받았습니다. 이는 다른 누군가의 범위 부족으로 인한 25포인트 페널티입니다. Flare Systems Explorer는 동일한 수치를 게시하고 더 많은 엔티티를 다루므로, 이제 모든 간격을 채웁니다. 실시간 Flaremetrics 보상률은 절대 덮어써지지 않습니다. 이것이 배포된 날, 이전까지 없었던 15개 제공자에 공개된 보상률을 복원했습니다.
v4.6 (2026-07-01) — 새 노드에 대해 일관성 편향 제거. 이전에는 전체 30-에포크 히스토리에 대한 보상률의 평균/표준편차였으므로, 새 노드의 램프-인플레이션된 첫 획득 에포크 (작은 투표력 → 높은 단위별 요율, 이후 정규화)가 이후 수개월간 CV를 높게 고정하여 0점을 받는 이상치로 작용했습니다. 이제 후행 윈도우 (최근 12개의 획득 에포크)와 견고한 중앙값/MAD 분산을 사용하므로 램프 에포크는 해로운 이상치이면서 진정한 지속적 변동성은 여전히 낮은 점수를 받습니다.
v4.5 (2026-06-30) — Self-Bond 크기 중립화. 비율 전용 곡선은 낮은 비율의 큰 절대 자금을 높은 비율의 작은 자금보다 낮게 점수할 수 있었습니다. Self-Bond는 이제 정렬 비율 또는 포화 절대 금액 (5M FLR 상한선)의 더 큰 값을 인정하므로, 큰 약정 운영자와 완전히 정렬된 작은 운영자 모두 만점을 얻습니다 — 이는 부의 아닌 약정을 보상하며 검증자 품질은 다른 차원에 남아 있습니다.
v4.4 (2026-06-30) — 두 가지 실제 버그 수정. (1) Self-Bond는 데드 차원이었습니다: API가 드롭한 Flaremetrics 필드를 읽어서 모든 제공자가 0/7을 점수했습니다. 검증자 집합에서 nodeID로 교차 참조하여 운영자의 실제 P-Chain 노드 자금에서 다시 소싱했습니다. (2) Compliance는 제공자가 활성화되기 전의 에포크를 패널티했습니다 — 출시 이후 깔끔하게 획득한 신규 노드는 이전에 이를 선행하는 모든 에포크에 대해 청구되어 수주간 0/10을 유지했습니다. 놓친 에포크는 이제 각 제공자의 활성 윈도우 내에서만 계산됩니다.
v4.3 (2026-06-03) — 방법론 명확화, 점수 수학 변화 없음. Accuracy 차원은 이제 명시적으로 온체인 보조 대역 도달률 (가격 품질 — 제출된 가격 중 수용 대역 내에 도달하는 비율)로 정의되며, Compliance 차원과 구별되며, Compliance는 놓친 보상 에포크를 계산합니다 (FSP 참여). 이 페이지와 검증자-테이블 툴팁이 구별을 명시적으로 만들기 위해 다시 작성되었고, Accuracy와 함께 Compliance 열이 추가되었습니다. 두 차원 모두 이전 가중치 (25 및 10)와 입력값 (fseAccuracySecondary 및 epochsWithoutRewards)을 유지합니다.
v4.2 (2026-05-20) — Rewards Distributed 차원 수리. 제공자의 v3 API가 드롭한 Flaremetrics 보상-분배 필드에 연결되어서 차원이 모든 제공자에 대해 0을 읽었고 아무것도 기여하지 않았습니다. 온체인 FSP 위임-보상 총액에 다시 연결했습니다 — Compliance 차원이 이미 집계하는 동일한 보상-청구 데이터입니다 — 차원이 다시 구별되므로.
v4.1 (2026-05-20) — Compliance 차원 제한. epochsWithoutRewards는 FSP 보상 크론이 롤링 윈도우를 넘어 에포크-현재 수를 누적하여 음수로 올 수 있으며, 이를 통해 Compliance가 10점 상한선을 초과하고 (약 ~58까지 관찰됨) 복합을 최대값을 초과하도록 밀어 약 70%의 제공자를 평탄한 100으로 포화시켰습니다. Compliance는 이제 가중치로 제한되며, FSP 크론은 윈도우당 비상태적으로 보상 요약을 다시 계산하므로 수는 더 이상 드리프트할 수 없습니다.
v4.0 (2026-05-11) — 검증자 점수의 v4.0 출시와 동등한 전체 공정성 감사 패스. 두 가지 실제 버그 수정: (1) Delegator Count는 500에서 역설적 인센티브가 있었습니다 — 수정 전 500-위임자 버킷은 14pts를 반환했지만 >500 상한선은 기본 WEIGHT_DELEGATORS (12)를 반환했으므로, 그 경계를 넘어 위임자를 얻으면 2점이 손실되었습니다. 이제 5 → 500에서 로그 스케일, 단조 상향. (2) V2 Participation 티어는 축소되었습니다 — 부분 V1 등록과 전체 V2 (Scaling + FastUpdates + FDC) 모두 15를 반환했으므로, 부분에서 전체 V2로 업그레이드하는 것은 점수 개선이 없었습니다. 이제 프로토콜별 스택 (활성 +3, V1 +4, 각 V2 프로토콜 +~2.67). Accuracy (97%에서 7점 절벽이 있었음), Stability 및 Self-Bond Ratio의 경계 절벽 제거 — 모두 버킷 경계에서 값이 보존된 선형화. Reward Rate 곡선 재균형으로 중앙값 = 차원 포인트의 절반 (40%였음). 오래된 차원 문서 문자열을 실제 가중치 값과 조정. 순 효과: 모든 차원은 입력 축에서 단조 상향이며, 실제 운영 메트릭을 개선하여 FlareWatch 점수를 낮출 수 있는 제공자는 없습니다.
v3 (2026-05-09 → 2026-05-11) — 동적 가중치 재분배 및 투표력 희석 패널티를 갖춘 13-차원 점수. MIRROR Participation은 베이지안 수축 및 30일 데이터 누적 게이트가 있는 베이스 12 + 최대 +3 초과 성과 보너스를 가진 1급 차원으로 도입되었습니다. Identity 및 Self-Bond가 별개 차원으로 추가되었습니다. Reward Rate는 중앙값-앵커링으로 이동했습니다. Accuracy는 고해상도 대역에 FSE 보조 메트릭을 사용합니다. Consistency는 최근 에포크 전체에 걸친 CV를 사용합니다.
v2 이전 — v3 이전 버전은 여기에 문서화되지 않습니다; 더 간단한 차원 부분 집합을 사용했고 동적 가중치 재분배보다 선행합니다. 현재 모델을 위해 버전이 폐지되었습니다.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.