सारांश

FlareWatch एक Next.js एप्लिकेशन है जो Flare Network की स्थितियों की निगरानी और ट्रैकिंग करता है — staking, प्रतिनिधिमंडन, पुरस्कार, और उपज। परिभाषित आर्किटेक्चर तथ्य यह है कि यह केवल-पढ़ने वाली है: उपयोगकर्ता वित्तीय स्थिति रखने वाली कोई बैकएंड डेटाबेस नहीं है, कोई लेनदेन-हस्ताक्षर पथ नहीं है, और उपयोगकर्ता कुंजियों के लिए कोई प्रोग्रामेटिक पहुँच नहीं है। सभी स्थिति डेटा अनुरोध समय पर Flare के ऑन-चेन बुनियादी ढांचे से प्राप्त किया जाता है।

Wallet कनेक्शन (Sign-In-With-Ethereum) केवल यह पहचानने के लिए मौजूद है कि कौन सा ऑन-चेन पता क्वेरी करना है। यह ऑन-चेन कार्यों को अधिकृत नहीं करता क्योंकि एप्लिकेशन के पास अधिकृत करने के लिए कोई ऑन-चेन कार्य नहीं है।

FlareWatch क्या पढ़ता है, और कहाँ से

FlareWatch द्वारा उपयोग किए जाने वाले प्रत्येक contract address को रनटाइम पर FlareContractRegistry से resolve किया जाता है, जो Flare का canonical on-chain address registry है (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019)। जब Flare governance किसी contract को स्थानांतरित करता है, तो FlareWatch बिना कोड परिवर्तन के अगले सत्र पर नया address ले लेता है।

डेटा स्रोत, प्राथमिकता क्रम में:

On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — शेष राशि, stakes, claim योग्य rewards, और कीमतों के लिए ground truth।
Flaremetrics API — validator और FTSO provider metadata जो client-side पर compute करने के लिए बहुत महंगा है।
CoinGecko — बहु-currency मूल्य डेटा और market cap।
Flare Block Explorer — tax records और reward classification के लिए historical transaction lookups।

स्तरीय डेटा प्रवाह

एप्लिकेशन एक कड़े एक-दिशा layering नियम को enforce करता है:

services → stores → hooks → components → pages

परत	जिम्मेदारी
सेवाएँ	Business logic और data fetching। Pure async functions। कोई React नहीं।
स्टोर्स	Reactive state (Zustand)। Data hold करें, कोई fetching नहीं।
हुक्स	वायरिंग लेयर। सेवाएं कॉल करें, स्टोर में लिखें। कोई व्यावसायिक तर्क नहीं।
घटक	सेलेक्टर्स के माध्यम से स्टोर से पढ़ें। UI रेंडर करें। कभी भी फ़ेच न करें।
पृष्ठ	संरचना। सुविधा घटकों को व्यवस्थित करें।

व्यावहारिक प्रभाव यह है कि फ़ेचिंग, व्युत्पत्ति, और रेंडरिंग के प्रत्येक के पास एक एकल घर है। एक घटक जिसे वेलिडेटर डेटा की आवश्यकता है, वेलिडेटर स्थिति की सदस्यता लेता है — यह कभी भी स्वयं Flaremetrics API को कॉल नहीं करता है।

पुरस्कार प्रवाह

FlareWatch चार स्वतंत्र पुरस्कार प्रवाह को ट्रैक करता है। इनमें से किसी को भी एक एकल पूल के रूप में मानने से महत्वपूर्ण यील्ड गणना त्रुटि होती है, यही कारण है कि प्रत्येक को अलग से सोर्स और कंप्यूट किया जाता है।

प्रवाह	संचरण	समापन
FTSO प्रतिनिधिमंडन पुरस्कार	प्रत्येक पुरस्कार epoch (~3.5 दिन)	~87.5 days
वेलिडेशन रिवार्ड मैनेजर (VRM)	हर 4 पुरस्कार एपोक (~14 दिन)	कभी नहीं
मिरर्ड-स्टेक (P-Chain → FSP)	प्रत्येक पुरस्कार epoch (~3.5 दिन)	~87.5 days
FlareDrop	संपन्न	—

P-Chain स्टेक प्रिंसिपल अनलॉक करने पर वापस किया जाता है और यह एक पुरस्कार स्ट्रीम नहीं है, भले ही यह खाता शेष में दिखाई दे।

उपज अनुमान

FlareWatch एक तीन-स्तरीय यील्ड मॉडल का उपयोग करता है। प्रत्येक स्तर UI में लेबल किया गया है ताकि उपयोगकर्ता अनुमान की सटीकता को समझ सके।

