वेलिडेटर स्कोर पद्धति

एल्गोरिदम संस्करण: v4.8 · अंतिम अपडेट: 2026-08-19

FlareWatch प्रत्येक P-Chain वेलिडेटर को 9 आयामों में 0–100 कम्पोज़िट स्कोर प्रदान करता है। गणित नियतात्मक है, इनपुट सार्वजनिक चेन डेटा [Flare Explorer] [FSE] [Flaremetrics] हैं, और नेटवर्क पर प्रत्येक वेलिडेटर पर यही एल्गोरिदम लागू होता है — जिसमें FlareWatch का अपना वेलिडेटर नोड भी शामिल है, जिसे इसी सटीक फ़ंक्शन द्वारा कोई विशेष व्यवहार दिए बिना स्कोर किया जाता है। यह पृष्ठ प्रत्येक आयाम और थ्रेसहोल्ड को दस्तावेज़ित करता है ताकि ऑपरेटर और स्टेकर्स बिल्कुल देख सकें कि स्कोर कैसे परिकलित होता है और प्रत्येक मान को क्यों चुना गया था। यहां हर दावा अपने प्राथमिक ऑन-चेन या अपस्ट्रीम स्रोत से जुड़ा है — नीचे स्रोत और संदर्भ देखें।

दायरा: यह पृष्ठ वेलिडेटर स्कोर को दस्तावेज़ित करता है — जो आप वेलिडेटर्स पृष्ठ पर स्टेकिंग मोड में देखते हैं (VRM + MIRROR पुरस्कारों के लिए FLR को P-Chain वेलिडेटर को डेलीगेट करना)। डेलीगेशन मोड में दिखाया गया FTSO प्रदाता स्कोर (WFLR को FTSO डेटा प्रदाताओं को डेलीगेट करना) डेटा-प्रदाता प्रदर्शन पर केंद्रित एक अलग 13-आयामी एल्गोरिदम का उपयोग करता है — सटीकता, V2 प्रोटोकॉल भागीदारी, आदि। ये अलग ऑन-चेन भूमिकाएं हैं अलग पुरस्कारों के साथ, अलग स्कोर किए गए। डेलीगेशन पक्ष के लिए FTSO प्रदाता स्कोर पद्धति देखें।
कोई SGB समकक्ष नहीं: यह स्कोरिंग केवल Flare P-Chain वेलिडेटर्स पर लागू होती है। Songbird का P-Chain वेलिडेटर सेट Flare Foundation द्वारा अनुमोदित इकाइयों तक सीमित है, इसलिए खुदरा SGB P-Chain डेलीगेशन दुर्लभ है और स्टेकिंग टैब केवल FLR है। स्टेकिंग मोड में कोई FLR / SGB टॉगल नहीं है। SGB FTSO डेलीगेशन के लिए FTSO प्रदाता स्कोर पद्धति देखें, जो दोनों चेन को कवर करता है।
हम APY की गणना कैसे करते हैं — आप वास्तव में क्या कमाते हैं

स्टेकिंग टेबल पर APY वह ऑल-इन दर है जो डेलीगेटर प्राप्त करता है — एक संख्या, मानसिक गणित नहीं। यह Flare के रिवार्ड-स्क्रिप्ट्स से मापी गई है (वास्तविक भुगतान, सूत्र नहीं), वेलिडेटर की फीस के बाद, और यह हर एपोक वास्तविक रिवार्ड्स के साथ चलती है। FlareWatch पर हर जगह, APY का अर्थ फीस के बाद है और APY का अर्थ पहले है।

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • स्टेकिंग पुरस्कार (VRM) — डेलीगेटर का सत्यापन पुरस्कारों का शुद्ध हिस्सा = Σ डेलीगेटर पेआउट ÷ Σ डेलीगेट किया गया (Flare का अपना विभाजन; फीस पहले ही हटा दी गई है)। क्योंकि Flare स्टेक के अनुपात में भुगतान करता है, यह पूरे नेटवर्क में लगभग समान है और मुख्य रूप से फीस द्वारा भिन्न होता है — कम फीस का अर्थ है उच्च डेलीगेशन दर।
  • MIRROR — आपके स्टेक का FTSO मुद्रास्फीति का हिस्सा, शीर्ष पर भुगतान किया गया, केवल सक्रिय FTSO स्टैक चलाने वाले वेलिडेटर्स पर। यह वेलिडेटर की FTSO भागीदारी के आधार पर भिन्न होता है और सबसे हाल के epoch में मापा जाता है।

Flare Systems Explorer से तुलना? FSE और अन्य एक्सप्लोरर्स केवल डेलीगेशन दर दिखाते हैं — वे MIRROR नहीं जोड़ते — इसलिए हमारा कुल APY किसी भी MIRROR-सक्रिय वेलिडेटर पर अधिक पढ़ता है (अंतर बिल्कुल ऊपर MIRROR लाइन है)। दोनों आंकड़े उसी रिवार्ड-स्क्रिप्ट्स डेटा से ~8-एपोक ट्रेलिंग एवरेज हैं, इसलिए वेलिडेटर के मध्य-विंडो फीस परिवर्तन को किसी भी साइट पर वर्तमान-फीस स्नैपशॉट तक पिछड़ते हैं जब तक यह विंडो के माध्यम से उम्र तक नहीं।

APY टूलटिप में दो अन्य आंकड़े दिखाई देते हैं और नहीं डेलीगेटर की दर हैं: सैद्धांतिक बेसलाइन (नेटवर्क सकल APY × (1 − फीस), केवल स्टेकिंग — पर्याप्त मापी गई इतिहास से पहले फॉलबैक के रूप में उपयोग किया जाता है), और ऑपरेटर की स्व-बॉन्ड यील्ड (वेलिडेटर के अपने स्टेक रिटर्न, फीस कैप्चर द्वारा प्रवर्धित — एक ऑपरेटर मेट्रिक, वह नहीं जो आप कमाते हैं)।

स्कोरिंग के लिए: नेट यील्ड आयाम केवल VRM डेलीगेशन दर को स्कोर करता है, और MIRROR को अपने आयाम में स्कोर किया जाता है — इसलिए MIRROR कभी डबल-गिनती नहीं किया जाता है, भले ही यह प्रदर्शित कुल APY में शामिल हो।

स्कोर बैंड
90+शीर्ष स्तर — ऑपरेटर्स के शीर्ष ~10–20%। विशिष्ट प्रोफ़ाइल: पूर्ण-स्टैक वेलिडेटर + FTSO + FDC, कम-अंत फीस, MIRROR-सक्रिय, सुसंगत FIP-10 विश्वसनीयता, स्वस्थ डेलीगेटर बेस, सार्थक स्व-बॉन्ड। कोई एकल आयाम आवश्यक नहीं — ऑपरेटर्स अधिकांश श्रेणियों में शक्ति को स्टैक करके शीर्ष स्तर तक पहुंचते हैं।
80–89मजबूत — अधिकांश प्रमुख बेंचमार्क को पूरा करता है; शीर्ष स्तर से एक या दो आयाम कम है।
70–79अच्छा — सभी आधारभूत मानदंड को पूरा करता है; कोई बड़ा अंतर नहीं।
60–69स्वीकार्य — उपयोग योग्य लेकिन अलग नहीं है।
<60माध्यिका के नीचे — एक या अधिक आयामों में महत्वपूर्ण अंतर। गणितीय तथ्य, गुणवत्ता निर्णय नहीं।
आयाम (100 तक का योग)
अपटाइम20 अधिकतम pts
क्या: तत्काल P-Chain RPC अपटाइम और हाल के पुरस्कार epoch में ऐतिहासिक FIP-10 अपटाइम-पात्रता अनुपात का संयोजन।
कैसे: RPC वक्र: ≥ 99.5% → 17 से 20। 99–99.5% → 13–17। 95–99% → 4–13। 90–95% → 0–4। < 90% → 0। परिणाम को फिर uptimeReliability (पिछले 8 पुरस्कार epochs में public reward-scripts डेटा से epochsIncluded / epochsObserved — v4.2 के बाद से पूर्ण FIP-10 न्यूनतम सेट, केवल RPC-uptime नहीं) से गुणा किया जाता है। v3.9 ने 95% पर एक विपरीत cliff को ठीक किया जहां 94.99 → 95.00 uptime से जाने से 4 अंक खो जाते थे।
if (uptime >= 99.5)   raw = 17 + (uptime - 99.5) * 6
else if (uptime >= 99) raw = 13 + (uptime - 99)   * 8
else if (uptime >= 95) raw = 4 + (uptime - 95) * 2.25    // v3.9: was (u - 95) * 3.25 starting at 0
else                   raw = max(0, uptime - 90) * 0.8   // 90 → 0, 95 → 4 (continuity)
raw = clamp(raw, 0, 20)

reliability = epochsIncluded / epochsObserved   // last ~8 epochs · v4.2: the
                                                // FULL FIP-10 minimums set
                                                // (uptime + FSP + FTSO + FDC),
                                                // not RPC-uptime alone

score = raw * clamp(reliability, 0, 1)                 // dimension max 20
क्यों: v3.4 से पहले, यह आयाम अनिवार्य रूप से मृत था — 92.9% लाइव वेलिडेटर्स के पास 100% RPC अपटाइम है, इसलिए वक्र ने सभी को समान स्कोर किया। विश्वसनीयता अनुपात एक वास्तविक समय-श्रृंखला संकेत है: एक वेलिडेटर जो हाल के 8 epoch में से 3 में FIP-10 न्यूनतम शर्तों को विफल किया है, उसके पास 62.5% विश्वसनीयता स्कोर है, भले ही तत्काल RPC वर्तमान में क्या रिपोर्ट करता है। FIP-10 के 80% प्रोटोकॉल फ्लोर से अधिक सख्त। प्रति-epoch पात्रता डेटा Flare Foundation द्वारा उनके रिवॉर्ड-स्क्रिप्ट्स रिपो में प्रकाशित किया जाता है।
नेट यील्ड18 अधिकतम pts
क्या: नेट-ऑफ-फीस स्टेकिंग-रिवॉर्ड (VRM) दर जो डेलीगेटर प्राप्त करता है, नेटवर्क माध्यिका के लिए लंगर।
कैसे: scoreAPR = मापी गई नेट डेलीगेशन दर (delegationAPY: Σ delegatorRewardAmount / Σ delegated, Flare Foundation रिवॉर्ड-स्क्रिप्ट्स से, पिछले ~8 epoch) जब उपलब्ध हो, अन्यथा सैद्धांतिक baseAPR = सकल × (1 − फीस)। स्कोर = (scoreAPR / medianAPR) लंगर: अनुपात 0.6 → 0 pts, 1.0 (माध्यिका) → 12 pts, 1.2 → 18 pts। महत्वपूर्ण: यह आयाम केवल VRM (सत्यापन-पुरस्कार) दर को स्कोर करता है — MIRROR को MIRROR भागीदारी आयाम में अलग से स्कोर किया जाता है, इसलिए इसे यहां दोहराया नहीं जाता है। प्रदर्शित 'कुल APR' (VRM + MIRROR) एक डेलीगेटर-सामना करने वाली संख्या है, नेट यील्ड इनपुट नहीं।
scoreAPR = delegationAPY > 0 ? delegationAPY : baseAPR   // VRM, net of fee
medianAPR = median(scoreAPR across all validators)
cappedAPR = min(scoreAPR, 25)                  // APY_DISPLAY_CAP

if (medianAPR > 0):
  ratio = cappedAPR / medianAPR
  score = clamp(((ratio - 0.6) / 0.6) * 18, 0, 18)
else:
  score = min(18, (cappedAPR / 8) * 18)        // fallback: BASE_APY = 8
