Metodologi Skor Penyedia FTSO

Versi algoritma: v4.11 · Terakhir diperbarui: 2026-07-04

FlareWatch memberikan setiap penyedia data FTSO skor komposit 0–100 di seluruh 12 dimensi terukur. Matematikanya deterministik, input adalah data on-chain publik dan ekosistem Flare[Flaremetrics] [FSE] [Flare Explorer], dan algoritma yang sama berlaku untuk setiap penyedia — termasuk penyedia FTSO FlareWatch sendiri, yang dicore oleh fungsi eksak ini tanpa perlakuan khusus. Halaman ini mendokumentasikan setiap dimensi dan threshold sehingga delegator dan operator dapat melihat dengan tepat bagaimana skor dihitung dan mengapa setiap nilai dipilih. Setiap klaim di sini menghubungkan kembali ke sumber upstream utamanya — lihat Sumber & referensi di bagian bawah.

Ruang lingkup: halaman ini mendokumentasikan skor penyedia FTSO — apa yang Anda lihat dalam delegation mode di halaman validator (mendelegasikan WFLR ke penyedia data FTSO untuk bagian inflasi FTSO). Skor validator yang ditampilkan dalam staking mode (mendelegasikan FLR ke validator P-Chain untuk reward VRM + MIRROR) menggunakan algoritma 9-dimensi terpisah yang berfokus pada operasi validator — uptime, fee, keandalan, dll. Ini adalah peran on-chain yang berbeda dengan reward yang berbeda, dinilai secara terpisah. Lihat Validator Score Methodology untuk sisi staking.
Cakupan rantai FLR / SGB: tab Delegation di halaman validator memiliki toggle FLR / SGB untuk dompet yang memegang Songbird (SGB) apa pun. Metodologi ini mendokumentasikan skor sisi FLR saja. Penyedia FTSO Songbird terdaftar tanpa skor komposit — data akurasi / konsistensi / hadiah FSP yang sama yang kami gunakan untuk FLR belum terhubung ke pipeline Songbird kami (Flaremetrics, sumber data FLR utama kami, tidak mencakup Songbird). Apa yang delegator SGB lihat hari ini: nama penyedia + logo dari registri TowoLabs lintas jaringan, bobot saat ini (WSGB didelegasikan, dibaca langsung dari kontrak WNat Songbird melalui RPC Songbird kami sendiri), dan URL penyedia. Urutkan berdasarkan bobot; bobot yang lebih besar adalah sinyal proxy hingga data akurasi tersedia. Ketika kami menghubungkan pipeline akurasi Songbird + reward-rate, formula 13-dimensi yang sama akan diterapkan ke penyedia SGB — tidak ada algoritma penilaian baru, hanya formula FLR yang dihitung terhadap data Songbird. Penilaian validator FlareWatch (tab staking) tidak memiliki padanan SGB sama sekali: set validator P-Chain Songbird terbatas pada entitas yang disetujui Flare Foundation, jadi delegasi P-Chain SGB retail jarang terjadi dan tab staking tetap FLR-only.
Band skor
90+Tingkat teratas — teratas ~10–20% penyedia FTSO. Profil tipikal: tingkat reward di atas median, akurasi tinggi, partisipasi protokol V2 penuh (FTSO Scaling + Fast Updates + FDC), fee rendah/nol, basis delegator besar, node validator yang membayar MIRROR, merek bernama. Tidak ada dimensi tunggal yang diperlukan — penyedia mencapai tingkat teratas dengan mengumpulkan kekuatan di sebagian besar kategori.
80–89Kuat — memenuhi sebagian besar benchmark utama; satu atau dua dimensi kurang dari tingkat teratas.
70–79Baik — memenuhi semua kriteria baseline; tidak ada celah besar.
60–69Dapat diterima — dapat digunakan tetapi tidak terdiferensiasi.
<60Di bawah median — celah signifikan di satu atau lebih dimensi. Fakta matematis, bukan penilaian kualitas.
Dimensi (bobot mentah — total 172, dinormalisasi ke 100)
"Active" mengatur dua dimensi (Fee dan V2 Participation): penyedia yang tidak berjalan seharusnya tidak mengumpulkan kredit untuk mengiklankan biaya rendah. Penyedia dihitung sebagai aktif jika memiliki tingkat reward yang dipublikasikan atau jika data reward Flare Systems Protocol menunjukkan pembayaran dalam setidaknya satu epoch dari jendela penilaian. Hingga 2026-07-31 hanya tingkat reward saja, yang berasal dari satu API pihak ketiga — jadi penyedia yang API itu tidak cover mendapat skor nol pada kedua dimensi sementara secara terlihat mendistribusikan reward setiap epoch. Activity adalah properti penyedia, bukan siapa yang kebetulan mencantumkannya.
Tingkat Reward25 pts maks
Apa: Tingkat reward penyedia per epoch, diperkuat ke median jaringan.
Bagaimana: rasio = providerRate / medianRate. Linear: rasio 1,0 (median) → 12,5 poin, rasio 2,0 → 25 poin (batas). Penyedia tidak aktif (rewardRate ≤ 0) → 0. v4.0 (2026-05-11): batas didasarkan ulang sehingga median = setengah dari poin dimensi (bukan 40% seperti sebelumnya).
if (rate <= 0 || medianRate <= 0): score = 0
else:
  ratio = rate / medianRate
  score = min(25, round(ratio * 12.5 * 10) / 10)   // 1 decimal place

// Anomaly detection: providers > 3× the median are capped at
// median × 3 for scoring purposes (prevents data outliers from
// distorting the linear curve).
Mengapa: Tingkat reward adalah #1 hal yang dialami delegator. Jangkar median membuat skor tetap jujur saat ekonomi reward jaringan bergeser — penyedia pada 1,2× median di era reward rendah masih peringkat sama dengan satu pada 1,2× di era reward tinggi. Batas dan filter anomali mencegah pencilan epoch tunggal mendominasi.
Akurasi25 pts maks
Apa: Akurasi harga FTSO dari Flare Systems Explorer (FSE) — tingkat landing pita reward primary (IQR ketat) dan secondary (lebih luas).
Bagaimana: Campuran 40/60 dari tingkat landing pita FTSO PRIMARY (IQR ketat) dan SECONDARY (lebih luas) (v4.8), mencerminkan pembagian reward Flare sendiri — FIP.11 membayar reward anchor-feed 40% primary / 60% secondary. Secondary menggunakan kurva piecewise sebelumnya (97% → 25 … 70% → 2); itu hampir jenuh di seluruh lapangan (95–99%), jadi itu hampir tidak membedakan. Primary menggunakan kurva linear absolut — 28% → 0 hingga 78% → 25 penuh — sehingga engineering pita-ketat yang jauh lebih sulit, di mana penyedia benar-benar tersebar dari ~28% hingga ~80%, adalah apa yang memisahkan lapangan. Anchor tetap (bukan persentil lapangan), sehingga skor tetap dapat diturunkan kembali dari input penyedia sendiri. Fallback single-band ketika hanya satu yang tersedia; neutral 12.5 ketika tidak ada data FSE.
if (fseAccuracySecondary > 0):
  pct = fseAccuracySecondary / 100
  if (pct >= 97) score = 25
  elif (pct >= 95) score = 18 + (pct - 95) * 3.5     // 95 → 18,  97 → 25
  elif (pct >= 93) score = 16 + (pct - 93) * 1       // 93 → 16,  95 → 18
  elif (pct >= 90) score = 13 + (pct - 90) * 1       // 90 → 13,  93 → 16
  elif (pct >= 85) score = 10 + (pct - 85) * 0.6     // 85 → 10,  90 → 13
  elif (pct >= 80) score = 6  + (pct - 80) * 0.8     // 80 → 6,   85 → 10
  else              score = max(0, 2 + (pct - 70) * 0.4)