स्तर 1 — वास्तविक सत्य। RewardManager अनुबंध के माध्यम से ऑन-चेन दावा करने योग्य पुरस्कार। यह वास्तविक मूल्य है जो ऑन-चेन पर बैठा है, दावा किए जाने की प्रतीक्षा कर रहा है।
स्तर 2 — डेटा-संचालित। जब दावा करने योग्य शून्य हो, FlareWatch वॉलेट के लेनदेन इतिहास से पिछले पांच दावों के माध्यिका का उपयोग अगले-एपोक अनुमान के रूप में करता है।
स्तर 3 — सूत्र फॉलबैक। जब कोई दावा इतिहास मौजूद नहीं है, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear वर्तमान नेटवर्क स्थिति से गणितीय दर का अनुमान लगाता है।

FlareWatch नेटिव Flare स्टेकिंग और FTSO डेलीगेशन के लिए एक एकल APY दिखाता है: नवीनतम रिवार्ड एपोक के पेआउट प्रति FLR फीस के बाद, वार्षिकीकृत (× 365 / 3.5 दिन)। यह कंपाउंडेड नहीं है, क्योंकि Flare रिवार्ड्स को क्लेम किया जाना चाहिए इससे पहले कि वे कमा सकें, और यह अन्य Flare एक्सप्लोरर्स द्वारा प्रकाशित आंकड़े से मेल खाता है। DeFi पोजीशन्स जो ऑटो-कंपाउंड करते हैं (जैसे Sceptre sFLR) अपना स्वयं का प्रोटोकॉल APY दिखाते हैं।

सुरक्षा मॉडल — एक नज़र में

सुरक्षा का विवरण सुरक्षा विशेषताएं पृष्ठ पर दिया गया है। मुख्य बिंदु हैं:

वॉलेट-आधारित पहचान, खाते नहीं। कोई पासवर्ड नहीं, कोई ईमेल-लिंक्ड पहचान नहीं। वॉलेट कनेक्शन पहचानता है कि कौन सा पता क्वेरी करना है।
डिज़ाइन द्वारा केवल-पढ़ने के लिए। ऐप कभी कुंजियां नहीं रखता, कभी लेनदेन पर हस्ताक्षर नहीं करता, और कभी उपयोगकर्ता की ओर से स्मार्ट अनुबंधों के साथ इंटरैक्ट नहीं करता।
सर्वर-साइड सत्र निरस्तता। साइन-आउट को सर्वर पर लागू किया जाता है, इसलिए चोरी किया गया सत्र कुकी तुरंत काम करना बंद कर देती है जब उपयोगकर्ता साइन आउट करता है — इसके 24 घंटे की एक्सपायरी पर नहीं।
प्रति-वॉलेट स्वामित्व गेटिंग। हर API मार्ग जो प्रति-वॉलेट स्थिति को पढ़ता या लिखता है, सत्यापित करता है कि प्रमाणित वॉलेट लक्ष्य वॉलेट से मेल खाता है। उपयोगकर्ता डेटा के लिए कोई व्यवस्थापक ओवरराइड पथ नहीं है।
गहरी सुरक्षा HTTP हेडर। Strict-Transport-Security, प्रतिबंधक Content-Security-Policy, X-Frame-Options DENY, और कड़ा Permissions-Policy प्रत्येक प्रतिक्रिया के साथ भेजे जाते हैं।

परीक्षण

एप्लिकेशन को इस तरह परीक्षित किया जाता है जैसे कि हर प्रतिगमन होने वाला है — क्योंकि FlareWatch जिन प्रतिगमनों की परवाह करता है (वित्तीय गणना सूक्ष्मता से गलत होना) शांति से भेजे जाते हैं। कवरेज क्षेत्र:

स्टेकिंग और FTSO डेलीगेशन APY गणित।
कई क्षेत्राधिकार में मुद्रा स्वरूपण।
FLR राशि, प्रतिशत, और दिनांक स्वरूपण।
थ्रेसहोल्ड रंग-बैंड तर्क (ताकि एक "हरी" डिलीवरी शांति से पीले रंग में न फ़्लिप हो)।
क्षेत्राधिकार में कर समय सीमा गणना।

परीक्षण सूट हर पुश पर CI में चलता है।

बुनियादी ढांचा

FlareWatch Vercel पर चलता है। फ्रंटएंड, क्रॉन जॉब्स जो कैश को गर्म करते हैं, और Redis-समर्थित की-वैल्यू स्टोर जो उन कैश को रखता है सभी प्लेटफॉर्म साझा करते हैं। यह पसंद जानबूझकर है: स्केल पर शून्य परिचालन लागत, और संपूर्ण तैनाती सतह एक प्रदाता के माध्यम से ऑडिट योग्य है।

services/ परत जानबूझकर फ्रेमवर्क-स्वतंत्र है। अगर FlareWatch कभी Vercel से माइग्रेट हो जाता है, तो व्यावसायिक-तर्क सेवाएं शुद्ध async कार्य हैं और इसके साथ स्थानांतरित होती हैं।

अतिरिक्त पठन

सुरक्षा विशेषताएँ — प्रमाणीकरण, प्राधिकरण, दर सीमा, हेडर, ऑडिट इतिहास।
सुरक्षा उपाय अवलोकन — आर्किटेक्चरल नियम जो FlareWatch अपने आप पर लागू करता है, और क्यों।