Phương pháp Tính Điểm Trình Xác Thực

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

FlareWatch gán cho mỗi trình xác thực P-Chain một điểm tổng hợp 0–100 trên 9 chiều. Toán học là xác định, các đầu vào là dữ liệu chuỗi công khai [Flare Explorer] [FSE] [Flaremetrics], và cùng một thuật toán áp dụng cho mọi trình xác thực trên mạng — bao gồm nút trình xác thực của chính FlareWatch, được tính bởi chính hàm này mà không có xử lý đặc biệt nào. Trang này ghi lại mọi chiều và ngưỡng để các nhà khai thác và những người staking có thể thấy chính xác cách tính điểm và tại sao mỗi giá trị được chọn. Mọi yêu cầu ở đây liên kết trở lại nguồn gốc trên chuỗi hoặc nguồn cấp trên của nó — xem Nguồn & tham khảo ở cuối.

Phạm vi: trang này ghi lại điểm trình xác thực — những gì bạn thấy trong staking mode trên trang trình xác thực (ủy quyền FLR cho trình xác thực P-Chain để nhận phần thưởng VRM + MIRROR). Điểm nhà cung cấp FTSO hiển thị trong delegation mode (ủy quyền WFLR cho các nhà cung cấp dữ liệu FTSO) sử dụng một thuật toán 13 chiều riêng biệt tập trung vào hiệu suất nhà cung cấp dữ liệu — độ chính xác, tham gia giao thức V2, v.v. Đây là các vai trò on-chain riêng biệt có phần thưởng riêng biệt, được tính điểm riêng biệt. Xem Phương pháp Tính Điểm Nhà Cung Cấp FTSO cho phía ủy quyền.

Không có tương đương SGB: việc tính điểm này áp dụng cho các trình xác thực P-Chain Flare chỉ. Tập hợp trình xác thực P-Chain của Songbird bị giới hạn ở các thực thể được Flare Foundation phê duyệt, vì vậy ủy quyền P-Chain SGB bán lẻ là hiếm và tab staking chỉ là FLR. Không có bộ chuyển đổi FLR / SGB trong staking mode. Để ủy quyền FTSO SGB xem Phương pháp Tính Điểm Nhà Cung Cấp FTSO, bao gồm cả hai chuỗi.

Cách chúng tôi tính toán APY — những gì bạn thực sự kiếm

APY trên bảng staking là tỷ lệ toàn bộ mà một người ủy thác nhận được — một con số, không cần tính toán tinh thần. Nó được đo từ các script phần thưởng của Flare (payout thực tế, không phải công thức), sau khi trừ phí của validator, và nó thay đổi mỗi epoch theo phần thưởng thực tế. Ở mọi nơi trên FlareWatch, APY có nghĩa là sau khi trừ phí và APY có nghĩa là trước nó.

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

Phần thưởng staking (VRM) — phần chia net của người ủy quyền từ phần thưởng xác thực = Σ payout người ủy quyền ÷ Σ delegated (chia của chính Flare; phí đã bị loại bỏ). Vì Flare trả tỷ lệ với stake, điều này gần như đồng đều trên toàn bộ mạng và khác nhau chủ yếu bởi phí — phí thấp hơn có nghĩa là tỷ lệ ủy quyền cao hơn.
MIRROR — phần chia stake của bạn trong lạm phát FTSO, được trả thêm, chỉ trên các trình xác thực chạy một stack FTSO hoạt động. Nó thay đổi tùy theo sự tham gia FTSO của trình xác thực và được đo trên các epoch gần đây nhất.

So sánh với Flare Systems Explorer? FSE và các trình khám phá khác hiển thị tỷ lệ ủy thác duy nhất — họ không cộng MIRROR — vì vậy APY tổng của chúng tôi đọc cao hơn trên bất kỳ validator MIRROR-active nào (khoảng cách chính xác là dòng MIRROR ở trên). Cả hai con số đều là ~8-epoch trailing averages từ cùng dữ liệu reward-scripts, vì vậy thay đổi phí mid-window của validator lạm vào một ảnh chụp phí hiện tại trên trang web bất kỳ cho đến khi nó lão hóa qua cửa sổ.

Hai con số khác xuất hiện trong tooltip APY và không phải là tỷ lệ của người ủy thác: đường cơ sở lý thuyết (APY tổng của mạng × (1 − phí), chỉ staking — được sử dụng làm fallback trước khi có đủ lịch sử đo được), và lợi suất tự ràng buộc của nhà điều hành (lợi suất stake riêng của validator, được khuếch đại bởi việc thu phí — một số liệu nhà điều hành, không phải những gì bạn kiếm).

Để tính điểm: chiều Net Yield tính điểm chỉ tỷ lệ ủy thác VRM và MIRROR được tính điểm trong chiều riêng của nó — vì vậy MIRROR không bao giờ được tính điểm kép, ngay cả khi nó được bao gồm trong APY tổng được hiển thị.

Dải điểm

90+	Tầng hàng đầu — hàng đầu ~10–20% các nhà khai thác. Hồ sơ điển hình: trình xác thực full-stack + FTSO + FDC, phí ở mức thấp, hoạt động MIRROR, độ tin cậy FIP-10 nhất quán, cơ sở người ủy quyền lành mạnh, self-bond có ý nghĩa. Không yêu cầu chiều nào đơn lẻ — các nhà khai thác đạt tầng hàng đầu bằng cách xếp chồng sức mạnh trên hầu hết các loại.
80–89	Mạnh — đáp ứng hầu hết các tiêu chuẩn chính; thiếu một hoặc hai chiều so với tầng hàng đầu.
70–79	Tốt — đáp ứng tất cả các tiêu chí cơ sở; không có khoảng trống lớn.
60–69	Chấp nhận được — có thể sử dụng nhưng không phân biệt.
<60	Dưới trung bình — khoảng trống đáng kể trong một hoặc nhiều chiều. Sự thật toán học, không phải đánh giá chất lượng.

Các chiều (tổng cộng 100)

Uptime20 điểm tối đa

Cái gì: Kết hợp uptime RPC P-Chain tức thì VÀ tỷ lệ đủ điều kiện uptime FIP-10 lịch sử trên các epoch phần thưởng gần đây.

Làm sao: Đường cong RPC: ≥ 99,5% → 17 đến 20. 99–99,5% → 13–17. 95–99% → 4–13. 90–95% → 0–4. < 90% → 0. Kết quả sau đó được nhân với uptimeReliability (epochsIncluded / epochsObserved trong 8 epoch phần thưởng gần đây nhất từ dữ liệu public reward-scripts — bộ minimums FIP-10 đầy đủ kể từ v4.2, không chỉ riêng RPC-uptime). v3.9 đã sửa một cliff nghịch lý tại đúng 95% nơi chuyển từ 94,99 → 95,00 uptime mất 4 điểm.

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

Tại sao: Trước v3.4, chiều này về cơ bản đã chết — 92.9% các trình xác thực trực tiếp có uptime RPC 100%, vì vậy đường cong tính điểm mọi người giống nhau. Tỷ lệ độ tin cậy là một tín hiệu chuỗi thời gian thực: một trình xác thực không đáp ứng điều kiện tối thiểu FIP-10 trong 3 trong 8 epoch gần đây có điểm độ tin cậy 62.5%, bất kể RPC tức thì hiện nay báo cáo gì. Nghiêm ngặt hơn mục tiêu giao thức 80% của FIP-10 có mục đích. Dữ liệu đủ điều kiện theo epoch được công bố bởi Flare Foundation trong repo script phần thưởng của họ.

Net Yield18 điểm tối đa

Cái gì: Tỷ lệ phần thưởng staking trừ phí (VRM) mà người ủy quyền nhận được, neo tại trung vị mạng.

Làm sao: scoreAPR = tỷ lệ ỦYQUYỀN ròng đo được (delegationAPY: Σ delegatorRewardAmount / Σ delegated, từ script phần thưởng Flare Foundation, ~8 epoch gần đây) khi có, nếu không thì baseAPR lý thuyết = gross × (1 − phí). Điểm = (scoreAPR / medianAPR) neo: tỷ lệ 0.6 → 0 điểm, 1.0 (trung vị) → 12 điểm, 1.2 → 18 điểm. QUAN TRỌNG: chiều này tính điểm tỷ lệ VRM (validation-reward) CHỈ — MIRROR được tính điểm riêng biệt trong chiều Tham Gia MIRROR, vì vậy nó không được tính hai lần ở đây. 'Total APR' được hiển thị (VRM + MIRROR) là một số hướng đến người ủy quyền, không phải đầu vào Net Yield.

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

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

Tại sao: Cả hai bên của tỷ lệ đều là tỷ lệ ủy quyền ròng (delegationAPY đo được so với gross×(1−phí) lý thuyết), vì vậy so sánh giống như — không còn được tăng cường bởi 1/(1−phí) như khi đầu vào là tỷ lệ gross trước phí (lỗi 'doubling' ~2×). Vì Flare trả phần thưởng xác thực tỷ lệ với stake, tỷ lệ ủy quyền VRM gần như đồng đều trên toàn bộ mạng và thay đổi chủ yếu bởi phí — vì vậy chiều này phản ánh chủ yếu sự cạnh tranh phí và độ tin cậy cung cấp (trình xác thực bỏ lỡ epoch cung cấp ít hơn). MIRROR (thay đổi tùy theo sự tham gia FTSO) được cố ý giữ trong chiều của riêng nó để tránh tính hai lần.

Tính Hợp Lý về Phí7 điểm tối đa

Cái gì: Ngăn chặn việc chiết xuất vượt quá mức phí cơ sở của giao thức, mịn từng phần tuyến tính.

Làm sao: Điểm neo = max(mức phí hoạt động tối thiểu quan sát được, mức sàn phí của giao thức — 20% kể từ hard fork Granite, 2026-07-14). Bất kỳ phí nào ở mức điểm neo hoặc dưới đó → đầy đủ 7 điểm. Trên đó, một lên dốc tuyến tính với độ dốc ngày càng dốc hơn trong 20 điểm phí tiếp theo (neo+5 → 6, neo+10 → 4,5, neo+15 → 2,5, neo+20 → 0): vượt quá nhỏ hầu như không bị phạt, chiết xuất bị phạt nặng. Trước Granite, điểm neo là mức tuyệt đối 5%; kẹp sàn có nghĩa là không có nhà điều hành nào bao giờ bị phạt vì tính phí tối thiểu hợp pháp.

