सिग्नल

हर वॉच प्रकार में एक या अधिक सिग्नल होते हैं। एक सिग्नल एक शर्त जाँचता है, उदाहरण के लिए गायब FTSO कमिट या आपकी सीमा से कम क्रेडिट बैलेंस। वॉच एडिटर के भाग 3. संकेत में आप हर सिग्नल को चालू या बंद कर सकते हैं, उसकी रिकवरी सूचना चालू या बंद कर सकते हैं, और उसके पैरामीटर बदल सकते हैं। डिफ़ॉल्ट पर रीसेट करें मानक मान वापस ले आता है।

सिग्नल FTSO, FDC या बैलेंस जैसे सिग्नल समूहों में आते हैं। रूटिंग के लिए समूह मायने रखते हैं, क्योंकि आप किसी एक समूह को बाकी से अलग प्राप्तकर्ताओं को भेज सकते हैं; देखें प्राप्तकर्ता और रूटिंग।

नीचे दिए गए संदर्भ में हर सिग्नल चार सवालों के जवाब देता है: क्या जाँचा जाता है, यह क्यों महत्वपूर्ण है, आम कारण, और आप क्या कर सकते हैं। यही पाठ ऐप में भी दिखते हैं जब आप किसी सिग्नल के पास जानकारी आइकन पर क्लिक करते हैं।

लगभग हर सिग्नल डिफ़ॉल्ट रूप से चालू होता है और रिकवरी सूचना भेजता है। अपवाद नीचे के संदर्भ में चिह्नित हैं। प्रोवाइडर वॉच का सिग्नल निगरानी की उपलब्धता हमेशा चालू रहता है और इसे बंद नहीं किया जा सकता, क्योंकि यह आपको बताता है कि कब निगरानी स्वयं संभव नहीं है।

कुछ प्रोवाइडर सिग्नल में पैरामीटर लगातार राउंड होता है। यह किसी एक देर से आए या गायब सबमिशन को रात में आपको जगाने से रोकता है। डिफ़ॉल्ट 2 है।

डिफ़ॉल्ट 2 के साथ उदाहरण:

• राउंड 1000: कमिट गायब है। लगातार पहला राउंड, अभी कोई अलर्ट नहीं।
• राउंड 1001: कमिट फिर गायब है। लगातार दूसरा राउंड, अलर्ट।
• राउंड 1002: कमिट समय पर आता है। रिकवरी सूचना, अगर वह चालू है।

अगर राउंड 1001 ठीक होता, तो कुछ भी नहीं भेजा जाता। जब तक कोई अलर्ट सक्रिय है, आगे के खराब राउंड उसे दोबारा नहीं भेजते; आपको हर समस्या के लिए एक अलर्ट मिलता है, हर राउंड के लिए नहीं। अगर आप हर एक चूक के बारे में जानना चाहते हैं, तो मान 1 पर सेट करें।

रिकवरी सूचना आपको बताती है कि स्थिति फिर सामान्य है। यह उन्हीं प्राप्तकर्ताओं को जाती है जिन्हें अलर्ट गया था। अगर आपको केवल समस्याओं से मतलब है, तो इसे हर सिग्नल के लिए अलग से बंद करें।

कूलडाउन हर वॉच की एक सेटिंग है जिसका नाम अलर्ट के बीच न्यूनतम अंतराल है। यह उस समय के भीतर उसी घटना के दोहराव को रोकता है, लेकिन रिकवरी सूचना जैसी किसी अलग घटना को कभी नहीं। यह विस्तार से कैसे काम करता है, यह संदेश और शांत घंटे पर है।

जब Watchdog कोई मान नहीं पढ़ पाता, उदाहरण के लिए क्योंकि कोई डेटा स्रोत देर से है, तो वह इसे स्वस्थ स्थिति नहीं मानता। बिना सबूत वाला राउंड खराब राउंड के सिलसिले को तोड़ देता है, लेकिन कभी रिकवरी सूचना ट्रिगर नहीं करता। प्रोवाइडर वॉच के लिए, सिग्नल निगरानी की उपलब्धता आपको बताता है जब analyzer का डेटा 10 मिनट से पुराना हो; जब तक ऐसा है, उस वॉच के बाकी प्रोवाइडर अलर्ट अनुमान लगाने के बजाय रुके रहते हैं।

