FTSO Sağlayıcısı Puanı Metodolojisi

Algoritma sürümü: v4.11 · Son güncelleme: 2026-07-04

FlareWatch, her FTSO veri sağlayıcısına 12 puanlı boyut üzerinden 0–100 bileşik puan atanır. Matematik deterministiktir, girdiler genel Flare zinciri üzerinde ve Flare ekosistemi verilerinden alınmıştır.[Flaremetrics] [FSE] [Flare Explorer], ve aynı algoritma her sağlayıcı için geçerlidir — FlareWatch'ın kendi FTSO sağlayıcısı dahil, bu tam işlevle özel tedavi olmaksızın puanlanır. Bu sayfa, delegatörler ve operatörlerin puanın nasıl hesaplandığını ve her değerin neden seçildiğini tam olarak görebilmeleri için her boyutu ve eşiği belgelemektedir. Her talep burada birincil yukarı akış kaynağına bağlanır — bkz. Kaynaklar & referanslar altta.

Kapsam: bu sayfa FTSO sağlayıcı puanını belgelendirir — validators sayfasında delegasyon modu'nda gördüğünüz (WFLR'yi FTSO veri sağlayıcılarına FTSO enflasyon payı için delegasyonu yapma). staking modu'nda gösterilen validator puanı (FLR'yi P-Chain validatörüne VRM + MIRROR ödülleri için delegasyonu yapma) validatör operasyonları — çalışma süresi, ücret, güvenilirlik vb.'ne odaklanan ayrı bir 9-boyut algoritması kullanır. Bunlar farklı on-chain rolleri ve farklı ödülleri olan ayrı şekilde puanlanan rol türleridir. Staking tarafı için Validator Puanı Metodolojisi'ne bakınız.
FLR / SGB zincir kapsamı: validators sayfasındaki Delegasyon sekmesi, Songbird (SGB) tutan cüzdanlar için bir FLR / SGB geçişine sahiptir. Bu metodoloji yalnızca FLR tarafı puanını belgelendirir. Songbird FTSO sağlayıcıları bileşik puan olmadan listelenir — FLR için kullandığımız aynı doğruluk / tutarlılık / FSP ödül verileri henüz Songbird boru hattımıza bağlanmamıştır (Flaremetrics, birincil FLR veri kaynağımız, Songbird'ü kapsamaz). SGB delegatörleri bugün gördükleri: sağlayıcı adı + TowoLabs çapraz ağ kayıt defterinden logo, mevcut ağırlık (delege edilen WSGB, Songbird'ün WNat sözleşmesinden doğrudan kendi Songbird RPC'miz aracılığıyla okunur) ve sağlayıcının URL'si. Ağırlığa göre sıralayınız; daha büyük ağırlık doğruluk verileri gelene kadar vekil sinyal olur. Songbird tarafı doğruluk + ödül oranı boru hattını yükledikten sonra, aynı 13-boyut formülü SGB sağlayıcılarına uygulanacak — yeni puanlama algoritması yok, sadece FLR formülü Songbird verilerine karşı hesaplanır. FlareWatch validator puanlaması (staking sekmesi) hiç SGB eşdeğerine sahip değildir: 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.
Puan bantları
90+En üst kademe — FTSO sağlayıcılarının ilk ~%10–20'si. Tipik profil: ortalamanın üzerinde ödül oranı, yüksek doğruluk, tam V2 protokol katılımı (FTSO Scaling + Fast Updates + FDC), düşük/sıfır ücret, geniş delegatör tabanı, MIRROR ödeyen validator düğümleri, isimlendirilen marka. Hiçbir tek boyut gerekli değildir — sağlayıcılar çoğu kategoride gücü yığınlayarak En üst kademeye ulaşırlar.
80–89Güçlü — çoğu kilit kıyaslamayı karşılar; en üst kademeden bir veya iki boyut eksiktir.
70–79İyi — tüm temel kriterleri karşılar; önemli boşluk yok.
60–69Kabul edilebilir — kullanılabilir ancak ayırt edilmemiş.
<60Medyan altı — bir veya daha fazla boyutta önemli boşluklar. Matematiksel gerçek, kalite yargısı değil.
Boyutlar (ham ağırlıklar — toplam 172, 100'e normalize edilmiş)
"Aktif" iki boyutu kontrol eder (Ücret ve V2 Katılımı): çalışmayan bir sağlayıcı düşük ücret reklamı için kredi toplayamaz. Bir sağlayıcı, yayımlanmış bir ödül oranı varsa veya Flare Systems Protocol ödül verileri skorlama penceresinin en az bir döneminde ödeme yaptığını gösteriyorsa aktif sayılır. 2026-07-31'e kadar tek bir üçüncü taraf API'sinden gelen ödül oranıydı — bu nedenle o API'nin kapsamadığı bir sağlayıcı her epok her ödülü görünür şekilde dağıtırken her iki boyutta sıfır aldı. Aktivite, onu listeleyenin değil, sağlayıcının bir özelliğidir.
Ödül Oranı25 puan maksimum
Ne: Sağlayıcının epoch başına ödül oranı, ağ medyanına bağlı.
Nasıl: oran = sağlayıcıOranı / medyanOranı. Doğrusal: oran 1.0 (medyan) → 12.5 puan, oran 2.0 → 25 puan (sınır). Etkin olmayan sağlayıcı (ödülOranı ≤ 0) → 0. v4.0 (2026-05-11): sınır yeniden ayarlanmış, medyan = boyutun puanlarının yarısı (önceden %40 değildi).
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).
Neden: Ödül oranı delegatörlerin deneyimledikleri #1 şeydir. Medyan tutturmak, ağın ödül ekonomisi değiştikçe puanı dürüst tutar — düşük ödüller döneminde medyanın 1.2 katında olan bir sağlayıcı, yüksek ödüller döneminde medyanın 1.2 katında olan sağlayıcı ile aynı sırada yer alır. Sınırlar ve anomali filtreleri, tek epoch'un aykırı değerlerinin hakimiyetini önler.
Doğruluk25 puan maksimum
Ne: Flare Systems Explorer (FSE) üzerinden FTSO fiyat doğruluğu — birincil (dar IQR) ve ikincil (daha geniş) ödül bandı iniş oranları.
Nasıl: FTSO BİRİNCİL (dar IQR) ve İKİNCİL (daha geniş) band iniş oranlarının %40/%60 karışımı (v4.8), Flare'nin kendi ödül bölünmesini yansıtarak — FIP.11 çıpa beslemesi ödüllerini %40 birincil / %60 ikincil öder. İkincil önceki parçalı eğriyi kullanır (%97 → 25 … %70 → 2); alan genelinde neredeyse doygun (%95–99%), bu yüzden neredeyse hiç farklılık yaratmaz. Birincil mutlak doğrusal eğri kullanır — %28 → 0 üstten %78 → tam 25 — böylece sağlayıcıların gerçekten ~%28 ile ~%80 arasında yayıldığı çok daha zor dar band mühendisliği, alanı ayıran şeydir. Sabit çıpalar (alan yüzdelikleri değil), bu yüzden puan sağlayıcının kendi girdilerinden yeniden türetilebilir kalır. Yalnızca bir tanesi kullanılabilir olduğunda tek band geri dönüş; FSE verisi olmadığında nötr 12.5.
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
Neden: Kaçırılan epoch'ler = delegatörlerin kaçırdığı ödül geliri. Doğruluk, sağlayıcının gönderimlerinin FTSO konsensüsü için gerçekten sayılıp sayılmadığını belirler ve ikincil metrik (daha son epoch'ları ağırlandıran), mevcut performansa en temiz şekilde eşleyen metriktir.
Tutarlılık20 puan maksimum
Ne: Sağlayıcının en son kazanç epoch'ları arasında ödül oranının ne kadar stabil olduğu.
Nasıl: Bir sağlayıcının en son kazanç dönemleri arasındaki aşağı yönlü volatilite; yalnızca gerçekten ardışık olan dönemler arasında ölçülür — bir sağlayıcının hiçbir şey kazanmadığı bir dönem hiçbir kayıt bırakmaz ve bu boşluğun her iki tarafındaki iki dönem asla birbirleriyle karşılaştırılmaz. Yalnızca dönem-dönem DÜŞÜŞLERİ sayılır — bir yükseliş sıfır katkı yapar — bu nedenle sabit veya yükselen bir oran neredeyse tam puan alır ve bir toparlanma puanı yükselirken kaldırır. Düşüşler RMS-toplanmış olduğu için güçlü bir düşüş hafif birinden daha fazla ağırlık taşır ve son çiftlere doğru ağırlıklandırılır (bozunma 0.8), bu nedenle etkin bir toparlanma puanı yukarı çeker, eski düşüşler aşamalı olarak ortadan kaybolur. cv = 0 → 20 puan; cv ≥ ~0.167 → 0. Son 12 kazanç döneminde 3'ten az ardışık dönem çiftinden az varsa 10 Nötr.
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)
Neden: Aynı ortalama ödül oranına sahip iki sağlayıcı çok farklı stake sahibi deneyimleri sunabilir: keskin düşen bir sağlayıcı istikrarlı kalan veya yükselen bir sağlayıcıdan daha kötüdür. Tutarlılık, bir delegatın gerçekte istediğini — istikrarlı veya yükselen bir oranı — ödüllendirir ve yalnızca düşüşleri derinliğe orantılı olarak cezalandırır. Bir oran YUKARI geri döndüğünde hiçbir zaman cezalandırılmaz (önceki simetrik ölçü bunu yaptı, bu da geriye dönüktü). Yakın zamanda güçlü bir düşüş düşük puan alır ve ardından yaşlanırken iyileşir.
V2 Katılımı15 puan maksimum
Ne: Sağlayıcının modern V2 yığınını (FTSO Scaling + Fast Updates + FDC) çalıştırıp çalıştırmadığı.
Nasıl: Protokol başına yığınlama. Etkin taban (ödülOranı > 0) +3, V1 kısmi (gönder + imza + seçmen) +4, her V2 protokolü (FTSO Scaling / Fast Updates / FDC) +~2.67 her biri, 15'te sınır. Etkin olmayan → 0. v4.0 (2026-05-11) önceki hep ya da hiç katmanını (kısmi V1 = tam V2 = 15 — yükseltme teşviki yok) protokol başına bonuslara bölündü.
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)
Neden: V2 ağın gidişi. v4.0'ın protokol başına yığınlaması, V1 kısmi'den tam V2'ye yükseltmenin puanı gerçekten hareket ettirmesi anlamına gelir (ön-düzeltmede değildi — kısmi V1 ve tam V2 her ikisi de 15 döndürü). Herhangi bir tek V2 protokolü eklemek artık boyutu iyileştirir.
Ücret15 puan maksimum
Ne: Sağlayıcının delege edilen ödüller üzerinden aldığı ücret.
Nasıl: Kırılım noktaları arasında doğrusal enterpolasyon: %0 → 15, %5 → 13, %10 → 10, %15 → 7, %20 → 4, ≥%25 → 0. Etkin olmayan sağlayıcı → 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
Neden: Ücret delegatörlerin aldığı şeyi doğrudan azaltır. Doğrusal enterpolasyon (kovalara karşılık), %7 ücretin %10 ve %15 arasında puan alması anlamına gelir — operatörler ücretlerini sonraki kova sınırına aşağı yuvarlama için kredi almaz.
MIRROR Katılımı12 (+3 bonus) puan maksimum
Ne: Operatörün P-Chain validator düğümlerinin staker'lara FTSO enflasyon payı aktif olarak ödeyip ödemediği, artı aşırı performans bonusu.
Nasıl: Temel puan, operatörün MIRROR ödülleri ödeyen nodeID'lerinin oranı ile doğrusal olarak ölçeklendirilir. Tüm düğümler aktif → 12 puan. Kısmi → orantılı. Hiçbiri → 0. 2026-05-11 itibariyle 'aktif' sinyal iki kanonik kaynaktan okunur: V2 RewardManager'da zincir üstü RewardClaimed(claimType=3) olayları VE resmi FSP Merkle JSON'da claimType=3 tahsisatları — her biri yeterlidir. Güncelleme öncesi, yalnızca zincir üstü akışı sinyal olarak kullanıyorduk; bu, standart olmayan bir talep yolu aracılığıyla MIRROR'u gerçekleştiren sağlayıcılar için yanlış negatifler üretti. Ayrıca, operatörün doğrulayıcıları tutarlı olarak beklenen (vrm + mirror) / beklenen %100'ün üzerinde sunduğunda +3 puana kadar overperformans bonusu — Bayes daralması, 30 günlük veri birikme kapısı ve minimum 3 stake örneği, küçük veya yeni operatörlerin bonusu birkaç şanslı okumada oynamasını engeller.
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
Neden: MIRROR katılımı, FTSO enflasyon payını sahiplerinize devreden şeydir. V2-aktif bir sağlayıcı, doğrulayıcı düğümleri MIRROR ödemiyorsa, aynı sağlayıcıya aktif düğümlü kıyasla delegatörlere ~%5-15 daha az getiri gönderiyor. Overperformans bonusu tutarlı olarak beklenenden daha iyi teslim edilmesi ödüllendirir ve yeni operatörleri küçük örneklere şişirmez — Bayes daralması ve 30 günlük birikme kapısı bunu adil tutar.
Delegatör Sayısı12 puan maksimum
Ne: Bu sağlayıcıya şu anda delegasyon yapan farklı cüzdan sayısı, zincir durumundan sayılmıştır.
Nasıl: 5 → 500 delegatörü 0 → 12'ye eşleyen logaritmik ölçek. ≤5 → 0, ≥500 → 12 (üst sınır). Doğrulayıcı Trust boyutunun sayım sinyal stilini eşleştirir. v4.0 (2026-05-11): önceki kova şemasının tam 500 delegatörde ters bir teşviki olduğu gerçek bir hatayı düzeltir (düzeltme öncesi: 500 → 14, 501 → 12 — o sınırda delegatör kazanmak 2 puan KAYBETTİ).
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
Neden: Delegatör sayısı, stake büyüklüğünden bağımsız bir güven sinyalidir. 200 delegatörü olan bir sağlayıcı 200 bağımsız hissedar tarafından seçilmiştir; 5'i olan operatöre yakın seçilmiştir. Logaritmik ölçekleme ~50 delegatör sonrası azalan getiriler verir, hiçbir zaman tersine dönmez (v4.0 öncesi kova puanlaması yaptığı şekilde).
Epoch Katılımı10 puan maksimum
Ne: Sağlayıcının epoch'lara aktif olarak katılıp katılmadığı.
Nasıl: FSE sağlayıcıyı aktif olarak işaretler → 10. Sağlayıcının rewardRate > 0 (Flaremetrics) ancak FSE aktif bayrağı yok → 7 (pazar verilerine göre aktif, FSE onayı eksik). Aksi takdirde → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
Neden: Ödül akışı dursa bile Flaremetrics hala onları listeliyor sağlayıcıları yakalar. Accuracy'den (epoch başına doğruluk hakkında) farklı — Participation tüm şeyde gösterilme hakkındadır.
Oy Gücü Stabilitesi10 puan maksimum
Ne: Sağlayıcının oy gücündeki günden güne yüzde değişimi.
Nasıl: Mutlak günden güne yüzde değişiminde parçalı doğrusal. <1% → 10. 1% → 3% doğrusal (10 → 7). 3% → 5% doğrusal (7 → 4). 5% → 10% doğrusal (4 → 2). %10'ın ötesinde 0'a devam eder. v4.0 (2026-05-11): önceki kova uçurumlarını doğrusallaştırır (her eşikte 3 puan uçurumu vardı).
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)
Neden: Oy gücündeki büyük günden güne dalgalanmalar genellikle delegatör dalgasının içeri veya dışarı hareket ettiğini gösterir — tabloyu okuyan hissedarlar hareket eden bir hedefi görür. Sabit oy gücü, sabit delegatörlere sahip yerleşik bir sağlayıcıyı gösterir.
Uyum10 puan maksimum
Ne: Sağlayıcının FSP ödül verilerinde aktif hale gelmesinden BERI her ödül epoch'ında ödeme alıp almadığı.
Nasıl: Sağlayıcının aktif penceresi içinde sıfır kaçırılmış epoch için tam 10 puan. Her kaçırılmış epoch 3 puan düşer (0'da klamplanır). FSP verisi yoksa nötr 5. v4.4 (2026-06-30): kaçırılmış epoch'lar şimdi sağlayıcının ilk katılım epoch'ından itibaren sayılır — yeni bir sağlayıcı artık var olmadığı epoch'lar için ücretlendirilmez (bu önceden yeni ama temiz düğümleri haftalar boyunca 0/10'da tuttu).
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)
Neden: Resmi Flare Sistemleri Protokolü ödül dağıtımında kaçırılmış bir epoch, sağlayıcının o epoch için protokol uyumunu başaramadığı anlamına gelir — minimum koşullar, imza politikası, vb. Yalnızca ilk katılımdan sayma, yeni sağlayıcılara adil kalırken gerçek yakalanmayan cezaları cezalandırır. Miss başına üç puan diktir, bu nedenle tek bir miss fark edilir ancak kurtarılabilir; ~3 miss boyutu sıfıra döner.
Kimlik8 puan maksimum
Ne: Sağlayıcının gerçek bir marka adı veya sadece bir hex adres olup olmadığı.
Nasıl: Adlandırılmış marka (≥4 karakter, 0x ile başlamayan) → 8. Kısa veya anonim (<4 karakter) → 4. Ad olarak saf hex / 0x adresi → 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
Neden: Adlandırılmış bir sağlayıcı bulunabilir ve hesap verebilir olmayı seçmiştir — araştırılabilir, iletişim kurulabilir ve yayınlanan taahhütlere tutulabilirler. Adresleri anonim sağlayıcılar işlevseldir ancak onları değerlendiren delegatörlere daha az güven sinyal sunarlar.
Kendi Tahvili7 puan maksimum
Ne: Operatörün KENDİ P-Chain düğüm tahvili (oyunda deri) — diğerlerinin düğüme devrettiği stake'i hariç tutarak. Servet sıralaması değil, boyut-nötr taahhüt kapısı.
Nasıl: İki doyurucu eksenden KÜÇÜKÜne göre kredilendirilir: (1) hizalama — kendi tahvil olarak toplam taahhüt edilen stake payı (≥%10 → tam); veya (2) mutlak — riskte kendi sermaye, 5M FLR'de kapatılmış, bu nedenle 5M ve 80M aynı puan alır. v4.4 (2026-06-30): operatörün doğru P-Chain kendi-tahvili'nden yeniden kaynak oluşturulur (doğrulayıcı ağırlığı nodeID tarafından çapraz referans) — okuduğu önceki Flaremetrics alanı durduruldu, bu nedenle her sağlayıcı 0 puan aldı. v4.5 (2026-06-30): mutlak ekseni + doyum eklendi, böylece düşük orandaki büyük kendi-tahvil düşük orandaki küçük birine kıyasla aşağıda puanlanmaz, boyut kazanmadan veya küçük operatörleri cezalandırmadan.
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)
Neden: Oyunda deri — kendi sermayesi riskte olan bir operatör delegatörlarla uyumludur. Ancak kendi-tahvil boyutu operatör KALİTESİ'nin vekili değildir (bu diğer boyutlarda yer alır), bu nedenle tam hizalanmış küçük bir operatör ve taahhüt edilen büyük bir operatör tam puan kazanır. Yalnızca kendi sermayesinin az olduğu bir operatör — küçük pay VE küçük tutar — tam altında puan alır.
100/100 nasıl puan alınır — bir FTSO sağlayıcı oyun kitabı
v4.0 adalet denetimi, her puan boyutunu maksimize etmenin sizi delegatörleriniz için gerçekten daha iyi bir FTSO sağlayıcısı yapacak şekilde tasarlanmıştır. Puanınızı iyileştirmek sistemi oyunlamak değildir — bu sistem tasarım gereği çalışmaktadır. İşte boyut başına oyun kitabı.
Ödül Oranı — 25 puan. Epoch başına ağ medyan FSP ödül oranının ≥ 2 katını sunun (ücret sonrası, protokol dağıtım sonrası). 0'dan 2× medyana doğrusal: medyan → 12.5, 2× medyan → 25. Neden uyumludur: bu delegatörlerinize epoch başına ulaşan dolar miktarıdır.
Doğruluk — 25 puan. FSE'de tam puan için ≥%97 ikinci band iniş oranını hedefleyin. Parçalı doğrusal, bu nedenle %95 → 18, %93 → 16, %90 → 13, vb. — %1'lik her iyileştirme puanı hareket ettirir. Bu fiyat-KALİTEdir, epoch katılımı değil: sunulan fiyatların kesir olarak zincir üstü kabul edilen bant içinde indiğini ölçer. Yüksek Doğruluklu bir sağlayıcı fikriye yakın fiyatlar yayınlar; düşük Doğruluklu, güvenilir ancak konsensüsten daha sık ayrılır. Neden uyumludur: band dışı gönderimleri, sağlayıcı her epoch'ta katılsa bile, delegatör ödüllerini üretir. Aşağıdaki ayrı Compliance boyutu epoch katılımını izler.
Tutarlılık — 20 puan. Epoch başına ödül oranı varyansını en aza indirin (CV = stddev/mean son epoch'larda). CV = 0 → 20, CV = 0.2+ → 0. Neden uyumludur: aynı medyan ödül oranıyla iki sağlayıcı eşdeğer değildir — öngörülebilir ödemeler hissedar UX için değişkenleri yener.
V2 Katılımı — 15 puan. Protokolleri katkı olarak istifleyin: aktif baseline + V1 kısmi kaydı + her V2 protokolü (Ölçekleme, FastUpdates, FDC). Tam V2 + aktif + V1 kayıtlı = 15. Neden uyumludur: V2 ağın gittiği yerdir; benimsediğiniz her ek protokol delegatörlerinizin yararlandığı ileri bir yatırımdır.
Ücret — 15 puan. ≤%5 için 13 puan, %0 için 15 ücret alın. %5/%10/%15/%20/%25 kesme noktaları aracılığıyla parçalı doğrusal rampa 0'a kadar. Neden uyumludur: düşük ücret = daha fazla ödül delegatörlerinize doğrudan ulaşır.
MIRROR Katılımı — 12 + 3'e kadar bonus. Operatörünüzün tüm P-Chain doğrulayıcı düğümlerini MIRROR-aktif olarak çalıştırın (zincir üstü RewardClaimed olayları VEYA FSP Merkle JSON tahsisatları aracılığıyla — v3.6 çift kaynakla). Sürdürülen overperformans (30 günlük gözlem sonrası ≥3 ödenen stake'de ortanca (vrm+mirror)/beklenen oran 1.05'in üzerinde) +3'e kadar bonus kazanır. Neden uyumludur: MIRROR delegatörlerinizin FTSO enflasyon payıdır; MIRROR'u ödemeyene düğümler hissedarlarına ~%5-15 daha az getiri gönderi.
Delegatör Sayısı — 12 puan. 5 → 500 delegatörleri 0 → 12'ye eşleyen logaritmik ölçek. Sadece birkaç balina değil, bağımsız hissedarların tabanını oluşturun. Neden uyumludur: sayım stake büyüklüğünden bağımsız bir güven sinyalidir; 200 delegatör sizi seçmek 200 bağımsız onay anlamına gelir.
Epoch Katılımı — 10 puan. Her epoch'ta pozitif ödül oranı ve aktif FSE bayrağıyla gösterilin. Neden uyumludur: per-epoch boyutlarının kaçırabileceği durmuş ödül akışlarını yakalar.
Stabilite — 10 puan. Gün içi oy gücü değişimini %1'in altında tutun. Oradan itibaren parçalı doğrusal artış. Neden uyumlu: istikrarlı oy gücü, geçici balina dalgaları yerine yerleşmiş delegatörları (yapışkan topluluk) gösterir.
Uyum — 10 puan. FSP verilerinde sıfır ceza dönemi kaçırma. Her kaçırma 3 puan tutar; ~3 kaçırma boyutu sıfırlar. Bu KATILIMs, fiyat kalitesi DEĞİLdir: sağlayıcının minimum koşulları, imza politikasını veya diğer protokol gereksinimlerini kaçırdığı için cezalandırılan dönemleri sayar — yukarıdaki Doğruluk boyutundan farklıdır ve band içi fiyat inişini puanlar. Neden uyumlu: protokolün kendi ödül dağıtımında kaçırılan bir dönem, sağlayıcının minimum koşulları yerine getiremediği ve delegatörlerin o dönem hiçbir şey kazanmadığı anlamına gelir. Bir sağlayıcı katılan dönemlerde mükemmel Doğruluk sağlayabilir ve yine de dönemleri tamamen kaçırabilir.
Kimlik — 8 puan. Flaremetrics veya FSE'de gerçek bir marka adı kaydettirin (≥4 karakter, hex adresi değil). Adres yoluyla anonim sağlayıcılar 0 alır; adlandırılmış sağlayıcılar 8 alır. Neden uyumlu: adlandırılmış sağlayıcılar bulunabilir ve sorumludur; bu temel güven sinyalidir.
Öz-Tahvil — 7 puan. Kendi P-Chain düğüm tahvilini taahhüt edin (size delegatörlerin stake ettiği değil). Tam puan VEYA toplam stake'inizin anlamlı bir payı için (≥10%) VEYA anlamlı bir mutlak tutar için (mutlak eksen 5M FLR'de doygunlaşır, bu nedenle büyük bir operatör boyut açısından küçük birini yenebilmez). Neden uyumlu: oyunda deri — kendi sermayeye sahip operatörler delegatörlerinin getiri sonuçlarını paylaşırlar. Bu, servet sıralaması değil, boyut-nötr bir taahhüt kapısıdır: tam uyumlu küçük bir operatör ve büyük, taahhütlü bir operatör her ikisi de maksimum yapar, operasyonel kalitesi diğer boyutlar tarafından yargılanır.
Kısayol yapamayacağınız zaman-geçitli sinyaller: Tutarlılık ≥3 dönem geçmişi gerektirir. MIRROR üstün performans bonusu 30 günlük gözlem artı ≥3 ödenen stake örneği gerektirir. Uyum, yeterli dönem sayısını saymak için FSP verilerine ihtiyaç duyar. Bir pist kaydı oluşturun; puan takip edecektir.
Ham puan tüm 12 puanlı boyut üzerinden maksimum 172'ye kadar toplanır ve ardından 100'e normalize edilir. Mükemmel bir girdiler seti 172/172 → 100 görüntülenmiş olur. Çok büyük sağlayıcılar (>1,34B VP) için −3 puana kadar oy gücü seyreltme cezası bir tiebreaker olarak uygulanır.
Kendi puanınızı nasıl doğrulayacağınız
Sağlayıcılar tablosundaki her puan, halka açık verilerden yeniden üretilebilir. Bir operatörsünüz ve buradaki matematik gördüğünüz puan ile eşleşmiyorsa, bir hata yaptığımızı varsaymadan önce bunu kendiniz doğrulamak doğru harekettir. İşlem:
  1. Sağlayıcınızın genel istatistiklerine bakın flaremetrics.io adresinde (adla arayın veya delegasyon adresinizi yapıştırın). fspRewardRate, delegationFeePercentage, wNatWeight ve votePowerDailyChangePct değerini not edin.
  2. FTSO V2 + doğruluğunuzu doğrulayın flare-systems-explorer.flare.network adresinde. Varlığınızı bulun. Doğruluk için providersuccessrate.secondary ve V2 durumu için entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc bayraklarını kontrol edin.
  3. MIRROR katılımınızı kontrol edin V2 RewardManager sözleşmesinde flare-explorer.flare.network aracılığıyla. NodeID'lerinize atıfta bulunan claimType=3 ile RewardClaimed olaylarını arayın. Düğümlerinizden herhangi biri için yakın zamanda hiç yoksa, puanınızda MIRROR-inaktif olarak gösterilirsiniz.
  4. Girdilerinizi yukarıdaki formüllere takın. Her boyutun kod bloğu, çalıştırmanız gereken tam aritmetiği size söyler. Boyutları toplayın, 172'ye (ham maksimum) bölün, 100 ile çarpın ve ham bileşik skorunuz olacak.
  5. Büyükseniz seyreltme cezasını uygulayın. 1,34B üzerindeki oy gücü −3, 1B üzerinde −1. Aşağıdaki Son Puan kartı tam eşikleri içerir.
  6. Görüntülenen puanınızla karşılaştırın. Görüntülenen puan ayrıca dinamik ağırlık yeniden dağıtımını yansıtır — çoğu sağlayıcı bir boyutta kümelendiğinde (aktif set arasında düşük standart sapma), bu boyutun ağırlığı yayılmanın daha geniş olduğu boyutlara yeniden dağıtılır. Her sağlayıcı satırındaki puan dökümü paneli, geçerli boyut başına değerleri gösterir.
  7. Matematik hesaplamazsa, [email protected] adresine delegasyon adresiniz, kullandığınız girdiler ve hesapladığınız puan ile e-posta gönderin. Cevaplayacağız ve bir hata yaptıysak bunu herkese açık olarak düzelteceğiz.