// 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

Tại sao: Net Yield đã tính đến phí theo phần trăm dưới dạng các thuật ngữ được cung cấp; chiều này chỉ gắn cờ các nhà điều hành tính phí cao hơn đáng kể so với những gì giao thức và thị trường cho phép. Khi mọi phí đều ở mức sàn bắt buộc 20%, mọi người sẽ kiếm được điểm tối đa ở đây và chiều này ngừng phân biệt — theo thiết kế: một con số mà không ai có thể cạnh tranh dưới nó không thể phân biệt ai cả.

Chất Lượng Nhà Khai Thác12 điểm tối đa

Cái gì: Lấy cái cao hơn của hai tín hiệu độc lập: baseline xác minh (độ tin cậy danh tính) và hiệu suất hoạt động xuất phát từ FTSO.

Làm sao: Baseline xác minh: tầng curated (+7) đạt được theo hai cách — mục nhập KNOWN_VALIDATORS xác minh thủ công HOẶC tự động thăng tiến thông qua hành vi khách quan (v3.10: 90+ ngày quan sát VÀ 25+ nhà khai thác tổng hợp người ủy quyền VÀ không hiện đang thu hẹp VÀ self-bond ≥ mặt sàn FIP-10). Tên được khám phá tự động từ Flaremetrics hoặc FSE → +3. Chưa xác minh → 0. FTSO-xuất phát: nội suy tuyến tính điểm FTSO 50 → 4 điểm lên tới điểm FTSO 100 → 12 điểm (dưới 50 tầng ở 4). Điểm cuối cùng là max(xác minh, FTSO-xuất phát) — tham gia FTSO chỉ có thể giúp, không bao giờ làm tổn thương.

// 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)

Tại sao: Thưởng những nhà điều hành chạy stack đầy đủ (validator + FTSO + FDC) mà không phạt những nhà điều hành được tin cậy vì tham gia FTSO với điểm mid-tier. Logic max() của v3.8 rõ ràng ngăn chặn incentive xấu của 'bỏ FTSO để cải thiện điểm FlareWatch của bạn.' Tier tự khám phá (+3) đóng cliff 7→0 trước đó đã ảnh hưởng tới những nhà điều hành đăng ký với Flaremetrics hoặc FSE nhưng chưa được tuyển chọn thủ công.

MIRROR Participation12 điểm tối đa

Cái gì: Liệu nodeID của validator có thực sự mang lại cổ phần lạm phát FTSO cho những người stake — cả tỷ lệ phần trăm chuyển tới những người ủy quyền (fee passthrough) và, kể từ v4.6, số tiền được mang lại so với lĩnh vực.

Làm sao: Active → 10 × (1 − fee/100). Paused → 5 × passthrough. Inactive (không có tín hiệu tham gia ở bất cứ đâu) → 0. Không có dữ liệu (validator thực sự không được quan sát) → 5 × passthrough. v3.6 mở rộng tín hiệu 'active' để bao gồm cả sự kiện RewardClaimed(claimType=3) on-chain VÀ cấp phát claimType=3 trong FSP Merkle JSON chính tắc — một trong hai là đủ. Điều này bắt những validator có MIRROR đã được cấp phát nhưng chưa được yêu cầu on-chain (ví dụ, những nhà cung cấp tự ủy quyền có đường dẫn thanh toán không kích hoạt sự kiện yêu cầu tiêu chuẩn). v4.6 khoản thưởng magnitude (tối đa +2, trần dimension 12): chỉ dành cho validator mirror-active, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2) — ghi nhận cho việc mang lại tỷ lệ MIRROR trên trung vị (net của phí) cho những người ủy quyền. Được neo bằng tỷ lệ trung vị mạng, vì vậy nó là trung lập về kích thước: một validator nhỏ mang lại tỷ lệ cao kiếm được khoản ghi nhận giống như một validator lớn.

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

Tại sao: MIRROR phân phối tự động cho những người stake trên validator tham gia FSP. Một validator phí 100% là 'active' mang lại $0 cho những người ủy quyền; điểm số phản ánh những gì những người ủy quyền thực sự nhận được, không chỉ trạng thái cờ phía giao thức. Khoản thưởng magnitude v4.6 đóng một điểm mù: passthrough một mình đo TỶ LỆ PHẦN TRĂM chuyển tới những người ủy quyền nhưng không phải SỐ TIỀN, vì vậy một validator trả tỷ lệ MIRROR được mang lại cao hơn nhiều kiếm được không ghi nhận bổ sung cho nó. Bây giờ nó làm — giới hạn, và chỉ trên trung vị mạng.

Capacity Profile7 điểm tối đa

Cái gì: Hàm tent đạt đỉnh ở mức sử dụng phù hợp.

Làm sao: 0% sử dụng → 1.75. Tăng tuyến tính lên 7 ở 70% sử dụng. Giảm tuyến tính xuống 5.25 ở 100% (có giới hạn). Được tính toán lại trong v3.7 từ 8 → 7 để tài trợ các thành phần quỹ đạo Trust mới.

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

Tại sao: Ở giới hạn delegations FIP-10 tối đa là tín hiệu TÍCH CỰC của sự hấp dẫn — được chứng minh là đáng tin cậy bởi đủ delegators để lấp đầy. v2 chấm điểm validators capped 0/5; v3 sửa lại. Phù hợp (được chứng minh hấp dẫn VÀ có chỗ) nhận đỉnh. v3.7 cắt giảm cap dimension 8 → 7 để điểm được giải phóng có thể tài trợ các thành phần quỹ đạo retention + self-bond mới của Trust.

Community Trust11 điểm tối đa

Cái gì: Multi-signal: delegator count + stake-distribution health + longevity + operator self-bond commitment (proportional and absolute) + 30-day retention + self-bond trajectory + multi-node operator aggregation.

Làm sao: Count signal (max 6, OPERATOR-AGGREGATED v3.7): log-scaled [5, 500] delegators → [0, 6], summed across all of an operator's known nodes. Concentration adjustment (±1): retail-friendly avg stake (<500K FLR) → +1, whale-concentrated (>50M FLR avg) → −1. Longevity bonus (max +1, wipe-immune v3.6): +0.5 at 30 days observed, +1 at 90+ days — falls back to reward-scripts epoch presence if the first-observed KV was wiped. Self-bond skin-in-the-game (max +2 / min −1, TWO-AXIS v4.7): credited by the BETTER of proportional share OR absolute size — proportional ≥10% → +2 / 5–10% → +1, and absolute = min(1, selfBond ÷ 20M) × 2 saturating at the network top-decile bond; the signal takes the max of the two, still capped at +2. Sub-FIP-10 floor (<1M FLR) → −1. Retention (max ±0.5, NEW v3.7): delegated FLR +10% over 30 days → +0.5, −15% → −0.5. Self-bond trajectory (max ±0.5, NEW v3.7): operator's self-bond +20% over 30 days → +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)

Tại sao: Skin-in-the-game self-bond là một tín hiệu công bằng thực sự mà chúng tôi đã thiếu — một validator có 10% tổng stake làm self-bond có incentives căn chỉnh vật chất hơn một validator chạy ở mức tối thiểu FIP-10. v4.7 làm cho đây là hai trục: đọc self-bond chỉ như một tỷ lệ penalised các nhà điều hành đã gửi xuống một stake tuyệt đối lớn rồi sau đó thu hút delegation, điều này loãng tỷ lệ mà không giảm cam kết thực tế — một self-bond 20M ở một tỷ lệ loãng ghi điểm giống hệt như một bond dưới 2M ở tỷ lệ đó. Tín hiệu hiện nay tín dụng ĐIỀU TỐT HƠN của proportional share hoặc kích thước tuyệt đối, mặt tuyệt đối bão hòa ở một bond top-of-network vì vậy kích thước không thể đơn giản mua điểm số, phù hợp với cách điểm số nhà cung cấp FTSO đã xử lý self-bond; giới hạn +2 không thay đổi, vì vậy các nhà điều hành cam kết lớn hiện nay có thể đạt tới nó nhưng trần không di chuyển. Longevity thưởng các hồ sơ được chứng minh mà không penalize người mới (bonus nhỏ ở trên, không phải penalty dưới). Concentration risk quan trọng cho delegators — một validator có 1 whale ở 50M FLR có cấu trúc khác với 50 retail ở 1M mỗi cái. Hai tín hiệu trajectory v3.7 thưởng tăng trưởng hữu cơ và cam kết nhà điều hành đang phát triển. Giới hạn kết hợp là 11 (được nâng từ 10 trong v3.7 để tài trợ cho chúng), không có tín hiệu nào nổi bật.

Delivery Reliability10 điểm tối đa

Cái gì: Tỷ lệ net delegation rate (VRM) thực sự được phân phối vs. baseline lý thuyết, với penalty variance cho payouts không nhất quán. Cả hai phía đều net of fee, vì vậy tỷ lệ đo lường phân phối thực — không phải fee.

Làm sao: Delivery ratio piecewise linear: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → linear ramp toward 0. Variance penalty: coefficient of variation × 0.5, capped ở −30%. Confidence dampener blend tới neutral 5 khi sample size < 3 epochs. v3.9 tuyến tính hóa các thresholds được bucketed trước đó — boundary cliffs lên tới 2 điểm giờ smooth.

// 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

Tại sao: Promised vs. delivered là tín hiệu accountability trực tiếp nhất cho stakers. v3.3 thêm hai tinh chỉnh: (1) headline ratio sử dụng exponentially time-weighted mean (recent epochs tính toán nhiều hơn), vì vậy một validator từng phân phối tốt nhưng gần đây bị trượt được phạt đúng cách; (2) variance penalty phân biệt 95% deliverers nhất quán từ oscillating-around-95% deliverers, vì cái sau mang nhiều rủi ro hơn cho stakers quan tâm tới predictable yield.

Time Remaining5 điểm tối đa

Cái gì: Số ngày cho tới khi stake-end của validator trên P-Chain.

Làm sao: < 14 ngày → 0 (về cơ bản không khả dụng theo FIP-10). 14-30d → linear 0→2. 30-60d → linear 2→3. 60-120d → linear 3→5. 120d+ → 5. v3.9 tuyến tính hóa các thresholds được bucketed trước đó — boundary cliffs (ví dụ 13.99d → 0, 14d → 2) giờ smooth.

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