1. आपकी वॉचेस खोलें और वॉच पर संपादित करें चुनें।
2. भाग 3. संकेत खोलें और वह समूह खोलें जिसे आप बदलना चाहते हैं।
3. सिग्नल या उसकी रिकवरी सूचना को चालू या बंद करें, या कोई पैरामीटर बदलें। अगर कोई मान सीमा से बाहर है, तो भाग में “इस भाग के मान जाँचें।” दिखता है, और जब तक आप उसे ठीक नहीं करते, सहेजना बंद रहता है।
4. सहेजें। बदलाव अगली जाँच से लागू होता है।

चुने watch target और threshold के events।

बैलेंस में बदलाव

कॉन्फ़िगर किए गए वॉलेट बैलेंस का बदलाव सीमा पार करने पर सूचित करता है।

• क्या जाँचा जाता है? पिछले observation से balance तुलना कर चुनी दिशा में threshold पहुँचने पर alert देता है। पहला observation baseline है।
• यह क्यों महत्वपूर्ण है? Balance change tracked incoming या outgoing transfer दर्शा सकता है।
• आम कारण: Observations के बीच transfers, gas fees या अन्य balance changes हुए।
• क्या करें? Observed amounts को recent wallet transactions और configured token से मिलाएँ।
• सिग्नल सक्रिय: चालू

चुने watch target और threshold के events।

मूल्य में बदलाव

कॉन्फ़िगर किए गए फ़ीड का बदलाव सीमा पार करने पर सूचित करता है।

• क्या जाँचा जाता है? USD price को window के सबसे पुराने valid point से मिलाता है। threshold पर प्रति window अधिकतम एक alert; दोगुना critical है।
• यह क्यों महत्वपूर्ण है? बड़ा observed price move ध्यान देने योग्य हो सकता है।
• आम कारण: Current feed price चुनी window के पुराने valid price से अलग है।
• क्या करें? Timestamps और prices की तुलना कर window और percentage देखें।
• सिग्नल सक्रिय: चालू

चुने watch target और threshold के events।

प्रोवाइडर स्थिति

प्रोवाइडर का पंजीकरण हटने या पात्रता खोने पर सूचित करता है।

• क्या जाँचा जाता है? baseline के बाद registration या eligibility खोने और लौटने पर बताता है। dataset में गायब provider unregistered और ineligible माना जाता है।
• यह क्यों महत्वपूर्ण है? अपंजीकृत या अपात्र प्रोवाइडर उस रिवॉर्ड युग में अपने डेलिगेटरों के लिए कोई पुरस्कार नहीं कमाता।
• आम कारण: पंजीकरण छूट गया या कोई pass शेष न रहते हुए एक Minimal Condition पूरी नहीं हुई।
• क्या करें? Flare Systems Explorer पर प्रोवाइडर की Minimal Conditions और passes तथा वर्तमान युग के लिए उसका पंजीकरण जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

चुने watch target और threshold के events।

कम क्रेडिट बैलेंस

आपका क्रेडिट बैलेंस कॉन्फ़िगर की गई सीमा से नीचे जाने पर सूचित करता है।

• क्या जाँचा जाता है? wallet credit balance limit से कम होने पर alert; limit के बराबर भी recovery है।
• यह क्यों महत्वपूर्ण है? कम credits उन services को प्रभावित कर सकते हैं जो credits खर्च करती हैं।
• आम कारण: Credit खर्च या adjustment से balance चुनी सीमा के नीचे गया हो सकता है।
• क्या करें? Credit balance और recent entries देखकर threshold बदलें या जरूरत पर भरें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

चुने watch target और threshold के events।

रिवॉर्ड साइनिंग

खुले, विलंबित या छूटे हुए अपटाइम और रिवॉर्ड हस्ताक्षरों की सूचना देता है।

• क्या जाँचा जाता है? समाप्त epoch के uptime और reward signatures जाँचता है। epoch end या पहली observed publication के दो घंटे बाद alert; बारह घंटे बाद reminder, समाप्त unsigned vote critical।
• यह क्यों महत्वपूर्ण है? आवश्यक provider signature बाकी है या समाप्त vote से छूट गया है।
• आम कारण: Uptime या reward data के observed signer set में identity नहीं है।
• क्या करें? Configured identity का epoch, vote state और signing process जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