Yaygın operatör endişeleri
Ödül oranım ortancanın üzerinde ancak Ödül Oranı puanım 25/25 değil — neden?
Ödül Oranı medyana oranında doğrusaldır: puan = oran × 12,5, bu nedenle 1,0× medyan = 12,5/25 ve sınırı vurmak için 2,0× orana ihtiyacınız vardır. Medyanın 1,2× sağlayıcısı 15 puanlar, 1,5× puan ~18,8, 2,0× tam 25 puanı. Limit (artı 3×-medyan anomali filtresi) tek bir anormal yüksek ödül döneminin boyutu hakimiyeti yapamayacağı şekilde vardır; oranınız sürekli olarak en iyi onbirde ise, puan yine de ağır puanlandırır.
Yeni sürüme yükseltmeyi tamamladım — V2 puanım ne zaman güncelleniyor?
V2 durumu FSE'nin entityminimalconditionslatest bayraklarından gelir (ftso_scaling, ftso_fast_updates, fdc). v4.0'dan beri boyut protokol başına yığılır: etkin temel +3, V1 kaydı (gönder + imza + oy) +4 ve her V2 protokolü +~2,67. Bu nedenle gönder + imza adresleri olan ancak üç V2 protokolünden hiçbiri olmayan oy-kayıtlı sağlayıcı 7/15 puanlar ve açıp açtığınız her V2 protokolü puanı hareket ettirir — her üçü canlı tam 15 alır. Değişiklikler, FSE'nin onları yansıtması sonrasında sonraki FlareWatch cron çalışmasında (her 5 dakika) inişir.
FSE'deki doğruluğum %96 ancak beklenenden daha düşük puanlandırıyorum.
Doğruluk boyutu, FSE'nin ikincil doğruluk ölçümünü kullanır (%94–97% bandında çoğu sağlayıcının kümelendiği yüksek çözünürlük). %95–96% 18 puana eşlenir; tam 25 için ≥%97 gereklidir. Kovalolar üstte sıkıdır çünkü %95–97% bandında yüzde puan bazında gerçek performans ayrımı sağlayıcılar arasında temsil eder.
MIRROR sunuyorum — FlareWatch neden beni sağlayıcı puanımda MIRROR-inaktif olarak gösteriyor?
2026-05-11 itibariyle, MIRROR katılımı İKİ kaynaktan tespit edilir: V2 RewardManager'da zincir üstü RewardClaimed(claimType=3) olayları, VE resmi FSP Merkle JSON'daki claimType=3 tahsisatları. Her iki kaynakta da görünen bir nodeID aktif olarak sayılır. Multi-düğüm operatörleri için puan, aktif olan düğümlerin kesirini kullanır (1/3 aktif = 4/12 taban, vb.). Bir düğüm aktif olarak sınıflandırılmalı ancak sonraki süpürme döngüsünden sonra değilse, NodeID ve belirttiğiniz belirli dönem ile bize e-posta gönderin — her iki kaynağı da çapraz kontrol edeceğiz.
Oy gücüm dün %8 hareket etti — neden Stabilite puanı ~2.8/10?
Oy Gücü Stabilitesi, mutlak gün içi değişimde parçalı doğrusaldır (v4.0'da doğrusal — kova kenarları yok): <1% → 10, 1→3% rampa aşağı 7'ye, 3→5% rampa aşağı 4'e, 5→10% rampa aşağı 2'ye, sonra 10%'in ötesinde 0'a doğru. %8 hareket, 4 − (8 − 5) × 0,4 = 2,8 adresinde 5–10% rampada açılır. Amaç, önemli delegatör devri yaşayan sağlayıcıları işaretlemektir; bu nedenle staker'lar tabloyu görebilir. Puan, oy gücü stabilize olur olmaz kurtarır; bir uçucu gün seni kalıcı olarak düşük tutmaz.
Sağlayıcım varlık adresimle adlandırıldı (0x…). Kimlik puanı neden 0?
Kimlik, gerçek bir marka adı (≥4 karakter, 0x ile başlamayan veya yalnızca hex değil) için 8 puan ve saf adres adı için 0 alır. Adı uyduramayız — Flaremetrics'te profile.name'inizi ayarlayın ve sonraki cron çalışmasında alacağız. Varlığınızda bir profil varsa ancak ad alanı boşsa, aynı şey geçerlidir.
Küçük ama taahhütlü bir delegatör tabanım var — Delegatör Sayısı puanım neden sınırlı?
Delegatör Sayısı gerçek sayımları kullanır: WFLR tutan her cüzdan, mevcut delegasyonları için zincirde kontrol edilir ve her sağlayıcının farklı delegatörleri sayılır (yaklaşık her 6 saatte yenilenir, bağımsız bir olay defterine karşı çapraz kontrol edilir). v4.0 sürümünden itibaren 5 → 500 delegatörün 0 → 12 puana eşlendiği logaritmik ölçek kullanılır, 500 ile sınırlandırılır (≤5 skor 0 puan alır). Logaritmik ölçekleme, güçlü delegatör sayısı büyümesine sahip daha küçük sağlayıcıların en hızlı şekilde yükseldiği anlamına gelir; yaklaşık 50 delegatörün ötesinde, ek delegatörler göstergeyi daha az hareket ettirir — ancak eğri monoton olduğu için bir delegatör kazanmak puanı asla düşüremez (v4.0 öncesi gruplar yapabilirdi).
Bir düğüm ekledikten sonra puanım düştü — ne oldu?
Yeni düğüm henüz claimType=3 MIRROR olayları göstermiyorsa, MIRROR fraksiyonu düşer (örneğin, 1/1 = %100'den 1/2 = %50'ye), MIRROR Katılım temel puanını düşürür. Yeni düğüm MIRROR'ı ödeme yapmaya başladığında (tipik olarak aktivasyondan bir veya iki ödül dönem içinde), fraksiyon kurtarılır ve puan tırmanır.
Puanıma karşı çıkabilir veya manuel inceleme isteyebilir miyim?
Evet. Delegasyon adresiniz ve belirli bir endişe ile [email protected] adresine e-posta gönderin. Her operatöre cevaplarız. Harekete geçeceğimiz şeyler: MIRROR-sınıflandırma düzeltmeleri, boyuta özgü matematik hataları, Flaremetrics aracılığıyla ad/logo düzeltmeleri. Harekete geçmeyeceğimiz şeyler: algoritmin dışında puanı manuel olarak yükseltme istekleri, rakibi hariç tutma veya düşürme istekleri.
Ne yapacağımız ve ne yapmayacağımız
Puanı nasıl çalıştırdığımız hakkında belirsizliği kaldırmak için, açık taahhütler var. Bu taahhütlerden birini hiç ihlal edersek, belgelendirin ve [email protected] adresine e-posta gönderin — bunu herkese açık olarak düzelteceğiz.
✓
Daha yüksek puanlar, sponsorlu yerleşim veya herhangi bir iyilik için ödeme kabul etmeyeceğiz. Puan, genel verilerden belirleyici olarak hesaplanır.
✓
Sağlayıcı başına kod ile el yazısı bumps yapacağız Hiçbir "X, onları seviyoruz için +5 alır" satırı kod'ta herhangi bir yerde yoktur. Aynı algoritma, bu tam fonksiyon tarafından puanlanan FlareWatch'ın kendi sağlayıcısı dahil olmak üzere her sağlayıcı için geçerlidir.
✓
Sağlayıcıları, kamuya açık olmayan nedenlerle tablodan hariç tutmayacağız. Liste Flaremetrics + FSE'den kaynaklanır; görüntülememiz, bu kaynakların ortaya çıkardığı her etkin sağlayıcıyı içerir.
✓
Algoritma değişikliklerini yayınlayacağız. Her sürüm güncellemesi, bu sayfadaki Versions kartında gerekçesi ve neler değiştiği ile belgelenir. 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 somut bir endişe ile e-posta gönderen her operatör, birkaç iş günü içinde gerçek bir yanıt alır.
✓
Hatalarımızı herkese açık şekilde düzelteceğiz. Algoritma hatasını, veri kaynağı hatasını veya metodoloji boşluğunu keşfedersek, düzeltme yayınlarız ve belgeleririz. Sessizce yeniden sıralamayız.
✗
Göndericinin izni olmadan e-posta içeriklerini herkese açık şekilde paylaşmayız veya operatör e-postalarını onları üreten puan konuşmasından başka bir amaç için kullanmayız.
✗
Algoritma değişikliği için gelecek planlarımızı önceden seçilen operatörlerle paylaşmayız — her sürüm aynı anda herkese canlı yayına geçer.
Final skor (boyutlar nasıl birleşir)
Puanlanan tüm 12 boyut ham bileşik (maks 172) değerine toplanır. Ham bileşik 0–100 ölçeğine normalize edilir, ardından son görüntülenen puanı üretmek için dinamik ağırlık yeniden dağıtımı uygulanır.
// 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)
Kota yakınlığı bir puan indirimi değil, bir görüntü sinyalidir. v4.9 sürümüne kadar puan, çok büyük sağlayıcılardan da sabit 1–3 puan çıkartıyordu, ancak bu çifte saydı — kota aşan bir sağlayıcı zaten ortanca oranı altında gerçekleşen ödül oranı kazanıyor ve bu, ortanca sabitli Ödül Oranı boyutu tarafından puanlanıyor. Bu nedenle ceza kaldırıldı. Her sağlayıcı artık FSP kotasının (WNat sözleşmesinin canlı toplam oy gücünün %2,5'i) ne kadarını doldurduğunu gösterir ve bu, tarafsız marjinal delegasyon sinyali olarak işlev görür: %100'e ne kadar yakınsa, yeni bir delegasyon o kadar çok seyreltilir.
Görüntüleme katmanı aykırı değer bayrağı: mevcut ödül oranı alan medyanının üzerinde üçten fazla robust sapma (medyan mutlak sapma, ×1.4826 ölçekli) ve en az %50 üzerinde olan bir sağlayıcı, sağlayıcı tablosunda Aykırı Değer rozeti taşır. Rozet puanı değiştirmez; puanın kendi anomali koruması, puanlandırmadan önce medyanın 3 katının üzerindeki oranları ayrı olarak sınırlar. Yıllıklandırılmış dönem oranı artışları genellikle çok küçük oy gücünden kaynaklanır ve bir dönem içinde normalleşir.
Veri kaynakları (her girdi halka açıktır)
Flare kontratları, doğrudan zincir üzerinde okunur: kayıtlı sağlayıcı seti (VoterRegistry), varlık → delegasyon adresi ve nodeID bağlantıları ile gönderme/imzalama adresi kaydı (EntityManager), delege edilen oy gücü (WNat) ve delegasyon ücreti (WNatDelegationFee). Bu, sağlayıcı listesini herhangi bir indeksten bağımsız kılan şeydir: ödül dönem 420'de zincir, üçüncü taraf listesindeki 80'e karşı 98 kayıtlı sağlayıcı içeriyordu ve boşluktaki 18 sağlayıcı daha önce bu sitede hiç yoktu.
Flaremetrics genel API: ödül oranı, delegasyon ücreti, oy gücü, oy gücü günlük değişimi, kilitli oy gücü (self-bond), profil adı + logosu + bölgesi, fspRewardRate.
Flare Systems Explorer (FSE): FTSO doğruluğu (birincil + ikincil), V2 durum bayrakları (ftso_scaling, ftso_fast_updates, fdc), varlık adresi bağlantılandırması, imzalama/gönderme adresi mevcudiyeti, seçmen kaydı, P-Chain nodeID bağlantılandırması ve varlık başına temsilci ödül oranı (reward_rate_wnat). Ödül oranı kasıtlı olarak FSE ve Flaremetrics'ten DE kaynaklıdır: aynı rakamı farklı birimlerle yayınlarlar (FSE ondalık, Flaremetrics yüzde — her iki kaynağı taşıyan 72 sağlayıcının tümünde beş ondalık basamağa kadar doğrulanmış özdeş), ve FSE 154 varlığı kapsar, Flaremetrics'in 80'ine karşı. Tek kaynak başına hiçbir eksiklik yoktur, sağlayıcılar kendi kusurları olmaksızın hiçbir oran ile kalabilir.
Flare Systems Protocol ödül verileri (FSP): sağlayıcı başına epok başına ödül dağılımı, Uyumluluk boyutu için kullanılır (ödülsüz epokları sayar) ve delegasyon ödül toplamlarının yetkili kaynağı olarak kullanılır.
V2 RewardManager (claimType=3 olayları): doğrulayıcı nodeID başına zincir üzerinde talep edilen MIRROR dağılımı. Tip 3'te kesin olarak filtrelenir — VRM, FTSO delegasyonu veya DIRECT ödülleri ile karıştırılmaz. FlareWatch'ın kendi indeksleyicisi bunları MIRROR Katılım boyutu için yüzeye çıkarır.
FSP Merkle JSON (claimType=3 tahsisler): doğrulayıcılardan kimin epok başına MIRROR'a layık olduğunun kanonik yayınlanmış kaydı (Flare'ın kendi imzalama aracının okuduğu veriler). 2026-05-11 tarihinde ikinci yetkili kaynak olarak eklendi — MIRROR tahsis edilen ancak zincir üzerinde henüz talep edilmeyen doğrulayıcıları yakalar.
FlareWatch geçmiş anlık görüntüleri: epok başına ödül oranları Tutarlılık CV'yi besler; doğrulayıcı başına ödenen hisse gözlemleri MIRROR aşırı performans bonusunu besler (30 günlük veri birikimi geçidi ile).
Skorun içinde neler yok
• Kendi tanıtımı veya ödenen yerleştirme. Hiçbir sağlayıcı daha yüksek bir skor için ödeme yapamaz veya sponsor olamaz.
• Elle kodlanmış sağlayıcıya özgü artışlar. Kodun hiçbir yerinde "X onları beğendikleri için +5 alır" satırı yok. Aynı algoritma, FlareWatch'ın kendi sağlayıcısı da dahil olmak üzere her sağlayıcıya uygulanır ve bu sağlayıcı bu tam işlevle puanlandırılır.
• Öznel altyapı kalitesi. Çalışma süresi SLA'larını, coğrafi dağılımı veya FSE ve Flaremetrics'in genel veri olarak yüzeye çıkardığı şeyler dışında donanım özelliklerini değerlendirmeye çalışmayız.
• FlareWatch'a kilitlemeler veya taahhütler. Başka bir araç yerine FlareWatch kullanan staker'lar için uygun puanlama yok.
• Henüz bağlı olmayan gelecek sinyalleri. Topluluk varlığı (doğrulanmış sosyal ağlar, yönetişim katılımı), tarihsel slashing, yanıt gecikmesi ve epok başına trend çizgileri gelecek sürümler için kapsamlı olsa da bugün v3'te değil. Hiçbiri gizli bir şekilde ağırlıklandırılmaz.
Operatör geri bildirimi
Sağlayıcınızın skorunda bir şey yanlış mı görüyorsunuz? Delegasyon adresiniz ve endişeniz ile [email protected] adresine e-posta gönderin. Her operatöre yanıt veririz. Üzerinde harekete geçeceğimiz yaygın istekler:
  • MIRROR sınıflandırması düzeltmeleri (claimType=3 nodeID'lerinize atama).
  • Kullandığınız girişleri içeren boyuta özgü matematik hataları.
  • Flaremetrics veya FSE aracılığıyla ad / logo / profil düzeltmeleri.
  • Genel algoritma eleştirisi.
Kaynaklar ve referanslar
Skorun her girişi halka açık, doğrulanabilir Flare ekosistemi kaynaklarından gelir. Herkes iddialarımızı bu birincil kaynaklar karşısında çapraz kontrol edebilir ve ham verilerden matematik çoğaltabilir. Bu sayfa ile upstream kaynakların söyledikleri arasında bir tutarsızlık tespit ederseniz, [email protected] adresine e-posta gönderin ve biz bunu düzeltelim.
Flare Ağ protokol belgeleri ↗https://docs.flare.network
Yetkili protokol belgeleri. FTSO V2, FSP, P-Chain doğrulaması, FAssets ve Flare yığınının geri kalanını kapsar.
Flare yönetişim portalı (FIP'ler) ↗https://proposals.flare.network
Flare Geliştirme Önerileri — V2 protokolü minimum koşulları, ücret mekanikleri ve bu skoru besleyen ödül ekonomisi değişiklikleri için gerçek kaynağı.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
FTSO veri sağlayıcılarının, kuruluş adreslerinin, P-Chain nodeID bağlantılarının ve minimum koşul bayraklarının resmi Flare işletim defteri. Doğruluk, V2 ve Katılım boyutlarımızın birincil kaynağı.
Flaremetrics ↗https://flaremetrics.io
Bağımsız Flare ekosistemi metrikleri sağlayıcısı. Ödül oranları, ücretler, oy gücü, oy gücü günlük değişimi, kilitli oy gücü, profil adları + logoları ve fspRewardRate metriği kaynağı.
Flare Blok Gezgini ↗https://flare-explorer.flare.network
Tüm zincir üzerindeki durumun salt okunur tarayıcısı. Herkesin V2 RewardManager'ın RewardClaimed olaylarını (MIRROR için claimType=3), ödül epok geçişlerini ve gerisini doğrulamasına izin verir.
Flare Foundation ödül-scripts deposu ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation tarafından yayınlanan doğrulayıcı başına teslim edilen ödülleri gösteren epok başına JSON. Dolaylı girdi — FlareWatch'ın başına hisse gözlemi indeksleyicisi aracılığıyla MIRROR aşırı performans bonus hesaplamasını besler.
Flaremetrics genel API'si (FTSO sağlayıcıları) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
Cron işleminin tükettiği kesin endpoint, varlık profillerini, ödül oranlarını, ücretleri ve oy gücünü döndürür. Herkes doğrudan erişebilir.
Flaremetrics genel API'si (düğüm kayıtları) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID dönüştürme tablosu. Bunu sayfalandırarak MIRROR Participation boyutunu yönlendiren varlık-NodeID arama tablosunu oluştururuz.
Özel veri yok, kapalı kaynak model yok. Puanlama algoritması FlareWatch kod tabanındaki services/ftso/scoring.ts dosyasında uygulanmıştır. İşletmeciler veya araştırmacılar uygulamayı doğrudan incelemek isteyenler (yukarıdaki yazı ve formülleri okumak yerine) — ya da kendi kullanımları için fork etmek isteyenler — erişim istemek için [email protected] adresine e-posta gönderebilirler. Gerçek bir talep varsa dosyayı bağımsız bir açık kaynak paketi olarak yayınlayacağız.
Puanlar nasıl güncellenir
FTSO sağlayıcı puanlaması /api/cron/refresh-validators adresindeki cron içinde bir geçiş olarak çalışır ve her aktif sağlayıcının puanını her 5 dakikada bir yeniden hesaplar (P-Chain validatörlerini yeniden puanlandıran aynı çalıştırma). Girişler (Flaremetrics, FSE, FSP ödülleri, V2 RewardManager olayları) her çalıştırmada yenilenerek alınır.
Tutarlılık CV'si yakın dönem geçmişini kullanır — boyut hadde penceresi kaydığında değişebilir. Üç dönemden az geçmişi olan yeni sağlayıcılar, yeterli veri birikene kadar nötr 10 puanını alır.
Dinamik ağırlık yeniden dağıtımı her çalıştırmada yeniden hesaplanır ve geçerli aktif sağlayıcı setine dayalıdır. Sağlayıcılar değiştikçe (örn., yeni V2 yükseltme dalgası), ayrımcı olmayan hale gelen boyut değişir; yeniden dağıtım otomatik olarak uyum sağlar.
Algoritma sürümü bu sayfanın başlığına damgalanır. Yeni bir sürümü çıkardığımızda, buradaki sürüm dizesi değişir ve aşağıdaki Sürümler kartı ne değiştiğini belgelendirir.
Sürümler
v4.8 (2026-08-20) — Doğruluk artık ZOR ödül bandını ödüllendirir. Yalnızca FTSO ikincilini (daha geniş) bandını kullanıyordu, neredeyse her ciddi sağlayıcının %95–99 oranında indiği — böylece boyut alanın en üstünde neredeyse düz 25/25 idi, hiçbir şeyi ölçmeye yakındı. BİRİNCİL (dar IQR) band gerçekten zor mühendislik ve sağlayıcıları ~%28–80 yayıyor. Flare bu banları %40 birincil / %60 ikincil ödüllendirir (FIP.11, 2024'ten beri canlı, daha fazla ikincil band artışları işaret edilerek), böylece Doğruluk artık bunu yansıtıyor: %40/%60 karışımı. İkincil önceki eğrisini korur; birincil mutlak eğri kullanır (%28 → 0, %78 → tam 25), sabit böylece puan sağlayıcının kendi girdilerinden yeniden türetilebilir kalır. Tüm 100 puanlandırılmış sağlayıcı üzerinde tam önce/sonra, gönderimden önce arşivlendi: yeniden sıralama birincil band gücünü takip ediyor — zor dar band işini yapan sağlayıcılar yükseliyor, kolay bir ikincil sayıya dayanan sağlayıcılar düşüyor. Aynı kural bizim kendi sağlayıcımıza uygulanır, bugün zayıf bir birincil bandı var: 84'ten 77'ye düşüyor ve birkaç sıra aşağı düşüyor. Yine de gönderilen — gerçek mühendisliği ödüllendir bir puan, rakibin de olsa ve kendi masrafımızda da olsa, yayınlamaya değer tek çeşittir.
v4.7 (2026-07-31) — Sağlayıcı listesi tek bir endekse bağlı olmayı bıraktı ve skor kendi veri açıklarını cezalandırmayı bıraktı. (1) Liste artık zincir üzerinde kayıtlı seçmen setinden oluşturulur ve üçüncü taraf endeksin varlıkları kaçırdığı yerlerde geri doldurulur: önceden gösterilen 80'e karşı 98 sağlayıcı, bu nedenle aranması ve buradan temsilci seçilmesi imkansız olan 18 gerçek sağlayıcı artık görünüyor. (2) "Aktif" "bu endeksten bir ödül oranına sahip" anlamına geliyordu, bu da kendi FSP verimiz onları her dönem ödeme yaptığını gösterse bile her geri doldurulmuş sağlayıcı için Ücret (15) ve V2 (15) boyutlarını sıfıra indiriyordu; artık dağıtım kanıtı kabul ediyor. (3) Eksik bir ödül oranı artık tam payda karşısında 0 puan almıyor — 25 puanlık ağırlık payda yerine ayrılıyor, bu nedenle bir sağlayıcı ölçtüğümüz şeye göre puanlanıyor, ölçemediklerimiz için cezalandırılmıyor. (4) Ücret boyutu hala FIP-16 öncesi eğride puanlandırılıyordu; burada %0 ücret tam puan kazanıyordu. FIP-16 %20'yi minimum yasal varlık ücreti yapar ve 98 sağlayıcının her biri tam olarak bunu uygular, bu nedenle boyut sıfır varyansla tüm alana 4.00/15 veriyordu — kimse kazanamadığı 11 puan, yayınlanan her skordan, en yüksek olanlar dahil, yaklaşık 4.3 puan çıkıyor. Ücret artık max(gözlemlenen en düşük ücret, protokol tabanı) olarak sabitlendi, doğrulayıcı sayfası Granite fork'undan beri bunu yaptığı şekilde: yasal minimum ücret talep etmek tam puanları kazanır ve yalnızca bunun üzerindeki ücretler mesafeye göre cezalandırılır. Bu tüm skorları benzer bir miktarla yükseltir ve sıralamayı değiştirmez. Yayınlanan orana sahip sağlayıcılar (1) ile (3) değişikliklerinden etkilenmez. Ödül oranı tahmin edilmiyor veya çıkarılmıyor: bu satırlar "Veri yok" yazıyor. (5) Ödül oranı artık tek bir endekse bağlı değil. Yalnızca Flaremetrics'ten okunuyordu, bu nedenle bu endeksin kapsamı bıraktığı sağlayıcı Net ve Brüt APR'sini kaybetti ve Ödül Oranı'nda 0/25 puan aldı — birinin kapsamı açığı için 25 puanlık ceza. Flare Systems Explorer aynı rakamı yayınlar ve daha fazla varlığı kapsar, bu nedenle artık herhangi bir açığı doldurur; canlı bir Flaremetrics oranı asla üzerine yazılmaz. Bu sevkiyatın yapıldığı gün, hiçbiri olmayan 15 sağlayıcıya yayınlanan bir oran geri getirdi.
v4.6 (2026-07-01) — Tutarlılık yeni düğümler için yanlılıktan arındırıldı. Ödül oranının tam 30 dönem geçmişi üzerindeki ortalama/standart sapması idi, bu nedenle yeni bir düğümün rampa-enflasyonlu ilk kazanç dönemi (küçük oy ağırlığı → birim başına yüksek oran, daha sonra normalleşir) aylar boyunca CV'yi yüksekliğinde sabitleyen ve 0 puanlandıran bir aykırı değer görevi görüyordu. Şimdi sondaki pencereyi (son 12 kazanç dönemi) ve güçlü bir medyan/MAD dağılımını kullanıyor, böylece rampa dönemi zararsız bir aykırı değer iken gerçek devam eden oynaklık yine düşük puanlanıyor.
v4.5 (2026-06-30) — Öz-Tahvil boyuta göre nötrleştirildi. Sadece oran eğrisi, küçük bir özdeşim oranında küçük öz-tahvili AŞAN düşük bir orana sahip büyük mutlak öz-tahvili puanlayabiliyordu. Öz-Tahvil şimdi bir uyum oranı veya doymuş mutlak miktar (5M FLR'de sınırlı) hangisiyse ona kredi veriyor, böylece geniş çaplı taahhüt veren işletmeci ve tamamen uyumlu olan küçük bir operatör da tam puan alıyor — taahhüdü ödüllendiriyor, serveti değil, ve validatör kalitesi diğer boyutlarda kalıyor.
v4.4 (2026-06-30) — İki gerçek hata düzeltmesi. (1) Öz-Tahvil bir ÖLÜ boyuttu: API'nin bıraktığı bir Flaremetrics alanını okudu, bu nedenle her sağlayıcı 0/7 puanını aldı. Operatörün gerçek P-Chain düğümü öz-tahvilinden yeniden kaynaklandırıldı (validator seti tarafından nodeID'den çapraz referanslı). (2) Uyum, bir sağlayıcının aktif olmadan önce dönemi cezalandırmayı durdurdu — başından beri temiz kazanan yeni bir düğüm, daha önce kendisinden önce gelen her dönem için ücretlendiriliyordu ve bunu haftalar boyunca 0/10'da tutuyordu. Kaçırılan dönemler artık yalnızca her sağlayıcının aktif penceresi içinde sayılıyor.
v4.3 (2026-06-03) — Metodoloji açıklaması, puanlama matematiği değişikliği yok. Doğruluk boyutu artık açıkça zincir üstü ikincil bant açılış oranı olarak tanımlanıyor (fiyat KALİTESİ — gönderilen fiyatların ne kadarı kabul edilen bant içinde açılıyor), Uyum boyutundan farklı, bu da kaçırılan ödül dönemlerini sayıyor (FSP KATILIM). Bu sayfa ve validatörler-tablo araç ipuçları yeniden yazıldı ve ayrımı açık hale getirmek için bir Uyum sütunu eklendi. Her iki boyut da önceki ağırlıklarını korur (25 ve 10) ve girişler (fseAccuracySecondary ve epochsWithoutRewards).
v4.2 (2026-05-20) — Dağıtılan Ödüller boyutu onarıldı. Sağlayıcının v3 API'sinin bıraktığı bir Flaremetrics ödül dağıtımı alanına bağlıydı, bu nedenle boyut her sağlayıcı için 0 okudu ve hiçbir katkıda bulunmadı. Zincir üstü FSP delegasyon-ödül toplamlarına yeniden bağlandırıldı — Uyum boyutunun zaten topladığı aynı ödül talep verileri — böylece boyut yine farklılık gösteriyor.
v4.1 (2026-05-20) — Uyum boyutu sınırlandırıldı. epochsWithoutRewards negatif gelebiliyordu çünkü FSP ödülleri cron'u hadde penceresinin geçmişine dönem-varlık sayısını biriktiriyordu, bu da Uyumun 10 puanlık sınırını aşmasını sağlıyor (gözlemlenen ~58'e kadar) ve bileşimi maksimum üzerinden itti — kabaca %70 sağlayıcıyı düz 100 değerine doyuruyor. Uyum artık ağırlığına sınırlandırılıyor ve FSP cron'u hadde penceresinde bağımsız olarak ödül özetlerini yeniden hesapladığı için sayı artık sapamayabilir.
v4.0 (2026-05-11) — Validatör puanlamasının v4.0 yayınına eşdeğer tam adillik denetim geçişi. İki gerçek hata düzeltildi: (1) Delege Sayısı 500'de olumsuz bir teşvike sahipti — ön-düzeltme 500 delegatörlü demet 14 puan döndürüyordu ama >500 sınırı altta yatan WEIGHT_DELEGATORS (12) döndürüyordu, bu nedenle o sınır üzerinden bir delegatörlü kazanmak 2 puan KAYIPTI. Şimdi 5 → 500'den logaritmik ölçekte, monoton yukarı. (2) V2 Participation seviyeleri çöktü — kısmi V1 kayıt ve tam V2 (Scaling + FastUpdates + FDC) her ikisi de 15 döndürüyordu, bu nedenle kısmi V2'den tam V2'ye yükseltme sıfır puan iyileştirmesi sağlıyordu. Şimdi protokol başına yığılıyor (etkin +3, V1 +4, her V2 protokolü +~2,67). Sınır uçurumları Doğrulukta (97%'de 7 puanlık uçurum vardı), Stabilite ve Öz-Tahvil Oranında ortadan kaldırıldı — tümü doğrusal olarak değerler sınır sınırlarında korunmuş. Ödül Oranı eğrisi yeniden dengelenmiş, medyan = boyutun puanlarının yarısı (% 40 idi). Eski boyut belgelendirilmiş dizeleri gerçek ağırlık değerleriyle uzlaştırıldı. Net etki: her boyut giriş ekseninde monoton yukarı, ve hiçbir sağlayıcı FlareWatch puanını gerçek bir operasyonel metriği iyileştirerek düşüremez.
v3 (2026-05-09 → 2026-05-11) — Dinamik ağırlık yeniden dağıtımı ve oy gücü seyreltme cezası ile 13 boyutlu puanlama. MIRROR Participation birinci sınıf bir boyut olarak tanıtıldı (12 taban + Bayes daralması ve 30 günlük veri birikme kapısı ile +3'e kadar overperformans bonusu). Kimlik ve Öz-Tahvil ayrı boyutlar olarak eklendi. Ödül Oranı medyan-uyumlu olarak taşındı. Doğruluk yüksek çözünürlük bandı için FSE ikincil metriğini kullanıyor. Tutarlılık yakın dönem üzerinden CV kullanıyor.
v2 ve öncesi — Ön-v3 sürümleri burada belgelenmemiştir; daha basit bir boyut alt kümesi kullanıyordu ve dinamik ağırlık yeniden dağıtımından önceydi. Sürümler geçerli model lehine emekli oldu.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.