elif (fseAccuracyPrimary > 0):
  // Primary fallback: similar piecewise linear curve.
else:
  score = WEIGHT_ACCURACY / 2   // Neutral — no FSE data
Mengapa: Epoch yang terlewat = pendapatan reward yang hilang untuk delegator. Akurasi menentukan apakah pengajuan penyedia benar-benar dihitung untuk konsensus FTSO, dan metrik sekunder (yang memberi bobot lebih banyak pada epoch terbaru) adalah yang pemetaannya paling bersih ke kinerja saat ini.
Konsistensi20 pts maks
Apa: Seberapa stabil tingkat reward penyedia di seluruh epoch penghasil paling recentnya.
Bagaimana: Volatilitas penurunan di seluruh epoch penghasilan terbaru penyedia, diukur hanya antara epoch yang benar-benar berurutan — epoch tempat penyedia tidak memperoleh apa pun tidak meninggalkan catatan, dan dua epoch di kedua sisi celah tersebut tidak pernah dibandingkan satu sama lain. Hanya penurunan epoch-over-epoch yang dihitung — kenaikan berkontribusi nol — jadi tarif yang stabil atau naik mendapat skor hampir penuh dan pemulihan meningkatkan skor saat terjadi. Penurunan diagregasi RMS sehingga penurunan yang tajam berbobot lebih dari yang ringan, dan tertimbang ke arah pasangan baru (decay 0,8) sehingga pemulihan aktif meningkatkan skor sementara penurunan lama hilang. cv = 0 → 20 poin; cv ≥ ~0,167 → 0. Netral 10 ketika ada lebih dari 3 pasang epoch berurutan dalam 12 epoch penghasilan terakhir.
earned = last 12 epochs where rewardRate > 0, keyed by epochId
pairs  = [earned[i-1], earned[i]] where epochId[i] - epochId[i-1] == 1
if (pairs.length < 3) return 10        // Neutral — too few consecutive pairs

// DOWNSIDE volatility only: rises never hurt, so a stable or RISING
// rate scores near full and a recovery lifts the score. Only drops
// between CONSECUTIVE epochs count, in proportion to depth (RMS),
// weighted toward recent pairs so an active recovery pulls the score up.
drops[i] = max(0, (prev - cur) / prev)     // rise -> 0
w[i]     = 0.8 ^ (age of pair)             // newest pair = highest
cv       = sqrt( sum(w[i] * drops[i]^2) / sum(w[i]) )
score    = max(0, round((1 - min(1, cv * 6)) * 20 * 10) / 10)
Mengapa: Dua penyedia dengan tingkat reward rata-rata yang sama dapat memberikan pengalaman staker yang sangat berbeda: satu yang dip keras lebih buruk daripada satu yang stabil atau naik. Konsistensi memberi reward pada apa yang benar-benar diinginkan delegator — tingkat stabil atau naik — dan hanya menghukum drop, sebanding dengan kedalaman. Tingkat yang naik KEMBALI tidak pernah dihukum (ukuran simetris awal melakukannya, yang terbalik). Dip kuat terbaru mendapat skor rendah kemudian pulih saat habis.
Partisipasi V215 pts maks
Apa: Apakah penyedia menjalankan stack V2 modern (FTSO Scaling + Fast Updates + FDC).
Bagaimana: Stacking per-protokol. Baseline aktif (rewardRate > 0) +3, V1 parsial (submit + signing + voter) +4, setiap protokol V2 (FTSO Scaling / Fast Updates / FDC) +~2,67 masing-masing, batas 15. Tidak aktif → 0. v4.0 (2026-05-11) membagi tier all-or-nothing sebelumnya (di mana V1 parsial = V2 penuh = 15 — tidak ada insentif untuk upgrade) menjadi bonus per-protokol yang stack.
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
Mengapa: V2 adalah ke mana jaringan menuju. Stacking per-protokol v4.0 berarti upgrade dari V1 parsial ke V2 penuh sebenarnya memindahkan skor (pra-perbaikan itu tidak — V1 parsial dan V2 penuh keduanya mengembalikan 15). Menambahkan protokol V2 tunggal sekarang meningkatkan dimensi.
Fee15 pts maks
Apa: Fee yang dikenakan penyedia pada reward yang didelegasikan.
Bagaimana: Interpolasi linear di seluruh breakpoint: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0. Penyedia tidak aktif → 0.
anchor = max(lowest active fee observed, protocol fee floor)
// FIP-16 sets a 20% minimum entity fee. All 98 providers charge
// exactly 20%, so the anchor is 20% and nobody is docked for
// charging the only fee the protocol permits. Same curve and
// same anchor the validator page's Fee dimension uses.

if (!isActive) score = 0
d = fee - anchor              // distance ABOVE the best real offer
if (d <= 0)  score = 15       // at or below the anchor → full marks
elif (d <= 5)  score = 15 - d * 0.43
elif (d <= 10) score = 12.9 - (d - 5) * 0.64
elif (d <= 15) score = 9.6 - (d - 10) * 0.86
elif (d <= 20) score = 5.4 - (d - 15) * 1.07
else: score = 0               // extractive
Mengapa: Fee secara langsung mengurangi apa yang diterima delegator. Interpolasi linear (daripada bucket) berarti fee 7% mencetak antara 10% dan 15% daripada snap ke satu bucket — operator tidak mendapat kredit untuk membulatkan fee mereka turun ke batas bucket berikutnya.
Partisipasi MIRROR12 (+3 bonus) pts maks
Apa: Apakah node validator P-Chain operator secara aktif membayar bagian inflasi FTSO kepada staker, plus bonus overperformance.
Bagaimana: Skor dasar berkala secara linear dengan fraksi nodeID operator yang membayar reward MIRROR. Semua node aktif → 12 poin. Parsial → proporsional. Tidak ada → 0. Sejak 2026-05-11, sinyal 'aktif' dibaca dari dua sumber kanonik: event RewardClaimed(claimType=3) on-chain di V2 RewardManager DAN alokasi claimType=3 dalam JSON Merkle FSP resmi — salah satu sudah cukup. Sebelum update kami menggunakan stream on-chain sebagai sinyal satu-satunya, yang menghasilkan false negative untuk provider yang MIRROR settlement-nya melalui jalur klaim non-standar. Plus bonus overperformance hingga +3 poin ketika validator operator secara konsisten memberikan hasil di atas 100% dari yang diharapkan (vrm + mirror) / diharapkan — shrinkage Bayesian dengan gate akrual 30 hari dan minimum sampel 3 stake menjaga operator kecil atau baru agar tidak mengamankan bonus pada beberapa pembacaan beruntung.
if (no fseNodeIDs) score = 0
if (mirrorStatsMap empty) score = 12 / 2 = 6   // Neutral seed before data lands

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

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