FTSO voting rounds में commit, reveal और signature भागीदारी।

FTSO कमिट

लगातार राउंड में कमिट गायब या देर से आया।

• क्या जाँचा जाता है? लगातार voting rounds में गायब या देर से आए FTSO commits जाँचता है।
• यह क्यों महत्वपूर्ण है? वैध commit के बिना आपका मान उस वोटिंग राउंड में नहीं गिना जाता, इसलिए आप उसके माध्यिका-निकटता पुरस्कार खो देते हैं। छूटे राउंड anchor-feed Minimal Condition को पूरा करने में भी बाधा बनते हैं (हर रिवॉर्ड युग के 80% राउंड में माध्यिका से 0.5% के भीतर)।
• आम कारण: FTSO क्लाइंट या Flare System Client बंद है या रीस्टार्ट हो रहा है, C-chain इंडेक्सर चेन के नवीनतम ब्लॉक से पीछे है, RPC समस्याएँ हैं या सबमिट पते पर मूल टोकन बैलेंस कम है।
• क्या करें? जाँचें कि सिस्टम क्लाइंट हर राउंड में “Submitter submit1 successfully sent tx” लॉग करता है, इंडेक्सर चेन के नवीनतम ब्लॉक तक पहुँचा है और सबमिट पते पर धन है।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

FTSO रिवील

लगातार राउंड में रिवील गायब, जल्दी या देर से आया।

• क्या जाँचा जाता है? लगातार voting rounds में गायब, जल्दी या देर से आए FTSO reveals जाँचता है।
• यह क्यों महत्वपूर्ण है? मेल खाते reveal के बिना commit पर दंड लगता है: आपका मान बाहर हो जाता है और राउंड के पुरस्कार घट जाते हैं या खो जाते हैं। reveal न होने पर आपकी यादृच्छिक संख्या भी उस राउंड से हट जाती है।
• आम कारण: क्लाइंट commit और reveal के बीच रीस्टार्ट हुआ, reveal (submit2) बहुत देर से भेजा गया या सबमिट पते का धन समाप्त हो गया।
• क्या करें? बताए गए राउंड के submit2 लेनदेन, लॉग में commit और reveal का समय-अंतर और क्या क्लाइंट बीच में रीस्टार्ट हुआ था, जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

FTSO हस्ताक्षर

लगातार राउंड में हस्ताक्षर गायब या जल्दी आया।

• क्या जाँचा जाता है? लगातार rounds में गायब या जल्दी आए FTSO signatures जाँचता है; grace period चूक अलग signal है।
• यह क्यों महत्वपूर्ण है? हस्ताक्षर पुरस्कार केवल अंतिम रूप दिए गए Merkle root पर समय से पहुँचे हस्ताक्षरों के लिए मिलते हैं। हस्ताक्षर न होने पर यह हिस्सा खो जाता है और राउंड को अंतिम रूप देने में मदद नहीं मिलती।
• आम कारण: हस्ताक्षर चरण (submitSignatures) विफल हुआ या देर से हुआ, Merkle root की गणना नहीं हो सकी या हस्ताक्षर सबमिट पते पर धन कम है।
• क्या करें? सिस्टम क्लाइंट के लॉग में “Submitter submitSignatures successfully sent tx” खोजें और हस्ताक्षर सबमिट पते का बैलेंस जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

FDC bitvotes, signatures और consensus requests से सहमति।

FDC बिटवोट

लगातार राउंड में बिटवोट गायब, जल्दी या देर से आया।

• क्या जाँचा जाता है? लगातार voting rounds में गायब, जल्दी या देर से आए FDC bitvotes जाँचता है।
• यह क्यों महत्वपूर्ण है? समय पर bitvote के बिना आप उस राउंड की FDC सहमति में भाग नहीं लेते। FDC Minimal Condition के लिए हर रिवॉर्ड युग के 60% वोटिंग राउंड में सफल भागीदारी आवश्यक है।
• आम कारण: FDC क्लाइंट या verifier उपलब्ध नहीं हैं, attestation स्रोत (जैसे BTC, DOGE या XRP नोड) सिंक नहीं है या bitvote चयन चरण के बाहर भेजा गया (राउंड शुरू होने के 90–135 सेकंड में चयन चरण होता है)।
• क्या करें? FDC क्लाइंट के लॉग और हर verifier का /health एंडपॉइंट जाँचें तथा देखें कि bitvote लेनदेन चयन चरण के भीतर पहुँचता है या नहीं।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

