FTSO Provider Score Methodology

Phiên bản thuật toán: v4.11 · Cập nhật lần cuối: 2026-07-04

FlareWatch gán cho mỗi nhà cung cấp dữ liệu FTSO một điểm tổng hợp từ 0–100 trên 12 chiều được tính điểm. Phép toán là xác định, các đầu vào là dữ liệu công khai trên chuỗi và hệ sinh thái Flare[Flaremetrics] [FSE] [Flare Explorer], và cùng một thuật toán áp dụng cho mỗi provider — bao gồm FTSO provider của FlareWatch, được tính điểm bằng chính xác hàm này mà không có xử lý đặc biệt. Trang này ghi lại mỗi thứ nguyên và ngưỡng để delegator và nhà khai thác có thể thấy chính xác cách tính điểm số và tại sao mỗi giá trị được chọn. Mỗi khiếu nại ở đây liên kết trở lại với nguồn ngữp hạng chính của nó — xem Nguồn & tham khảo ở dưới cùng.

Phạm vi: trang này ghi chép điểm số nhà cung cấp FTSO — những gì bạn thấy trong chế độ ủy quyền trên trang các trình xác thực (ủy quyền WFLR cho các nhà cung cấp dữ liệu FTSO để chia sẻ lạm phát FTSO). Điểm số trình xác thực được hiển thị trong chế độ staking (ủy quyền FLR cho trình xác thực P-Chain để nhận phần thưởng VRM + MIRROR) sử dụng một thuật toán 9 chiều riêng biệt tập trung vào hoạt động của trình xác thực — thời gian hoạt động, phí, độ tin cậy, v.v. Đây là các vai trò riêng biệt trên chuỗi với phần thưởng riêng biệt, được chấm điểm riêng. Xem Phương pháp luận Điểm số Trình xác thực cho phía staking.
Phạm vi chuỗi FLR / SGB: tab Ủy quyền trên trang các trình xác thực có công tắc FLR / SGB dành cho ví có Songbird (SGB). Phương pháp luận này chỉ ghi chép điểm số phía FLR. Các nhà cung cấp FTSO Songbird được liệt kê mà không có điểm số tổng hợp — dữ liệu độ chính xác / tính nhất quán / phần thưởng FSP tương tự mà chúng tôi sử dụng cho FLR chưa được kết nối vào pipeline Songbird của chúng tôi (Flaremetrics, nguồn dữ liệu FLR chính của chúng tôi, không bao gồm Songbird). Những gì các ủy quyền SGB thấy ngày hôm nay: tên nhà cung cấp + biểu tượng từ sổ đăng ký TowoLabs xuyên mạng, trọng lượng hiện tại (WSGB được ủy quyền, đọc trực tiếp từ hợp đồng WNat của Songbird qua RPC Songbird riêng của chúng tôi), và URL của nhà cung cấp. Sắp xếp theo trọng lượng; trọng lượng lớn hơn là tín hiệu đại diện cho đến khi dữ liệu độ chính xác xuất hiện. Khi chúng tôi kết nối pipeline độ chính xác + tỷ lệ phần thưởng phía Songbird, cùng công thức 13 chiều sẽ áp dụng cho các nhà cung cấp SGB — không có thuật toán chấm điểm mới, chỉ là công thức FLR được tính toán dựa trên dữ liệu Songbird. Chấm điểm trình xác thực FlareWatch (tab staking) không có tương đương SGB: tập hợp trình xác thực P-Chain của Songbird bị hạn chế ở các thực thể được Flare Foundation phê duyệt, do đó ủy quyền P-Chain SGB cho bán lẻ hiếm khi xảy ra và tab staking vẫn chỉ là FLR.
Các dải điểm số
90+Tầng hàng đầu — top ~10–20% các nhà cung cấp FTSO. Hồ sơ điển hình: tỷ lệ phần thưởng cao hơn mức trung bình, độ chính xác cao, tham gia đầy đủ giao thức V2 (FTSO Scaling + Fast Updates + FDC), phí thấp/bằng không, cơ sở ủy quyền lớn, nút trình xác thực thanh toán MIRROR, thương hiệu được đặt tên. Không yêu cầu chiều độ duy nhất — các nhà cung cấp đạt tầng hàng đầu bằng cách tích tụ sức mạnh trên hầu hết các danh mục.
80–89Mạnh — đáp ứng hầu hết các điểm chuẩn chính; thiếu một hoặc hai chiều so với tầng hàng đầu.
70–79Tốt — đáp ứng tất cả các tiêu chí cơ sở; không có khoảng trống lớn.
60–69Chấp nhận được — có thể sử dụng nhưng không có sự khác biệt.
<60Dưới mức trung bình — khoảng trống đáng kể trong một hoặc nhiều chiều. Sự kiện toán học, không phải đánh giá chất lượng.
Chiều (trọng lượng thô — tổng 172, chuẩn hóa thành 100)
"Hoạt động" kiểm soát hai chiều (Phí và V2 Participation): một nhà cung cấp không chạy không nên nhận credit cho việc quảng cáo phí thấp. Một nhà cung cấp được tính là hoạt động nếu nó có tỷ lệ phần thưởng công bố hoặc nếu dữ liệu phần thưởng của Flare Systems Protocol cho thấy nó đã thanh toán trong ít nhất một epoch của cửa sổ tính điểm. Cho đến 2026-07-31, nó chỉ dựa trên tỷ lệ phần thưởng, được lấy từ một API của bên thứ ba — vì vậy một nhà cung cấp mà API đó không bao phủ được tính điểm không trên cả hai chiều trong khi rõ ràng phân phối phần thưởng mỗi epoch. Hoạt động là một thuộc tính của nhà cung cấp, không phải của ai tình cờ liệt kê nó.
Tỷ lệ phần thưởng25 pts tối đa
Là gì: Tỷ lệ phần thưởng của nhà cung cấp trên mỗi epoch, được neo vào mức trung bình mạng.
Cách thức: tỷ lệ = tỷ lệ nhà cung cấp / tỷ lệ trung bình. Tuyến tính: tỷ lệ 1,0 (trung bình) → 12,5 pts, tỷ lệ 2,0 → 25 pts (tối đa). Nhà cung cấp không hoạt động (rewardRate ≤ 0) → 0. v4.0 (2026-05-11): giới hạn được đặt lại để trung bình = một nửa điểm của chiều (không phải 40% như trước).
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).
Tại sao: Tỷ lệ phần thưởng là điều #1 mà các ủy quyền trải nghiệm. Neo mức trung bình giữ cho điểm số trung thực khi kinh tế phần thưởng của mạng thay đổi — một nhà cung cấp ở 1,2× mức trung bình trong một kỷ nguyên có phần thưởng thấp vẫn xếp hạng giống như một nhà cung cấp ở 1,2× trong một kỷ nguyên có phần thưởng cao. Các giới hạn và bộ lọc bất thường ngăn chặn các ngoại lệ epoch đơn lẻ chi phối.
Độ chính xác25 pts tối đa
Là gì: Độ chính xác giá FTSO từ Flare Systems Explorer (FSE) — tỷ lệ đạt dải phần thưởng primary (IQR chặt chẽ) và secondary (rộng hơn).
Cách thức: Sự kết hợp 40/60 của tỷ lệ đạt dải FTSO PRIMARY (IQR chặt chẽ) và SECONDARY (rộng hơn) (v4.8), phản ánh chia tách phần thưởng của chính Flare — FIP.11 trả thưởng anchor-feed 40% primary / 60% secondary. Secondary sử dụng đường cong piecewise trước đó (97% → 25 … 70% → 2); nó gần như bão hòa trên toàn lĩnh vực (95–99%), vì vậy nó gần như không phân biệt. Primary sử dụng đường cong tuyến tính tuyệt đối — 28% → 0 lên đến 78% → đầy đủ 25 — vì vậy kỹ thuật dải chặt chẽ khó hơn nhiều, nơi các nhà cung cấp thực sự phân tán từ ~28% đến ~80%, là điều phân tách lĩnh vực. Các mốc cố định (không phần trăm lĩnh vực), vì vậy điểm số vẫn có thể tái tạo từ các đầu vào của chính nhà cung cấp đó. Fallback single-band khi chỉ có một dải; neutral 12.5 khi không có dữ liệu FSE.
if (fseAccuracySecondary > 0):
  pct = fseAccuracySecondary / 100
  if (pct >= 97) score = 25
  elif (pct >= 95) score = 18 + (pct - 95) * 3.5     // 95 → 18,  97 → 25
  elif (pct >= 93) score = 16 + (pct - 93) * 1       // 93 → 16,  95 → 18
  elif (pct >= 90) score = 13 + (pct - 90) * 1       // 90 → 13,  93 → 16
  elif (pct >= 85) score = 10 + (pct - 85) * 0.6     // 85 → 10,  90 → 13
  elif (pct >= 80) score = 6  + (pct - 80) * 0.8     // 80 → 6,   85 → 10
  else              score = max(0, 2 + (pct - 70) * 0.4)
