FTSO Provider Score Methodology

Algorithm version: v4.11 · Last updated: 2026-07-04

FlareWatch प्रत्येक FTSO डेटा प्रोवाइडर को 12 स्कोर किए गए आयामों में 0–100 कम्पोजिट स्कोर असाइन करता है। गणित निर्धारक है, इनपुट्स ब्लॉकचेन पर सार्वजनिक हैं और Flare-इकोसिस्टम डेटा हैं।[Flaremetrics] [FSE] [Flare Explorer], और एक ही algorithm हर provider को apply होता है — FlareWatch के अपने FTSO provider सहित, जिसे इस exact function के साथ score किया जाता है बिना special treatment के। यह page हर dimension और threshold को document करता है ताकि delegators और operators exactly देख सकें कि score कैसे compute होता है और प्रत्येक value क्यों choose किया गया। यहाँ हर claim अपने primary upstream source को back link करता है — देखें Sources & referencesनीचे।

दायरा: यह पृष्ठ FTSO प्रदाता स्कोर को दस्तावेज़ित करता है — जो आप वैलिडेटर पृष्ठ पर delegation mode में देखते हैं (FTSO डेटा प्रदाताओं को WFLR प्रत्यायोजित करना FTSO inflation share के लिए)। staking mode में दिखाया गया वैलिडेटर स्कोर (VRM + MIRROR पुरस्कारों के लिए P-Chain वैलिडेटर को FLR प्रत्यायोजित करना) एक अलग 9-dimension एल्गोरिदम का उपयोग करता है जो वैलिडेटर संचालन पर केंद्रित है — अपटाइम, शुल्क, विश्वसनीयता, आदि। ये विशिष्ट ऑन-चेन भूमिकाएं हैं विशिष्ट पुरस्कारों के साथ, अलग से स्कोर किए गए। staking पक्ष के लिए Validator Score Methodology देखें।
FLR / SGB chain coverage: वैलिडेटर पृष्ठ पर Delegation टैब में उन वॉलेट के लिए FLR / SGB टॉगल है जो किसी भी Songbird (SGB) को धारण करते हैं। यह पद्धति केवल FLR-side स्कोर को दस्तावेज़ित करता है। Songbird FTSO प्रदाता समग्र स्कोर के बिना सूचीबद्ध हैं — वही accuracy / consistency / FSP rewards डेटा जो हम FLR के लिए उपयोग करते हैं, अभी तक हमनी Songbird pipeline में तैयार नहीं है (Flaremetrics, हमारा प्राथमिक FLR डेटा स्रोत, Songbird को कवर नहीं करता)। क्या SGB प्रत्यायोजन देखते हैं आज: प्रदाता नाम + लोगो cross-network TowoLabs रजिस्ट्री से, वर्तमान weight (WSGB प्रत्यायोजित, सीधे Songbird के WNat contract से हमारे स्वयं के Songbird RPC के माध्यम से पढ़ा गया), और प्रदाता का URL। weight के अनुसार सॉर्ट करें; accuracy डेटा तक बड़ा weight प्रॉक्सी सिग्नल है। जब हम Songbird-side accuracy + reward-rate pipeline को तैयार करते हैं, तो same 13-dimension formula SGB प्रदाताओं पर लागू होगा — कोई नया scoring एल्गोरिदम नहीं, बस Songbird डेटा के विरुद्ध FLR formula की गणना की गई। FlareWatch वैलिडेटर scoring (staking tab) का SGB पूर्ण नहीं है: Songbird का P-Chain validator set Flare Foundation-approved entities तक प्रतिबंधित है, इसलिए retail SGB P-Chain प्रत्यायोजन दुर्लभ है और staking tab FLR-only रहता है।
स्कोर बैंड
90+शीर्ष tier — FTSO प्रदाताओं का शीर्ष ~10–20%। विशिष्ट प्रोफ़ाइल: above-median reward rate, उच्च accuracy, पूर्ण V2 protocol participation (FTSO Scaling + Fast Updates + FDC), low/zero fee, बड़ा delegator base, MIRROR-paying validator nodes, नाम वाली brand। कोई भी एकल dimension आवश्यक नहीं — प्रदाता अधिकांश श्रेणियों में शक्ति को stack करके Top tier तक पहुंचते हैं।
80–89मजबूत — अधिकांश मुख्य benchmarks पूरा करता है; top tier से एक या दो dimensions कम।
70–79अच्छा — सभी baseline criteria को पूरा करता है; कोई बड़ा gap नहीं।
60–69स्वीकार्य — उपयोगी लेकिन विभेदित नहीं।
<60Below median — एक या अधिक dimensions में महत्वपूर्ण gap। गणितीय तथ्य, गुणवत्ता निर्णय नहीं।
आयाम (कच्चा वजन — 172 तक जोड़ता है, 100 पर सामान्यीकृत)
"सक्रिय" दो आयामों को नियंत्रित करता है (शुल्क और V2 भागीदारी): एक प्रदाता जो चल नहीं रहा है उसे कम शुल्क का विज्ञापन देने के लिए क्रेडिट नहीं मिलना चाहिए। एक प्रदाता सक्रिय माना जाता है यदि उसके पास एक प्रकाशित पुरस्कार दर है या यदि Flare Systems Protocol पुरस्कार डेटा दिखाता है कि इसने स्कोरिंग विंडो के कम से कम एक epoch में भुगतान किया है। 2026-07-31 तक यह केवल पुरस्कार दर थी, जो एक एकल तीसरे पक्ष के API से आई थी — इसलिए एक प्रदाता जिसे वह API कवर नहीं करता था वह दोनों आयामों पर शून्य अंक प्राप्त करता था जबकि हर epoch में स्पष्ट रूप से पुरस्कार वितरित कर रहा था। सक्रियता प्रदाता की एक संपत्ति है, इसे सूचीबद्ध करने वाले की नहीं।
Reward Rate25 pts max
क्या: प्रदाता का reward rate प्रति epoch, network median के लिए anchored।
कैसे: ratio = providerRate / medianRate। Linear: ratio 1.0 (median) → 12.5 pts, ratio 2.0 → 25 pts (cap)। Inactive provider (rewardRate ≤ 0) → 0। v4.0 (2026-05-11): cap को rebase किया गया ताकि median = dimension के आधे अंक (पहले 40% नहीं)।
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).
क्यों: Reward rate वह #1 चीज है जो delegators अनुभव करते हैं। Median anchoring जैसे-जैसे network के reward economics बदलते हैं, स्कोर को honest रखता है — एक प्रदाता जो low rewards के युग में 1.2× median है, अभी भी same rank करता है जो high rewards के युग में 1.2× है। Caps और anomaly filters single-epoch outliers को dominance से रोकते हैं।
Accuracy25 pts max
क्या: Flare Systems Explorer (FSE) से FTSO मूल्य सटीकता — प्राथमिक (टाइट IQR) और माध्यमिक (व्यापक) पुरस्कार-बैंड लैंडिंग दरें।
कैसे: FTSO PRIMARY (टाइट IQR) और SECONDARY (व्यापक) बैंड लैंडिंग दरों का 40/60 मिश्रण (v4.8), Flare के अपने पुरस्कार विभाजन को दर्शाता है — FIP.11 एंकर-फीड पुरस्कार 40% प्राथमिक / 60% माध्यमिक का भुगतान करता है। माध्यमिक पूर्व टुकड़ावार वक्र का उपयोग करता है (97% → 25 … 70% → 2); यह क्षेत्र भर में लगभग संतृप्त है (95–99%), इसलिए यह मुश्किल से अंतर करता है। प्राथमिक एक निरपेक्ष रैखिक वक्र का उपयोग करता है — 28% → 0 से 78% → पूर्ण 25 तक — ताकि बहुत कठिन टाइट-बैंड इंजीनियरिंग, जहां प्रदाता वास्तव में ~28% से ~80% तक फैलते हैं, वह क्षेत्र को अलग करता है। निश्चित एंकर (क्षेत्र प्रतिशत नहीं), इसलिए स्कोर प्रदाता के अपने इनपुट से पुनः व्युत्पन्न रहता है। जब केवल एक उपलब्ध हो तो एकल-बैंड फॉलबैक; FSE डेटा के बिना तटस्थ 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
क्यों: Missed epochs = delegators के लिए missed reward income। Accuracy निर्धारित करता है कि प्रदाता के submissions वास्तव में FTSO consensus के लिए count करते हैं, और secondary metric (जो अधिक recent epochs को weight देता है) वह है जो current performance के लिए cleanest map करता है।
Consistency20 pts max
क्या: प्रदाता का reward rate अपने सबसे हाल के earning epochs में कितना stable है।
कैसे: किसी प्रदाता के सबसे हाल के earning epochs में downside volatility, केवल genuinely consecutive epochs के बीच मापी गई — एक epoch जिसमें प्रदाता को कुछ नहीं मिला वह कोई रिकॉर्ड नहीं छोड़ता, और उस gap के दोनों ओर के दो epochs की कभी तुलना नहीं की जाती। केवल epoch-over-epoch DROPS गिनते हैं — वृद्धि शून्य योगदान देती है — इसलिए एक स्थिर या बढ़ती दर लगभग पूर्ण स्कोर प्राप्त करती है और एक recovery स्कोर को बढ़ाती है जैसे-जैसे यह होती है। Drops को RMS-aggregated किया जाता है इसलिए एक strong dip एक slight को अधिक weight देता है, और recent pairs की ओर weighted (decay 0.8) इसलिए एक active recovery स्कोर को ऊपर खींचता है जबकि old dips पुराने हो जाते हैं। cv = 0 → 20 pts; cv ≥ ~0.167 → 0. Neutral 10 जब पिछले 12 earning epochs में 3 से कम consecutive epoch pairs मौजूद हों।
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)
क्यों: दो प्रदाता जिनकी समान औसत पुरस्कार दर है, बहुत अलग staker अनुभव प्रदान कर सकते हैं: जो कठोर गिरता है वह उससे बदतर है जो स्थिर रहता है या चढ़ता है। Consistency वह पुरस्कृत करता है जो एक delegator वास्तव में चाहता है — एक स्थिर या बढ़ती दर — और केवल गिरावट को दंडित करता है, गहराई के अनुपात में। एक दर जो वापस ऊपर जाती है कभी दंडित नहीं होती (पहले की सममित माप करती थी, जो पीछे की ओर थी)। एक हाल की मजबूत गिरावट कम स्कोर करती है और फिर पुनरावृत्ति होती है जैसे ही यह बाहर निकल जाती है।
V2 Participation15 pts max
क्या: क्या प्रदाता modern V2 stack (FTSO Scaling + Fast Updates + FDC) चला रहा है।
कैसे: Per-protocol stacking। Active baseline (rewardRate > 0) +3, V1 partial (submit + signing + voter) +4, each V2 protocol (FTSO Scaling / Fast Updates / FDC) +~2.67 each, cap at 15। Inactive → 0। v4.0 (2026-05-11) ने previous all-or-nothing tier (जहां partial V1 = full V2 = 15 — upgrade के लिए कोई incentive नहीं) को per-protocol bonuses में split किया जो stack करते हैं।
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
क्यों: V2 वह है जहां network जा रहा है। v4.0 के per-protocol stacking का मतलब partial V1 से full V2 में upgrade करने का अर्थ है score move करता है (pre-fix में यह नहीं था — partial V1 और full V2 दोनों 15 return करते थे)। अब कोई भी एकल V2 protocol जोड़ना dimension को improve करता है।
Fee15 pts max
क्या: प्रदाता प्रत्यायोजित rewards पर charge करता है।
कैसे: Linear interpolation breakpoints के across: 0% → 15, 5% → 13, 10% → 10, 15% → 7, 20% → 4, ≥25% → 0। Inactive provider → 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
क्यों: Fee सीधे delegators को मिलने वाले को reduce करता है। Linear interpolation (buckets की बजाय) का मतलब है कि 7% fee 10% और 15% के बीच score करता है बजाय एक bucket में snap करने के — operators को अपने fee को next bucket boundary तक round down करने के लिए credit नहीं मिलता।
MIRROR Participation12 (+3 bonus) pts max
क्या: क्या operator के P-Chain validator nodes सक्रिय रूप से stakers को FTSO inflation share pay करते हैं, साथ ही एक overperformance bonus।
कैसे: बेस स्कोर ऑपरेटर के उन nodeIDs के अंश के साथ रैखिकतः स्केल करता है जो MIRROR पुरस्कार देते हैं। सभी नोड्स सक्रिय → 12 अंक। आंशिक → आनुपातिक। कोई नहीं → 0। 2026-05-11 तक, 'सक्रिय' सिग्नल दो canonical स्रोतों से पढ़ता है: V2 RewardManager पर on-chain RewardClaimed(claimType=3) इवेंट्स AND आधिकारिक FSP Merkle JSON में claimType=3 allocations — कोई एक पर्याप्त है। पूर्व-अपडेट में हमने on-chain स्ट्रीम को एकमात्र सिग्नल के रूप में उपयोग किया था, जो उन प्रदाताओं के लिए false negatives उत्पन्न करता था जिनका MIRROR गैर-मानक क्लेम पाथ के माध्यम से settle करता था। साथ ही एक overperformance बोनस जो +3 अंक तक हो सकता है जब ऑपरेटर के validators लगातार अपेक्षित (vrm + mirror) / अपेक्षित से 100% से अधिक deliver करते हैं — Bayesian shrinkage एक 30-दिन के डेटा accrual gate और न्यूनतम 3-stake नमूने के साथ छोटे या नए ऑपरेटरों को कुछ भाग्यशाली रीडिंग पर बोनस को गेम करने से रोकता है।
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
क्यों: MIRROR भागीदारी वह है जो FTSO मुद्रास्फीति शेयर को आपके stakers के लिए delegate करता है। एक V2-सक्रिय प्रदाता जिसके validator नोड्स MIRROR नहीं देते हैं, वह उसी प्रदाता से ~5–15% कम yield shipment कर रहे हैं जिनके सक्रिय नोड्स हैं। overperformance बोनस लगातार-बेहतर-than-अपेक्षित delivery को reward देता है बिना नए ऑपरेटरों को छोटे नमूनों पर inflate किए — Bayesian shrinkage और 30-दिन के accrual gate इसे fair रखते हैं।
Delegator Count12 pts max
क्या: इस प्रदाता को वर्तमान में प्रत्यायोजित करने वाले अलग-अलग वॉलेट की संख्या, चेन स्थिति से गिनी गई।
कैसे: Log-स्केल किया गया 5 → 500 delegators को 0 → 12 पर मैप किया गया। ≤5 → 0, ≥500 → 12 (cap)। validator Trust dimension के count सिग्नल स्टाइल से मेल खाता है। v4.0 (2026-05-11): एक वास्तविक बग को ठीक किया जहां पिछली bucket स्कीम में ठीक 500 delegators पर एक विपरीत प्रोत्साहन था (पूर्व-fix: 500 → 14, 501 → 12 — उस सीमा पार एक delegator gain करना 2 अंक LOST करता था)।
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
क्यों: Delegator count एक trust सिग्नल है — stake आकार से स्वतंत्र। 200 delegators वाला प्रदाता 200 स्वतंत्र stakers द्वारा चुना गया है; 5 वाला लगभग अपने ऑपरेटर द्वारा चुना गया है। Log स्केलिंग ~50 delegators के बाद diminishing returns देता है बिना कभी reverse किए (जिस तरह bucketed स्कोरिंग pre-v4.0 में करती थी)।
Epoch Participation10 pts max
क्या: क्या प्रदाता epochs में सक्रिय रूप से भाग ले रहा है।
कैसे: FSE प्रदाता को सक्रिय चिह्नित करता है → 10। प्रदाता के पास rewardRate > 0 है (Flaremetrics) लेकिन कोई FSE सक्रिय flag नहीं → 7 (बाजार डेटा के अनुसार सक्रिय, FSE पुष्टि लापता)। अन्यथा → 0।
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
क्यों: उन प्रदाताओं को पकड़ता है जिनकी reward स्ट्रीम stall हो गई है भले ही Flaremetrics अभी भी उन्हें सूचीबद्ध करता है। Accuracy से अलग (जो प्रति-epoch सटीकता के बारे में है) — Participation बस दिखना है।
Vote Power Stability10 pts max
क्या: प्रदाता की vote power में दिन-दर-दिन प्रतिशत परिवर्तन।
कैसे: Piecewise linear absolute दिन-दर-दिन प्रतिशत परिवर्तन में। <1% → 10। Linear 1% → 3% से (10 → 7)। Linear 3% → 5% से (7 → 4)। Linear 5% → 10% से (4 → 2)। 10% के बाद 0 की ओर जारी है। v4.0 (2026-05-11): पिछली bucket cliffs को linearized किया (प्रत्येक threshold पर up to 3-point cliffs थे)।
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)
क्यों: Vote power में बड़े दिन-दर-दिन swings अक्सर एक delegator wave को इंगित करते हैं जो अंदर या बाहर जा रहा है — table पढ़ने वाले stakers एक moving target देखते हैं। Stable vote power एक settled प्रदाता के साथ sticky delegators को सिग्नल करता है।
Compliance10 pts max
क्या: क्या प्रदाता FSP rewards डेटा में सक्रिय होने के बाद से हर reward epoch में paid था।
कैसे: प्रदाता की सक्रिय window के भीतर शून्य missed epochs के लिए पूर्ण 10 अंक। प्रत्येक missed epoch 3 अंक deduct करता है (0 पर clamped)। कोई FSP डेटा उपलब्ध न होने पर Neutral 5। v4.4 (2026-06-30): missed epochs अब केवल प्रदाता के पहले भाग लेने वाले epoch से forward गिने जाते हैं — एक नया प्रदाता अब epochs के लिए charge नहीं किया जाता है जब तक यह exist नहीं करता था (जिसने पहले new-but-clean नोड्स को हफ्तों के लिए 0/10 पर रखा था)।
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)
क्यों: आधिकारिक Flare Systems Protocol reward distribution में एक missed epoch का मतलब है प्रदाता उस epoch के लिए protocol compliance विफल रहा — minimum conditions, signing policy, आदि। केवल first participation से counting नए प्रदाताओं के लिए measure को fair रखता है जबकि अभी भी genuine misses को penalize करता है। तीन अंक per miss steep है इसलिए एक single miss एक noticeable सिग्नल है लेकिन recoverable है; ~3 misses dimension को zero करते हैं।
Identity8 pts max
क्या: क्या प्रदाता के पास एक real brand name है या सिर्फ एक hex address।
कैसे: Named brand (≥4 chars, 0x से शुरू नहीं) → 8। Short या anonymous (<4 chars) → 4। Pure hex / 0x address as name → 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
क्यों: एक named प्रदाता खुद को findable और accountable होना चुना है — वे looked up, contacted, और published commitments के लिए held किए जा सकते हैं। Anonymous-by-address प्रदाता functional हैं लेकिन delegators को evaluate करने के लिए fewer trust signals offer करते हैं।
Self-Bond7 pts max
क्या: ऑपरेटर का OWN P-Chain node bond (skin in the game) — अन्य लोगों द्वारा delegate किए गए stake को छोड़कर। एक size-neutral commitment gate, wealth ranking नहीं।
कैसे: दो saturating axes में से GREATER पर credited: (1) alignment — own bond total committed stake का एक share (≥10% → full); या (2) absolute — own capital at stake, 5M FLR पर capped इसलिए 5M और 80M same score करते हैं। v4.4 (2026-06-30): ऑपरेटर के true P-Chain self-bond से re-sourced (validator weight nodeID द्वारा cross-referenced) — पिछली Flaremetrics field जिसे यह read करता था discontinued था, इसलिए हर प्रदाता 0 पर score किया था। v4.5 (2026-06-30): absolute axis + saturation जोड़ा गया इसलिए एक बड़ा self-bond एक low ratio पर एक छोटे से नीचे scored नहीं है एक high ratio पर, बिना size को win करने या small operators को penalize किए।
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)
क्यों: Skin in the game — एक ऑपरेटर अपने own capital को risk पर रखता है वह delegators के साथ aligned है। लेकिन self-bond size operator QUALITY का proxy नहीं है (जो अन्य dimensions में रहता है), इसलिए एक छोटा fully-aligned ऑपरेटर और एक बड़ा committed one दोनों full marks earn करते हैं। केवल एक ऑपरेटर अपने own capital के साथ little committed — small share AND small amount — full से below score करता है।
कैसे 100/100 को स्कोर करें — एक FTSO provider playbook
v4.0 fairness audit विशेष रूप से design किया गया था ताकि हर score dimension को max करना genuinely आपको अपने delegators के लिए एक better FTSO provider बनाए। अपने score को improve करना system को game करना नहीं है — यह system working as designed है। यहां per-dimension playbook है।
Reward Rate — 25 अंक। Deliver ≥ 2× network median FSP reward rate प्रति epoch (after-fee, post-protocol-distribution)। Linear 0 से 2× median तक: median → 12.5, 2× median → 25। यह क्यों align करता है: यह dollar amount है जो actually आपके delegators के लिए per epoch पहुंच रही है।
Accuracy — 25 अंक। Target ≥97% secondary-band landing rate FSE पर full points के लिए। Piecewise linear इसलिए 95% → 18, 93% → 16, 90% → 13, आदि — हर 1% improvement score को move करता है। यह price-QUALITY है, epoch participation नहीं: यह measure करता है कि submitted prices का कितना fraction on-chain accepted band के अंदर land करता है। High Accuracy वाला प्रदाता consensus के close prices publish करता है; low Accuracy वाला reliably submit करता है लेकिन अधिक बार off-consensus होता है। यह क्यों align करता है: off-band submissions छोटे delegator rewards produce करते हैं भले ही प्रदाता हर epoch में participate करे। अलग Compliance dimension नीचे epoch participation track करता है।
Consistency — 20 अंक। Per-epoch reward-rate variance को minimize करें (CV = stddev/mean recent epochs में)। CV = 0 → 20, CV = 0.2+ → 0। यह क्यों align करता है: same mean reward rate वाले दो providers equivalent नहीं हैं — predictable payouts volatile ones को beat करते हैं staker UX के लिए।
V2 Participation — 15 अंक। Stack protocols additively: active baseline + V1 partial registration + each V2 protocol (Scaling, FastUpdates, FDC)। Full V2 + active + V1 registered = 15। यह क्यों align करता है: V2 वह जगह है जहां network जा रहा है; हर additional protocol जो आप adopt करते हैं एक forward investment है जो आपके delegators benefit करते हैं।
Fee — 15 अंक। Charge ≤ 5% के लिए 13 अंक, 0% के लिए 15। Piecewise linear ramp 5%/10%/15%/20%/25% breakpoints के माध्यम से 0 तक। यह क्यों align करता है: lower fee = अधिक reward directly आपके delegators को पहुंचता है।
MIRROR Participation — 12 + up to 3 बोनस। अपने सभी operator के P-Chain validator nodes को MIRROR-सक्रिय के रूप में चलाएं (या तो on-chain RewardClaimed events के माध्यम से OR FSP Merkle JSON allocations — v3.6 dual-source)। Sustained overperformance (median (vrm+mirror)/expected ratio 1.05 से ऊपर) ≥3 paid stakes पर 30 दिन के observation के बाद up to +3 बोनस earn करता है। यह क्यों align करता है: MIRROR आपके delegators का FTSO inflation का share है; nodes MIRROR नहीं देते हैं ~5-15% कम yield stakers को shipment करते हैं।
Delegator Count — 12 अंक। Log-scaled 5 → 500 delegators को 0 → 12 पर मैप किया गया। Independent stakers का एक base build करें, सिर्फ कुछ whales नहीं। यह क्यों align करता है: count एक trust सिग्नल है stake size से स्वतंत्र; 200 delegators आपको pick करना मतलब 200 independent endorsements।
Epoch Participation — 10 अंक। हर epoch में positive reward rate और सक्रिय FSE flag के साथ show up करें। यह क्यों align करता है: stalled-out reward streams को पकड़ता है जो per-epoch dimensions miss कर सकते हैं।
स्थिरता — 10 अंक। दिन-दर-दिन वोट-पावर परिवर्तन 1% के अंतर्गत रखें। वहां से टुकड़ों के अनुसार रैखिक रैंप। यह क्यों संरेखित है: स्थिर वोट पावर बसे हुए प्रतिनिधियों (स्टिकी समुदाय) का संकेत देता है न कि क्षणिक व्हेल लहरों का।
अनुपालन — 10 अंक। FSP डेटा में शून्य छूटे हुए पुरस्कार युग। प्रत्येक मिस 3 अंक खर्च करता है; ~3 मिस आयाम को शून्य कर देता है। यह भागीदारी है, कीमत की गुणवत्ता नहीं: यह उन युगों की गिनती करता है जहां प्रदाता को न्यूनतम शर्तें, हस्ताक्षर नीति, या अन्य प्रोटोकॉल आवश्यकताओं को याद करने के लिए दंडित किया गया था — ऊपर दी गई सटीकता आयाम से अलग जो इन-बैंड मूल्य लैंडिंग को स्कोर करता है। यह क्यों संरेखित है: प्रोटोकॉल के अपने पुरस्कार वितरण में एक छूटा हुआ युग का मतलब है कि प्रदाता न्यूनतम शर्तें पूरी नहीं कर पाया और प्रतिनिधियों ने उस युग में कुछ नहीं अर्जित किया। एक प्रदाता के पास भाग लिए गए युगों पर बेहतरीन सटीकता हो सकती है और फिर भी पूरी तरह से युग को याद कर सकता है।
पहचान — 8 अंक। Flaremetrics या FSE पर एक वास्तविक ब्रांड नाम (≥4 वर्ण, हेक्स पता नहीं) पंजीकृत करें। अनाम-दर-पता प्रदाता 0 स्कोर करते हैं; नामित प्रदाता 8 स्कोर करते हैं। यह क्यों संरेखित है: नामित प्रदाता खोजने योग्य और जवाबदेह होते हैं; यह आधारभूत विश्वास संकेत है।
स्व-बंधन — 7 अंक। अपना P-Chain नोड बंधन प्रतिबद्ध करें (दूसरों के स्टेक नहीं जो आप प्रतिनिधि बनाते हैं)। आपके कुल स्टेक के सार्थक हिस्से के लिए पूर्ण अंक (≥10%) या एक सार्थक पूर्ण राशि (पूर्ण अक्ष 5M FLR पर संतृप्त होता है, इसलिए एक बड़ा ऑपरेटर आकार पर एक छोटे को आउट-स्कोर नहीं कर सकता)। यह क्यों संरेखित है: खेल में चमड़ी — अपने स्वयं के पूंजी पर जोखिम वाले ऑपरेटर अपने प्रतिनिधियों के पैदावार परिणामों को साझा करते हैं। यह एक आकार-तटस्थ प्रतिबद्धता गेट है, न कि एक संपत्ति रैंकिंग: एक पूरी तरह से संरेखित छोटा ऑपरेटर और एक बड़ा प्रतिबद्ध दोनों इसे अधिकतम करते हैं, और आपकी परिचालन गुणवत्ता अन्य आयामों द्वारा निर्णीत होती है।
समय-गेटेड संकेत जिन्हें आप शॉर्टकट नहीं कर सकते: स्थिरता को ≥3 युगों का इतिहास चाहिए। MIRROR अतिप्रदर्शन बोनस को 30 दिनों की अवलोकन अवधि और ≥3 भुगतान किए गए स्टेक नमूने की आवश्यकता है। अनुपालन को FSP डेटा को गिनने के लिए पर्याप्त युगों में फैलाने की आवश्यकता है। एक ट्रैक रिकॉर्ड बनाएं; स्कोर अनुसरण करेगा।
कच्चा स्कोर 12 स्कोर किए गए आयामों में अधिकतम 172 तक जोड़ता है और फिर 100 तक नॉर्मलाइज़ किया जाता है। इनपुट्स पर एक परफेक्ट रन 172/172 → 100 प्रदर्शित हिट करता है। वोट-पावर डाइल्यूशन पेनल्टी अधिकतम −3 pts बहुत बड़े प्रोवाइडर्स (>1.34B VP) के लिए टाईब्रेकर के रूप में लागू होता है।
अपने स्वयं के स्कोर को कैसे सत्यापित करें
प्रदाताओं तालिका पर प्रत्येक स्कोर सार्वजनिक डेटा से प्रजनन योग्य है। यदि आप एक ऑपरेटर हैं और यहां गणित आपके द्वारा देखे गए स्कोर से मेल नहीं खाता है, तो सही कदम है कि यह मानने से पहले इसे स्वयं सत्यापित करें कि हमने त्रुटि की है। निर्देश:
  1. अपने प्रदाता के सार्वजनिक आंकड़ों को देखें flaremetrics.io पर (नाम से खोजें या अपना प्रतिनिधि पता पेस्ट करें)। अपना fspRewardRate, delegationFeePercentage, wNatWeight, और votePowerDailyChangePct नोट करें।
  2. flare-systems-explorer.flare.network पर अपनी FTSO V2 + सटीकता सत्यापित करें। अपनी इकाई खोजें। सटीकता के लिए providersuccessrate.secondary जांचें, साथ ही V2 स्थिति के लिए entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc फ़्लैग।
  3. V2 RewardManager अनुबंध पर flare-explorer.flare.network के माध्यम से अपनी MIRROR भागीदारी जांचें। RewardClaimed घटनाओं के लिए claimType=3 के साथ अपनी nodeIDs को संदर्भित करते हुए देखें। यदि आपके किसी भी नोड के लिए हाल ही में कोई नहीं हैं, तो आप स्कोर पर MIRROR-निष्क्रिय दिखाई देंगे।
  4. अपने इनपुट को ऊपर दिए गए सूत्रों में प्लग करें। प्रत्येक आयाम का कोड ब्लॉक आपको बताता है कि बिल्कुल कौन सी गणित चलानी है। आयामों को जोड़ें, 172 (कच्चा अधिकतम) से विभाजित करें, 100 से गुणा करें, और आपके पास आपका कच्चा समग्र स्कोर है।
  5. यदि आप बड़े हैं तो कमजोरी दंड लागू करें। 1.34B से ऊपर वोट पावर −3, 1B से ऊपर −1। अंतिम स्कोर कार्ड के नीचे सटीक थ्रेसहोल्ड हैं।
  6. अपने प्रदर्शित स्कोर से तुलना करें। प्रदर्शित स्कोर गतिशील वजन पुनर्वितरण को भी प्रतिबिंबित करता है — जब अधिकांश प्रदाता एक आयाम में क्लस्टर करते हैं (सक्रिय सेट में कम मानक विचलन), उस आयाम का वजन उन आयामों को पुनर्वितरित किया जाता है जहां प्रसार व्यापक है। प्रत्येक प्रदाता पंक्ति पर स्कोर-ब्रेकडाउन पैनल वर्तमान प्रति-आयाम मान दिखाता है।
  7. यदि गणित जोड़ी नहीं जाती है, [email protected] को अपना प्रतिनिधि पता, आपके द्वारा उपयोग किए गए इनपुट, और आपके द्वारा गणना किए गए स्कोर के साथ ईमेल करें। हम प्रतिक्रिया देंगे, और यदि हमने त्रुटि की तो हम इसे सार्वजनिक रूप से ठीक करेंगे।