FDC हस्ताक्षर

लगातार राउंड में हस्ताक्षर गायब या जल्दी आया।

• क्या जाँचा जाता है? लगातार voting rounds में गायब या जल्दी आए FDC signatures जाँचता है।
• यह क्यों महत्वपूर्ण है? FDC भागीदारी तभी गिनी जाती है जब आप सही Merkle root सबमिट करते हैं। आपके हस्ताक्षर के बिना राउंड 60% की शर्त में नहीं गिना जाता और उसके हस्ताक्षर पुरस्कार खो जाते हैं।
• आम कारण: FDC Merkle root नहीं बन सका या उस पर हस्ताक्षर नहीं हो सका, verifier डेटा अधूरा था या हस्ताक्षर सबमिट पते पर धन कम है।
• क्या करें? FDC क्लाइंट और verifier की स्वास्थ्य स्थिति तथा बताए गए राउंड के submitSignatures लेनदेन जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

अप्रत्याशित FDC submit1

एक FDC submit1 देखा गया।

• क्या जाँचा जाता है? submission data उपलब्ध होने पर देखा गया FDC submit1 बताता है।
• यह क्यों महत्वपूर्ण है? FDC के लिए यह submission phase अप्रत्याशित है; configuration जाँचें।
• आम कारण: Submitter गलत protocol या submission method उपयोग कर सकता है।
• क्या करें? Reported transaction और submitter protocol configuration जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

अपुष्ट सहमति अनुरोध

लगातार दौरों में अपुष्ट सहमति अनुरोधों के लिए एक संयुक्त चेतावनी।

• क्या जाँचा जाता है? लगातार voting rounds में unconfirmed consensus requests पर एक aggregate alert देता है।
• यह क्यों महत्वपूर्ण है? सहमति ने जिन अनुरोधों की पुष्टि की और आपने नहीं की, उनका आम तौर पर अर्थ है कि आपका verifier उन्हें जाँच नहीं सका। उस डेटा के बिना आप अक्सर सहमति का Merkle root बना और हस्ताक्षरित नहीं कर सकते, और राउंड आपके लिए नहीं गिना जाता।
• आम कारण: किसी चेन का verifier बंद या पीछे है, या उसका डेटा स्रोत (जैसे BTC, DOGE या XRP नोड) सिंक नहीं है।
• क्या करें? पता करें कि अपुष्ट अनुरोध किस चेन या attestation प्रकार के हैं और उस verifier की स्वास्थ्य तथा सिंक स्थिति जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• लगातार राउंड: डिफ़ॉल्ट 2 (1–20)। लगातार खराब voting rounds; 2 एक अकेली चूक अनदेखी करता है। data गायब होने पर streak reset, recovery साबित नहीं।

FDC बिटवोट की लंबाई

बिटवोट की लंबाई सत्यापित विशिष्ट अनुरोधों की संख्या से अलग है।

• क्या जाँचा जाता है? FDC bitvote length को verified unique request count से मिलाता है।
• यह क्यों महत्वपूर्ण है? गलत लंबाई वाला bitvote राउंड के अनुरोधों से नहीं मिलाया जा सकता, इसलिए वह न सहमति में गिना जाता है, न आपकी FDC भागीदारी में।
• आम कारण: FDC क्लाइंट को चेन से अलग अनुरोध मिले, जैसे इंडेक्सर के पीछे होने या अपग्रेड के बाद क्लाइंट संस्करण की समस्या के कारण।
• क्या करें? जाँचें कि C-chain इंडेक्सर नवीनतम ब्लॉक तक पहुँचा है और FDC क्लाइंट वर्तमान संस्करण चला रहा है, फिर लॉग में अनुरोधों की संख्या की तुलना करें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

reveal mismatch, गलत signer या signature grace period चूक के प्रमाण।

रिवील उल्लंघन

कमिट और रिवील मेल नहीं खाते; तुरंत गंभीर अलर्ट।