elif (fseAccuracyPrimary > 0):
  // Primary fallback: similar piecewise linear curve.
else:
  score = WEIGHT_ACCURACY / 2   // Neutral — no FSE data
Tại sao: Các epoch bị bỏ lỡ = thu nhập phần thưởng bị mất cho các ủy quyền. Độ chính xác là những gì quyết định xem doanh vụ gửi của nhà cung cấp có thực sự được tính trong sự đồng thuận FTSO hay không, và số liệu phụ (trọng số hơn các epoch gần đây hơn) là số liệu ánh xạ sạch nhất tới hiệu suất hiện tại.
Tính nhất quán20 pts tối đa
Là gì: Mức độ ổn định của tỷ lệ phần thưởng của nhà cung cấp trong các epoch kiếm được gần đây nhất của nó.
Cách thức: Biến động chiều xuống trên các epoch kiếm gần đây nhất của nhà cung cấp, được đo chỉ giữa các epoch thực sự liên tiếp — một epoch mà nhà cung cấp không kiếm được gì không để lại bản ghi, và hai epoch nằm trên hai bên của khoảng cách đó không bao giờ được so sánh với nhau. Chỉ các DROP epoch-over-epoch mới được tính — mức tăng không đóng góp gì — vì vậy tỷ giá ổn định hoặc tăng lên sẽ ghi điểm gần tối đa và phục hồi sẽ nâng điểm ngay khi nó xảy ra. Các DROP được tổng hợp RMS để một mức sụt giảm mạnh có trọng lượng lớn hơn mức sụt nhẹ, và được trọng số hướng tới các cặp gần đây (decay 0.8) để phục hồi tích cực nâng điểm lên trong khi các mức sụt cũ dần được loại bỏ. cv = 0 → 20 điểm; cv ≥ ~0.167 → 0. Trung lập 10 khi tồn tại ít hơn 3 cặp epoch liên tiếp trong 12 epoch kiếm gần đây.
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)
Tại sao: Hai nhà cung cấp có cùng tỷ lệ phần thưởng trung bình có thể mang lại những trải nghiệm ủy quyền rất khác nhau: một nhà sụt mạnh tệ hơn một nhà giữ ổn định hoặc tăng trưởng. Tính nhất quán thưởng những gì ủy quyền thực sự muốn — tỷ giá ổn định hoặc tăng — và chỉ phạt các giảm, tỷ lệ với mức độ sâu. Một tỷ giá tăng LÊN không bao giờ bị phạt (thước đo đối xứng trước đó đã làm, điều này là sai). Một sụt mạnh gần đây ghi điểm thấp sau đó phục hồi khi nó mất giá trị.
Tham gia V215 pts tối đa
Là gì: Liệu nhà cung cấp có đang chạy ngăn xếp V2 hiện đại (FTSO Scaling + Fast Updates + FDC) hay không.
Cách thức: Xếp chồng mỗi giao thức. Baseline hoạt động (rewardRate > 0) +3, V1 một phần (gửi + ký + bỏ phiếu) +4, mỗi giao thức V2 (FTSO Scaling / Fast Updates / FDC) +~2,67 mỗi cái, giới hạn ở 15. Không hoạt động → 0. v4.0 (2026-05-11) chia tầng all-or-nothing trước đây (nơi V1 một phần = V2 đầy đủ = 15 — không có động lực để nâng cấp) thành các tiền thưởng mỗi giao thức tích tụ.
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)
Tại sao: V2 là nơi mạng đang đi. Xếp chồng mỗi giao thức của v4.0 có nghĩa là nâng cấp từ V1 một phần lên V2 đầy đủ thực sự di chuyển điểm số (trước sửa nó không — V1 một phần và V2 đầy đủ đều trả về 15). Thêm bất kỳ giao thức V2 nào bây giờ cải thiện chiều.
Phí15 pts tối đa
Là gì: Phí mà nhà cung cấp tính trên các phần thưởng được ủy quyền.
Cách thức: Nội suy tuyến tính qua các điểm ngắt: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. Nhà cung cấp không hoạt động → 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
Tại sao: Phí trực tiếp giảm những gì các ủy quyền nhận được. Nội suy tuyến tính (thay vì các bucket) có nghĩa là phí 7% ghi điểm giữa 10% và 15% thay vì chụm lại một bucket — các nhà điều hành không được ghi công cho làm tròn phí của họ xuống ranh giới bucket tiếp theo.
Tham gia MIRROR12 (+3 tiền thưởng) pts tối đa
Là gì: Liệu các nút trình xác thực P-Chain của nhà điều hành có chủ động thanh toán chia sẻ lạm phát FTSO cho những người đặt cược hay không, cộng với tiền thưởng vượt quá hiệu suất.
Cách thức: Điểm cơ sở tăng tuyến tính theo tỷ lệ nodeID của nhà điều hành trả thưởng MIRROR. Tất cả các nút hoạt động → 12 pts. Một phần → tỷ lệ. Không → 0. Kể từ 2026-05-11, tín hiệu 'hoạt động' đọc từ hai nguồn chính tắc: sự kiện RewardClaimed(claimType=3) trên chuỗi trong V2 RewardManager VÀ phân bổ claimType=3 trong JSON Merkle FSP chính thức — một trong hai đều đủ. Trước cập nhật, chúng tôi sử dụng luồng trên chuỗi làm tín hiệu duy nhất, tạo ra âm tính giả cho các nhà cung cấp có MIRROR thanh toán thông qua đường yêu cầu không chuẩn. Cộng với thưởng vượt mức hiệu suất lên tới +3 pts khi các trình xác thực của nhà điều hành liên tục cung cấp trên 100% mức dự kiến (vrm + mirror) / mức dự kiến — co rút Bayesian với cổng tích lũy dữ liệu 30 ngày và mẫu tối thiểu 3 stake giữ các nhà điều hành nhỏ hoặc mới không thể chơi thưởng trên một vài lần đọc may mắn.
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
Tại sao: Tham gia MIRROR là cách ủy quyền phần lạm phát FTSO cho những người đặt cược của bạn. Nhà cung cấp hoạt động V2 có các nút xác thực không trả MIRROR đang gửi ~5–15% lợi suất ít hơn cho người ủy quyền so với nhà cung cấp tương tự có nút hoạt động. Thưởng vượt mức hiệu suất thưởng cung cấp liên tục tốt hơn dự kiến mà không làm tăng các nhà điều hành mới trên mẫu nhỏ — co rút Bayesian và cổng tích lũy 30 ngày giữ nó công bằng.
Số Lượng Người Ủy Quyền12 pts tối đa
Là gì: Số ví riêng biệt hiện đang ủy quyền cho nhà cung cấp này, được tính từ trạng thái chuỗi.
Cách thức: Tỷ lệ log từ 5 → 500 người ủy quyền ánh xạ tới 0 → 12. ≤5 → 0, ≥500 → 12 (mức tối đa). Khớp với kiểu tín hiệu đếm của chiều Trust trình xác thực. v4.0 (2026-05-11): sửa lỗi thực tế trong đó sơ đồ bucket trước đó có một ưu đãi bất lợi chính xác ở 500 người ủy quyền (trước sửa: 500 → 14, 501 → 12 — lấy một người ủy quyền vượt qua ranh giới đó mất 2 điểm).
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
Tại sao: Số lượng người ủy quyền là tín hiệu tin cậy — độc lập với kích thước stake. Nhà cung cấp có 200 người ủy quyền đã được 200 người đặt cược độc lập chọn; người có 5 đã được chọn gần bằng nhà điều hành của nó. Tỷ lệ log mang lại lợi suất giảm dần quá ~50 người ủy quyền mà không bao giờ đảo ngược (cách ghi điểm bucketed trước v4.0 đã làm).
Tham Gia Epoch10 pts tối đa
Là gì: Liệu nhà cung cấp có đang tham gia hoạt động trong các epoch.
Cách thức: FSE đánh dấu nhà cung cấp hoạt động → 10. Nhà cung cấp có rewardRate > 0 (Flaremetrics) nhưng không có cờ hoạt động FSE → 7 (hoạt động theo dữ liệu thị trường, thiếu xác nhận FSE). Nếu không → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Tại sao: Bắt những nhà cung cấp có luồng phần thưởng bị dừng ngay cả khi Flaremetrics vẫn liệt kê họ. Khác biệt với Accuracy (liên quan đến tính đúng đắn trên mỗi epoch) — Participation là về việc xuất hiện ở tất cả.
Ổn Định Sức Mạnh Bỏ Phiếu10 pts tối đa
Là gì: Phần trăm thay đổi từ ngày này sang ngày khác trong sức mạnh bỏ phiếu của nhà cung cấp.
Cách thức: Tuyến tính từng phần trong phần trăm thay đổi tuyệt đối từ ngày này sang ngày khác. <1% → 10. Tuyến tính từ 1% → 3% (10 → 7). Tuyến tính từ 3% → 5% (7 → 4). Tuyến tính từ 5% → 10% (4 → 2). Tiếp tục hướng về 0 quá 10%. v4.0 (2026-05-11): tuyến tính hóa các vách đá bucket trước đó (lên đến 3 điểm vách đá ở mỗi ngưỡng).
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)
Tại sao: Biến động lớn từ ngày này sang ngày khác trong sức mạnh bỏ phiếu thường chỉ ra một sóng người ủy quyền di chuyển vào hoặc ra — những người đặt cược đọc bảng thấy một mục tiêu di động. Sức mạnh bỏ phiếu ổn định báo hiệu một nhà cung cấp được giải quyết có những người ủy quyền dính.
Tuân Thủ10 pts tối đa
Là gì: Liệu nhà cung cấp có được thanh toán trong mọi epoch thưởng KỂ TỪ KHI nó hoạt động trong dữ liệu phần thưởng FSP.
Cách thức: Đầy đủ 10 điểm cho không epoch bị bỏ qua trong cửa sổ hoạt động của nhà cung cấp. Mỗi epoch bị bỏ qua trừ 3 pts (giới hạn ở 0). Trung lập 5 khi không có dữ liệu FSP. v4.4 (2026-06-30): các epoch bị bỏ qua hiện được tính chỉ từ epoch tham gia đầu tiên của nhà cung cấp trở đi — một nhà cung cấp mới không còn bị tính phí cho các epoch trước khi nó tồn tại (trước đó giữ các nút mới nhưng sạch sẽ ở 0/10 trong nhiều tuần).
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)
Tại sao: Một epoch bị bỏ qua trong phân phối phần thưởng Flare Systems Protocol chính thức có nghĩa là nhà cung cấp không tuân thủ giao thức cho epoch đó — các điều kiện tối thiểu, chính sách ký, v.v. Tính chỉ từ tham gia đầu tiên giữ thước đo công bằng với các nhà cung cấp mới trong khi vẫn phạt những lần bỏ qua thực sự. Ba điểm trên mỗi lần bỏ qua là dốc nên một lần bỏ qua duy nhất là một tín hiệu đáng chú ý nhưng có thể phục hồi; ~3 lần bỏ qua xóa chiều.
Danh Tính8 pts tối đa
Là gì: Liệu nhà cung cấp có tên thương hiệu thực sự hay chỉ là một địa chỉ hex.
Cách thức: Thương hiệu có tên (≥4 ký tự, không bắt đầu bằng 0x) → 8. Ngắn hoặc ẩn danh (<4 ký tự) → 4. Địa chỉ hex thuần / 0x làm tên → 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
Tại sao: Nhà cung cấp có tên đã chọn để có thể tìm được và chịu trách nhiệm — họ có thể được tra cứu, liên hệ và buộc phải tuân thủ các cam kết được công bố. Các nhà cung cấp ẩn danh theo địa chỉ hoạt động nhưng cung cấp ít tín hiệu tin cậy hơn cho những người ủy quyền đánh giá chúng.
Self-Bond7 pts tối đa
Là gì: Trái phiếu nút P-Chain của chính nhà điều hành (có tiền chơi) — không bao gồm stake mà những người khác ủy quyền cho nút. Một cổng cam kết trung lập về kích thước, không phải xếp hạng sự giàu có.
Cách thức: Được tính trên GREATER của hai trục bão hòa: (1) sắp xếp — trái phiếu riêng làm một phần của tổng stake cam kết (≥10% → đầy đủ); hoặc (2) tuyệt đối — vốn riêng có nguy hiểm, được giới hạn ở 5M FLR để 5M và 80M ghi điểm giống nhau. v4.4 (2026-06-30): được nguồn từ self-bond P-Chain thực sự của nhà điều hành (trọng lượng xác thực tham chiếu chéo bằng nodeID) — trường Flaremetrics trước đó mà nó đọc đã bị dừng, vì vậy mỗi nhà cung cấp đã ghi điểm 0. v4.5 (2026-06-30): thêm trục tuyệt đối + bão hòa để self-bond lớn ở tỷ lệ thấp không được ghi điểm dưới một tỷ lệ cao nhỏ, mà không để kích thước thắng hay phạt các nhà điều hành nhỏ.
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)
Tại sao: Có tiền chơi — một nhà điều hành có vốn riêng có nguy hiểm được sắp xếp với những người ủy quyền. Nhưng kích thước self-bond không phải là proxy cho QUALITY nhà điều hành (sống trong các chiều khác), vì vậy một nhà điều hành nhỏ được sắp xếp đầy đủ và một nhà lớn cam kết đều kiếm được điểm tối đa. Chỉ có một nhà điều hành có ít vốn riêng cam kết — phần nhỏ VÀ số tiền nhỏ — ghi điểm dưới toàn bộ.
Cách ghi 100/100 — playbook của nhà cung cấp FTSO
Kiểm toán công bằng v4.0 được thiết kế đặc biệt để tối đa hóa mọi chiều ghi điểm thực sự khiến bạn trở thành nhà cung cấp FTSO tốt hơn cho những người ủy quyền của bạn. Cải thiện điểm của bạn không phải là gaming hệ thống — đó là hệ thống hoạt động như được thiết kế. Đây là playbook trên mỗi chiều.
Tỷ Lệ Phần Thưởng — 25 pts. Cung cấp ≥ 2× tỷ lệ phần thưởng FSP trung bình mạng trên mỗi epoch (sau phí, phân phối sau giao thức). Tuyến tính từ 0 tới 2× trung bình: trung bình → 12,5, 2× trung bình → 25. Tại sao điều này sắp xếp: đây là số tiền thực sự đạt tới những người ủy quyền của bạn trên mỗi epoch.
Độ Chính Xác — 25 pts. Mục tiêu ≥97% tỷ lệ hạ cánh dải thứ cấp trên FSE để có điểm tối đa. Tuyến tính từng phần vì vậy 95% → 18, 93% → 16, 90% → 13, v.v. — mỗi cải thiện 1% di chuyển điểm. Đây là CHẤT LƯỢNG giá, không phải tham gia epoch: nó đo phần nào giá được gửi hạ cánh bên trong dải được chấp nhận trên chuỗi. Một nhà cung cấp có Accuracy cao xuất bản giá gần với sự đồng thuận; cái có Accuracy thấp gửi một cách đáng tin cậy nhưng ngoài dải đồng thuận thường xuyên hơn. Tại sao điều này sắp xếp: các bài nộp ngoài dải tạo ra phần thưởng người ủy quyền nhỏ hơn ngay cả khi nhà cung cấp tham gia mỗi epoch. Chiều Compliance riêng biệt dưới đây theo dõi tham gia epoch.
Tính Nhất Quán — 20 pts. Giảm thiểu phương sai tỷ lệ phần thưởng trên mỗi epoch (CV = stddev/mean trên các epoch gần đây). CV = 0 → 20, CV = 0,2+ → 0. Tại sao điều này sắp xếp: hai nhà cung cấp có cùng tỷ lệ phần thưởng trung bình không tương đương — thanh toán có thể dự đoán được vượt trội so với các thanh toán dễ xoay chuyển cho UX người đặt cược.
Tham Gia V2 — 15 pts. Stack giao thức một cách cộng: baseline hoạt động + đăng ký V1 một phần + mỗi giao thức V2 (Scaling, FastUpdates, FDC). V2 đầy đủ + hoạt động + V1 đăng ký = 15. Tại sao điều này sắp xếp: V2 là nơi mạng đang hướng tới; mỗi giao thức bổ sung bạn áp dụng là một khoản đầu tư phía trước những người ủy quyền của bạn được hưởng lợi.
Phí — 15 pts. Tính phí ≤ 5% cho 13 pts, 0% cho 15. Ramp tuyến tính từng phần thông qua các điểm ngắt 5%/10%/15%/20%/25% thành 0. Tại sao điều này sắp xếp: phí thấp hơn = phần thưởng nhiều hơn tới những người ủy quyền của bạn một cách trực tiếp.
Tham Gia MIRROR — 12 + lên tới 3 bonus. Chạy tất cả các nút xác thực P-Chain của nhà điều hành của bạn dưới dạng MIRROR-active (thông qua các sự kiện RewardClaimed trên chuỗi HOẶC phân bổ FSP Merkle JSON — dual-source v3.6). Vượt mức hiệu suất bền vững (tỷ lệ trung vị (vrm+mirror)/expected trên 1,05) trên ≥3 stake thanh toán sau 30 ngày quan sát kiếm được lên tới +3 bonus. Tại sao điều này sắp xếp: MIRROR là phần chia sẻ lạm phát FTSO của những người ủy quyền của bạn; các nút không trả MIRROR gửi ~5-15% lợi suất ít hơn cho những người đặt cược.
Số Lượng Người Ủy Quyền — 12 pts. Tỷ lệ log 5 → 500 người ủy quyền ánh xạ tới 0 → 12. Xây dựng cơ sở những người đặt cược độc lập, không chỉ là một vài cá voi. Tại sao điều này sắp xếp: đếm là tín hiệu tin cậy độc lập với kích thước stake; 200 người ủy quyền chọn bạn có nghĩa là 200 lời chứng thực độc lập.
Tham Gia Epoch — 10 pts. Xuất hiện trong mỗi epoch với tỷ lệ phần thưởng dương và cờ hoạt động FSE. Tại sao điều này sắp xếp: bắt các luồng phần thưởng bị dừng mà các chiều trên mỗi epoch có thể bỏ lỡ.
Ổn định — 10 điểm Giữ thay đổi sức bỏ phiếu hàng ngày dưới 1%. Tăng tuyến tính từ đó trở đi. Tại sao điều này phù hợp: sức bỏ phiếu ổn định báo hiệu các delegator đã ổn định (cộng đồng gắn bó) thay vì những làn sóng cá voi chuyển động.
Tuân thủ — 10 điểm Không bỏ lỡ bất kỳ epoch phần thưởng nào trong dữ liệu FSP. Mỗi lần bỏ lỡ mất 3 điểm; ~3 lần bỏ lỡ làm cho chiều này về 0. Đây là THAM GIA, không phải chất lượng giá: nó đếm các epoch nơi nhà cung cấp bị phạt vì bỏ lỡ các điều kiện tối thiểu, chính sách ký hoặc các yêu cầu giao thức khác — khác với chiều Độ chính xác ở trên để tính điểm trong phạm vi đặt giá. Tại sao điều này phù hợp: một epoch bị bỏ lỡ trong chính phân phối phần thưởng của giao thức có nghĩa là nhà cung cấp đã không đáp ứng các điều kiện tối thiểu và các delegator không kiếm được gì trong epoch đó. Một nhà cung cấp có thể có Độ chính xác tuyệt vời trên các epoch đã tham gia và vẫn bỏ lỡ các epoch hoàn toàn.
Danh tính — 8 điểm Đăng ký tên thương hiệu thực (≥4 ký tự, không phải địa chỉ hex) trên Flaremetrics hoặc FSE. Các nhà cung cấp ẩn danh theo địa chỉ ghi 0; các nhà cung cấp được đặt tên ghi 8. Tại sao điều này phù hợp: các nhà cung cấp được đặt tên có thể tìm được và chịu trách nhiệm; đó là tín hiệu lòng tin cơ bản.
Tự đảm bảo — 7 điểm Cam kết trái phiếu nút P-Chain của riêng bạn (không phải stake mà người khác ủy quyền cho bạn). Điểm đầy đủ cho MỘT trong số những điều sau: một phần có ý nghĩa của tổng stake của bạn (≥10%) HOẶC một số tiền tuyệt đối có ý nghĩa (trục tuyệt đối bão hoà ở 5M FLR, vì vậy một nhà điều hành lớn không thể vượt qua một nhà điều hành nhỏ theo kích thước). Tại sao điều này phù hợp: có tiền trong trò chơi — các nhà điều hành có vốn của riêng họ có nguy hiểm chia sẻ kết quả lợi suất của các delegator của họ. Đó là cổng cam kết trung lập về kích thước, không phải xếp hạng của cải: một nhà điều hành nhỏ hoàn toàn phù hợp và một nhà điều hành lớn cam kết đều đạt mức tối đa, và chất lượng hoạt động của bạn được đánh giá bởi các chiều khác.
Tín hiệu được ghi thời gian mà bạn không thể tắt đường cắt: Tính nhất quán cần ≥3 epoch lịch sử. Tiền thưởng vượt trội MIRROR cần 30 ngày quan sát cộng với ≥3 mẫu stake được trả. Tuân thủ cần dữ liệu FSP bao trùm đủ các epoch để đếm. Xây dựng hồ sơ theo dõi; điểm sẽ theo sau.
Điểm thô cộng lại tối đa 172 trên tất cả 12 chiều được tính điểm và sau đó được chuẩn hóa thành 100. Một lần chạy hoàn hảo trên các đầu vào đạt 172/172 → 100 hiển thị. Một hình phạt giảm quyền lực biểu quyết lên tới −3 điểm áp dụng cho các nhà cung cấp rất lớn (>1,34B VP) như một bộ phá vòng.
Cách xác minh điểm của riêng bạn
Mỗi điểm trên bảng nhà cung cấp có thể tái tạo từ dữ liệu công khai. Nếu bạn là một nhà điều hành và toán học ở đây không khớp với điểm bạn thấy, hành động đúng là tự xác minh nó trước khi giả định rằng chúng tôi đã mắc lỗi. Hướng dẫn từng bước:
  1. Tra cứu thống kê công khai của nhà cung cấp của bạn tại flaremetrics.io (tìm kiếm theo tên hoặc dán địa chỉ ủy quyền của bạn). Ghi chú fspRewardRate, delegationFeePercentage, wNatWeight, và votePowerDailyChangePct của bạn.
  2. Xác minh FTSO V2 + độ chính xác của bạn tại flare-systems-explorer.flare.network. Tìm thực thể của bạn. Kiểm tra providersuccessrate.secondary để tính độ chính xác, cộng với các cờ entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc cho trạng thái V2.
  3. Kiểm tra tham gia MIRROR của bạn trên hợp đồng V2 RewardManager qua flare-explorer.flare.network. Tìm các sự kiện RewardClaimed với claimType=3 tham chiếu đến nodeID của bạn. Nếu không có sự kiện gần đây nào cho bất kỳ nút nào của bạn, bạn sẽ hiển thị là MIRROR-không hoạt động trên điểm số.
  4. Thay đổi các đầu vào của bạn vào các công thức ở trên. Khối mã của mỗi chiều cho bạn biết chính xác những gì để chạy. Tính tổng các chiều, chia cho 172 (tối đa thô), nhân với 100, và bạn có điểm tổng hợp thô của mình.
  5. Áp dụng hình phạt suy giảm nếu bạn lớn. Sức bỏ phiếu trên 1.34B là −3, trên 1B là −1. Thẻ Điểm cuối cùng bên dưới có các ngưỡng chính xác.
  6. So sánh với điểm hiển thị của bạn. Điểm hiển thị cũng phản ánh tái phân bổ trọng lượng động — khi hầu hết các nhà cung cấp cụm trong một chiều (độ lệch chuẩn thấp trên bộ hoạt động), trọng lượng của chiều đó được phân bổ lại cho các chiều nơi lây lan rộng hơn. Bảng phân tích điểm số trên mỗi hàng nhà cung cấp cho thấy các giá trị hiện tại cho mỗi chiều.
  7. Nếu toán học không cộng lại, hãy gửi email [email protected] với địa chỉ ủy quyền của bạn, các đầu vào bạn sử dụng, và điểm bạn tính toán. Chúng tôi sẽ phản hồi, và nếu chúng tôi mắc lỗi, chúng tôi sẽ sửa nó công khai.