Tại sao: Tín hiệu thực tế — delegate tới validator với 7 ngày còn lại là mệnh đề khác so với 1 năm. v3.2 siết chặt bottom: validators trong 14 ngày tới stake-end không thể chấp nhận delegations mới (FIP-10 minimum lock là 14 ngày), vì vậy chúng về cơ bản unstakeable. Score = 0 phân biệt 'unstakeable ngay bây giờ' từ 'winding down sớm.'

Active Outage Penalty (v4.3)(deduction) điểm tối đa

Cái gì: Flat deduction layered trên đỉnh của các dimensions dương khi validator miss nhiều reward epochs liên tiếp. Khác biệt từ symmetric Uptime reliability multiplier — captures active outages, không phải chronic flakiness.

Làm sao: Nhìn vào !eligible prefix liên tục của validator trong cache:fsp-validator-participation record (newest-first epoch list từ public reward-scripts nodes-data.json). 0–1 consecutive misses → 0 pts (trong variance / single transient miss). 2 consecutive → −3 pts (developing outage). 3 consecutive → −6 pts (sustained — operator inattention). 4+ consecutive → −10 pts (active extended outage). Composite score được floor ở 0 sau deduction.

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)

Tại sao: Pre-v4.3 model dựa hoàn toàn vào symmetric uptimeReliability multiplier — 5 scattered misses qua 24 epochs chi phí giống như 5 misses liên tiếp. Từ khía cạnh hoạt động những cái đó là tín hiệu rất khác. Scattered misses nói với delegators về chronic flakiness; một streak nói với họ validator bị hỏng NGAY BÂY GIỜ. Sự cố Luganodes vào 2026-05-14 — multiple consecutive missed epochs trong khi delegators tích cực cam kết hàng triệu FLR — là trường hợp cụ thể mà phiên bản v4.3 giải quyết: surface tín hiệu active-outage với score impact sharper để delegators tránh in-flight failure trước khi cam kết. Tiered curve tránh overreacting tới single transient misses (phổ biến) trong khi sharply flagging sustained streaks (hiếm và consequential).

Phạt Phí Cực Cao (v4.5)(tối đa −75% điểm số) điểm tối đa

Cái gì: Khấu trừ tỷ lệ cho phí vượt quá phạm vi của thứ nguyên Phí. Thứ nguyên Phí đạt mức tối thiểu 0/7 khi phí vượt quá mốc neo bởi 20 điểm — vượt quá đó, thành phần trước đây đã ngừng phản ứng với phí hoàn toàn, do đó một trình xác thực với phí 100% (các ủy quyền của nó không giữ lại gì) vẫn có thể ghi điểm trong những thứ nguyên không nhạy cảm với phí như uptime và MIRROR.

Làm sao: Bằng không tại hoặc dưới mức phí 50% — thứ nguyên Phí đã định giá phạm vi đó, vì vậy không có tính toán kép. Trên 50%, khấu trừ tăng tuyến tính theo phí, đạt 75% của điểm số tích cực của trình xác thực tại mức phí 100%. Nó được mở rộng theo chính điểm số, vì vậy một nút riêng được bảo dưỡng tốt và một nút bị bỏ bê đều rơi vào đúng nơi của chúng: ở cuối bảng xếp hạng dành cho ủy quyền.

// 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)

Tại sao: Đây là một điểm số dành cho các ủy quyền. Một trình xác thực giữ lại mọi phần thưởng mà các ủy quyền của nó kiếm được không phải là ứng cử viên ủy quyền bất kể uptime của nó có tốt hay không — điểm số nên nói điều đó một cách rõ ràng. Chức năng thuần tuý của phí on-chain, được áp dụng giống hệt cho mọi nút, bao gồm của chúng tôi.

Cách để ghi 100/100 — validator playbook

Chu kỳ audit tạo ra v4.0 được thiết kế cụ thể sao cho maxing mỗi dimension thực sự làm cho bạn trở thành validator tốt hơn cho delegators của bạn. Cải thiện điểm số của bạn không phải gaming hệ thống — đó là hệ thống hoạt động như được thiết kế. Đây là playbook rõ ràng, per dimension.

Uptime — 20 pts. Duy trì ≥99.5% RPC uptime liên tục VÀ pass FIP-10 minimum conditions trong mỗi reward epoch (không miss reveals, hit median delivery). Hai tín hiệu được nhân — 100% RPC × 7/8 epochs eligible = 17.5/20, không phải 20. Tại sao điều này sắp xếp với delegators: mỗi epoch bạn fail FIP-10, delegators của bạn mất rewards của họ cho epoch đó.

Net Yield — 18 điểm. Cung cấp ≥1,2× APY trung bình của mạng cho những người ủy thác của bạn (sau khi trừ phí). Đường dẫn tốt nhất: phí thấp + đủ điều kiện FIP-10 đầy đủ để những người ủy thác nhận được phần chia sẻ đầy đủ của họ. Tại sao điều này phù hợp: đây chính xác là khoản tiền đô la đến người ủy thác sau khi bạn lấy phần của mình.

Tính Hợp Lý của Phí — 7 điểm. Kể từ hard fork Granite, giao thức bắt buộc mức phí ủy quyền tối thiểu 20%, và bất kỳ phí nào ở mức neo tính điểm (mức lớn hơn giữa mức tối thiểu thị trường quan sát được và mức sàn đó) sẽ kiếm được đầy đủ 7. Tính phí trên nó sẽ mất điểm trên một lên dốc gia tốc — neo+10 → 4,5 điểm, neo+20 → 0. Tại sao điều này phù hợp: mức sàn làm chết cạnh tranh phí, vì vậy chiều này giờ chỉ bảo vệ những người ủy quyền khỏi chiết xuất trên mức tối thiểu hợp pháp; lợi thế thực sự của bạn nằm ở Net Yield được cung cấp.

Operator Quality — 12 pts. Best path: đăng ký như một FTSO data provider và chạy stack top-quality (FTSO + FDC + signing) — FlareWatch Operator Quality score của bạn sau đó đến từ FTSO score của bạn, với max ở FTSO 100. Alternative nếu bạn chỉ staking-only: duy trì +7 verification baseline hoặc bằng qualifying cho v3.10 auto-promotion (90+ ngày quan sát, 25+ delegators, retention không giảm, FIP-10-compliant self-bond) hoặc bằng being added tới KNOWN_VALIDATORS như institutional infrastructure (manual fast-track). Score lấy max(verification, FTSO-derived) — participation không bao giờ có thể gây hại. Tại sao điều này sắp xếp: full-stack operators cung cấp giá trị ecosystem nhiều hơn; verification baseline cung cấp delegators tín hiệu danh tính rõ ràng hơn.

MIRROR Participation — 10 pts. Submit FSP price feeds một cách nhất quán, đáp ứng per-epoch protocol minimums (registered trong signing policy của bạn, claim threshold met, no reveal misses). Charge moderate fee — score được nhân với (1 − fee/100), vì vậy thậm chí một 100%-fee validator hoàn hảo MIRROR-active ghi 0 vì zero MIRROR đến delegators. Tại sao điều này sắp xếp: MIRROR là share của delegators của bạn từ FTSO inflation. Lower fee = nhiều đến họ hơn.

Capacity Profile — 7 pts. Target ~70% utilization (right-sized: proven attractive VÀ có chỗ cho delegators mới). Empty validators ghi 1.75; capped validators ghi 5.25. Tại sao điều này sắp xếp: delegators mới đọc score muốn biết họ thực sự có thể delegate; right-sized tín hiệu cả social proof và availability.

Community Trust — 11 pts. Sáu thành phần để max:

Build tới 500+ operator-aggregated delegators (max count signal: +6 pts).
Duy trì retail-friendly avg stake < 500K FLR per delegator (concentration bonus: +1).
Ở trên network ≥ 90 ngày cho longevity bonus (+1) — wipe-immune via reward-scripts presence.
Giữ một large self-bond — hoặc ≥ 10% proportionally HOẶC một stake tuyệt đối top-of-network (~20M FLR), cái nào ghi điểm tốt hơn (alignment bonus: +2).
Grow tổng delegated FLR bởi ≥ 10% trong 30 ngày (retention: +0.5).
Tăng self-bond thêm ≥ 20% trong 30 ngày (trajectory: +0.5).

Tại sao điều này phù hợp: mỗi thành phần thưởng cho hành vi mà các delegator muốn — operator có skin-in-the-game, tăng trưởng hữu cơ, tính bền vững, sự tham gia rộng rãi của cộng đồng. Các operator đa nút được tổng hợp cho count + concentration signals (v3.7).

Delivery Reliability — 10 pts. Trả cho các delegator những gì APY ước tính của bạn hứa (delivery ratio 1.00). Giảm thiểu phương sai trên mỗi epoch — payouts có thể dự đoán được tốt hơn cùng một giá trị trung bình với spread cao (variance penalty up to −30%). Xây dựng sample size 8+ epochs cho full confidence weighting. Tại sao điều này phù hợp: bạn có đang thực hiện lời hứa mà bạn đã đưa ra không, một cách nhất quán? Đó là signal accountability trực tiếp nhất.

Time Remaining — 5 pts. Giữ stake-end date của bạn ≥ 120 ngày tính từ bây giờ. Gia hạn tốt trước khi hết hạn; đừng để nó trượt vào dải < 14 ngày (bạn không thể chấp nhận delegations mới theo FIP-10 khi bạn ở trong 14 ngày). Tại sao điều này phù hợp: commitment dài hơn báo hiệu cho delegators rằng bạn sẽ ở đây lâu dài.

Time-gated signals mà bạn không thể tắc đường: longevity bonus (90 days observed), auto-curation tier (90 days + 25 delegators + non-declining retention + FIP-10 self-bond), retention signal (30 days of delegation history), delivery sample size (8 reward epochs). Tin tốt: duy trì các hành vi KHÁC tự động tích lũy những điều này theo thời gian.

Smoothing window quan trọng trong ngắn hạn: điểm số hiển thị là trung bình có trọng số theo hàm mũ của 4 snapshot cron cuối cùng (0.5 / 0.3 / 0.15 / 0.05), vì vậy ngay cả 100 hoàn hảo trên inputs cũng mất ~20 phút cron runs hoàn hảo liên tiếp để fully reflect. Steady-state perfect inputs = 100; transient improvements được smoothed in. Sudden-change penalties (fee jumps, self-bond drops, uptime crashes) cũng có thể giảm đến 10 pts trong một vài cron cycles sau khi phát hiện.