• क्या जाँचा जाता है? सत्यापित FTSO commit/reveal mismatch तुरंत critical alert देता है।
• यह क्यों महत्वपूर्ण है? अपने commit से मेल न खाने वाले reveal पर दंड लगता है: राउंड के पुरस्कार घट जाते हैं या खो जाते हैं, और दंड किसी युग के रिवॉर्ड दावों को ऋणात्मक बना सकते हैं।
• आम कारण: commit और reveal अलग डेटा से बने, आम तौर पर रीस्टार्ट के बाद, या दो चल रहे इंस्टेंस उन्हीं पतों से सबमिट करते हैं।
• क्या करें? सुनिश्चित करें कि आपके पतों के लिए केवल एक क्लाइंट सबमिट करता है और बताए गए राउंड के आसपास के लॉग जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

गलत हस्ताक्षरकर्ता

हस्ताक्षर signing policy पते से मेल नहीं खाता।

• क्या जाँचा जाता है? जाँचता है कि FTSO या FDC signer signing policy address से अलग है या नहीं।
• यह क्यों महत्वपूर्ण है? गलत कुंजी का हस्ताक्षर आपके भार में नहीं गिना जाता। आप हस्ताक्षर पुरस्कार खो देते हैं और यह राउंड को अंतिम रूप देने में मदद नहीं करता।
• आम कारण: क्लाइंट ऐसी कुंजी से हस्ताक्षर करता है जो आपकी entity के पंजीकृत signing policy पते से मेल नहीं खाती, जैसे कुंजी बदलने के बाद या कॉन्फ़िगरेशन में गलत कुंजी होने पर।
• क्या करें? बताए गए लेनदेन के हस्ताक्षरकर्ता की तुलना आपकी identity के लिए पंजीकृत signing policy पते से करें और कॉन्फ़िगर की गई हस्ताक्षर कुंजी ठीक करें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

हस्ताक्षर की समय सीमा चूकी

हस्ताक्षर पुरस्कार की समय सीमा के बाद आया।

• क्या जाँचा जाता है? जाँचता है कि FTSO या FDC signature ने reward grace period चूका है।
• यह क्यों महत्वपूर्ण है? हस्ताक्षर शुरू होने के बाद 10 सेकंड की छूट अवधि में आए हस्ताक्षरों को हमेशा पुरस्कार मिलता है। बाद के हस्ताक्षर तभी गिने जाते हैं जब वे अंतिम रूप दिए जाने से पहले पहुँचें, जो आम तौर पर जल्दी होता है।
• आम कारण: धीमा RPC या इंडेक्सर, व्यस्त होस्ट या हस्ताक्षर सबमिट पते पर कतार में लगे लेनदेन।
• क्या करें? लॉग में हस्ताक्षर शुरू होने के समय और अपने हस्ताक्षर लेनदेन की तुलना करें तथा RPC प्रतिक्रिया समय और होस्ट का लोड जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

FDC प्रकटीकरण उल्लंघन

बिटवोट में सहमति शामिल है लेकिन मान्य हस्ताक्षर नहीं है।

• क्या जाँचा जाता है? analyzer का FDC reveal offence बताता है: bitvote consensus कवर करता है पर valid signature नहीं है।
• यह क्यों महत्वपूर्ण है? जब आपका bitvote सहमति को कवर करता है, तो आपसे उससे बने Merkle root पर हस्ताक्षर की अपेक्षा होती है। एनालाइज़र वैध हस्ताक्षर न होने को FDC उल्लंघन मानता है और दंड आपके युग के पुरस्कार घटा सकते हैं।
• आम कारण: bitvote के बाद FDC हस्ताक्षर चरण विफल हुआ, अक्सर verifier की प्रतिक्रियाएँ न मिलने और Merkle ट्री न बन पाने के कारण।
• क्या करें? बताए गए राउंड के लिए FDC क्लाइंट और verifier की स्वास्थ्य स्थिति तथा submitSignatures लेनदेन जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

monitored submission phases में failed transactions।

असफल लेनदेन

सबमिशन का एक चरण विफल हुआ।

• क्या जाँचा जाता है? निगरानी के पाँच submission phases में failed transaction बताता है।
• यह क्यों महत्वपूर्ण है? रिवर्ट हुए सबमिशन में gas खर्च होती है और उसका डेटा दर्ज नहीं होता, इसलिए राउंड में वह चरण छूटा हुआ माना जाता है।
• आम कारण: एक पते पर दो क्लाइंट से nonce टकराव, कम gas, वर्तमान युग के लिए अपंजीकृत प्रेषक पता या प्रोटोकॉल अपग्रेड के बाद कॉन्ट्रैक्ट रिवर्ट।
• क्या करें? बताया गया लेनदेन एक्सप्लोरर में खोलें, रिवर्ट का कारण पढ़ें और सुनिश्चित करें कि हर सबमिट पता केवल एक क्लाइंट उपयोग करता है।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