Những lo lắng phổ biến của nhà điều hành
Tỷ lệ phần thưởng của tôi cao hơn trung bình nhưng điểm Tỷ lệ phần thưởng của tôi không phải 25/25 — tại sao?
Tỷ lệ phần thưởng tuyến tính theo tỷ lệ so với trung bình: điểm = tỷ lệ × 12,5, vì vậy 1,0× trung bình = 12,5/25 và bạn cần tỷ lệ 2,0× để đạt mức tối đa. Một nhà cung cấp ở mức 1,2× trung bình ghi 15, ở mức 1,5× ghi ~18,8, ở mức 2,0× ghi đầy đủ 25. Mức tối đa (cộng với bộ lọc bất thường 3×-trung bình) tồn tại để một epoch phần thưởng bất thường cao duy nhất không thể thống trị chiều; nếu tỷ lệ của bạn luôn nằm trong phần mười hàng đầu, điểm vẫn thưởng nó rất nhiều.
Tôi vừa nâng cấp lên V2 — khi nào điểm số V2 của tôi được cập nhật?
Trạng thái V2 đến từ các cờ entityminimalconditionslatest của FSE (ftso_scaling, ftso_fast_updates, fdc). Từ v4.0, chiều xếp chồng theo giao thức: cơ sở hoạt động +3, đăng ký V1 (gửi + ký + bỏ phiếu) +4, và mỗi giao thức V2 +~2,67. Vì vậy, nhà cung cấp được đăng ký bỏ phiếu với các địa chỉ gửi + ký nhưng không có giao thức V2 nào ghi 7/15, và mỗi giao thức V2 riêng lẻ bạn bật di chuyển điểm số — cả ba hoạt động trực tiếp được bạn điểm số đầy đủ 15. Những thay đổi được thực hiện trên lần chạy cron FlareWatch tiếp theo (mỗi 5 phút) sau khi FSE phản ánh chúng.
Độ chính xác của tôi trên FSE là 96% nhưng tôi ghi điểm thấp hơn dự kiến.
Chiều Độ chính xác sử dụng số liệu độ chính xác thứ cấp của FSE (độ phân giải cao hơn trong dải 94–97% nơi hầu hết các nhà cung cấp cụm). 95–96% ánh xạ tới 18 điểm; bạn cần ≥97% cho 25 đầy đủ. Các nhóm chặt ở trên cùng vì một vài phần mười điểm trong dải 95–97% đại diện cho tách biệt hiệu suất thực sự giữa các nhà cung cấp.
Tôi cung cấp MIRROR — tại sao FlareWatch hiển thị tôi là MIRROR-không hoạt động trên điểm nhà cung cấp của tôi?
Kể từ 2026-05-11, tham gia MIRROR được phát hiện từ HAI nguồn: các sự kiện RewardClaimed(claimType=3) trên chuỗi trên V2 RewardManager, VÀ các phân bổ claimType=3 trong JSON Merkle FSP chính thức. Một nodeID hiển thị trong cả hai nguồn đều tính là hoạt động. Đối với các nhà điều hành đa nút, điểm sử dụng phân số các nút của bạn đang hoạt động (1/3 hoạt động = 4/12 cơ sở, v.v.). Nếu một nút sẽ được phân loại là hoạt động nhưng không hoạt động sau chu kỳ quét tiếp theo, hãy gửi email cho chúng tôi với nodeID và epoch cụ thể mà bạn dự kiến sẽ xuất hiện — chúng tôi sẽ kiểm tra lại cả hai nguồn.
Sức bỏ phiếu của tôi di chuyển 8% hôm qua — tại sao điểm Ổn định ghi ~2,8/10?
Ổn định sức bỏ phiếu tuyến tính từng phần trong thay đổi hàng ngày tuyệt đối (tuyến tính hóa trong v4.0 — không có vách đá nhóm): <1% → 10, ramp 1→3% xuống 7, 3→5% xuống 4, 5→10% xuống 2, sau đó về 0 quá 10%. Một động thái 8% hạ cánh trên ramp 5–10% ở 4 − (8 − 5) × 0,4 = 2,8. Ý định là cờ các nhà cung cấp trải qua chuyển tiếp delegator có ý nghĩa để các người stake có thể thấy nó trên bảng. Điểm số phục hồi ngay sau khi sức bỏ phiếu của bạn ổn định; một ngày không ổn định không để lại bạn ở mức thấp vĩnh viễn.
Nhà cung cấp của tôi được đặt tên bằng địa chỉ thực thể của tôi (0x…). Tại sao điểm Danh tính ghi 0?
Danh tính trao 8 điểm cho tên thương hiệu thực (≥4 ký tự, không bắt đầu bằng 0x hoặc chỉ hex) và 0 cho tên thuần địa chỉ. Chúng tôi không thể tạo ra tên — đặt profile.name của bạn trên Flaremetrics và chúng tôi sẽ chọn nó trên lần chạy cron tiếp theo. Nếu thực thể của bạn có hồ sơ nhưng trường tên trống, điều tương tự cũng áp dụng.
Tôi có cơ sở delegator nhỏ nhưng cam kết — tại sao điểm Số lượng Delegator của tôi bị giới hạn?
Delegator Count sử dụng số lượng thực tế: mỗi ví giữ WFLR được kiểm tra trên chuỗi để xác định các ủy quyền hiện tại của nó, và những người ủy quyền riêng biệt của mỗi nhà cung cấp được tính toán (làm mới khoảng ~6 giờ, được kiểm chéo với sổ cập nhật sự kiện độc lập). Kể từ v4.0, nó được sắp xếp theo logarit từ 5 → 500 người ủy quyền ánh xạ tới 0 → 12 điểm, giới hạn ở 500 (≤5 được tính 0 điểm). Sắp xếp theo logarit có nghĩa là các nhà cung cấp nhỏ hơn có tăng trưởng số lượng người ủy quyền mạnh mẽ tăng nhanh nhất; quá ~50 người ủy quyền, những người ủy quyền bổ sung di chuyển đồng hồ ít hơn — nhưng đường cong là đơn điệu, vì vậy việc thêm một người ủy quyền không bao giờ có thể làm giảm điểm (những thùng chứa trước v4.0 có thể).
Điểm của tôi giảm sau khi tôi thêm một nút — điều gì đã xảy ra?
Nếu nút mới chưa hiển thị các sự kiện MIRROR claimType=3, phân số MIRROR của bạn giảm (ví dụ: từ 1/1 = 100% xuống 1/2 = 50%), giảm điểm cơ sở Tham gia MIRROR. Khi nút mới bắt đầu thanh toán MIRROR (thường trong một hoặc hai epoch phần thưởng kể từ khi kích hoạt), phân số phục hồi và điểm tăng trở lại.
Tôi có thể phúc thẩp điểm của tôi hoặc yêu cầu xem xét thủ công không?
Có. Gửi email [email protected] với địa chỉ ủy quyền của bạn và mối lo lắng cụ thể. Chúng tôi phản hồi mọi nhà điều hành. Những điều chúng tôi sẽ hành động: sửa chữa phân loại MIRROR, lỗi toán học dành riêng cho chiều, sửa chữa tên/logo thông qua Flaremetrics. Những điều chúng tôi sẽ không hành động: yêu cầu nâng điểm số thủ công bên ngoài thuật toán, yêu cầu loại trừ hoặc hạ xếp hạng đối thủ.
Những gì chúng tôi sẽ và sẽ không làm
Để loại bỏ sự mơ hồ về cách chúng tôi vận hành điểm, đây là các cam kết rõ ràng. Nếu chúng tôi bao giờ vi phạm một trong số này, hãy ghi lại nó và gửi email [email protected] — chúng tôi sẽ sửa chữa nó công khai.
✓
Chúng tôi sẽ không chấp nhận thanh toán cho điểm số cao hơn, vị trí được tài trợ, hoặc xử lý ưu tiên bất kỳ loại nào. Điểm được tính toán một cách xác định từ dữ liệu công khai.
✓
Chúng tôi sẽ không mã hóa tay các nâng cao cho mỗi nhà cung cấp. Không có dòng "X được +5 vì chúng tôi thích họ" ở đâu trong mã. Cùng một thuật toán áp dụng cho mọi nhà cung cấp bao gồm nhà cung cấp FlareWatch của chính chúng tôi, được tính bằng hàm chính xác này.
✓
Chúng tôi sẽ không loại trừ các nhà cung cấp khỏi bảng vì lý do không công khai. Danh sách được lấy từ Flaremetrics + FSE; hiển thị của chúng tôi bao gồm mọi nhà cung cấp hoạt động mà các nguồn này bề mặt.
✓
Chúng tôi sẽ công bố các thay đổi thuật toán. Mỗi lần cập nhật phiên bản được ghi lại trong thẻ Versions trên trang này với lý do và những gì đã thay đổi. Những thay đổi lớn nhận thêm một mục changelog riêng biệt có thể xem từ trang changelog của ứng dụng.
✓
Chúng tôi sẽ trả lời email của các nhà khai thác. Mỗi nhà khai thác gửi email tới [email protected] với những lo ngại thực chất về điểm số của họ sẽ nhận được phản hồi thực sự trong vòng vài ngày làm việc.
✓
Chúng tôi sẽ công khai sửa chữa các lỗi của mình. Nếu chúng tôi phát hiện lỗi trong thuật toán, lỗi nguồn dữ liệu hoặc khoảng trống phương pháp, chúng tôi sẽ triển khai bản sửa và ghi lại nó. Chúng tôi không sắp xếp lại im lặng.
✗
Chúng tôi sẽ không chia sẻ nội dung email công khai mà không có sự cho phép của người gửi, hoặc sử dụng email của nhà khai thác cho bất kỳ mục đích nào khác ngoài cuộc trò chuyện về điểm số đã tạo ra nó.
✗
Chúng tôi sẽ không chia sẻ các kế hoạch tương lai về thay đổi thuật toán với các nhà khai thác được chọn trước — mỗi phiên bản sẽ phát hành trực tiếp cho mọi người cùng một lúc.
Điểm cuối cùng (cách các thứ nguyên kết hợp)
Tất cả 12 thứ nguyên được tính điểm cộng lại thành một điểm composite thô (tối đa 172). Điểm composite thô được bình thường hóa thành thang 0–100, sau đó áp dụng sự phân bổ lại trọng số động để tạo ra điểm cuối cùng được hiển thị.
// 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)
Sự gần gũi với hạn mức là một tín hiệu hiển thị, không phải là một khoản khấu trừ điểm số. Cho đến phiên bản 4.9, điểm số cũng trừ đi 1–3 điểm cố định từ các nhà cung cấp rất lớn, nhưng điều đó lặp lại tính toán — một nhà cung cấp vượt hạn mức đã kiếm được tỷ lệ lợi suất thực hiện dưới trung vị, được thứ nguyên Tỷ lệ lợi suất neo giữa trung vị tính điểm một lần. Vì vậy, hình phạt đã bị xóa. Giờ đây, mọi nhà cung cấp đều hiển thị bao nhiêu phần của hạn mức FSP (2,5% của tổng quyền bình chọn trực tiếp của hợp đồng WNat) mà nó chiếm, như một tín hiệu ủy quyền cận biên trung lập: càng gần 100%, ủy quyền mới càng bị giảm thứ.
Cờ ngoại lệ lớp hiển thị: nhà cung cấp có tỷ lệ phần thưởng hiện tại cao hơn hơn ba độ lệch mạnh (độ lệch tuyệt đối trung vị, được chia tỷ lệ ×1,4826) so với trung vị của trường — và ít nhất cao hơn 50% — sẽ mang huy hiệu Ngoại lệ trong bảng nhà cung cấp. Huy hiệu không thay đổi điểm; bảo vệ bất thường của chính điểm riêng biệt giới hạn các tỷ lệ trên 3× trung vị trước khi tính điểm. Các tăng vọt tỷ lệ epoch hàng năm thường xuất phát từ quyền bình chọn rất nhỏ và bình thường hóa trong một epoch.
Nguồn dữ liệu (mọi đầu vào đều công khai)
Hợp đồng Flare, đọc trực tiếp trên chuỗi: bộ nhà cung cấp đã đăng ký (VoterRegistry), các liên kết thực thể → địa chỉ ủy quyền và nodeID cộng với đăng ký địa chỉ gửi/ký (EntityManager), quyền lực biểu quyết được ủy quyền (WNat) và phí ủy quyền (WNatDelegationFee). Đây là điều khiến danh sách nhà cung cấp độc lập với bất kỳ chỉ số nào: tại kỷ nguyên phần thưởng 420, chuỗi chứa 98 nhà cung cấp đã đăng ký so với 80 trong danh sách của bên thứ ba, và 18 nhà cung cấp trong khoảng trống đã không bao giờ xuất hiện trên trang web này trước đây.
API công khai Flaremetrics: tỷ lệ phần thưởng, phí ủy thác, vote power, thay đổi vote power hàng ngày, vote power bị khóa (tự liên kết), tên hồ sơ + logo + khu vực, fspRewardRate.
Flare Systems Explorer (FSE): độ chính xác FTSO (primary + secondary), cờ trạng thái V2 (ftso_scaling, ftso_fast_updates, fdc), liên kết địa chỉ thực thể, sự hiện diện của địa chỉ ký/gửi, đăng ký cử tri, liên kết nodeID P-Chain, và tỷ lệ phần thưởng ủy quyền cho mỗi thực thể (reward_rate_wnat). Tỷ lệ phần thưởng được cố ý lấy từ CẢ FSE và Flaremetrics: họ công bố cùng một con số ở các đơn vị khác nhau (FSE thập phân, Flaremetrics phần trăm — được xác minh giống hệt nhau trên cả 72 nhà cung cấp mang cả hai, đến năm chữ số thập phân), và FSE bao quát 154 thực thể so với 80 của Flaremetrics. Chỉ một nguồn sẽ để lại các nhà cung cấp mà không có tỷ lệ nào không phải do lỗi của họ.
Dữ liệu phần thưởng Flare Systems Protocol (FSP): phân phối phần thưởng theo epoch cho mỗi nhà cung cấp, được sử dụng cho thứ nguyên Compliance (đếm các epoch không có phần thưởng) và là nguồn có thẩm quyền cho tổng phần thưởng ủy thác.
V2 RewardManager (claimType=3 events): phân phối MIRROR được yêu cầu trên chuỗi cho mỗi nodeID của trình xác thực. Được lọc chặt chẽ theo loại 3 — không nhầm lẫn với VRM, ủy thác FTSO hoặc phần thưởng DIRECT. Indexer riêng của FlareWatch cung cấp các thứ này cho thứ nguyên MIRROR Participation.
FSP Merkle JSON (claimType=3 allocations): hồ sơ được công bố chính tắc về ai được nợ MIRROR theo epoch (cùng dữ liệu mà công cụ ký riêng của Flare đọc). Được thêm làm nguồn có thẩm quyền thứ hai vào ngày 2026-05-11 — bắt các trình xác thực có MIRROR được phân bổ nhưng chưa được yêu cầu trên chuỗi.
Snapshot lịch sử FlareWatch: tỷ lệ phần thưởng theo epoch cung cấp cho Consistency CV; quan sát paid-stake cho mỗi trình xác thực cung cấp cho bonus hiệu suất vượt mức MIRROR (với cổng tích lũy dữ liệu 30 ngày).
Những gì KHÔNG có trong điểm số
• Tự quảng cáo hoặc vị trí được trả tiền. Không có nhà cung cấp nào có thể trả tiền hoặc tài trợ để có điểm số cao hơn.
• Các tăng cộng dành riêng cho nhà cung cấp được mã hóa bằng tay. Không có dòng "X nhận +5 vì chúng tôi thích họ" ở bất kỳ đâu trong mã. Cùng một thuật toán áp dụng cho mỗi nhà cung cấp bao gồm nhà cung cấp của chính FlareWatch, được tính bằng hàm chính xác này.
• Chất lượng cơ sở hạ tầng chủ quan. Chúng tôi không cố gắng đánh giá các SLA thời gian hoạt động, phân bố địa lý hoặc thông số kỹ thuật phần cứng ngoài những gì FSE và Flaremetrics cung cấp dưới dạng dữ liệu công khai.
• Khóa hoặc cam kết với FlareWatch. Không có tính điểm thuận lợi cho những người stake sử dụng FlareWatch so với công cụ khác.
• Các tín hiệu tương lai chưa được kết nối. Sự hiện diện của cộng đồng (xã hội được xác minh, tham gia quản trị), lịch sử slashing, độ trễ phản hồi và đường xu hướng theo epoch được phạm vi cho các phiên bản tương lai nhưng không có trong v3 hôm nay. Không ai được tính trọng số bí mật.
Phản hồi của nhà khai thác
Thấy điều gì không ổn trong điểm số của nhà cung cấp của bạn? Gửi email tới [email protected] với địa chỉ ủy thác và mối lo ngại của bạn. Chúng tôi phản hồi mỗi nhà khai thác. Những yêu cầu phổ biến chúng tôi sẽ hành động:
  • Các bản sửa chữa phân loại MIRROR (claimType=3 attribution cho nodeID của bạn).
  • Lỗi toán học cụ thể cho thứ nguyên với các đầu vào bạn đã sử dụng.
  • Sửa chữa tên / logo / hồ sơ qua Flaremetrics hoặc FSE.
  • Phê bình thuật toán chung.