avgBonus = sum_per_node(bonus) / fseNodeIDs.length
score = round((base + avgBonus) * 10) / 10
Mengapa: Partisipasi MIRROR adalah apa yang mendelegasikan share inflasi FTSO ke staker Anda. Provider V2-aktif yang node validator-nya tidak membayar MIRROR mengirimkan ~5–15% yield lebih rendah kepada delegator dibanding provider yang sama dengan node aktif. Bonus overperformance menghargai pengiriman konsisten lebih baik dari yang diharapkan tanpa menginflasi operator baru pada sampel kecil — shrinkage Bayesian dan gate akrual 30 hari menjaganya tetap adil.
Jumlah Delegator12 pts maks
Apa: Jumlah dompet unik yang saat ini mendelegasikan ke penyedia ini, dihitung dari state chain.
Bagaimana: Skala log dari 5 → 500 delegator dipetakan ke 0 → 12. ≤5 → 0, ≥500 → 12 (cap). Cocok dengan gaya sinyal count dimensi Trust validator. v4.0 (2026-05-11): memperbaiki bug nyata di mana skema bucket sebelumnya memiliki insentif perverse pada tepat 500 delegator (pra-perbaikan: 500 → 14, 501 → 12 — mendapatkan delegator di perbatasan itu KEHILANGAN 2 poin).
if (count <= 5)   score = 0
elif (count >= 500) score = 12
else:
  ratio = log(count / 5) / log(100)   // maps [5, 500] → [0, 1]
  score = round(min(12, max(0, ratio * 12)) * 10) / 10
Mengapa: Jumlah delegator adalah sinyal trust — independent dari ukuran stake. Provider dengan 200 delegator telah dipilih oleh 200 staker independent; satu dengan 5 telah dipilih oleh dekat operatornya. Skala log memberikan diminishing return melewati ~50 delegator tanpa pernah berbalik (cara bucketed scoring lakukan pra-v4.0).
Partisipasi Epoch10 pts maks
Apa: Apakah provider secara aktif berpartisipasi dalam epoch.
Bagaimana: FSE tandai provider aktif → 10. Provider memiliki rewardRate > 0 (Flaremetrics) tapi tidak ada flag aktif FSE → 7 (aktif per data pasar, konfirmasi FSE hilang). Sebaliknya → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Mengapa: Menangkap provider yang reward stream-nya telah macet meskipun Flaremetrics masih mencantumnya. Berbeda dari Accuracy (yang tentang correctness per-epoch) — Participation tentang menunjukkan diri sama sekali.
Stabilitas Vote Power10 pts maks
Apa: Perubahan persen hari ke hari dalam vote power provider.
Bagaimana: Piecewise linear dalam perubahan persen hari ke hari absolut. <1% → 10. Linear dari 1% → 3% (10 → 7). Linear dari 3% → 5% (7 → 4). Linear dari 5% → 10% (4 → 2). Terus menuju 0 melewati 10%. v4.0 (2026-05-11): linearisasi cliff bucket sebelumnya (dulu hingga cliff 3-poin di setiap threshold).
change = abs(votePowerDailyChangePct * 100)
if (change < 1)  score = 10
elif (change < 3) score = 10 - (change - 1) * 1.5     // 1 → 10, 3 → 7
elif (change < 5) score = 7  - (change - 3) * 1.5     // 3 → 7,  5 → 4
elif (change < 10) score = 4 - (change - 5) * 0.4     // 5 → 4, 10 → 2
else               score = max(0, 2 - (change - 10) * 0.1)
Mengapa: Ayunan besar hari ke hari dalam vote power sering menunjukkan gelombang delegator bergerak masuk atau keluar — staker membaca tabel melihat target bergerak. Vote power stabil menandai provider established dengan delegator sticky.
Compliance10 pts maks
Apa: Apakah provider dibayar di setiap reward epoch SEJAK ia menjadi aktif dalam data reward FSP.
Bagaimana: Penuh 10 poin untuk nol epoch terlewatkan dalam window aktif provider. Setiap epoch terlewatkan mengurangi 3 poin (diklem di 0). Netral 5 ketika data FSP tidak tersedia. v4.4 (2026-06-30): epoch terlewatkan sekarang dihitung hanya dari epoch partisipasi pertama provider maju — provider baru tidak lagi dikenai biaya epoch sebelum ia ada (yang sebelumnya menjaga node baru-tapi-bersih di 0/10 selama berminggu-minggu).
if (no fspData OR totalEpochs <= 0) score = 5