signing weight और बीते blocks के सापेक्ष Fast Updates activity।

Fast Updates निष्क्रियता

निष्क्रियता सांख्यिकीय रूप से असंभावित होने पर अलर्ट। ब्लॉक संख्या चेतावनी डिफॉल्ट रूप से बंद है।

• क्या जाँचा जाता है? signing weight और बीते blocks से Fast Updates न आने की modeled probability को threshold से मिलाता है। वैकल्पिक चेतावनी epoch के 1% blocks पर है।
• यह क्यों महत्वपूर्ण है? Fast Updates (ब्लॉक विलंब वाले feeds) Minimal Conditions का हिस्सा हैं: हर रिवॉर्ड युग में आपको अपने अपेक्षित अपडेट के कम से कम 80% सबमिट करने होंगे, जब तक आपका भार कुल के 0.2% से कम न हो।
• आम कारण: Fast Updates क्लाइंट बंद हो गया, उसके खातों में gas के लिए धन समाप्त हो गया (“insufficient funds”) या sortition कुंजी पंजीकृत नहीं है।
• क्या करें? Fast Updates क्लाइंट के लॉग और सभी Fast Updates खातों के बैलेंस जाँचें। कम भार होने पर चयन के बीच लंबे अंतर सामान्य हैं।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• संभावना की सीमा: डिफ़ॉल्ट 1E-7 (1E-15–0.1)। कम probability threshold Fast Updates inactivity के मजबूत सांख्यिकीय प्रमाण माँगता है।
• ब्लॉक संख्या चेतावनी चालू करें: डिफ़ॉल्ट बंद। बिना updates के blocks epoch के 1% पर हों तो भी चेतावनी; default बंद।

अगली epoch registration और active signing policy membership।

अगले युग का पंजीकरण

तय समय के बाद भी पंजीकरण लंबित होने पर एक अलर्ट।

• क्या जाँचा जाता है? registration खुलने के निर्धारित विलंब बाद अगली reward epoch का registration गायब है या नहीं जाँचता है।
• यह क्यों महत्वपूर्ण है? रिवॉर्ड युग के लिए पंजीकरण चूकने का अर्थ है पूरे युग में कोई भागीदारी और कोई FSP पुरस्कार नहीं, और आपके passes शून्य हो जाते हैं।
• आम कारण: सिस्टम क्लाइंट 30 मिनट की पंजीकरण अवधि में नहीं चल रहा था, पंजीकरण लेनदेन विफल हुआ या entity के किसी पते पर धन कम था।
• क्या करें? सिस्टम क्लाइंट के लॉग में “Voter … registered for epoch …” खोजें और सुनिश्चित करें कि क्लाइंट पूरी पंजीकरण अवधि में चलता रहे; पंजीकरण केवल तभी संभव है।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• देरी (मिनट): डिफ़ॉल्ट 15 (1–1,440)। registration खुलने के इतने मिनट बाद missing registration की चेतावनी।

Signing policy सदस्यता

Identity सक्रिय signing policy में नहीं है।

• क्या जाँचा जाता है? जाँचता है कि identity active signing policy में नहीं है।
• यह क्यों महत्वपूर्ण है? सक्रिय signing policy की entities ही वर्तमान रिवॉर्ड युग में सबमिट, हस्ताक्षर और पुरस्कार अर्जित कर सकती हैं।
• आम कारण: इस युग का पंजीकरण छूट गया या सफल नहीं हुआ।
• क्या करें? अब वर्तमान युग में शामिल नहीं हो सकते। सुनिश्चित करें कि अगला पंजीकरण सफल हो और पिछली पंजीकरण अवधि के लॉग जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

transactions वाली provider operational addresses के native funds।

कम परिचालन बैलेंस

Submit, signatures और signing policy पतों के नेटिव बैलेंस की हर घंटे जाँच।