Tóm lại: mỗi chiều hướng là trung thực về những gì nó đo lường. Nếu validator của bạn ở 100/100, điểm số cũng đang cho delegators biết rằng họ nhận được phiên bản tốt nhất của một validator trên mạng — đó là design intent.

Cách xác minh điểm số của riêng bạn

Mọi điểm số trong bảng validators đều có thể tái tạo lại từ dữ liệu công khai. Nếu bạn là một operator và toán học ở đây không khớp với điểm số bạn thấy, điều đúng cần làm là xác minh nó tự mình trước khi cho rằng chúng tôi đã mắc lỗi.

Kiểm tra nhanh nhất chạy tự động. Mở rộng hàng điểm số của bất kỳ validator nào và panel "Verified in your browser" tính toán lại điểm số đó cục bộ — hàm scoring chính xác mà cron sử dụng, trên inputs chính xác mà nó sử dụng, không có cuộc gọi quay lại máy chủ của chúng tôi. Vì mọi validator được scoring bằng một hàm identical không có term cho node identity, đây cũng là cách bất kỳ ai cũng có thể xác nhận node riêng của chúng tôi không được hưởng ưu đãi ẩn. Hướng dẫn thủ công dưới đây làm điều tương tự bằng tay:

Tra cứu thống kê công khai của validator của bạn tại flaremetrics.io (tìm kiếm theo tên operator của bạn hoặc dán địa chỉ delegation của bạn). Ghi chú delegationFee, selfBond, delegatedStake, và FTSO score (nếu bạn cũng là data provider).
Xác minh FIP-10 eligibility của bạn cho mỗi 8 reward epochs cuối cùng tại github.com/flare-foundation/reward-scripts dưới generated-files/reward-epoch-N/nodes-data.json. Đếm có bao nhiêu epochs nodeID của bạn có uptimeEligible: true. Tỷ lệ đó xác định multiplier Uptime dimension của bạn.
Kiểm tra MIRROR participation của bạn trên V2 RewardManager contract via flare-explorer.flare.network. Tìm RewardClaimed events với claimType=3 referencing nodeID của bạn. Nếu không có gần đây, bạn sẽ hiển thị là MIRROR-inactive.
Cắm inputs của bạn vào các công thức trên. Code block của mỗi dimension cho bạn biết chính xác phép tính nào để chạy. Sum các dimensions, clamp đến 100, và bạn có điểm số cron-computed raw của bạn.
So sánh với điểm số hiển thị của bạn. Điểm số hiển thị bao gồm exponential moving average của v3.5 trên 4 snapshot cron cuối cùng (current weighted 0.5, prev 0.3, vv.) — vì vậy điểm số tính toán của một single run sẽ hơi khác với cái hiển thị. Panel score-breakdown trên mỗi hàng validator hiển thị các dimension values đã được persist đã đóng góp.
Nếu toán học không cộng hết, email [email protected] với nodeID của bạn, các inputs bạn sử dụng, và điểm số 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.

Programmatic access: cho bất kỳ validator nào đang hoạt động, hit GET /api/validators/{nodeID}/score-breakdown để retrieve persisted breakdown — mọi dimension's value, algorithm version đã tạo ra nó, và recent score history — dưới dạng JSON. Panel score-breakdown trong UI đọc từ cùng một nguồn.

Các mối quan tâm phổ biến của operator

Tôi ở 100% RPC uptime — tại sao Uptime score của tôi lại dưới 20/20?

Thứ nguyên Uptime nhân đầu ra đường cong RPC với tỷ lệ epoch-eligibility của bạn (epochsIncluded / epochsObserved trong 8 epoch phần thưởng gần đây nhất — bộ minimums FIP-10 đầy đủ kể từ v4.2, không chỉ riêng RPC-uptime). Nếu bạn không đáp ứng các điều kiện minimums FIP-10 trong bất kỳ epoch nào — ngay cả chỉ trong thời gian ngắn — tỷ lệ reliability của bạn giảm dưới 1,0 và điểm Uptime của bạn tỷ lệ thuận. Trước v3.4 thứ nguyên này ghi 20 cho mỗi validator có 100% RPC uptime bất kể eligibility lịch sử. Bây giờ nó phân biệt.

Tôi deliver MIRROR — tại sao FlareWatch lại hiển thị tôi là MIRROR-inactive?

Kể từ v3.6, MIRROR participation được phát hiện từ HAI canonical sources: on-chain RewardClaimed(claimType=3) events trên V2 RewardManager, VÀ claimType=3 allocations trong official FSP Merkle JSON (published reward distribution data). Một nodeID hiển thị trong bất kỳ nguồn nào đều tính là active. Pre-v3.6 chúng tôi sử dụng on-chain stream làm sole signal, tạo ra false negatives cho self-delegating providers có MIRROR settle thông qua non-standard claim path. Cũng fixed trong v3.6: một key-format bug nơi ~95 validators có mirror-stats entries của họ được viết dưới hex20 (bytes20 form của nodeID) bởi on-chain indexer khi họ chưa trong curated name list — trong khi mỗi UI lookup keyed bằng cb58 NodeID. Những entries đó tồn tại và đúng; chúng chỉ không visible cho display layer. Lookup hiện normalizes cả hai formats trên mọi consumer (validators table, score-breakdown panel, public mirror-stats API, Yield page Staking Positions card, FTSO providers panel). Nếu nodeID của bạn vẫn hiển thị inactive sau v3.6 sweep, các nguyên nhân có thể: (a) nodeID của bạn không thực sự enrolled trong FSP signing policy của bạn cho epoch đó, (b) chúng tôi ở giữa epoch publications (Merkle data updates per epoch, ~3.5 days). Email chúng tôi với nodeID của bạn và chúng tôi sẽ cross-check cả hai canonical sources.

Điểm số của tôi giảm 10 điểm qua đêm — có gì thay đổi?