// active window = epochs from the provider's first paid epoch to now
missed = (active-window epochs) - (epochs the provider was paid)
score = max(0, 10 - missed * 3)
Mengapa: Epoch terlewatkan dalam distribusi reward Flare Systems Protocol resmi berarti provider gagal compliance protokol untuk epoch itu — kondisi minimum, signing policy, dll. Menghitung hanya dari partisipasi pertama menjaga ukuran ini adil ke provider baru sambil tetap menghukum miss genuine. Tiga poin per miss sangat curam jadi single miss adalah sinyal terlihat tapi recoverable; ~3 miss mengosongkan dimensi.
Identitas8 pts maks
Apa: Apakah provider memiliki nama brand nyata atau hanya address hex.
Bagaimana: Brand named (≥4 char, tidak dimulai dengan 0x) → 8. Short atau anonymous (<4 char) → 4. Pure hex / alamat 0x sebagai nama → 0.
if (no name) score = 0
elif (name starts with 0x or matches hex regex) score = 0
elif (name.length < 4) score = 4
else score = 8
Mengapa: Provider named telah memilih untuk dapat ditemukan dan accountable — mereka dapat dicari, dihubungi, dan diminta untuk mempertahankan komitmen yang dipublikasikan. Provider anonymous-by-address fungsional tapi menawarkan sinyal trust lebih sedikit ke delegator yang mengevaluasi mereka.
Self-Bond7 pts maks
Apa: Bond P-Chain node MILIK operator (skin in the game) — mengecualikan stake yang didelegasikan orang lain ke node. Gate komitmen size-neutral, bukan ranking kekayaan.
Bagaimana: Dikreditkan pada LEBIH BESAR dari dua sumbu saturating: (1) alignment — bond milik sebagai share dari total committed stake (≥10% → full); atau (2) absolut — modal milik operator berisiko, dicap 5M FLR jadi 5M dan 80M skor sama. v4.4 (2026-06-30): re-sourced dari true P-Chain self-bond operator (validator weight cross-referenced oleh nodeID) — field Flaremetrics sebelumnya yang dibaca itu discontinued, jadi setiap provider telah skor 0. v4.5 (2026-06-30): menambahkan sumbu absolut + saturation jadi self-bond besar pada rasio rendah tidak skor di bawah yang kecil pada rasio tinggi, tanpa membiarkan size menang atau menghukum operator kecil.
ownBond      = operator's own P-Chain node bond (FLR)
total        = ownBond + delegated WFLR vote power
alignment    = piecewise-linear ratio curve (0% → 0 … ≥10% → 7)
absolute     = min(7, ownBond / 5,000,000 * 7)   // saturates at 5M FLR
score        = max(alignment, absolute)
Mengapa: Skin in the game — operator dengan modal milik mereka berisiko aligned dengan delegator. Tapi ukuran self-bond bukan proxy untuk QUALITY operator (itu hidup di dimensi lain), jadi operator aligned kecil dan besar committed keduanya earn full marks. Hanya operator dengan sedikit modal milik committed — share kecil DAN jumlah kecil — skor di bawah full.
Cara skor 100/100 — playbook provider FTSO
Audit fairness v4.0 dirancang secara khusus jadi memaksimalkan setiap dimensi skor skor benar-benar membuat Anda provider FTSO lebih baik untuk delegator Anda. Meningkatkan skor Anda bukan gaming sistem — itu sistem bekerja seperti dirancang. Ini playbook per-dimensi.
Reward Rate — 25 poin. Berikan ≥ 2× network median FSP reward rate per epoch (after-fee, post-protocol-distribution). Linear dari 0 ke 2× median: median → 12.5, 2× median → 25. Mengapa ini align: ini adalah jumlah dollar benar-benar mencapai delegator Anda per epoch.
Accuracy — 25 poin. Target ≥97% secondary-band landing rate di FSE untuk full points. Piecewise linear jadi 95% → 18, 93% → 16, 90% → 13, dll. — setiap 1% improvement menggerakkan skor. Ini adalah price-QUALITY, bukan epoch participation: itu mengukur fraksi apa dari harga submitted mendarat dalam band accepted on-chain. Provider dengan Accuracy tinggi mempublikasikan harga dekat consensus; satu dengan Accuracy rendah submit reliable tapi off-consensus lebih sering. Mengapa ini align: off-band submissions memproduksi reward delegator lebih kecil bahkan ketika provider berpartisipasi di setiap epoch. Dimensi Compliance terpisah di bawah track epoch participation.
Consistency — 20 poin. Minimalkan variance reward-rate per-epoch (CV = stddev/mean seluruh epoch recent). CV = 0 → 20, CV = 0.2+ → 0. Mengapa ini align: dua provider dengan reward rate mean sama tidak equivalent — payouts predictable mengalahkan volatile untuk staker UX.
V2 Participation — 15 poin. Stack protokol additively: active baseline + V1 partial registration + setiap protokol V2 (Scaling, FastUpdates, FDC). Full V2 + active + V1 registered = 15. Mengapa ini align: V2 adalah di mana network pergi; setiap protokol tambahan Anda adopsi adalah forward investment delegator Anda benefit dari.
Fee — 15 poin. Charge ≤ 5% untuk 13 poin, 0% untuk 15. Piecewise linear ramp melalui 5%/10%/15%/20%/25% breakpoint ke 0. Mengapa ini align: fee lebih rendah = reward lebih banyak mencapai delegator Anda langsung.
MIRROR Participation — 12 + hingga 3 bonus. Jalankan semua validator P-Chain node operator Anda sebagai MIRROR-active (baik via on-chain RewardClaimed event ATAU alokasi FSP Merkle JSON — v3.6 dual-source). Sustained overperformance (median (vrm+mirror)/expected ratio di atas 1.05) pada ≥3 paid stake setelah 30 hari observasi earn hingga +3 bonus. Mengapa ini align: MIRROR adalah share delegator Anda dari inflasi FTSO; node tidak membayar MIRROR mengirim ~5-15% yield lebih sedikit ke staker.
Delegator Count — 12 poin. Skala log 5 → 500 delegator dipetakan ke 0 → 12. Bangun base staker independent, bukan hanya beberapa whale. Mengapa ini align: count adalah sinyal trust independent dari stake size; 200 delegator memilih Anda berarti 200 independent endorsement.
Epoch Participation — 10 poin. Tampilkan di setiap epoch dengan reward rate positif dan flag aktif FSE. Mengapa ini align: menangkap reward stream stalled yang dimensi per-epoch mungkin lewatkan.
Stabilitas — 10 poin. Pertahankan perubahan kekuatan suara hari ke hari di bawah 1%. Ramp linier berjenjang dari sana. Mengapa ini selaras: kekuatan suara yang stabil menandakan delegator yang mapan (komunitas lengket) daripada gelombang paus yang bersifat sementara.
Kepatuhan — 10 poin. Nol epoch hadiah yang terlewatkan dalam data FSP. Setiap miss mengurangi 3 poin; ~3 miss menganulkan dimensi. Ini adalah PARTISIPASI, bukan kualitas harga: ini menghitung epoch di mana penyedia dihukum karena melewatkan kondisi minimum, kebijakan penandatanganan, atau persyaratan protokol lainnya — berbeda dari dimensi Akurasi di atas yang menilai pendaratan harga dalam pita. Mengapa ini selaras: epoch yang terlewatkan dalam distribusi hadiah protokol itu sendiri berarti penyedia gagal memenuhi kondisi minimum dan delegator tidak memperoleh apa pun di epoch itu. Penyedia dapat memiliki Akurasi luar biasa pada epoch yang diikuti dan masih melewatkan epoch sepenuhnya.
Identitas — 8 poin. Daftarkan nama merek nyata (≥4 karakter, bukan alamat hex) di Flaremetrics atau FSE. Penyedia anonim-menurut-alamat mendapat skor 0; penyedia bernama mendapat skor 8. Mengapa ini selaras: penyedia bernama dapat ditemukan dan bertanggung jawab; itu adalah sinyal kepercayaan dasar.
Ikatan Diri — 7 poin. Komitkan ikatan simpul P-Chain Anda sendiri (bukan stake yang didelegasikan orang lain kepada Anda). Nilai penuh untuk BAIK bagian bermakna dari total stake Anda (≥10%) ATAU jumlah absolut bermakna (sumbu absolut jenuh pada 5M FLR, jadi operator besar tidak dapat mengungguli operator kecil dalam ukuran). Mengapa ini selaras: skin-in-the-game — operator dengan modal mereka sendiri yang berisiko berbagi hasil hasil delegator mereka. Ini adalah gerbang komitmen netral ukuran, bukan peringkat kekayaan: operator kecil yang sepenuhnya selaras dan operator besar yang berkomitmen keduanya memaksimalkannya, dan kualitas operasional Anda dinilai oleh dimensi lain.
Sinyal time-gated yang tidak dapat Anda lewati: Konsistensi membutuhkan ≥3 epoch riwayat. Bonus kinerja berlebihan MIRROR membutuhkan 30 hari pengamatan ditambah ≥3 sampel stake berbayar. Kepatuhan membutuhkan data FSP mencakup epoch yang cukup untuk dihitung. Bangun track record; skor akan mengikutinya.
Skor raw berjumlah maksimal 172 di seluruh 12 dimensi terukur kemudian dinormalisasi menjadi 100. Perjalanan sempurna pada input mencapai 172/172 → 100 ditampilkan. Penalti dilusi kekuatan suara hingga −3 poin diterapkan untuk penyedia sangat besar (>1,34B VP) sebagai tiebreaker.
Cara memverifikasi skor Anda sendiri
Setiap skor di tabel penyedia dapat direproduksi dari data publik. Jika Anda seorang operator dan matematika di sini tidak cocok dengan skor yang Anda lihat, langkah yang tepat adalah memverifikasinya sendiri sebelum mengasumsikan kami membuat kesalahan. Panduan lengkap:
  1. Cari statistik publik penyedia Anda di flaremetrics.io (cari berdasarkan nama atau tempel alamat delegasi Anda). Catat fspRewardRate, delegationFeePercentage, wNatWeight, dan votePowerDailyChangePct Anda.
  2. Verifikasi FTSO V2 + akurasi Anda di flare-systems-explorer.flare.network. Temukan entitas Anda. Periksa providersuccessrate.secondary untuk akurasi, ditambah flag entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc untuk status V2.
  3. Periksa partisipasi MIRROR Anda pada kontrak V2 RewardManager melalui flare-explorer.flare.network. Cari acara RewardClaimed dengan claimType=3 mereferensikan nodeID Anda. Jika tidak ada yang terakhir untuk salah satu node Anda, Anda akan ditampilkan sebagai MIRROR-tidak aktif pada skor.
  4. Masukkan input Anda ke dalam formula di atas. Blok kode setiap dimensi memberi tahu Anda dengan tepat aritmatika apa yang akan dijalankan. Jumlahkan dimensi, bagi dengan 172 (maks mentah), kalikan dengan 100, dan Anda memiliki skor komposit mentah Anda.
  5. Terapkan penalti pengenceran jika Anda besar. Kekuatan suara di atas 1,34B adalah −3, di atas 1B adalah −1. Kartu Skor Akhir di bawah memiliki ambang batas yang tepat.
  6. Bandingkan dengan skor yang ditampilkan Anda. Skor yang ditampilkan juga mencerminkan redistribusi bobot dinamis — ketika sebagian besar penyedia berkumpul dalam dimensi (standar deviasi rendah di seluruh set aktif), bobot dimensi itu didistribusikan kembali ke dimensi di mana penyebarannya lebih luas. Panel rincian skor di setiap baris penyedia menunjukkan nilai per dimensi saat ini.
  7. Jika matematikanya tidak cocok, kirim email ke [email protected] dengan alamat delegasi Anda, input yang Anda gunakan, dan skor yang Anda hitung. Kami akan merespons, dan jika kami membuat kesalahan kami akan memperbaikinya secara terbuka.
