Metodologi Skor Validator

Versi algoritma: v4.8 · Terakhir diperbarui: 2026-08-19

FlareWatch memberikan setiap validator P-Chain skor komposit 0–100 di seluruh 9 dimensi. Matematinya deterministik, inputnya adalah data chain publik [Flare Explorer] [FSE] [Flaremetrics], dan algoritma yang sama berlaku untuk setiap validator di jaringan — termasuk node validator FlareWatch sendiri, yang diskor dengan fungsi yang tepat tanpa perlakuan khusus. Halaman ini mendokumentasikan setiap dimensi dan ambang batas sehingga operator dan staker dapat melihat dengan tepat bagaimana skor dihitung dan mengapa setiap nilai dipilih. Setiap klaim di sini tertaut kembali ke sumber on-chain atau upstream primernya — lihat Sumber & referensi di bagian bawah.

Cakupan: halaman ini mendokumentasikan skor validator — yang Anda lihat dalam staking mode di halaman validator (mendelegasikan FLR ke validator P-Chain untuk reward VRM + MIRROR). Skor penyedia FTSO yang ditampilkan dalam delegation mode (mendelegasikan WFLR ke penyedia data FTSO) menggunakan algoritma terpisah 13-dimensi yang berfokus pada kinerja penyedia data — akurasi, partisipasi protokol V2, dll. Ini adalah peran on-chain yang berbeda dengan reward yang berbeda, diskor secara terpisah. Lihat Metodologi Skor Penyedia FTSO untuk sisi delegasi.
Tidak ada setara SGB: penilaian ini berlaku hanya untuk validator P-Chain Flare. Set validator P-Chain Songbird dibatasi pada entitas yang disetujui Flare Foundation, jadi delegasi P-Chain retail SGB jarang dan tab staking hanya untuk FLR. Tidak ada saklar FLR / SGB dalam staking mode. Untuk delegasi FTSO SGB lihat Metodologi Skor Penyedia FTSO, yang mencakup kedua chain.
Bagaimana kami menghitung APY — apa yang benar-benar Anda hasilkan

APY di tabel staking adalah all-in rate yang diterima delegator — satu angka, tidak ada mental math. Ini diukur dari reward-scripts Flare (actual payouts, bukan formula), setelah dikurangi biaya validator, dan bergerak setiap epoch dengan reward nyata. Di mana pun di FlareWatch, APY berarti setelah biaya dan APY berarti sebelumnya.

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • Reward staking (VRM) — bagian bersih delegator dari reward validasi = Σ pembayaran delegator ÷ Σ didelegasikan (pembagian milik Flare sendiri; biaya sudah dihapus). Karena Flare membayar sebanding dengan stake, ini kira-kira seragam di seluruh jaringan dan berbeda terutama berdasarkan biaya — biaya lebih rendah berarti tingkat delegasi lebih tinggi.
  • MIRROR — bagian stake Anda dari inflasi FTSO, dibayar di atas, hanya pada validator yang menjalankan stack FTSO aktif. Ini bervariasi berdasarkan partisipasi FTSO validator dan diukur selama epoch terbaru.

Membandingkan dengan Flare Systems Explorer? FSE dan explorer lain menampilkan delegation rate only — mereka tidak menambahkan MIRROR — jadi Total APY kami membaca lebih tinggi di validator MIRROR-active mana pun (gapnya exactly MIRROR line di atas). Kedua figure adalah ~8-epoch trailing averages dari data reward-scripts yang sama, jadi perubahan fee mid-window validator lags current-fee snapshot di situs mana pun hingga usianya melalui window.

Dua figure lain muncul di APY tooltip dan bukan rate delegator: theoretical baseline (network gross APY × (1 − fee), staking only — digunakan sebagai fallback sebelum measured history cukup ada), dan self-bond yield operator (own stake return validator, diamplifikasi oleh fee capture — operator metric, bukan apa yang Anda hasilkan).

Untuk scoring: dimensi Net Yield scores VRM delegation rate only, dan MIRROR scores di dimensi tersendiri — jadi MIRROR tidak pernah double-counted, meskipun termasuk dalam displayed Total APY.