• क्या जाँचा जाता है? cached operational native balances को thresholds से जाँचता है; read failure recovery नहीं साबित करता।
• यह क्यों महत्वपूर्ण है? कम native funds operational transactions के gas को रोक सकते हैं।
• आम कारण: Gas खर्च या outgoing transfers ने operational address का balance घटाया हो सकता है।
• क्या करें? भरने से पहले कम balance वाला address और recent transactions देखें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• इससे नीचे चेतावनी (FLR/SGB): डिफ़ॉल्ट 25 (0.001–10,00,000)। पढ़ा जा सकने वाला native balance इस राशि से कम हो तो चेतावनी।
• इससे नीचे गंभीर (FLR/SGB): डिफ़ॉल्ट 5 (0–10,00,000)। इस राशि से नीचे low-balance alert critical; warning threshold से अधिक नहीं।

monitoring data की उपलब्धता और नवीनता।

निगरानी की उपलब्धता

हमेशा चालू। विश्लेषक या परिणाम पुराने होने पर प्रदाता के अलर्ट रुकते हैं।

• क्या जाँचा जाता है? analyzer हमेशा जाँचता है। गायब, failed या दस मिनट से पुराने run/round data पर provider evaluation रुकता है।
• यह क्यों महत्वपूर्ण है? पुराना monitoring provider की स्थिति विश्वसनीय ढंग से नहीं जाँच सकता।
• आम कारण: Analyzer बंद, विफल या पूर्ण rounds से वंचित हो सकता है।
• क्या करें? Analyzer status, आखिरी run और indexed rounds की नवीनता जाँचें।
• सिग्नल सक्रिय: हमेशा चालू
• रिकवरी सूचना भेजें: चालू

observed FTSO/FDC warnings, official Minimal Conditions निर्णय से अलग।

Anchor पूर्व चेतावनी

देखी गई सफलता दर सीमा से कम है; यह आधिकारिक पात्रता निर्णय नहीं है।

• क्या जाँचा जाता है? पर्याप्त recent samples पर window का FTSO anchor hit rate जाँचता है। शून्य signing weight पर लागू नहीं।
• यह क्यों महत्वपूर्ण है? आधिकारिक रूप से, हर रिवॉर्ड युग के 80% वोटिंग राउंड में anchor-feed अनुमान माध्यिका से 0.5% के भीतर होने चाहिए। यह विंडो शुरुआती संकेतक है, आधिकारिक परिणाम नहीं।
• आम कारण: कम भागीदारी, कनेक्शन टूटना या अधूरे अवलोकन माप को घटा सकते हैं।
• क्या करें? provider या validator की जाँच से पहले window, sample count और source की नवीनता जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• इससे नीचे चेतावनी (%): डिफ़ॉल्ट 80% (1%–100%)। पर्याप्त recent observations पर इस प्रतिशत से नीचे चेतावनी; recovery दो percentage points ऊपर, अधिकतम 100%।
• समयावधि: डिफ़ॉल्ट 2 घंटे। घंटों में observation window चुनें; पूरी reward epoch का assessment नहीं।
• न्यूनतम अवलोकन: डिफ़ॉल्ट 40 (10–240)। प्रतिशत जाँचने से पहले कम से कम इतने observations चाहिए।

FDC पूर्व चेतावनी

देखी गई भागीदारी सीमा से कम है। बिना सहमति वाले दौर शामिल नहीं हैं।

• क्या जाँचा जाता है? पर्याप्त recent samples पर consensus rounds में FDC participation जाँचता है; बिना consensus और zero weight बाहर हैं।
• यह क्यों महत्वपूर्ण है? आधिकारिक रूप से FDC के लिए हर रिवॉर्ड युग के 60% वोटिंग राउंड में सफल भागीदारी (सही Merkle root) आवश्यक है। यहाँ आपकी सीमा पहले चेतावनी दे सकती है।
• आम कारण: कम भागीदारी, कनेक्शन टूटना या अधूरे अवलोकन माप को घटा सकते हैं।
• क्या करें? provider या validator की जाँच से पहले window, sample count और source की नवीनता जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• इससे नीचे चेतावनी (%): डिफ़ॉल्ट 80% (1%–100%)। पर्याप्त recent observations पर इस प्रतिशत से नीचे चेतावनी; recovery दो percentage points ऊपर, अधिकतम 100%।
• समयावधि: डिफ़ॉल्ट 2 घंटे। घंटों में observation window चुनें; पूरी reward epoch का assessment नहीं।
• न्यूनतम अवलोकन: डिफ़ॉल्ट 40 (10–240)। प्रतिशत जाँचने से पहले कम से कम इतने observations चाहिए।