सामान्य ऑपरेटर चिंताएं
मेरी पुरस्कार दर माध्यिका से ऊपर है लेकिन मेरा पुरस्कार दर स्कोर 25/25 नहीं है — क्यों?
पुरस्कार दर माध्यिका के अनुपात में रैखिक है: स्कोर = अनुपात × 12.5, तो 1.0× माध्यिका = 12.5/25 और आपको कैप को मारने के लिए 2.0× अनुपात की आवश्यकता है। 1.2× माध्यिका पर एक प्रदाता 15 स्कोर करता है, 1.5× पर ~18.8 स्कोर करता है, 2.0× पर पूर्ण 25 स्कोर करता है। कैप (साथ ही 3×-माध्यिका विसंगति फ़िल्टर) मौजूद है ताकि एक एकल विसंगत रूप से उच्च पुरस्कार युग आयाम पर हावी न हो सके; यदि आपकी दर लगातार शीर्ष-दशमलव है, तो स्कोर फिर भी इसे भारी पुरस्कृत करता है।
मैंने अभी V2 में अपग्रेड किया — मेरा V2 स्कोर कब अपडेट होता है?
V2 स्थिति FSE के entityminimalconditionslatest फ़्लैग (ftso_scaling, ftso_fast_updates, fdc) से आता है। v4.0 के बाद से आयाम प्रोटोकॉल के अनुसार स्टैक होता है: सक्रिय आधारभूत +3, V1 पंजीकरण (सबमिट + हस्ताक्षर + मतदान) +4, और प्रत्येक V2 प्रोटोकॉल +~2.67। तो सबमिट + हस्ताक्षर पते के साथ एक मतदान-पंजीकृत प्रदाता लेकिन तीन V2 प्रोटोकॉल में से कोई भी 7/15 स्कोर करता है, और हर व्यक्तिगत V2 प्रोटोकॉल जिसे आप चालू करते हैं स्कोर को आगे बढ़ाता है — सभी तीन लाइव पूर्ण 15 प्राप्त करता है। परिवर्तन FSE द्वारा उन्हें प्रतिबिंबित करने के बाद अगली FlareWatch cron रन (हर 5 मिनट) पर लैंड होते हैं।
FSE पर मेरी सटीकता 96% है लेकिन मैं अपेक्षा से कम स्कोर कर रहा हूं।
सटीकता आयाम FSE की माध्यमिक सटीकता मीट्रिक का उपयोग करता है (94–97% बैंड में उच्च संकल्प जहां अधिकांश प्रदाता क्लस्टर)। 95–96% 18 अंकों में मैप करता है; आपको पूर्ण 25 के लिए ≥97% की आवश्यकता है। बाल्टियां शीर्ष पर तंग हैं क्योंकि 95–97% बैंड में कुछ दसवें प्रदाताओं के बीच वास्तविक प्रदर्शन पृथक्करण का प्रतिनिधित्व करते हैं।
मैं MIRROR डिलीवर करता हूं — FlareWatch मुझे अपने प्रदाता स्कोर पर MIRROR-निष्क्रिय क्यों दिखाता है?
2026-05-11 के अनुसार, MIRROR भागीदारी दो स्रोतों से का पता लगाया जाता है: V2 RewardManager पर ऑन-चेन RewardClaimed(claimType=3) घटनाएं, और आधिकारिक FSP Merkle JSON में claimType=3 आवंटन। किसी भी स्रोत में दिखाई देने वाला एक nodeID सक्रिय के रूप में गिना जाता है। बहु-नोड ऑपरेटरों के लिए स्कोर सक्रिय नोड्स का अंश उपयोग करता है (1/3 सक्रिय = 4/12 आधार, आदि)। यदि किसी नोड को सक्रिय के रूप में वर्गीकृत किया जाना चाहिए लेकिन अगली स्वीप चक्र के बाद नहीं है, तो nodeID और विशिष्ट युग के साथ हमें ईमेल करें जहां आप दिखाई देने की अपेक्षा करते हैं — हम दोनों स्रोतों को क्रॉस-चेक करेंगे।
कल मेरी वोट पावर 8% चली गई — स्थिरता स्कोर ~2.8/10 क्यों है?
वोट पावर स्थिरता निरपेक्ष दिन-दर-दिन परिवर्तन में टुकड़ों के अनुसार रैखिक है (v4.0 में रैखिकीकृत — कोई बाल्टी चट्टानें नहीं): <1% → 10, 1→3% के ऊपर 7 तक रैम्पिंग, 3→5% 4 तक नीचे, 5→10% 2 तक नीचे, फिर 10% से परे 0 की ओर। एक 8% चाल 5–10% रैम्प पर 4 − (8 − 5) × 0.4 = 2.8 पर लैंड करता है। आशय प्रदाताओं को फ्लैग करना है जो सार्थक प्रतिनिधि टर्नओवर का अनुभव कर रहे हैं ताकि स्टेकर्स इसे तालिका पर देख सकें। स्कोर तुरंत ठीक हो जाता है क्योंकि आपकी वोट पावर स्थिर हो जाती है; एक अस्थिर दिन आपको स्थायी रूप से कम पर एंकर नहीं करता है।
मेरा प्रदाता अपनी इकाई पता (0x…) के साथ नामित है। पहचान स्कोर 0 क्यों है?
पहचान एक वास्तविक ब्रांड नाम के लिए 8 अंक (≥4 वर्ण, 0x के साथ या हेक्स-केवल से शुरू नहीं) और एक शुद्ध-पता नाम के लिए 0 देता है। हम एक नाम गढ़ नहीं सकते — Flaremetrics पर अपना profile.name सेट करें और हम अगली cron रन पर इसे उठाएंगे। यदि आपकी इकाई के पास एक प्रोफ़ाइल है लेकिन नाम फ़ील्ड खाली है, तो यही लागू होता है।
मेरे पास एक छोटा लेकिन प्रतिबद्ध प्रतिनिधि आधार है — प्रतिनिधि गणना स्कोर क्यों कैप किया गया है?
डेलिगेटर काउंट वास्तविक गणना का उपयोग करता है: WFLR रखने वाले प्रत्येक वॉलेट को अपने वर्तमान प्रत्यायोजन के लिए ऑन-चेन पर जांचा जाता है, और प्रत्येक प्रदाता के अलग-अलग डेलिगेटर की गणना की जाती है (हर ~6 घंटे में ताज़ा किया जाता है, एक स्वतंत्र इवेंट लेजर के विरुद्ध क्रॉस-चेक किया जाता है)। v4.0 के बाद से यह 5 → 500 डेलिगेटर को 0 → 12 अंकों में मैप किए गए लॉग-स्केल है, 500 पर सीमित है (≤5 को 0 स्कोर मिलता है)। लॉग स्केलिंग का मतलब है कि डेलिगेटर-काउंट वृद्धि के साथ छोटे प्रदाता सबसे तेजी से चढ़ते हैं; ~50 डेलिगेटर के बाद, अतिरिक्त डेलिगेटर डायल को कम हिलाते हैं — लेकिन वक्र मोनोटोनिक है, इसलिए एक डेलिगेटर प्राप्त करने से स्कोर कभी कम नहीं हो सकता (v4.0 से पहले की बकेट ऐसा हो सकती थीं)।
मैंने एक नोड जोड़ने के बाद स्कोर ड्रॉप किया — क्या हुआ?
यदि नया नोड अभी तक claimType=3 MIRROR घटनाओं को दिखा नहीं रहा है, तो आपका MIRROR अंश ड्रॉप हो जाता है (उदाहरण के लिए, 1/1 = 100% से 1/2 = 50%), MIRROR भागीदारी आधार स्कोर को कम करते हुए। एक बार नया नोड MIRROR का भुगतान करना शुरू कर देता है (आमतौर पर सक्रियण के एक या दो पुरस्कार युगों के भीतर), अंश ठीक हो जाता है और स्कोर वापस चढ़ जाता है।
क्या मैं अपने स्कोर पर अपील कर सकता हूं या मैनुअल समीक्षा का अनुरोध कर सकता हूं?
हाँ। [email protected] को अपने प्रतिनिधि पता और एक विशिष्ट चिंता के साथ ईमेल करें। हम हर ऑपरेटर को जवाब देते हैं। चीजें जो हम करेंगे: MIRROR-वर्गीकरण सुधार, आयाम-विशिष्ट गणित त्रुटियां, Flaremetrics के माध्यम से नाम/लोगो फिक्स। चीजें जो हम नहीं करेंगे: एल्गोरिथ्म के बाहर स्कोर को मैनुअल रूप से बढ़ाने के अनुरोध, किसी प्रतियोगी को बाहर करने या डी-रैंक करने के अनुरोध।
हम क्या करेंगे और क्या नहीं करेंगे
स्कोर कैसे संचालित करते हैं, इसके बारे में अस्पष्टता को दूर करने के लिए, यहां स्पष्ट प्रतिबद्धताएं हैं। यदि हम कभी इनमें से एक का उल्लंघन करते हैं, तो इसे दस्तावेज़ करें और [email protected] को ईमेल करें — हम सार्वजनिक रूप से इसे सही करेंगे।
✓
हम उच्च स्कोर, प्रायोजित स्थान, या किसी भी प्रकार के अनुकूल उपचार के लिए भुगतान स्वीकार नहीं करेंगे। स्कोर सार्वजनिक डेटा से नियतात्मक रूप से गणना किया जाता है।
✓
हम प्रति-प्रदाता बम्प को हाथ से कोडित नहीं करेंगे। कोड में कहीं भी "X को +5 मिलता है क्योंकि हम उन्हें पसंद करते हैं" लाइन नहीं है। FlareWatch के अपने प्रदाता सहित हर प्रदाता पर एक ही एल्गोरिथ्म लागू होता है, जो इस सटीक फ़ंक्शन द्वारा स्कोर किया जाता है।
✓
हम गैर-सार्वजनिक कारणों से प्रदाताओं को तालिका से बाहर नहीं करेंगे। सूची Flaremetrics + FSE से प्राप्त की जाती है; हमारा प्रदर्शन इन स्रोतों के सभी सक्रिय प्रदाताओं को शामिल करता है।
✓
हम एल्गोरिथम परिवर्तन प्रकाशित करेंगे। हर संस्करण बम्प को इस पृष्ठ पर वर्जन कार्ड में तर्क और जो कुछ बदला गया उसके साथ दस्तावेज़ित किया जाता है। प्रमुख परिवर्तन को ऐप के changelog पेज से दृश्यमान अतिरिक्त changelog प्रविष्टि मिलती है।
✓
हम ऑपरेटर ईमेल का जवाब देंगे। हर ऑपरेटर जो [email protected] को अपने स्कोर के बारे में कोई ठोस चिंता के साथ ईमेल करता है, वह कुछ कार्य दिवसों के भीतर एक वास्तविक प्रतिक्रिया पाता है।
✓
हम सार्वजनिक रूप से अपनी गलतियों को सुधारेंगे। यदि हम एल्गोरिथम में एक बग, डेटा-स्रोत त्रुटि, या पद्धति में अंतराल खोजते हैं, तो हम एक फिक्स जारी करते हैं और इसे दस्तावेज़ित करते हैं। हम चुपचाप पुनः-रैंक नहीं करते।
✗
हम नहीं करेंगे प्रेषक की अनुमति के बिना ईमेल सामग्री सार्वजनिक रूप से साझा करना, या ऑपरेटर ईमेल का उपयोग स्कोर बातचीत के अलावा किसी और चीज़ के लिए नहीं करेंगे।
✗
हम नहीं करेंगे एल्गोरिथम परिवर्तन के लिए अपनी भविष्य की योजना चुनिंदा ऑपरेटरों के साथ अग्रिम में साझा करना — हर संस्करण सभी के लिए एक साथ लाइव जाता है।
अंतिम स्कोर (आयाम कैसे संयोजित होते हैं)
सभी 12 स्कोर किए गए आयाम कुल योग को कच्चा (अधिकतम 172) देते हैं। कच्चा समग्र 0–100 पैमाने पर सामान्यीकृत है, फिर अंतिम प्रदर्शित स्कोर बनाने के लिए गतिशील वजन पुनर्वितरण लागू किया जाता है।
// 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)
कैप निकटता एक प्रदर्शन संकेत है, स्कोर में कटौती नहीं। v4.9 तक स्कोर ने बहुत बड़े प्रदाताओं से एक निश्चित 1–3 बिंदु भी घटाए थे, लेकिन यह दोहरी गिनती थी — एक ओवर-कैप प्रदाता पहले से ही एक नीचे-माध्यिका वास्तविक पुरस्कार दर अर्जित करता है, जिसे माध्यिका-एंकर्ड रिवॉर्ड रेट आयाम एक बार स्कोर करता है। तो दंड हटा दिया गया था। हर प्रदाता अब दिखाता है कि यह FSP कैप (WNat कॉन्ट्रैक्ट के लाइव कुल वोट पावर का 2.5%) को कितना भरता है, एक तटस्थ सीमांत-डेलिगेशन संकेत के रूप में: जितना 100% के करीब, उतना ही अधिक नया डेलिगेशन कम होता है।
डिस्प्ले-लेयर आउटलायर फ़्लैग: एक प्रदाता जिसकी वर्तमान पुरस्कार दर क्षेत्र माध्यिका से तीन से अधिक मजबूत विचलन (माध्यिका निरपेक्ष विचलन, ×1.4826 से स्केल किया गया) से अधिक है — और कम से कम 50% इसके ऊपर है — प्रदाता तालिका में एक आउटलायर बैज रखता है। बैज स्कोर को नहीं बदलता है; स्कोर का स्वयं का विसंगति गार्ड अलग से स्कोरिंग से पहले 3× माध्यिका से ऊपर की दरों को सीमित करता है। वार्षिकीकृत एपोक-दर स्पाइक आमतौर पर बहुत कम वोट शक्ति से आते हैं और एक एपोक के भीतर सामान्य हो जाते हैं।
डेटा स्रोत (हर इनपुट सार्वजनिक है)
Flare अनुबंध, सीधे ऑन-चेन पढ़ें: पंजीकृत प्रदाता सेट (VoterRegistry), इकाई → प्रतिनिधिमंडल पता और nodeID लिंक साथ ही प्रस्तुत/हस्ताक्षर पता पंजीकरण (EntityManager), प्रतिनिधिमंडित वोट शक्ति (WNat), और प्रतिनिधिमंडन शुल्क (WNatDelegationFee)। यह वह है जो प्रदाता सूची को किसी एक इंडेक्स से स्वतंत्र बनाता है: पुरस्कार epoch 420 में चेन में 98 पंजीकृत प्रदाता थे जबकि तीसरे पक्ष की सूची में 80 थे, और अंतर में 18 पहले इस साइट से पूरी तरह अनुपस्थित थे।
Flaremetrics सार्वजनिक API: पुरस्कार दर, प्रतिनिधिमंडल शुल्क, वोट शक्ति, वोट शक्ति दैनिक परिवर्तन, locked वोट शक्ति (self-bond), प्रोफाइल नाम + लोगो + क्षेत्र, fspRewardRate।
Flare Systems Explorer (FSE): FTSO सटीकता (प्राथमिक + माध्यमिक), V2 स्थिति फ्लैग (ftso_scaling, ftso_fast_updates, fdc), इकाई पता लिंकेज, हस्ताक्षर/सबमिट पता उपस्थिति, मतदाता पंजीकरण, P-Chain nodeID लिंकेज, और प्रति-इकाई प्रतिनिधिमंडन पुरस्कार दर (reward_rate_wnat)। पुरस्कार दर को जानबूझकर FSE और Flaremetrics दोनों से प्राप्त किया जाता है: वे विभिन्न इकाइयों में समान आंकड़ा प्रकाशित करते हैं (FSE दशमलव, Flaremetrics प्रतिशत — सभी 72 प्रदाताओं में पाँच दशमलव स्थानों तक सत्यापित समान है जो दोनों को वहन करते हैं), और FSE Flaremetrics के 80 के विरुद्ध 154 इकाइयों को कवर करता है। कोई भी एकल स्रोत प्रदाताओं को उनकी गलती के बिना कोई दर नहीं छोड़ता।
Flare Systems Protocol पुरस्कार डेटा (FSP): प्रति-epoch पुरस्कार वितरण प्रति प्रदाता, Compliance आयाम के लिए उपयोग किया जाता है (बिना पुरस्कार के epochs गिनता है) और प्रतिनिधिमंडल पुरस्कार कुल के लिए अधिकृत स्रोत के रूप में।
V2 RewardManager (claimType=3 events): on-chain claimed MIRROR वितरण प्रति validator nodeID। प्रकार 3 पर कड़ाई से फ़िल्टर किया गया — VRM, FTSO प्रतिनिधिमंडल, या DIRECT पुरस्कार के साथ कोई मिश्रण नहीं। FlareWatch का अपना indexer ये MIRROR Participation आयाम के लिए सतह में लाता है।
FSP Merkle JSON (claimType=3 allocations): यह विहित प्रकाशित रिकॉर्ड कि कौन प्रति epoch MIRROR का हकदार है (वही डेटा जो Flare का अपना signing टूल पढ़ता है)। 2026-05-11 को दूसरे अधिकृत स्रोत के रूप में जोड़ा गया — उन validators को पकड़ता है जिनके MIRROR आवंटित हैं लेकिन अभी तक on-chain में claim नहीं किए गए हैं।
FlareWatch ऐतिहासिक snapshots: प्रति-epoch पुरस्कार दरें Consistency CV को feed करती हैं; प्रति-validator paid-stake observations MIRROR overperformance बोनस को feed करते हैं (30-दिवस डेटा accrual gate के साथ)।
स्कोर में क्या नहीं है
• आत्म-प्रचार या भुगतान किया गया प्लेसमेंट। कोई भी प्रदाता उच्च स्कोर के लिए भुगतान या प्रायोजन नहीं कर सकता।
• Hand-coded प्रदाता-specific bumps। कहीं भी कोड में "X को +5 मिलता है क्योंकि हमें यह पसंद है" की कोई लाइन नहीं। समान एल्गोरिथम FlareWatch के अपने प्रदाता सहित हर प्रदाता पर लागू होता है, जिसे इसी सटीक फ़ंक्शन द्वारा स्कोर किया जाता है।
• व्यक्तिपरक infrastructure गुणवत्ता। हम uptime SLAs, भौगोलिक वितरण, या FSE और Flaremetrics के सार्वजनिक डेटा सतह द्वारा परे hardware specs का मूल्यांकन करने का प्रयास नहीं करते।
• FlareWatch के लिए Lockups या commitments। FlareWatch vs. किसी अन्य टूल का उपयोग करने वाले stakers के लिए कोई अनुकूल स्कोरिंग नहीं।
• Future signals अभी तक wired नहीं। Community presence (verified socials, governance participation), ऐतिहासिक slashing, response latency, और per-epoch trend लाइनें भविष्य के संस्करणों के लिए scoped हैं लेकिन आज v3 में नहीं हैं। कोई भी secretly weighted नहीं हैं।
ऑपरेटर feedback
अपने प्रदाता के स्कोर में कुछ गलत दिख रहा है? [email protected] को अपने प्रतिनिधिमंडन पते और चिंता के साथ ईमेल करें। हम हर ऑपरेटर को जवाब देते हैं। सामान्य अनुरोध जो हम कार्य करेंगे:
  • MIRROR-वर्गीकरण सुधार (claimType=3 attribution आपके nodeIDs के लिए)।
  • आयाम-specific गणित त्रुटियां आपने जो inputs का उपयोग किया उसके साथ।
  • नाम / लोगो / प्रोफाइल सुधार Flaremetrics या FSE के माध्यम से।
  • सामान्य एल्गोरिथम critique।