क्यों: अनुपात के दोनों पक्ष नेट डेलीगेशन दर हैं (मापी गई delegationAPY बनाम सैद्धांतिक सकल×(1−फीस)), इसलिए तुलना समान के लिए है — जब इनपुट प्री-फीस सकल दर था तब 1/(1−फीस) द्वारा महंगाई नहीं करी जाती है (लगभग 2× 'दोहरीकरण' बग)। क्योंकि Flare सत्यापन पुरस्कार स्टेक के अनुपात में भुगतान करता है, VRM डेलीगेशन दर पूरे नेटवर्क में लगभग समान है और मुख्य रूप से फीस द्वारा भिन्न होता है — इसलिए यह आयाम ज्यादातर फीस प्रतिस्पर्धा और वितरण विश्वसनीयता को दर्शाता है (एक वेलिडेटर जो epoch को मिस करता है वह कम वितरण करता है)। MIRROR (जो FTSO भागीदारी के आधार पर भिन्न होता है) जानबूझकर दोहरी गिनती से बचने के लिए अपने स्वयं के आयाम में रखा जाता है।
फीस उचितता7 अधिकतम pts
क्या: प्रोटोकॉल शुल्क तल से ऊपर निष्कर्षण के विरुद्ध गेट, सुचारु टुकड़ावार रैखिक।
कैसे: एंकर = max(देखा गया न्यूनतम सक्रिय शुल्क, प्रोटोकॉल वेलिडेटर-शुल्क तल — ग्रेनाइट हार्ड फोर्क के बाद से 20%, 2026-07-14)। एंकर पर या उससे कम कोई भी शुल्क → पूर्ण 7 अंक। इससे ऊपर, अगले 20 शुल्क बिंदुओं (एंकर+5 → 6, एंकर+10 → 4.5, एंकर+15 → 2.5, एंकर+20 → 0) पर क्रमशः तीव्र ढलान वाली रैखिक रैम्प: छोटी अधिकता को मुश्किल से दंडित किया जाता है, निष्कर्षण को कठोरता से दंडित किया जाता है। ग्रेनाइट-पूर्व एंकर एक निरपेक्ष 5% था; तल क्लैम्प का मतलब है कि कोई भी ऑपरेटर कानूनी न्यूनतम की मांग के लिए कभी दंडित नहीं होता है।
// anchor = max(observed minimum active fee, 20% protocol floor)
d = fee - anchor                                  // distance above market best
if (d <= 0)       score = 7                       // at/below best available
else if (d <= 5)  score = 7   - d * 0.2           //  0 → 5 over: 7 → 6
else if (d <= 10) score = 6   - (d - 5)  * 0.3    //  5 → 10 over: 6 → 4.5
else if (d <= 15) score = 4.5 - (d - 10) * 0.4    // 10 → 15 over: 4.5 → 2.5
else if (d <= 20) score = 2.5 - (d - 15) * 0.5    // 15 → 20 over: 2.5 → 0
else              score = 0
// fees > anchor+20 saturate at 0/7 — the v4.5 extreme-fee
// penalty below takes over from there
क्यों: नेट यील्ड पहले से ही वितरित शर्तों में प्रति-प्रतिशत शुल्क को ध्यान में रखता है; यह आयाम केवल वह ऑपरेटरों को चिह्नित करता है जो प्रोटोकॉल और बाजार के अनुमति से काफी अधिक शुल्क लेते हैं। एक बार जब हर शुल्क लागू 20% तल पर बैठ जाता है, तो सभी को यहाँ पूर्ण अंक मिलते हैं और आयाम भेदभाव करना बंद कर देता है — डिज़ाइन के अनुसार: एक ऐसी संख्या जिसे कोई भी कम नहीं कर सकता, किसी को अलग नहीं कर सकता।
ऑपरेटर गुणवत्ता12 अधिकतम pts
क्या: दो स्वतंत्र संकेतों में से अधिकतर लेता है: सत्यापन आधारभूत (पहचान आत्मविश्वास) और FTSO-व्युत्पन्न परिचालन प्रदर्शन।
कैसे: सत्यापन आधारभूत: क्यूरेटेड स्तर (+7) दो तरीकों से पहुंचा — मैनुअल-जांचा गया KNOWN_VALIDATORS प्रविष्टि या उद्देश्य व्यवहार के माध्यम से ऑटो-प्रचार (v3.10: 90+ दिन अवलोकन AND 25+ ऑपरेटर-समेकित डेलीगेटर्स AND वर्तमान में सिकुड़ नहीं रहे AND स्व-बॉन्ड ≥ FIP-10 फ्लोर)। Flaremetrics या FSE से ऑटो-खोजा गया नाम → +3। अनसत्यापित → 0। FTSO-व्युत्पन्न: रैखिक प्रक्षेप FTSO स्कोर 50 → 4 pts FTSO स्कोर 100 तक → 12 pts (50 से नीचे 4 पर तल)। अंतिम स्कोर max(verification, FTSO-derived) है — FTSO भागीदारी केवल मदद कर सकता है, कभी भी नुकसान नहीं।
// Verification baseline (v3.10 hybrid)
isCurated = (in KNOWN_VALIDATORS) OR (
  daysObserved >= 90 AND
  operatorDelegatorCount >= 25 AND
  retention30d >= -15% AND
  selfBondFLR >= 1_000_000
)

if (isCurated)                       verification = 7
else if (name auto-discovered)      verification = 3
else                                verification = 0

// FTSO-derived (only when ftsoOperatorScore is a number)
clamped = clamp(ftsoOperatorScore, 50, 100)
ftsoDerived = 4 + (clamped - 50) * (8/50)   // FTSO 50 → 4, FTSO 100 → 12