observed P-chain connectivity और registered NodeID validator membership।

वैलिडेटर कनेक्टिविटी

कई P-chain दृष्टिकोण; समानांतर सत्यापन तक चेतावनी बंद है।

• क्या जाँचा जाता है? कई P-chain viewpoints से observed connectivity जाँचता है, official Uptime नहीं। default में बंद।
• यह क्यों महत्वपूर्ण है? स्टेकिंग के लिए हर रिवॉर्ड युग में कुल 80% अपटाइम आवश्यक है। यह अवलोकित कनेक्टिविटी संकेत है, आधिकारिक अपटाइम नहीं।
• आम कारण: कम भागीदारी, कनेक्शन टूटना या अधूरे अवलोकन माप को घटा सकते हैं।
• क्या करें? provider या validator की जाँच से पहले window, sample count और source की नवीनता जाँचें।
• सिग्नल सक्रिय: बंद
• रिकवरी सूचना भेजें: चालू
• इससे नीचे चेतावनी (%): डिफ़ॉल्ट 80% (1%–100%)। पर्याप्त recent observations पर इस प्रतिशत से नीचे चेतावनी; recovery दो percentage points ऊपर, अधिकतम 100%।
• समयावधि: डिफ़ॉल्ट 2 घंटे। घंटों में observation window चुनें; पूरी reward epoch का assessment नहीं।
• न्यूनतम अवलोकन: डिफ़ॉल्ट 40 (10–240)। प्रतिशत जाँचने से पहले कम से कम इतने observations चाहिए।

वैलिडेटर सूचीबद्ध नहीं

कोई पंजीकृत NodeID वर्तमान वैलिडेटर नहीं है। अनुपस्थित या समाप्त स्टेक जाँचें। NodeID न होने पर लागू नहीं।

• क्या जाँचा जाता है? सभी registered NodeIDs current validator set से निश्चित रूप से गायब हों तभी चेतावनी। अज्ञात result या NodeIDs न होना प्रमाण नहीं।
• यह क्यों महत्वपूर्ण है? जो नोड सक्रिय वैलिडेटर नहीं है उसे स्टेकिंग पुरस्कार नहीं मिलते, और स्टेकिंग Minimal Condition में हर रिवॉर्ड युग में कुल 80% अपटाइम आवश्यक है।
• आम कारण: वैलिडेटर की स्टेक अवधि समाप्त हो गई, नोड कभी वैलिडेटर के रूप में जोड़ा ही नहीं गया या entity से जुड़ा NodeID बदल गया।
• क्या करें? नोड की स्टेक समाप्ति का समय जाँचें, आवश्यकता पर स्टेक नवीनीकृत करें और अपनी identity से जुड़े NodeID की पुष्टि करें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू

provider addresses के personal unclaimed rewards, epoch अनुसार।

बिना दावे वाले व्यक्तिगत पुरस्कार

प्रति युग प्रमाणों से सत्यापित दावा योग्य DIRECT/FEE पुरस्कारों का एक सारांश। डेलिगेटर पूल शामिल नहीं हैं।

• क्या जाँचा जाता है? हर reward epoch में minimum से अधिक personal direct और fee unclaimed rewards एक बार बताता है; threshold तक घटने पर recovery।
• यह क्यों महत्वपूर्ण है? FSP पुरस्कार 25 रिवॉर्ड युग (लगभग तीन महीने) के बाद समाप्त हो जाते हैं; तब क्लेम न किए गए प्रत्यक्ष और शुल्क पुरस्कार खो जाते हैं।
• आम कारण: Rewards claimable हुए या claim अभी cached snapshot में नहीं दिखा।
• क्या करें? Rewards view में epoch, राशि और claim status जाँचें।
• सिग्नल सक्रिय: चालू
• रिकवरी सूचना भेजें: चालू
• न्यूनतम राशि (FLR/SGB): डिफ़ॉल्ट 1 (0–1,00,00,00,000)। personal unclaimed rewards इस native-token राशि से अधिक हों तभी alert।