Một trong ba điều: (1) v3.5 sudden-change detection flagged fee jump, self-bond drop, hoặc uptime crash trên nodeID của bạn — 10-pt penalty áp dụng run chúng tôi detect nó và decay trong 3 runs tiếp theo khi state mới ổn định; (2) smoothing window incorporate một older snapshot mà pulled average của bạn xuống; (3) chúng tôi shipped algorithm version bump (visible trong record's algorithmVersion field của bạn — xem Versions card dưới đây). Panel score-breakdown hiển thị dimension values hiện tại; so sánh với prior runs của bạn.

Tại sao high-fee validator lại score thấp hơn low-fee với tất cả mọi thứ tương tự?

Thứ nguyên Net Yield (tối đa 18 điểm) nhạy cảm với phí — một validator với phí 0% cung cấp ~1,25× APY trung vị của mạng, ghi điểm gần tối đa; một validator với phí 20% cung cấp ~80% trung vị, ghi điểm thấp hơn. Cộng thêm Fee Reasonableness (7 điểm) là tuyến tính từng phần kể từ v3.9 (không có các nhóm): ≤5% nhận đầy đủ 7 điểm, sau đó đường cong giảm xuống với các độ dốc ngày càng dốc — 10% → 6, 15% → 4,5, 20% → 2,5, 25%+ → 0 (vì vậy ví dụ phí 16% ghi điểm ~4,1, không phải giá trị nhóm phẳng). Vì vậy, sự khác biệt phí 5 điểm tương đương ~5-8 điểm chênh lệch điểm số. Điều này là cố ý — những người ủy thác quan tâm trực tiếp đến phí.

Tôi là validator hoàn toàn mới với không có FTSO score. Tại sao Operator Quality của tôi chỉ là 7/12?

Operator Quality (12 pts max) thưởng cho full-stack operators — validators chạy top FTSO data-provider stack (FTSO + FDC + signing). Nếu bạn là staking-only, +7 baseline là reachable hai cách: (1) manual inclusion trong KNOWN_VALIDATORS list — institutional fast-track cho trusted infrastructure operators (Ankr, InfStones, Kiln, vv.); (2) v3.10 auto-promotion dựa trên objective behavior — 90+ days observed VÀ 25+ operator-aggregated delegators VÀ retention không declining VÀ FIP-10-compliant self-bond. Auto-promotion hoàn toàn tự động, không cần email. Nếu bạn chưa đáp ứng auto-criteria, bạn bắt đầu ở +3 (auto-discovered tier, yêu cầu Flaremetrics hoặc FSE entity profile) và phát triển thành +7 khi track record của bạn xây dựng. Để tăng tốc: register làm FTSO data provider và chạy V2 protocols — điểm số của bạn sau đó đến từ FTSO-derived branch với max 12 ở FTSO 100. v3.8: FTSO participation chỉ có thể giúp, không bao giờ gây hại — nếu FTSO score của bạn dưới verification baseline, bạn giữ baseline.

Tôi có logo nhưng tên của tôi hiển thị là truncated NodeID. Tại sao?

Entity operator của bạn tồn tại trong Flaremetrics (đó là lý do chúng tôi có logo cho bạn) nhưng profile provider của bạn không có 'name' field được set. Chúng tôi không fabricate names. Set profile.name của bạn trên Flaremetrics hoặc trong Flare Systems Explorer entity registry, và chúng tôi sẽ pick it up trên next cron run. Ngoài ra, email chúng tôi một verifiable claim (ví dụ, signed message từ delegation address của bạn) và chúng tôi sẽ add bạn vào KNOWN_VALIDATORS bằng tay.

Validator của tôi ở FIP-10 max delegations. Tại sao Capacity score không phải là 7/7?

Capacity là tent function peaking ở 70% utilization (7 pts), ramping down thành 5.25 pts ở 100%. Peak không phải 100% — being at-cap có nghĩa delegators không thể thêm stake nữa ngay cả khi họ muốn, đó là neutral-to-mildly-negative signal cho new delegators đọc bảng. Pre-v3 chúng tôi scored capped validators 0/5 (penalty cho success); v3 corrected này thành neutral at-cap value, và v3.7 rescaled toàn bộ dimension từ 8 → 7 max (freeing point cho Trust trajectory signals), nên hôm nay capped scores 5.25/7. Right-sized validators (proven attractive VÀ với room để grow, peak ở 70% utilized) nhận full 7.

Tôi là real operator nhưng tôi không ở trong validator list gần như lúc nào cả. Chuyện gì vậy?

Danh sách validator được xây dựng từ live P-Chain RPC's getCurrentValidators result. Nếu bạn không ở đó, bạn hoặc không hiện đang active trên P-Chain, stake của bạn vừa hết hạn, hoặc có P-Chain RPC issue ở phía chúng tôi. Cron chạy mỗi 5 phút — bạn sẽ xuất hiện trong 1-2 cycles của việc activate stake. Nếu bạn đã live trong một giờ và vẫn không thấy mình, email chúng tôi nodeID của bạn.

Tôi có thể appeal điểm số của tôi hoặc request manual review không?

Có. Email [email protected] với nodeID của bạn và một mối quan tâm cụ thể. Chúng tôi phản hồi mọi operator. Những điều chúng tôi sẽ hành động: KNOWN_VALIDATORS additions, MIRROR-classification corrections, logo/name fixes, dimension-specific math errors. Những điều chúng tôi sẽ không hành động: requests để manually raise score ngoài algorithm, requests để exclude hoặc de-rank competitor.

Những gì chúng tôi sẽ và sẽ không làm

Để loại bỏ ambiguity về cách chúng tôi vận hành điểm số, đây là các commitments rõ ràng. Nếu chúng tôi bao giờ vi phạm một trong những điều này, document nó và email [email protected] — chúng tôi sẽ publicly correct nó.

✓

Chúng tôi sẽ không chấp nhận payment cho higher scores, sponsored placement, hoặc favorable treatment bất kỳ loại nào. Điểm số được tính toán deterministically từ public chain data.

✓

Chúng tôi sẽ không hand-code per-validator bumps. Không có "X nhận +5 vì chúng tôi thích họ" line ở bất kỳ đâu trong code. Cùng một algorithm áp dụng cho mỗi validator bao gồm node riêng của FlareWatch, được scored bằng hàm chính xác này.

✓

Chúng tôi sẽ không loại trừ các validator khỏi bảng vì các lý do không công khai. Danh sách được lấy từ P-Chain RPC trực tiếp và hiển thị của chúng tôi bao gồm mọi validator đang hoạt động. Các bổ sung được curation vào KNOWN_VALIDATORS chỉ điền tên hiển thị — chúng không giới hạn khả năng hiển thị.

✓

Chúng tôi sẽ công bố các thay đổi thuật toán. Mọi bản cập nhật phiên bản (v3 → v3.1 → v3.2 → ...) được ghi chép trong thẻ Versions trên trang này với lý do và những gì đã thay đổi. Các thay đổi lớn nhận được một mục changelog bổ sung hiển thị từ trang changelog của ứng dụng.

✓

Chúng tôi sẽ phản hồi các email từ operator. Mọi operator gửi email tới [email protected] với một quan ngại substantive về điểm số của họ sẽ nhận được phản hồi thực sự trong vài ngày làm việc.

✓

Chúng tôi sẽ công khai sửa 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 trong phương pháp, chúng tôi sẽ phát hành bản sửa và ghi chép nó. Chúng tôi không im lặng xếp hạng lại.

✗

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 operator cho bất cứ điều gì khác ngoài cuộc trò chuyện điểm số mà chúng tạo ra.

✗

Chúng tôi sẽ không chia sẻ các kế hoạch tương lai của chúng tôi cho một thay đổi thuật toán với một số operator nhất định trước — mọi phiên bản đều có hiệu lực cho mọi người cùng một lúc.

Hạn chế — điểm số này là gì, và nó không phải là gì

Một điểm số tổng hợp là một bản tóm tắt hữu ích, không phải là sự thật khách quan. Điểm số của chúng tôi là minh bạch, có phiên bản, được áp dụng giống hệt cho mọi validator — bao gồm cả validator của chúng tôi — và có thể được tái tính toán từ các đầu vào đã công bố ngay trong trình duyệt của bạn. Nhưng nó vẫn mã hóa những phán xét biên tập, và chúng tôi muốn chỉ cho bạn chính xác nó ở đâu hơn là ngụ ý một độ chính xác mà phương pháp không có.

Trọng số của các chiều là phán xét của chúng tôi. Uptime có giá trị 20 điểm và phí có giá trị 7 điểm vì chúng tôi quyết định rằng độ tin cậy quan trọng hơn đối với hầu hết những người ủy quyền so với một vài điểm phí — không phải vì một công thức chứng minh điều đó. Những người hợp lý sẽ cân nhắc những điều này khác nhau. Trọng số là cố định và công khai, vì vậy bạn có thể thấy chính xác những gì chúng tôi chọn và có thể tái cân nhắc chúng từ phân tích chi tiết.

Net Yield là một kết quả, không phải là một đức hạnh. Nó đo lường những gì một người ủy quyền thực sự kiếm được, được neo ở trung vị mạng — vì vậy nó được định hình một phần bởi những thứ ngoài tầm kiểm soát của một nhà điều hành (lạm phát mạng, lượng ủy quyền họ đã thu hút) và nó thay đổi khi phần còn lại của lĩnh vực thay đổi. Một nhà điều hành kỷ luật tính phí công bằng nhưng cao hơn có thể ghi điểm thấp hơn ở đây trong khi vẫn xuất sắc. Hãy đọc nó như "tôi sẽ kiếm được bao nhiêu," không phải "nhà điều hành này tốt như thế nào."

Các chiều liên quan đến FTSO ưu tiên các nhà điều hành toàn diện. MIRROR Participation và một phần của Operator Quality thưởng cho các validator cũng chạy một bộ nhà cung cấp dữ liệu FTSO hàng đầu. Điều đó là cố ý — với tư cách là một người ủy quyền, bạn thực sự kiếm được nhiều hơn, thông qua MIRROR, từ một validator hoạt động FTSO — nhưng điều đó có nghĩa là một validator chỉ staking thuần túy và xuất sắc không thể đạt được vị trí hàng đầu trên bảng này. Nếu bạn chỉ staking theo lựa chọn, hãy giảm trọng số của những chiều đó cho chính bạn.

Mô hình là tính cộng. Các chiều cộng lại, vì vậy một điểm mạnh có thể bù đắp một điểm yếu — uptime xuất sắc có thể mang theo một phí cao hơn để đạt được điểm số tôn trọng. Những lỗi thực sự không đủ điều kiện (không đáp ứng các mức tối thiểu FIP-10, phí tàn nhẫn) được gated riêng biệt để chúng không thể bị che phủ hoàn toàn — một validator không đáp ứng các mức tối thiểu mỗi epoch hoặc tính phí 100% hạ cánh gần phía dưới cùng bất kể các chiều khác của nó — nhưng cơ bản là một tổng có trọng số, không phải là một hệ thống veto.

Một số ẩn chín phán xét. Con số 0-100 duy nhất là một điểm bắt đầu, không phải là một phán quyết. Hai validator cách nhau một điểm không có khác biệt có ý nghĩa. Hãy mở phân tích chi tiết và cân nhắc các chiều quan trọng với bạn — con số tồn tại để làm cho việc so sánh đó nhanh hơn, không phải để thay thế nó.

Chúng tôi thay đổi phương pháp hiếm khi, và công khai. Mỗi thay đổi được gửi với một phiên bản bump, một lý do được viết rõ ràng, và một trước-và-sau trên toàn lĩnh vực, vì vậy bạn có thể kiểm toán những gì đã di chuyển và tại sao. Khi kiểm toán tự động của chúng tôi phát hiện ra một sự khác biệt trong các số của chúng tôi — như nó thường xuyên làm — chúng tôi sửa nó và nói như vậy.

Điểm cuối cùng (cách các chiều kết hợp)

Tất cả 9 chiều cộng trực tiếp, sau đó trừ đi lệnh phạt streak outage hoạt động v4.3. Tổng cộng tối đa là 100 và tối thiểu là 0. Làm mịn trên các snapshot cron gần đây (v3.5) và bất kỳ lệnh phạt thay đổi đột ngột nào sau đó được áp dụng cho số cuối cùng.

// 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)

Nguồn dữ liệu (mọi input đều công khai)

Flare P-Chain RPC: danh sách validator, uptime, self-bond, delegated stake, fee, end time, delegator count.

V2 RewardManager (claimType=3 events): MIRROR distribution yêu cầu on-chain cho mỗi validator nodeID. Được lọc chặt chẽ theo loại 3 — không có nhập nhằng với VRM, FTSO delegation, hoặc DIRECT rewards.

FSP Merkle JSON (claimType=3 allocations): bản ghi được công bố chính thức về ai được nợ MIRROR mỗi epoch (dữ liệu tương tự mà công cụ ký của chính Flare đọc). Được thêm vào v3.6 như một nguồn có thẩm quyền thứ hai — bắt các validator có MIRROR được phân bổ nhưng chưa được yêu cầu on-chain.

Flare Systems Explorer (FSE): bộ đăng ký thực thể validator, tên hiển thị, logo, các cờ tham gia giao thức FTSO V2.

Dữ liệu provider Flaremetrics: FTSO score, reward rate, accuracy, V2 features, entity-to-nodeID linkage.

Flare reward-scripts (GitHub): APY được gửi cho mỗi validator cho N epoch phần thưởng gần đây nhất. Điều khiển chiều Delivery.

Curation FlareWatch: bản đồ KNOWN_VALIDATORS (~110 entries). Tên + Operator Quality baseline cho các operator cơ sở hạ tầng đáng tin cậy.

Những gì KHÔNG có trong điểm số

• Tự quảng bá hoặc vị trí trả phí. Không operator nào có thể trả tiền hoặc tài trợ cho điểm số cao hơn.

• Tăng giá trị hand-coded dành riêng cho validator. Không có dòng "X nhận +5 vì chúng tôi thích họ" ở đâu trong code. Cùng một thuật toán được áp dụng cho mỗi validator bao gồm node của chính FlareWatch, được chấm điểm 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á uptime SLA, phân phối địa lý hoặc thông số kỹ thuật phần cứng. Nếu bạn muốn tuyên bố cấp cơ sở hạ tầng, hãy chạy FTSO + FDC stack hàng đầu và chiều Operator Quality sẽ phản ánh nó.

• Khóa hoặc cam kết với FlareWatch. Không có điểm cao hơn cho các staker sử dụng FlareWatch so với công cụ khác.

Phản hồi từ operator

Thấy điều gì không ổn trong điểm số validator của bạn? Gửi email tới [email protected] với NodeID và quan ngại của bạn. Chúng tôi phản hồi cho mọi operator. Các yêu cầu phổ biến mà chúng tôi sẽ hành động:

Thêm operator của bạn vào KNOWN_VALIDATORS (với xác minh).
Xem xét lại phân loại MIRROR-inactive của bạn nếu bạn tin rằng nó có lỗi.
Sửa chữa logo / tên hiển thị.
Phê bình thuật toán chung.

Nguồn & tài liệu tham khảo

Mọi input cho điểm số đều đến từ các nguồn Flare-ecosystem công khai, có thể xác minh được. Bất cứ ai cũng có thể kiểm tra chéo các yêu cầu của chúng tôi so 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 ra sự không일致 giữa trang này và những gì các nguồn phía trên 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 Flare Network ↗https://docs.flare.network

Tài liệu giao thức có thẩm quyền. Bao gồm FTSO V2, FSP, P-Chain validation, FAssets, và phần còn lại của stack Flare.

Portal quản trị Flare (FIPs) ↗https://proposals.flare.network

Flare Improvement Proposals — nguồn sự thật cho FIP-05 (delegation factor), FIP-10 (điều kiện tối thiểu validator: 1M FLR self-bond floor, 80% uptime floor, 14-day minimum lock), và tất cả các quy tắc khác được trích dẫn trên trang này.

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

Bộ đăng ký chính thức do Flare vận hành của dữ liệu provider FTSO, địa chỉ thực thể, P-Chain nodeID linkages, và các cờ điều kiện tối thiểu FIP-10. Nguồn chính cho dữ liệu Operator Quality và độ tin cậy của chúng tôi.

Flaremetrics ↗https://flaremetrics.io

Provider metrics Flare-ecosystem độc lập. Nguồn của FTSO provider scoring, reward rates, accuracy metrics, V2 protocol participation flags, và mappings địa chỉ validator-to-entity. Chúng tôi tiêu thụ public REST API của họ.

Flare Foundation reward-scripts repo ↗https://github.com/flare-foundation/reward-scripts

JSON được công bố cho mỗi reward-epoch bởi Flare Foundation cho thấy mỗi validator eligibility, uptime-eligibility, và delivered rewards. Điều khiển chiều Delivery Reliability và tỷ lệ epoch-eligibility v3.4 cho Uptime.

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

Trình duyệt chỉ đọc tất cả trạng thái on-chain. Cho phép bất kỳ ai xác minh các sự kiện RewardClaimed của V2 RewardManager (claimType=3 cho MIRROR), tổng số stake của validator, thay đổi phí và những thứ khác.

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

Giao diện staking chính thức. Nguồn thẩm quyền cho các khoản self-bond / delegated stake hiện tại và thời gian kết thúc validator được đọc từ P-Chain RPC mà chúng tôi sử dụng.

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 tiêu thụ, trả về hồ sơ thực thể, điểm số FTSO, phí và nodeId ở định dạng hex. 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 bảng tra cứu entity-to-NodeID điều khiển mọi consumer ở định dạng cb58.

Không có dữ liệu riêng tư, không có mô hình nguồn đóng. Thuật toán tính điểm được triển khai trong services/validators/scoring.ts trong codebase FlareWatch. Các nhà khai thác hoặc nhà nghiên cứu muốn kiểm tra việc triển khai trực tiếp (thay vì đọc phần mô tả + công thức ở trên) — hoặc những người muốn fork nó để sử dụng riêng — có thể gửi email tới [email protected] để yêu cầu truy cập. Chúng tôi sẽ công bố tệp dưới dạng gói open-source độc lập nếu có nhu cầu thực sự.

Cách điểm số được cập nhật

Cron tại /api/cron/refresh-validators tính toán lại điểm số của mọi validator hoạt động mỗi 5 phút. Các đầu vào (P-Chain RPC reads, Flaremetrics, FSE, reward-scripts) được lấy lại mới trên mỗi lần chạy.

v3.5 đã thêm smoothing trên 4 snapshot cron gần đây (trọng số: 0.5 / 0.3 / 0.15 / 0.05), vì vậy điểm số được hiển thị không biến động do nhiễu đầu vào tạm thời. Điểm số được tính toán bởi cron thô vẫn được lưu trữ để tính toán smoothing trong tương lai, và bảng phân tích điểm số hiển thị giá trị hiện tại của mỗi thứ nguyên để bạn có thể thấy điều gì đã thay đổi.

Phiên bản thuật toán được đóng dấu trên mỗi bản ghi điểm được lưu trong bộ nhớ cache. Khi chúng tôi phát hành phiên bản mới, mỗi điểm sẽ nhận được thẻ mới. Thẻ Phiên bản bên dưới ghi lại mỗi thay đổi.

Mô hình penalty của Flare

Flare không slash stake của validator. Toàn bộ cơ chế penalty cho hành vi sai trái của validator là forfeiture reward cộng với hệ thống các pass FIP-10. Không có double-signing slash, không có equivocation slash, không có sự kiện phá hủy stake mà chúng tôi cần theo dõi. Các validator không đáp ứng các điều kiện tối thiểu FIP-10 sẽ mất reward của epoch đó (forfeiture đầy đủ nếu không có pass, nếu không thì mất một pass trên mỗi giao thức mà họ không thỏa mãn); số stake chính của họ vẫn không được thay đổi.

Điều đó có nghĩa là điểm số không có thứ nguyên "lịch sử slashing" — không có lịch sử như vậy để theo dõi. Những gì chúng TÔI THEO DÕI là hệ quả của mỗi lỗi tối thiểu: validator kiếm được không có gì trong epoch đó, được nắm bắt trong epochsIncluded / epochsObserved. Bản cập nhật v4.2 vào ngày 2026-05-14 đã mở rộng bộ nhân độ tin cậy của điểm số để sử dụng tỷ lệ đó trên toàn bộ bộ tối thiểu FIP-10 (uptime, FSP signing, FTSO submission rate, FDC participation) để validator không thỏa mãn bất kỳ tối thiểu nào bị phạt tương ứng trong thứ nguyên Uptime bất kể trục nào bị hỏng.

Ngưỡng tối thiểu FIP-10, lấy từ dev.flare.network/network/fsp/rewarding: staking yêu cầu 80% uptime + 1M FLR active self-bond; FTSO anchor feeds yêu cầu ước tính trong 0.5% của trung bình đồng thuận trong 80% vòng; FTSO block-latency feeds yêu cầu submit 80% cập nhật dự kiến; FDC yêu cầu tham gia 60% vòng bỏ phiếu. Các validator đáp ứng sàn 80% uptime + 1M self-bond nhưng dưới ngưỡng kiếm 3M / 15M vẫn nhận reward nhưng không thể tích lũy pass — vùng xám được hiển thị qua phân loại passEligibility: "at-risk" của thẻ này.

Các phiên bản

v4.8 (2026-09-17) — Các epoch phần thưởng được tính năng suất hàng năm theo chiều dài thực tế của chúng. Mọi tỷ lệ validator đo được (APR được giao, ủy quyền, MIRROR, lợi suất tự ràng buộc của nhà điều hành) đều được tính năng suất hàng năm với epoch phần thưởng 3,19 ngày, giá trị được thêm vào 2026-04-04 và được mô tả là được đo từ các dấu thời gian khối mặc dù không có gì đo được nó. Các epoch phần thưởng Flare chính xác là 3,5 ngày — FlareSystemsManager's rewardEpochDurationSeconds trả về 302.400 và mọi khởi đầu epoch on-chain cách nhau 3,500 ngày — vì vậy mỗi tỷ lệ đo được đọc cao hơn khoảng 9,7% trong năm tháh rưỡi, bao gồm cả của chúng tôi. Độ dài hiện được đọc từ hợp đồng đó. Mọi APR đo được giảm đi cùng một yếu tố, 3,19 ÷ 3,5 (trung bình mạng 9,08% → 8,28%; FlareWatch 8,17% → 7,45%). Điểm số: chỉ Delivery Reliability thay đổi, vì nó so sánh tỷ lệ đo được với tỷ lệ lý thuyết cho phí của validator. Phía lạm phát đã đặt 91% các validator ở mức 1,0, tức là rõ ràng trả nhiều hơn mức có thể; với chiều dài epoch thực tế, tỷ lệ delivered-to-theoretical trung bình là 0,990. Mô phỏng trên 168 validator có dữ liệu đo được trước khi phát hành: trung bình −0,32 điểm, 146 validator mất dưới 1 điểm, 13 validator đã giao dưới tỷ lệ hàm ý phí của họ mất 2–3,5. Fallback tính tuổi Community Trust chuyển đổi epoch thành ngày với cùng chiều dài và cũng được sửa chữa; nó không di chuyển điểm nào, vì nó thấy nhiều nhất 8 epoch (28 ngày), dưới bước 30 ngày của nó theo cách nào đó. Các chứng thực hiệu suất đã ký sử dụng cùng chiều dài sai; thông số tính toán được sửa đổi thành rev.3 và rev.2 được giữ nguyên từ chữ với lỗi được tiết lộ.

v4.7 (2026-08-19) — Two-axis self-bond trong Trust dimension. Trust tính điểm self-bond nhà điều hành chỉ như một TỶ LỆ (own bond ÷ total stake), vì vậy một large self-bond loãng bởi delegation ghi điểm giống hệt như một tiny bond ở tỷ lệ đó — điểm số không nhận thấy vốn thực tế được cam kết. Trên mạng đang hoạt động 61 trong 178 validators giữ ≥10M self-bond ở một <10% ratio, vì vậy một phần ba trường bị ghi điểm thấp hơn. v4.7 tính điểm self-bond theo ĐIỀU TỐT HƠN của proportional share (≥10% → +2, 5–10% → +1, không thay đổi) HOẶC kích thước tuyệt đối (min(1, selfBond ÷ 20M) × 2, bão hòa ở bond P-chain top-decile của mạng), lấy max và vẫn giới hạn tín hiệu phụ ở +2 — giới hạn Trust (11) và giới hạn composite (100) không thay đổi, và sàn hollow sub-FIP-10 (<1M FLR → −1) không thay đổi. Phản chiếu two-axis self-bond mà điểm số nhà cung cấp FTSO đã sử dụng. Toàn trường trước/sau trên tất cả 178 validators, lưu trữ trước khi vận chuyển: 58 di chuyển lên, không ai di chuyển xuống, không có điểm nào tăng hơn một điểm, và đỉnh cao của bảng xếp hạng không thay đổi. Node của chúng tôi tăng một điểm (83 → 84) theo quy tắc tương tự như mọi nhà điều hành được vốn hóa tốt — không có thuật ngữ nào đề cập đến chúng tôi.

v4.6 (2026-08-13) — Khoản thưởng magnitude được mang lại MIRROR. Dimension MIRROR trước đây chỉ ghi điểm passthrough (tỷ lệ phần trăm MIRROR chuyển tới những người ủy quyền, = 1 − fee) và trạng thái tham gia — nó không nhận thức được SỐ TIỀN được mang lại. Một validator trả tỷ lệ MIRROR được mang lại cao hơn nhiều (mirrorAPY, net của phí) so với lĩnh vực kiếm được không ghi nhận cho nó, vì vậy một nút lợi suất cao hơn thực sự có thể xếp hạng dưới một nút lợi suất thấp hơn ở các dimension lợi suất. v4.6 thêm một khoản thưởng nhỏ, giới hạn, được neo bằng trung vị: chỉ dành cho validator mirror-active, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2). Chỉ mang lại trên 1.2× tỷ lệ trung vị mạng mới kiếm được nó, và nó tối đa hóa ở +2, nâng trần dimension MIRROR từ 10 lên 12 (composite vẫn được kẹp ở 100). Nó được neo bằng tỷ lệ MIRROR trung vị mạng, không phải khối lượng, vì vậy nó là trung lập về kích thước theo cấu trúc: trên toàn lĩnh vực hoạt động khoản thưởng tương quan TIÊU CỰC với self-bond (nó ưu tiên các validator nhỏ mang lại tỷ lệ cao, không phải những validator lớn). Một bản so sánh trước/sau toàn bộ lĩnh vực trên tất cả các validator hoạt động đã được lưu trữ trước khi triển khai — hầu hết các validator không di chuyển, và phần trên của bảng xếp hạng không thay đổi. Cùng một công thức được áp dụng cho mỗi validator, bao gồm cả nút của chúng tôi.