// Final score
score = max(verification, ftsoDerived)
क्यों: उन ऑपरेटरों को पुरस्कृत करता है जो एक पूर्ण स्टैक (वैलिडेटर + FTSO + FDC) चलाते हैं, विश्वसनीय ऑपरेटरों को मध्य-स्तर के स्कोर के साथ FTSO में भाग लेने के लिए दंडित किए बिना। v3.8 max() लॉजिक स्पष्ट रूप से 'अपने FlareWatch स्कोर को बेहतर बनाने के लिए FTSO को ड्रॉप करना' के विचित्र प्रोत्साहन को रोकता है। स्वत:-खोजा गया टियर (+3) पिछले 7→0 क्लिफ को बंद करता है जो Flaremetrics या FSE के साथ पंजीकृत ऑपरेटरों को प्रभावित करता था लेकिन अभी तक हाथ से क्यूरेट नहीं किया गया था।
MIRROR भागीदारी12 अधिकतम pts
क्या: क्या वैलिडेटर का nodeID वास्तव में FTSO मुद्रास्फीति शेयर को stakers को देता है — दोनों अंश जो प्रतिनिधियों तक पहुंचता है (शुल्क पास-थ्रू) और, v4.6 के बाद से, क्षेत्र के सापेक्ष दी गई राशि।
कैसे: सक्रिय → 10 × (1 − शुल्क/100)। रोका गया → 5 × पास-थ्रू। निष्क्रिय (कहीं भी कोई भागीदारी संकेत नहीं) → 0। कोई डेटा नहीं (वास्तव में अनदेखे वैलिडेटर) → 5 × पास-थ्रू। v3.6 ने 'सक्रिय' संकेत को on-chain RewardClaimed(claimType=3) इवेंट और विहित FSP Merkle JSON में claimType=3 आवंटन दोनों को शामिल करने के लिए बढ़ाया — कोई भी पर्याप्त है। यह वैलिडेटर को पकड़ता है जिनके MIRROR को आवंटित किया गया है लेकिन अभी तक on-chain पर दावा नहीं किया गया है (जैसे, self-delegating प्रदाता जिनके निपटान पथ मानक दावा इवेंट को ट्रिगर नहीं करते)। v4.6 परिमाण बोनस (अधिकतम +2, आयाम छत 12): केवल mirror-सक्रिय वैलिडेटर के लिए, क्लैंप((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2) — ऊपर-औसत MIRROR दर (शुल्क के बिना) को प्रतिनिधियों को देने के लिए क्रेडिट। नेटवर्क माध्यिका दर में एंकर किया गया है, इसलिए यह आकार-तटस्थ है: एक छोटा वैलिडेटर उच्च दर दिए जाने से बड़े के समान क्रेडिट प्राप्त करता है।
passthrough = max(0, 1 - fee / 100)

if (mirrorStatus == "active")    base = 10 * passthrough
else if (mirrorStatus == "paused")   base = 5 * passthrough
else if (mirrorStatus == "inactive") base = 0
else                                 base = 5 * passthrough  // no data yet

// v4.6 — capped, median-anchored bonus for delivered MIRROR yield.
// Only mirror-active validators paying ABOVE 1.2x the network median
// delivered rate (mirrorAPY, net of fee) earn it; size-neutral.
ratio = mirrorAPY / networkMedianMirrorAPY
bonus = clamp((ratio - 1.2) * 5, 0, 2)   // active only, else 0
score = base + bonus                     // dimension max 12
क्यों: MIRROR स्वचालित रूप से FSP-भाग लेने वाले वैलिडेटर पर stakers को वितरित करता है। एक 100%-शुल्क वैलिडेटर जो 'सक्रिय' है प्रतिनिधियों को $0 देता है; स्कोर प्रोटोकॉल-साइड ध्वज स्थिति के बजाय प्रतिनिधियों को वास्तव में प्राप्त होने वाली राशि को प्रतिबिंबित करता है। v4.6 परिमाण बोनस एक अंधे स्थान को बंद करता है: पास-थ्रू अकेले प्रतिनिधियों तक पहुंचने वाले अंश को मापता था लेकिन राशि नहीं, इसलिए एक वैलिडेटर जो बहुत अधिक दी गई MIRROR दर का भुगतान करता था उसे इसके लिए अतिरिक्त क्रेडिट नहीं मिलता था। अब यह करता है — कैप किया गया, और केवल नेटवर्क माध्यिका से ऊपर।
क्षमता प्रोफाइल7 अधिकतम pts
क्या: सही आकार की उपयोग पर शिखर फ़ंक्शन।
कैसे: 0% उपयोग किया गया → 1.75। 70% उपयोग पर 7 तक रैखिक रैंप अप। 100% पर 5.25 तक रैखिक रैंप डाउन (सीमित)। v3.7 में 8 → 7 से पुनः स्केल किया गया ताकि नया Trust ट्रैजेक्टरी घटकों को वित्त पोषित किया जा सके।
utilization = clamp(1 - freeSpaceFLR / maxDelegationFLR, 0, 1)

if (utilization <= 0.70):
  score = 1.75 + (utilization / 0.70) * 5.25     // 1.75 → 7 ramp
else:
  score = 7 - ((utilization - 0.70) / 0.30) * 1.75 // 7 → 5.25 ramp
क्यों: FIP-10 अधिकतम डेलिगेशन पर होना एक सकारात्मक आकर्षण संकेत है — पर्याप्त डेलिगेटरों द्वारा भरने के लिए साबित विश्वसनीय। v2 ने सीमित वैलिडेटरों को 0/5 दिया; v3 इसे ठीक करता है। सही आकार (साबित आकर्षक और कमरा है) शिखर प्राप्त करता है। v3.7 ने आयाम कैप 8 → 7 को ट्रिम किया ताकि मुक्त बिंदु Trust के नए retention + self-bond ट्रैजेक्टरी घटकों को वित्त पोषित कर सके।
सामुदायिक विश्वास11 अधिकतम pts
क्या: बहु-सिग्नल: प्रतिनिधि गणना + स्टेक-वितरण स्वास्थ्य + दीर्घायु + ऑपरेटर self-bond प्रतिबद्धता (आनुपातिक और निरपेक्ष) + 30-दिन का प्रतिधारण + self-bond प्रक्षेपवक्र + बहु-नोड ऑपरेटर एकत्रीकरण।
कैसे: गणना सिग्नल (अधिकतम 6, OPERATOR-AGGREGATED v3.7): लॉग-स्केल [5, 500] प्रतिनिधि → [0, 6], एक ऑपरेटर के सभी ज्ञात नोड्स में कुल। एकाग्रता समायोजन (±1): खुदरा-अनुकूल औसत स्टेक (<500K FLR) → +1, व्हेल-केंद्रित (>50M FLR औसत) → −1। दीर्घायु बोनस (अधिकतम +1, wipe-immune v3.6): 30 दिन देखे गए पर +0.5, 90+ दिन पर +1 — यदि पहला-देखा गया KV मिटा दिया गया था तो reward-scripts epoch उपस्थिति में वापस जाता है। Self-bond त्वचा-खेल (अधिकतम +2 / न्यूनतम −1, TWO-AXIS v4.7): आनुपातिक हिस्से या निरपेक्ष आकार में से बेहतर द्वारा क्रेडिट किया गया — आनुपातिक ≥10% → +2 / 5–10% → +1, और निरपेक्ष = min(1, selfBond ÷ 20M) × 2 नेटवर्क top-decile बांड पर संतृप्त; सिग्नल दोनों का अधिकतम लेता है, अभी भी +2 पर सीमित। Sub-FIP-10 फर्श (<1M FLR) → −1। प्रतिधारण (अधिकतम ±0.5, नया v3.7): प्रतिनिधि FLR 30 दिन में +10% → +0.5, −15% → −0.5। Self-bond प्रक्षेपवक्र (अधिकतम ±0.5, नया v3.7): ऑपरेटर का self-bond 30 दिन में +20% → +0.5, −10% → −0.5।
// Count signal (max 6)
if (delegatorCount <= 5)        countScore = 0
else if (delegatorCount >= 500) countScore = 6
else  countScore = clamp(log(delegatorCount / 5) / log(100) * 6, 0, 6)

// Concentration adjustment (-1 to +1) — skip if <3 delegators
avgFLR = delegatedFLR / delegatorCount
if (avgFLR < 500_000)        concentrationAdj = +1
else if (avgFLR < 5_000_000)   concentrationAdj = +0.5
else if (avgFLR > 50_000_000)  concentrationAdj = -1
else if (avgFLR > 20_000_000)  concentrationAdj = -0.5
else                           concentrationAdj = 0

// Longevity bonus (0 to +1)
daysObserved = (now - firstObservedAtMs) / 86400000
if (daysObserved >= 90)      longevityBonus = +1
else if (daysObserved >= 30) longevityBonus = +0.5
else                         longevityBonus = 0

// Self-bond alignment (-1 to +2, two-axis since v4.7)
if (selfBondFLR < 1_000_000)   selfBondAdj = -1              // hollow-operator floor
else:
  ratio        = selfBondFLR / totalStake                   // totalStake = selfBond + delegated
  proportional = ratio >= 0.10 ? +2 : ratio >= 0.05 ? +1 : 0
  absolute     = min(1, selfBondFLR / 20_000_000) * 2        // saturates at top-decile bond
  selfBondAdj  = max(proportional, absolute)                 // the better of the two axes

// Retention (-0.5 to +0.5, v3.7) — skip if no 30-day baseline yet
delta = (delegatedFLR - delegatedFLR30dAgo) / delegatedFLR30dAgo
if (delta >= +0.10)      retentionAdj = +0.5
else if (delta <= -0.15) retentionAdj = -0.5
else                     retentionAdj = 0

// Self-bond trajectory (-0.5 to +0.5, v3.7) — skip if no baseline
sbDelta = (selfBondFLR - selfBondFLR30dAgo) / selfBondFLR30dAgo
if (sbDelta >= +0.20)      selfBondTrajectoryAdj = +0.5
else if (sbDelta <= -0.10) selfBondTrajectoryAdj = -0.5
else                       selfBondTrajectoryAdj = 0

score = clamp(countScore + concentrationAdj + longevityBonus + selfBondAdj
            + retentionAdj + selfBondTrajectoryAdj, 0, 11)
क्यों: त्वचा-खेल self-bond एक वास्तविक निष्पक्षता सिग्नल है जो हमें गायब था — एक वेलिडेटर जो कुल स्टेक का 10% self-bond रखता है वह एक ऑपरेटर की तुलना में काफी अधिक संरेखित प्रोत्साहन रखता है जो FIP-10 न्यूनतम पर चल रहा है। v4.7 यह दो-अक्ष बनाता है: self-bond को केवल एक अनुपात के रूप में पढ़ना उन ऑपरेटरों को दंडित करता था जिन्होंने एक बड़ी निरपेक्ष स्टेक डाली और फिर प्रतिनिधिमंडन को आकर्षित किया, जो अनुपात को कमजोर करता है बिना वास्तविक प्रतिबद्धता को कम किए — एक 20M self-bond एक कमजोर अनुपात पर एक sub-2M बांड के समान स्कोर करता था। सिग्नल अब आनुपातिक हिस्से या निरपेक्ष आकार में से बेहतर को क्रेडिट करता है, निरपेक्ष पक्ष एक नेटवर्क के शीर्ष बांड पर संतृप्त होता है ताकि आकार केवल स्कोर नहीं खरीद सके, जैसे FTSO प्रदाता स्कोर पहले से self-bond को व्यवहार करता है; +2 कैप अपरिवर्तित है, तो बड़े प्रतिबद्ध ऑपरेटर अब इसे पहुंच सकते हैं लेकिन छत नहीं हिली। दीर्घायु सिद्ध ट्रैक रिकॉर्ड को पुरस्कृत करता है बिना नए लोगों को दंडित किए (ऊपर एक छोटा बोनस, नीचे दंड नहीं)। एकाग्रता जोखिम प्रतिनिधिकरणकारों के लिए महत्वपूर्ण है — एक वेलिडेटर 1 व्हेल के साथ 50M FLR पर संरचनात्मक रूप से 50 खुदरा at 1M प्रत्येक से अलग है। दो v3.7 प्रक्षेपवक्र सिग्नल कार्बनिक वृद्धि और बढ़ती ऑपरेटर प्रतिबद्धता को पुरस्कृत करते हैं। संयुक्त कैप 11 है (v3.7 में 10 से उठाया गया उन्हें निधि देने के लिए), कोई एकल सिग्नल हावी नहीं है।
डिलीवरी विश्वसनीयता10 अधिकतम pts
क्या: वास्तव में-डिलीवर किए गए नेट डेलिगेशन दर (VRM) का अनुपात सैद्धांतिक बेसलाइन के विरुद्ध, असंगत payouts के लिए variance दंड के साथ। दोनों पक्ष फीस के नेट हैं, इसलिए अनुपात वास्तविक डिलीवरी को मापता है — फीस को नहीं।
कैसे: टुकड़ावार रैखिक डिलीवरी अनुपात: 100%+ → 10, 95% → 8, 90% → 6, 85% → 4, 80% → 2, <80% → 0 की ओर रैखिक रैंप। Variance दंड: भिन्नता का गुणांक × 0.5, −30% पर सीमित। आत्मविश्वास dampener नमूना आकार < 3 epochs होने पर तटस्थ 5 की ओर मिश्रण करता है। v3.9 ने पहले से मौजूद थ्रेशहोल्ड को रैखिकीकृत किया — boundary cliffs अब तक 2 बिंदु की अब चिकने हैं।
// Time-weighted rate is computed upstream from per-epoch
// reward-scripts data with decay = 0.85 per epoch back.
r = deliveryRatio   // capped at 1.0

if (r >= 1.00)      base = 10
else if (r >= 0.97) base = 9  + (r - 0.97) * (1 / 0.03)   // 0.97 → 9, 1.00 → 10
else if (r >= 0.95) base = 8  + (r - 0.95) * (1 / 0.02)   // 0.95 → 8, 0.97 → 9
else if (r >= 0.90) base = 6  + (r - 0.90) * (2 / 0.05)   // 0.90 → 6, 0.95 → 8
else if (r >= 0.85) base = 4  + (r - 0.85) * (2 / 0.05)   // 0.85 → 4, 0.90 → 6
else if (r >= 0.80) base = 2  + (r - 0.80) * (2 / 0.05)   // 0.80 → 2, 0.85 → 4
else                base = max(0, r * 2.5)                 // 0 → 0, 0.80 → 2

// Variance penalty (CoV = std-dev / mean across per-epoch rates)
variancePenalty = min(0.30, coefficientOfVariation * 0.5)
score = base * (1 - variancePenalty)

// Sample-size confidence dampener for < 3 epochs
if (totalStakesCompleted < 3):
  confidence = totalStakesCompleted / 3
  score = 5 + (score - 5) * confidence
क्यों: वादा बनाम वास्तविक डेलीगेटरों के लिए सबसे सीधा जवाबदेही संकेत है। v3.3 ने दो परिशोधन जोड़े: (1) शीर्षक अनुपात एक्सपोनेंशियली time-weighted माध्य का उपयोग करता है (हाल के epochs अधिक गिनते हैं), इसलिए एक वैलिडेटर जो अच्छी तरह से डिलीवर करता था लेकिन हाल ही में गिरा है सही ढंग से दंडित है; (2) variance दंड सुसंगत 95% डेलीवरर्स को oscillating-around-95% से अलग करता है, क्योंकि बाद वाले डेलिगेटरों के लिए अधिक जोखिम वहन करते हैं जो अनुमानित yield की परवाह करते हैं।
बचा समय5 अधिकतम pts
क्या: वैलिडेटर के P-Chain पर स्टेक-एंड तक के दिन।
कैसे: < 14 दिन → 0 (FIP-10 के तहत अनिवार्य रूप से अनुपलब्ध)। 14-30d → रैखिक 0→2। 30-60d → रैखिक 2→3। 60-120d → रैखिक 3→5। 120d+ → 5। v3.9 ने पहले से मौजूद थ्रेशहोल्ड को रैखिकीकृत किया — boundary cliffs (जैसे 13.99d → 0, 14d → 2) अब चिकने हैं।
daysLeft = (endTimeMs - now) / 86_400_000

if (daysLeft < 14)       score = 0
else if (daysLeft < 30)  score = 0 + (daysLeft - 14) * (2 / 16)    // 14 → 0, 30 → 2
else if (daysLeft < 60)  score = 2 + (daysLeft - 30) * (1 / 30)    // 30 → 2, 60 → 3
else if (daysLeft < 120) score = 3 + (daysLeft - 60) * (2 / 60)    // 60 → 3, 120 → 5
else                     score = 5
क्यों: व्यावहारिक संकेत — 7 दिन बचे वैलिडेटर को डेलीगेट करना 1 साल के वैलिडेटर से अलग प्रस्ताव है। v3.2 ने नीचे कड़ा किया: स्टेक-एंड के 14 दिनों के भीतर वैलिडेटर नए डेलिगेशन स्वीकार नहीं कर सकते (FIP-10 न्यूनतम लॉक 14 दिन है), इसलिए वे प्रभावी रूप से unstakeable हैं। स्कोर = 0 'अभी unstakeable' को 'जल्द ही wind down' से अलग करता है।
सक्रिय आउटेज पेनल्टी (v4.3)(कटौती) अधिकतम pts
क्या: सकारात्मक आयामों के शीर्ष पर एक फ्लैट कटौती जब वैलिडेटर लगातार कई reward epochs मिस करता है। सममित Uptime विश्वसनीयता गुणक से अलग — सक्रिय आउटेज को पकड़ता है, पुरानी flakiness को नहीं।
कैसे: cache:fsp-validator-participation रिकॉर्ड में वैलिडेटर के contiguous !eligible प्रीफिक्स को देखें (सार्वजनिक reward-scripts nodes-data.json से newest-first epoch सूची)। 0–1 लगातार misses → 0 pts (variance के भीतर / single transient miss)। 2 लगातार → −3 pts (विकसित आउटेज)। 3 लगातार → −6 pts (sustained — ऑपरेटर inattention)। 4+ लगातार → −10 pts (सक्रिय extended आउटेज)। Composite स्कोर कटौती के बाद 0 पर floored है।
consecutiveMisses = 0
for entry in participation.recent (newest-first):
  if entry.eligible: break
  consecutiveMisses++

if consecutiveMisses < 2:  penalty = 0
elif consecutiveMisses == 2: penalty = 3
elif consecutiveMisses == 3: penalty = 6
else:                        penalty = 10                  // 4+

score = max(0, positiveDimensionsSum - penalty)
क्यों: pre-v4.3 मॉडल पूरी तरह से सममित uptimeReliability गुणक पर निर्भर था — 24 epochs में 5 scattered misses 5 misses in a row के समान खर्च करते हैं। operationally ये बहुत अलग संकेत हैं। Scattered misses डेलिगेटरों को पुरानी flakiness के बारे में बताता है; एक streak उन्हें बताता है कि वैलिडेटर अभी broken है। 2026-05-14 पर Luganodes incident — लगातार कई छूटे epochs जबकि डेलिगेटर सक्रिय रूप से लाखों FLR प्रतिबद्ध कर रहे थे — विशेष मामला है जिसे v4.3 रिलीज़ संबोधित करता है: सक्रिय-आउटेज संकेत को surface करें तेज स्कोर प्रभाव के साथ ताकि डेलिगेटर प्रतिबद्ध करने से पहले in-flight विफलता से बच सकें। Tiered curve single transient misses (सामान्य) के लिए overreacting से बचता है जबकि sustained streaks (दुर्लभ और परिणामी) को तेजी से फ्लैग करता है।
Extreme-Fee Penalty (v4.5)(अधिकतम −75% स्कोर में कमी) अधिकतम pts
क्या: शुल्क आयाम की सीमा से परे शुल्क के लिए आनुपातिक कटौती। शुल्क आयाम 0/7 पर रुक जाता है जब कोई शुल्क एंकर से 20 अंक अधिक हो जाता है — उसके बाद, समग्र पहले शुल्क के प्रति पूरी तरह प्रतिक्रिया करना बंद कर देता है, इसलिए 100%-शुल्क वाला एक सत्यापनकर्ता (इसके प्रतिनिधि कुछ नहीं रखते) अभी भी अपटाइम और MIRROR जैसे शुल्क-अंधे आयामों पर 40 के दशक में स्कोर कर सकता है।
कैसे: 50% या उससे कम के शुल्क पर शून्य — शुल्क आयाम पहले से ही उस सीमा को मूल्य देता है, इसलिए कोई दोहरी गणना नहीं है। 50% से ऊपर कटौती शुल्क के साथ रैखिक रूप से बढ़ती है, 100% शुल्क पर सत्यापनकर्ता के सकारात्मक स्कोर का 75% तक पहुंचती है। यह स्कोर के साथ ही स्केल करता है, इसलिए एक पॉलिश किया हुआ निजी नोड और एक उपेक्षित नोड दोनों जहां उन्हें होना चाहिए वहां पहुंचते हैं: प्रतिनिधि-सामना करने वाली रैंकिंग के निचले भाग में।
// v4.5 — fees beyond the Fee dimension's range (anchor+20)
if fee <= 50:  penalty = 0
else:          fraction = min(1, (fee - 50) / 50) * 0.75
               penalty  = positiveDimensionsSum * fraction

// fee 50% → no change · 75% → −37.5% of score · 100% → −75%
score = max(0, positiveDimensionsSum - outagePenalty - penalty)
क्यों: यह प्रतिनिधियों के लिए एक स्कोर है। एक सत्यापनकर्ता जो अपने प्रतिनिधियों द्वारा अर्जित प्रत्येक पुरस्कार रखता है वह प्रतिनिधि उम्मीदवार नहीं है चाहे इसका अपटाइम कितना भी अच्छा हो — स्कोर को स्पष्ट रूप से ऐसा कहना चाहिए। ऑन-चेन शुल्क का शुद्ध कार्य, प्रत्येक नोड पर समान रूप से लागू, हमारे सहित।
100/100 स्कोर कैसे करें — एक वैलिडेटर playbook
v4.0 का audit cycle विशेष रूप से इसलिए डिज़ाइन किया गया था कि हर आयाम को अधिकतम करना सत्यिक आपको अपने डेलिगेटरों के लिए एक बेहतर वैलिडेटर बनाता है। अपने स्कोर में सुधार सिस्टम को गेम करना नहीं है — यह सिस्टम को काम करने के लिए डिज़ाइन किया जा रहा है। यहां प्रत्येक आयाम के लिए स्पष्ट playbook है।
Uptime — 20 pts। निरंतर ≥99.5% RPC uptime बनाए रखें और हर reward epoch में FIP-10 न्यूनतम शर्तों को पास करें (reveals को miss न करें, median delivery को hit करें)। दो संकेत गुणा किए जाते हैं — 100% RPC × 7/8 epochs eligible = 17.5/20, 20 नहीं। डेलिगेटरों के साथ यह क्यों संरेखित है: हर बार जब आप FIP-10 को fail करते हैं, आपके डेलिगेटरों को उस epoch के लिए अपने rewards खो देते हैं।
नेट यील्ड — 18 पीटीएस। अपने डेलीगेटर्स को ≥1.2× नेटवर्क मीडियन APY (पोस्ट-फीस) प्रदान करें। सर्वश्रेष्ठ पथ: कम फीस + पूर्ण FIP-10 योग्यता ताकि डेलीगेटर्स अपना पूर्ण शेयर प्राप्त करें। यह क्यों संरेखित होता है: यह वह डॉलर राशि है जो आपके कट के बाद डेलीगेटर तक पहुँचती है।
शुल्क तर्कसंगतता — 7 अंक। ग्रेनाइट हार्ड फोर्क के बाद से प्रोटोकॉल एक 20% न्यूनतम प्रतिनिधिमंडन शुल्क लागू करता है, और स्कोरिंग एंकर पर या उससे नीचे कोई भी शुल्क (देखे गए बाजार न्यूनतम और उस तल का अधिकतम) पूर्ण 7 अर्जित करता है। इससे ऊपर की मांग त्वरणशील रैम्प पर अंक लागत करती है — एंकर+10 → 4.5 अंक, एंकर+20 → 0। यह क्यों संरेखित है: तल ने शुल्क प्रतिस्पर्धा को समाप्त कर दिया, इसलिए यह आयाम अब केवल प्रतिनिधियों को कानूनी न्यूनतम से ऊपर निष्कर्षण से बचाता है; आपकी वास्तविक बढ़त वितरित नेट यील्ड में रहती है।
Operator Quality — 12 pts। सर्वश्रेष्ठ path: एक FTSO डेटा प्रदाता के रूप में पंजीकृत करें और एक शीर्ष-गुणवत्ता स्टैक चलाएं (FTSO + FDC + signing) — आपका FlareWatch Operator Quality स्कोर तब आपके FTSO स्कोर से आता है, अधिकतम FTSO 100 पर। वैकल्पिक यदि आप staking-only हैं: +7 verification baseline बनाए रखें या तो v3.10 auto-promotion के लिए qualifying करके (90+ दिन देखे, 25+ delegators, retention declining नहीं, FIP-10-compliant self-bond) या KNOWN_VALIDATORS में जोड़े जाने से संस्थागत बुनियादी ढांचे के रूप में (manual fast-track)। स्कोर max(verification, FTSO-derived) लेता है — भागीदारी कभी नुकसान नहीं कर सकती। ecosystem value प्रदान करते हैं; verification baseline डेलिगेटरों को स्पष्टता पहचान संकेत देता है।
MIRROR Participation — 10 pts। लगातार FSP मूल्य feeds submit करें, per-epoch protocol minimums को पूरा करें (आपकी signing policy में पंजीकृत, claim threshold पूरी, कोई reveal misses नहीं)। एक moderate fee charge करें — स्कोर (1 − फीस/100) से गुणा किया जाता है, इसलिए यहां तक कि एक बिल्कुल MIRROR-active 100%-fee वैलिडेटर 0 स्कोर करता है क्योंकि zero MIRROR डेलिगेटरों को पहुंचता है। डेलिगेटरों के साथ यह क्यों संरेखित है: MIRROR आपके डेलिगेटरों का FTSO मुद्रास्फीति शेयर है। कम fee = अधिक उन्हें पहुंचता है।
Capacity Profile — 7 pts। ~70% utilization को target करें (सही आकार: साबित आकर्षक और नए डेलिगेटरों के लिए कमरा है)। खाली वैलिडेटर 1.75 स्कोर करते हैं; capped वैलिडेटर 5.25 स्कोर करते हैं। नए डेलिगेटर स्कोर पढ़ते हुए जानना चाहते हैं कि वे वास्तव में डेलीगेट कर सकते हैं या नहीं; सही आकार सामाजिक proof और availability दोनों को संकेत करता है।
Community Trust — 11 pts। Max करने के लिए छः घटक:
  • 500+ operator-aggregated delegators में बिल्ड करें (अधिकतम count संकेत: +6 pts)।
  • खुदरा-अनुकूल औसत stake < 500K FLR प्रति डेलिगेटर बनाए रखें (concentration बोनस: +1)।
  • network पर ≥ 90 दिनों तक रहें longevity बोनस के लिए (+1) — reward-scripts उपस्थिति द्वारा wipe-immune।
  • एक बड़ी self-bond रखें — या तो ≥ 10% आनुपातिक रूप से या एक नेटवर्क शीर्ष पर निरपेक्ष स्टेक (~20M FLR), जो भी बेहतर स्कोर करता है (संरेखण बोनस: +2)।
  • 30 दिनों में कुल डेलीगेटेड FLR को ≥ 10% बढ़ाएं (retention: +0.5)।
  • 30 दिनों में self-bond को ≥ 20% बढ़ाएं (trajectory: +0.5)।
यह क्यों संरेखित है: प्रत्येक घटक एक व्यवहार को पुरस्कृत करता है जो delegators चाहते हैं — operator skin-in-the-game, organic growth, longevity, broad community participation। Multi-node operators को count + concentration signals के लिए aggregated किया जाता है (v3.7)।
Delivery Reliability — 10 pts. अपने delegators को वह पुरस्कृत करें जो आपका estimated APY promise करता है (delivery ratio 1.00)। Per-epoch variance को minimize करें — predictable payouts same mean के साथ high spread को beat करते हैं (variance penalty up to −30%)। Full confidence weighting के लिए 8+ epochs का sample size बनाएं। यह क्यों संरेखित है: क्या आप उस promise को deliver कर रहे हैं जो आपने किया था, consistently? यह सबसे सीधा accountability signal है।
Time Remaining — 5 pts. अपनी stake-end date को ≥ 120 दिनों दूर रखें। Expiration से well पहले renew करें; इसे < 14-day band में slide न होने दें (एक बार आप 14 दिनों के अंदर हों तो आप FIP-10 के अंतर्गत नए delegations स्वीकार नहीं कर सकते)। यह क्यों संरेखित है: longer commitment delegators को signal करती है कि आप long haul के लिए यहां हैं।
Time-gated signals जिन्हें आप shortcut नहीं कर सकते: longevity bonus (90 days observed), auto-curation tier (90 days + 25 delegators + non-declining retention + FIP-10 self-bond), retention signal (30 days of delegation history), delivery sample size (8 reward epochs)। अच्छी बात: OTHER behaviors को maintain करना automatically इन्हें समय के साथ accrue करता है।
Smoothing window short term में matters करता है: displayed score last 4 cron snapshots का exponentially-weighted average है (0.5 / 0.3 / 0.15 / 0.05), इसलिए inputs पर perfect 100 भी ~20 minutes की consecutive perfect cron runs लगते हैं fully reflect करने के लिए। Steady-state perfect inputs = 100; transient improvements smoothed होते हैं। Sudden-change penalties (fee jumps, self-bond drops, uptime crashes) detection के बाद कुछ cron cycles के लिए 10 pts तक dock कर सकते हैं।
संक्षेप में: हर dimension इस बारे में honest है कि वह क्या measure करता है। अगर आपका validator 100/100 पर है, तो score भी अपने delegators को बता रहा है कि वे network पर validator का सर्वश्रेष्ठ संस्करण प्राप्त कर रहे हैं — यह design intent है।
अपने स्कोर को कैसे verify करें
Validators table पर हर score public data से reproducible है। अगर आप एक operator हैं और यहां math आपके देखे हुए score से match नहीं करता है, तो सही move यह assume करने से पहले इसे स्वयं verify करना है कि हमने गलती की है।
सबसे तेजी वाली check automatically चलती है। किसी भी validator के score row को expand करें और "Verified in your browser" panel उस score को locally recompute करता है — exact same scoring function जो cron uses, exact same inputs पर जिसे उसने use किया, हमारे server को वापस call किए बिना। क्योंकि हर validator को one identical function द्वारा score किया जाता है जिसका node identity के लिए कोई term नहीं है, यह भी है कि कोई भी कैसे confirm कर सकता है कि हमारा अपना node कोई hidden advantage नहीं कमाता है। नीचे दिया गया manual walkthrough यही चीज hand से करता है:
  1. अपने validator के public stats को lookup करें flaremetrics.io पर (अपने operator name से search करें या अपना delegation address paste करें)। अपना delegationFee, selfBond, delegatedStake, और FTSO score (अगर आप एक data provider भी हैं) note करें।
  2. Verify करें अपनी FIP-10 eligibility last 8 reward epochs के लिए github.com/flare-foundation/reward-scripts पर generated-files/reward-epoch-N/nodes-data.json के अंतर्गत। Count करें कितने epochs आपके nodeID का uptimeEligible: true था। यह ratio आपके Uptime dimension multiplier को drive करता है।
  3. अपनी MIRROR participation check करें V2 RewardManager contract पर via flare-explorer.flare.network। RewardClaimed events के लिए claimType=3 के साथ अपने nodeID को reference करते हुए देखें। अगर कोई recent नहीं हैं, तो आप MIRROR-inactive दिखेंगे।
  4. अपने inputs को ऊपर दिए गए formulas में plug करें। प्रत्येक dimension का code block आपको बिल्कुल बताता है कि कौन सी arithmetic चलानी है। Dimensions को sum करें, 100 को clamp करें, और आपके पास अपना raw cron-computed score है।
  5. अपने displayed score से compare करें। Displayed score में v3.5 का exponential moving average है last 4 cron snapshots के across (current weighted 0.5, prev 0.3, आदि) — इसलिए एक single run का computed score displayed one से slightly different होगा। हर validator row पर score-breakdown panel persisted dimension values दिखाता है जिसने contributed किया।
  6. अगर math add नहीं होता है, email करें [email protected] को अपना nodeID, जो inputs आपने use किए, और score जो आपने computed किया। हम respond करेंगे, और अगर हमने गलती की तो हम इसे publicly fix करेंगे।
Programmatic access: किसी भी active validator के लिए, GET /api/validators/{nodeID}/score-breakdown को hit करें persisted breakdown retrieve करने के लिए — हर dimension की value, algorithm version जिसने इसे produced किया, और recent score history — JSON के रूप में। UI में score-breakdown panel यही same source से read करता है।
आम operator concerns
मैं 100% RPC uptime पर हूं — मेरा Uptime score 20/20 से नीचे क्यों है?
Uptime dimension RPC-curve आउटपुट को आपके epoch-eligibility अनुपात (पिछले 8 पुरस्कार epochs में epochsIncluded / epochsObserved — v4.2 के बाद से पूर्ण FIP-10 न्यूनतम सेट, केवल RPC-uptime नहीं) से गुणा करता है। यदि आप उन epochs में से किसी में भी FIP-10 न्यूनतम शर्तें विफल रहे — भले ही संक्षिप्त रूप से — आपका reliability अनुपात 1.0 से नीचे गिरता है और आपका Uptime score आनुपातिक रूप से स्केल होता है। v3.4 से पहले यह dimension हर validator को 100% RPC uptime के लिए 20 स्कोर करता था चाहे ऐतिहासिक eligibility कुछ भी हो। अब यह differentiate करता है।
मैं MIRROR deliver करता हूं — FlareWatch मुझे MIRROR-inactive क्यों दिखाता है?
v3.6 के रूप में, MIRROR participation को TWO canonical sources से detect किया जाता है: on-chain RewardClaimed(claimType=3) events V2 RewardManager पर, AND claimType=3 allocations official FSP Merkle JSON में (published reward distribution data)। कोई भी nodeID जो either source में दिखता है active counts करता है। Pre-v3.6 हमने on-chain stream को sole signal के रूप में use किया, जिसने self-delegating providers के लिए false negatives produced किए जिनका MIRROR non-standard claim path के through settle होता है। v3.6 में भी fixed: एक key-format bug जहां ~95 validators के mirror-stats entries hex20 के अंतर्गत लिखे गए थे (bytes20 form of the nodeID) on-chain indexer द्वारा जब वे अभी तक हमारे curated name list में नहीं थे — जब हर UI lookup cb58 NodeID द्वारा keyed था। यह entries मौजूद थे और सही थे; वह display layer के लिए visible नहीं थे। Lookup अब हर consumer के across दोनों formats को normalize करता है (validators table, score-breakdown panel, public mirror-stats API, Yield page Staking Positions card, FTSO providers panel)। अगर आपका nodeID v3.6 sweep के बाद भी inactive दिखा रहा है, possible causes: (a) आपका nodeID actually enrolled नहीं है आपके FSP signing policy में उस epoch के लिए, (b) हम epoch publications के बीच हैं (Merkle data updates per epoch, ~3.5 days)। अपना nodeID के साथ email करें और हम दोनों canonical sources को cross-check करेंगे।
मेरा score रातोंरात 10 points drop किया — क्या बदला?
तीन चीजों में से एक: (1) v3.5 sudden-change detection ने आपके nodeID पर fee jump, self-bond drop, या uptime crash को flag किया — एक 10-pt penalty उस run को apply करता है जब हम इसे detect करते हैं और next 3 runs के over decays करते हैं जैसे नया state stabilize होता है; (2) smoothing window ने एक older snapshot को incorporate किया जिसने आपकी average को down किया; (3) हमने एक algorithm version bump ship किया (आपके record के algorithmVersion field में visible — नीचे Versions card देखें)। Score-breakdown panel current dimension values दिखाता है; अपने prior runs के against compare करें।
एक high-fee validator एक low-fee वाले के साथ lower score क्यों करता है similar everything else के साथ?
नेट यील्ड आयाम (18 पीटीएस अधिकतम) फीस-संवेदनशील है — एक 0% फीस वेलिडेटर ~1.25× नेटवर्क मीडियन APY प्रदान करता है, अधिकतम के पास स्कोर करता है; एक 20% फीस वेलिडेटर मीडियन का ~80% प्रदान करता है, कम स्कोर करता है। साथ ही फीस रीजनेबलनेस (7 पीटीएस) v3.9 के बाद से पिस-वार रैखिक है (कोई बाल्टी नहीं): ≤5% पूर्ण 7 पाता है, फिर वक्र कठोर ढलान के साथ नीचे जाता है — 10% → 6, 15% → 4.5, 20% → 2.5, 25%+ → 0 (तो उदा. 16% फीस ~4.1 स्कोर करता है, फ्लैट बाल्टी मान नहीं)। तो 5-पीटी फीस अंतर ~5-8 पीटीएस स्कोर अंतर में अनुवाद करता है। यह जानबूझकर है — डेलीगेटर्स सीधे फीस की परवाह करते हैं।
मैं brand-new validator हूं कोई FTSO score नहीं है। मेरा Operator Quality केवल 7/12 क्यों है?
Operator Quality (12 pts max) full-stack operators को reward करता है — validators जो एक top FTSO data-provider stack भी run करते हैं (FTSO + FDC + signing)। अगर आप staking-only हैं, तो +7 baseline दो तरीकों से reachable है: (1) हमारे KNOWN_VALIDATORS list में manual inclusion — institutional fast-track trusted infrastructure operators के लिए (Ankr, InfStones, Kiln, आदि); (2) v3.10 auto-promotion objective behavior के आधार पर — 90+ days observed AND 25+ operator-aggregated delegators AND retention not declining AND FIP-10-compliant self-bond। Auto-promotion fully automatic है, कोई email नहीं needed। अगर आप अभी auto-criteria को meet नहीं करते हैं तो आप +3 पर start करते हैं (auto-discovered tier, requires a Flaremetrics or FSE entity profile) और grow करते हैं +7 में जैसे आपका track record builds करता है। Accelerate करने के लिए: एक FTSO data provider के रूप में register करें और V2 protocols run करें — आपका score तब FTSO-derived branch से comes करता है max of 12 के साथ FTSO 100 पर। v3.8: FTSO participation केवल help कर सकता है, कभी hurt नहीं — अगर आपका FTSO score verification baseline से नीचे है, तो आप baseline को keep करते हैं।
मेरे पास एक logo है लेकिन मेरा name truncated NodeID के रूप में दिखता है। क्यों?
आपका operator entity Flaremetrics में मौजूद है (जो कि हमारे पास आपके लिए logo है) लेकिन आपका provider profile 'name' field set नहीं रखता है। हम names fabricate नहीं करते। अपना profile.name Flaremetrics पर या Flare Systems Explorer entity registry में set करें, और हम इसे next cron run पर pick करेंगे। Alternatively, हमें एक verifiable claim email करें (e.g., आपके delegation address से एक signed message) और हम आपको KNOWN_VALIDATORS में hand से add करेंगे।
मेरा validator FIP-10 max delegations पर है। Capacity score 7/7 क्यों नहीं करता है?
Capacity एक tent function है जो 70% utilization पर peak करता है (7 pts), 100% पर 5.25 pts तक ramp down करता है। Peak 100% नहीं है — at-cap होने का मतलब है कि delegators और भी stake add नहीं कर सकते भले ही वे चाहते हों, जो new delegators के लिए table read करने के लिए neutral-to-mildly-negative signal है। Pre-v3 हमने capped validators को 0/5 score किया (penalty for success); v3 ने इसे neutral at-cap value में correct किया, और v3.7 ने पूरे dimension को 8 → 7 max से rescale किया (Trust trajectory signals के लिए point free करते हुए), इसलिए आज capped 5.25/7 score करता है। Right-sized validators (proven attractive AND room to grow के साथ, 70% utilized पर peak) को full 7 मिलते हैं।
मैं real operator हूं लेकिन मैं validator list में बिल्कुल नहीं हूं। क्या बात है?
Validator list live P-Chain RPC के getCurrentValidators result से built है। अगर आप नहीं हैं वहां, तो आप या तो currently P-Chain पर active नहीं हैं, आपका stake अभी expire हुआ है, या हमारी ओर से P-Chain RPC issue है। Cron हर 5 मिनट चलता है — आपको 1-2 cycles के within अपने stake को activate करने के बाद appear होना चाहिए। अगर आप एक घंटे के लिए live रहे हैं और फिर भी अपने आप को नहीं देखते हैं, तो अपना nodeID के साथ email करें।
क्या मैं अपने score को appeal कर सकता हूं या manual review के लिए request कर सकता हूं?
हां। [email protected] को अपना nodeID और specific concern के साथ email करें। हम हर operator को respond करते हैं। चीजें जिन पर हम act करेंगे: KNOWN_VALIDATORS additions, MIRROR-classification corrections, logo/name fixes, dimension-specific math errors। चीजें जिन पर हम act नहीं करेंगे: algorithm के बाहर score को manually raise करने के लिए requests, competitor को exclude या de-rank करने के लिए requests।
हम क्या करेंगे और क्या नहीं करेंगे
Score को कैसे operate करते हैं इस बारे में ambiguity को remove करने के लिए, यहां explicit commitments हैं। अगर हम कभी इन में से एक को violate करते हैं, document करें और [email protected] को email करें — हम publicly correct करेंगे।
✓
हम higher scores, sponsored placement, या किसी भी प्रकार के favorable treatment के लिए payment accept नहीं करेंगे। Score deterministically public chain data से computed है।
✓
हम per-validator bumps को hand-code नहीं करेंगे। Code में कहीं "X को +5 मिलते हैं क्योंकि हमें वह पसंद है" line नहीं है। Same algorithm हर validator को apply होता है including FlareWatch के अपने node को, जो exactly इस function द्वारा scored है।
✓
हम सार्वजनिक कारणों के बिना validators को तालिका से बाहर नहीं करेंगे। सूची लाइव P-Chain RPC से प्राप्त है और हमारी प्रदर्शनी प्रत्येक सक्रिय validator को शामिल करती है। KNOWN_VALIDATORS में curated जोड़ केवल display names भरते हैं — वे दृश्यमानता को प्रतिबंधित नहीं करते।
✓
हम algorithm परिवर्तन प्रकाशित करेंगे। प्रत्येक version bump (v3 → v3.1 → v3.2 → ...) इस पृष्ठ पर Versions कार्ड में documented है जिसमें rationale और क्या बदला गया है। Major changes को app के changelog पृष्ठ से दिखाई देने वाली अतिरिक्त changelog entry मिलती है।
✓
हम operator emails का जवाब देंगे। प्रत्येक operator जो [email protected] को अपने score के बारे में कोई substantive concern भेजता है, उसे कुछ व्यावसायिक दिनों में असली जवाब मिलता है।
✓
हम अपनी गलतियों को सार्वजनिक रूप से ठीक करेंगे। यदि हम algorithm में कोई bug, data-source error, या methodology gap खोजते हैं, तो हम एक fix ship करते हैं और इसे document करते हैं। हम चुप-चाप re-rank नहीं करते।
✗
हम नहीं करेंगे email contents को सार्वजनिक रूप से साझा करना sender की अनुमति के बिना, या operator emails का उपयोग score conversation के अलावा किसी और के लिए करना।
✗
हम नहीं करेंगे algorithm change के लिए अपनी future plans को select operators के साथ advance में साझा करना — हर version एक साथ सभी के लिए live जाता है।
सीमाएँ — यह स्कोर क्या है, और क्या नहीं है
एक समग्र स्कोर एक उपयोगी सारांश है, एक वस्तुनिष्ठ सत्य नहीं। हमारा पारदर्शी है, संस्करण नियंत्रित है, प्रत्येक सत्यापनकर्ता पर समान रूप से लागू किया जाता है — हमारे स्वयं के सहित — और आपके ब्राउज़र में प्रकाशित इनपुट से पुनः प्राप्त किया जा सकता है। लेकिन यह अभी भी संपादकीय निर्णय को एन्कोड करता है, और हम आपको यह दिखाना पसंद करेंगे कि वह बिल्कुल कहाँ है, बजाय ऐसी सटीकता का संकेत देने के जो विधि के पास नहीं है।
आयाम भार हमारा निर्णय हैं। अपटाइम 20 अंक के लायक है और शुल्क 7 के लायक है क्योंकि हमने तय किया कि अधिकांश प्रतिनिधिकर्ताओं के लिए विश्वसनीयता कुछ अंकों की शुल्क से अधिक महत्वपूर्ण है — न कि क्योंकि किसी सूत्र ने इसे साबित किया। समझदारी वाले लोग इन्हें अलग तरीके से भार देंगे। भार निश्चित और सार्वजनिक हैं, इसलिए आप देख सकते हैं कि हमने बिल्कुल क्या चुना और विभाजन से उन्हें मानसिक रूप से पुनः भार दे सकते हैं।
शुद्ध यील्ड एक परिणाम है, एक गुण नहीं। यह मापता है कि एक प्रतिनिधिकर्ता वास्तव में क्या अर्जित करता है, नेटवर्क माध्यिका को लंगर किया जाता है — इसलिए यह आंशिक रूप से उन चीजों द्वारा आकार दिया जाता है जो किसी ऑपरेटर के नियंत्रण से बाहर हैं (नेटवर्क मुद्रास्फीति, उन्हें कितना प्रतिनिधिमंडन आकर्षित हुआ है) और यह जब बाकी क्षेत्र चलता है तो यह चलता है। एक अनुशासित ऑपरेटर जो एक उचित लेकिन उच्चतर शुल्क लगाता है, यहाँ कम स्कोर कर सकता है जबकि उत्कृष्ट हो। इसे "मैं क्या अर्जित करूँगा" के रूप में पढ़ें, "यह ऑपरेटर कितना अच्छा है" नहीं।
FTSO-से जुड़े आयाम पूर्ण-स्टैक ऑपरेटरों का पक्ष लेते हैं। MIRROR प्रतिभागिता और ऑपरेटर गुणवत्ता के एक हिस्से उन सत्यापनकर्ताओं को पुरस्कृत करते हैं जो एक शीर्ष FTSO डेटा-प्रदाता स्टैक भी चलाते हैं। यह जानबूझकर है — एक प्रतिनिधिकर्ता के रूप में आप एक FTSO-सक्रिय सत्यापनकर्ता से MIRROR के माध्यम से वास्तव में अधिक अर्जित करते हैं — लेकिन इसका मतलब है कि एक शुद्ध, उत्कृष्ट केवल-स्टेकिंग सत्यापनकर्ता इस बोर्ड के बहुत शीर्ष तक नहीं पहुंच सकता है। यदि आप विकल्प द्वारा केवल-स्टेकिंग करते हैं, तो अपने लिए उन आयामों को कम भार दें।
मॉडल योगात्मक है। आयाम जोड़ते हैं, इसलिए एक शक्ति एक कमजोरी को ऑफसेट कर सकती है — शानदार अपटाइम एक उच्च शुल्क को सम्मानजनक स्कोर तक ले जा सकता है। वास्तव में अयोग्य विफलताएँ (FIP-10 न्यूनतम विफल होना, शिकारी शुल्क) अलग से गेट किए जाते हैं ताकि उन्हें पूरी तरह से छिपाया न जा सके — एक सत्यापनकर्ता हर युग में न्यूनतम विफल होना या 100% शुल्क लगाना इसके अन्य आयामों की परवाह किए बिना नीचे की ओर उतरता है — लेकिन मुख्य एक भारित योग है, एक निषेधाज्ञा प्रणाली नहीं।
एक संख्या नौ निर्णयों को छिपाती है। एकल 0-100 आंकड़ा एक प्रारंभिक बिंदु है, एक निर्णय नहीं। दो सत्यापनकर्ता एक अंक अलग नहीं हैं। विभाजन खोलें और उन आयामों को भार दें जो आपके लिए महत्वपूर्ण हैं — संख्या उस तुलना को तेज़ बनाने के लिए मौजूद है, उसे प्रतिस्थापित करने के लिए नहीं।
हम विधि को कम ही बदलते हैं, और सार्वजनिक रूप से। प्रत्येक परिवर्तन एक संस्करण बम्प, एक लिखित कारण, और एक क्षेत्र-व्यापी पहले-और-बाद के साथ भेजा जाता है, इसलिए आप ऑडिट कर सकते हैं कि क्या चला गया और क्यों। जब हमारा स्वयं का स्वचालित ऑडिट हमारी संख्याओं में एक विसंगति को पकड़ता है — जैसा कि यह करता है — हम इसे ठीक करते हैं और ऐसा कहते हैं।
Final score (dimensions कैसे combine होते हैं)
सभी 9 dimensions सीधे जोड़ते हैं, फिर v4.3 active-outage streak deduction घटाया जाता है। Total 100 पर cap होता है और 0 पर floor होता है। Recent cron snapshots (v3.5) में smoothing और कोई भी sudden-change penalty फिर final number पर लागू होते हैं।
// Step 1 — Raw composite (sum of dimensions, minus the two penalties)
positive = uptime + netYield + fee + operatorQuality
         + mirror + capacity + trust + delivery + timeRemaining

// Penalties (see the two penalty cards above):
// v4.3 active-outage streak — 0-1 missed epochs → 0, 2 → 3, 3 → 6, 4+ → 10
// v4.5 extreme fee (>50%)   — positive × min(1, (fee - 50) / 50) × 0.75
raw = clamp(positive - streakPenalty - extremeFeePenalty, 0, 100)

// Step 2 — Smooth across recent cron snapshots (v3.5)
// Weights: current 0.5, prev1 0.3, prev2 0.15, prev3 0.05
smoothed = 0.5*raw + 0.3*prev1 + 0.15*prev2 + 0.05*prev3

// Step 3 — Apply sudden-change penalty if flagged this run
// Triggers: fee +50% or +5pt jump, self-bond -20% drop, uptime -5% crash
// Magnitude: -10 pts on detection, decays -7, -4, -1 over 3 runs
suddenPenalty = -10 if any flag triggered else (decaying remainder)

// Step 4 — Final score
score = clamp(smoothed + suddenPenalty, 0, 100)
Data sources (हर input public है)
Flare P-Chain RPC: validator list, uptime, self-bond, delegated stake, fee, end time, delegator count।
V2 RewardManager (claimType=3 events): on-chain claimed MIRROR distribution प्रति validator nodeID। Type 3 पर strictly filtered — VRM, FTSO delegation, या DIRECT rewards के साथ कोई conflation नहीं।
FSP Merkle JSON (claimType=3 allocations): canonical published record कि प्रति epoch MIRROR किसे दिया जाता है (वही data जो Flare का अपना signing tool पढ़ता है)। v3.6 में दूसरे authoritative source के रूप में जोड़ा गया — उन validators को पकड़ता है जिनका MIRROR allocated है लेकिन अभी on-chain claim नहीं हुआ।
Flare Systems Explorer (FSE): validator entity registry, display names, logos, FTSO V2 protocol participation flags।
Flaremetrics provider data: FTSO score, reward rate, accuracy, V2 features, entity-to-nodeID linkage।
Flare reward-scripts (GitHub): सबसे हाल के N reward epochs के लिए per-validator delivered APY। Delivery dimension को drive करता है।
FlareWatch curation: KNOWN_VALIDATORS map (~110 entries)। Trusted infrastructure operators के लिए Names + Operator Quality baseline।
Score में क्या नहीं है
• Self-promotion या paid placement। कोई भी operator higher score के लिए pay या sponsor नहीं कर सकता।
• Hand-coded validator-specific bumps। Code में कहीं "X को +5 मिलता है क्योंकि हमें पसंद है" lines नहीं है। FlareWatch के अपने node सहित हर validator के लिए same algorithm लागू होता है, जिसे इस exact function द्वारा scored किया जाता है।
• Subjective infrastructure quality। हम uptime SLAs, geographic distribution, या hardware specs को evaluate करने का प्रयास नहीं करते। यदि आप infrastructure-grade claim करना चाहते हैं, तो एक top FTSO + FDC stack चलाएं और Operator Quality dimension इसे reflect करेगा।
• Lockups या FlareWatch के लिए commitments। FlareWatch बनाम दूसरे tool का उपयोग करने वाले stakers के लिए कोई favorable scoring नहीं।
Operator feedback
अपने validator के score में कुछ गलत दिख रहा है? [email protected] को अपना NodeID और concern के साथ email करें। हम हर operator को respond करते हैं। Common requests जिन पर हम action लेंगे:
  • अपने operator को KNOWN_VALIDATORS में जोड़ना (verification के साथ)।
  • अपने MIRROR-inactive classification की समीक्षा करना यदि आप मानते हैं कि यह error में है।
  • Logo / display-name corrections।
  • General algorithm critique।
Sources & references
Score के लिए हर input public, verifiable Flare-ecosystem sources से आता है। कोई भी अपने claims को इन primary sources के विरुद्ध cross-check कर सकता है और raw data से math को reproduce कर सकता है। यदि आप इस पृष्ठ और upstream sources के बीच कोई discrepancy देखते हैं, तो [email protected] को email करें और हम इसे ठीक करेंगे।
Authoritative protocol docs। FTSO V2, FSP, P-Chain validation, FAssets, और Flare stack के बाकी हिस्सों को covers करता है।
Flare governance portal (FIPs) ↗https://proposals.flare.network
Flare Improvement Proposals — FIP-05 (delegation factor), FIP-10 (validator minimum conditions: 1M FLR self-bond floor, 80% uptime floor, 14-day minimum lock), और इस पृष्ठ पर cited सभी other rules के लिए source of truth।
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
FTSO data providers, entity addresses, P-Chain nodeID linkages, और FIP-10 minimum-conditions flags का official Flare-operated registry। Operator Quality और reliability data के लिए primary source।
Flaremetrics ↗https://flaremetrics.io
Independent Flare-ecosystem metrics provider। FTSO provider scoring, reward rates, accuracy metrics, V2 protocol participation flags, और validator-to-entity address mappings का source। हम उनके public REST API को consume करते हैं।
Flare Foundation reward-scripts repo ↗https://github.com/flare-foundation/reward-scripts
Flare Foundation द्वारा published per-reward-epoch JSON जो per-validator eligibility, uptime-eligibility, और delivered rewards दिखाता है। Delivery Reliability dimension और v3.4 epoch-eligibility ratio को Uptime के लिए drive करता है।
Flare Block Explorer ↗https://flare-explorer.flare.network
सभी ऑन-चेन स्टेट का केवल-पढ़ने वाला ब्राउज़र। किसी को भी V2 RewardManager के RewardClaimed इवेंट्स (claimType=3 for MIRROR), validator stake totals, fee changes, और बाकी सब कुछ सत्यापित करने देता है।
Flare Portal (staking) ↗https://portal.flare.network/staking
आधिकारिक staking interface। वर्तमान self-bond / delegated stake amounts और validator end-times के लिए authoritative source जो P-Chain RPC reads को feed करते हैं जिनका हम उपयोग करते हैं।
Flaremetrics public API (FTSO providers) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
वह सटीक endpoint जिसे हमारा cron consume करता है, entity profiles, FTSO scores, fees, और hex format में nodeIds return करता है। कोई भी इसे सीधे hit कर सकता है।
Flaremetrics public API (node registrations) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
Hex → cb58 NodeID conversion table। हम इसे paginate करते हैं entity-to-NodeID lookup बनाने के लिए जो हर cb58-format consumer को drive करता है।
कोई निजी डेटा नहीं, कोई बंद-स्रोत मॉडल नहीं। स्कोरिंग एल्गोरिदम FlareWatch codebase में services/validators/scoring.ts में implemented है। Operators या researchers जो implementation को सीधे inspect करना चाहते हैं (ऊपर दिए गए prose + formulas को पढ़ने के बजाय) — या अपने स्वयं के उपयोग के लिए इसे fork करना चाहते हैं — access के लिए request करने के लिए [email protected] को email कर सकते हैं। यदि वास्तविक मांग है तो हम फ़ाइल को एक standalone open-source package के रूप में प्रकाशित करेंगे।
स्कोर कैसे update होते हैं
/api/cron/refresh-validators पर cron हर सक्रिय validator के स्कोर को हर 5 मिनट में recompute करता है। Inputs (P-Chain RPC reads, Flaremetrics, FSE, reward-scripts) हर run पर fresh fetch किए जाते हैं।
v3.5 ने last 4 cron snapshots के पार smoothing (weights: 0.5 / 0.3 / 0.15 / 0.05) जोड़ी, इसलिए displayed score transient input noise पर whipsaw नहीं करता। raw cron-computed score अभी भी future smoothing math के लिए persisted है, और score-breakdown panel हर dimension की current value दिखाता है ताकि आप देख सकें कि क्या बदला।
Algorithm version हर cached score record पर stamped है। जब हम एक नया version ship करते हैं, हर score को नया tag मिलता है। नीचे Versions card हर change को document करता है।
Flare की penalty model

Flare validator stake को slash नहीं करता। validator misbehavior के लिए पूरी penalty mechanism reward forfeiture plus FIP-10 passes system है। कोई double-signing slash नहीं, कोई equivocation slash नहीं, कोई stake-destruction event नहीं जिसे हमें track करने की जरूरत है। FIP-10 minimum conditions को fail करने वाले validators उस epoch के rewards lose करते हैं (full forfeit अगर zero passes पर हैं, अन्यथा प्रत्येक protocol के लिए एक pass lose करें जिसे वे fail करते हैं); उनका staked principal untouched है।

इसका मतलब है कि score के पास कोई "slashing history" dimension नहीं है — ऐसा कोई history track करने के लिए नहीं है। जो हम DO track करते हैं वह हर minimum failure का consequence है: validator उस epoch में zero earned, जो epochsIncluded / epochsObserved में captured है। 2026-05-14 पर v4.2 update ने score के reliability multiplier को widen किया ताकि पूरे FIP-10 minimums set (uptime, FSP signing, FTSO submission rate, FDC participation) के पार उस ratio का उपयोग किया जाए ताकि कोई भी minimum fail करने वाला validator Uptime dimension में proportionally penalized हो regardless of कि कौन सी axis fail हुई।

FIP-10 minimum thresholds, sourced from dev.flare.network/network/fsp/rewarding: staking को 80% uptime + 1M FLR active self-bond की जरूरत है; FTSO anchor feeds को estimates की जरूरत है जो 80% of rounds में consensus median के 0.5% के भीतर हैं; FTSO block-latency feeds को expected updates का 80% submit करने की जरूरत है; FDC को voting rounds का 60% में participate करने की जरूरत है। 80% uptime + 1M self-bond floor meet करने वाले लेकिन 3M / 15M earn thresholds से नीचे validators अभी भी rewards receive करते हैं लेकिन passes accumulate नहीं कर सकते — gray zone इस card के passEligibility: "at-risk" classification के via surfaced है।

Versions
v4.8 (2026-09-17) — रिवार्ड एपोक्स को उनकी वास्तविक लंबाई पर वार्षिकीकृत किया गया। प्रत्येक मापा गया वेलिडेटर दर (डिलीवर किया गया APR, डेलिगेशन, MIRROR, ऑपरेटर सेल्फ-बॉन्ड यील्ड) को 3.19-दिन के रिवार्ड एपोक को के साथ वार्षिकीकृत किया गया था, यह मान 2026-04-04 को जोड़ा गया था और ब्लॉक टाइमस्टैम्प से मापा जाने के रूप में वर्णित था, हालांकि इसे कुछ नहीं मापता था। Flare रिवार्ड एपोक्स बिल्कुल 3.5 दिन हैं — FlareSystemsManager का rewardEpochDurationSeconds 302,400 रिटर्न करता है और हर एपोक शुरुआत ऑन-चेन पर 3.500 दिन अलग है — इसलिए प्रत्येक मापी गई दर पाँच डेढ़ महीने के लिए लगभग 9.7% अधिक पढ़ता है, हमारा भी। लंबाई अब उस कॉन्ट्रैक्ट से पढ़ी जाती है। प्रत्येक मापा गया APR एक ही कारक से गिरता है, 3.19 ÷ 3.5 (नेटवर्क मेडियन 9.08% → 8.28%; FlareWatch 8.17% → 7.45%)। स्कोर: केवल डिलीवरी रिलायबिलिटी चलता है, क्योंकि यह मापी गई दर की तुलना वेलिडेटर की फीस के लिए सैद्धांतिक दर के साथ करता है। फुलाए गए पक्ष ने 91% वेलिडेटर को 1.0 कैप पर रखा था, अर्थात् स्पष्ट रूप से संभव से अधिक का भुगतान कर रहे थे; वास्तविक एपोक लंबाई के साथ माध्यिका डिलीवर-से-सैद्धांतिक अनुपात 0.990 है। 168 वेलिडेटर के साथ शिपिंग से पहले मापे गए डेटा के साथ सिम्युलेट किया गया: माध्यिका −0.32 अंक, 146 1 अंक से कम खो देते हैं, 13 पहले से ही अपनी फीस-निहित दर से नीचे डिलीवर कर रहे हैं 2–3.5 खो देते हैं। Community Trust लंबेपन फॉलबैक एपोक्स को उसी लंबाई के साथ दिनों में परिवर्तित करता है और सही किया जाता है; यह कोई स्कोर नहीं चलाता है, क्योंकि यह अधिकतम 8 एपोक्स (28 दिन) देखता है, इसके 30-दिन के चरण से नीचे किसी भी तरह से। हस्ताक्षरित परफॉर्मेंस एटेस्टेशन ने उसी गलत लंबाई का उपयोग किया; रीकम्प्यूट स्पेक को rev.3 के लिए संशोधित किया गया है और rev.2 त्रुटि के साथ प्रकट किए गए शाब्दिक रूप से रखा गया है।
v4.7 (2026-08-19) — सामुदायिक Trust आयाम में दो-अक्ष self-bond। Trust ने ऑपरेटर self-bond को केवल एक अनुपात के रूप में क्रेडिट किया (अपना बांड ÷ कुल स्टेक), तो एक बड़ी self-bond कमजोर प्रतिनिधिमंडन द्वारा उस अनुपात पर एक छोटी बांड के समान स्कोर किया — स्कोर वास्तविक पूंजी प्रतिबद्ध के लिए अंधा था। पूरे लाइव नेटवर्क में 178 में से 61 वेलिडेटर ने <10% अनुपात पर ≥10M self-bond रखा, तो तीसरा क्षेत्र कम क्रेडिट दिया गया। v4.7 आनुपातिक हिस्से (≥10% → +2, 5–10% → +1, अपरिवर्तित) या निरपेक्ष आकार (min(1, selfBond ÷ 20M) × 2, नेटवर्क top-decile P-chain बांड पर संतृप्त) में से बेहतर द्वारा self-bond को क्रेडिट करता है, अधिकतम को लेते हुए और अभी भी उप-सिग्नल को +2 पर सीमित करते हुए — Trust कैप (11) और समग्र कैप (100) अपरिवर्तित हैं, और sub-FIP-10 खोखला फर्श (<1M FLR → −1) अपरिवर्तित है। FTSO प्रदाता स्कोर पहले से उपयोग करने वाले दो-अक्ष self-bond को मिररों करता है। सभी 178 वेलिडेटरों पर क्षेत्र-व्यापी पहले/बाद, भेजने से पहले संग्रहीत: 58 ऊपर जाते हैं, कोई नीचे नहीं, कोई स्कोर एक बिंदु से अधिक नहीं बढ़ता है, और लीडरबोर्ड का शीर्ष अपरिवर्तित है। हमारा अपना नोड एक बिंदु से बढ़ता है (83 → 84) हर दूसरे अच्छी तरह से पूंजीकृत ऑपरेटर के समान नियम से — कोई शब्द नहीं हमें नाम देता है।
v4.6 (2026-08-13) — MIRROR दी गई-परिमाण बोनस। MIRROR आयाम पहले केवल पास-थ्रू (MIRROR का अंश जो प्रतिनिधियों तक पहुंचता है, = 1 − शुल्क) और भागीदारी स्थिति को स्कोर करता था — यह दी गई राशि के लिए अंधा था। एक वैलिडेटर जो क्षेत्र की तुलना में बहुत अधिक दी गई MIRROR दर (mirrorAPY, शुल्क के बिना) का भुगतान करता था उसे इसके लिए कोई क्रेडिट नहीं मिलता था, इसलिए एक वास्तविक रूप से उच्च-यील्ड नोड यील्ड आयामों पर कम-यील्ड वाले के नीचे रैंक कर सकता था। v4.6 एक छोटा, कैप्ड, माध्यिका-एंकर बोनस जोड़ता है: केवल mirror-सक्रिय वैलिडेटर के लिए, क्लैंप((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2)। केवल नेटवर्क माध्यिका दर से 1.2× से ऊपर की डिलीवरी इसे अर्जित करती है, और यह अधिकतम +2 है, MIRROR आयाम छत को 10 से 12 तक बढ़ाता है (समग्र अभी भी 100 पर क्लैंप किया गया है)। यह वॉल्यूम नहीं, दर के लिए नेटवर्क माध्यिका में एंकर किया गया है, इसलिए यह निर्माण के आधार पर आकार-तटस्थ है: जीवंत क्षेत्र में बोनस self-bond के साथ नकारात्मक रूप से संबंधित है (यह उच्च दरें दिए जाने वाले छोटे वैलिडेटर का समर्थन करता है, बड़े वालों का नहीं)। भेजने से पहले सभी सक्रिय वैलिडेटर पर क्षेत्र-व्यापी पहले/बाद को संग्रहीत किया गया था — अधिकांश वैलिडेटर नहीं हिलते, और लीडरबोर्ड का शीर्ष अपरिवर्तित है। वही सूत्र हर वैलिडेटर पर लागू होता है, हमारे अपने नोड सहित।
v4.5 (2026-07-16) — Extreme-fee viability penalty। Fee Reasonableness dimension 0/7 पर saturate होता है एक बार fee बाजार anchor + 20 अंक (~40% post-Granite) से अधिक हो जाता है; वहां से 100% fee तक composite बिल्कुल fee के प्रति प्रतिक्रिया नहीं करता, इसलिए एक 100%-fee validator — जहां delegators कुछ नहीं रखते — अपने fee-blind dimensions पर अभी भी 40s में स्कोर करते थे। एक delegator-facing score पर यह परिणाम near-disqualifying है, mid-table नहीं। v4.5 एक composite penalty जोड़ता है जो positive-dimension total के एक अंश के रूप में लागू होता है: 50% fee पर या उससे नीचे शून्य (Fee dimension पहले से जो कीमत देता है उस range में दोहरी-गणना नहीं), फिर 100% fee पर score का 75% तक रैखिक रूप से रैंप करता है। एक 100%-fee node लगभग 10/100 पर आता है — अभी भी सूचीबद्ध और रैंक किया गया, स्पष्ट रूप से delegation candidate नहीं। यह on-chain fee का एक pure function है, हर validator के लिए समान, हमारे अपने node सहित।
v4.4 (2026-07-11) — ग्रेनाइट तल-सचेत शुल्क एंकर। ग्रेनाइट हार्ड फोर्क (Flare, 2026-07-14) एक 20% न्यूनतम वेलिडेटर प्रतिनिधिमंडन शुल्क लागू करता है। शुल्क तर्कसंगतता एंकर max(देखा गया न्यूनतम सक्रिय शुल्क, प्रोटोकॉल तल) बन जाता है: कानूनी न्यूनतम पर या उससे नीचे हर शुल्क पूर्ण अंक अर्जित करता है, और केवल इसके ऊपर के शुल्क दूरी द्वारा दंडित होते हैं। तर्क: उड़ान भरने वाले दांव के दादा को अप्रमाणित छोड़ने के साथ, एक दादा वाले 2% (या फोर्क-पूर्व 0%) अवशेष को एंकर करना प्रोटोकॉल-अनुपालक 20% ऑपरेटरों को लगभग-निष्कर्षक के रूप में स्कोर किया होता — और नेट यील्ड पहले से ही वितरित शर्तों में मूल्य देने वाले शुल्क डेल्टा को दोहराया होता। कोई अन्य आयाम नहीं बदला। जब पूरा समूह तल तक पहुंचता है, तो आयाम समान रूप से पूर्ण अंक प्रदान करता है — शुल्क गिनना बंद हो जाता है एक बार जब कोई भी इस पर प्रतिस्पर्धा नहीं कर सकता।
v4.3 (2026-05-14) — Active Outage Penalty को flat post-dimension deduction के रूप में जोड़ा गया। existing uptimeReliability multiplier symmetric है — 24 epochs में 5 scattered misses, 5 misses in a row के समान cost करते हैं — लेकिन operationally वे बहुत अलग signals हैं: scattered misses का मतलब है chronic flakiness, streak का मतलब है validator अभी टूटा हुआ है। v4.3 validator के recent participation history के head पर contiguous run को read करता है !eligible epochs का और 0-point को 0–1 consecutive misses के लिए deduct करता है (normal variance / single transient miss), 3 pts को 2 पर (developing outage), 6 pts को 3 पर (sustained outage), और 10 pts को 4+ पर (active extended outage), composite को 0 पर floored किया जाता है। Layered on top of — not replacing — reliability multiplier, क्योंकि दोनों different hazards को capture करते हैं। Trigger: 2026-05-14 पर Luganodes-class incident, जहां multiple recent epochs एक पंक्ति में miss हुए जबकि delegators actively stake को commit कर रहे थे; streak signal delegators को committed करने से पहले in-flight failure को देखने देता है। Penalties score-breakdown panel में अपने section के रूप में render होते हैं ताकि 9 positive dimensions अभी भी 100 को sum करें।
v4.2 (2026-05-14) — TWO संबंधित fixes, Luganodes' score के बारे में AU (@aucc_official) से एक public correction के response में साथ में shipped। (1) deliveredAPY computation अब rate-per-earning-epoch को `epochsIncluded / epochsObserved` से multiply करता है ताकि displayed APR उस EFFECTIVE rate को reflect करे जो एक delegator actually receives over observation window — शामिल करके zero-earning epochs को जब एक validator FIP-10 minimums को fail करता है। prior implementation केवल earning epochs को average करता था और validators को उनके good-epoch rate को दिखाता था, minimum failures को mask करते हुए। (2) Uptime dimension का reliability multiplier uptime-only (epochsUptimeEligible / epochsObserved) से पूरे FIP-10 minimums set (epochsIncluded / epochsObserved) को widen किया। 100% RPC uptime वाला एक validator जो FSP signing या FTSO submission rate को fail करता है अब Uptime dimension पर proportional hit लेता है regardless of कौन सी minimum को वे miss करते हैं। Luganodes पर विशेष रूप से Net effect: deliveredAPY 10.86% से ~5.43% तक drops (matching actual half-paying reality), uptime reliability 1.0 से 0.5 तक drops, score materially drops। `epochsIncluded < epochsObserved` वाले हर validator के लिए same correction apply होता है — network भर में यह real participation-quality gaps को surface करता है जो previously hidden थे।
v4.1 (2026-05-14) — Net Yield dimension को theoretical APR (formula: gross_APR × (1 − fee)) से MEASURED deliveredAPY को switched किया है Flare Foundation reward-scripts से, जिसमें theoretical fallback per-validator है केवल जब कोई measurement history नहीं है। Trigger: FIP-16 का inflation reduction (5% → 3%) 2026-05-14 को live हुआ, और theoretical formula का eligible-stake denominator on-chain reality से दूर drift हो गया जैसे कि theoretical APR network भर में delivered yields को ~2× से under-report करता था। measured-first को switch करना score input को उस साथ realign करता है जो stakers actually receive करते हैं। networkMedianAPR anchor को भी measured-first methodology का उपयोग करके recompute किया गया ताकि ratio comparison दोनों sides पर consistent रहे — scores roughly stable होने चाहिए (network median पर एक validator अभी भी ~12/18 को score करता है, आदि), केवल formula output के बजाय real delivered rates पर आधारित।
v4.0 (2026-05-11) — Major version। v3.7-v3.10 cycle cumulatively scoring system का एक structural rewrite constitute करता है, बड़ा पर्याप्त bump को warrant करने के लिए। Summary: दो dimensions के पास उनके caps changed (Trust 10→11, Capacity 8→7); Operator Quality का formula को rewritten किया गया max(verification, FTSO-derived) के लिए ताकि participation hurt न कर सके; चार remaining bucketed dimensions (Uptime, Fee, Delivery, Time Remaining) को linearized किया गया boundary cliffs को eliminate करने के लिए; तीन नए score components add किए गए (30-day delegation retention, 30-day self-bond trajectory, auto-promotion to curated tier); multi-node operator aggregation को Trust count + concentration के लिए introduce किया गया; longevity अब wipe-immune है reward-scripts epoch presence के via; और दो perverse incentives eliminate किए गए (Operator Quality FTSO-participation penalty और Uptime 95% inverted-V cliff)। Score के लिए हर input अब externally verifiable है — कोई editorial decision load-bearing नहीं है। Validators हर observable behavior (90+ days observed, 25+ delegators, retention not declining, FIP-10-compliant self-bond) के through +7 curated-operator baseline को earn कर सकते हैं, कोई email-the-team required नहीं। granular changes के लिए नीचे v3.7-v3.10 entries देखें जो इस release को compose करते हैं।
v3.10 (2026-05-11) — Score में last curatorial gap को closed किया। Operator Quality पर +7 curated-operator baseline पहले हमारे KNOWN_VALIDATORS list में hand-inclusion को require करता था, जो v3.7-v3.9 audit cycle के बाद एकमात्र meaningful editorial decision था। v3.10 एक objective auto-promotion path add करता है: कोई भी validator 90+ days FlareWatch observation के साथ, 25+ operator-aggregated delegators, retention not in decline में (30-day drop ≤ 15%), और FIP-10-compliant self-bond automatically +7 baseline के लिए qualify करता है — कोई manual review needed नहीं। KNOWN_VALIDATORS एक fast-track के रूप में रहता है institutional operators के लिए जिन्हें अभी तक 90-day window accumulate नहीं करना है (एक launch-day Ankr या Kiln entry think करें), लेकिन typical case अब fully automated है। सभी चार criteria on-chain-derived या near-on-chain हैं (delegator count, retention, self-bond) plus हमारा अपना observation timestamp — कुछ भी subjective नहीं, कोई email-the-team gating नहीं। Net effect: एक validator behavior alone के through +7 tier को earn कर सकता है। network पर most established operators पहले से ही आज criteria को meet करते हैं।
v3.9 (2026-05-11) — Boundary-cliff cleanup remaining चार bucketed dimensions के पार, fairness के लिए score के हर part को audit करने के बाद। Fixed: (1) Uptime curve में एक perverse inverted-V cliff 95% पर — 94.99% → 95.00% uptime जाना से 4 points lose हुए (95-99% branch 0 पर शुरू हुआ lower branch के max 4 को match करने के बजाय)। Operator Quality में हमने अभी-अभी fix किए गए same shape का backward incentive (v3.8)। (2) Fee Reasonableness thresholds linearized — pre-v3.9, bucket boundary के पार एक 0.01% fee increase up to 2.5 points को lose कर सकता था। अब piecewise linear bucket values को boundaries पर preserve करने वाले increasingly steep slopes के साथ (low fees barely penalized, extractive fees punished hard)। (3) Delivery Reliability deliveryRatio thresholds linearized — same pattern, up to 2-point cliffs eliminated। (4) Time Remaining bucket thresholds linearized — छोटे cliffs (14-day boundary पर max 2 points) लेकिन अभी भी एक छोटे dimension में present; अब smooth। Net Yield, MIRROR Participation, और Capacity Profile को audit किया गया और confirmed fair-as-is (already linear/continuous)। Total cap unchanged 100 पर। कोई score regressions design द्वारा नहीं; एकमात्र validators जिनके scores move करते हैं वे हैं जो happened हो सकते हैं previous bucket boundary पर exactly sitting करने के लिए।
v3.8 (2026-05-11) — Operator Quality dimension audited और एक fairness review के बाद rewritten। तीन fixes एक साथ shipped। (1) एक perverse incentive eliminate किया — एक known operator एक mid-tier FTSO score (e.g. 50) के साथ 4 pts को score करता है, लेकिन same operator FTSO से पूरी तरह dropping 7 pts को score करता है। v3.8 के under score max(verification baseline, FTSO-derived) है, इसलिए FTSO participation केवल help कर सकता है, कभी hurt नहीं। (2) एक intermediate verification tier introduce किया — Flaremetrics या FSE से auto-discovered names वाले operators (लेकिन अभी तक curated KNOWN_VALIDATORS map में नहीं) +3 को 0 के बजाय get करते हैं, पिछले 7→0 cliff को softening करते हुए। (3) surfaces दोनों signals breakdown detail में जब verification एक low FTSO score (e.g.
v3.7 (2026-05-11) — Community Trust dimension audited और एक operator-fairness review के बाद expanded। तीन additions: (1) Multi-node operator aggregation — operators जो multiple P-Chain nodes (AU, FlareBus, Aureus Ox, Kiln, आदि) चलाते हैं अब अपने delegator count और total stake को Trust count + concentration signals के लिए aggregated किया जाता है, इसलिए वे same delegator base को multiple nodes के पार distribute करने के लिए penalized नहीं हैं। (2) 30-day delegation retention signal (±0.5 pt) — growing / stable / shrinking validators को distinguish करता है एक sliding-window comparison का उपयोग करके। snapshot-only Trust dimension पहले इन्हें tell apart नहीं कर सकता था। (3) 30-day self-bond trajectory (±0.5 pt) — operators को reward करता है जो अपने self-bond को समय के साथ बढ़ाते हैं, उन्हें penalizes करता है जो quietly un-bonding करते हैं। sudden-change penalty से distinct जो केवल single large drops को catch करता है। Cap rebalanced: Trust 10 → 11, Capacity 8 → 7। Audit से Bug fixes: (a) zero self-bond अब sub-FIP-10 penalty को correctly hit करता है (पहले एक `selfBondFLR > 0` gate let exactly-0 self-bond escape the −1)। (b) FIP-10 floor और 5% के बीच small self-bond ratios अब breakdown panel में actual percentage को render करते हैं ताकि operators देख सकें कि क्या +1 / +2 tiers को close करता है। (c) longevity bonus अब wipe-immune है — falls back reward-scripts epoch presence को जब first-observed KV artificially fresh है।
v3.6 (2026-05-11) — MIRROR detection के लिए दो fixes, एक साथ shipped। (a) Detection अब दो canonical sources से read करता है: on-chain RewardClaimed(claimType=3) events V2 RewardManager से AND claimType=3 allocations official FSP Merkle JSON में (same data जो Flare का अपना signing tool consume करता है)। Either signal sufficient है — catches validators जिनके MIRROR allocated हो गए हैं लेकिन yet on-chain claim नहीं किया गया। (b) Merkle के विरुद्ध cross-checking एक separate key-format bug को revealed किया: validators:mirror-stats के पास mixed hex20/cb58 NodeID keys (on-chain indexer ने hex लिखा जब एक validator अभी तक हमारे curated name list में नहीं था), जबकि हर UI consumer cb58 के द्वारा केवल lookup करता था — तो ~95 validators' status display के लिए invisible था। Lookup अब दोनों formats को validators table, score-breakdown panel, mirror-stats public API, Yield page Staking Positions card, और FTSO providers panel के पार normalize करता है। Affected validators अगले cron cycle पर अपने MIRROR Participation + Operator Quality dimensions और overall FlareWatch Score 9-10 points rise को देखा। FTSO-provider report (FlareBus, 2026-05-11) के via discovered — credit और thanks। उनके feedback ने हर delegator के network के view को materially improve किया, केवल उनके स्वयं के scores को नहीं।
v3.5 (2026-05-09) — Net Yield अब median-anchored network APR के विरुद्ध (median पर एक validator 12/18 को score करता है, top performers 18 तक reach करते हैं, bottom-quartile 0 को drops)। Trust dimension self-bond alignment को एक चौथे component के रूप में absorbed किया (proportional self-bond rewards skin-in-the-game; sub-FIP-10 floor एक छोटी penalty लेता है)। नया "NEW Xd" badge surface validators FlareWatch has केवल <30 days के लिए observed ताकि stakers देख सकें जब track record thin है।
v3.4 (2026-05-09) — Uptime dimension अब instantaneous RPC uptime को historical FIP-10 epoch-eligibility ratio के साथ blend करता है। Pre-v3.4 dimension non-discriminating था (92.9% of validators 100% RPC uptime रखते थे)। Reliability ratio derived epochsUptimeEligible / epochsObserved से last 8 reward-scripts epochs के पार — एक time-series signal जो meaningfully differentiate करता है validators जो occasionally FIP-10 minimum conditions को fail करते हैं उन लोगों को जो नहीं करते हैं।
v3.3 (2026-05-09) — Delivery dimension अब exponentially time-weighted mean rate को use करता है (recent epochs more count करते हैं, decay constant 0.85) और एक variance penalty को apply करता है (coefficient of variation × 0.5, capped at −30%)। Computed per-epoch reward-scripts data से — sample size carries through existing confidence dampener के रूप में।
v3.2 (2026-05-09) — Multi-signal Community Trust (count + concentration + longevity); first-observed-by-FlareWatch tracking persisted KV में longevity bonus के लिए; stake-end edge-case (validators 14 days के within Time Remaining पर 0 को score करते हैं expiry से क्योंकि वे FIP-10 के under नए delegations को accept नहीं कर सकते); methodology page को public made किया; operator feedback channel को surfaced; algorithm version stamped हर cached score record पर।
v3.1 (2026-05-09) — Wired Delivery dimension reward-scripts data से; smoothed Operator Quality (linear interpolation), Capacity (tent function), और Trust (log scale); reclassified FSP-known + zero claimType=3 को MIRROR "inactive" के रूप में "no data" के बजाय; persisted scoreBreakdown server-side ताकि client पूरे inputs के बिना recompute नहीं करता।
v3 (2026-05-09) — Replaced binary identity bonus को continuous Operator Quality के साथ। Added MIRROR Participation एक dedicated dimension के रूप में fee passthrough के साथ। Made capped capacity neutral एक 0-pt penalty के बजाय। Removed APY/fee double-count Net Yield के via। Recalibrated bands (Top tier 90+, Strong/Good/Acceptable/Below median)।
v2 (pre-2026-05-09) — Original 8-dimension score (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery)। APY/Fee double-count, binary identity penalty, capped-capacity penalty, कोई MIRROR dimension नहीं के कारण Retired। Historical reference के लिए Documented।
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.