Kekhawatiran operator umum
Tingkat hadiah saya di atas median tetapi skor Reward Rate saya bukan 25/25 — mengapa?
Reward Rate linier dalam rasio-ke-median: skor = rasio × 12,5, jadi 1,0× median = 12,5/25 dan Anda membutuhkan rasio 2,0× untuk mencapai batas. Penyedia pada 1,2× median mencetak 15, pada 1,5× mencetak ~18,8, pada 2,0× mencetak 25 penuh. Batas (ditambah filter anomali 3×-median) ada sehingga epoch hadiah tunggal yang anomali tinggi tidak dapat mendominasi dimensi; jika tingkat Anda secara konsisten di desil atas, skor masih menghargainya dengan berat.
Saya baru saja upgrade ke V2 — kapan skor V2 saya diperbarui?
Status V2 berasal dari flag entityminimalconditionslatest FSE (ftso_scaling, ftso_fast_updates, fdc). Sejak v4.0 dimensi bertumpuk per protokol: dasar aktif +3, pendaftaran V1 (submit + penandatanganan + pemilih) +4, dan setiap protokol V2 +~2,67. Jadi penyedia terdaftar pemilih dengan alamat submit + penandatanganan tetapi tidak ada tiga protokol V2 mencetak 7/15, dan setiap protokol V2 individu yang Anda nyalakan menggerakkan skor — ketiga-tiganya langsung mendapat 15 penuh. Perubahan diterapkan pada cron run FlareWatch berikutnya (setiap 5 menit) setelah FSE mencerminkannya.
Akurasi saya di FSE adalah 96% tetapi saya mencetak lebih rendah dari yang saya harapkan.
Dimensi Akurasi menggunakan metrik akurasi sekunder FSE (resolusi lebih tinggi dalam band 94–97% di mana sebagian besar penyedia berkumpul). 95–96% dipetakan ke 18 poin; Anda membutuhkan ≥97% untuk 25 penuh. Ember ketat di atas karena beberapa persepuluhan persen dalam band 95–97% mewakili pemisahan kinerja nyata antara penyedia.
Saya memberikan MIRROR — mengapa FlareWatch menunjukkan saya sebagai MIRROR-tidak aktif pada skor penyedia saya?
Sejak 2026-05-11, partisipasi MIRROR dideteksi dari DUA sumber: acara RewardClaimed(claimType=3) on-chain pada RewardManager V2, DAN alokasi claimType=3 dalam JSON Merkle FSP resmi. NodeID yang muncul di kedua sumber dihitung sebagai aktif. Untuk operator multi-node skor menggunakan fraksi node Anda yang aktif (1/3 aktif = 4/12 dasar, dll.). Jika nodeID harus diklasifikasikan aktif tetapi tidak setelah siklus sapuan berikutnya, kirim email kepada kami dengan nodeID dan epoch spesifik yang Anda harapkan untuk muncul — kami akan memeriksa silang kedua sumber.
Kekuatan suara saya bergerak 8% kemarin — mengapa skor Stabilitas saya ~2,8/10?
Vote Power Stability adalah piecewise linear dalam perubahan absolut hari ke hari (dilinearkan dalam v4.0 — tanpa tebing ember): <1% → 10, ramp 1→3% turun ke 7, 3→5% turun ke 4, 5→10% turun ke 2, kemudian menuju 0 melampaui 10%. Gerakan 8% mendarat pada ramp 5–10% pada 4 − (8 − 5) × 0,4 = 2,8. Tujuannya adalah untuk menandai penyedia yang mengalami turnover delegator bermakna sehingga staker dapat melihatnya di tabel. Skor pulih segera setelah kekuatan suara Anda stabil; satu hari yang volatile tidak secara permanen menahan Anda tetap rendah.
Penyedia saya dinamai dengan alamat entitas saya (0x…). Mengapa skor Identitas adalah 0?
Identitas memberi 8 poin untuk nama merek nyata (≥4 karakter, bukan dimulai dengan 0x atau hex-only) dan 0 untuk nama murni-alamat. Kami tidak dapat membuat nama — atur profile.name Anda di Flaremetrics dan kami akan mengambilnya pada cron run berikutnya. Jika entitas Anda memiliki profil tetapi bidang nama kosong, hal yang sama berlaku.
Saya memiliki dasar delegator kecil tetapi berkomitmen — mengapa skor Delegator Count saya dibatasi?
Delegator Count menggunakan penghitungan nyata: setiap dompet yang memegang WFLR diperiksa on-chain untuk delegasi saat ini, dan delegator unik setiap penyedia dijumlahkan (diperbarui setiap ~6 jam, diverifikasi silang terhadap buku besar peristiwa independen). Sejak v4.0, diskalakan logaritmik dari 5 → 500 delegasi dipetakan ke 0 → 12 poin, dengan batas 500 (≤5 mendapat skor 0). Penskalaan logaritmik berarti penyedia yang lebih kecil dengan pertumbuhan jumlah delegasi yang kuat naik paling cepat; setelah ~50 delegasi, delegasi tambahan menggerakkan indikator lebih sedikit — tetapi kurva bersifat monoton, sehingga mendapatkan delegasi tidak pernah dapat menurunkan skor (bucket pre-v4.0 bisa).
Skor saya turun setelah saya menambahkan node — apa yang terjadi?
Jika node baru belum menunjukkan acara MIRROR claimType=3, fraksi MIRROR Anda turun (misalnya, dari 1/1 = 100% menjadi 1/2 = 50%), mengurangi skor dasar Partisipasi MIRROR. Setelah node baru mulai membayar MIRROR (biasanya dalam satu atau dua epoch hadiah aktivasi), fraksi pulih dan skor naik kembali.
Dapatkah saya banding skor saya atau meminta tinjauan manual?
Ya. Kirim email ke [email protected] dengan alamat delegasi Anda dan kekhawatiran spesifik. Kami merespons setiap operator. Hal-hal yang akan kami lakukan: koreksi klasifikasi MIRROR, kesalahan matematika spesifik dimensi, perbaikan nama/logo melalui Flaremetrics. Hal-hal yang tidak akan kami lakukan: permintaan untuk secara manual menaikkan skor di luar algoritma, permintaan untuk mengecualikan atau menurunkan peringkat pesaing.
Apa yang akan dan tidak akan kami lakukan
Untuk menghilangkan ambiguitas tentang cara kami mengoperasikan skor, berikut adalah komitmen eksplisit. Jika kami pernah melanggar salah satu dari ini, dokumentasikan dan kirim email ke [email protected] — kami akan memperbaikinya secara terbuka.
✓
Kami tidak akan menerima pembayaran untuk skor yang lebih tinggi, penempatan bersponsor, atau perlakuan yang menguntungkan dalam bentuk apa pun. Skor dihitung secara deterministik dari data publik.
✓
Kami tidak akan mengkode tangan bumps per-penyedia. Tidak ada baris "X mendapat +5 karena kami suka mereka" di mana pun dalam kode. Algoritma yang sama berlaku untuk setiap penyedia termasuk penyedia FlareWatch sendiri, yang diskor oleh fungsi eksak ini.
✓
Kami tidak akan mengecualikan penyedia dari tabel untuk alasan non-publik. Daftar bersumber dari Flaremetrics + FSE; tampilan kami mencakup setiap penyedia aktif yang sumber-sumber itu permukaan.
✓
Kami akan menerbitkan perubahan algoritma. Setiap pembaruan versi didokumentasikan dalam kartu Versi di halaman ini dengan penjelasan 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 mengeluarkan perbaikan dan mendokumentasikannya. Kami tidak me-ranking ulang secara diam-diam.
✗
Kami tidak akan membagikan isi email secara publik tanpa izin pengirim, atau menggunakan email operator untuk tujuan lain selain percakapan skor yang menghasilkannya.
✗
Kami tidak akan membagikan rencana masa depan untuk perubahan algoritma dengan operator tertentu sebelumnya — setiap versi diluncurkan untuk semua orang secara bersamaan.
Skor akhir (cara dimensi digabungkan)
Semua 12 dimensi terskor berjumlah komposit mentah (maks 172). Komposit mentah dinormalisasi ke skala 0–100, kemudian redistribusi bobot dinamis diterapkan untuk menghasilkan skor akhir yang ditampilkan.
// Step 1 — Raw composite (sum of 12 dimensions, max 172)
raw = rewardRate + accuracy + consistency + v2 + fee + mirror
    + delegators + participation + stability + compliance
    + identity + selfBond

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

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

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