v4.5 (2026-07-16) — Hình phạt khả thi phí cực cao. Thứ nguyên Fee Reasonableness bão hòa tại 0/7 khi phí vượt quá neo thị trường + 20 điểm (~40% sau Granite); từ đó cho đến phí 100% composite dừng phản hồi fee hoàn toàn, vì vậy một validator phí 100% — nơi delegators không nhận được gì — vẫn ghi điểm trong những năm 40 trên các thứ nguyên mù phí. Trên điểm số hướng đến delegator, kết quả đó gần như bất hợp tác, không phải giữa bảng. v4.5 thêm một hình phạt composite được áp dụng như một phần của tổng thứ nguyên tích cực: không tại hoặc dưới phí 50% (không tính kép trong phạm vi Fee dimension đã định giá), sau đó tăng tuyến tính lên 75% điểm tại phí 100%. Một node phí 100% đạt khoảng 10/100 — vẫn được liệt kê và xếp hạng, rõ ràng không phải là ứng viên ủy thác. Nó là hàm thuần của phí on-chain, giống hệt với mỗi validator, bao gồm cả node của chúng tôi.

v4.4 (2026-07-11) — Điểm neo phí nhận biết mức sàn Granite. Hard fork Granite (Flare, 2026-07-14) bắt buộc mức phí ủy quyền trình xác thực tối thiểu 20%. Điểm neo Tính Hợp Lý của Phí trở thành max(mức phí hoạt động tối thiểu quan sát được, mức sàn giao thức): mọi phí ở mức tối thiểu hợp pháp hoặc dưới đó sẽ kiếm được điểm tối đa, và chỉ những phí trên nó mới bị phạt, theo khoảng cách. Cơ sở lý thuyết: với đặc quyền của những cổ phần đang diễn ra không được chỉ định thượng nguồn, neo hóa đến một di sản được đặc quyền 2% (hoặc pre-fork 0%) sẽ đã chấm điểm những nhà điều hành tuân thủ giao thức 20% gần như chiết xuất — và tính hai lần delta phí mà Net Yield đã tính giá trị dưới dạng các thuật ngữ được cung cấp. Không có chiều nào khác thay đổi. Khi toàn bộ nhóm đạt đến mức sàn, chiều này trao điểm tối đa thống nhất — phí ngừng đếm khi không ai có thể cạnh tranh nó.