Pita skor
90+Top tier — top ~10–20% operator. Profil tipikal: validator full-stack + FTSO + FDC, biaya low-end, MIRROR-active, keandalan FIP-10 konsisten, basis delegator sehat, self-bond bermakna. Tidak ada dimensi tunggal yang diperlukan — operator mencapai Top tier dengan menumpuk kekuatan di sebagian besar kategori.
80–89Strong — memenuhi sebagian besar benchmark kunci; satu atau dua dimensi kurang dari top tier.
70–79Good — memenuhi semua kriteria baseline; tidak ada celah besar.
60–69Acceptable — dapat digunakan tetapi tidak terdiferensiasi.
<60Below median — celah signifikan dalam satu atau lebih dimensi. Fakta matematis, bukan penilaian kualitas.
Dimensi (jumlah ke 100)
Uptime20 poin maks
Apa: Kombinasi uptime RPC P-Chain instan DAN rasio kelayakan uptime FIP-10 historis di seluruh epoch reward terbaru.
Bagaimana: Kurva RPC: ≥ 99,5% → 17 hingga 20. 99–99,5% → 13–17. 95–99% → 4–13. 90–95% → 0–4. < 90% → 0. Hasilnya kemudian dikalikan dengan uptimeReliability (epochsIncluded / epochsObserved dalam 8 epoch reward terakhir dari data public reward-scripts — set minimum FIP-10 lengkap sejak v4.2, bukan RPC-uptime saja). v3.9 memperbaiki cliff yang merugikan pada tepat 95% di mana perubahan dari uptime 94,99 → 95,00 kehilangan 4 poin.
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
Mengapa: Pre-v3.4, dimensi ini pada dasarnya mati — 92,9% validator langsung memiliki uptime RPC 100%, jadi kurva menilai semua orang sama. Rasio keandalan adalah sinyal deret waktu nyata: validator yang gagal kondisi minimum FIP-10 dalam 3 dari 8 epoch terakhir memiliki skor keandalan 62,5%, terlepas dari apa yang dilaporkan RPC instan saat ini. Lebih ketat dari lantai protokol 80% FIP-10 dengan sengaja. Data kelayakan per-epoch dipublikasikan oleh Flare Foundation di repo skrip reward mereka.
Net Yield18 poin maks
Apa: Tingkat reward staking (VRM) bersih-biaya yang diterima delegator, berlabuh ke median jaringan.
Bagaimana: scoreAPR = tingkat DELEGASI bersih terukur (delegationAPY: Σ delegatorRewardAmount / Σ didelegasikan, dari skrip reward Flare Foundation, ~8 epoch terakhir) ketika tersedia, atau baseAPR teoritis = kotor × (1 − biaya). Skor = (scoreAPR / medianAPR) berlabuh: rasio 0,6 → 0 poin, 1,0 (median) → 12 poin, 1,2 → 18 poin. PENTING: dimensi ini menilai tingkat VRM (validation-reward) SAJA — MIRROR diskor secara terpisah dalam dimensi Partisipasi MIRROR, jadi tidak dihitung dua kali di sini. 'Total APR' yang ditampilkan (VRM + MIRROR) adalah angka yang dihadapi delegator, bukan input 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
Mengapa: Kedua sisi rasio adalah tingkat delegasi BERSIH (delegationAPY terukur vs teoritis kotor×(1−biaya)), jadi perbandingannya seperti-untuk-seperti — tidak lagi digelembungkan oleh 1/(1−biaya) seperti ketika inputnya adalah tingkat kotor pra-biaya (bug 'doubling' ~2×). Karena Flare membayar reward validasi sebanding dengan stake, tingkat delegasi VRM kira-kira seragam di seluruh jaringan dan bervariasi terutama berdasarkan biaya — jadi dimensi ini sebagian besar mencerminkan kompetitivitas biaya dan keandalan pengiriman (validator yang melewatkan epoch memberikan lebih sedikit). MIRROR (yang bervariasi berdasarkan partisipasi FTSO) dengan sengaja disimpan dalam dimensinya sendiri untuk menghindari penghitungan ganda.
Kelayakan Biaya7 poin maks
Apa: Cegah ekstraksi di atas batas biaya protokol, mulus dan linier piecewise.
Bagaimana: Anchor = max(biaya aktif minimum yang diamati, lantai biaya validator protokol — 20% sejak hard fork Granite, 2026-07-14). Biaya apa pun pada atau di bawah anchor → 7 poin penuh. Di atasnya, ramp linier dengan slope yang semakin curam selama 20 poin biaya berikutnya (anchor+5 → 6, anchor+10 → 4,5, anchor+15 → 2,5, anchor+20 → 0): kelebihan kecil hampir tidak dihukum, ekstraksi dihukum keras. Sebelum Granite, anchor adalah 5% absolut; clamping lantai berarti operator tidak pernah dihukum karena mengenakan minimum legal.
// 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
Mengapa: Net Yield sudah memperhitungkan biaya per-persen dalam istilah yang disampaikan; dimensi ini hanya menandai operator yang mengenakan biaya secara material di atas apa yang diizinkan protokol dan pasar. Setelah setiap biaya duduk di lantai 20% yang ditegakkan, semua orang mendapat nilai penuh di sini dan dimensi berhenti membedakan — dirancang dengan sengaja: angka yang tidak bisa dipotong siapa pun tidak dapat membedakan siapa pun.
Kualitas Operator12 poin maks
Apa: Mengambil yang lebih tinggi dari dua sinyal independen: baseline verifikasi (kepercayaan diri identitas) dan kinerja operasional yang diturunkan dari FTSO.
Bagaimana: Baseline verifikasi: tier yang dikurasi (+7) dicapai dua cara — entri KNOWN_VALIDATORS yang diverifikasi secara manual ATAU promosi otomatis melalui perilaku objektif (v3.10: 90+ hari diamati DAN 25+ delegator yang dikumpulkan operator DAN tidak saat ini menyusut DAN self-bond ≥ lantai FIP-10). Nama yang ditemukan secara otomatis dari Flaremetrics atau FSE → +3. Tidak diverifikasi → 0. FTSO-derived: interpolasi linear skor FTSO 50 → 4 poin hingga skor FTSO 100 → 12 poin (di bawah 50 lantai pada 4). Skor akhir adalah max(verifikasi, FTSO-derived) — partisipasi FTSO hanya dapat membantu, tidak pernah merugikan.
// 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)
Mengapa: Menghargai operator yang menjalankan stack lengkap (validator + FTSO + FDC) tanpa menghukum operator terpercaya yang berpartisipasi di FTSO dengan skor tier menengah. Logika max() v3.8 secara eksplisit mencegah insentif pervers 'berhenti dari FTSO untuk meningkatkan skor FlareWatch Anda.' Tier yang ditemukan otomatis (+3) menutup tebing 7→0 sebelumnya yang menimpa operator yang terdaftar di Flaremetrics atau FSE namun belum dikurasi tangan.
Partisipasi MIRROR12 poin maks
Apa: Apakah nodeID validator benar-benar memberikan share inflasi FTSO kepada staker — baik fraksi yang mencapai delegator (passthrough biaya) dan, sejak v4.6, jumlah yang dikirimkan relatif terhadap lapangan.
Bagaimana: Active → 10 × (1 − fee/100). Paused → 5 × passthrough. Inactive (tidak ada sinyal partisipasi di mana pun) → 0. Tidak ada data (validator yang benar-benar tidak teramati) → 5 × passthrough. v3.6 memperluas sinyal 'active' untuk memasukkan event RewardClaimed(claimType=3) on-chain DAN alokasi claimType=3 dalam JSON Merkle FSP kanonik — salah satu cukup. Ini menangkap validator yang MIRROR telah dialokasikan tetapi belum diklaim on-chain (misalnya, penyedia self-delegating yang jalur settlement-nya tidak memicu standard claim event). v4.6 magnitude bonus (maksimal +2, dimensi ceiling 12): hanya untuk validator mirror-active, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2) — credit untuk memberikan rate MIRROR di atas median (net of fee) kepada delegator. Dipasok ke rate median jaringan, jadi netral ukuran: validator kecil yang memberikan rate tinggi mendapatkan credit yang sama seperti validator besar.
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
Mengapa: MIRROR distribusi otomatis kepada staker di validator yang berpartisipasi FSP. Validator 100%-fee yang 'active' memberikan $0 kepada delegator; skor mencerminkan apa yang benar-benar diterima delegator, bukan hanya status flag sisi protokol. Bonus magnitude v4.6 menutup titik buta: passthrough saja mengukur FRAKSI yang mencapai delegator tetapi bukan JUMLAH, jadi validator yang membayar rate MIRROR yang dikirimkan jauh lebih tinggi tidak mendapatkan credit tambahan untuk itu. Sekarang itu melakukannya — dibatasi, dan hanya di atas median jaringan.
Profil Kapasitas7 poin maks
Apa: Fungsi tenda yang mencapai puncak pada utilisasi ukuran-tepat.
Bagaimana: 0% digunakan → 1,75. Rampa linier naik ke 7 pada utilisasi 70%. Rampa linier turun ke 5,25 pada 100% (tutup). Diskalakan ulang di v3.7 dari 8 → 7 untuk mendanai komponen trajektori Trust baru.
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
Mengapa: Berada di delegasi maksimum FIP-10 adalah sinyal POSITIF daya tarik — terbukti dipercaya oleh delegator yang cukup untuk mengisi. v2 menilai validator tutup 0/5; v3 memperbaiki ini. Ukuran-tepat (terbukti menarik DAN memiliki ruang) mendapat puncak. v3.7 merapikan cap dimensi 8 → 7 sehingga poin yang dibebaskan dapat mendanai komponen trajektori retensi Trust + obligasi-diri baru.
Kepercayaan Komunitas11 poin maks
Apa: Multi-sinyal: jumlah delegator + kesehatan distribusi stake + longevitas + komitmen self-bond operator (proporsional dan absolut) + retensi 30 hari + trajectory self-bond + agregasi operator multi-node.
Bagaimana: Sinyal hitungan (maks 6, OPERATOR-AGGREGATED v3.7): skala log [5, 500] delegator → [0, 6], dijumlahkan di semua node yang diketahui dari operator. Penyesuaian konsentrasi (±1): stake rata-rata ramah retail (<500K FLR) → +1, terkonsentrasi whale (>50M FLR rata-rata) → −1. Bonus longevitas (maks +1, tahan-wipe v3.6): +0.5 pada 30 hari diamati, +1 pada 90+ hari — jatuh kembali ke kehadiran epoch reward-scripts jika KV yang pertama diamati dihapus. Skin-in-the-game self-bond (maks +2 / min −1, DUA-SUMBU v4.7): dikreditkan dengan YANG LEBIH BAIK dari bagian proporsional ATAU ukuran absolut — proporsional ≥10% → +2 / 5–10% → +1, dan absolut = min(1, selfBond ÷ 20M) × 2 jenuh pada bond desil teratas jaringan; sinyal mengambil max dari keduanya, masih dibatasi pada +2. Lantai sub-FIP-10 (<1M FLR) → −1. Retensi (maks ±0.5, BARU v3.7): FLR terdelegasi +10% dalam 30 hari → +0.5, −15% → −0.5. Trajectory self-bond (maks ±0.5, BARU v3.7): self-bond operator +20% dalam 30 hari → +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)
Mengapa: Self-bond skin-in-the-game adalah sinyal keadilan nyata yang kami lewatkan — validator dengan 10% dari total stake sebagai self-bond memiliki insentif yang jauh lebih selaras daripada yang berjalan pada minimum FIP-10. v4.7 membuat ini dua-sumbu: membaca self-bond hanya sebagai rasio menghukum operator yang menginvestasikan stake absolut besar dan kemudian menarik delegasi, yang mengencerkan rasio tanpa mengurangi komitmen nyata — self-bond 20M pada rasio yang diencerkan mencetak sama seperti bond sub-2M pada rasio itu. Sinyal sekarang mengakui YANG LEBIH BAIK dari bagian proporsional atau ukuran absolut, sisi absolut jenuh pada bond teratas jaringan sehingga ukuran tidak dapat sekadar membeli skor, cocok dengan bagaimana skor penyedia FTSO sudah memperlakukan self-bond; batas +2 tidak berubah, jadi operator berkomitmen besar sekarang dapat mencapainya tetapi plafon tidak bergerak. Longevitas menghargai track record yang terbukti tanpa menghukum pendatang baru (bonus kecil di atas, bukan penalti di bawah). Risiko konsentrasi penting untuk delegator — validator dengan 1 whale di 50M FLR secara struktural berbeda dari 50 retail di masing-masing 1M. Dua sinyal trajectory v3.7 menghargai pertumbuhan organik dan komitmen operator yang berkembang. Batas gabungan adalah 11 (naik dari 10 di v3.7 untuk mendanainya), tidak ada sinyal yang mendominasi.
Keandalan Pengiriman10 poin maks
Apa: Rasio tingkat delegasi bersih yang benar-benar dikirimkan (VRM) vs. baseline teoritis, dengan penalti varians untuk pembayaran yang tidak konsisten. Kedua sisi adalah neto biaya, jadi rasio mengukur pengiriman nyata — bukan biayanya.
Bagaimana: Rasio pengiriman piecewise linier: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → rampa linier menuju 0. Penalti varians: koefisien variasi × 0,5, tutup pada −30%. Peredam kepercayaan mencampur ke arah netral 5 ketika ukuran sampel < 3 epoch. v3.9 melinierkan threshold yang sebelumnya dibatasi — tebing batas hingga 2 poin kini mulus.
// 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
Mengapa: Dijanjikan vs. dikirimkan adalah sinyal akuntabilitas paling langsung untuk staker. v3.3 menambahkan dua penyempurnaan: (1) rasio headline menggunakan rerata tertimbang waktu eksponensial (epoch terbaru menghitung lebih banyak), jadi validator yang dulu mengirim dengan baik namun baru-baru ini meleset diperbaiki dengan benar; (2) penalti varians membedakan pengiriman konsisten 95% dari pengiriman berosilasi-di-sekitar-95%, karena yang terakhir membawa risiko lebih bagi staker yang peduli hasil yang dapat diprediksi.
Waktu Tersisa5 poin maks
Apa: Hari sampai stake-end validator di P-Chain.
Bagaimana: < 14 hari → 0 (pada dasarnya tidak tersedia di bawah FIP-10). 14-30h → linier 0→2. 30-60h → linier 2→3. 60-120h → linier 3→5. 120h+ → 5. v3.9 melinierkan threshold yang sebelumnya dibatasi — tebing batas (mis. 13,99h → 0, 14h → 2) kini mulus.
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
Mengapa: Sinyal praktis — mendelegasikan ke validator dengan 7 hari tersisa adalah proposisi yang berbeda dari 1 tahun. v3.2 memperketat bagian bawah: validator dalam 14 hari dari stake-end tidak dapat menerima delegasi baru (kunci minimum FIP-10 adalah 14 hari), jadi mereka pada dasarnya tidak dapat dibatalkan. Skor = 0 membedakan 'tidak dapat dibatalkan sekarang' dari 'menutup segera.'
Penalti Pemadaman Aktif (v4.3)(potongan) poin maks
Apa: Potongan datar berlapis di atas dimensi positif ketika validator melewatkan beberapa epoch reward berturut-turut. Berbeda dari pengganda keandalan Uptime simetris — menangkap pemadaman aktif, bukan kelambanan kronis.
Bagaimana: Lihat prefix !eligible berdekatan validator dalam record cache:fsp-validator-participation (daftar epoch newest-first dari node reward-scripts publik nodes-data.json). 0–1 melompat berturut-turut → 0 poin (dalam varians / miss transien tunggal). 2 berturut-turut → −3 poin (pemadaman berkembang). 3 berturut-turut → −6 poin (berkelanjutan — kelalaian operator). 4+ berturut-turut → −10 poin (pemadaman perpanjangan aktif). Skor gabungan dijatuhkan ke 0 setelah potongan.
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)
Mengapa: Model pra-v4.3 bergantung sepenuhnya pada pengganda keandalan uptimeReliability simetris — 5 miss tersebar selama 24 epoch biaya yang sama dengan 5 miss berturut-turut. Operasionalnya itu sinyal yang sangat berbeda. Miss tersebar memberitahu delegator tentang kelambanan kronis; rentetan memberitahu mereka validator rusak SEKARANG. Insiden Luganodes pada 2026-05-14 — beberapa epoch yang melewatkan berturut-turut sementara delegator secara aktif berkomitmen jutaan FLR — adalah kasus spesifik yang dirancang untuk ditangani rilis v4.3: permukaan sinyal pemadaman-aktif dengan dampak skor lebih tajam sehingga delegator dapat menghindari kegagalan dalam-penerbangan sebelum berkomitmen. Kurva bertingkat menghindari overreacting terhadap miss transien tunggal (umum) sementara secara tajam menandai rentetan berkelanjutan (langka dan konsekuensial).
Penalti Biaya Ekstrem (v4.5)(hingga −75% dari skor) poin maks
Apa: Pengurangan proporsional untuk biaya di luar jangkauan dimensi Biaya. Dimensi Biaya mencapai batas bawah 0/7 setelah biaya melebihi jangkar sebesar 20 poin — setelah itu, komposit sebelumnya berhenti merespons biaya sepenuhnya, sehingga validator berbiaya 100% (pendelegasinya tidak mendapatkan apa-apa) masih bisa mencetak skor di 40-an pada dimensi yang buta biaya seperti uptime dan MIRROR.
Bagaimana: Nol pada biaya 50% atau lebih rendah — dimensi Biaya sudah memperhitungkan rentang tersebut, jadi tidak ada penghitungan ganda. Di atas 50%, pengurangan meningkat secara linier dengan biaya, mencapai 75% dari skor positif validator pada biaya 100%. Biaya tersebut berskala dengan skor itu sendiri, sehingga node pribadi yang dipoles dan yang terabaikan sama-sama mendarat di tempat yang seharusnya: di bagian bawah peringkat yang menghadap pendelegasi.
// 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)
Mengapa: Ini adalah skor untuk pendelegasi. Validator yang mempertahankan setiap imbalan yang diperoleh pendelegasinya bukan kandidat pendelegasian apapun betapapun baiknya uptime-nya — skor harus dengan jelas menunjukkan hal itu. Fungsi murni dari biaya on-chain, diterapkan secara identik pada setiap node, termasuk milik kami.
Cara mencetak 100/100 — playbook validator
Siklus audit yang menghasilkan v4.0 dirancang khusus sehingga memaksimalkan setiap dimensi benar-benar membuat Anda validator yang lebih baik untuk delegator Anda. Meningkatkan skor Anda bukan gaming sistem — itu sistem bekerja sesuai desain. Berikut playbook eksplisit, per dimensi.
Uptime — 20 poin. Pertahankan keandalan RPC ≥99,5% secara berkelanjutan DAN lewati kondisi minimum FIP-10 di setiap epoch reward (jangan lewatkan reveal, capai pengiriman median). Dua sinyal dikalikan — RPC 100% × 7/8 epoch eligible = 17,5/20, bukan 20. Mengapa ini sejalan dengan delegator: setiap epoch Anda gagal FIP-10, delegator Anda kehilangan reward mereka untuk epoch tersebut.
Net Yield — 18 pts. Deliver ≥1,2× network median APY kepada delegator Anda (post-fee). Best path: low fee + full FIP-10 eligibility sehingga delegator menerima full share mereka. Mengapa ini aligned: ini literally dollar amount yang mencapai delegator setelah cut Anda.
Kelayakan Biaya — 7 poin. Sejak hard fork Granite, protokol menerapkan biaya delegasi minimum 20%, dan biaya apa pun pada atau di bawah anchor penilaian (yang lebih besar dari minimum pasar yang diamati dan lantai itu) mendapatkan 7 penuh. Mengenakan biaya di atasnya menghabiskan poin pada ramp yang mempercepat — anchor+10 → 4,5 poin, anchor+20 → 0. Mengapa ini selaras: lantai membunuh kompetisi biaya, jadi dimensi ini sekarang hanya melindungi delegator dari ekstraksi di atas minimum legal; keunggulan nyata Anda ada di Net Yield yang disampaikan.
Kualitas Operator — 12 poin. Jalur terbaik: daftar sebagai penyedia data FTSO dan jalankan stack berkualitas-tinggi (FTSO + FDC + signing) — skor Operator Quality FlareWatch Anda kemudian berasal dari skor FTSO Anda, dengan maks di FTSO 100. Alternatif jika Anda staking-saja: pertahankan baseline verifikasi +7 baik dengan memenuhi syarat promosi-otomatis v3.10 (90+ hari diamati, 25+ delegator, retensi tidak menurun, obligasi-diri FIP-10-compliant) atau ditambahkan ke KNOWN_VALIDATORS sebagai infrastruktur institusional (fast-track manual). Skor mengambil max(verifikasi, FTSO-derived) — partisipasi tidak pernah dapat merugikan. Mengapa ini sejalan: operator full-stack memberikan nilai ekosistem lebih; baseline verifikasi memberikan sinyal identitas delegator yang lebih jelas.
Partisipasi MIRROR — 10 poin. Kirimkan feed harga FSP secara konsisten, penuhi minimum per-epoch protokol (terdaftar dalam kebijakan signing Anda, ambang klaim terpenuhi, tidak ada reveal miss). Kenakan biaya moderat — skor dikalikan dengan (1 − biaya/100), jadi bahkan validator MIRROR-aktif sempurna dengan biaya 100% mencetak 0 karena nol MIRROR mencapai delegator. Mengapa ini sejalan: MIRROR adalah bagian delegator Anda dari inflasi FTSO. Biaya lebih rendah = lebih banyak mencapai mereka.
Profil Kapasitas — 7 poin. Target utilisasi ~70% (ukuran-tepat: terbukti menarik DAN memiliki ruang untuk delegator baru). Validator kosong mencetak 1,75; validator tutup mencetak 5,25. Mengapa ini sejalan: delegator baru membaca skor ingin tahu mereka benar-benar dapat mendelegasi; ukuran-tepat menandakan bukti sosial dan ketersediaan.
Kepercayaan Komunitas — 11 poin. Enam komponen untuk maksimalkan:
  • Bangun ke 500+ delegator operator-agregat (sinyal jumlah maks: +6 poin).
  • Pertahankan avg stake ramah-ritel < 500K FLR per delegator (bonus konsentrasi: +1).
  • Tetap di jaringan ≥ 90 hari untuk bonus longevitas (+1) — tahan-hapus melalui kehadiran reward-scripts.
  • Tahan self-bond besar — baik ≥ 10% secara proporsional ATAU stake absolut teratas jaringan (~20M FLR), mana yang mencetak lebih baik (bonus alignment: +2).
  • Tumbuhkan total FLR terdelegasi sebesar ≥ 10% dalam 30 hari (retensi: +0,5).
  • Tingkatkan self-bond sebesar ≥ 20% selama 30 hari (trajectory: +0.5).