स्रोत और references
स्कोर का हर इनपुट सार्वजनिक, verifiable Flare-ecosystem स्रोतों से आता है। कोई भी इन प्राथमिक स्रोतों के विरुद्ध हमारे दावों को cross-check कर सकता है और कच्चे डेटा से गणित को reproduce कर सकता है। यदि आप इस पृष्ठ और upstream sources क्या कहते हैं के बीच discrepancy देखते हैं, [email protected] को ईमेल करें और हम इसे ठीक करेंगे।
अधिकृत protocol docs। FTSO V2, FSP, P-Chain validation, FAssets, और Flare stack के बाकी हिस्सों को कवर करता है।
Flare governance portal (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — V2 protocol न्यूनतम conditions, fee mechanics, और reward economics परिवर्तनों के लिए सत्य का स्रोत जो इस स्कोर को feed करते हैं।
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
Official Flare-operated FTSO डेटा प्रदाता registry, entity पते, P-Chain nodeID linkages, और न्यूनतम-conditions flags। हमारे Accuracy, V2, और Participation आयामों के लिए प्राथमिक स्रोत।
Flaremetrics ↗https://flaremetrics.io
Independent Flare-ecosystem metrics प्रदाता। पुरस्कार दरें, fees, vote शक्ति, vote शक्ति दैनिक परिवर्तन, locked vote शक्ति, प्रोफाइल नाम + लोगो, और fspRewardRate metric का स्रोत।
Flare Block Explorer ↗https://flare-explorer.flare.network
सभी on-chain state का read-only ब्राउज़र। किसी को भी V2 RewardManager के RewardClaimed events (claimType=3 MIRROR के लिए), reward epoch transitions, और बाकी को verify करने देता है।
Flare Foundation reward-scripts repo ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation द्वारा प्रकाशित per-reward-epoch JSON जो प्रति-validator delivered rewards दिखाता है। Indirect input — FlareWatch के per-stake observation indexer के माध्यम से MIRROR overperformance bonus calculation को feed करता है।
Flaremetrics सार्वजनिक API (FTSO प्रदाता) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
सटीक endpoint जिसे हमारा cron उपभोग करता है, entity profiles, reward rates, fees, और vote power return करता है। कोई भी इसे सीधे hit कर सकता है।
Flaremetrics सार्वजनिक API (नोड पंजीकरण) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID रूपांतरण तालिका। हम इसे paginate करते हैं ताकि entity-to-NodeID लुकअप बनाएं जो MIRROR Participation dimension को चलाता है।
कोई निजी डेटा नहीं, कोई बंद-स्रोत मॉडल नहीं। स्कोरिंग एल्गोरिथम FlareWatch codebase में services/ftso/scoring.ts में implemented है। Operators या researchers जो implementation को सीधे inspect करना चाहते हैं (बजाय ऊपर दिए prose + formulas को पढ़ने के) — या जो इसे अपने उपयोग के लिए fork करना चाहते हैं — access request करने के लिए [email protected] को email कर सकते हैं। यदि real demand हो तो हम file को standalone open-source package के रूप में publish करेंगे।
स्कोर कैसे अपडेट होते हैं
FTSO provider scoring cron के अंदर एक pass के रूप में चलता है /api/cron/refresh-validators पर, जो हर 5 मिनट में हर active provider के score को recompute करता है (वही run जो P-Chain validators को rescores करता है)। Inputs (Flaremetrics, FSE, FSP rewards, V2 RewardManager events) हर run पर fresh fetch किए जाते हैं।
Consistency CV हाल के epoch history का उपयोग करता है — यह dimension rolling window shift के रूप में move कर सकता है। 3 से कम historical epochs वाले newcomer providers को neutral 10 स्कोर मिलता है जब तक पर्याप्त डेटा जमा न हो जाए।
Dynamic weight redistribution हर run के दौरान recompute किया जाता है वर्तमान active provider set के आधार पर। जैसे-जैसे providers move करते हैं (उदा., नए V2 upgrades की wave), जो dimension non-discriminating बन जाता है वह shift होता है; redistribution स्वचालित रूप से adapt करता है।
एल्गोरिथम version इस page के header में stamped है। जब हम नया version ship करते हैं, तो यहाँ version string बदलता है और नीचे Versions card दस्तावेज़ करता है कि क्या moved।
Versions
v4.8 (2026-08-20) — Accuracy अब कठिन पुरस्कार बैंड को पुरस्कृत करता है। यह केवल FTSO माध्यमिक (व्यापक) बैंड का उपयोग करता था, जहां लगभग हर गंभीर प्रदाता 95–99% में आता है — इसलिए यह आयाम क्षेत्र के शीर्ष पर लगभग-फ्लैट 25/25 था, कुछ भी नहीं मापने के करीब। PRIMARY (टाइट IQR) बैंड वास्तविक कठिन इंजीनियरिंग है और प्रदाताओं को ~28–80% में फैलाता है। Flare इन बैंड को 40% प्राथमिक / 60% माध्यमिक पुरस्कृत करता है (FIP.11, 2024 से लाइव, आगे की माध्यमिक-बैंड वृद्धि संकेत के साथ), इसलिए Accuracy अब इसे दर्शाता है: एक 40/60 मिश्रण। माध्यमिक अपना पूर्व वक्र रखता है; प्राथमिक एक निरपेक्ष वक्र का उपयोग करता है (28% → 0, 78% → पूर्ण 25), निश्चित ताकि स्कोर प्रदाता के अपने इनपुट से पुनः व्युत्पन्न रहे। सभी 100 स्कोर किए गए प्रदाताओं पर पूर्ण पहले/बाद, शिप करने से पहले संग्रहीत: पुनः क्रम प्राथमिक-बैंड शक्ति को ट्रैक करता है — कठिन टाइट-बैंड काम करने वाले प्रदाता वृद्धि करते हैं, आसान माध्यमिक संख्या पर तट करने वाले प्रदाता गिरते हैं। समान नियम हमारे अपने प्रदाता पर लागू होता है, जिसके पास आज कमजोर प्राथमिक बैंड है: यह 84 से 77 में गिरता है और कई स्थान गिरता है। वैसे भी शिप किया गया — एक स्कोर जो वास्तविक इंजीनियरिंग को पुरस्कृत करता है, भले ही प्रतियोगी का हो और भले ही हमारे अपने खर्च पर हो, प्रकाशित करने के लिए एकमात्र प्रकार है।
v4.7 (2026-07-31) — प्रदाता सूची एकल सूचकांक पर निर्भर करना बंद कर गई, और स्कोर ने हमारे स्वयं के डेटा अंतराल को दंडित करना बंद कर दिया। (1) सूची अब ऑन-चेन पंजीकृत मतदाता सेट से बनाई गई है और जहाँ तीसरे पक्ष का सूचकांक इकाइयों को याद कर रहा है वहाँ वापस भरी गई है: पहले दिखाए गए 80 के विरुद्ध 98 प्रदाता, इसलिए 18 वास्तविक प्रदाता जो अदृश्य और यहाँ से अप्रतिनिधित्वशील थे अब दिखाई देते हैं। (2)
v4.6 (2026-07-01) — Consistency नए नोड्स के लिए de-biased। यह पूर्ण 30-epoch history पर reward rate का mean/stddev था, इसलिए एक नए नोड का ramp-inflated पहला earning epoch (tiny vote weight → high per-unit rate, जो फिर normalize हो जाता है) एक outlier के रूप में काम करता था जो CV को महीनों तक high पर pin करता था, 0 स्कोर करता था — जब तक यह age न हो जाए। अब यह trailing window (last 12 earning epochs) और robust median/MAD dispersion का उपयोग करता है, ताकि रamp epoch एक harmless outlier हो जबकि genuine ongoing volatility अभी भी कम स्कोर करे।
v4.5 (2026-06-30) — Self-Bond को size-neutral बनाया गया। केवल-ratio curve कम ratio पर बड़े absolute self-bond को छोटे self-bond के high ratio पर score कर सकता था। Self-Bond अब alignment ratio या saturating absolute amount (5M FLR पर capped) में से अधिक को credit करता है, इसलिए एक बड़ा committed operator और एक छोटा fully-aligned दोनों पूर्ण अंक अर्जित करते हैं — यह commitment को पुरस्कृत करता है, wealth को नहीं, और validator quality अन्य dimensions में रहता है।
v4.4 (2026-06-30) — दो real-bug fixes। (1) Self-Bond एक DEAD dimension था: यह एक Flaremetrics field को read करता था जिसे API ने drop कर दिया था, इसलिए हर provider 0/7 score करता था। Operator के true P-Chain node self-bond से re-sourced (validator set से nodeID द्वारा cross-referenced)। (2) Compliance ने epochs को penalize करना बंद कर दिया जिससे पहले एक provider active था — एक नया नोड जो अपनी launch के बाद से cleanly earn कर रहा था वह पहले हर epoch के लिए charged था जो इसे predate करता था, इसे हफ्तों के लिए 0/10 पर रखता था। Missed epochs अब हर provider की active window के भीतर गिने जाते हैं।
v4.3 (2026-06-03) — पद्धति स्पष्टीकरण, कोई scoring गणित परिवर्तन नहीं। Accuracy आयाम अब स्पष्ट रूप से on-chain secondary-band landing दर के रूप में परिभाषित है (मूल्य QUALITY — जमा किए गए मूल्यों का कौन सा अंश स्वीकृत बैंड के अंदर उतरता है), Compliance आयाम से अलग है, जो छूटे हुए reward epochs (FSP PARTICIPATION) की गणना करता है। यह पृष्ठ और validators-table tooltips दोनों को स्पष्ट करने के लिए फिर से लिखा गया था, और Accuracy के साथ एक Compliance कॉलम जोड़ा गया था। दोनों आयाम अपने पूर्व वजन (25 और 10) और इनपुट (fseAccuracySecondary और epochsWithoutRewards) रखते हैं।
v4.2 (2026-05-20) — Rewards Distributed dimension repaired। यह एक Flaremetrics reward-distribution field को wire किया गया था जिसे provider का v3 API drop कर गया था, इसलिए dimension हर provider के लिए 0 read करता था और कुछ भी contribute नहीं करता था। On-chain FSP delegation-reward totals को rewired — same reward-claim data जिसे Compliance dimension पहले से aggregate करता है — ताकि dimension फिर से differentiate हो।
v4.1 (2026-05-20) — Compliance dimension clamped। epochsWithoutRewards नकारात्मक आ सकता है क्योंकि FSP rewards cron ने अपने epoch-presence count को rolling window के पास accumulate किया, जिसने Compliance को अपने 10-point cap को exceed करने दिया (observed up to ~58) और composite को इसके maximum पास pushed किया — roughly 70% providers को flat 100 पर saturate किया। Compliance अब अपने weight तक clamped है, और FSP cron reward summaries को statelessly per window पर recompute करता है ताकि count कभी भी drift न कर सके।
v4.0 (2026-05-11) — Full fairness audit pass validator score के v4.0 release के बराबर। दो real bugs fixed: (1) Delegator Count में 500 पर एक perverse incentive था — pre-fix 500-delegator bucket 14 pts return करता था लेकिन >500 cap underlying WEIGHT_DELEGATORS (12) return करता था, इसलिए उस boundary के cross एक delegator प्राप्त करना 2 points LOST करता था। अब 5 → 500 से log-scaled, monotonic upward। (2) V2 Participation tiers collapsed थे — partial V1 registration और full V2 (Scaling + FastUpdates + FDC) दोनों 15 return करते थे, इसलिए partial से full V2 में upgrade करना zero score improvement प्रदान करता था। अब per-protocol stacking (active +3, V1 +4, प्रत्येक V2 protocol +~2.67)। Boundary cliffs Accuracy में eliminated (97% पर 7-pt cliff था), Stability, और Self-Bond Ratio — सभी linearized bucket boundaries पर values preserved के साथ। Reward Rate curve rebalanced ताकि median = dimension के आधे points (था 40%)। Stale dimension docstrings को actual weight values के साथ reconciled। Net effect: हर dimension input axis पर upward monotonic है, और कोई भी provider अपने FlareWatch score को एक actual operational metric improve करके lower नहीं कर सकता।
v3 (2026-05-09 → 2026-05-11) — 13-dimension scoring with dynamic weight redistribution और vote-power dilution penalty। MIRROR Participation एक first-class dimension के रूप में introduced (12 base + up to +3 overperformance bonus with Bayesian shrinkage और 30-day data accrual gate)। Identity और Self-Bond discrete dimensions के रूप में जोड़े गए। Reward Rate को median-anchored पर moved। Accuracy high-resolution band के लिए FSE secondary metric का uses करता है। Consistency recent epochs के cross CV uses करता है।
v2 और पहले — Pre-v3 versions यहाँ documented नहीं हैं; उन्होंने dimensions का एक simpler subset use किया था और dynamic weight redistribution को predate करते थे। Versions current model के पक्ष में retired।
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.