v4.3 (2026-05-14) — Active Outage Penalty được thêm vào làm khoản khấu trừ cố định sau thứ nguyên. Bộ nhân uptimeReliability hiện có là symmetric — 5 miss phân tán trên 24 epoch tốn kém như 5 miss liên tiếp — nhưng về mặt hoạt động chúng rất khác nhau: các miss phân tán có nghĩa là độ không ổn định mãn tính, một chuỗi có nghĩa là validator bị hỏng NGAY BÂY GIỜ. v4.3 đọc lần chạy liên tiếp của các epoch !eligible ở đầu lịch sử tham gia gần đây của validator và khấu trừ 0 pts cho 0–1 consecutive misses (độ biến thiên bình thường / single transient miss), 3 pts ở 2 (developing outage), 6 pts ở 3 (sustained outage), và 10 pts ở 4+ (active extended outage), với composite được làm tòa lại ở 0. Được tính thêm trên — chứ không thay thế — bộ nhân độ tin cậy, vì cả hai nắm bắt những rủi ro khác nhau. Trigger: sự cố lớp Luganodes vào ngày 2026-05-14, nơi nhiều epoch gần đây miss liên tiếp trong khi các delegator đang tích cực cam kết stake; tín hiệu chuỗi cho phép delegator thấy lỗi đang diễn ra trước khi cam kết. Các penalty được hiển thị dưới dạng phần riêng của chúng trong bảng phân tích điểm số để 9 thứ nguyên tích cực vẫn cộng lại thành 100.

v4.2 (2026-05-14) — HAI lỗi liên quan được sửa chữa, phát hành cùng nhau để đáp ứng với sự sửa chữa công khai từ AU (@aucc_official) về điểm số của Luganodes. (1) Tính toán deliveredAPY giờ đây nhân tỷ lệ-trên-mỗi-earning-epoch với `epochsIncluded / epochsObserved` để APR được hiển thị phản ánh tỷ lệ EFFECTIVE mà delegator thực sự nhận được trong cửa sổ quan sát — bao gồm các epoch không kiếm được khi validator không thỏa mãn tối thiểu FIP-10. Việc triển khai trước đó chỉ trung bình các epoch kiếm được và cho thấy các validator tỷ lệ good-epoch của họ, che giấu các lỗi tối thiểu. (2) Bộ nhân độ tin cậy của thứ nguyên Uptime mở rộng từ uptime-only (epochsUptimeEligible / epochsObserved) sang bộ tối thiểu FIP-10 đầy đủ (epochsIncluded / epochsObserved). Validator có 100% RPC uptime nhưng không thỏa mãn FSP signing hoặc FTSO submission rate giờ đây phải chịu mức giảm tương ứng trên thứ nguyên Uptime bất kể tối thiểu nào mà họ bỏ lỡ. Tác động ròng đối với Luganodes cụ thể: deliveredAPY giảm từ 10.86% xuống ~5.43% (phù hợp với thực tế trả tiền một nửa), độ tin cậy uptime giảm từ 1.0 xuống 0.5, điểm số giảm đáng kể. Sự sửa chữa tương tự áp dụng cho mỗi validator với `epochsIncluded < epochsObserved` — trên toàn mạng lưới này bề mặt những khoảng cách về chất lượng tham gia thực sự trước đây được ẩn.

v4.1 (2026-05-14) — Thứ nguyên Net Yield chuyển từ APR lý thuyết (công thức: gross_APR × (1 − fee)) sang deliveredAPY ĐO ĐƯỢC từ các reward-scripts của Flare Foundation, với fallback lý thuyết cho mỗi validator khi không có lịch sử đo lường. Trigger: FIP-16's inflation reduction (5% → 3%) went live 2026-05-14, và mẫu số eligible-stake của công thức lý thuyết dịch chuyển từ thực tế on-chain sao cho APR lý thuyết dưới báo cáo các yield được cung cấp ~2× trên toàn mạng lưới. Chuyển sang measured-first để căn chỉnh lại đầu vào điểm số với những gì staker thực sự nhận được. Anchor networkMedianAPR cũng được tính toán lại bằng cách sử dụng cùng một phương pháp measured-first để so sánh tỷ lệ vẫn nhất quán trên cả hai bên — điểm số phải tương đối ổn định (validator ở mức trung bình mạng lưới vẫn ghi ~12/18, v.v.), chỉ dựa trên tỷ lệ thực tế được cung cấp thay vì kết quả công thức.

v4.0 (2026-05-11) — Phiên bản lớn. Chu kỳ v3.7-v3.10 cumulatively tạo thành một viết lại cấu trúc của hệ thống tính điểm, đủ lớn để đáng giá bước nhảy. Tóm tắt: hai thứ nguyên đã thay đổi các nắp của chúng (Trust 10→11, Capacity 8→7); công thức Operator Quality được viết lại thành max(verification, FTSO-derived) để tham gia không thể làm hại; bốn thứ nguyên bucketed còn lại (Uptime, Fee, Delivery, Time Remaining) được tuyến tính hóa để loại bỏ các cliff biên; ba thành phần điểm số mới được thêm vào (30-day delegation retention, 30-day self-bond trajectory, auto-promotion to curated tier); aggregation của multi-node operator được giới thiệu cho Trust count + concentration; longevity hiện nay là wipe-immune via reward-scripts epoch presence; và hai incentive perverse bị loại bỏ (FTSO-participation penalty của Operator Quality và Uptime 95% inverted-V cliff). Mỗi đầu vào cho điểm số hiện nay là ngoài xác minh được — không có quyết định biên tập nào là load-bearing. Các validator có thể kiếm được +7 curated-operator baseline thông qua hành vi có thể quan sát được (90+ days observed, 25+ delegators, retention not declining, FIP-10-compliant self-bond), không cần email-the-team bắt buộc. Xem các mục v3.7-v3.10 bên dưới để biết những thay đổi chi tiết tạo thành bản phát hành này.