Mengapa ini sejalan: setiap komponen menghargai perilaku yang delegator inginkan — operator skin-in-the-game, pertumbuhan organik, longevity, partisipasi komunitas yang luas. Operator multi-node diagregasikan untuk sinyal count + concentration (v3.7).
Delivery Reliability — 10 pts. Bayar delegator sesuai APY estimasi yang Anda janjikan (delivery ratio 1.00). Minimalkan varians per-epoch — predictable payouts lebih baik daripada mean yang sama dengan spread tinggi (variance penalty hingga −30%). Bangun sample size 8+ epoch untuk weighting penuh confidence. Mengapa ini sejalan: apakah Anda deliver apa yang dijanjikan, konsisten? Itu sinyal accountability paling langsung.
Time Remaining — 5 pts. Jaga stake-end date Anda ≥ 120 hari ke depan. Renew jauh sebelum expiration; jangan biarkan masuk ke band < 14 hari (Anda tidak bisa accept delegasi baru di bawah FIP-10 setelah masuk 14 hari). Mengapa ini sejalan: komitmen jangka panjang signals delegator bahwa Anda ada untuk jangka panjang.
Time-gated signals yang tidak bisa Anda shortcut: longevity bonus (90 hari observed), auto-curation tier (90 hari + 25 delegator + non-declining retention + FIP-10 self-bond), retention signal (30 hari delegation history), delivery sample size (8 reward epoch). Kabar baiknya: maintain perilaku LAIN akan otomatis mengumpulkan ini seiring waktu.
Smoothing window penting dalam jangka pendek: skor yang ditampilkan adalah exponentially-weighted average dari 4 cron snapshot terakhir (0.5 / 0.3 / 0.15 / 0.05), jadi bahkan 100 sempurna pada inputs membutuhkan ~20 menit cron runs sempurna berturut-turut untuk fully reflect. Steady-state perfect inputs = 100; improvements transient ter-smooth in. Sudden-change penalties (fee jumps, self-bond drops, uptime crashes) juga bisa dock hingga 10 pts selama beberapa cron cycle setelah detection.
Singkatnya: setiap dimensi jujur tentang apa yang diukur. Jika validator Anda 100/100, skor juga tell delegator mereka mendapatkan best version validator di network — itu design intent.
Cara verify skor Anda sendiri
Setiap skor di validator table dapat direproduksi dari public data. Jika Anda operator dan math di sini tidak match skor yang Anda lihat, langkah yang tepat adalah verify sendiri sebelum assume kami membuat error.
Fastest check runs automatically. Expand validator score row dan panel "Verified in your browser" recompute skor locally — exact same scoring function yang cron gunakan, over exact inputs yang digunakan, tanpa call balik ke server kami. Karena setiap validator scored oleh satu identical function tanpa term untuk node identity, ini juga bagaimana anyone bisa confirm node kami sendiri earn tanpa hidden advantage. Manual walkthrough di bawah lakukan hal yang sama by hand:
  1. Cari public stats validator Anda di flaremetrics.io (search by operator name atau paste delegation address Anda). Catat delegationFee, selfBond, delegatedStake, dan FTSO score Anda (jika Anda juga data provider).
  2. Verify FIP-10 eligibility Anda untuk masing-masing 8 reward epoch terakhir di github.com/flare-foundation/reward-scripts di bawah generated-files/reward-epoch-N/nodes-data.json. Hitung berapa banyak epoch nodeID Anda memiliki uptimeEligible: true. Rasio itu drive Uptime dimension multiplier Anda.
  3. Periksa partisipasi MIRROR Anda di V2 RewardManager contract via flare-explorer.flare.network. Cari RewardClaimed events dengan claimType=3 referencing nodeID Anda. Jika tidak ada recent, Anda akan show sebagai MIRROR-inactive.
  4. Plug inputs Anda ke formulas di atas. Code block dimensi setiap memberitahu Anda exactly apa arithmetic untuk run. Sum dimensinya, clamp ke 100, dan Anda punya raw cron-computed score Anda.
  5. Bandingkan ke skor yang ditampilkan. Skor yang ditampilkan includes v3.5's exponential moving average across 4 cron snapshot terakhir (current weighted 0.5, prev 0.3, etc.) — jadi single run's computed score akan slightly different dari yang ditampilkan. Panel score-breakdown di setiap validator row shows persisted dimension values yang contributed.
  6. Jika math tidak add up, email [email protected] dengan nodeID Anda, inputs yang Anda gunakan, dan skor yang Anda compute. Kami akan respond, dan jika kami buat error kami akan fix publicly.
