Validatör Puanı Metodolojisi

Algoritma sürümü: v4.8 · Son güncelleme: 2026-08-19

FlareWatch, her P-Chain validatörüne 9 boyut üzerinde 0–100 arası bir bileşik puan atar. Matematik deterministiktir, girdiler halkadaki açık verilerdir [Flare Explorer] [FSE] [Flaremetrics], ve ağdaki her validatöre aynı algoritma uygulanır — FlareWatch'ın kendi validatör düğümü de dahil olmak üzere, özel muamele yapılmaksızın bu tam fonksiyonla puanlandırılır. Bu sayfa her boyutu ve eşiği belgeleyerek operatörlerin ve staker'ların puanın tam olarak nasıl hesaplandığını ve her değerin neden seçildiğini görmesini sağlar. Buradaki her iddia zincir üstü veya yukarı akış kaynağına geri bağlanır — Kaynaklar ve referanslar'ı altta bölümüne bakın.

Kapsam: bu sayfa validatör puanı'nı belgeleyerek — validatörler sayfasında staking modu'nda gördüğünüz (FLR'yi P-Chain validatörüne VRM + MIRROR ödülleri için devredilerek). delegasyon modu'nda gösterilen FTSO sağlayıcı puanı (WFLR'yi FTSO veri sağlayıcılarına devredilerek) veri sağlayıcı performansına odaklanan ayrı bir 13 boyutlu algoritma kullanır — doğruluk, V2 protokol katılımı, vb. Bunlar zincir üstü rolleri ve ödülleri ayrı olan, ayrı puanlanan farklı roller. Delegasyon tarafı için FTSO Sağlayıcı Puanı Metodolojisi'ne bakın.
SGB eşdeğeri yok: bu puanlama yalnızca Flare P-Chain validatörleri için geçerlidir. Songbird'ün P-Chain validatör seti Flare Foundation tarafından onaylanan kuruluşlarla sınırlıdır, bu nedenle perakende SGB P-Chain delegasyonu nadirdir ve staking sekmesi yalnızca FLR'dir. Staking modunda FLR / SGB anahtarı yoktur. SGB FTSO delegasyonu için FTSO Sağlayıcı Puanı Metodolojisi'ne bakın; her iki zinciri de kapsar.
APY'yi nasıl hesaplarız — gerçekten ne kazanırsınız

Staking tablosundaki APY, delegatörün aldığı tüm oranıdır — bir sayı, zihinsel matematik yok. Flare'in ödül-betikleri üzerinden ölçülmüştür (formül değil gerçek ödemeler), validatörün ücretinden net, ve her epoch'ta gerçek ödüllerle hareket eder. FlareWatch'ta her yerde APY, ücretinden sonra anlamına gelir ve APY, ücretinden önce anlamına gelir.

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • Staking ödülleri (VRM) — bir delegatörün doğrulama ödüllerinin net payı = Σ delegatör ödemesi ÷ Σ devredilen (Flare'ın kendi bölüşümü; ücret zaten kaldırıldı). Flare stake'e orantılı ödeme yaptığı için bu ağ çapında kabaca homojen ve temel olarak ücret'ten farklılık gösterir — daha düşük ücret daha yüksek delegasyon oranı anlamına gelir.
  • MIRROR — stake'inizin FTSO enflasyonunun payı, üstüne ödenen, yalnızca aktif FTSO yığını çalıştıran validatörlerde. Validatörün FTSO katılımına göre değişir ve en yakın epoch'lar üzerinden ölçülür.

Flare Systems Explorer ile karşılaştırılıyor mu? FSE ve diğer explorer'lar sadece delegasyon oranını gösterir — MIRROR'u eklemezler — böylece Toplam APY'miz herhangi bir MIRROR-aktif validatör'de daha yüksek okunur (fark tam olarak yukarıdaki MIRROR satırıdır). Her iki şekil de aynı ödül-betikleri verilerinden ~8-epoch trailing ortalamasıdır, bu nedenle validatörün mid-window ücret değişikliği, her iki sitede de güncel ücret anlık görüntüsü ile window üzerinden yaşlanana kadar gecikir.

İki başka şekil, APY tooltip'te görünür ve değildir delegatörün oranı: teorik temel (ağ brüt APY × (1 − ücret), sadece staking — yeterli ölçülen geçmiş var olana kadar fallback olarak kullanılır) ve operatörün kendi-tahvil verimi (kendi stake geri dönüşü, ücret tarafından ampliye — operatör metriği, sizin kazandığınız değil).

Puanlama için: Net Verim boyutu sadece VRM delegasyon oranını puanlar ve MIRROR kendi boyutunda puanlanır — bu nedenle MIRROR, görüntülenen Toplam APY'ye dahil edilmiş olsa bile hiçbir zaman çift sayılmaz.

Puan bantları
90+Üst kademe — operatörlerin ilk ~%10–20'si. Tipik profil: tam yığın validatör + FTSO + FDC, düşük uçlu ücret, MIRROR-aktif, tutarlı FIP-10 güvenilirliği, sağlıklı delegatör tabanı, anlamlı öz-tahvil. Hiçbir boyut gerekli değildir — operatörler çoğu kategoride gücü yığarak Üst kademeye ulaşır.
80–89Güçlü — çoğu önemli kıyaslama karşılanır; üst kademenin bir veya iki boyut altında.
70–79İyi — tüm taban ölçütlerini karşılar; önemli açık yok.
60–69Kabul edilebilir — kullanılabilir ancak ayırıcı değil.
<60Medyan altında — bir veya daha fazla boyutta önemli açıklar. Matematiksel gerçek, kalite yargısı değil.
Boyutlar (100'e kadar toplanır)
Çalışma Süresi20 puan maks
Ne: P-Chain RPC anlık çalışma süresi VE son ödül epoch'ları arasında geçmiş FIP-10 çalışma süresi uygunluk oranının kombinasyonu.
Nasıl: RPC eğrisi: ≥ %99,5 → 17–20. %99–99,5 → 13–17. %95–99 → 4–13. %90–95 → 0–4. < %90 → 0. Sonuç daha sonra uptimeReliability ile çarpılır (son 8 ödül epochu boyunca public reward-scripts verilerine göre epochsIncluded / epochsObserved — v4.2'den beri tam FIP-10 minimumluk seti, yalnızca RPC-uptime değil). v3.9, tam olarak %95'te perverse bir cliff'i düzeltti; %94,99 → %95,00 uptime'dan 4 puan kaybediliyordu.
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
Neden: v3.4 öncesinde bu boyut temelde ölü idi — canlı validatörlerin %92,9'u %100 RPC çalışma süresine sahiptir, bu nedenle eğri herkesi aynı şekilde puanlandırdı. Güvenilirlik oranı gerçek bir zaman serisi sinyalidir: son 8 epoch'ta 3'ünde FIP-10 minimum koşullarını başarısız olan bir validatör, anlık RPC'nin şu anda ne rapor ettiğinden bağımsız olarak %62,5 güvenilirlik puanına sahiptir. FIP-10'un %80 protokol tabanından kasıtlı olarak daha katı. Epoch başına uygunluk verileri Flare Foundation tarafından ödül-scriptleri repo'sunda yayınlanır.
Net Verim18 puan maks
Ne: Bir delegatörün aldığı, ağ medyanına sabitlenen ücret-net staking-ödül (VRM) oranı.
Nasıl: scoreAPR = ölçülen net DELEGASYON oranı (delegationAPY: Σ delegatorRewardAmount / Σ devredilen, Flare Foundation ödül-scriptlerinden, son ~8 epoch'lar), varsa, aksi takdirde teorik baseAPR = brüt × (1 − ücret). Puan = (scoreAPR / medianAPR) sabitlendi: oran 0,6 → 0 puan, 1,0 (medyan) → 12 puan, 1,2 → 18 puan. ÖNEMLİ: bu boyut YALNIZCA VRM (doğrulama-ödül) oranını puanlar — MIRROR, MIRROR Katılımı boyutunda ayrı olarak puanlanır, bu nedenle burada iki kez sayılmaz. Görüntülenen 'Toplam APR' (VRM + MIRROR) delegatör odaklı bir sayıdır, Net Yield girdisi değildir.
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
Neden: Oranın her iki tarafı NET delegasyon oranı (ölçülen delegationAPY ve teorik brüt×(1−ücret)), bu nedenle karşılaştırma benzer'dir — artık giriş ön ücret brüt oranı olduğunda 1/(1−ücret) tarafından şişirilmez (yaklaşık 2× 'ikiye katlama' hatası). Flare doğrulama ödüllerini stake'e orantılı ödediği için VRM delegasyon oranı ağ çapında kabaca homojendir ve temel olarak ücret tarafından farklılık gösterir — bu nedenle bu boyut çoğunlukla ücret rekabetçiliğini ve teslimat güvenilirliğini yansıtır (epoch'ları kaçıran validatör daha az teslimat eder). MIRROR (FTSO katılımı tarafından değişen), iki kez sayılmaktan kaçınmak için kasıtlı olarak kendi boyutunda tutulur.
Ücret Makullüğü7 puan maks
Ne: Protokol ücreti tabanının üzerindeki çıkarımlara karşı koruma, piecewise doğrusal yumuşatma.
Nasıl: Çıpa = maks(gözlenen minimum aktif ücret, protokol validatör-ücreti tabanı — Granite hard fork'undan bu yana %20, 2026-07-14). Çıpa'da veya altında herhangi bir ücret → tam 7 puan. Bunun üzerinde, sonraki 20 ücret puan üzerinde giderek daha dik eğimli doğrusal bir ramp (çıpa+5 → 6, çıpa+10 → 4,5, çıpa+15 → 2,5, çıpa+20 → 0): küçük fazlalıklar çok az cezalandırılır, çıkarım sert cezalandırılır. Granite öncesi çıpa mutlak %5 idi; taban kelemesi, hiçbir operatörün yasal minimum ücret talep etmesi nedeniyle asla cezalandırılmayacağı anlamına gelir.
// 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
Neden: Net Yield zaten teslim edilen koşullarda yüzde başına ücreti hesaba katar; bu boyut yalnızca protokol ve pazarın izin verdiğinin önemli ölçüde üzerinde ücret talep eden operatörleri işaretler. Her ücret zorunlu %20 tabanına oturduğunda, herkes burada tam puan kazanır ve boyut ayırt etmeyi durdurur — tasarım gereği: kimsenin alt çizemeyeceği bir sayı hiç kimseyi ayırt edemez.
Operatör Kalitesi12 puan maks
Ne: İki bağımsız sinyalin daha yüksek olanını alır: doğrulama tabanı (kimlik güveni) ve FTSO-türetilmiş operasyonel performans.
Nasıl: Doğrulama tabanı: küratörlü kademe (+7), iki şekilde ulaşılır — manuel olarak doğrulanmış KNOWN_VALIDATORS girişi VEYA amaçlı davranış yoluyla otomatik promosyon (v3.10: 90+ gün gözlemlendi VE 25+ operatör-toplanmış delegatör VE şu anda küçülmüyor VE öz-tahvil ≥ FIP-10 tabanı). Flaremetrics veya FSE'den otomatik keşfedilen ad → +3. Doğrulanmamış → 0. FTSO-türetilmiş: doğrusal interpolasyon FTSO puanı 50 → 4 puan FTSO puanı 100 → 12 puana kadar (50'nin altında 4'te taban). Son puan max(doğrulama, FTSO-türetilmiş)'tir — FTSO katılımı yalnızca yardımcı olabilir, asla zarar veremez.
// 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)
Neden: Tam yığın (validator + FTSO + FDC) çalıştıran ve FTSO'ya orta seviye puanla katılan güvenilir operatörleri cezalandırmayan operatörleri ödüllendirir. v3.8 max() mantığı "FTSO'yu bırakarak FlareWatch puanınızı iyileştir" gibi ters teşviki açıkça engeller. Otomatik keşfedilen katman (+3), Flaremetrics veya FSE'ye kayıtlı ancak henüz el ile seçilmemiş operatörleri vurmuş olan önceki 7→0 uçurumunu kapatır.
MIRROR Katılımı12 puan maks
Ne: Doğrulayıcının nodeID'sinin gerçekten FTSO enflasyon payını hissedarlarına sunup sunmadığı — hem delegatörlere ulaşan kesir (ücret geçişi) hem de v4.6'den bu yana, sunulan tutarın alana göre.
Nasıl: Aktif → 10 × (1 − ücret/100). Duraklatılmış → 5 × geçiş. Inaktif (hiçbir yerde katılım sinyali yok) → 0. Veri yok (gerçekten gözlemlenmeyen doğrulayıcı) → 5 × geçiş. v3.6 'aktif' sinyalini hem zincir üstü RewardClaimed(claimType=3) olaylarını hem de kanonik FSP Merkle JSON'unda claimType=3 tahsislerini içerecek şekilde genişletti — ikisi yeterli. Bu, MIRROR'u tahsis edilen ancak henüz zincir üstünde talep edilmemiş doğrulayıcıları yakalar (örn., standart talep olayını tetiklemeyen yerleşim yolu olan kendi kendine delege eden sağlayıcılar). v4.6 büyüklük bonusu (maksimum +2, boyut tavanı 12): sadece mirror-aktif doğrulayıcılar için, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2) — delegatörlere yukarı ortanca bir MIRROR oranı (ücret düşüldükten sonra) sunmak için kredi. Ağ medyan oranına tutturulmuştur, bu nedenle boyut tarafsızıdır: yüksek bir oran sunan küçük bir doğrulayıcı, bunu sunan büyük bir doğrulayıcı ile aynı krediyi kazanır.
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
Neden: MIRROR, FSP'ye katılan doğrulayıcılarda hissedarlarına otomatik olarak dağıtılır. %100 ücreti olan ve 'aktif' olan bir doğrulayıcı delegatörlere 0$ sunar; puan, sadece protokol tarafı bayrak durumunun değil, delegatörlerin gerçekten aldığını yansıtır. v4.6 büyüklük bonusu kör bir noktayı kapatır: yalnız geçiş, delegatörlere ulaşan KESRİ ölçmüştü ama TUTARI değil, bu nedenle çok daha yüksek sunulan MIRROR oranı ödeyen bir doğrulayıcı bunun için fazladan kredi kazanmadı. Şimdi kazanıyor — sınırlı ve yalnızca ağ medyanının üzerinde.
Kapasite Profili7 puan maks
Ne: Doğru boyuttaki kullanımda tepe yapan çadır fonksiyonu.
Nasıl: %0 kullanımda → 1.75. %70 kullanıma kadar doğrusal artış → 7. %100'de doğrusal inişe (%5.25 ile sınırlandırılmış). v3.7'de 8 → 7'ye yeniden ölçeklendirildi, yeni Trust trajektori bileşenlerini finanse etmek için.
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
Neden: FIP-10 maksimum delegasyonlarında olmak çekicilik hakkında POZİTİF bir sinyaldir — yeterli delegatör tarafından doldurulacak kadar güvenilir kanıtlanmıştır. v2 sınırlandırılmış validator'leri 0/5 puanladı; v3 bunu düzeltir. Doğru boyutta (kanıtlanmış çekici VE yer var) tepeyi alır. v3.7 boyut sınırını 8 → 7'ye indirdi, böylece boşalan nokta Trust'ın yeni retention + kendi tahvil trajektori bileşenlerini finanse edebilmesi için.
Topluluk Güveni11 puan maks
Ne: Çok-sinyal: delegatör sayısı + hisse-dağılımı sağlığı + uzunluk + operatör öz-bağ taahhüdü (orantılı ve mutlak) + 30 günlük tutma + öz-bağ yörüngesi + çok-düğüm operatörü toplamı.
Nasıl: Sayı sinyali (en fazla 6, OPERATOR-AGGREGATED v3.7): log-ölçekli [5, 500] delegatör → [0, 6], bir operatörün bilinen tüm düğümleri arasında toplanır. Konsantrasyon ayarlaması (±1): perakende dostu ort hisse (<500K FLR) → +1, balina-konsantre (>50M FLR ort) → −1. Uzunluk bonusu (en fazla +1, silme-muaf v3.6): 30 gün gözlenmekte → +0.5, 90+ gün → +1 — ilk-gözlenen KV silinmişse ödül-betikleri dönem varlığına geri döner. Öz-bağ taahhüt (en fazla +2 / en az −1, İKİ-EKSEN v4.7): orantılı pay VEYA mutlak büyüklüğün BETERİ tarafından krediye tutulur — orantılı ≥10% → +2 / 5–10% → +1, ve mutlak = min(1, öz-bağ ÷ 20M) × 2 ağ üst-ondayılık bağında doygunlaşır; sinyal ikisinin maksimumunu alır, yine +2'de sınırlandırılır. Sub-FIP-10 tabanı (<1M FLR) → −1. Tutma (en fazla ±0.5, YENİ v3.7): delegasyonlu FLR 30 gün üzerinde +10% → +0.5, −15% → −0.5. Öz-bağ yörüngesi (en fazla ±0.5, YENİ v3.7): operatörün öz-bağı 30 gün üzerinde +20% → +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)
Neden: Taahhüt öz-bağı eksik olduğumuz gerçek adillik sinyalidir — toplam hissenin %10'u kadar öz-bağa sahip bir doğrulayıcının FIP-10 minimumunda çalışan birinden materyal olarak daha uyumlu teşvikleri vardır. v4.7 bunu iki eksenli hale getirir: öz-bağı sadece oran olarak okumak büyük mutlak hisse koyan ve sonra delegasyon çeken operatörleri cezalandırdı, bu da oranı seyreltir ancak gerçek taahhüdü azaltmaz — seyreltilmiş oranında 20M öz-bağ o oranında sub-2M bağ ile aynı puanı aldı. Sinyal artık orantılı payın VEYA mutlak büyüklüğün BETERİ tarafından krediye tutulur, mutlak taraf ağ üst bağında doygunlaşır bu yüzden boyut basitçe puanı satın alamaz, FTSO sağlayıcı puanının zaten öz-bağı nasıl işlediği ile eşleşerek; +2 sınırı değişmedi, bu yüzden büyük taahhütlü operatörler artık buna ulaşabilir ama tavan hareket etmedi. Uzunluk kanıtlanmış izleri ödüllendirse başta penaltı vermiyor (üstte küçük bonus, altında penalti değil). Konsantrasyon riski delegatörler için önemlidir — 50M FLR'de 1 balina olan doğrulayıcı, her biri 1M'de 50 perakende olanından yapısal olarak farklıdır. İki v3.7 yörünge sinyali organik büyümeyi ve artan operatör taahhüdünü ödüllendiri. Birleşik sınır 11'dir (v3.7'de 10'dan yükseltildi onları finanse etmek için), hiçbir sinyal baskındır.
Teslimat Güvenilirliği10 puan maks
Ne: Gerçekten teslim edilen net delegasyon oranı (VRM) ile teorik temel arasındaki oran, tutarsız ödeme ödemeleri için varyans cezası. Her iki taraf da ücret sonrası nettir, bu nedenle oran gerçek teslimatı ölçer — ücret değil.
Nasıl: Parça parça doğrusal teslimat oranı: %100+ → 10, %95 → 8, %90 → 6, %85 → 4, %80 → 2, <%80 → 0'a doğru doğrusal rampa. Varyans cezası: varyasyon katsayısı × 0,5, −%30 ile sınırlandırılmış. Güven azaltıcısı, örnek boyutu < 3 dönem olduğunda tarafsız 5'e uyum sağlar. v3.9 önceden kova halinde yapılan eşikleri doğrusallaştırdı — 2 putalığına kadar sınır uçurumları artık sorunsuz.
// 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
Neden: Vaat edilen vs. teslim edilen, staker'lar için en doğrudan hesap verebilirlik sinyalidir. v3.3 iki iyileştirme ekledi: (1) başlık oranı üstel zaman ağırlıklı ortalama kullanır (son dönemler daha fazla sayılır), bu nedenle eskiden iyi teslimat yapan ancak son zamanlarda kayıp olan bir validator doğru cezalandırılır; (2) varyans cezası, tutarlı %95 teslimatçılardan salınan ~%95 teslimatçıları ayırt eder, çünkü ikincisi tahmin edilebilir getiri konusunda endişeli staker'lar için daha fazla risk taşır.
Kalan Zaman5 puan maks
Ne: Validator'ün P-Chain'deki stake-end'ine kadar olan gün sayısı.
Nasıl: < 14 gün → 0 (FIP-10 altında esasen kullanılamaz). 14-30g → doğrusal 0→2. 30-60g → doğrusal 2→3. 60-120g → doğrusal 3→5. 120g+ → 5. v3.9 önceden kova halinde yapılan eşikleri doğrusallaştırdı — sınır uçurumları (örn. 13.99g → 0, 14g → 2) artık sorunsuz.
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
Neden: Pratik sinyal — 7 gün kalan bir validator'e delegasyon yapmak, 1 yıl kalandan farklı bir önerme. v3.2 alt kısmı sıkılaştırdı: stake-end'e 14 gün içinde olan validator'ler yeni delegasyon alamazlar (FIP-10 minimum kilidi 14 gündür), bu yüzden etkili olarak stake edilemezler. Puan = 0, "şu anda stake edilemez" ile "yakında vinding down" arasında ayrım yapar.
Aktif Kesinti Cezası (v4.3)(kesinti) puan maks
Ne: Bir validator ard arda birden fazla ödül dönemini kaçırdığında, pozitif boyutların üzerine katmanlanmış düz kesinti. Simetrik Uptime güvenilirlik çarpanından farklı — kronik kararsızlığı değil, aktif kesintileri yakalar.
Nasıl: Validator'ün cache:fsp-validator-participation kaydında bitişik !uygun ön ekini inceleyin (kamu ödül-scriptleri nodes-data.json'deki en yeni-ilk dönem listesi). 0–1 ardışık kaçırma → 0 puan (varyans / tek geçici kaçırma içinde). 2 ardışık → −3 puan (gelişen kesinti). 3 ardışık → −6 puan (sürdürülen — operatör ihmalı). 4+ ardışık → −10 puan (aktif uzun kesinti). Bileşik puan, kesinti sonrasında 0'da bloke edilir.
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)
Neden: Pre-v4.3 modeli tamamen simetrik uptimeReliability çarpanına dayanıyordu — 24 dönem içinde saçılmış 5 kaçırma, ard arda 5 kaçırmışla aynı maliyete neden olur. Operasyonel olarak bunlar çok farklı sinyallerdir. Saçılmış kaçırmalar delegatörlere kronik kararsızlık hakkında bilgi verir; bir dizi onlara validator'ün ŞUAN kırık olduğunu söyler. 2026-05-14'teki Luganodes olayı — delegatörler milyonlarca FLR'yi aktif olarak taahhüt ederken ard arda kaçırılan dönemler — v4.3 sürümünün ele aldığı spesifik durumdur: aktif kesinti sinyalini delegatörler taahhüt etmeden uçuş içi arızadan kaçınabilmeleri için daha keskin puan etkisiyle yüzey. Kademeleme eğrisi, tek geçici kaçırmalara aşırı tepki vermeyi (yaygın) önlerken, sürdürülen serileri keskin bir şekilde bayrakla (nadir ve sonuç doğurucu).
Extreme-Fee Cezası (v4.5)(puana kadar −%75) puan maks
Ne: Ücret boyutunun aralığını aşan ücretler için orantılı indirim. Ücret boyutu, bir ücret ankoru 20 puan aştığında 0/7'de durur — bunun ötesinde, bileşik daha önce ücrete tamamen yanıt vermeyi bırakırdı, bu nedenle %100 ücretli bir validator (temsilcileri hiçbir şey tutmaz) yine de uptime ve MIRROR gibi ücret-kör boyutlarda 40'lı puanlara ulaşabilirdi.
Nasıl: %50 ücret veya altında sıfır — Ücret boyutu bu aralığı zaten fiyatlandırır, bu nedenle çift sayım yoktur. %50'nin üzerinde indirim, ücretle doğrusal olarak artarak, %100 ücretinde validatörün pozitif puanının %75'ine ulaşır. Puanın kendisiyle ölçeklendirilir, bu nedenle cilalanmış bir özel düğüm ve ihmal edilmiş bir düğüm her ikisi de ait oldukları yere iner: temsilci-tarafından gözlemlenen bir sıralamada altta.
// 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)
Neden: Bu, temsilciler için bir puandır. Temsilcilerinin kazandığı her ödülü tutan bir validator, uptime ne kadar iyi olursa olsun, delegasyon adayı değildir — puan bunu açıkça söylemelidir. Zincir üstü ücretin saf işlevi, her düğüme özdeş şekilde uygulanır, bizimkisi de dahil olmak üzere.
100/100 nasıl puanlandırılır — bir validator oyun defteri
v4.0'ı üreten denetim döngüsü, her boyutu maksimize etmenin sizi delegatörleriniz için gerçekten daha iyi bir validator yaptığı şekilde tasarlanmıştır. Puanınızı iyileştirmek sistemi oyun oynamak değildir — sistem tasarım gereği çalışmaktadır. İşte açık playbook, boyut başına.
Uptime — 20 puan. Sürekli olarak ≥%99.5 RPC uptime'ını koruyun VE her ödül döneminde FIP-10 minimum koşullarını geçin (açıkları kaçırmayın, medyan teslimatı iyileştirin). İki sinyal çarpılır — %100 RPC × 7/8 dönem uygun = 17.5/20, 20 değil. Bunu neden delegatörlere hizalayar: başarısız olduğunuz her dönem FIP-10'da, delegatörleriniz bu dönem için ödüllerini kaybederler.
Net Verim — 18 puan. Delegatörlerinize ≥1.2× ağ medyan APY'si sunun (ücret sonrası). En iyi yol: düşük ücret + tam FIP-10 uygunluğu, böylece delegatörler tam paylarını alırlar. Neden bu uyumludur: bu tam olarak sizin kesintinizden sonra delegatöre ulaşan dolar tutarıdır.
Ücret Makullüğü — 7 puan. Granite hard fork'undan bu yana protokol %20 minimum delegasyon ücreti uygular ve çıpa'da veya altında herhangi bir ücret (gözlenen pazar minimumu ve o tabanın ikisinden büyüğü) tam 7 puan kazanır. Bunun üzerinde ücret talep etmek, hızlandırılan bir ramp üzerinde puan kaybettirir — çıpa+10 → 4,5 puan, çıpa+20 → 0. Neden bu uyumludur: taban ücret rekabetini öldürdü, bu nedenle bu boyut artık yalnızca delegatörleri yasal minimumun üzerindeki çıkarmalardan korur; gerçek avantajınız teslim edilen Net Yield'de yaşar.
Operatör Kalitesi — 12 puan. En iyi yol: FTSO veri sağlayıcısı olarak kayıt yaptırın ve yüksek kaliteli bir yığın çalıştırın (FTSO + FDC + imzalama) — FlareWatch Operatör Kalitesi puanınız FTSO puanınızdan gelir, maksimum FTSO 100'de. Staking-only ise alternatif: +7 doğrulama tabanını koruyun v3.10 oto-promosyonu nitelendirebiliyorsanız (90+ gün gözlemlendi, 25+ delegatör, retention düşmüyor, FIP-10 uyumlu kendi tahvil) veya kurumsal altyapı olarak KNOWN_VALIDATORS'a eklendi (el ile hızlı izleme). Puan max(doğrulama, FTSO türetilmiş) alır — katılım hiçbir şekilde zarar veremez. Bunu neden hizalayar: tam yığın operatörler daha fazla ekosistem değeri sağlar; doğrulama tabanı delegatörlere daha net kimlik sinyali verir.
MIRROR Katılımı — 10 puan. FSP fiyat beslemelerini tutarlı bir şekilde gönderin, dönem başına protokol minimumlarını karşılayın (imza politikanızda kayıtlı, talep eşiği karşılandı, açıklama kaçırmayın). Makul bir ücret alın — puan (1 − ücret/100) ile çarpılır, bu nedenle mükemmel MIRROR aktif %100 ücretli bir validator bile 0 puanlar, çünkü sıfır MIRROR delegatörlere ulaşır. Bunu neden hizalayar: MIRROR delegatörlerinizin FTSO enflasyonunun payıdır. Daha düşük ücret = daha fazlası onlara ulaşır.
Kapasite Profili — 7 puan. ~%70 kullanımı hedefleyin (doğru boyutta: kanıtlanmış çekici VE yeni delegatörler için yer var). Boş validator'ler 1.75 puan alırlar; sınırlandırılmış validator'ler 5.25 puanı alırlar. Bunu neden hizalayar: puanı okuyan yeni delegatörler gerçekten delegasyon yapabileceklerini bilmek istiyorlar; doğru boyutta hem sosyal kanıt hem de kullanılabilirliği gösterir.
Topluluk Güveni — 11 puan. Maksimize etmek için altı bileşen:
  • 500+ operatör-toplu delegatöre ulaşın (maksimum sayı sinyali: +6 puan).
  • Ortalama stake'in perakende dostu kalmasını sağlayın < delegatör başına 500K FLR (konsantrasyon bonusu: +1).
  • Uzun ömürlülük bonusu için ağda ≥ 90 gün kalın (+1) — ödül-scriptleri varlığı yoluyla silinme-bağışık.
  • Büyük bir öz-bağ tutun — orantılı ≥%10 VEYA üst-ağ mutlak hissesi (~20M FLR), hangisi daha iyi puanlanırsa (uyum bonusu: +2).
  • Toplam delegeli FLR'yi 30 gün içinde ≥ %10 oranında artırın (retention: +0.5).
  • 30 gün içinde self-bond'u ≥ %20 oranında artır (yörünge: +0.5).
Neden bu uyumlu: her bileşen delegatörlerin istediği davranışa karşılık gelir — operatör parası işin içinde, organik büyüme, uzun ömürlülük, geniş topluluk katılımı. Multi-node operatörler sayım + konsantrasyon sinyalleri için toplanır (v3.7).
Teslim Güvenilirliği — 10 puan. Delegatörlere tahmin ettiğiniz APY'yi ödeyin (teslim oranı 1.00). Epoch başına varyansı en aza indirin — tahmin edilebilir ödemeler aynı ortalama ile yüksek dalgalanmadan daha iyidir (varyans cezası −%30'a kadar). Tam güven ağırlığı için 8+ epoch örnek boyutu oluşturun. Neden bu uyumlu: yaptığınız sözü tuttuğunuz var mı, tutarlı bir şekilde? Bu en doğrudan hesap verebilirlik sinyalidir.
Kalan Zaman — 5 puan. Stake-bitiş tarihinizi ≥ 120 gün uzakta tutun. Süre dolmadan çok önce yenileyin; < 14 günlük bandına kaymayın (FIP-10 kapsamında 14 gün içinde yeni delegasyonları kabul edemezsiniz). Neden bu uyumlu: daha uzun taahhüt, delegatörlere uzun vadede burada olduğunuzu gösterir.
Kısayollaştıramayacağınız zaman geçitli sinyaller: uzun ömür bonusu (90 gün gözlemlendi), otomatik kuratlık katmanı (90 gün + 25 delegatör + azalmayan tutma + FIP-10 self-bond), tutma sinyali (30 gün delegasyon geçmişi), teslim örnek boyutu (8 ödül epoch'u). İyi haber: DİĞER davranışları korumak otomatik olarak bunları zaman içinde biriktir.
Yumuşatma penceresi kısa vadede önemlidir: gösterilen puan, son 4 cron anlık görüntüsünün üstel ağırlıklı ortalamasıdır (0.5 / 0.3 / 0.15 / 0.05), bu nedenle girişlerde mükemmel 100 bile tam olarak yansıtılmak için ~20 dakikalık ardışık mükemmel cron çalışmasını alır. Sabit durum mükemmel girişler = 100; geçici iyileştirmeler yumuşatılmış olarak girilir. Ani değişim cezaları (ücret atlamaları, self-bond düşüşleri, çalışma süresi çöküşleri), algılamadan sonra birkaç cron döngüsü için 10 puana kadar indirilebilir.
Kısaca: her boyut ölçtüğü konuda dürüsttür. Doğrulayıcınız 100/100'de ise, puan da delegatörlere ağdaki en iyi doğrulayıcı sürümünü aldıklarını söyleyerek; bu tasarım niyetidir.
Kendi puanınızı nasıl doğrularsınız
Doğrulayıcılar tablosundaki her puan halka açık verilerden yeniden üretilebilir. Bir operatörseniz ve buradaki matematik gördüğünüz puanla eşleşmezse, doğru hareket kendi doğrulamanız olmadır.
En hızlı kontrol otomatik olarak çalışır. Herhangi bir doğrulayıcının puan satırını genişletin ve "Tarayıcınızda doğrulanmış" paneli yerel olarak o puanı yeniden hesapla — cron'un kullandığı tam puanlama işlevi, kullandığı tam girişler üzerinde, sunucumuza geri çağrı olmadan. Her doğrulayıcı düğüm kimliği için hiçbir terimi olmayan bir özdeş işlevle puanlandığı için, herkes kendi düğümümüzün gizli avantaj elde etmediğini doğrulayabilir. Aşağıdaki manuel izlenecek yol aynı şeyi elle yapar:
  1. Doğrulayıcınızın halka açık istatistiklerini arayın flaremetrics.io'de (operatör adınızla ara veya delegasyon adresinizi yapıştır). delegationFee, selfBond, delegatedStake ve FTSO puanını (bir veri sağlayıcısıysanız) not edin.
  2. FIP-10 uygunluğunuzu doğrulayın son 8 ödül epoch'unun her biri için github.com/flare-foundation/reward-scripts'de generated-files/reward-epoch-N/nodes-data.json altında. NodeID'nizin kaç epoch'ta uptimeEligible: true olduğunu sayın. Bu oran Çalışma Süresi boyutu çarpanınızı yönlendirir.
  3. MIRROR katılımınızı kontrol edin V2 RewardManager sözleşmesinde flare-explorer.flare.network aracılığıyla. RewardClaimed olaylarını claimType=3 ile nodeID'nize referans vererek arayın. Yakın zaman yoksa, MIRROR-inaktif olarak görüneceksiniz.
  4. Girişlerinizi yukarıdaki formüllere takın. Her boyutun kod bloğu tam olarak hangi aritmetiği yapacağınızı söyler. Boyutları toplayın, 100'e kesin ve ham cron hesaplamasını yapılan puanınız var.
  5. Görüntülenen puanınızla karşılaştırın. Görüntülenen puan v3.5'in son 4 cron anlık görüntüsü arasında üstel hareketli ortalamasını içerir (şimdiki 0.5 ağırlıklı, önceki 0.3 vb.) — tek bir çalışmanın hesaplanan puanı, görüntülenen puandan biraz farklı olacaktır. Her doğrulayıcı satırındaki puan-bölme paneli, katkıda bulunan kalıcı boyut değerlerini gösterir.
  6. Matematik uyuşmuyorsa, [email protected]'ya nodeID'niz, kullandığınız girişler ve hesapladığınız puan ile e-posta gönderin. Cevap veririz ve hata yaptıysak herkese açık olarak düzeltiriz.
Programlı erişim: herhangi bir etkin doğrulayıcı için, GET /api/validators/{nodeID}/score-breakdown'ı isabet ettirerek kalıcı bölmeyi alın — her boyutun değeri, onu üreten algoritma sürümü ve son puan geçmişi — JSON olarak. UI'daki puan-bölme paneli aynı kaynaktan okur.
Ortak operatör endişeleri
%100 RPC çalışma süresi ile çalışıyorum — neden Çalışma Süresi puanım 20/20'nin altında?
Uptime boyutu, RPC-eğrisi çıktısını epoch-uygunluk oranınızla çarpar (son 8 ödül epochu boyunca epochsIncluded / epochsObserved — v4.2'den beri tam FIP-10 minimumluk seti, yalnızca RPC-uptime değil). Bu epochlardan herhangi birinde FIP-10 minimum koşullarını yerine getiremezseniz — kısaca da olsa — reliability oranınız 1,0'ın altına düşer ve Uptime puanınız orantılı olarak ölçeklenir. Pre-v3.4'te boyut, %100 RPC uptime'ı olan her validator için 20 puan verirdi; tarihsel uygunluktan bağımsız olarak. Şimdi farklılaştırılır.
MIRROR teslim ediyorum — FlareWatch neden beni MIRROR-inaktif olarak gösteriyor?
v3.6 itibariyle MIRROR katılımı İKİ kanonik kaynaktan algılanır: V2 RewardManager'da zincir üstü RewardClaimed(claimType=3) olayları VE resmi FSP Merkle JSON'da claimType=3 tahsisleri (yayınlanan ödül dağılım verileri). Bir nodeID ya da kaynakta görünen bir nodeID aktif olarak sayılır. Pre-v3.6'da, zincir üstü akışını tek sinyal olarak kullandık; bu, standart olmayan talep yolu aracılığıyla MIRROR'ü belirleyen kendi kendine delegasyon yapan sağlayıcılar için yanlış negatifleri üretti. Ayrıca v3.6'da düzeltildi: ~95 doğrulayıcı kilitli mirror-istatistikleri, zincir üstü dizin tarafından hex20 (nodeID'nin bytes20 biçimi) altında yazılmış bir anahtar biçimi hatası — her UI araması cb58 NodeID'sine göre yapıldığında. Bu girişler vardı ve doğruydu; sadece görüntüleme katmanında görünmüyorlardı. Arama artık her tüketici arasında her iki biçimi normalleştirir (doğrulayıcılar tablosu, puan-bölme paneli, halka açık mirror-istatistikleri API'si, Verim sayfası Staking Konumları kartı, FTSO sağlayıcılar paneli). NodeID'niz v3.6 sweepinden sonra hâlâ inaktif olarak görünüyorsa, olası nedenler: (a) nodeID'niz aslında bu epoch için FSP imzalama politikanıza kayıtlı değildir, (b) epoch yayınları arasındayız (Merkle verileri epoch başına güncellenir, ~3,5 gün). NodeID'niz ile bize e-posta gönderin ve her iki kanonik kaynakta çapraz kontrol edeceğiz.
Puanım bir gece 10 puan düştü — ne değişti?
Üç şeyden biri: (1) v3.5 ani-değişim algılama, nodeID'nizde ücret atlaması, self-bond düşüşü veya çalışma süresi çöküşü işaretledi — 10 puanlık ceza, algıladığımız çalışmada uygulanır ve yeni durum sabit hale geldikçe sonraki 3 çalışma arasında azalır; (2) yumuşatma penceresi ortalamanızı aşağı çeken eski bir anlık görüntü içerir; (3) algoritma sürümü yükseltmesi yaptık (kayıt'larında algorithmVersion alanında görünür — aşağıdaki Sürümler kartına bakın). Puan-bölme paneli mevcut boyut değerlerini gösterir; önceki çalışmalara göre karşılaştırın.
Neden yüksek ücretli doğrulayıcı, diğer her şey benzer olan düşük ücretli doğrulayıcıdan daha düşük puan alır?
Net Yield boyutu (maksimum 18 puan) ücrete duyarlıdır — %0 ücretli bir doğrulayıcı ağ medyan APY'nin ~1,25 katını sunarak maksimuma yakın puan alır; %20 ücretli bir doğrulayıcı medyanın ~%80'ini sunarak daha düşük puan alır. Ayrıca Ücret Makullüğü (7 puan) v3.9'dan beri parça parça doğrusaldır (demet yok): ≤%5 tam 7 puan alır, ardından eğri yükseliş eğimi ile aşağı doğru rampa yapıyor — %10 → 6, %15 → 4,5, %20 → 2,5, %25+ → 0 (örneğin %16 ücret ~4,1 puan alır, sabit demet değeri değil). Yani 5 puanlık bir ücret farkı ~5-8 puanlık puan farkına dönüşür. Bu kasıtlıdır — delegatörler doğrudan ücrete önem verirler.
Brand-yeni doğrulayıcı ve FTSO puanı yok — neden Operatör Kalitesi sadece 7/12?
Operatör Kalitesi (maks 12 puan), tam yığın operatörleri ödüllendirir — doğrulayıcıları ayrıca üst FTSO veri-sağlayıcı yığını (FTSO + FDC + imzalama) çalıştıran. Sadece stake yapıyorsanız, +7 taban iki şekilde ulaşılabilir: (1) KNOWN_VALIDATORS listesine manuel ekleme — güvenilir altyapı operatörleri (Ankr, InfStones, Kiln, vb.) için kurumsal hızlı yol; (2) v3.10 nesnel davranışa dayalı otomatik promosyon — 90+ gün gözlemlendi VE 25+ operatör-toplanmış delegatör VE tutma düşmez VE FIP-10-uyumlu self-bond. Otomatik promosyon tamamen otomatiktir, e-posta gerekli değildir. Henüz otomatik kriterleri karşılamazsan +3 ile başlar (otomatik keşfedilen katman, Flaremetrics veya FSE varlığı profili gerektirir) ve izini takip etmek azalmadıkça +7'ye büyürsün. İvme kazandırmak için: FTSO veri sağlayıcı olarak kaydolun ve V2 protokollerini çalıştırın — puanınız FTSO 100'de maks 12 olan FTSO-türetilmiş daldan gelir. v3.8: FTSO katılımı yalnızca yardımcı olabilir, asla zarar veremez — FTSO puanınız doğrulama tabanlığının altındaysa, taban tutarsınız.
Logom var ama adım kesik NodeID olarak gösteriyor. Neden?
Operatör varlığınız Flaremetrics'te bulunmaktadır (bu yüzden sizin için bir logomuz var) ancak sağlayıcı profilinizde 'ad' alanı ayarlanmamıştır. Biz adlar yapmayız. Flaremetrics'te profile.name veya Flare Systems Explorer varlık kayıt defterinde ayarlayın ve biz sonraki cron çalışmasında alacağız. Alternatif olarak, bize doğrulanabilir bir talep gönderin (örneğin, delegasyon adresinizden imzalanan ileti) ve KNOWN_VALIDATORS'e elle ekleyeceğiz.
Doğrulayıcım FIP-10 maks delegasyonda — neden Kapasite 7/7 puanı almıyor?
Kapasite, %70 kullanımda tepe yapan çadır işlevi (7 puan), %100'de 5,25 puana kadar rampa aşağı. Tepe %100 değildir — başında olmak, delegatörlerin istese bile daha fazla stake ekleyemeyeceği anlamına gelir; bu, tabloyu okuyan yeni delegatörler için nötr-hafif negatif sinyaldir. Pre-v3'de kapasiteli doğrulayıcıları 0/5 (başarı için ceza) ile puanlandırırdık; v3 bunu nötr olarak düzeltti; v3.7 boyutun tamamını 8 → 7'ye yeniden ölçeklendirdi (Trust yörünge sinyalleri için bir puan serbest bıraktı), bugün kapasiteli 5,25/7 puanlar. Doğru boyutlu doğrulayıcılar (kanıtlanmış çekici VE büyüme yerine, %70 kullanımda tepe), tam 7 alır.
Ben gerçek operatörüm ama doğrulayıcı listesinde hiç yokum. Ne bu?
Doğrulayıcı listesi canlı P-Chain RPC'nin getCurrentValidators sonucundan oluşturulur. Orada değilseniz, P-Chain'de şu anda aktif değilsiniz, stake'niz az önce sona erdi veya bizim tarafımızda P-Chain RPC sorunu var. Cron 5 dakikada bir çalışır — staking'inizi etkinleştirdikten 1-2 döngü içinde görünmelisiniz. Bir saattir canlısınız ve kendinizi görmüyorsanız, nodeID'niz ile bize e-posta gönderin.
Puanıma itiraz edebilir veya manuel inceleme talep edebilir miyim?
Evet. NodeID'niz ve belirli bir endişe ile [email protected]'ya e-posta gönderin. Her operatöre yanıt veririz. Hareket edeceğimiz şeyler: KNOWN_VALIDATORS ekleme, MIRROR sınıflandırması düzeltme, logo/ad düzeltme, boyuta özgü matematik hataları. Hareket etmeyeceğimiz şeyler: puanı algoritma dışında elle yükseltme istekleri, rakip hariç tutma veya kötüleştirme istekleri.
Ne yapacağız ve yapmayacağız
Puanı nasıl çalıştırdığımız konusundaki belirsizliği ortadan kaldırmak için, açık taahhütler burada. Bu taahhütlerden birini ihlal edersek, belgeleyip [email protected]'ya e-posta gönderin — herkese açık olarak düzeltiriz.
✓
Daha yüksek puanlar, sponsorlu yerleştirme veya herhangi türlü uygun muamele için ödeme kabul etmeyiz. Puan, halka açık zincir verilerinden deterministik olarak hesaplanır.
✓
Doğrulayıcı başına elle kodlanmış bumplar yapmayız. Kodun hiçbir yerinde "X, onları sevdiğimiz için +5 alır" satırı yok. Aynı algoritma FlareWatch'ın kendi düğümü de dahil olmak üzere her doğrulayıcı için geçerlidir; bu tam işlevle puanlandırılır.
✓
Validatörleri kamuya açık olmayan nedenlerle tablodan hariç tutmayacağız. Liste, canlı P-Chain RPC'sinden alınmıştır ve ekranımız her aktif validatörü içerir. KNOWN_VALIDATORS için seçilmiş eklemeler yalnızca ekran adlarını doldurur — görünürlüğü kısıtlamazlar.
✓
Algoritma değişikliklerini yayınlayacağız. Her sürüm atlaması (v3 → v3.1 → v3.2 → ...) bu sayfadaki Sürümler kartında mantık ve neler değiştiğiyle belgelenmiştir. Büyük değişiklikler, uygulamanın changelog sayfasından görülebilen ek bir changelog girişi alır.
✓
Operatör e-postalarına yanıt vereceğiz. [email protected] adresine puanları hakkında önemli bir endişe gönderen her operatör, birkaç iş günü içinde gerçek bir yanıt alır.
✓
Hatalarımızı kamuya açık şekilde düzelteceğiz. Algoritma hatası, veri kaynağı hatası veya metodoloji boşluğu keşfedersek, düzeltme yayınlarız ve belgelendiririz. Sessizce yeniden sıralamayız.
✗
E-posta içeriğini gönderenin izni olmadan kamuya açık şekilde paylaşmayacağız veya operatör e-postalarını puan konuşması dışında başka amaçlar için kullanmayacağız.
✗
Algoritma değişikliği için gelecek planlarımızı önceden seçilmiş operatörlerle paylaşmayacağız — her sürüm aynı anda herkes için canlı yayına alınır.
Sınırlamalar — bu skor ne, ne değil
Bileşik bir skor yararlı bir özet olup, nesnel bir gerçek değildir. Bizimki şeffaf, sürümlendirilmiş, her validatöre —kendi validatörümüz dahil— aynı şekilde uygulanmakta ve tarayıcınızda yayınlanan girdilerden yeniden türetilmektedir. Ancak yine de editoryal yargı içerir ve yöntemin sahip olmadığı bir hassasiyeti ima etmektense tam olarak nerede olduğunu göstermek daha iyi olur.
Boyut ağırlıkları bizim yargımızdır. Çalışma süresi 20 puan ve ücret 7 puan değerindedir, çünkü güvenilirliğin çoğu delegatör için birkaç puanlık ücretin ağırlığından daha fazla önemli olduğunu karar verdik — çünkü bir formül bunu kanıtladı değil. Makul olan insanlar bunları farklı şekilde ağırllandıracaktır. Ağırlıklar sabit ve herkese açıktır, böylece tam olarak neyi seçtiğimizi görebilir ve dökümden zihinsel olarak yeniden ağırllandırabilirsiniz.
Net Verim bir sonuç, bir erdem değildir. Bir delegatörün gerçekten ne kazandığını ölçer, ağ medyanına sabitlenir — bu nedenle kısmen bir operatörün kontrolü dışındaki şeylerle şekillenir (ağ enflasyonu, ne kadar delegasyon çekmiş oldukları) ve alanın geri kalanı hareket ettiğinde hareket eder. Adil ancak daha yüksek bir ücret alan disiplinli bir operatör burada daha düşük puan alabilir ve mükemmel olabilir. Bunu "ne kazanırdım" olarak okuyun, "bu operatör ne kadar iyi" değil.
FTSO'ya bağlı boyutlar tam yığın operatörleri tercih eder. MIRROR Katılımı ve Operatör Kalitesinin bir kısmı, aynı zamanda en iyi FTSO veri sağlayıcı yığınını çalıştıran validatörleri ödüllendirir. Bu kasıtlı — bir delegatör olarak siz gerçekten FTSO'ya aktif bir validatörden MIRROR aracılığıyla daha fazla kazanırsınız — ancak bu, saf, mükemmel bir yalnızca staking validatörünün bu panonun çok üstüne ulaşamayacağı anlamına gelir. Seçim olarak yalnızca staking yapıyorsanız, bu boyutları kendi başınıza aşağı ağırllandırın.
Model katkılıdır. Boyutlar toplanır, bu nedenle bir güç bir zayıflığı dengeleyebilir — harika çalışma süresi, daha yüksek bir ücreti saygın bir skora taşıyabilir. Gerçekten diskalifiye edici arızalar (FIP-10 minimumlarını başarısız olması, yırtıcı ücretler) ayrı olarak kapısı kapatılmış olup tamamen maskelenmesi mümkün değil — her dönem minimumları başarısız olan veya %100 ücret talep eden bir validatör diğer boyutlarından bağımsız olarak panonun yakınında yer alır — ancak temel, bir veto sistemi değil, ağırlıklı bir toplamdır.
Bir rakam dokuz yargıyı gizler. Tek 0-100 rakamı bir başlangıç noktası olup, bir karar değildir. Bir puan kadar ayrı olan iki validatör anlamlı bir şekilde farklı değildir. Dökümü açın ve sizin için önemli olan boyutları ağırllandırın — rakam bu karşılaştırmayı daha hızlı hale getirmek için var, onu değiştirmek için değil.
Yöntemi nadiren ve herkese açık olarak değiştiririz. Her değişiklik sürüm artışı, yazılı bir gerekçe ve tüm alan için bir öncesi-sonrası ile gönderilir, böylece neyin hareket ettiğini ve nedenini denetleyebilirsiniz. Kendi otomatik denetimimiz sayılarımızda bir tutarsızlık tespit ettiğinde — olduğu gibi — bunu düzeltiriz ve öyle deriz.
Son puan (boyutlar nasıl birleşir)
Tüm 9 boyut doğrudan toplanır, ardından v4.3 aktif kesinti serisi indirimi çıkarılır. Toplam 100'de üst sınırı ve 0'da alt sınırı vardır. Son sayıya son yakın cron anlık görüntüleri (v3.5) ve ani değişim cezası uygulanır.
// 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)
Veri kaynakları (her giriş herkese açıktır)
Flare P-Chain RPC: validatör listesi, çalışma süresi, kendi tahvili, devredilen staking, ücret, bitiş saati, delegatör sayısı.
V2 RewardManager (claimType=3 etkinlikleri): validatör nodeID başına zincir üstü talep edilen MIRROR dağıtımı. Tip 3'te kesinlikle filtrelendi — VRM, FTSO delegasyonu veya DIRECT ödüller ile karışmadı.
FSP Merkle JSON (claimType=3 ayırımları): per epoch kime MIRROR borcu olduğunun kanonik yayınlanan kaydı (Flare'ın kendi imzalama aracının okuduğu veriler). v3.6'da ikinci yetkili kaynak olarak eklendi — MIRROR'u tahsis edilmiş ancak henüz zincir üstü talep edilmemiş validatörleri yakalar.
Flare Systems Explorer (FSE): validatör varlık kaydı, ekran adları, logolar, FTSO V2 protokol katılım bayrakları.
Flaremetrics sağlayıcı verileri: FTSO puanı, ödül oranı, doğruluk, V2 özellikleri, varlık-nodeID bağlantısı.
Flare reward-scripts (GitHub): validatör başına en son N ödül epoch'u için teslim edilen APY. Delivery boyutunu yönlendirir.
FlareWatch kurasyonu: KNOWN_VALIDATORS haritası (~110 giriş). Güvenilen altyapı operatörleri için Adlar + Operatör Kalitesi temeli.
Puanda olmayan şeyler
• Kendi promosyonu veya ücretli yerleştirme. Hiçbir operatör daha yüksek bir puan için ödeme yapamaz veya sponsor olamaz.
• Elle kodlanan validatöre özel artışlar. Kodun hiçbir yerinde "X alır +5 çünkü biz onları seviyoruz" satırları yoktur. Aynı algoritma FlareWatch'un kendi düğümü de dahil olmak üzere her validatöre uygulanır ve bu tam fonksiyon tarafından puanlandırılır.
• Öznel altyapı kalitesi. Uptime SLA'larını, coğrafi dağıtımı veya donanım özelliklerini değerlendirmeye çalışmayız. Altyapı sınıfını iddia etmek istiyorsanız, üst FTSO + FDC yığınını çalıştırın ve Operatör Kalitesi boyutu bunu yansıtacaktır.
• FlareWatch'a kilitlemeler veya taahhütler. FlareWatch'u başka bir araçla kullanmaya karşı uygun puanlandırma yok.
Operatör geri bildirimi
Validatörünüzün puanında bir şey mi ters gidiyor? NodeID'niz ve endişeniz ile [email protected] adresine e-posta gönderin. Her operatöre yanıt veririz. Harekete geçeceğimiz yaygın istekler:
  • Operatörünüzü KNOWN_VALIDATORS'a ekleme (doğrulama ile).
  • MIRROR-inaktif sınıflandırması hata içinde olduğuna inanıyorsanız gözden geçirme.
  • Logo / ekran adı düzeltmeleri.
  • Genel algoritma eleştirisi.
Kaynaklar ve referanslar
Puanın her girdisi kamuya açık, doğrulanabilir Flare ekosistemi kaynaklarından gelir. Herkes iddialarımızı bu birincil kaynaklara karşı kontrol edebilir ve ham verilerden matematik'i yeniden üretebilir. Bu sayfa ile upstream kaynakları söyledikleri arasında bir tutarsızlık fark ederseniz, [email protected] adresine e-posta gönderin ve düzelteceğiz.
Flare Network protokol belgeleri ↗https://docs.flare.network
Yetkili protokol dokümanları. FTSO V2, FSP, P-Chain doğrulaması, FAssets ve Flare yığınının geri kalanını kapsar.
Flare yönetim portalı (FIP'ler) ↗https://proposals.flare.network
Flare İyileştirme Önerileri — FIP-05 (delegasyon faktörü), FIP-10 (validatör minimum koşulları: 1M FLR kendi tahvil tabanı, %80 uptime tabanı, 14 günlük minimum kilit) ve bu sayfada alıntılanan tüm diğer kurallar için doğruluk kaynağı.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
FTSO veri sağlayıcılarının, varlık adreslerinin, P-Chain nodeID bağlantılarının ve FIP-10 minimum koşul bayraklarının resmi Flare tarafından yönetilen kaydı. Operatör Kalitesi ve güvenilirlik verimiz için birincil kaynak.
Flaremetrics ↗https://flaremetrics.io
Bağımsız Flare ekosistemi metrik sağlayıcısı. FTSO sağlayıcı puanlandırması, ödül oranları, doğruluk metrikleri, V2 protokol katılım bayrakları ve validatör-varlık adres eşlemeleri kaynağı. Kamu REST API'larını tüketiyoruz.
Flare Foundation reward-scripts deposu ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation tarafından yayınlanan per-reward-epoch JSON, per-validatör uygunluğunu, uptime-uygunluğunu ve teslim edilen ödülleri gösterir. Delivery Reliability boyutunu ve Uptime için v3.4 epoch-uygunluk oranını yönlendirir.
Flare Blok Gezgini ↗https://flare-explorer.flare.network
Tüm zincir üstü durumun salt-okunur tarayıcısı. RewardManager v2'nin RewardClaimed olaylarını (claimType=3 MIRROR için), doğrulayıcı hisse toplamlarını, ücret değişikliklerini ve geri kalanını herkesin doğrulamasını sağlar.
Flare Portal (staking) ↗https://portal.flare.network/staking
Resmi staking arayüzü. Mevcut self-bond / delegated hisse miktarları ve P-Chain RPC okumaları için kullandığımız doğrulayıcı bitiş zamanlarının yetkili kaynağı.
Flaremetrics public API (FTSO sağlayıcıları) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Cron işimizin tükettiği tam endpoint, varlık profillerini, FTSO puanlarını, ücretleri ve nodeId'leri onaltılık formatta döndürür. Herkes doğrudan erişebilir.
Flaremetrics public API (node kayıtları) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Onaltılık → cb58 NodeID dönüştürme tablosu. Bunu sayfalandırarak, her cb58-format tüketicisini yöneten varlık-NodeID aramasını oluştururuz.
Özel veri yok, kapalı kaynaklı modeller yok. Puanlama algoritması FlareWatch kod tabanında services/validators/scoring.ts dosyasında uygulanmıştır. Uygulamayı doğrudan incelemek isteyenler (yukarıdaki metni ve formülleri okumak yerine) veya kendi kullanımları için çatallak isteyenler — erişim istemek için [email protected] adresine e-posta gönderebilirler. Gerçek talep varsa dosyayı bağımsız bir açık kaynaklı paket olarak yayınlayacağız.
Puanlar nasıl güncellenir
/api/cron/refresh-validators adresindeki cron, her etkin doğrulayıcının puanını her 5 dakikada yeniden hesaplar. Girdiler (P-Chain RPC okumaları, Flaremetrics, FSE, reward-scripts) her çalıştırmada yeniden alınır.
v3.5, son 4 cron anlık görüntüsü arasında düzleştirme ekledi (ağırlıklar: 0.5 / 0.3 / 0.15 / 0.05), böylece görüntülenen puan geçici giriş gürültüsünde sallanmaz. Ham cron-hesaplanan puan yine de gelecekteki düzleştirme matematik için kalıcıdır ve puan-döküm paneli her boyutun mevcut değerini gösterir, böylece neyin değiştiğini görebilirsiniz.
Algoritma sürümü her önbelleğe alınmış puan kaydında damgalanır. Yeni bir sürüm yayınladığımızda, her puan yeni etiketi alır. Aşağıdaki Sürümler kartı her değişikliği belgelemektedir.
Flare'nin ceza modeli

Flare, doğrulayıcı hissesini kesmiyor. Doğrulayıcı kötü davranışı için tüm ceza mekanizması ödül kaybı artı FIP-10 passes sistemidir. İkili imzalama kesimi yok, çifte harcama kesimi yok, izlemesi gereken hisse yok etme olayı yok. FIP-10 minimum koşullarında başarısız olan doğrulayıcılar bu epok'un ödüllerini kaybeder (sıfır geçişte tam kaybetme, aksi takdirde başarısız oldukları protokol başına bir geçiş kaybetme); sahip oldukları anapara dokunulmaz.

Bu, puanın "kesme geçmişi" boyutuna sahip olmadığı anlamına gelir — izlenecek böyle bir geçmiş yoktur. BIZ izleyin EDİYORUZ her minimum başarısızlığın sonucu: doğrulayıcı bu epok'ta sıfır kazandı, bu epochsIncluded / epochsObserved içinde yakalanır. 2026-05-14 tarihindeki v4.2 güncellemesi, puanın güvenilirlik çarpanını tüm FIP-10 minimums setinde bu oranı kullanacak şekilde genişletti (uptime, FSP imzalama, FTSO gönderim oranı, FDC katılımı), bu nedenle herhangi bir minimum'da başarısız olan bir doğrulayıcı, hangi eksen başarısız olursa olsun Uptime boyutunda orantılı olarak cezalandırılır.

FIP-10 minimum eşikleri, dev.flare.network/network/fsp/rewarding adresinden alınan: staking %80 uptime + 1M FLR aktif self-bond gerektirir; FTSO anchor feeds, tahminleri fikir birliği medyanının %0.5 içinde %80 turunda gerektirir; FTSO blok-gecikmesi feeds, beklenen güncellemelerin %80'ini göndermek gerektirir; FDC, oylama turlarının %60'ına katılmayı gerektirir. %80 uptime + 1M self-bond tabanını karşılayan ancak 3M / 15M kazanç eşiklerinin altında olan doğrulayıcılar yine de ödül alırlar ancak geçiş biriktiremezler — bu kartın passEligibility: "at-risk" sınıflandırması aracılığıyla ortaya çıkan gri bölge.

Sürümler
v4.8 (2026-09-17) — Ödül dönemleri gerçek uzunluklarında yıllıklandırıldı. Ölçülen her doğrulayıcı oranı (teslim edilen APR, delegasyon, MIRROR, operatör kendine bağlı verim) 3,19 günlük ödül döneminde yıllıklandırıldı; bu değer 2026-04-04 tarihinde eklendi ve blok zaman damgalarından ölçüldüğü şeklinde tanımlandı, ancak hiçbir şey bunu ölçmedi. Flare ödül dönemleri tam olarak 3,5 gündür — FlareSystemsManager'ın rewardEpochDurationSeconds değeri 302.400 döndürür ve zincir üzerindeki her dönem başlangıcı 3,500 gün aralıklarla başlar — dolayısıyla her ölçülen oran beş buçuk ay boyunca yaklaşık %9,7 yüksek okundu, kendi değerimiz de dahil olmak üzere. Uzunluk artık bu sözleşmeden okunmaktadır. Her ölçülen APR aynı faktörle düşer, 3,19 ÷ 3,5 (ağ medyanı %9,08 → %8,28; FlareWatch %8,17 → %7,45). Puanlar: yalnızca Teslim Güvenilirliği hareket eder, çünkü ölçülen oranı doğrulayıcının ücreti için teorik oranla karşılaştırır. Şişirilmiş taraf doğrulayıcıların %91'ini 1,0 sınırında koymuştu, yani görünüşte mümkün olandan daha fazla ödeme yapıyordu; gerçek dönem uzunluğu ile medyan teslim edilen-teorik oranı 0,990'dır. Göndermeden önce ölçülen verilere sahip 168 doğrulayıcı üzerinde simüle edildi: medyan −0,32 puan, 146'sı 1 puandan az kaybediyor, 13'ü zaten ücret-ima edilen oranın altında teslim edilen 2–3,5 kaybediyor. Community Trust uzunluk yedek dönüştürülmesi aynı uzunluk ile dönemleri günlere dönüştürür ve düzeltildi de; hiçbir puanı hareket ettirmez, çünkü en fazla 8 dönem (28 gün) görür, her iki şekilde de 30 günlük adımının altında. İmzalı performans attestasyonları aynı yanlış uzunluğu kullandı; yeniden hesaplama spesifikasyonu rev.3'e revize edildi ve rev.2 hata açıklanmış şekilde kelimesi kelimesine tutuldu.
v4.7 (2026-08-19) — Community Trust boyutunda iki eksenli öz-bağ. Trust operatör öz-bağını sadece ORAN olarak krediye tutuyor (kendi bağ ÷ toplam hisse), bu yüzden delegasyon tarafından seyreltilmiş büyük öz-bağ o oranında küçük bağ ile aynı puanı aldı — puan gerçek taahhüt edilen sermayeye kör kaldı. Canlı ağda 178 doğrulayıcıdan 61'i <10% oranında ≥10M öz-bağ tutuyor, bu yüzden alanın üçte biri eksik krediye tutuldu. v4.7 öz-bağı orantılı payın VEYA mutlak büyüklüğün BETERİ tarafından krediye tutuyor (≥10% → +2, 5–10% → +1, değişmedi) VEYA mutlak boyut (min(1, öz-bağ ÷ 20M) × 2, ağ üst-ondayılık P-chain bağında doygunlaşır), maksimumunu alır ve alt-sinyali yine +2'de kapatalım — Trust sınırı (11) ve bileşik sınırı (100) değişmedi, ve sub-FIP-10 boş tabanı (<1M FLR → −1) değişmedi. FTSO sağlayıcı puanının zaten kullandığı iki eksenli öz-bağı yansıtır. Tüm 178 doğrulayıcı üzerinden alan çapında öncesi/sonrası, gönderimden önce arşivlenmiş: 58 yukarı, hiçbiri aşağı, hiçbir puan bir noktadan fazla yükselmez, ve sıralamanın tepesi değişmez. Kendi düğümümüz bir puan yükseliyor (83 → 84) diğer iyi sermayeli operatör ile aynı kural tarafından — hiçbir terim bizi adlandırmaz.
v4.6 (2026-08-13) — MIRROR sunulan-büyüklük bonusu. MIRROR boyutu eski baştan sadece geçişi (delegatörlere ulaşan MIRROR'un kesri, = 1 − ücret) ve katılım durumunu puanlandırıyordu — sunulan TUTAR'a karşı kördü. Çok daha yüksek sunulan MIRROR oranı (mirrorAPY, ücret düşüldükten sonra) ödeyen bir doğrulayıcı, alan ortalamasından bunun için kredi kazanmadı, bu nedenle gerçekten daha yüksek getirili bir düğüm, getiri boyutlarında daha düşük getirili bir düğümün altında yer alabilir. v4.6 küçük, sınırlı, medyan merkezli bir bonus ekler: sadece mirror-aktif doğrulayıcılar için, clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2). Yalnızca ağ medyan oranının 1.2 katı üzerinde sunulan tutarlar bunu kazanır ve maksimum +2 olur, MIRROR boyutu tavanını 10'dan 12'ye yükseltir (bileşik hala 100'de sınırlanır). Hacim değil ağ medyan ORANI'na tutturulmuştur, bu nedenle yapı gereği boyut tarafsızıdır: canlı alanda bonus self-bond ile NEGATİF olarak korelasyon gösterir (yüksek oranlar sunan küçük doğrulayıcıları destekler, büyük olanları değil). Tüm aktif doğrulayıcılar üzerinde ağ çapında öncesi-sonrası, sevkiyattan önce arşivlendi — çoğu doğrulayıcı hareket etmez ve liderlik tablosunun tepesi değişmez. Aynı formül her doğrulayıcıya, kendi düğümümüze de dahil olmak üzere uygulanır.
v4.5 (2026-07-16) — Aşırı ücret viability penaltısı. Fee Reasonableness boyutu, bir ücret pazar ankorunu + 20 puan aştığında 0/7'de doygunluğa ulaşır (~Granite sonrası %40); buradan %100 ücrete kadar composite tepki vermemeyi durdurdu, bu nedenle %100-ücret validator'ı — delegatörlerin HİÇBİR ŞEY tutmadığı — hala fee-blind boyutlarında 40'larda puan aldı. Delegatör yönelimli bir puanda bu sonuç yakın-diskalifiye edici, mid-table değildir. v4.5, pozitif boyutların toplamının bir kesri olarak uygulanan bir composite penalti ekler: %50 ücret veya daha düşükte sıfır (Fee boyutunun zaten fiyatlandırdığı aralıkta çift sayım yok), ardından %100 ücrefte doğrusal olarak puanın %75'ine kadar ramping yapar. %100-ücret düğümü ~10/100'ün etrafında yer alır — hala listelenir ve sıralanır, açık şekilde delegasyon adayı değildir. On-chain ücretin saf bir fonksiyonudur, her validator için aynı, kendi düğümümüz de dahil.
v4.4 (2026-07-11) — Granite taban-farkında ücret çıpası. Granite hard fork (Flare, 2026-07-14) %20 minimum validatör delegasyon ücreti uygular. Ücret Makullüğü çıpası maks(gözlenen minimum aktif ücret, protokol tabanı) olur: yasal minimumda veya altında her ücret tam puan kazanır ve yalnızca bunun üzerindeki ücretler mesafeye göre cezalandırılır. Mantık: başlangıçtaki bahisler için mirasçılık akışın yukarısında belirtilmediğinde, mirasçılık bir %2 (veya fork öncesi %0) kalıntısına sabitleme, protokole uyumlu %20 operatörleri neredeyse çıkarmacı olarak puanlandırmış olacaktı — ve Net Yield tarafından teslim edilen koşullarda fiyatlandırılan bir ücret deltasını çift sayacaktı. Başka hiçbir boyut değişmedi. Tüm grup tabana ulaştığında, boyut düzgün şekilde tam puan verir — kohort tabanında rekabet edemediğinde ücret sayılmayı durdurur.
v4.3 (2026-05-14) — Aktif Kesinti Cezası sabit bir boyut sonrası kesinti olarak eklendi. Mevcut uptimeReliability çarpanı simetriktir — 24 epok arasında dağılmış 5 miss, bir satırda 5 miss ile aynı maliyete sahiptir — ancak operasyonel olarak bunlar çok farklı sinyallerdir: dağılmış missler kronik dengesizliği, bir streak doğrulayıcının ŞU AN arızalı olduğu anlamına gelir. v4.3, doğrulayıcının son katılım geçmişinin başında uygun olmayan epok'ların bitişik çalışmasını okur ve 0–1 ardışık miss için 0 puan (normal varyans / tek geçici miss), 2'de 3 puan (gelişen kesinti), 3'te 6 puan (sürdürülen kesinti) ve 4+'da 10 puan (etkin uzun kesinti) kesintisi yapılır ve bileşik 0'da taban alınır. Güvenilirlik çarpanının yerine değil, üzerine katmanlaştırılır, çünkü ikisi farklı tehlikeleri yakalar. Tetikleyici: 2026-05-14'teki Luganodes sınıfı olayı; birden fazla son epok bir satırda miss edildi ve delegatörler aktif olarak hisse taahhüt ediyordu; streak sinyali delegatörlerin taahhüt etmeden önce uçuşta bir başarısızlığı görmesini sağlar. Cezalar, puan-döküm panelinde kendi bölümü olarak işlenir, böylece 9 pozitif boyut yine de 100'e toplar.
v4.2 (2026-05-14) — İKİ ilgili düzeltme, Luganodes'in puanı hakkında @aucc_official'dan (AU) gelen halka açık bir düzeltmeye yanıt olarak birlikte yayınlandı. (1) deliveredAPY hesaplaması artık oran-kazanç-epok'u `epochsIncluded / epochsObserved` ile çarpıyor, böylece görüntülenen APR, delegatörün gözlem penceresi boyunca fiilen aldığı ETKİLİ oranı yansıtıyor — bir doğrulayıcı FIP-10 minimums'da başarısız olduğunda sıfır kazanma epok'ları dahil. Önceki uygulama yalnızca kazanma epok'larını ortalaması aldı ve doğrulayıcılara iyi-epok oranını göstererek minimum başarısızlıklarını maskeledi. (2) Uptime boyutunun güvenilirlik çarpanı yalnızca uptime'dan (epochsUptimeEligible / epochsObserved) tüm FIP-10 minimums setine (epochsIncluded / epochsObserved) genişledi. %100 RPC uptime'ı olan ancak FSP imzalamada veya FTSO gönderim oranında başarısız olan bir doğrulayıcı artık hangi minimum'da başarısız olursa olsun Uptime boyutunda orantılı bir hit alır. Luganodes'te net etki: deliveredAPY %10.86'dan ~%5.43'e düşer (gerçek yarı ödeme gerçekliğine uyar), uptime güvenilirliği 1.0'dan 0.5'e düşer, puan materyal olarak düşer. Aynı düzeltme `epochsIncluded < epochsObserved` olan her doğrulayıcı için geçerlidir — ağ genelinde bu daha önce gizli olan gerçek katılım-kalitesi boşluklarını ortaya çıkarır.
v4.1 (2026-05-14) — Net Yield boyutu teorik APR'den (formül: gross_APR × (1 − fee)) MEASURED deliveredAPY'ye Flare Foundation reward-scripts'ten değiştirildi, hiçbir ölçüm geçmişi olmadığında doğrulayıcı başına teorik geri dönemin. Tetikleyici: FIP-16'nin enflasyon azaltması (5% → 3%) 2026-05-14'te canlıya geçti ve teorik formülün uygun hisse paydası zincir üstü gerçeklikten sapmış, böylece teorik APR ağ genelinde teslim edilen getiriyi ~2× az rapor etti. Ölçülen-ilk'e geçmek puanın girdisini paylaştıranların fiilen aldığı şeylerle yeniden hizalar. networkMedianAPR ankoru aynı ölçülen-ilk metodolojisi kullanılarak da yeniden hesaplandı, böylece oran karşılaştırması her iki tarafta da tutarlı kalır — puanlar kabaca sabit olmalıdır (ağ medyanında bir doğrulayıcı halen ~12/18 puan alır, vb.), sadece formül çıkışı yerine gerçek teslim edilen oranlar temelinde.
v4.0 (2026-05-11) — Ana sürüm. v3.7-v3.10 döngüsü kumulatif olarak puanlama sisteminin yapısal bir yeniden yazılmasını oluşturur ve çok büyüktür. Özet: iki boyutun sınırları değişti (Trust 10→11, Capacity 8→7); Operator Quality formülü max(verification, FTSO-derived) olarak yeniden yazıldı, böylece katılım zarar veremez; kalan dört bucketed boyut (Uptime, Fee, Delivery, Time Remaining) sınır uçurumlarını ortadan kaldırmak için linearize edildi; üç yeni puan bileşeni eklendi (30 günlük delegasyon tutma, 30 günlük self-bond yörüngesi, auto-promotion to curated tier); multi-node operator aggregation Trust count + concentration için tanıtıldı; longevity artık reward-scripts epok varlığı aracılığıyla silme-bağışık; ve iki sapkın teşvik ortadan kaldırıldı (Operator Quality FTSO-katılım cezası ve Uptime %95 ters-V uçurumu). Puanın her girdisi artık harici olarak doğrulanabilir — hiçbir editöryel karar yük taşıyor değil. Doğrulayıcılar gözlemlenebilir davranış aracılığıyla +7 curated-operator basleline kazanabilirler (90+ gün gözlemlenmiş, 25+ delegatör, tutma düşüşte değil, FIP-10-uyumlu self-bond), e-posta-takım gerekli değil. v3.7-v3.10 girdilerini bu sürümü oluşturan tanecikli değişiklikler için aşağıya bakın.
v3.10 (2026-05-11) — Puandaki son kuratörlük boşluğu kapattı. Operator Quality'deki +7 curated-operator basleine daha önce bizim KNOWN_VALIDATORS listesine manuel dahil olmayı gerektirdi, bu v3.7-v3.9 denetim döngüsünden sonra kalan tek anlamlı editöryel kararıydı. v3.10 nesnel bir auto-promotion yolu ekler: 90+ gün FlareWatch gözlemi, 25+ operator-aggregated delegatör, tutma düşüşte olmayan (30 günlük düşüş ≤ %15) ve FIP-10-uyumlu self-bond ile herhangi bir doğrulayıcı otomatik olarak +7 basleine niteliği alır — manuel inceleme gerek yoktur. KNOWN_VALIDATORS 90 günlük pencereyi henüz biriktirememiş kurumsal operatörler için hızlı pist olarak kalır (bir başlatma günü Ankr veya Kiln girişini düşünün), ancak tipik durum artık tam otomatiktir. Dört kriter tümü zincir üstü türemiş veya zincir üstü-yakındır (delegatör sayı, tutma, self-bond) artı bizim kendi gözlem zaman damgası — hiçbir şey öznel, e-posta-takım kapısı yok. Net etki: bir doğrulayıcı davranış yalnız +7 katmanını kazanabilir. Ağdaki çoğu kurulan operatör bugün zaten kriterleri karşılamaktadır.
v3.9 (2026-05-11) — Kalan dört bucketed boyut arasında sınır-uçurum temizliği, puanın her bölümünü adılık için denetledikten sonra. Düzeltilen: (1) Uptime eğrisinde %95'te ters-V uçurumu — %94.99 → %95.00 uptime'dan gitmek 4 puan kaybetti (%95-99% şubesi 0'da başladı, alt şubenin max'ı 4 ile eşleşme yerine). Operator Quality'de yeni düzelttiğimiz geri teşvik türü ile aynı şekil (v3.8). (2) Fee Reasonableness eşikleri linearize edildi — pre-v3.9, %0.01 ücret artışı bucket sınırı arasında 2.5 puana kadar kaybedebilirdi. Şimdi parçalı lineer, bucket değerlerini sınırlarda koruyan giderek dik eğimlerle (düşük ücretler zayıf cezalandırıldı, kazançcı ücretler sert cezalandırıldı). (3) Delivery Reliability deliveryRatio eşikleri linearize edildi — aynı pattern, 2 puntaya kadar uçurumlar ortadan kaldırıldı. (4) Time Remaining bucket eşikleri linearize edildi — daha küçük uçurumlar (%14 günlük sınırda max 2 puan) ancak küçük bir boyutta yine mevcut; şimdi düzgün. Net Yield, MIRROR Participation ve Capacity Profile denetlendi ve adil olarak onaylandı (zaten lineer/sürekli). Toplam sınır değişmedi 100. Tasarım gereği puan gerilemeleri yok; puanları hareket eden tek doğrulayıcılar, bir önceki bucket sınırının tam olarak oturmuş olanlarıdır.
v3.8 (2026-05-11) — Operator Quality boyutu bir adılık gözdengeçirmesinden sonra denetlendi ve yeniden yazıldı. Üç düzeltme birlikte yayınlandı. (1) Sapkın teşvik ortadan kaldırıldı — mid-tier FTSO puanı (ör. 50) olan bilinen bir operatör 4 puan aldı, ancak FTSO'dan tamamen bırakanı aynı operatör 7 puan aldı. v3.8 altında puan max(verification baseline, FTSO-derived), böylece FTSO katılımı yalnız yardımcı olabilir, asla zarar veremez. (2) Ara bir doğrulama katmanı tanıtıldı — Flaremetrics veya FSE'den otomatik olarak bulunan adlara sahip operatörler (ancak henüz curated KNOWN_VALIDATORS haritasında değil) 0 yerine +3 alırlar, önceki 7→0 uçurumunu yumuşatır. (3) Doğrulama düşük FTSO puanını kazandığında her iki sinyali döküm detayında ortaya çıkarır (ör.
v3.7 (2026-05-11) — Community Trust boyutu bir operatör-adılık gözdengeçirmesinden sonra denetlendi ve genişletildi. Üç ekleme: (1) Multi-node operatör aggregation — birden fazla P-Chain node çalıştıran operatörler (AU, FlareBus, Aureus Ox, Kiln, vb.) artık delegatör sayıları ve toplam hissesi Trust count + concentration sinyalleri için aggregated; bu nedenle aynı delegatör tabanını birden fazla node'a dağıttıkları için cezalandırılmaz. (2) 30 günlük delegasyon tutma sinyali (±0.5 puan) — büyüyen / sabit / küçülen doğrulayıcıları açılır pencere karşılaştırması kullanılarak ayırt eder. Anlık görüntü yalnız Trust boyutu pre-v3.7 bunları ayırt edemedi. (3) 30 günlük self-bond yörüngesi (±0.5 puan) — zaman içinde self-bond'ı artan operatörleri ödüllendirin, sessiz olarak ortadan kaldıranları cezalandırın. Tek bir büyük damla yalnız yakaladığı ani değişim cezasından farklı. Sınır yeniden dengelendi: Trust 10 → 11, Capacity 8 → 7. Denetimden hata düzeltmeleri: (a) sıfır self-bond artık FIP-10 alt cezası doğru vuruşu (' selfBondFLR > 0' kapısı tam 0 self-bond'ın cezadan kaçmasını sağladı, önceki). (b) FIP-10 tabanı ve %5 arasında küçük self-bond oranları artık döküm panelinde gerçek yüzdeyi işler, böylece operatörler +1 / +2 katmanlarına kapatmaya nelerin kapatılması gerektiğini görürler. (c) longevity bonusu artık wipe-bağışık — ilk-gözlenen KV yapay olarak fresh olduğunda reward-scripts epok varlığına düşer.
v3.6 (2026-05-11) — İki MIRROR saptama düzeltmesi, birlikte yayınlandı. (a) Algılama artık iki kanonik kaynaktan okur: V2 RewardManager'dan on-chain RewardClaimed(claimType=3) olayları VE resmi FSP Merkle JSON'daki claimType=3 ayırmaları (Flare'nin kendi imzalama aracının tükettiği aynı veri). Her iki sinyal yeterlidir — MIRROR tahsis edilmiş ancak zincir üstü henüz talep edilmemiş doğrulayıcıları yakalar. (b) Merkle'ye karşı çapraz kontrol ayrı bir anahtar-format hatasını ortaya çıkardı: validators:mirror-stats mixed hex20/cb58 NodeID anahtarlarına sahipti (zincir üstü indexer, bir doğrulayıcı henüz bizim curated isim listesinde olmadığında hex yazıyordu), oysa her UI tüketicisi yalnızca cb58 tarafından baktı — bu nedenle ~95 doğrulayıcının durumu görüntüye görünmez. Araştırma artık validators tablosu, puan-döküm paneli, mirror-stats public API, Yield sayfası Staking Positions kartı ve FTSO sağlayıcıları paneli arasında her iki formatı normalleştirir. Etkilenen doğrulayıcılar sonraki cron döngüsünde MIRROR Participation + Operator Quality boyutlarında ve genel FlareWatch Score'da 9-10 puan yüksek gördüler. FTSO-sağlayıcısı raporu aracılığıyla keşfedildi (FlareBus, 2026-05-11) — kredi ve teşekkür. Geri bildirimi ağın her delegatörünün görünümünü iyileştirdi, sadece kendi puanları değil.
v3.5 (2026-05-09) — Net Yield artık ağ APR'ye karşı medyan-bağlantılı (bir medyan'daki doğrulayıcı 12/18 puan alır, en iyi performans gösterenler 18'e ulaşır, alt-çeyrek 0'a düşer). Trust boyutu self-bond hizalamasını dördüncü bileşen olarak absorbe etti (orantılı self-bond oyunu-cilt için kaldırır; FIP-10 tabanı altında küçük ceza alır). Yeni "NEW Xd" rozeti, FlareWatch'ın yalnızca <30 gün boyunca gözlemledikleri doğrulayıcıları ortaya çıkarır, böylece staking'ciler izleme geçmişinin ince olduğunu görebilir.
v3.4 (2026-05-09) — Uptime boyutu artık anlık RPC uptime'ı tarihsel FIP-10 epok-uygunluk oranıyla karıştırıyor. Pre-v3.4 boyutu ayrım yapmıyordu (%92.9 doğrulayıcısının %100 RPC uptime'ı vardı). Son 8 reward-scripts epok'u arasında epochsUptimeEligible / epochsObserved'ten türetilen Güvenilirlik oranı — doğrulayıcıları occasionally fail FIP-10 minimum conditions'dan sometimes'ı anlamlı bir şekilde ayırt eden zaman-serisi sinyali.
v3.3 (2026-05-09) — Delivery boyutu artık üstel zaman ağırlıklı ortalama oranı (son epok'lar daha fazla sayılır, azınma sabiti 0.85) ve varyans cezasını (varyasyon katsayısı × 0.5, sınırlı −30%) uygular. Per-epok reward-scripts verilerinden hesaplanır — örnek boyutu mevcut güven dampener olarak taşınır.
v3.2 (2026-05-09) — Multi-signal Community Trust (count + concentration + longevity); ilk-gözlenen-FlareWatch'a-FlareWatch'ta KV'de kalıcı; stake-end edge-case (imparatorlar 14 gün içinde bitiş 14 günü 14 gün içinde Time Remaining'de 0 puan olması nedeniyle FIP-10 altında yeni delegasyonları kabul edemez); methodology sayfa halka açık; operatör geri bildirim kanalı yüzey; algoritma sürümü her önbelleğe alınmış puan kaydında damgalanmıştır.
v3.1 (2026-05-09) — Wired Delivery boyutu reward-scripts verilerinden; smoothed Operator Quality (lineer interpolation), Capacity (tent işlevi) ve Trust (log scale); FSP-known + zero claimType=3 yeniden sınıflandırıldı MIRROR "inactive" yerine "no data"; persisted scoreBreakdown server-side böylece istemci tam girdileri yeniden hesaplamaz.
v3 (2026-05-09) — Binom kimlik bonusu sürekli Operator Quality ile değiştirildi. FTSO Katılımı bağımsız bir boyut olarak eklendi. Sınırlı kapasiteyi 0-pt cezası yerine nötr yaptı. APY/fee çift-sayımı Net Yield aracılığıyla kaldırıldı. Yeniden kalibre edilmiş bandlar (Top tier 90+, Strong/Good/Acceptable/Below median).
v2 (pre-2026-05-09) — Orijinal 8-boyutlu puan (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). APY/Fee çift-sayımı, ikili kimlik cezası, sınırlı-kapasite cezası, no MIRROR boyutu nedeniyle kullanımdan kaldırıldı. Tarihi referans için belgelenmiş.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.