v3.10 (2026-05-11) — Đóng khoảng cách quản lý cuối cùng trong điểm số. +7 curated-operator baseline trên Operator Quality trước đây yêu cầu tự-inclusion trong danh sách KNOWN_VALIDATORS của chúng tôi, đó là quyết định biên tập có ý nghĩa duy nhất còn lại sau chu kỳ kiểm toán v3.7-v3.9. v3.10 thêm một đường dẫn auto-promotion mục tiêu: bất kỳ validator nào có 90+ ngày quan sát FlareWatch, 25+ delegator được tổng hợp bởi nhà khai thác, retention không giảm (drop 30 ngày ≤ 15%), và self-bond tuân thủ FIP-10 tự động đủ điều kiện cho +7 baseline — không cần xem xét thủ công. KNOWN_VALIDATORS vẫn là fast-track cho các nhà khai thác tổ chức chưa tích lũy cửa sổ 90 ngày (hãy nghĩ về một entry Ankr hoặc Kiln launch-day), nhưng trường hợp điển hình hiện nay hoàn toàn tự động hóa. Cả bốn tiêu chí đều được lấy từ on-chain hoặc gần on-chain (delegator count, retention, self-bond) cộng với dấu thời gian quan sát của chúng tôi — không có gì chủ quan, không có gating email-the-team. Tác động ròng: validator có thể kiếm được +7 tier thông qua hành vi một mình. Hầu hết các nhà khai thác lâu đời trên mạng lưới đã đáp ứng các tiêu chí ngày hôm nay.

v3.9 (2026-05-11) — Boundary-cliff cleanup trên bốn thứ nguyên bucketed còn lại, sau khi kiểm toán mỗi phần của điểm số để công bằng. Đã sửa: (1) một cliff inverted-V perverse trong đường cong Uptime ở 95% — đi từ 94.99% → 95.00% uptime mất 4 điểm (nhánh 95-99% bắt đầu ở 0 thay vì khớp max 4 của nhánh thấp hơn). Cùng hình dạng incentive ngược lại mà chúng tôi vừa sửa chữa trong Operator Quality (v3.8). (2) Ngưỡng Fee Reasonableness tuyến tính hóa — trước v3.9, tăng phí 0.01% trên giới hạn bucket có thể mất tới 2.5 điểm. Hiện nay piecewise linear với các độ dốc ngày càng dốc hơn để bảo tồn giá trị bucket ở các ranh giới (phí thấp hầu như không bị phạt, phí trích xuất bị phạt nặng). (3) Ngưỡng deliveryRatio Delivery Reliability tuyến tính hóa — cùng mẫu, cliff lên tới 2 điểm bị loại bỏ. (4) Ngưỡng Time Remaining bucket tuyến tính hóa — cliff nhỏ hơn (max 2 điểm ở ranh giới 14 ngày) nhưng vẫn hiện diện trong thứ nguyên nhỏ; hiện nay mịn. Net Yield, MIRROR Participation, và Capacity Profile được kiểm toán và xác nhận công bằng-như-là (đã linear/continuous). Tổng cap không thay đổi ở 100. Không có reversion điểm số theo thiết kế; validators duy nhất có điểm số di chuyển là những validators tình cờ ngồi chính xác trên ranh giới bucket trước đó.

v3.8 (2026-05-11) — Thứ nguyên Operator Quality được kiểm toán và viết lại sau khi xem xét công bằng. Ba lỗi được phát hành cùng nhau. (1) Loại bỏ incentive perverse — một nhà khai thác được biết đến với điểm số FTSO mid-tier (ví dụ: 50) ghi được 4 pts, nhưng cùng một nhà khai thác rơi ra khỏi FTSO hoàn toàn ghi được 7 pts. Theo v3.8 điểm số là max(verification baseline, FTSO-derived), vì vậy tham gia FTSO chỉ có thể giúp đỡ, không bao giờ làm hại. (2) Giới thiệu tầng xác minh trung gian — nhà khai thác với tên được tự động khám phá từ Flaremetrics hoặc FSE (nhưng chưa ở trong bản đồ KNOWN_VALIDATORS đã được sắp xếp) nhận được +3 thay vì 0, làm mềm cliff 7→0 trước đó. (3) Bề mặt cả hai tín hiệu trong chi tiết phân tích khi xác minh thắng dựa trên điểm số FTSO thấp (ví dụ:

v3.7 (2026-05-11) — Thứ nguyên Community Trust được kiểm toán và mở rộng sau khi xem xét công bằng với nhà khai thác. Ba bổ sung: (1) Multi-node operator aggregation — các nhà khai thác chạy nhiều nút P-Chain (AU, FlareBus, Aureus Ox, Kiln, v.v.) hiện nay có delegator count và tổng stake được tổng hợp cho Trust count + concentration signals, vì vậy họ không bị phạt vì phân phối cùng một cơ sở delegator trên nhiều nút. (2) Tín hiệu retention delegation 30 ngày (±0.5 pt) — phân biệt giữa các validator đang phát triển / ổn định / teo tóp bằng cách so sánh cửa sổ trượt. Thứ nguyên Trust snapshot-only không thể phân biệt những cái này trước v3.7. (3) Quỹ đạo self-bond 30 ngày (±0.5 pt) — thưởng cho các nhà khai thác tăng self-bond của họ theo thời gian, phạt những người yên tĩnh un-bonding. Khác biệt với penalty thay đổi đột ngột chỉ nắm bắt các drop lớn riêng lẻ. Cap được cân bằng lại: Trust 10 → 11, Capacity 8 → 7. Sửa lỗi từ kiểm toán: (a) zero self-bond hiện nay đúng đắn hits sub-FIP-10 penalty (trước đây một `selfBondFLR > 0` gate cho phép exactly-0 self-bond thoát khỏi −1). (b) tỷ lệ self-bond nhỏ giữa sàn FIP-10 và 5% hiện nay kết xuất tỷ lệ phần trăm thực tế trong bảng phân tích để các nhà khai thác thấy điều gì đóng khoảng cách tới +1 / +2 tiers. (c) longevity bonus hiện nay wipe-immune — falls back đến reward-scripts epoch presence khi first-observed KV là artificially fresh.

v3.6 (2026-05-11) — Hai lỗi để MIRROR detection, được phát hành cùng nhau. (a) Phát hiện hiện nay đọc từ hai nguồn chính: on-chain RewardClaimed(claimType=3) events từ V2 RewardManager AND claimType=3 allocations trong FSP Merkle JSON chính thức (cùng dữ liệu mà công cụ signing của Flare tiêu thụ). Tín hiệu riêng lẻ là đủ — catches validators có MIRROR được cấp phát nhưng chưa được yêu cầu on-chain. (b) Cross-checking chống lại Merkle tiết lộ một lỗi định dạng key riêng: validators:mirror-stats có các key NodeID hex20/cb58 trộn lẫn (on-chain indexer viết hex khi validator chưa ở trong danh sách tên đã sắp xếp của chúng tôi), trong khi mỗi consumer giao diện người dùng chỉ tìm kiếm bằng cb58 — vì vậy ~95 validators' status bị vô hình đối với bản hiển thị. Tra cứu hiện nay normalize cả định dạng trên bảng validators, bảng phân tích điểm số, mirror-stats public API, Yield page Staking Positions card, và FTSO providers panel. Các validator bị ảnh hưởng thấy MIRROR Participation + Operator Quality dimensions và overall FlareWatch Score tăng 9-10 điểm trên chu kỳ cron tiếp theo. Được khám phá qua một báo cáo FTSO-provider (FlareBus, 2026-05-11) — tín dụng và cảm ơn. Phản hồi của họ đã cải thiện đáng kể cách nhìn của mỗi delegator về mạng lưới, không chỉ điểm số của họ.

v3.5 (2026-05-09) — Net Yield hiện nay median-anchored chống lại network APR (validator ở mức trung bình ghi được 12/18, top performers đạt 18, bottom-quartile drops đến 0). Trust dimension hấp thụ self-bond alignment như một thành phần thứ tư (proportional self-bond rewards skin-in-the-game; sub-FIP-10 floor takes a small penalty). Badge "NEW Xd" mới bề mặt validators FlareWatch chỉ quan sát được <30 ngày để staker có thể thấy khi track record là mỏng.

v3.4 (2026-05-09) — Thứ nguyên Uptime hiện nay trộn lẫn RPC uptime tức thời với tỷ lệ FIP-10 epoch-eligibility lịch sử. Pre-v3.4 thứ nguyên là non-discriminating (92.9% của các validator có 100% RPC uptime). Tỷ lệ độ tin cậy được lấy từ epochsUptimeEligible / epochsObserved trên 8 epochs reward-scripts cuối cùng — tín hiệu time-series có ý nghĩa phân biệt các validator thỉnh thoảng không thỏa mãn điều kiện tối thiểu FIP-10 từ những validator không.

v3.3 (2026-05-09) — Delivery dimension hiện nay sử dụng exponentially time-weighted mean rate (recent epochs count more, decay constant 0.85) và áp dụng variance penalty (coefficient of variation × 0.5, capped tại −30%). Tính toán từ per-epoch reward-scripts data — kích thước mẫu được mang theo như dampener độ tin cậy hiện có.

v3.2 (2026-05-09) — Multi-signal Community Trust (count + concentration + longevity); first-observed-by-FlareWatch tracking persisted trong KV để longevity bonus; stake-end edge-case (validators trong 14 ngày chấm dứt score 0 trên Time Remaining vì họ không thể chấp nhận delegations mới theo FIP-10); trang phương pháp made public; operator feedback channel surfaced; algorithm version stamped trên mỗi bản ghi điểm được lưu trong bộ nhớ cache.

v3.1 (2026-05-09) — Wired Delivery dimension từ reward-scripts data; smoothed Operator Quality (linear interpolation), Capacity (tent function), và Trust (log scale); reclassified FSP-known + zero claimType=3 như MIRROR "inactive" thay vì "no data"; persisted scoreBreakdown server-side vì vậy client không tính toán lại mà không cần đầu vào đầy đủ.

v3 (2026-05-09) — Thay thế binary identity bonus bằng continuous Operator Quality. Thêm MIRROR Participation như một thứ nguyên chuyên dụng với fee passthrough. Đã làm capped capacity trung lập thay vì penalty 0-pt. Xóa APY/fee double-count qua Net Yield. Tính toán lại các bands (Top tier 90+, Strong/Good/Acceptable/Below median).

v2 (pre-2026-05-09) — Điểm số 8 chiều ban đầu (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). Bị loại vì APY/Fee double-count, binary identity penalty, capped-capacity penalty, không MIRROR dimension. Được ghi lại để tham khảo lịch sử.