Programmatic access: untuk validator aktif apapun, hit GET /api/validators/{nodeID}/score-breakdown untuk retrieve persisted breakdown — setiap dimension's value, algorithm version yang produce, dan recent score history — sebagai JSON. Panel score-breakdown di UI reads dari source yang sama.
Kekhawatiran operator umum
Saya di 100% RPC uptime — mengapa Uptime score saya di bawah 20/20?
Dimensi Uptime mengalikan output kurva RPC dengan rasio kelayakan epoch Anda (epochsIncluded / epochsObserved dalam 8 epoch reward terakhir — set minimum FIP-10 lengkap sejak v4.2, bukan RPC-uptime saja). Jika Anda gagal memenuhi kondisi minimum FIP-10 dalam salah satu epoch tersebut — bahkan sebentar — rasio keandalan Anda turun di bawah 1,0 dan skor Uptime Anda berkurang secara proporsional. Sebelum v3.4 dimensi ini memberikan skor 20 untuk setiap validator dengan uptime RPC 100% terlepas dari kelayakan historis. Sekarang ini membedakan.
Saya deliver MIRROR — mengapa FlareWatch show saya sebagai MIRROR-inactive?
As of v3.6, MIRROR participation detected dari TWO canonical sources: on-chain RewardClaimed(claimType=3) events di V2 RewardManager, DAN claimType=3 allocations di official FSP Merkle JSON (published reward distribution data). NodeID showing di either source counts sebagai active. Pre-v3.6 kami gunakan on-chain stream sebagai sole signal, yang produce false negatives untuk self-delegating providers yang MIRROR settles through non-standard claim path. Juga fixed di v3.6: key-format bug di mana ~95 validators punya mirror-stats entries ditulis di bawah hex20 (bytes20 form nodeID) by on-chain indexer ketika mereka belum di curated name list kami — sementara setiap UI lookup key by cb58 NodeID. Entry itu exist dan correct; mereka just tidak visible untuk display layer. Lookup sekarang normalize both formats across setiap consumer (validators table, score-breakdown panel, public mirror-stats API, Yield page Staking Positions card, FTSO providers panel). Jika nodeID Anda masih show inactive setelah v3.6 sweep, possible causes: (a) nodeID Anda tidak actually enrolled di FSP signing policy Anda untuk epoch itu, (b) kami between epoch publications (Merkle data updates per epoch, ~3.5 hari). Email kami dengan nodeID Anda dan kami akan cross-check both canonical sources.
Score saya drop 10 poin overnight — apa yang berubah?
Satu dari tiga hal: (1) v3.5 sudden-change detection flag fee jump, self-bond drop, atau uptime crash di nodeID Anda — 10-pt penalty apply run kami detect dan decay over next 3 runs saat state baru stabilize; (2) smoothing window incorporate older snapshot yang pull average Anda down; (3) kami ship algorithm version bump (visible di record's algorithmVersion field Anda — lihat Versions card di bawah). Panel score-breakdown show current dimension values; compare against prior runs Anda.
Mengapa high-fee validator score lebih rendah daripada low-fee satu dengan similar everything else?
Dimensi Net Yield (maks 18 poin) sensitif terhadap fee — validator dengan fee 0% menghasilkan ~1,25× median APY jaringan, mendapat skor mendekati maksimum; validator dengan fee 20% menghasilkan ~80% median, mendapat skor lebih rendah. Plus Fee Reasonableness (7 poin) bersifat linear piecewise sejak v3.9 (tanpa bucket): ≤5% mendapat 7 penuh, kemudian kurva menurun dengan kemiringan yang semakin curam — 10% → 6, 15% → 4,5, 20% → 2,5, 25%+ → 0 (jadi misalnya fee 16% mendapat skor ~4,1, bukan nilai bucket datar). Jadi perbedaan fee 5 poin diterjemahkan ke ~5-8 poin perbedaan skor. Itu disengaja — delegator peduli langsung dengan fee.
Saya brand-new validator tanpa FTSO score. Mengapa Operator Quality saya hanya 7/12?
Operator Quality (12 pts max) reward full-stack operators — validators yang juga run top FTSO data-provider stack (FTSO + FDC + signing). Jika Anda staking-only, +7 baseline reachable dua cara: (1) manual inclusion di KNOWN_VALIDATORS list kami — institutional fast-track untuk trusted infrastructure operators (Ankr, InfStones, Kiln, dll.); (2) v3.10 auto-promotion based objective behavior — 90+ hari observed DAN 25+ operator-aggregated delegators DAN retention tidak declining DAN FIP-10-compliant self-bond. Auto-promotion fully automatic, tidak perlu email. Jika Anda belum meet auto-criteria Anda start +3 (auto-discovered tier, require Flaremetrics atau FSE entity profile) dan grow ke +7 saat track record Anda build. Untuk accelerate: register sebagai FTSO data provider dan run V2 protocols — score Anda kemudian come dari FTSO-derived branch dengan max 12 di FTSO 100. v3.8: FTSO participation bisa hanya help, tidak pernah hurt — jika FTSO score Anda di bawah verification baseline, Anda keep baseline.
Saya punya logo tapi name saya show sebagai truncated NodeID. Mengapa?
Operator entity Anda exist di Flaremetrics (karena itu kami punya logo untuk Anda) tapi provider profile Anda tidak punya 'name' field set. Kami tidak fabricate names. Set profile.name Anda di Flaremetrics atau di Flare Systems Explorer entity registry, dan kami akan pick up di next cron run. Alternatively, email kami verifiable claim (e.g., signed message dari delegation address Anda) dan kami akan add Anda ke KNOWN_VALIDATORS by hand.
Validator saya di FIP-10 max delegations. Mengapa Capacity score bukan 7/7?
Capacity adalah tent function peaking di 70% utilization (7 pts), ramping down ke 5.25 pts di 100%. Peak bukan 100% — being at-cap means delegators tidak bisa add lebih banyak stake bahkan jika mereka mau, yang adalah neutral-to-mildly-negative signal untuk new delegators reading table. Pre-v3 kami score capped validators 0/5 (penalty untuk success); v3 correct ini ke neutral at-cap value, dan v3.7 rescale whole dimension dari 8 → 7 max (freeing point untuk Trust trajectory signals), jadi hari ini capped score 5.25/7. Right-sized validators (proven attractive DAN dengan room untuk grow, peak di 70% utilized) dapat 7 penuh.
Saya operator real tapi saya tidak di validator list sama sekali. Apa masalahnya?
Validator list di-build dari live P-Chain RPC's getCurrentValidators result. Jika Anda tidak ada di sana, Anda either tidak currently active di P-Chain, stake Anda baru expire, atau ada P-Chain RPC issue di side kami. Cron run setiap 5 menit — Anda seharusnya appear dalam 1-2 cycles dari activating stake Anda. Jika Anda sudah live selama satu jam dan masih tidak lihat diri sendiri, email kami nodeID Anda.
Bisa saya appeal skor atau request manual review?
Ya. Email [email protected] dengan nodeID Anda dan concern spesifik. Kami respond ke setiap operator. Things yang kami akan act on: KNOWN_VALIDATORS additions, MIRROR-classification corrections, logo/name fixes, dimension-specific math errors. Things yang kami tidak akan act on: requests untuk manually raise skor outside algorithm, requests untuk exclude atau de-rank competitor.
Apa yang akan dan tidak akan kami lakukan
Untuk remove ambiguity tentang bagaimana kami operate skor, berikut explicit commitments. Jika kami pernah violate satu dari ini, document dan email [email protected] — kami akan publicly correct.
✓
Kami tidak akan accept payment untuk higher scores, sponsored placement, atau favorable treatment dari any kind. Skor di-compute deterministically dari public chain data.
✓
Kami tidak akan hand-code per-validator bumps. Tidak ada "X dapat +5 karena kami suka mereka" line anywhere di code. Same algorithm applies ke setiap validator including FlareWatch's own node, yang di-score oleh exact function ini.
✓
Kami tidak akan mengecualikan validator dari tabel karena alasan non-publik. Daftar bersumber dari P-Chain RPC langsung dan layanan kami mencakup setiap validator aktif. Penambahan yang dikurasi ke KNOWN_VALIDATORS hanya mengisi nama tampilan — mereka tidak membatasi visibilitas.
✓
Kami akan menerbitkan perubahan algoritma. Setiap bump versi (v3 → v3.1 → v3.2 → ...) didokumentasikan di kartu Versions di halaman ini dengan rasional dan apa yang berubah. Perubahan besar mendapat entri changelog tambahan yang terlihat dari halaman changelog aplikasi.
✓
Kami akan merespons email operator. Setiap operator yang mengirim email ke [email protected] dengan kekhawatiran substansial tentang skor mereka mendapat respons nyata dalam beberapa hari kerja.
✓
Kami akan memperbaiki kesalahan kami secara publik. Jika kami menemukan bug dalam algoritma, kesalahan sumber data, atau celah metodologi, kami mengirimkan perbaikan dan mendokumentasikannya. Kami tidak mengurutkan ulang secara diam-diam.
✗
Kami tidak akan membagikan isi email secara publik tanpa izin pengirim, atau menggunakan email operator untuk apa pun selain percakapan skor yang menghasilkannya.
✗
Kami tidak akan membagikan rencana masa depan untuk perubahan algoritma dengan operator pilihan terlebih dahulu — setiap versi diluncurkan untuk semua orang secara bersamaan.
Keterbatasan — apa skor ini, dan apa yang bukan
Skor komposit adalah ringkasan yang berguna, bukan kebenaran objektif. Kami transparan, terversi, diterapkan secara identik untuk setiap validator — termasuk validator kami sendiri — dan dapat diturunkan kembali dari input yang dipublikasikan langsung di browser Anda. Tetapi ini tetap menyandikan pertimbangan editorial, dan kami lebih suka menunjukkan kepada Anda tempat tepatnya daripada menyiratkan presisi yang tidak dimiliki metode ini.
Bobot dimensi adalah pertimbangan kami. Uptime bernilai 20 poin dan biaya bernilai 7 karena kami memutuskan bahwa keandalan lebih penting bagi sebagian besar delegator daripada beberapa poin biaya — bukan karena formula membuktikannya. Orang-orang yang wajar akan membobotnya secara berbeda. Bobot bersifat tetap dan publik, sehingga Anda dapat melihat dengan tepat apa yang kami pilih dan secara mental membobotnya kembali dari rinciannya.
Net Yield adalah hasil, bukan keunggulan. Ini mengukur apa yang sebenarnya diperoleh delegator, berlabuh pada median jaringan — jadi ini sebagian dibentuk oleh hal-hal di luar kendali operator (inflasi jaringan, jumlah delegasi yang telah mereka tarik) dan bergerak saat sisa lapangan bergerak. Operator yang disiplin mengenakan biaya yang adil tetapi lebih tinggi dapat mencetak skor lebih rendah di sini sambil menjadi sangat baik. Bacanya sebagai "apa yang akan saya peroleh," bukan "seberapa baik operator ini."
Dimensi tertaut FTSO menguntungkan operator full-stack. MIRROR Participation dan bagian dari Operator Quality memberi penghargaan kepada validator yang juga menjalankan tumpukan penyedia data FTSO teratas. Itu disengaja — sebagai delegator Anda benar-benar memperoleh lebih banyak, melalui MIRROR, dari validator yang aktif FTSO — tetapi itu berarti validator yang murni dan sangat baik yang hanya staking tidak dapat mencapai puncak papan ini. Jika Anda hanya staking dengan pilihan, bobotkan dimensi tersebut ke bawah untuk diri sendiri.
Model ini bersifat aditif. Dimensi ditambahkan bersama-sama, jadi kekuatan dapat mengimbangi kelemahan — uptime yang luar biasa dapat membawa biaya yang lebih tinggi ke skor yang terhormat. Kegagalan yang benar-benar diskualifikasi (gagal minimum FIP-10, biaya predator) dijaga secara terpisah sehingga tidak dapat sepenuhnya tersembunyi — validator yang gagal minimum setiap epoch atau mengenakan biaya 100% mendarat di dekat bagian bawah terlepas dari dimensi lainnya — tetapi intinya adalah jumlah tertimbang, bukan sistem veto.
Satu angka menyembunyikan sembilan pertimbangan. Angka 0-100 tunggal adalah titik awal, bukan putusan. Dua validator yang terpaut satu poin tidak berbeda secara berarti. Buka rinciannya dan bobotkan dimensi yang penting bagi Anda — angka ada untuk membuat perbandingan itu lebih cepat, bukan untuk menggantinya.
Kami mengubah metode jarang kali, dan secara publik. Setiap perubahan dilengkapi dengan bump versi, rasional tertulis, dan before-and-after di seluruh lapangan, sehingga Anda dapat mengaudit apa yang bergerak dan mengapa. Ketika audit otomatis kami sendiri menangkap perbedaan dalam angka kami — seperti yang terjadi — kami memperbaikinya dan memberitahunya.
Skor akhir (cara dimensi digabungkan)
Semua 9 dimensi dijumlahkan langsung, kemudian pengurangan streak outage aktif v4.3 dikurangkan. Total dibatasi pada 100 dan minimum 0. Smoothing lintas snapshot cron terbaru (v3.5) dan penalti perubahan mendadak kemudian diterapkan pada angka akhir.
// 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)
Sumber data (setiap input bersifat publik)
Flare P-Chain RPC: daftar validator, uptime, self-bond, delegated stake, fee, waktu akhir, jumlah delegator.
V2 RewardManager (claimType=3 events): distribusi MIRROR yang diklaim on-chain per nodeID validator. Disaring ketat pada tipe 3 — tanpa pencampuran dengan VRM, delegasi FTSO, atau rewards DIRECT.
FSP Merkle JSON (claimType=3 allocations): catatan yang dipublikasikan secara kanonis tentang siapa yang berhak menerima MIRROR per epoch (data yang sama yang dibaca oleh alat penandatanganan Flare). Ditambahkan di v3.6 sebagai sumber yang dapat dipercaya kedua — menangkap validator yang MIRROR-nya dialokasikan tetapi belum diklaim on-chain.
Flare Systems Explorer (FSE): registry entitas validator, nama tampilan, logo, flag partisipasi protokol FTSO V2.
Data provider Flaremetrics: skor FTSO, tingkat reward, akurasi, fitur V2, linkage entitas-ke-nodeID.
Flare reward-scripts (GitHub): APY yang dikirimkan per-validator untuk N epoch reward terbaru. Mendorong dimensi Delivery.
Kurasi FlareWatch: peta KNOWN_VALIDATORS (~110 entri). Nama + baseline Operator Quality untuk operator infrastruktur terpercaya.
Apa yang TIDAK ada dalam skor
• Promosi diri atau penempatan berbayar. Tidak ada operator yang dapat membayar atau mensponsori skor lebih tinggi.
• Bump validator-spesifik yang dikode tangan. Tidak ada baris "X mendapat +5 karena kami menyukai mereka" di mana pun dalam kode. Algoritma yang sama berlaku untuk setiap validator termasuk node FlareWatch sendiri, yang diskor dengan fungsi yang tepat ini.
• Kualitas infrastruktur subjektif. Kami tidak mencoba mengevaluasi SLA uptime, distribusi geografis, atau spesifikasi hardware. Jika Anda ingin mengklaim tingkat infrastruktur, jalankan stack FTSO + FDC terkemuka dan dimensi Operator Quality akan mencerminkannya.
• Lockups atau komitmen kepada FlareWatch. Tidak ada favorable scoring untuk staker yang menggunakan FlareWatch vs. alat lain.
Feedback operator
Melihat ada yang salah dalam skor validator Anda? Kirim email ke [email protected] dengan NodeID dan kekhawatiran Anda. Kami merespons setiap operator. Permintaan umum yang akan kami tindaklanjuti:
  • Menambahkan operator Anda ke KNOWN_VALIDATORS (dengan verifikasi).
  • Meninjau klasifikasi MIRROR-inactive Anda jika Anda percaya ada kesalahan.
  • Koreksi logo / nama tampilan.
  • Kritik algoritma umum.
Sumber & referensi
Setiap input ke skor berasal dari sumber publik dan dapat diverifikasi dari ekosistem Flare. Siapa pun dapat melakukan cross-check klaim kami terhadap sumber utama ini dan mereproduksi matematika dari data mentah. Jika Anda menemukan diskrepansi antara halaman ini dan apa yang dikatakan sumber upstream, kirim email ke [email protected] dan kami akan memperbaikinya.
Dokumentasi protokol Flare Network ↗https://docs.flare.network
Dokumentasi protokol yang berwenang. Mencakup FTSO V2, FSP, validasi P-Chain, FAssets, dan sisa stack Flare.
Portal governance Flare (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — sumber kebenaran untuk FIP-05 (delegation factor), FIP-10 (kondisi minimum validator: floor self-bond 1M FLR, floor uptime 80%, minimum lock 14 hari), dan semua aturan lain yang dikutip di halaman ini.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Registry resmi yang dioperasikan Flare untuk data provider FTSO, alamat entitas, linkage nodeID P-Chain, dan flag kondisi minimum FIP-10. Sumber utama untuk data Operator Quality dan reliability kami.
Flaremetrics ↗https://flaremetrics.io
Provider metrik ekosistem Flare independen. Sumber scoring provider FTSO, tingkat reward, metrik akurasi, flag partisipasi protokol V2, dan pemetaan alamat validator-ke-entitas. Kami mengonsumsi REST API publik mereka.
Flare Foundation reward-scripts repo ↗https://github.com/flare-foundation/reward-scripts
JSON per-reward-epoch yang dipublikasikan oleh Flare Foundation menunjukkan kelayakan per-validator, kelayakan uptime, dan reward yang dikirimkan. Mendorong dimensi Delivery Reliability dan rasio epoch-eligibility v3.4 untuk Uptime.
Flare Block Explorer ↗https://flare-explorer.flare.network
Browser baca-saja untuk semua status on-chain. Memungkinkan siapa saja memverifikasi event RewardClaimed V2 RewardManager (claimType=3 untuk MIRROR), total stake validator, perubahan biaya, dan lainnya.
Flare Portal (staking) ↗https://portal.flare.network/staking
Antarmuka staking resmi. Sumber otoritatif untuk jumlah self-bond / delegated stake saat ini dan waktu akhir validator yang mengisi pembacaan P-Chain RPC kami.
Flaremetrics public API (penyedia FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Endpoint eksak yang cron kami konsumsi, mengembalikan profil entitas, skor FTSO, biaya, dan nodeId dalam format hex. Siapa saja dapat mengaksesnya langsung.
Flaremetrics public API (pendaftaran node) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Tabel konversi Hex → cb58 NodeID. Kami memisahkan ini untuk membangun pencarian entitas-ke-NodeID yang mendorong setiap konsumen format cb58.
Tidak ada data pribadi, tidak ada model sumber tertutup. Algoritma scoring diimplementasikan dalam services/validators/scoring.ts dalam basis kode FlareWatch. Operator atau peneliti yang ingin memeriksa implementasi secara langsung (bukan membaca prosa + formula di atas) — atau yang ingin memforking untuk penggunaan mereka sendiri — dapat mengirim email ke [email protected] untuk meminta akses. Kami akan menerbitkan file sebagai paket open-source standalone jika ada permintaan nyata.
Bagaimana skor diperbarui
Cron di /api/cron/refresh-validators menghitung ulang skor setiap validator aktif setiap 5 menit. Input (pembacaan P-Chain RPC, Flaremetrics, FSE, reward-scripts) diambil segar di setiap penjalankan.
v3.5 menambahkan smoothing di seluruh 4 snapshot cron terakhir (bobot: 0,5 / 0,3 / 0,15 / 0,05), sehingga skor yang ditampilkan tidak berfluktuasi pada noise input transien. Skor yang dihitung cron mentah masih disimpan untuk matematika smoothing masa depan, dan panel breakdown skor menampilkan nilai saat ini setiap dimensi sehingga Anda dapat melihat apa yang berubah.
Versi algoritma dicap pada setiap record skor yang di-cache. Ketika kami mengirimkan versi baru, setiap skor mendapatkan tag baru. Kartu Versions di bawah mendokumentasikan setiap perubahan.
Model penalti Flare

Flare tidak melakukan slash pada stake validator. Seluruh mekanisme penalti untuk perilaku validator yang salah adalah forfeiture reward ditambah sistem passes FIP-10. Tidak ada double-signing slash, tidak ada equivocation slash, tidak ada event perusakan stake yang perlu kami lacak. Validator yang gagal kondisi minimum FIP-10 kehilangan reward epoch itu (forfeit penuh jika di nol passes, jika tidak kehilangan satu pass per protokol yang mereka gagalkan); principal stake mereka tetap utuh.

Itu berarti skor tidak memiliki dimensi "slashing history" — tidak ada riwayat seperti itu yang perlu dilacak. Yang KAMI lacak adalah konsekuensi dari setiap kegagalan minimum: validator menghasilkan nol di epoch itu, yang ditangkap dalam epochsIncluded / epochsObserved. Update v4.2 pada 2026-05-14 memperluas multiplier keandalan skor untuk menggunakan rasio itu di seluruh set minimum FIP-10 (uptime, FSP signing, tingkat submisi FTSO, partisipasi FDC) sehingga validator yang gagal minimum apa pun secara proporsional dihukum di dimensi Uptime terlepas dari sumbu mana yang gagal.

Ambang batas minimum FIP-10, bersumber dari dev.flare.network/network/fsp/rewarding: staking memerlukan uptime 80% + self-bond aktif 1M FLR; feed anchor FTSO memerlukan estimasi dalam 0,5% dari median konsensus di 80% putaran; feed block-latency FTSO memerlukan pengiriman 80% pembaruan yang diharapkan; FDC memerlukan partisipasi dalam 60% putaran voting. Validator yang memenuhi lantai uptime 80% + self-bond 1M tetapi di bawah ambang batas earning 3M / 15M masih menerima reward tetapi tidak dapat mengakumulasi passes — zona abu-abu yang ditampilkan melalui kartu passEligibility: "at-risk" ini.

Versi
v4.8 (2026-09-17) — Epoch reward ditahunan dengan panjang sesungguhnya. Setiap suku validator terukur (APR tersampaikan, delegasi, MIRROR, imbal hasil obligasi mandiri operator) ditahunan dengan epoch reward 3,19 hari, nilai yang ditambahkan pada 2026-04-04 dan dideskripsikan sebagai terukur dari timestamp blok meskipun tidak ada yang mengukurnya. Epoch reward Flare tepat 3,5 hari — rewardEpochDurationSeconds FlareSystemsManager mengembalikan 302.400 dan setiap awal epoch on-chain berjarak 3,500 hari — sehingga setiap suku terukur terbaca sekitar 9,7% lebih tinggi selama lima setengah bulan, termasuk milik kami. Panjangnya sekarang dibaca dari kontrak tersebut. Setiap APR terukur turun dengan faktor yang sama, 3,19 ÷ 3,5 (median jaringan 9,08% → 8,28%; FlareWatch 8,17% → 7,45%). Skor: hanya Delivery Reliability bergerak, karena membandingkan suku terukur dengan suku teoritis untuk biaya validator. Sisi yang mengembung telah menempatkan 91% validator di batas 1,0, yaitu tampaknya membayar lebih dari yang mungkin; dengan panjang epoch sebenarnya rasio delivered-to-theoretical median adalah 0,990. Disimulasikan atas 168 validator dengan data terukur sebelum peluncuran: median −0,32 poin, 146 kehilangan di bawah 1 poin, 13 yang sudah memberikan di bawah suku yang tersirat biayanya kehilangan 2–3,5. Fallback kesederhanaan Community Trust longevity mengonversi epoch menjadi hari dengan panjang yang sama dan juga dikoreksi; tidak menggerakkan skor apa pun, karena paling banyak melihat 8 epoch (28 hari), di bawah langkah 30 harinya dalam kedua arah. Attestasi performa yang ditandatangani menggunakan panjang salah yang sama; spesifikasi recompute direvisi ke rev.3 dan rev.2 disimpan verbatim dengan kesalahan yang diungkapkan.
v4.7 (2026-08-19) — Self-bond dua-sumbu dalam dimensi Community Trust. Trust mengakui self-bond operator hanya sebagai RASIO (bond sendiri ÷ total stake), jadi self-bond besar yang diencerkan oleh delegasi mencetak sama seperti bond tiny pada rasio itu — skor itu buta terhadap modal aktual yang dikomitkan. Di seluruh jaringan live 61 dari 178 validator memegang ≥10M self-bond pada rasio <10%, jadi sepertiga lapangan tidak mendapat kredit yang sepatutnya. v4.7 mengakui self-bond dengan YANG LEBIH BAIK dari bagian proporsional (≥10% → +2, 5–10% → +1, tidak berubah) ATAU ukuran absolut (min(1, selfBond ÷ 20M) × 2, jenuh pada bond desil teratas P-chain jaringan), mengambil max dan masih membatasi sub-sinyal pada +2 — batas Trust (11) dan batas komposit (100) tidak berubah, dan lantai hollow sub-FIP-10 (<1M FLR → −1) tidak berubah. Mencerminkan self-bond dua-sumbu yang sudah digunakan skor penyedia FTSO. Before/after seluruh lapangan atas semua 178 validator, diarsipkan sebelum dikirim: 58 naik, tidak ada turun, tidak ada skor yang naik lebih dari satu poin, dan teratas leaderboard tidak berubah. Node kami sendiri naik satu poin (83 → 84) dengan aturan yang sama seperti setiap operator bermodal besar lainnya — tidak ada istilah yang menyebutkan kami.
v4.6 (2026-08-13) — Bonus magnitude terkirim MIRROR. Dimensi MIRROR dulu hanya menskor passthrough (fraksi MIRROR yang mencapai delegator, = 1 − fee) dan status partisipasi — itu buta terhadap JUMLAH terkirim. Validator yang membayar rate MIRROR terkirim (mirrorAPY, net of fee) jauh lebih tinggi dari lapangan tidak mendapatkan credit untuk itu, jadi node yield-lebih tinggi asli bisa ranking di bawah satu yield-lebih rendah pada dimensi yield. v4.6 menambahkan bonus kecil, dibatasi, yang dipasok median: hanya untuk validator mirror-active, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2). Hanya delivery di atas 1,2× rate median jaringan yang mendapatkannya, dan maksimal di +2, menaikkan ceiling dimensi MIRROR dari 10 ke 12 (komposit masih clamped di 100). Itu dipasok ke rate RATE jaringan median, bukan volume, jadi netral ukuran menurut konstruksi: di seluruh lapangan langsung bonus berkorelasi NEGATIF dengan self-bond (itu mendukung validator kecil yang memberikan rate tinggi, bukan yang besar). Sebelum-dan-sesudah di seluruh lapangan di atas semua validator aktif diarsipkan sebelum pengiriman — sebagian besar validator tidak bergerak, dan puncak leaderboard tetap tidak berubah. Formula yang sama berlaku untuk setiap validator, node kami sendiri termasuk.
v4.5 (2026-07-16) — Penalti viabilitas biaya ekstrem. Dimensi Fee Reasonableness jenuh pada 0/7 setelah biaya melebihi anchor pasar + 20 poin (~40% pasca-Granite); dari sana hingga biaya 100% komposit berhenti merespons biaya sama sekali, sehingga validator dengan biaya 100% — di mana delegator tidak mendapatkan apa pun — masih mendapat skor di angka 40-an pada dimensi yang buta terhadap biaya. Pada skor yang menghadap delegator, hasil itu hampir diskualifikasi, bukan pertengahan tabel. v4.5 menambahkan penalti komposit yang diterapkan sebagai fraksi dari total dimensi positif: nol pada atau di bawah biaya 50% (tanpa penghitungan ganda dalam jangkauan yang sudah dinilai oleh dimensi Fee), kemudian meningkat secara linear hingga 75% dari skor pada biaya 100%. Node dengan biaya 100% mencapai sekitar 10/100 — tetap terdaftar dan peringkat, jelas bukan kandidat delegasi. Ini adalah fungsi murni dari biaya on-chain, identik untuk setiap validator, termasuk node kami sendiri.
v4.4 (2026-07-11) — Anchor biaya yang sadar lantai Granite. Hard fork Granite (Flare, 2026-07-14) menerapkan biaya delegasi validator minimum 20%. Anchor Kelayakan Biaya menjadi max(biaya aktif minimum yang diamati, lantai protokol): setiap biaya pada atau di bawah minimum legal mendapat nilai penuh, dan hanya biaya di atasnya yang dihukum, berdasarkan jarak. Rasional: dengan grandfathering dari stakes dalam penerbangan yang tidak ditentukan upstream, penambatan ke relique grandfathered 2% (atau 0% pra-fork) akan memberi skor operator 20% yang sesuai protokol sebagai hampir-ekstraktif — dan menghitung dua kali delta biaya yang Net Yield sudah hargai dalam istilah yang disampaikan. Tidak ada dimensi lain yang berubah. Ketika seluruh kohort mencapai lantai, dimensi memberikan nilai penuh secara seragam — biaya berhenti dihitung setelah tidak ada yang bisa bersaing berdasarkannya.
v4.3 (2026-05-14) — Active Outage Penalty ditambahkan sebagai pengurangan post-dimensi flat. Multiplier uptimeReliability yang ada adalah simetris — 5 miss yang tersebar di 24 epoch biaya yang sama seperti 5 miss berturut-turut — tetapi secara operasional itu adalah sinyal yang sangat berbeda: miss yang tersebar berarti kekurangan keandalan kronis, streak berarti validator rusak SEKARANG. v4.3 membaca jalankan berdampingan dari epoch !eligible di kepala riwayat partisipasi validator baru-baru ini dan mengurangi 0 poin untuk 0–1 miss berturut-turut (varian normal / single transient miss), 3 poin di 2 (berkembang outage), 6 poin di 3 (sustained outage), dan 10 poin di 4+ (active extended outage), dengan composite di-floor pada 0. Berlapis di atas — bukan mengganti — multiplier keandalan, karena keduanya menangkap bahaya yang berbeda. Pemicu: insiden kelas Luganodes pada 2026-05-14, di mana beberapa epoch baru-baru ini terlewat secara berturut-turut sementara delegator secara aktif melakukan commit stake; sinyal streak membiarkan delegator melihat kegagalan in-flight sebelum melakukan commit. Penalti dirender sebagai bagian mereka sendiri dalam panel breakdown skor sehingga 9 dimensi positif masih berjumlah 100.
v4.2 (2026-05-14) — DUA perbaikan terkait, dikirim bersama sebagai respons atas koreksi publik dari AU (@aucc_official) tentang skor Luganodes. (1) komputasi deliveredAPY sekarang mengalikan rate-per-earning-epoch dengan `epochsIncluded / epochsObserved` sehingga APR yang ditampilkan mencerminkan tingkat EFEKTIF yang benar-benar diterima delegator selama jendela observasi — termasuk epoch penghasilan nol ketika validator gagal minimum FIP-10. Implementasi sebelumnya rata-ratakan hanya epoch penghasilan dan menunjukkan validator tingkat epoch baik mereka, menyembunyikan kegagalan minimum. (2) Multiplier keandalan dimensi Uptime meluas dari uptime-only (epochsUptimeEligible / epochsObserved) ke set minimum FIP-10 penuh (epochsIncluded / epochsObserved). Validator dengan uptime RPC 100% yang gagal FSP signing atau tingkat submisi FTSO sekarang mengambil pukulan proporsional pada dimensi Uptime terlepas dari minimum mana yang mereka lewatkan. Efek bersih pada Luganodes khususnya: deliveredAPY turun dari 10,86% menjadi ~5,43% (sesuai dengan realitas half-paying aktual), keandalan uptime turun dari 1,0 menjadi 0,5, skor turun secara material. Koreksi yang sama berlaku untuk setiap validator dengan `epochsIncluded < epochsObserved` — di seluruh jaringan ini menampilkan celah kualitas partisipasi nyata yang sebelumnya tersembunyi.
v4.1 (2026-05-14) — Dimensi Net Yield beralih dari APR teoritis (formula: gross_APR × (1 − fee)) ke deliveredAPY TERUKUR dari Flare Foundation reward-scripts, dengan fallback teoritis per-validator hanya ketika tidak ada riwayat pengukuran yang ada. Pemicu: pengurangan inflasi FIP-16 (5% → 3%) go live 2026-05-14, dan penyebut eligible-stake formula teoritis bergeser dari realitas on-chain sehingga APR teoritis under-reported delivered yields sebesar ~2× di seluruh jaringan. Beralih ke measured-first menyelaraskan kembali input skor dengan apa yang benar-benar diterima staker. Jangkar networkMedianAPR juga diperhitungkan ulang menggunakan metodologi measured-first yang sama sehingga perbandingan rasio tetap konsisten di kedua sisi — skor seharusnya kira-kira stabil (validator pada median jaringan masih mencetak ~12/18, dll.), hanya berdasarkan tingkat delivered nyata daripada output formula.
v4.0 (2026-05-11) — Versi besar. Siklus v3.7-v3.10 secara kumulatif merupakan penulisan ulang struktural dari sistem scoring, cukup besar untuk menjamin bump. Ringkasan: dua dimensi memiliki cap mereka berubah (Trust 10→11, Capacity 8→7); formula Operator Quality ditulis ulang menjadi max(verification, FTSO-derived) sehingga partisipasi tidak dapat merugikan; empat dimensi bucketed yang tersisa (Uptime, Fee, Delivery, Time Remaining) dilinearkan untuk menghilangkan tebing boundary; tiga komponen skor baru ditambahkan (retensi delegasi 30 hari, lintasan self-bond 30 hari, auto-promotion ke tier curated); aggregasi operator multi-node diperkenalkan untuk Trust count + concentration; longevity sekarang wipe-immune melalui reward-scripts epoch presence; dan dua perverse incentives dihilangkan (penalti partisipasi FTSO Operator Quality dan tebing inverted-V uptime 95%). Setiap input untuk skor sekarang dapat diverifikasi secara eksternal — tidak ada keputusan editorial yang sedang dimuat. Validator dapat memperoleh baseline operator +7 curated melalui perilaku yang dapat diamati (90+ hari diamati, 25+ delegator, retensi tidak menurun, FIP-10-compliant self-bond), tidak perlu email-the-team required. Lihat entri v3.7-v3.10 di bawah untuk perubahan granular yang membentuk release ini.
v3.10 (2026-05-11) — Ditutup celah kurator terakhir dalam skor. Baseline operator +7 curated pada Operator Quality sebelumnya memerlukan hand-inclusion dalam daftar KNOWN_VALIDATORS kami, yang merupakan satu-satunya keputusan editorial yang bermakna yang tersisa setelah siklus audit v3.7-v3.9. v3.10 menambahkan jalur auto-promotion objektif: validator apa pun dengan observasi FlareWatch 90+ hari, delegator 25+ operator-aggregated, retensi tidak menurun (drop 30 hari ≤ 15%), dan FIP-10-compliant self-bond secara otomatis memenuhi syarat untuk baseline +7 — tidak diperlukan review manual. KNOWN_VALIDATORS tetap sebagai fast-track untuk operator institusional yang belum mengumpulkan jendela 90 hari (pikirkan masuk Ankr atau Kiln launch-day), tetapi kasus tipikal sekarang sepenuhnya otomatis. Keempat kriteria adalah on-chain-derived atau near-on-chain (delegator count, retensi, self-bond) ditambah timestamp observasi kami sendiri — tidak ada yang subjektif, tidak ada email-the-team gating. Efek bersih: validator dapat memperoleh tier +7 melalui perilaku saja. Sebagian besar operator yang sudah mapan di jaringan sudah memenuhi kriteria hari ini.
v3.9 (2026-05-11) — Pembersihan tebing boundary di empat dimensi bucketed yang tersisa, setelah mengaudit setiap bagian dari skor untuk keadilan. Diperbaiki: (1) tebing inverted-V perverse di kurva Uptime pada 95% — pergi dari 94,99% → 95,00% uptime kehilangan 4 poin (cabang 95-99% dimulai pada 0 bukan matching max cabang lebih rendah 4). Bentuk backward incentive yang sama yang baru saja kami perbaiki di Operator Quality (v3.8). (2) Ambang Reasonableness Fee dilinearkan — pre-v3.9, kenaikan biaya 0,01% di seluruh boundary bucket dapat kehilangan hingga 2,5 poin. Sekarang piecewise linear dengan slope yang semakin curam melestarikan nilai bucket di boundary (biaya rendah hampir tidak dihukum, biaya extractive dihukum keras). (3) Ambang deliveryRatio Delivery Reliability dilinearkan — pola yang sama, hingga 2-point cliffs dihilangkan. (4) Ambang bucket Time Remaining dilinearkan — cliffs yang lebih kecil (max 2 poin di boundary 14 hari) tetapi masih ada di dimensi kecil; sekarang smooth. Net Yield, MIRROR Participation, dan Capacity Profile diaudit dan dikonfirmasi fair-as-is (sudah linear/continuous). Total cap tidak berubah di 100. Tidak ada regresi skor berdasarkan desain; validator hanya skor mereka bergerak adalah mereka yang kebetulan duduk tepat di tepi bucket sebelumnya.
v3.8 (2026-05-11) — Dimensi Operator Quality diaudit dan ditulis ulang setelah review keadilan. Tiga perbaikan dikirim bersama. (1) Dihilangkan incentive perverse — operator yang dikenal dengan skor FTSO mid-tier (mis. 50) mencetak 4 poin, tetapi operator yang sama keluar dari FTSO sepenuhnya mencetak 7 poin. Di bawah v3.8 skor adalah max(verification baseline, FTSO-derived), sehingga partisipasi FTSO hanya dapat membantu, tidak pernah merugikan. (2) Diperkenalkan tier verifikasi menengah — operator dengan nama yang auto-discovered dari Flaremetrics atau FSE (tetapi belum dalam peta KNOWN_VALIDATORS curated) mendapatkan +3 bukan 0, melembagakan tebing 7→0 sebelumnya. (3) Surfaces kedua sinyal dalam detail breakdown ketika verification menang atas skor FTSO rendah (mis. "Curated operator · FTSO 45") sehingga operator memahami dengan tepat tempat skor mereka berasal. Cap 12-pt tidak berubah; tidak ada rebalance yang diperlukan karena perubahan hanya melebarkan distribusi skor di bagian bawah (memberi penghargaan verifikasi parsial) tanpa mengubah bagian atas.
v3.7 (2026-05-11) — Dimensi Community Trust diaudit dan diperluas setelah review operator-fairness. Tiga penambahan: (1) Aggregasi operator multi-node — operator menjalankan beberapa node P-Chain (AU, FlareBus, Aureus Ox, Kiln, dll.) sekarang memiliki delegator count dan total stake mereka diagregasi untuk sinyal Trust count + concentration, sehingga mereka tidak dihukum karena mendistribusikan basis delegator yang sama di beberapa node. (2) Sinyal retensi delegasi 30 hari (±0,5 poin) — membedakan validator yang tumbuh / stabil / menyusut menggunakan perbandingan sliding-window. Dimensi Trust snapshot-only tidak bisa membedakan ini pre-v3.7. (3) Lintasan self-bond 30 hari (±0,5 poin) — menghargai operator yang meningkatkan self-bond mereka seiring waktu, menghukum mereka yang diam-diam membatalkan. Berbeda dari penalti perubahan tiba-tiba yang hanya menangkap drops besar tunggal. Cap reseimbang: Trust 10 → 11, Capacity 8 → 7. Bug fixes dari audit: (a) self-bond nol sekarang dengan benar menekan penalti sub-FIP-10 (sebelumnya gate `selfBondFLR > 0` membiarkan exactly-0 self-bond lolos dari −1). (b) rasio self-bond kecil antara lantai FIP-10 dan 5% sekarang render persentase aktual dalam panel breakdown sehingga operator melihat apa yang menutup gap ke tier +1 / +2. (c) bonus longevity sekarang wipe-immune — falls back ke reward-scripts epoch presence ketika first-observed KV secara artifisial fresh.
v3.6 (2026-05-11) — Dua perbaikan untuk deteksi MIRROR, dikirim bersama. (a) Deteksi sekarang membaca dari dua sumber kanonik: event RewardClaimed on-chain(claimType=3) dari V2 RewardManager DAN alokasi claimType=3 dalam Merkle JSON FSP resmi (data yang sama yang alat signing Flare sendiri konsumsi). Sinyal apa pun sudah cukup — menangkap validator yang MIRROR sudah dialokasi tetapi belum diklaim on-chain. (b) Cross-checking terhadap Merkle mengungkapkan bug format kunci terpisah: validators:mirror-stats memiliki kunci NodeID hex20/cb58 campuran (indexer on-chain menulis hex ketika validator belum dalam daftar nama curated kami), sementara setiap konsumen UI mencari hanya oleh cb58 — jadi ~95 validator status tidak terlihat untuk display. Lookup sekarang menormalisasi kedua format di seluruh tabel validator, panel breakdown skor, mirror-stats public API, halaman Yield Kartu Staking Positions, dan panel penyedia FTSO. Validator yang terpengaruh melihat dimensi MIRROR Participation + Operator Quality mereka dan FlareWatch Score keseluruhan naik 9-10 poin pada siklus cron berikutnya. Ditemukan melalui laporan penyedia FTSO (FlareBus, 2026-05-11) — kredit dan terima kasih. Umpan balik mereka secara material meningkatkan pandangan setiap delegator tentang jaringan, bukan hanya skor mereka sendiri.
v3.5 (2026-05-09) — Net Yield sekarang median-anchored terhadap APR jaringan (validator pada median mencetak 12/18, top performers mencapai 18, bottom-quartile turun ke 0). Dimensi Trust menyerap alignment self-bond sebagai komponen keempat (self-bond proporsional menghargai skin-in-the-game; sub-lantai FIP-10 mengambil penalti kecil). Badge "NEW Xd" baru menampilkan validator FlareWatch hanya diamati selama <30 hari sehingga staker dapat melihat ketika track record tipis.
v3.4 (2026-05-09) — Dimensi Uptime sekarang mencampur uptime RPC instan dengan rasio kelayakan epoch historis FIP-10. Pre-v3.4 dimensi tidak diskriminatif (92,9% validator memiliki uptime RPC 100%). Rasio keandalan yang diturunkan dari epochsUptimeEligible / epochsObserved di seluruh 8 epoch reward-scripts terakhir — sinyal time-series yang bermakna membedakan validator yang sesekali gagal kondisi minimum FIP-10 dari yang tidak.
v3.3 (2026-05-09) — Dimensi Delivery sekarang menggunakan tingkat mean waktu-weighted secara eksponensial (epoch baru-baru ini menghitung lebih banyak, konstanta decay 0,85) dan menerapkan penalti varians (coefficient of variation × 0,5, di-cap pada −30%). Dihitung dari data reward-scripts per-epoch — ukuran sampel membawa melalui sebagai dampener kepercayaan yang ada.
v3.2 (2026-05-09) — Multi-signal Community Trust (count + concentration + longevity); pelacakan first-observed-by-FlareWatch persisten dalam KV untuk bonus longevity; edge-case stake-end (validator dalam 14 hari dari expiry skor 0 pada Time Remaining karena mereka tidak dapat menerima delegasi baru di bawah FIP-10); halaman methodology dibuat publik; saluran feedback operator ditampilkan; versi algoritma dicap pada setiap record skor cache.
v3.1 (2026-05-09) — Wired Delivery dimension dari reward-scripts data; smoothed Operator Quality (linear interpolation), Capacity (tent function), dan Trust (log scale); reclassified FSP-known + zero claimType=3 sebagai MIRROR "inactive" bukan "no data"; persisted scoreBreakdown server-side jadi client tidak recompute tanpa full inputs.
v3 (2026-05-09) — Mengganti bonus identity biner dengan Operator Quality berkelanjutan. Ditambahkan MIRROR Participation sebagai dimensi dedicated dengan fee passthrough. Membuat kapasitas capped netral bukan penalti 0-pt. Menghapus double-count APY/fee melalui Net Yield. Dikalibrasi ulang band (Top tier 90+, Strong/Good/Acceptable/Below median).
v2 (pre-2026-05-09) — Skor 8-dimensi original (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). Pensiun karena double-count APY/Fee, penalti identity biner, penalti kapasitas capped, tidak ada dimensi MIRROR. Didokumentasikan untuk referensi historis.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.