نظرة عامة

FlareWatch هو تطبيق Next.js يراقب ويتتبع مراكز Flare Network — الرهن والتفويض والمكافآت والعائد. الحقيقة المعمارية الأساسية هي أنه للقراءة فقط: لا توجد قاعدة بيانات خلفية تحتفظ بالحالة المالية للمستخدم، لا توجد مسار توقيع للمعاملات، ولا يوجد وصول برمجي لمفاتيح المستخدم. يتم الحصول على جميع بيانات المركز من بنية Flare الموجودة على السلسلة في وقت الطلب.

اتصال المحفظة (Sign-In-With-Ethereum) موجود فقط لتحديد عنوان السلسلة المراد الاستعلام عنه. لا يصرح بإجراءات على السلسلة لأن التطبيق ليس لديه إجراءات على السلسلة للتصريح بها.

ما الذي يقرأه FlareWatch وأين منه

يتم حل كل عنوان عقد يستخدمه FlareWatch في وقت التشغيل من FlareContractRegistry، سجل عناوين Flare الأساسي الموجود على السلسلة (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). عندما تنقل حوكمة Flare عقداً، يلتقط FlareWatch العنوان الجديد في الجلسة التالية دون تغيير الكود.

مصادر البيانات بترتيب الأولوية:

على السلسلة (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — الحقيقة الأساسية للأرصدة والمراهنة والمكافآت القابلة للمطالبة والأسعار.
Flaremetrics API — بيانات المدقق ومزود FTSO التي تكون باهظة الثمن للحساب على جانب العميل.
CoinGecko — بيانات الأسعار بعملات متعددة وقيمة السوق.
Flare Block Explorer — البحث عن المعاملات التاريخية لسجلات الضرائب وتصنيف المكافآت.

تدفق البيانات متعدد الطبقات

يفرض التطبيق قاعدة طبقية صارمة في اتجاه واحد:

services → stores → hooks → components → pages

الطبقة	المسؤولية
الخدمات	منطق العمل وجلب البيانات. وظائف غير متزامنة خالصة. بدون React.
المتاجر	الحالة التفاعلية (Zustand). تخزين البيانات، بدون جلب.
خطافات	طبقة الربط. استدعاء الخدمات والكتابة إلى المخازن. بدون منطق تجاري.
المكونات	القراءة من المخازن عبر المحددات. تقديم واجهة المستخدم. عدم الجلب أبداً.
الصفحات	التركيب. ترتيب مكونات الميزات.

التأثير العملي هو أن الجلب والاشتقاق والعرض لكل منها منزل واحد. يشترك المكون الذي يحتاج إلى بيانات المدقق في حالة المدقق — فهو لا يستدعي API Flaremetrics بنفسه.

تدفقات المكافآت

تتتبع FlareWatch أربع تدفقات مكافآت مستقلة. معاملة أي من هذه كمجموعة واحدة يسبب سوء حساب عائد كبير، وهذا هو السبب في الحصول على كل منها والحساب بشكل منفصل.

التدفق	الإيقاع	انتهاء الصلاحية
مكافآت تفويض FTSO	كل حقبة مكافآت (~3.5 أيام)	~87.5 days
مدير مكافآت التحقق (VRM)	كل 4 حقب مكافآت (~14 يوم)	أبداً
الرهن المرآة (P-Chain → FSP)	كل حقبة مكافآت (~3.5 أيام)	~87.5 days
FlareDrop	منتهية	—

رأس مال حصة P-Chain يتم إرجاعه عند فك القفل وليس بمثابة تدفق مكافآت، على الرغم من ظهوره في أرصدة الحسابات.

تقدير العائد

يستخدم FlareWatch نموذج عائد ثلاثي المستويات. يتم وضع علامة على كل مستوى في الواجهة بحيث يفهم المستخدم دقة التقدير.

المستوى 1 — الحقيقة الأساسية. المكافآت القابلة للمطالبة على السلسلة عبر عقد RewardManager. هذه قيمة حقيقية موجودة على السلسلة، في انتظار المطالبة بها.
المستوى 2 — مدفوع بالبيانات. عندما تكون المبالغ القابلة للمطالبة صفراً، يستخدم FlareWatch متوسط آخر خمس مطالبات من سجل معاملات المحفظة كتقدير للحقبة التالية.
المستوى 3 — خيار الصيغة. عندما لا يكون هناك سجل مطالبات، wflrBalance × FTSO_DELEGATION_APR / epochsPerYear يتنبأ بمعدل رياضي من حالة الشبكة الحالية.

يعرض FlareWatch عائد سنوي واحد APY لرهن Flare الأصلي وتفويض FTSO: مدفوعات حقبة المكافآت الأخيرة لكل FLR بعد الرسوم، مسنوية (× 365 / 3.5 أيام). لا يتم تركيبه، لأن مكافآت Flare يجب المطالبة بها قبل أن تتمكن من الكسب، ويطابق الرقم الذي تنشره مستكشفات Flare الأخرى. مواقع DeFi التي تركب تلقائيًا (مثل Sceptre sFLR) تعرض عائدها السنوي الخاص بالبروتوكول.

نموذج الأمان — لمحة سريعة

يتم تغطية الأمان بالتفصيل على صفحة ميزات الأمان. النقاط الرئيسية هي:

هوية قائمة على المحفظة، وليس الحسابات. لا كلمات مرور، لا هوية مرتبطة بالبريد الإلكتروني. يحدد اتصال المحفظة العنوان الذي سيتم الاستعلام عنه.
للقراءة فقط حسب التصميم. التطبيق لا يحتفظ بالمفاتيح أبداً، لا يوقع المعاملات أبداً، ولا يتفاعل مع العقود الذكية نيابة عن المستخدم.
إلغاء جلسة العمل من جانب الخادم. يتم فرض تسجيل الخروج على الخادم، بحيث تتوقف ملفات تعريف الجلسة المسروقة عن العمل فور تسجيل خروج المستخدم — وليس عند انتهاء صلاحيتها بعد 24 ساعة.
التحكم في ملكية المحفظة لكل محفظة. يتحقق كل مسار API الذي يقرأ أو يكتب حالة لكل محفظة من أن المحفظة المصرح لها تطابق المحفظة المستهدفة. لا توجد مسارات إعادة تجاوز مسؤول لبيانات المستخدم.
رؤوس HTTP متعددة الطبقات. يتم شحن Strict-Transport-Security، وContent-Security-Policy مقيدة، وX-Frame-Options DENY، وPermissions-Policy محكمة في كل استجابة.

الاختبار

يتم اختبار التطبيق كما لو أن كل انحدار سيحدث — لأن نوع الانحدارات التي تهتم بها FlareWatch (الحسابات المالية التي تكون خاطئة بشكل دقيق) تكون صامتة عند نشرها. مناطق التغطية:

رياضيات العائد السنوي للرهن وتفويض FTSO.
تنسيق العملة عبر عدة دول.
تنسيق كمية FLR والنسبة المئوية والتاريخ.
منطق فئات الألوان الحدية (حتى لا يتحول التسليم "الأخضر" بصمت إلى البرتقالي).
حسابات مواعيد الضرائب عبر الدول.

يتم تشغيل مجموعة الاختبار في CI في كل push.

البنية التحتية

يعمل FlareWatch على Vercel. الواجهة الأمامية، وعمليات cron التي تدفئ ذاكرات التخزين المؤقت، وخزن القيمة الرئيسية المدعوم بـ Redis الذي يحتفظ بتلك ذاكرات التخزين المؤقت — كلها تشارك المنصة. الاختيار مقصود: صفر تكلفة تشغيلية مع التوسع، وسطح النشر بأكمله قابل للتدقيق من خلال موفر واحد.

طبقة services/ مستقلة عن الإطار بقصد. إذا هاجرت FlareWatch في أي وقت من Vercel، فإن خدمات منطق الأعمال هي دوال غير متزامنة نقية وتتحرك معها.

قراءة إضافية

ميزات الأمان — المصادقة والتفويض وتحديد المعدل والرؤوس وسجل التدقيق.
نظرة عامة على الضمانات — القواعد المعمارية التي يفرضها FlareWatch على نفسه، والسبب وراءها.