// Step 3 — Final score (capped at 100)
score = min(100, final)
Kedekatan cap adalah sinyal tampilan, bukan pengurangan skor. Hingga v4.9 skor juga mengurangi poin rata-rata 1–3 dari penyedia yang sangat besar, tetapi itu menghitung ganda — penyedia yang melebihi cap sudah menghasilkan tingkat pengembalian yang direalisasikan di bawah median, yang dimensi Tingkat Pengembalian yang dijangkar median mencetak sekali. Jadi penalti dihapus. Setiap penyedia sekarang menunjukkan berapa banyak dari cap FSP (2,5% dari kekuatan suara total WNat contract yang aktif) yang diisinya, sebagai sinyal dilusi marginal-delegasi netral: semakin dekat dengan 100%, semakin banyak delegasi baru akan terdilusi.
Bendera outlier tingkat tampilan: penyedia yang tingkat reward saat ininya lebih dari tiga robust deviation (median absolute deviation, diukur ×1.4826) di atas median lapangan — dan setidaknya 50% di atasnya — membawa badge Outlier di tabel penyedia. Badge tidak mengubah skor; penjaga anomali skor itu sendiri secara terpisah membatasi tingkat di atas 3× median sebelum penilaian. Lonjakan tingkat epoch-rate yang diannualisasi biasanya berasal dari vote power yang sangat kecil dan kembali normal dalam satu epoch.
Sumber data (setiap input bersifat publik)
Kontrak Flare, dibaca langsung on-chain: kumpulan penyedia terdaftar (VoterRegistry), tautan entitas → alamat delegasi dan nodeID ditambah pendaftaran alamat submit/penandatanganan (EntityManager), kekuatan suara yang didelegasikan (WNat), dan biaya delegasi (WNatDelegationFee). Ini yang membuat daftar penyedia independen dari satu indeks apa pun: pada epoch reward 420, rantai menampilkan 98 penyedia terdaftar dibandingkan 80 dalam daftar pihak ketiga, dan 18 di antara celah tersebut sebelumnya sama sekali tidak ada di situs ini.
API publik Flaremetrics: tingkat reward, biaya delegasi, daya suara, perubahan harian daya suara, daya suara terkunci (self-bond), nama profil + logo + wilayah, fspRewardRate.
Flare Systems Explorer (FSE): akurasi FTSO (primer + sekunder), flag status V2 (ftso_scaling, ftso_fast_updates, fdc), penghubung alamat entitas, kehadiran alamat penandatangan/pengiriman, pendaftaran pemilih, penghubung nodeID P-Chain, dan tingkat reward delegasi per-entitas (reward_rate_wnat). Tingkat reward sengaja bersumber dari KEDUA FSE dan Flaremetrics: mereka menerbitkan angka yang sama dalam unit berbeda (desimal FSE, persen Flaremetrics — diverifikasi identik di semua 72 penyedia yang membawa keduanya, hingga lima tempat desimal), dan FSE mencakup 154 entitas terhadap 80 Flaremetrics. Satu sumber saja meninggalkan penyedia tanpa tarif tanpa kesalahan mereka sendiri.
Data reward Flare Systems Protocol (FSP): distribusi reward per epoch per penyedia, digunakan untuk dimensi Compliance (menghitung epoch tanpa reward) dan sebagai sumber otoritatif untuk total reward delegasi.
V2 RewardManager (acara claimType=3): distribusi MIRROR yang diklaim on-chain per validator nodeID. Disaring ketat pada tipe 3 — tidak ada percampuran dengan VRM, delegasi FTSO, atau reward DIRECT. Indexer FlareWatch sendiri menampilkan ini untuk dimensi Partisipasi MIRROR.
FSP Merkle JSON (alokasi claimType=3): catatan publik resmi tentang siapa yang berhak mendapat MIRROR per epoch (data yang sama yang dibaca alat penandatangan Flare sendiri). Ditambahkan sebagai sumber otoritatif kedua pada 2026-05-11 — menangkap validator yang MIRROR-nya dialokasikan tetapi belum diklaim on-chain.
Snapshot historis FlareWatch: feed tingkat reward per epoch memberi makan CV Konsistensi; observasi paid-stake per validator memberi makan bonus overperformance MIRROR (dengan gate akumulasi data 30 hari).
Apa yang BUKAN dalam skor
• Promosi diri atau penempatan berbayar. Tidak ada penyedia yang dapat membayar atau mensponsori skor lebih tinggi.
• Bump spesifik penyedia yang dikodekan dengan tangan. Tidak ada baris "X mendapat +5 karena kami menyukai mereka" di mana pun dalam kode. Algoritma yang sama berlaku untuk setiap penyedia termasuk penyedia FlareWatch sendiri, yang diskor oleh fungsi yang tepat ini.
• Kualitas infrastruktur subjektif. Kami tidak mencoba mengevaluasi SLA uptime, distribusi geografis, atau spesifikasi hardware di luar apa yang FSE dan Flaremetrics tampilkan sebagai data publik.
• Lockup atau komitmen kepada FlareWatch. Tidak ada skor menguntungkan untuk staker menggunakan FlareWatch vs. alat lain.
• Sinyal masa depan belum terhubung. Kehadiran komunitas (media sosial terverifikasi, partisipasi tata kelola), slashing historis, latensi respons, dan garis tren per epoch dilingkupkan untuk versi masa depan tetapi tidak ada di v3 saat ini. Tidak ada yang ditimbang secara diam-diam.
Umpan balik operator
Melihat sesuatu yang aneh dalam skor penyedia Anda? Kirim email ke [email protected] dengan alamat delegasi dan kekhawatiran Anda. Kami merespons setiap operator. Permintaan umum yang akan kami tindaklanjuti:
  • Koreksi klasifikasi MIRROR (atribusi claimType=3 ke nodeID Anda).
  • Kesalahan matematika spesifik dimensi dengan input yang Anda gunakan.
  • Koreksi nama / logo / profil melalui Flaremetrics atau FSE.
  • Kritik algoritma umum.