Nguồn & tham chiếu
Mọi đầu vào cho điểm số đều đến từ các nguồn công khai, có thể xác minh trong hệ sinh thái Flare. Bất kỳ ai cũng có thể kiểm chéo các yêu cầu của chúng tôi với các nguồn chính này và tái tạo toán học từ dữ liệu thô. Nếu bạn phát hiện sự khác biệt giữa trang này và những gì các nguồn thượng game nói, hãy gửi email tới [email protected] và chúng tôi sẽ sửa nó.
Tài liệu giao thức có thẩm quyền. Bao gồm FTSO V2, FSP, xác thực P-Chain, FAssets và phần còn lại của ngăn xếp Flare.
Cổng quản trị Flare (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — nguồn sự thật cho các điều kiện tối thiểu giao thức V2, cơ học phí và những thay đổi về kinh tế phần thưởng cung cấp cho điểm số này.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Sổ đăng ký FTSO do Flare điều hành chính thức các nhà cung cấp dữ liệu, địa chỉ thực thể, liên kết nodeID P-Chain và các cờ điều kiện tối thiểu. Nguồn chính cho các thứ nguyên Accuracy, V2 và Participation của chúng tôi.
Flaremetrics ↗https://flaremetrics.io
Nhà cung cấp số liệu độc lập trong hệ sinh thái Flare. Nguồn tỷ lệ phần thưởng, phí, vote power, thay đổi vote power hàng ngày, vote power bị khóa, tên hồ sơ + logo và số liệu fspRewardRate.
Flare Block Explorer ↗https://flare-explorer.flare.network
Trình duyệt chỉ đọc tất cả trạng thái trên chuỗi. Cho phép bất kỳ ai xác minh các sự kiện RewardClaimed của V2 RewardManager (claimType=3 cho MIRROR), quá trình chuyển epoch phần thưởng và phần còn lại.
Repo reward-scripts của Flare Foundation ↗https://github.com/flare-foundation/reward-scripts
JSON được công bố theo mỗi epoch phần thưởng của Flare Foundation cho thấy phần thưởng được cung cấp theo trình xác thực. Đầu vào gián tiếp — cung cấp cho tính toán bonus hiệu suất vượt mức MIRROR thông qua indexer quan sát per-stake của FlareWatch.
Flaremetrics public API (FTSO providers) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Điểm cuối chính xác mà cron của chúng tôi sử dụng, trả về hồ sơ thực thể, tỷ lệ phần thưởng, phí và quyền bình chọn. Bất kỳ ai cũng có thể truy cập trực tiếp.
Flaremetrics public API (node registrations) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Bảng chuyển đổi Hex → cb58 NodeID. Chúng tôi phân trang điều này để xây dựng tra cứu thực thể-đến-NodeID điều khiển kích thước MIRROR Participation.
Không có dữ liệu riêng tư, không có mô hình đóng nguồn. Thuật toán chấm điểm được triển khai trong services/ftso/scoring.ts trong codebase FlareWatch. Các toán tử hoặc nhà nghiên cứu muốn kiểm tra triển khai trực tiếp (thay vì đọc các công thức văn bản + ở trên) — hoặc muốn fork nó cho riêng họ — có thể gửi email đến [email protected] để yêu cầu truy cập. Chúng tôi sẽ xuất bản tệp dưới dạng gói mã nguồn mở độc lập nếu có nhu cầu thực sự.
Cách điểm số cập nhật
Chấm điểm nhà cung cấp FTSO chạy như một pass bên trong cron tại /api/cron/refresh-validators, điều này tính toán lại điểm của mỗi nhà cung cấp hoạt động mỗi 5 phút (cùng một lần chạy tính toán lại điểm của các trình xác thực P-Chain). Các đầu vào (Flaremetrics, FSE, FSP rewards, V2 RewardManager events) được tìm nạp mới trên mỗi lần chạy.
Consistency CV sử dụng lịch sử kỷ nguyên gần đây — kích thước có thể thay đổi khi cửa sổ lăn dịch chuyển. Các nhà cung cấp mới có ít hơn 3 kỷ nguyên lịch sử chấm điểm trung lập 10 cho đến khi đủ dữ liệu tích lũy.
Phân phối trọng số động được tính toán lại trên mỗi lần chạy dựa trên bộ nhà cung cấp hoạt động hiện tại. Khi các nhà cung cấp di chuyển (ví dụ: một làn sóng nâng cấp V2 mới), kích thước trở nên không phân biệt được sẽ thay đổi; phân phối lại sẽ thích ứng tự động.
Phiên bản thuật toán được đóng dấu trong tiêu đề của trang này. Khi chúng tôi gửi một phiên bản mới, chuỗi phiên bản ở đây thay đổi và thẻ Phiên bản bên dưới ghi lại những gì đã di chuyển.
Phiên bản
v4.8 (2026-08-20) — Độ chính xác giờ đây thưởng cho dải phần thưởng KHÓ. Trước đây nó chỉ sử dụng dải secondary FTSO (rộng hơn), nơi gần như mọi nhà cung cấp nghiêm túc đều đạt 95–99% — vì vậy thứ nguyên này gần như là 25/25 phẳng trên đỉnh lĩnh vực, gần như không đo lường gì. Dải PRIMARY (IQR chặt chẽ) là kỹ thuật thực sự khó hơn và phân tán các nhà cung cấp ~28–80%. Flare thưởng các dải này 40% primary / 60% secondary (FIP.11, hoạt động kể từ 2024, với tăng cường dải secondary được báo hiệu thêm), vì vậy Độ chính xác hiện nay phản ánh điều đó: sự kết hợp 40/60. Secondary giữ đường cong trước đó; primary sử dụng đường cong tuyệt đối (28% → 0, 78% → đầy đủ 25), cố định để điểm số vẫn có thể tái tạo từ các đầu vào của chính nhà cung cấp đó. Đầy đủ trước/sau trên tất cả 100 nhà cung cấp được xếp hạng, lưu trữ trước khi triển khai: việc sắp xếp lại theo dõi sức mạnh dải primary — các nhà cung cấp thực hiện công việc dải chặt chẽ khó tăng lên, các nhà cung cấp chỉ dựa vào con số secondary dễ giảm xuống. Quy tắc tương tự áp dụng cho nhà cung cấp của chúng tôi, hiện có dải primary yếu: nó giảm từ 84 xuống 77 và giảm một số vị trí. Triển khai dù sao — một điểm số thưởng cho kỹ thuật thực sự, ngay cả của đối thủ cạnh tranh và ngay cả với chi phí của chúng tôi, là loại duy nhất có giá trị công bố.
v4.7 (2026-07-31) — Danh sách nhà cung cấp không còn phụ thuộc vào một chỉ số duy nhất, và điểm số không còn phạt các khoảng trống dữ liệu của chúng ta. (1) Danh sách hiện được xây dựng từ tập cử tri đăng ký trên chuỗi và được điền lại khi chỉ số bên thứ ba thiếu các thực thể: 98 nhà cung cấp so với 80 được hiển thị trước đó, do đó 18 nhà cung cấp thực tế không thể tìm kiếm và không thể ủy quyền từ đây nay đã xuất hiện. (2)
v4.6 (2026-07-01) — Consistency được khử thiên vị cho các nút mới. Nó là mean/stddev của tỷ lệ phần thưởng trên toàn bộ lịch sử 30 kỷ nguyên, vì vậy kỷ nguyên kiếm tiền ramp bị phong phú của nút mới (trọng lượng bình chọn nhỏ → tỷ lệ cao trên mỗi đơn vị, sau đó bình thường hóa) hoạt động như một ngoại lệ đã giữ CV cao — chấm 0 — trong nhiều tháng cho đến khi nó hết hạn. Bây giờ nó sử dụng cửa sổ cuối cùng (12 kỷ nguyên kiếm tiền gần đây) và phân tán trung bình/MAD mạnh mẽ, vì vậy kỷ nguyên ramp là một ngoại lệ vô hại trong khi biến động đang diễn ra chính thức vẫn chấm thấp.
v4.5 (2026-06-30) — Self-Bond được làm trung lập kích thước. Đường cong chỉ tỷ lệ có thể chấm self-bond tuyệt đối lớn ở tỷ lệ thấp BÊN DƯỚI self-bond nhỏ ở tỷ lệ cao. Self-Bond bây giờ ghi có phần lớn hơn của tỷ lệ căn chỉnh hoặc số tiền tuyệt đối bão hòa (giới hạn ở 5M FLR), vì vậy toán tử cam kết lớn và toán tử căn chỉnh đầy đủ nhỏ cả hai đều kiếm điểm tối đa — nó thưởng cho cam kết, không phải tài sản, và chất lượng trình xác thực vẫn ở các kích thước khác.
v4.4 (2026-06-30) — Hai sửa chữa lỗi thực sự. (1) Self-Bond là một kích thước CHẾT: nó đọc trường Flaremetrics mà API đã bỏ, vì vậy mỗi nhà cung cấp chấm 0/7. Được nguồn lại từ self-bond nút P-Chain thực sự của toán tử (tham chiếu chéo từ bộ trình xác thực theo nodeID). (2) Compliance ngừng phạt các kỷ nguyên trước khi nhà cung cấp hoạt động — một nút mới kiếm tiền sạch sẽ kể từ khi nó ra mắt trước đây bị tính phí cho mỗi kỷ nguyên trước nó, giữ nó ở 0/10 trong nhiều tuần. Các kỷ nguyên bị bỏ lỡ bây giờ chỉ được tính trong cửa sổ hoạt động của mỗi nhà cung cấp.
v4.3 (2026-06-03) — Làm rõ phương pháp, không thay đổi toán học chấm điểm. Kích thước Accuracy bây giờ được định nghĩa rõ ràng là tỷ lệ hạ cánh dải phụ trên chuỗi (CHẤT LƯỢNG giá — phần nào giá được gửi hạ cánh bên trong dải chấp nhận), khác biệt với kích thước Compliance, đếm các kỷ nguyên phần thưởng bị bỏ lỡ (FSP THAM GIA). Trang này và các gợi ý bảng trình xác thực được viết lại để làm cho sự khác biệt rõ ràng, và một cột Compliance được thêm vào cùng với Accuracy. Cả hai kích thước giữ trọng số trước đây (25 và 10) và đầu vào (fseAccuracySecondary và epochsWithoutRewards).
v4.2 (2026-05-20) — Kích thước Rewards Distributed đã được sửa chữa. Nó được nối với trường phân phối phần thưởng Flaremetrics mà API v3 của nhà cung cấp đã bỏ, vì vậy kích thước đọc 0 cho mỗi nhà cung cấp và không đóng góp gì. Được nối lại với tổng phần thưởng ủy quyền FSP trên chuỗi — dữ liệu đơn yêu cầu phần thưởng giống như kích thước Compliance đã tổng hợp — vì vậy kích thước khác biệt lại.
v4.1 (2026-05-20) — Kích thước Compliance bị kẹp. epochsWithoutRewards có thể đến âm vì cron phần thưởng FSP tích lũy số lượng hiện diện kỷ nguyên của nó vượt quá cửa sổ lăn, cho phép Compliance vượt quá nắp 10 điểm (quan sát đến ~58) và đẩy tổng hợp qua tối đa — bão hòa khoảng 70% nhà cung cấp với căn bản 100. Compliance bây giờ bị kẹp vào trọng số của nó, và cron FSP tính toán lại tóm tắt phần thưởng không trạng thái trên mỗi cửa sổ để số lượng không thể trôi dạt.
v4.0 (2026-05-11) — Đẩy kiểm toán công bằng đầy đủ tương đương với phiên bản v4.0 phát hành điểm trình xác thực. Hai lỗi thực sự được sửa chữa: (1) Delegator Count có động lực phản chứng tại 500 — sửa chữa trước kỳ 500-delegator trả về 14 điểm nhưng giới hạn >500 trả về WEIGHT_DELEGATORS cơ bản (12), vì vậy lợi đạt delegator trên ranh giới đó mất 2 điểm. Bây giờ được log-scaled từ 5 → 500, đơn điệu hướng lên. (2) Kỷ nguyên V2 Participation bị sập — đăng ký V1 một phần và V2 đầy đủ (Scaling + FastUpdates + FDC) cả hai trả về 15, vì vậy nâng cấp từ V1 một phần sang V2 đầy đủ cung cấp cải thiện điểm bằng 0. Bây giờ xếp chồng mỗi giao thức (hoạt động +3, V1 +4, mỗi V2 giao thức +~2,67). Vách đá ranh giới loại bỏ trong Accuracy (có vách 7pt ở 97%), Stability, và Self-Bond Ratio — tất cả tuyến tính với giá trị được bảo toàn ở ranh giới xô. Đường cong Reward Rate được cân bằng lại để trung vị = nửa điểm kích thước (là 40%). Hòa giải docstring kích thước cũ với giá trị trọng số thực tế. Hiệu ứng ròng: mỗi kích thước là đơn điệu hướng lên trên trục đầu vào, và không có nhà cung cấp nào có thể hạ thấp điểm FlareWatch của họ bằng cách cải thiện số liệu hoạt động thực tế.
v3 (2026-05-09 → 2026-05-11) — Chấm điểm 13 kích thước với phân phối trọng số động và phạt phân loại quyền bình chọn. MIRROR Participation được giới thiệu như một kích thước hạng nhất (12 cơ sở + tối đa +3 tiền thưởng hiệu suất cao với thu nhỏ Bayes và cổng tích lũy dữ liệu 30 ngày). Identity và Self-Bond được thêm như các kích thước riêng biệt. Reward Rate được chuyển sang neo trung vị. Accuracy sử dụng số liệu phụ FSE để dải độ phân giải cao. Consistency sử dụng CV trên các kỷ nguyên gần đây.
v2 và trước đó — Các phiên bản trước v3 không được ghi lại ở đây; chúng sử dụng một tập hợp con đơn giản hơn của các kích thước và trước khi phân phối trọng số động. Phiên bản không còn sử dụng ưu tiên cho mô hình hiện tại.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.