Sumber & referensi
Setiap input ke skor berasal dari sumber ekosistem Flare publik dan dapat diverifikasi. Siapa pun dapat memverifikasi silang klaim kami terhadap sumber primer ini dan mereproduksi matematika dari data mentah. Jika Anda menemukan perbedaan antara halaman ini dan apa yang dikatakan sumber hulu, kirim email ke [email protected] dan kami akan memperbaikinya.
Dokumentasi protokol Flare Network ↗https://docs.flare.network
Dokumen protokol otoritatif. Mencakup FTSO V2, FSP, validasi P-Chain, FAssets, dan sisa stack Flare.
Portal tata kelola Flare (FIP) ↗https://proposals.flare.network
Flare Improvement Proposals — sumber kebenaran untuk kondisi minimum protokol V2, mekanik biaya, dan perubahan ekonomi reward yang memberi makan skor ini.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Registri resmi yang dioperasikan Flare dari penyedia data FTSO, alamat entitas, keterkaitan nodeID P-Chain, dan flag kondisi minimum. Sumber utama untuk dimensi Akurasi, V2, dan Partisipasi kami.
Flaremetrics ↗https://flaremetrics.io
Penyedia metrik ekosistem Flare independen. Sumber tingkat reward, biaya, daya suara, perubahan harian daya suara, daya suara terkunci, nama profil + logo, dan metrik fspRewardRate.
Penjelajah Blok Flare ↗https://flare-explorer.flare.network
Browser baca-saja dari semua status on-chain. Memungkinkan siapa pun untuk memverifikasi acara RewardClaimed RewardManager V2 (claimType=3 untuk MIRROR), transisi epoch reward, dan sisanya.
Repo reward-scripts Flare Foundation ↗https://github.com/flare-foundation/reward-scripts
JSON yang diterbitkan per reward-epoch oleh Flare Foundation yang menunjukkan reward yang disampaikan per validator. Input tidak langsung — memberi makan perhitungan bonus overperformance MIRROR melalui indexer observasi per-stake FlareWatch.
API publik Flaremetrics (penyedia FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Endpoint pasti yang dikonsumsi cron kami, mengembalikan profil entitas, tingkat reward, biaya, dan power voting. Siapa pun dapat mengaksesnya secara langsung.
API publik Flaremetrics (registrasi node) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Tabel konversi Hex → cb58 NodeID. Kami melakukan pagination untuk membangun pencarian entitas-ke-NodeID yang mendorong dimensi MIRROR Participation.
Tidak ada data pribadi, tidak ada model tertutup. Algoritma scoring diimplementasikan dalam services/ftso/scoring.ts di basis kode FlareWatch. Operator atau peneliti yang ingin menginspeksi implementasi secara langsung (bukan hanya membaca prose + formula di atas) — atau yang ingin memforknya 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
Scoring penyedia FTSO berjalan sebagai pass di dalam cron di /api/cron/refresh-validators, yang menghitung ulang skor setiap penyedia aktif setiap 5 menit (run yang sama yang melakukan rescoring validator P-Chain). Input (Flaremetrics, FSE, FSP rewards, V2 RewardManager events) diambil segar pada setiap run.
Consistency CV menggunakan sejarah epoch terakhir — dimensi dapat bergeser saat jendela rolling bergeser. Penyedia pendatang dengan kurang dari 3 epoch historis mendapat skor netral 10 hingga cukup data terakumulasi.
Redistribusi bobot dinamis dihitung ulang setiap run berdasarkan set penyedia aktif saat ini. Saat penyedia bergerak (misalnya, gelombang upgrade V2 baru), dimensi yang menjadi tidak diskriminasi bergeser; redistribusi beradaptasi secara otomatis.
Versi algoritma dicap dalam header halaman ini. Ketika kami mengirim versi baru, string versi di sini berubah dan kartu Versi di bawah mendokumentasikan apa yang berubah.
Versi
v4.8 (2026-08-20) — Akurasi sekarang menghargai pita reward YANG SULIT. Itu hanya menggunakan pita secondary FTSO (lebih luas), di mana hampir setiap penyedia serius mencapai 95–99% — jadi dimensi ini adalah 25/25 yang hampir datar di seluruh bagian atas lapangan, hampir tidak mengukur apa pun. Pita PRIMARY (IQR ketat) adalah engineering yang benar-benar sulit dan menyebarkan penyedia ~28–80%. Flare menghargai pita-pita ini 40% primary / 60% secondary (FIP.11, aktif sejak 2024, dengan peningkatan pita secondary lebih lanjut yang telah diberi sinyal), jadi Akurasi sekarang mencerminkan itu: campuran 40/60. Secondary mempertahankan kurva sebelumnya; primary menggunakan kurva absolut (28% → 0, 78% → 25 penuh), tetap sehingga skor tetap dapat diturunkan kembali dari input penyedia sendiri. Perbandingan lengkap sebelum/sesudah untuk semua 100 penyedia yang dinilai, diarsipkan sebelum peluncuran: pengurutan melacak kekuatan pita primary — penyedia yang melakukan pekerjaan pita-ketat yang sulit naik, penyedia yang sekadar mengandalkan angka secondary yang mudah turun. Aturan yang sama berlaku untuk penyedia kami sendiri, yang memiliki pita primary yang lemah hari ini: itu turun dari 84 menjadi 77 dan turun beberapa tempat. Tetap diluncurkan — skor yang menghargai engineering nyata, bahkan milik pesaing dan bahkan dengan merugikan kami sendiri, adalah satu-satunya jenis yang layak dipublikasikan.
v4.7 (2026-07-31) — Daftar penyedia berhenti bergantung pada satu indeks, dan skor berhenti menghukum kesenjangan data kami sendiri. (1) Daftar sekarang dibangun dari kumpulan pemilih terdaftar on-chain dan diisi kembali di mana indeks pihak ketiga kehilangan entitas: 98 penyedia terhadap 80 yang ditampilkan sebelumnya, jadi 18 penyedia nyata yang tidak dapat dicari dan tidak dapat didelegasikan dari sini sekarang muncul. (2) "Active" berarti "memiliki tingkat reward dari indeks itu", yang mengosongkan dimensi Fee (15) dan V2 (15) untuk setiap penyedia yang diisi kembali bahkan ketika data FSP kami sendiri menunjukkan pembayaran setiap epoch; sekarang menerima bukti distribusi. (3) Tingkat reward yang hilang tidak lagi mencetak 0 terhadap penyebut penuh — bobot 25 poin meninggalkan penyebut sebagai gantinya, jadi penyedia dinilai berdasarkan apa yang kami ukur daripada dikenakan untuk apa yang tidak bisa kami ukur. (4) Dimensi Fee masih dinilai pada kurva pra-FIP-16, di mana biaya 0% mendapat nilai penuh. FIP-16 membuat 20% sebagai biaya entitas hukum minimum dan setiap satu dari 98 penyedia mengenakan persis itu, jadi dimensi memberikan 4.00/15 ke seluruh lapangan tanpa varians — 11 poin yang tidak bisa diperoleh siapa pun, senilai sekitar 4,3 poin dari setiap skor yang dipublikasikan termasuk yang tertinggi. Fee sekarang berlabuh ke max(biaya terendah yang diamati, lantai protokol), dengan cara yang sama halaman validator telah berlabuh sejak fork Granite: mengenakan biaya hukum minimum mendapat nilai penuh, dan hanya biaya DI ATAS itu yang dikenakan penalti, menurut jarak. Ini meningkatkan setiap skor dengan jumlah serupa dan tidak mengubah peringkat. Penyedia dengan tarif yang dipublikasikan tidak terpengaruh oleh perubahan (1) hingga (3). Tidak ada tingkat reward yang diestimasi atau disimpulkan: baris tersebut berbunyi "No data". (5) Tingkat reward tidak lagi bergantung pada satu indeks. Itu dibaca dari Flaremetrics saja, jadi penyedia yang indeks itu berhenti cover kehilangan Net dan Gross APR-nya dan mencetak 0/25 pada Reward Rate — penalti 25 poin untuk kesenjangan cakupan seseorang. Flare Systems Explorer menerbitkan angka yang sama dan mencakup lebih banyak entitas, jadi sekarang mengisi kesenjangan apa pun; tarif Flaremetrics live tidak pernah ditimpa. Pada hari pengiriman ini, itu mengembalikan tarif yang dipublikasikan ke 15 penyedia yang tidak memilikinya.
v4.6 (2026-07-01) — Consistency de-bias untuk node baru. Ini adalah mean/stddev dari tingkat reward selama riwayat 30 epoch penuh, jadi epoch earning pertama yang meningkat inflasi dari node baru (weight voting kecil → tingkat per-unit tinggi, yang kemudian normal) bertindak sebagai outlier yang menjepitkan CV tinggi — scoring 0 — selama berbulan-bulan hingga usianya. Sekarang menggunakan jendela trailing (12 epoch earning terakhir) dan dispersi median/MAD yang kuat, sehingga epoch ramp adalah outlier yang tidak berbahaya sementara volatilitas genuine yang berkelanjutan masih mendapat skor rendah.
v4.5 (2026-06-30) — Self-Bond dibuat size-neutral. Kurva rasio-saja dapat menskor self-bond absolut besar pada rasio rendah DI BAWAH self-bond kecil pada rasio tinggi. Self-Bond sekarang mengkredit yang lebih besar dari rasio alignment atau jumlah absolut saturasi (dibatasi pada 5M FLR), jadi operator yang berkomitmen besar dan operator yang selaras sepenuhnya mendapat nilai penuh — ini menghargai komitmen, bukan kekayaan, dan kualitas validator tetap berada di dimensi lain.
v4.4 (2026-06-30) — Dua fix bug nyata. (1) Self-Bond adalah dimensi MATI: membaca field Flaremetrics yang API telah hilangkan, jadi setiap penyedia mendapat skor 0/7. Bersumber kembali dari self-bond P-Chain node operator yang sebenarnya (cross-referenced dari validator set oleh nodeID). (2) Compliance berhenti menghukum epoch sebelum penyedia aktif — node baru yang earning dengan bersih sejak diluncurkan sebelumnya ditagih untuk setiap epoch yang mendahuluinya, menjaganya pada 0/10 selama berminggu-minggu. Epoch yang terlewat sekarang dihitung hanya dalam jendela aktif setiap penyedia.
v4.3 (2026-06-03) — Klarifikasi metodologi, tidak ada perubahan math scoring. Dimensi Accuracy sekarang secara eksplisit didefinisikan sebagai on-chain secondary-band landing rate (KUALITAS harga — fraksi apa dari harga yang disubmit mendarat di dalam band yang diterima), berbeda dari dimensi Compliance, yang menghitung epoch reward yang terlewat (PARTISIPASI FSP). Halaman ini dan tooltip tabel validators ditulis ulang untuk membuat perbedaan eksplisit, dan kolom Compliance ditambahkan bersama Accuracy. Kedua dimensi tetap bobot sebelumnya (25 dan 10) dan input (fseAccuracySecondary dan epochsWithoutRewards).
v4.2 (2026-05-20) — Dimensi Rewards Distributed diperbaiki. Ini diwirkan ke field reward-distribution Flaremetrics yang API v3 penyedia hilangkan, jadi dimensi membaca 0 untuk setiap penyedia dan tidak berkontribusi apa-apa. Kabel ulang ke total delegasi-reward FSP on-chain — data reward-claim yang sama yang dimensi Compliance sudah agregat — jadi dimensi membedakan lagi.
v4.1 (2026-05-20) — Dimensi Compliance diklem. epochsWithoutRewards bisa tiba negatif karena cron FSP rewards terakumulasi epoch-presence count melewati jendela rolling, yang membiarkan Compliance melebihi tutup 10-point (diamati hingga ~58) dan mendorong composite melewati maksimum — saturasi kasar 70% penyedia pada flat 100. Compliance sekarang diklem ke bobotnya, dan cron FSP menghitung ulang ringkasan reward statelessly per window sehingga count tidak dapat lagi drift.
v4.0 (2026-05-11) — Pass audit keadilan penuh setara dengan rilis v4.0 skor validator. Dua bug nyata diperbaiki: (1) Delegator Count memiliki insentif perverse pada 500 — pre-fix ember 500-delegator mengembalikan 14 pts tetapi tutup >500 mengembalikan WEIGHT_DELEGATORS dasar (12), jadi mendapatkan delegator melintasi batas itu KEHILANGAN 2 poin. Sekarang log-scaled dari 5 → 500, monotonic naik. (2) Tingkat V2 Participation runtuh — pendaftaran V1 parsial dan V2 penuh (Scaling + FastUpdates + FDC) keduanya mengembalikan 15, jadi upgrade dari parsial ke V2 penuh memberikan peningkatan skor nol. Sekarang per-protocol stacking (active +3, V1 +4, setiap protokol V2 +~2.67). Boundary cliffs dihilangkan dalam Accuracy (memiliki tebing 7-pt pada 97%), Stability, dan Self-Bond Ratio — semua linearisasi dengan nilai yang dipertahankan di boundary bucket. Kurva Reward Rate disesuaikan ulang sehingga median = setengah poin dimensi (sebelumnya 40%). Docstring dimensi kuno yang direkonsiliasi dengan nilai bobot aktual. Efek bersih: setiap dimensi monotonic naik pada sumbu input, dan tidak ada penyedia yang dapat menurunkan skor FlareWatch mereka dengan meningkatkan metrik operasional sebenarnya.
v3 (2026-05-09 → 2026-05-11) — Scoring 13-dimensi dengan redistribusi bobot dinamis dan penalti dilusi vote-power. MIRROR Participation diperkenalkan sebagai dimensi first-class (12 base + hingga +3 bonus overperformance dengan shrinkage Bayesian dan 30-hari data accrual gate). Identity dan Self-Bond ditambahkan sebagai dimensi diskrit. Reward Rate dipindahkan ke median-anchored. Accuracy menggunakan metrik FSE secondary untuk band resolusi tinggi. Consistency menggunakan CV melintasi epoch terakhir.
v2 dan sebelumnya — Versi pre-v3 tidak didokumentasikan di sini; mereka menggunakan subset dimensi yang lebih sederhana dan mendahului redistribusi bobot dinamis. Versi dihentikan demi model saat ini.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.