منهجية درجة المدقق

إصدار الخوارزمية: v4.8 · آخر تحديث: 2026-08-19

يعين FlareWatch لكل مدقق P-Chain درجة مركبة من 0–100 عبر 9 أبعاد. الرياضيات حتمية، والمدخلات هي بيانات السلسلة العامة [Flare Explorer] [FSE] [Flaremetrics]، والخوارزمية نفسها تنطبق على كل مدقق في الشبكة — بما في ذلك عقدة المدقق الخاصة بـ FlareWatch، التي تُسجل بهذه الدالة بالضبط بدون معاملة خاصة. توثق هذه الصفحة كل بُعد وحد أدنى حتى يتمكن المشغلون والمراهنون من رؤية كيفية حساب الدرجة بالضبط ولماذا تم اختيار كل قيمة. كل مطالبة هنا ترتبط بمصدرها الأساسي في السلسلة أو المصدر الأعلى — انظر المصادر والمراجع في الأسفل.

النطاق: توثق هذه الصفحة درجة المدقق — ما تراه في وضع الرهن على صفحة المدققين (تفويض FLR إلى مدقق P-Chain للحصول على مكافآت VRM + MIRROR). تستخدم درجة موفر FTSO الموضحة في وضع التفويض (تفويض WFLR إلى موفري بيانات FTSO) خوارزمية منفصلة بـ 13 بُعد تركز على أداء موفر البيانات — الدقة، مشاركة بروتوكول V2، إلخ. إنها أدوار مختلفة في السلسلة بمكافآت مختلفة، يتم تسجيلها بشكل منفصل. انظر منهجية درجة موفر FTSO لجانب التفويض.
لا يوجد مكافئ SGB: يطبق هذا التسجيل على مدققي Flare P-Chain فقط. مجموعة مدققي Songbird P-Chain مقيدة بالكيانات المعتمدة من Flare Foundation، لذلك فإن تفويض SGB P-Chain بالتجزئة نادر وتبويب الرهن خاص بـ FLR فقط. لا يوجد تبديل FLR / SGB في وضع الرهن. بخصوص تفويض FTSO للـ SGB انظر منهجية درجة موفر FTSO، التي تغطي كلا السلسلتين.
كيفية حساب العائد السنوي — ما تكسبه فعلاً

العائد السنوي على جدول الرهن هو معدل الجملة الذي يحصل عليه المفوّض — رقم واحد بدون حساب عقلي. يتم قياسه من سكريبتات مكافآت Flare (المدفوعات الفعلية وليس الصيغة)، بخصم من رسم المدقق، وينتقل كل حقبة مع المكافآت الحقيقية. في كل مكان على FlareWatch، العائد السنوي يعني بعد الرسم والعائد السنوي يعني قبله.

Total APR = Staking rewards (VRM) + MIRROR (FTSO-inflation share)
  • مكافآت الرهن (VRM) — حصة صافي المفوض من مكافآت التحقق = Σ دفع المفوض ÷ Σ مرهون (التقسيم الخاص بـ Flare؛ الرسم مخصوم بالفعل). لأن Flare تدفع بما يتناسب مع الحصة، فإن هذا موحد تقريباً في جميع أنحاء الشبكة ويختلف في الأساس حسب الرسم — الرسم الأقل يعني معدل تفويض أعلى.
  • MIRROR — حصة رهنك من تضخم FTSO، يُدفع في الأعلى، فقط على المدققين الذين يديرون مكدس FTSO نشط. يختلف حسب مشاركة FTSO للمدقق ويتم قياسه عبر أحدث epochs.

مقارنة مع Flare Systems Explorer؟ يعرض FSE ومستكشفات أخرى معدل التفويض فقط — لا يضيفون MIRROR — لذا يقرأ إجمالي العائد السنوي لدينا أعلى على أي مدقق نشط MIRROR (الفجوة بالضبط هي سطر MIRROR أعلاه). كلا الرقمين ~متوسطات زائدة من 8 حقب من نفس بيانات سكريبتات المكافآت، لذا يتأخر تغيير رسم المدقق في منتصف النافذة عن لقطة الرسم الحالي على أي موقع حتى يتقادم من خلال النافذة.

يظهر رقمان آخران في تلميح العائد السنوي وليس معدل المفوّض: الحد الأدنى النظري (إجمالي العائد السنوي للشبكة × (1 − الرسم)، الرهن فقط — يُستخدم كمحاولة أخيرة قبل وجود سجل مقاس كافي)، وعائد السند الذاتي للمشغل (عائد الرهن الخاص للمدقق، مضخم برسم الالتقاط — مقياس مشغل وليس ما تكسبه).

للنقاط: بعد Net Yield ينقط معدل تفويض VRM فقط، ويتم نقط MIRROR في بعده الخاص — لذا لا يتم عد MIRROR مرتين أبدًا، حتى لو تم تضمينه في إجمالي العائد السنوي المعروض.

فئات الدرجات
90+الفئة الأولى — أفضل ~10–20% من المشغلين. الملف الشخصي النموذجي: مدقق مكدس كامل + FTSO + FDC، رسم منخفض، نشط MIRROR، موثوقية FIP-10 متسقة، قاعدة مفوضين صحية، رابط ذاتي ذو مغزى. لا يلزم بُعد واحد — يصل المشغلون إلى الفئة الأولى بتجميع القوة عبر معظم الفئات.
80–89قوي — يلبي معظم المعايير الرئيسية؛ بُعد أو اثنين أقصر من الفئة الأولى.
70–79جيد — يلبي جميع معايير الأساس؛ بدون فجوات كبيرة.
60–69مقبول — قابل للاستخدام لكن غير متمايز.
<60دون الوسيط — فجوات كبيرة في بُعد أو أكثر. حقيقة رياضية، وليس حكماً على الجودة.
الأبعاد (المجموع 100)
وقت التشغيل20 نقاط كحد أقصى
ما هو: مزيج من وقت تشغيل RPC للـ P-Chain الفوري و نسبة أهلية وقت التشغيل التاريخي FIP-10 عبر epochs المكافآت الأخيرة.
كيف: منحنى RPC: ≥ 99.5% → 17 إلى 20. 99–99.5% → 13–17. 95–99% → 4–13. 90–95% → 0–4. < 90% → 0. يتم بعد ذلك ضرب النتيجة في uptimeReliability (epochsIncluded / epochsObserved عبر آخر 8 حقب مكافآت من بيانات سكريبتات المكافآت العامة — مجموعة حد الأدنى الكاملة من FIP-10 منذ الإصدار v4.2، وليس RPC-uptime وحده). أصلحت الإصدار v3.9 منحدراً معكوساً عند 95% بالضبط حيث أدى الانتقال من 99.94 → 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، لذلك سجل المنحنى للجميع بنفس الطريقة. نسبة الموثوقية هي إشارة سلسلة زمنية حقيقية: مدقق فشل في تلبية شروط FIP-10 الدنيا في 3 من 8 epochs الأخيرة لديه درجة موثوقية 62.5%، بغض النظر عما يقوله RPC الفوري حالياً. أقسى من أرضية بروتوكول FIP-10 بنسبة 80% عن قصد. يتم نشر بيانات الأهلية لكل epoch بواسطة Flare Foundation في ريبو سكريبتات المكافآت الخاصة بهم.
صافي العائد18 نقاط كحد أقصى
ما هو: معدل مكافأة الرهن الصافي من الرسم (VRM) الذي يتلقاه المفوض، مرتسى إلى وسيط الشبكة.
كيف: scoreAPR = معدل التفويض الصافي المقاس (delegationAPY: Σ delegatorRewardAmount / Σ مرهون، من سكريبتات Flare Foundation، آخر ~8 epochs) عند التوفر، وإلا baseAPR النظري = إجمالي × (1 − رسم). الدرجة = (scoreAPR / medianAPR) مرتسى: نسبة 0.6 → 0 نقاط، 1.0 (وسيط) → 12 نقاط، 1.2 → 18 نقاط. مهم: يسجل هذا البُعد معدل 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 المقاس مقابل theoretical gross×(1−fee))، لذلك المقارنة متطابقة — لم تعد مضخمة بـ 1/(1−fee) كما كانت عندما كان المدخل معدل إجمالي ما قبل الرسم (الخطأ '2×' المضاعف تقريباً). لأن Flare تدفع مكافآت التحقق بما يتناسب مع الحصة، فإن معدل تفويض VRM موحد تقريباً في جميع أنحاء الشبكة ويختلف في الأساس حسب الرسم — لذلك يعكس هذا البُعد في الأساس قدرة الرسم التنافسية وموثوقية التسليم (المدقق الذي يفتقد epochs يسلم أقل). يتم الاحتفاظ بـ MIRROR (الذي يختلف حسب مشاركة FTSO) عن قصد في بُعده الخاص لتجنب الاحتساب المزدوج.
معقولية الرسم7 نقاط كحد أقصى
ما هو: الحماية من الاستخراج فوق الحد الأدنى لرسوم البروتوكول، بتدرج خطي منحني سلس.
كيف: الرساء = الحد الأقصى(الحد الأدنى النشط الملاحظ فعلياً، حد رسوم البروتوكول للتحقق — 20% منذ تحديث Granite، 2026-07-14). أي رسم عند أو أقل من الرساء → 7 نقاط كاملة. فوقه، منحدر خطي مع ميول متزايدة الانحدار على مدى الـ 20 نقطة رسم التالية (رساء+5 → 6، رساء+10 → 4.5، رساء+15 → 2.5، رساء+20 → 0): التجاوزات الصغيرة تُعاقب بالكاد، والاستخراج يُعاقب بقسوة. قبل Granite كان الرساء 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 نقاط كحد أقصى
ما هو: يأخذ أعلى من إشارتين مستقلتين: أساس التحقق (ثقة الهوية) والأداء التشغيلية المشتقة من FTSO.
كيف: أساس التحقق: وصول الفئة المنسقة (+7) بطريقتين — إدخال KNOWN_VALIDATORS معتمد يدويًا أو الترقية التلقائية عبر السلوك الموضوعي (v3.10: 90+ يوماً لوحظ و 25+ مفوضين مجمعين للمشغل و ليس يتقلص حالياً و رابط ذاتي ≥ أرضية FIP-10). اسم مكتشف تلقائياً من Flaremetrics أو FSE → +3. غير موثق → 0. FTSO-derived: الاستيفاء الخطي درجة FTSO 50 → 4 نقاط حتى درجة FTSO 100 → 12 نقطة (أقل من 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() الحافز السيء المتمثل في "إسقاط FTSO لتحسين درجة FlareWatch الخاصة بك". يغلق المستوى المكتشف تلقائياً (+3) الانخفاض السابق 7→0 الذي أثر على المشغلين المسجلين لدى Flaremetrics أو FSE لكن لم يتم اختيارهم يدوياً بعد.
مشاركة MIRROR12 نقاط كحد أقصى
ما هو: ما إذا كان معرّف العقدة الخاص بالمُدقّق يسلّم فعلياً حصة تضخم FTSO للمُراهنين — النسبة التي تصل للمفوضين (تمرير الرسم) والكمية المسلّمة نسبة إلى الحقل منذ v4.6.
كيف: نشط → 10 × (1 − رسم/100). موقوف → 5 × تمرير. غير نشط (لا إشارة مشاركة في أي مكان) → 0. بدون بيانات (مُدقّق لم يتم ملاحظته فعلياً) → 5 × تمرير. v3.6 وسّعت إشارة 'نشط' لتشمل كلاً من أحداث RewardClaimed(claimType=3) على السلسلة و تخصيصات claimType=3 في JSON Merkle FSP الموثوق — إما واحد كافٍ. هذا يمسك المُدقّقين الذين تم تخصيص MIRROR لهم لكن لم يتم المطالبة بهم على السلسلة بعد (مثل مزودي التفويض الذاتي التي لا تُطلق حدث المطالبة القياسي في مسار التسوية). v4.6 مكافأة الحجم (أقصى +2، سقف البُعد 12): فقط للمُدقّقين النشطين في mirror، clamp((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. مُدقّق برسم 100% و 'نشط' يسلّم $0 للمفوضين؛ الدرجة تعكس ما يتلقاه المفوضون فعلياً، وليس فقط حالة الراية من جانب البروتوكول. مكافأة حجم v4.6 تسد نقطة عمياء: التمرير وحده قاس النسبة التي وصلت للمفوضين لكن ليس الكمية، لذا مُدقّق يدفع معدل MIRROR مسلّم أعلى بكثير لم يكسب ائتماناً إضافياً له. الآن يفعل — محدود، وفقط فوق الوسيط الشبكة.
ملف السعة7 نقاط كحد أقصى
ما هو: دالة خيمة تصل ذروتها عند الاستخدام الصحيح الحجم.
كيف: استخدام بنسبة 0٪ → 1.75. منحدر خطي يصل إلى 7 عند استخدام 70٪. منحدر خطي ينخفض إلى 5.25 عند 100٪ (مسقوف). أعيد تحجيمه في 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.
ثقة المجتمع11 نقاط كحد أقصى
ما هو: إشارات متعددة: عدد المفوضين + صحة توزيع الحصة + الأقدمية + التزام الضمان الذاتي للمشغل (نسبي ومطلق) + الاحتفاظ لمدة 30 يوماً + مسار الضمان الذاتي + تجميع المشغل متعدد العقد.
كيف: إشارة العد (الحد الأقصى 6، مُجمّع حسب المشغل v3.7): مُقَيَّس لوغاريتمياً [5، 500] مفوض → [0، 6]، مجموع عبر جميع العقد المعروفة للمشغل. تعديل التركيز (±1): صديقة للتجزئة متوسط حصة (<500K FLR) → +1، مركزة الحيتان (>50M FLR متوسط) → −1. علاوة الأقدمية (الحد الأقصى +1، محصنة من المسح v3.6): +0.5 عند 30 يوم ملاحظة، +1 عند 90+ يوم — ترجع للاعتماد على وجود الحقبة الزمنية للسكريبتات إذا تم مسح أول KV ملاحظ. جلد الضمان الذاتي في اللعبة (الحد الأقصى +2 / الحد الأدنى −1، ثنائي المحور v4.7): معتمد على الأفضل من الحصة النسبية أو الحجم المطلق — النسبية ≥10% → +2 / 5–10% → +1، والمطلق = min(1, selfBond ÷ 20M) × 2 يصل إلى التشبع عند أعلى عُشر الشبكة للضمان؛ تأخذ الإشارة max من الاثنين، لا تزال محدودة بـ +2. تحت حد FIP-10 (<1M FLR) → −1. الاحتفاظ (الحد الأقصى ±0.5، جديد v3.7): FLR المفوض +10% عبر 30 يوم → +0.5, −15% → −0.5. مسار الضمان الذاتي (الحد الأقصى ±0.5، جديد v3.7): ضمان ذاتي للمشغل +20% عبر 30 يوم → +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)
لماذا: الضمان الذاتي جلد في اللعبة هو إشارة عدالة حقيقية كنا نفتقدها — المدقق الذي لديه 10% من إجمالي الحصة كضمان ذاتي لديه حوافز متوازنة بشكل ملموس أكثر من المدقق الذي يعمل على الحد الأدنى FIP-10. يجعل v4.7 هذا ثنائي المحور: قراءة الضمان الذاتي فقط كنسبة عاقبت المشغلين الذين وضعوا حصة مطلقة كبيرة ثم اجتذبوا تفويضات، مما يخفف النسبة دون تقليل الالتزام الحقيقي — الضمان الذاتي 20M بنسبة مخففة سجل بنفس درجة ضمان فرعي-2M بتلك النسبة. تعتمد الإشارة الآن على الأفضل من الحصة النسبية أو الحجم المطلق، يصل الجانب المطلق إلى التشبع عند ضمان أعلى الشبكة لذا الحجم لا يمكنه ببساطة شراء الدرجة، مطابقة كيفية معاملة درجة مزود FTSO للضمان الذاتي بالفعل؛ حد +2 دون تغيير، لذا يمكن للمشغلين الكبار الملتزمين الآن الوصول إليه لكن السقف لم يتحرك. تكافئ الأقدمية المسارات الثابتة المثبوتة دون معاقبة الوافدين الجدد (علاوة صغيرة في الأعلى، ليست عقوبة تحت). مخاطر التركيز مهمة للمفوضين — المدقق الذي لديه حوت واحد بـ 50M FLR مختلف هيكلياً عن 50 تجزئة بـ 1M لكل منهما. إشارات المسار v3.7 الاثنتان تكافئ النمو العضوي والتزام المشغل المتزايد. الحد الأقصى المدمج هو 11 (مرفوع من 10 في v3.7 لتمويلهم)، لا إشارة واحدة تهيمن.
موثوقية التسليم10 نقاط كحد أقصى
ما هو: نسبة معدل التفويض الصافي المسلم بالفعل (VRM) مقابل خط الأساس النظري، مع عقوبة التباين للمدفوعات غير المتسقة. كلا الجانبين خالي من الرسم، لذا تقيس النسبة التسليم الفعلي — وليس الرسم.
كيف: نسبة التسليم الخطية متعددة التعريفات: 100٪+ → 10، 95٪ → 8، 90٪ → 6، 85٪ → 4، 80٪ → 2، <80٪ → منحدر خطي نحو 0. عقوبة التباين: معامل الاختلاف × 0.5، مسقوف عند −30٪. يمزج مثبط الثقة نحو محايد 5 عندما يكون حجم العينة < 3 فترات. خطي v3.9 عتبات سابقة محددة مسبقاً — الانحدارات الحدية تصل إلى نقطتين الآن سلسة.
// 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) نسبة العنوان الرئيسي تستخدم متوسطاً مرجحاً زمنياً أسياً (الفترات الأخيرة تحسب أكثر)، لذا المدقق الذي كان يسلم بشكل جيد لكن انزلق مؤخراً يعاقب بشكل صحيح؛ (2) عقوبة التباين تميز مسلمي 95٪ المتسقين عن المتذبذبين حول 95٪، لأن الأخيرين يحملان مزيداً من المخاطر للأصحاب الذين يهتمون بالعائد المتوقع.
الوقت المتبقي5 نقاط كحد أقصى
ما هو: أيام حتى انتهاء حصة المدقق على سلسلة P.
كيف: < 14 يوماً → 0 (غير متاح بشكل أساسي بموجب FIP-10). 14-30 يوماً → خطي 0→2. 30-60 يوماً → خطي 2→3. 60-120 يوماً → خطي 3→5. 120 يوماً+ → 5. خطي v3.9 عتبات سابقة محددة مسبقاً — الانحدارات الحدية (على سبيل المثال 13.99 يوماً → 0، 14 يوماً → 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 أيام اقتراح مختلف عن سنة واحدة. شدد v3.2 القاع: المدققون في غضون 14 يوماً من انتهاء الحصة لا يمكنهم قبول تفويضات جديدة (الحد الأدنى القفل FIP-10 هو 14 يوماً)، لذا هم في الواقع غير قابلين للسحب. الدرجة = 0 تميز "غير قابل للسحب الآن" عن "الإغلاق قريباً".
عقوبة الانقطاع النشط (v4.3)(خصم) نقاط كحد أقصى
ما هو: خصم ثابت موضوع على الأبعاد الموجبة عندما يفقد المدقق فترات مكافأة متعددة متتالية. مختلف عن مضاعف موثوقية الوقت المتماثل — يلتقط الانقطاعات النشطة، وليس عدم الاستقرار المزمن.
كيف: انظر إلى بادئة !eligible المتجاورة للمدقق في سجل cache:fsp-validator-participation (قائمة فترة newest-first من عقد nodes-data.json العامة للمكافآت-السكريبتات). 0–1 يفقد متتالي → 0 نقطة (ضمن التباين / فقدان عابر واحد). 2 متتالي → −3 نقطة (انقطاع نامٍ). 3 متتالي → −6 نقطة (مستدام — إهمال المشغل). 4+ متتالي → −10 نقطة (انقطاع موسع نشط). يتم حد الدرجة المركبة عند 0 بعد الخصم.
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 بالكامل على مضاعف موثوقية الوقت المتماثل — 5 يفقد مشتتة عبر 24 فترة تكلف نفس 5 يفقد متتالي. تلك إشارات مختلفة تشغيلياً. أخبر اليفقد المشتتة المفوضين عن عدم الاستقرار المزمن؛ يخبرهم التسلسل أن المدقق معطل الآن. حادثة Luganodes في 2026-05-14 — فترات متتالية متعددة مفقودة بينما كان المفوضون يلتزمون بملايين FLR بنشاط — كانت الحالة المحددة التي تعالجها إصدار v4.3: سطح إشارة الانقطاع النشط برصيد درجة أكثر حدة حتى يتمكن المفوضون من تجنب فشل في الرحلة قبل الالتزام. يتجنب المنحنى المرحلي الإفراط في الرد على الفقدان العابر الواحد (شائع) مع وضع علم حاد للتسلسل المستدام (نادر وله عواقب).
عقوبة الرسوم الشديدة (v4.5)(حتى −75% من النقاط) نقاط كحد أقصى
ما هو: خصم متناسب للرسوم التي تتجاوز نطاق بُعد الرسوم. ينتهي بُعد الرسوم عند 0/7 بمجرد تجاوز الرسم للمرساة بـ 20 نقطة — بعد ذلك، لم يعد النقاط المركبة تستجيب للرسوم على الإطلاق، لذلك قد يسجل محقق برسوم 100% (لا يحصل وكلاؤه على شيء) في الأربعينيات في الأبعاد التي لا تنتبه للرسوم مثل الجاهزية و MIRROR.
كيف: صفر عند أو أقل من رسم 50% — بُعد الرسوم يُسعّر هذا النطاق بالفعل، لذا لا يوجد عد مزدوج. فوق 50% يزداد الخصم خطياً مع الرسم، ليصل إلى 75% من النقاط الموجبة للمحقق عند رسم 100%. يتدرج مع النقاط نفسها، لذا سواء كان عقدة خاصة مصقولة أو مهملة، كلاهما ينتهي بهما الحال حيث يجب أن يكونا: في القاع من ترتيب يواجه الوكلاء.
// 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 — كتيب المدقق
دورة التدقيق التي أنتجت v4.0 تم تصميمها خصيصاً بحيث تحقق كل بعد بحد أقصى فعلاً يجعلك مدققاً أفضل لمفوضيك. تحسين درجتك ليس العبث بالنظام — إنه النظام يعمل كما هو مصمم. إليك كتيب صريح، لكل بعد.
Uptime — 20 نقطة. احتفظ بـ ≥99.5٪ من وقت التشغيل بشكل مستمر وامر شروط FIP-10 الدنيا في كل فترة مكافأة (لا تفقد الكشف، اضرب توصيل الوسيط). يتم ضرب الإشارتين — 100٪ RPC × 7/8 فترات مؤهلة = 17.5/20، وليس 20. لماذا هذا يتوافق مع المفوضين: كل فترة تفشل FIP-10، يفقد مفوضوك مكافآتهم لتلك الفترة.
صافي العائد — 18 نقطة. قدم ≥1.2× متوسط العائد السنوي للشبكة لمفوضيك (بعد الرسم). أفضل مسار: رسم منخفض + أهلية FIP-10 كاملة حتى يحصل المفوضون على حصتهم الكاملة. لماذا يتوافق: هذا حرفيًا مبلغ الدولار الذي يصل إلى المفوّض بعد حصتك.
معقولية الرسم — 7 نقاط. منذ تحديث Granite يفرض البروتوكول حد أدنى 20% لرسم تفويض المحقق، وأي رسم عند أو أقل من رساء التسجيل (الأكبر بين الحد الأدنى النشط الملاحظ وذلك الحد) يحصل على 7 كاملة. فرض رسم أعلى يكلف نقاطاً على منحدر متسارع — رساء+10 → 4.5 نقطة، رساء+20 → 0. لماذا هذا متوافق: قتل الحد الأدنى منافسة الرسوم، لذا يحمي هذا البُعد الآن المفوضين فقط من الاستخراج فوق الحد الأدنى القانوني؛ ميزتك الحقيقية تعيش في العائد الصافي المسلّم.
جودة المشغل — 12 نقطة. أفضل مسار: تسجيل كمزود بيانات FTSO وتشغيل مجموعة عالية الجودة (FTSO + FDC + توقيع) — درجة FlareWatch Operator Quality الخاصة بك تأتي من درجة FTSO الخاصة بك، بحد أقصى عند FTSO 100. بديل إذا كنت تقتصر على الحصة: احتفظ بخط أساس التحقق +7 إما بالتأهل لترقية v3.10 التلقائية (90+ يوماً مراقب، 25+ مفوض، الاحتفاظ لا ينحدر، السند الذاتي الذي يتوافق مع FIP-10) أو بإضافتك إلى KNOWN_VALIDATORS كبنية أساسية مؤسسية (مسار سريع يدوي). تأخذ الدرجة max(verification, FTSO-derived) — المشاركة لا يمكن أن تؤذي. لماذا هذا يتوافق: مشغلو المجموعة الكاملة يوفرون قيمة النظام البيئي أكثر؛ خط الأساس للتحقق يعطي المفوضين إشارة هوية أوضح.
مشاركة MIRROR — 10 نقاط. قدم خلاصات سعر FSP بشكل متسق، استوفِ الحد الأدنى لكل فترة بروتوكول (مسجل في سياسة التوقيع الخاصة بك، حد المطالبة المقابل، بدون فقدان الكشف). اشحن رسماً معتدلاً — يتم ضرب الدرجة بـ (1 − رسم/100)، لذا حتى المدقق MIRROR-نشط بنسبة 100٪ يسجل 0 لأن صفر MIRROR يصل إلى المفوضين. لماذا هذا يتوافق: MIRROR هي حصة مفوضيك من تضخم FTSO. رسم أقل = أكثر يصل إليهم.
ملف السعة — 7 نقاط. استهدف ~70٪ الاستخدام (حجم صحيح: ثبت جاذبية وله مكان للمفوضين الجدد). المدققون الفارغون يسجلون 1.75؛ يسجل المدققون المسقوفون 5.25. لماذا هذا يتوافق: المفوضون الجدد الذين يقرؤون الدرجة يريدون معرفة أنهم يستطيعون فعلاً التفويض؛ يشير الحجم الصحيح إلى كل من الإثبات الاجتماعي والتوفر.
ثقة المجتمع — 11 نقطة. ستة مكونات للحد الأقصى:
  • بناء إلى 500+ مفوضين مُجَمَّع بواسطة المشغل (إشارة عد أقصى: +6 نقطة).
  • احتفظ بمتوسط حصة متوافقة مع البيع بالتجزئة < 500K FLR لكل مفوض (مكافأة التركيز: +1).
  • ابق على الشبكة ≥ 90 يوماً للحصول على مكافأة الطول (+1) — محصن من المسح عبر حضور reward-scripts.
  • احتفظ بضمان ذاتي كبير — إما ≥ 10% نسبياً أو حصة مطلقة من أعلى الشبكة (~20M FLR)، أيهما يسجل أفضل (علاوة التوازن: +2).
  • نمو إجمالي FLR المفوضة بـ ≥ 10٪ على مدار 30 يوماً (الاحتفاظ: +0.5).
  • زيادة الحد الأدنى للتجميد بنسبة ≥ 20% على مدار 30 يومًا (المسار: +0.5).
لماذا يتوافق هذا: كل مكون يكافئ السلوك الذي يريده المفوضون — استثمار المشغل الحقيقي، النمو العضوي، الاستمرارية، المشاركة الواسعة من المجتمع. يتم تجميع مشغلي العقد المتعددة بحسابها + إشارات التركيز (v3.7).
موثوقية التسليم — 10 نقاط. ادفع للمفوضين ما يعدهم به معدل APY المتوقع (نسبة التسليم 1.00). قلل التباين لكل حقبة — المدفوعات المتوقعة أفضل من نفس المتوسط مع انتشار عالي (عقوبة التباين حتى −30%). بناء حجم عينة من 8+ حقب للثقة الكاملة. لماذا يتوافق هذا: هل أنت تحقق الوعود التي قطعتها، باستمرار؟ هذه أقوى إشارة المساءلة.
الوقت المتبقي — 5 نقاط. احتفظ بتاريخ انتهاء الحصة ≥ 120 يومًا. جدد قبل الانتهاء بوقت طويل؛ لا تدعه ينزلق إلى فئة < 14 يومًا (لا يمكنك قبول تفويضات جديدة بموجب FIP-10 بمجرد دخول الـ 14 يوم). لماذا يتوافق هذا: الالتزام الأطول يشير للمفوضين بأنك هنا للبقاء طويلًا.
الإشارات المقيدة بالوقت التي لا يمكنك تجاوزها: مكافأة الاستمرارية (90 يومًا مراقبة)، طبقة التنسيق التلقائي (90 يومًا + 25 مفوضًا + الاحتفاظ غير المتناقص + self-bond الممتثل لـ FIP-10)، إشارة الاحتفاظ (30 يومًا من سجل التفويض)، حجم عينة التسليم (8 حقب مكافآت). الخبر السار: الحفاظ على السلوكيات الأخرى يجمع هذه تلقائيًا بمرور الوقت.
نافذة التمويه مهمة على المدى القصير: الدرجة المعروضة هي متوسط مرجح أسي للقطات cron الأربع الأخيرة (0.5 / 0.3 / 0.15 / 0.05)، لذا حتى 100 مثالي على المدخلات يتطلب ~20 دقيقة من عمليات cron المثالية المتتالية للانعكاس بالكامل. المدخلات المثالية الثابتة = 100؛ التحسينات العابرة يتم تمويهها. عقوبات التغيير المفاجئ (قفزات الرسوم، انخفاض self-bond، أعطال التشغيل) يمكن أن تخفض حتى 10 نقاط لعدة دورات cron بعد الكشف.
باختصار: كل بعد صادق حول ما يقيسه. إذا كان محقق التحقق الخاص بك 100/100، فالنتيجة تخبر مفوضيك أيضًا أنهم يحصلون على أفضل نسخة من محقق التحقق على الشبكة — هذا هو قصد التصميم.
كيفية التحقق من درجتك الخاصة
كل درجة في جدول المحققين قابلة للتكرار من البيانات العامة. إذا كنت مشغلًا والحسابات هنا لا تتطابق مع الدرجة التي تراها، الخطوة الصحيحة هي التحقق منها بنفسك قبل افتراض أننا أخطأنا.
الفحص الأسرع يعمل تلقائيًا. وسع صف درجة أي محقق وسيقوم لوحة "تم التحقق منها في متصفحك" بإعادة حساب تلك الدرجة محليًا — نفس دالة التسجيل بالضبط التي يستخدمها cron، على نفس المدخلات التي استخدمها، بدون استدعاء عودة إلى خادمنا. لأن كل محقق يتم تسجيله بنفس دالة واحدة ليس لها مصطلح لهوية العقدة، هذا أيضًا كيف يمكن لأي شخص تأكيد عقدتنا الخاصة تكسب أي ميزة مخفية. الشرح اليدوي أدناه يفعل نفس الشيء يدويًا:
  1. ابحث عن إحصائيات محققك العامة على flaremetrics.io (ابحث باسم مشغلك أو الصق عنوان التفويض الخاص بك). لاحظ delegationFee، selfBond، delegatedStake، ودرجة FTSO (إذا كنت أيضًا موفر بيانات).
  2. تحقق من أهليتك لـ FIP-10 لكل من آخر 8 حقب مكافآت على github.com/flare-foundation/reward-scripts تحت generated-files/reward-epoch-N/nodes-data.json. احسب كم عدد الحقب التي كان nodeID الخاص بك فيها uptimeEligible: true. تلك النسبة تحرك مضاعف بعد Uptime الخاص بك.
  3. تحقق من مشاركة MIRROR الخاصة بك على عقد V2 RewardManager عبر flare-explorer.flare.network. ابحث عن أحداث RewardClaimed مع claimType=3 التي تشير إلى nodeID الخاص بك. إذا لم تكن هناك مؤخرًا، ستظهر كـ MIRROR-غير نشط.
  4. أدخل مدخلاتك في الصيغ أعلاه. يخبرك كل كتلة رمز البعد بالضبط ما هي العملية الحسابية التي تريد تشغيلها. اجمع الأبعاد، قيّد إلى 100، ولديك درجة cron المحسوبة الخام.
  5. قارن بدرجتك المعروضة. الدرجة المعروضة تشمل المتوسط المتحرك الأسي لـ v3.5 عبر آخر 4 لقطات cron (الحالية مرجحة بـ 0.5، السابقة 0.3، إلخ.) — لذا فإن درجة حساب تشغيل واحد ستكون مختلفة قليلًا عن الدرجة المعروضة. لوحة تفصيل الدرجات على كل صف محقق تظهر قيم البعد المستمرة التي ساهمت.
  6. إذا لم تنجح الحسابات، راسل [email protected] مع nodeID الخاص بك والمدخلات التي استخدمتها والدرجة التي حسبتها. سنرد، وإذا أخطأنا سنصلحه علانية.
الوصول البرمجي: لأي محقق نشط، اضغط على GET /api/validators/{nodeID}/score-breakdown لاسترجاع التفصيل المستمر — قيمة كل بعد، نسخة الخوارزمية التي أنتجتها، وسجل الدرجات الأخير — كـ JSON. لوحة تفصيل الدرجات في الواجهة تقرأ من نفس المصدر.
المخاوف الشائعة للمشغلين
أنا في 100% تشغيل RPC — لماذا درجة Uptime الخاصة بي أقل من 20/20؟
يضرب بعد Uptime مخرجات منحنى RPC بنسبة أهليتك للحقب (epochsIncluded / epochsObserved عبر آخر 8 حقب مكافآت — مجموعة حد الأدنى الكاملة من FIP-10 منذ الإصدار v4.2، وليس RPC-uptime وحده). إذا فشلت في استيفاء شروط الحد الأدنى من FIP-10 في أي من تلك الحقب — حتى لفترة وجيزة — تنخفض نسبة موثوقيتك عن 1.0 وتتدرج درجة Uptime الخاصة بك بشكل متناسب. قبل الإصدار v3.4 كان البعد يسجل 20 لكل معقّد مع وقت تشغيل RPC بنسبة 100% بغض النظر عن الأهلية التاريخية. الآن يفرّق بينها.
أنا أوصل MIRROR — لماذا يظهر FlareWatch لي كـ MIRROR-غير نشط؟
اعتبارًا من v3.6، يتم اكتشاف مشاركة MIRROR من مصدرين أساسيين: أحداث RewardClaimed(claimType=3) على السلسلة على V2 RewardManager، وتخصيصات claimType=3 في Merkle JSON الرسمية (بيانات توزيع المكافآت المنشورة). يعتبر nodeID الذي يظهر في أي مصدر نشطًا. قبل v3.6 استخدمنا تدفق السلسلة كإشارة وحيدة، مما أنتج false negatives لموفري self-delegating الذين يستقر MIRROR الخاص بهم من خلال مسار مطالبة غير قياسي. وأيضًا تم إصلاحه في v3.6: خطأ صيغة مفتاح حيث ~95 محقق كان لديهم مدخلات mirror-stats الخاصة بهم مكتوبة تحت hex20 (نموذج bytes20 من nodeID) بواسطة فاهرس على السلسلة عندما لم يكونوا بعد في قائمة الأسماء المنسقة — بينما كل بحث في الواجهة مفتاح بـ cb58 NodeID. كانت تلك المدخلات موجودة وصحيحة؛ لقد لم تكن مرئية لطبقة العرض. البحث الآن يطبيع كلا الصيغتين عبر كل مستهلك (جدول المحققين، لوحة تفصيل الدرجات، API mirror-stats العام، بطاقة Staking Positions صفحة العائد، لوحة موفري FTSO). إذا كان nodeID الخاص بك لا يزال يظهر غير نشط بعد كنس v3.6، الأسباب المحتملة: (أ) nodeID الخاص بك ليس مسجلاً فعلاً في سياسة التوقيع الخاصة بـ FSP الخاص بك لتلك الحقبة، (ب) نحن بين نشرات الحقبة (بيانات Merkle محدثة لكل حقبة، ~3.5 أيام). راسلنا مع nodeID الخاص بك وسنتحقق من كلا المصدرين الأساسيين.
انخفضت درجتي 10 نقاط بين عشية وضحاها — ما الذي تغير؟
واحد من ثلاثة أشياء: (1) كشف التغيير المفاجئ v3.5 علّم قفزة رسوم أو انخفاض self-bond أو تعطل تشغيل على nodeID الخاص بك — عقوبة 10 نقاط تنطبق على التشغيل الذي نكتشفه ويتحلل على التشغيل التالي 3 عند استقرار الحالة الجديدة؛ (2) نافذة التمويه دمجت لقطة أقدم سحبت متوسطك؛ (3) شحنا اصطدام نسخة الخوارزمية (مرئي في حقل algorithmVersion للسجل الخاص بك — انظر بطاقة الإصدارات أدناه). لوحة تفصيل الدرجات تظهر قيم البعد الحالية؛ قارن ضد التشغيلات السابقة.
لماذا يسجل محقق برسوم عالية أقل من محقق برسوم منخفضة مع كل شيء آخر متشابه؟
بعد صافي العائد (18 نقطة بحد أقصى) حساس للرسم — يوفر مدقق برسم 0% ~1.25× متوسط العائد السنوي للشبكة، مسجل بالقرب من الحد الأقصى؛ يوفر مدقق برسم 20% ~80% من المتوسط، مسجل أقل. بالإضافة إلى معقولية الرسم (7 نقاط) متعدد التقسيم خطي منذ v3.9 (بدون سلاسل): ≤5% يحصل على 7 كاملة، ثم تنخفض المنحنى مع منحدرات متشددة — 10% → 6، 15% → 4.5، 20% → 2.5، 25%+ → 0 (لذا على سبيل المثال رسم 16% ينقط ~4.1، وليس قيمة سلسلة ثابتة). لذا فرق 5-نقاط في الرسم يترجم إلى ~5-8 نقاط فرق النقاط. هذا مقصود — يهتم المفوضون مباشرة بالرسم.
أنا محقق جديد تمامًا بدون درجة FTSO. لماذا جودة المشغل الخاصة بي فقط 7/12؟
جودة المشغل (12 نقاط كحد أقصى) تكافئ مشغلي المكدس الكامل — المحققون الذين يشغلون أيضًا مكدس موفر بيانات FTSO أعلى (FTSO + FDC + التوقيع). إذا كنت فقط staking، خط أساس +7 قابل للوصول بطريقتين: (1) إدراج يدوي في قائمة KNOWN_VALIDATORS الخاصة بنا — مسار سريع مؤسسي لمشغلي البنية الموثوقة (Ankr، InfStones، Kiln، إلخ)؛ (2) ترقية تلقائية v3.10 بناءً على السلوك الموضوعي — 90+ يومًا مراقبة و 25+ مفوضون متجمعون وعدم الاحتفاظ بالتناقص والامتثال الذاتي لـ FIP-10. الترقية التلقائية مستقلة تمامًا، بدون بريد إلكتروني مطلوب. إذا لم تستوف الشروط التلقائية بعد، تبدأ من +3 (طبقة مكتشفة تلقائيًا، تتطلب ملف تعريف كيان Flaremetrics أو FSE) وتنمو إلى +7 مع بناء سجلك. للتسريع: سجل كموفر بيانات FTSO وقم بتشغيل بروتوكولات V2 — درجتك تأتي بعد ذلك من فرع مشتق FTSO مع أقصى حد 12 في FTSO 100. v3.8: يمكن للمشاركة FTSO فقط أن تساعد، أبدًا تؤذي — إذا كانت درجة FTSO الخاصة بك أقل من خط الأساس للتحقق، تحتفظ بخط الأساس.
لدي شعار لكن اسمي يظهر كـ NodeID مختصر. لماذا؟
كيان المشغل الخاص بك موجود في Flaremetrics (وهذا هو السبب في أن لدينا شعار لك) لكن ملف التعريف موفر الخاص بك لا يحتوي على حقل "الاسم" معين. نحن لا نصنع الأسماء. اضبط profile.name الخاص بك على Flaremetrics أو في سجل كيان Flare Systems Explorer، وسنلتقطه عند التشغيل التالي. بدلاً من ذلك، راسلنا مطالبة قابلة للتحقق (على سبيل المثال، رسالة موقعة من عنوان التفويض الخاص بك) وسنضيفك إلى KNOWN_VALIDATORS يدويًا.
محقق الخاص بي هو في أقصى تفويضات FIP-10. لماذا لا تسجل Capacity 7/7؟
Capacity دالة خيمة تذروة في استخدام 70% (7 نقاط)، تنحدر إلى 5.25 نقاط بـ 100%. القمة ليست 100% — كونك في الحد الأقصى يعني لا يمكن للمفوضين إضافة حصة أكثر حتى إذا أرادوا، وهي إشارة محايدة إلى سلبية قليلاً للمفوضين الجدد يقرؤون الجدول. قبل v3 سجلنا محققي مغطوسين 0/5 (عقوبة للنجاح)؛ v3 صحح هذا إلى محايد عند الحد الأقصى، و v3.7 أعاد تحجيم البعد كاملاً من 8 → 7 الحد الأقصى (تحرير نقطة للإشارات مسار الثقة)، لذا اليوم مغطوسين 5.25/7. محققو حجم صحيح (ثبت جاذب والغرفة التي تنمو، ذروة في استخدام 70%) احصل على الكامل 7.
أنا مشغل حقيقي لكنني لست في قائمة المحققين على الإطلاق. ما هذا؟
يتم بناء قائمة المحققين من نتيجة getCurrentValidators من P-Chain RPC الحي. إذا لم تكن هناك، فأنت إما غير نشط حاليًا على P-Chain، انتهت حصتك للتو، أو هناك مشكلة P-Chain RPC على جانبنا. يعمل cron كل 5 دقائق — يجب أن تظهر في غضون 1-2 دورة من تنشيط حصتك. إذا كنت مباشرة لمدة ساعة ولا تزال لا ترى نفسك، راسلنا nodeID الخاص بك.
هل يمكنني استئناف درجتي أو طلب مراجعة يدوية؟
نعم. راسل [email protected] مع nodeID الخاص بك والقلق المحدد. نرد على كل مشغل. الأشياء التي سننفذها: إضافات KNOWN_VALIDATORS، تصحيحات تصنيف MIRROR، إصلاحات الشعار/الاسم، أخطاء حسابية خاصة بالبعد. الأشياء التي لن نفعلها: طلبات لرفع درجة يدويًا خارج الخوارزمية، طلبات لاستبعاد أو ترقية منخفضة منافس.
ما الذي سنفعله ولن نفعله
لإزالة الغموض حول كيفية تشغيلنا للنتيجة، فيما يلي التزامات صريحة. إذا انتهكنا أحدها في أي وقت، وثقها وراسل [email protected] — سنصلحها علانية.
✓
لن نقبل الدفع مقابل درجات أعلى أو وضع برعاية أو معاملة مواتية من أي نوع. يتم حساب الدرجة بشكل حتمي من بيانات السلسلة العامة.
✓
لن نقوم بترميز محقق مرتفع يدويًا. لا توجد "X يحصل على +5 لأننا نحبهم" سطر في أي مكان في الرمز. نفس الخوارزمية تنطبق على كل محقق بما في ذلك عقدة FlareWatch الخاصة بنا، والتي تسجل بهذه الدالة بالضبط.
✓
لن نستبعد المدققين من الجدول لأسباب غير علنية. تُستمد القائمة من P-Chain RPC المباشر وتتضمن عرضنا كل مدقق نشط. التجميعات المختارة على KNOWN_VALIDATORS تملأ أسماء العرض فقط — فهي لا تحدد الرؤية.
✓
سننشر تغييرات الخوارزمية. كل تحديث إصدار (v3 → v3.1 → v3.2 → ...) موثق في بطاقة الإصدارات على هذه الصفحة مع المنطق الأساسي وما تغير. التغييرات الرئيسية تحصل على إدخال سجل تغييرات إضافي مرئي من صفحة سجل التغييرات في التطبيق.
✓
سنرد على رسائل البريد الإلكتروني للمشغلين. كل مشغل يرسل بريداً إلكترونياً إلى [email protected] مع مخاوف موضوعية بشأن درجته يحصل على رد حقيقي في غضون بضعة أيام عمل.
✓
سنصحح أخطاؤنا علناً. إذا اكتشفنا خطأ في الخوارزمية أو خطأ في مصدر البيانات أو فجوة في المنهجية، نقوم بشحن إصلاح وتوثيقه. نحن لا نعيد الترتيب بصمت.
✗
لن نشارك محتويات البريد الإلكتروني علناً دون إذن المرسل، أو نستخدم رسائل البريد الإلكتروني للمشغلين لأي شيء آخر غير محادثة الدرجة التي أنتجتها.
✗
لن نشارك خططنا المستقبلية لتغيير الخوارزمية مع مشغلين معينين مسبقاً — كل إصدار يصبح مباشراً للجميع في نفس الوقت.
القيود — ما هي هذه النقاط وما هي ليست
النقاط المركبة هي ملخص مفيد وليست حقيقة موضوعية. نقاطنا شفافة ومرقمة النسخة، وتطبق بشكل متطابق على كل مدقق — بما في ذلك مدققونا — ويمكن إعادة اشتقاقها من المدخلات المنشورة مباشرة في متصفحك. لكنها تحمل أحكامًا تحريرية، ونفضل أن نريك بالضبط أين بدلاً من الإشارة إلى دقة لا تملكها الطريقة.
أوزان الأبعاد هي حكمنا. الجهوزية تستحق 20 نقطة والرسم تستحق 7 لأننا قررنا أن الموثوقية مهمة أكثر لمعظم المفوضين من بضع نقاط من الرسوم — وليس لأن صيغة ما أثبتت ذلك. الأشخاص المعقولون يرجحون هذه بشكل مختلف. الأوزان ثابتة وعامة، لذا يمكنك أن ترى بالضبط ما اخترناه وإعادة وزنها عقليًا من التفصيل.
العائد الصافي هو نتيجة وليس فضيلة. يقيس ما يكسبه المفوض فعليًا، مرتكزًا على متوسط الشبكة — لذا فإنه يتشكل جزئيًا من قبل الأشياء خارج السيطرة (التضخم في الشبكة، كم التفويض الذي جذبوه) وينتقل عندما تتحرك بقية الحقل. يمكن لمشغل منضبط يفرض رسومًا عادلة لكن أعلى أن يحصل على نقاط أقل هنا بينما يكون ممتازًا. اقرأها باعتبارها
أبعاد FTSO المرتبطة تفضل مشغلي المكدس الكامل. مشاركة MIRROR وجزء من جودة المشغل يكافئان المدققين الذين يشغلون أيضًا مكدس موفر بيانات FTSO عالي المستوى. هذا مقصود — كمفوض أنت تكسب فعليًا أكثر، من خلال MIRROR، من مدقق نشط في FTSO — لكن هذا يعني أن مدقق نقي وممتاز مخصص للمراهنة فقط لا يمكنه الوصول إلى أعلى هذا اللوحة. إذا كنت مراهنًا فقط بالاختيار، فقلل وزن هذه الأبعاد بنفسك.
النموذج إضافي. تضاف الأبعاد، لذا يمكن للقوة أن تعوض الضعف — الجهوزية الممتازة يمكن أن تحمل رسومًا أعلى إلى نقاط محترمة. الإخفاقات المؤهلة حقًا (فشل حد أدنى FIP-10، الرسوم المفترسة) يتم السيطرة عليها بشكل منفصل بحيث لا يمكن إخفاؤها بالكامل — مدقق يفشل في الحد الأدنى كل حقبة أو يفرض رسم 100٪ ينتهي به الحال بالقرب من القاع بغض النظر عن أبعاده الأخرى — لكن الأساس هو مجموع مرجح وليس نظام النقض.
رقم واحد يخفي تسع أحكام. الرقم الفردي من 0-100 هو نقطة انطلاق وليس حكمًا. المدققان بفارق نقطة واحدة لا يختلفان بشكل مجدٍ. افتح التفصيل وأعطِ وزنًا للأبعاد التي تهمك — الرقم موجود لجعل هذه المقارنة أسرع وليس لاستبدالها.
نغير الطريقة نادرًا وعلنًا. كل تغيير يأتي مع ارتفاع نسخة وحجة مكتوبة ومقارنة قبل وبعد على مستوى الحقل، لذا يمكنك مراجعة ما تحرك ولماذا. عندما يكتشف تدقيقنا الآلي تناقضًا في أرقامنا — كما يحدث — نصلحه ونقول ذلك.
الدرجة النهائية (كيفية دمج الأبعاد)
جميع الأبعاد التسعة تجمع مباشرة، ثم يتم طرح خصم شريط الانقطاع النشط v4.3. إجمالي الحد الأقصى عند 100 والحد الأدنى عند 0. يتم تطبيق التمويه عبر لقطات cron الحالية (v3.5) وأي عقوبة تغيير مفاجئ على الرقم النهائي.
// 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)
مصادر البيانات (كل مدخل عام)
Flare P-Chain RPC: قائمة المدققين، الوقت المتاح، السندات الذاتية، الحصة المفوضة، الرسوم، وقت الانتهاء، عدد المفوضين.
V2 RewardManager (أحداث claimType=3): توزيع MIRROR المطلوب على السلسلة لكل مدقق nodeID. مرشح بدقة على النوع 3 — لا اختلاط مع VRM أو تفويض FTSO أو مكافآت DIRECT.
FSP Merkle JSON (تخصيصات claimType=3): السجل المنشور الموثوق به لمن يستحق MIRROR لكل حقبة (نفس البيانات التي تقرأها أداة التوقيع الخاصة بـ Flare). تمت إضافتها في v3.6 كمصدر موثوق ثاني — تمسك بالمدققين الذين تم تخصيص MIRROR لهم ولكن لم يتم المطالبة بهم على السلسلة بعد.
Flare Systems Explorer (FSE): سجل كيان المدقق، أسماء العرض، الشعارات، أعلام مشاركة بروتوكول FTSO V2.
بيانات مزود Flaremetrics: درجة FTSO، معدل المكافأة، الدقة، ميزات V2، ربط الكيان برقم nodeID.
سكريبتات مكافآت Flare (GitHub): APY المسلم لكل مدقق لأحدث N حقبة مكافأة. يحرك بعد التسليم.
تنسيق FlareWatch: خريطة KNOWN_VALIDATORS (~110 إدخالات). أسماء + خط أساس جودة المشغل لمشغلي البنية التحتية الموثوقين.
ما هو NOT في الدرجة
• الترويج الذاتي أو الموضع المدفوع. لا يمكن لأي مشغل أن يدفع أو يرعى درجة أعلى.
• تصعيد محدد للمدقق الذي يتم ترميزه يدويًا. لا توجد أسطر "X يحصل على +5 لأننا نحبهم" في أي مكان في الكود. نفس الخوارزمية تنطبق على كل مدقق بما في ذلك عقدة FlareWatch الخاصة بنا، والتي يتم تسجيلها بهذه الوظيفة بالضبط.
• جودة البنية التحتية الموضوعية. نحن لا نحاول تقييم اتفاقيات مستوى الخدمة أو التوزيع الجغرافي أو مواصفات الأجهزة. إذا كنت تريد المطالبة ببنية تحتية من الدرجة الأولى، قم بتشغيل مكدس FTSO + FDC عالي الجودة وستعكسه بعد جودة المشغل.
• قفل أو التزامات تجاه FlareWatch. لا توجد نقاط مواتية للمراهنين باستخدام FlareWatch مقابل أداة أخرى.
تعليقات المشغل
هل رأيت شيئاً خاطئاً في درجة المدقق الخاص بك؟ أرسل بريداً إلكترونياً إلى [email protected] مع NodeID والمخاوف الخاصة بك. نحن نرد على كل مشغل. الطلبات الشائعة التي سننفذها:
  • إضافة مشغلك إلى KNOWN_VALIDATORS (مع التحقق).
  • مراجعة تصنيف MIRROR-غير النشط الخاص بك إذا كنت تعتقد أنه خطأ.
  • تصحيحات الشعار / اسم العرض.
  • نقد الخوارزمية العام.
المصادر والمراجع
كل مدخل للدرجة يأتي من مصادر عامة قابلة للتحقق من نظام Flare البيئي. يمكن لأي شخص التحقق من مطالباتنا مقابل هذه المصادر الأساسية وإعادة إنتاج الرياضيات من البيانات الخام. إذا لاحظت تناقضاً بين هذه الصفحة وما تقوله المصادر الأعلى سلطة، أرسل بريداً إلكترونياً إلى [email protected] وسنصلحه.
وثائق البروتوكول الموثوقة. يغطي FTSO V2 و FSP و P-Chain validation و FAssets وبقية مكدس Flare.
بوابة حوكمة Flare (FIPs) ↗https://proposals.flare.network
اقتراحات تحسين Flare — مصدر الحقيقة لـ FIP-05 (عامل التفويض) و FIP-10 (شروط الحد الأدنى للمدقق: 1M FLR floor الربط الذاتي و 80% floor الوقت المتاح و 14 يوم minimum lock) وجميع القواعس الأخرى المذكورة على هذه الصفحة.
Flare Systems Explorer (FSE) ↗https://flare-systems-explorer.flare.network
السجل الرسمي الذي تشغله Flare لمزودي بيانات FTSO وعناوين الكيانات وربطات nodeID الخاصة بـ P-Chain وأعلام الحد الأدنى من الشروط FIP-10. مصدر أساسي لبيانات جودة المشغل والموثوقية لدينا.
Flaremetrics ↗https://flaremetrics.io
مزود مقاييس نظام Flare البيئي المستقل. مصدر تسجيل مزود FTSO ومعدلات المكافأة ومقاييس الدقة وأعلام مشاركة بروتوكول V2 وتعيينات المدقق إلى عنوان الكيان. نحن نستهلك واجهة برمجة التطبيقات العامة الخاصة بهم.
مستودع سكريبتات مكافآت Flare Foundation ↗https://github.com/flare-foundation/reward-scripts
JSON الذي ينشره Flare Foundation لكل حقبة مكافأة يوضح أهلية كل مدقق وأهلية الوقت المتاح والمكافآت المسلمة. يحرك بعد موثوقية التسليم ونسبة أهلية الحقبة v3.4 للوقت المتاح.
Flare Block Explorer ↗https://flare-explorer.flare.network
متصفح للقراءة فقط لجميع حالات على السلسلة. يتيح لأي شخص التحقق من أحداث RewardClaimed في V2 RewardManager (claimType=3 لـ MIRROR)، إجمالي حصص المدققين، تغييرات الرسوم، وغيرها.
Flare Portal (staking) ↗https://portal.flare.network/staking
واجهة الرهن الرسمية. المصدر الموثوق للحصول على مبالغ الرهن الذاتي / المفوضة الحالية وأوقات نهاية المدقق التي تغذي قراءات P-Chain RPC التي نستخدمها.
Flaremetrics public API (FTSO providers) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
نقطة النهاية الدقيقة التي يستهلكها cron الخاص بنا، وتُرجع ملفات تعريف الكيانات وNFTSO scores والرسوم وmodeIds بصيغة hex. يمكن لأي شخص الوصول إليها مباشرة.
Flaremetrics public API (node registrations) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
جدول تحويل Hex → cb58 NodeID. نقسم هذا للصفحات لبناء بحث الكيان-إلى-NodeID الذي يدفع كل مستهلك بصيغة cb58.
لا توجد بيانات خاصة، لا توجد نماذج مغلقة المصدر. تم تنفيذ خوارزمية التسجيل في services/validators/scoring.ts في قاعدة كود FlareWatch. يمكن للمشغلين أو الباحثين الذين يريدون فحص التنفيذ مباشرة (بدلاً من قراءة النثر + الصيغ أعلاه) — أو الذين يريدون عمل نسخة منه لاستخدامهم الخاص — إرسال بريد إلى [email protected] لطلب الوصول. سننشر الملف كحزمة مفتوحة المصدر مستقلة إذا كان هناك طلب حقيقي.
كيفية تحديث الدرجات
يعيد حساب cron في /api/cron/refresh-validators درجة كل مدقق نشط كل 5 دقائق. يتم جلب المدخلات (قراءات P-Chain RPC، Flaremetrics، FSE، reward-scripts) بشكل جديد في كل مرة تشغيل.
أضافت v3.5 تمويج عبر آخر 4 لقطات cron (الأوزان: 0.5 / 0.3 / 0.15 / 0.05)، لذا فإن الدرجة المعروضة لا تتقلب من ضوضاء المدخلات العابرة. لا تزال الدرجة المحسوبة بواسطة cron الخام محفوظة لرياضيات التمويج المستقبلية، وتظهر لوحة تفصيل الدرجة قيمة كل بُعد الحالية بحيث يمكنك رؤية ما تغير.
إصدار الخوارزمية مختوم على كل سجل درجة مخزن مؤقتًا. عند شحن نسخة جديدة، تحصل كل درجة على العلامة الجديدة. توثق بطاقة الإصدارات أدناه كل تغيير.
نموذج العقوبة في Flare

Flare لا تقطع حصة المدقق. آلية العقوبة بأكملها لسوء السلوك من المدقق هي مصادرة المكافأة بالإضافة إلى نظام تمريرات FIP-10. لا يوجد قطع توقيع مزدوج، لا قطع تعادل، لا حدث تدمير حصة نحتاج إلى تتبعه. المدققون الذين يفشلون في شروط الحد الأدنى لـ FIP-10 يفقدون مكافآت تلك الحقبة (مصادرة كاملة إذا كانت عند صفر تمريرات، وإلا يفقدون تمريرة واحدة لكل بروتوكول فشلوا فيه)؛ رأس مالهم المرهون لم يتغير.

هذا يعني أن الدرجة ليس لديها بُعد "سجل القطع" — لا يوجد مثل هذا السجل لتتبعه. ما نتتبعه بالفعل هو نتيجة كل فشل في الحد الأدنى: كسب المدقق صفر في تلك الحقبة، وهو ما يُلتقط في epochsIncluded / epochsObserved. قام تحديث v4.2 في 2026-05-14 بتوسيع مُضاعِف موثوقية الدرجة لاستخدام تلك النسبة عبر مجموعة الحد الأدنى الكاملة لـ FIP-10 (وقت التشغيل، توقيع FSP، معدل تقديم FTSO، مشاركة FDC) لذا فإن فشل المدقق في أي حد أدنى يعاقبه بشكل متناسب في بُعد وقت التشغيل بغض النظر عن المحور الذي فشل فيه.

حدود الحد الأدنى لـ FIP-10، المستمدة من dev.flare.network/network/fsp/rewarding: يتطلب الرهن 80٪ وقت تشغيل + 1M FLR ربط ذاتي نشط؛ تتطلب بيانات FTSO anchor أن تكون التقديرات ضمن 0.5٪ من متوسط الإجماع في 80٪ من الجولات؛ تتطلب بيانات زمن الانتقال لـ FTSO تقديم 80٪ من التحديثات المتوقعة؛ يتطلب FDC المشاركة في 60٪ من جولات التصويت. المدققون الذين يستوفون الحد الأدنى لوقت التشغيل 80٪ + 1M ربط ذاتي ولكن أقل من عتبات الكسب 3M / 15M لا يزالون يتلقون مكافآت ولكن لا يمكنهم تجميع التمريرات — المنطقة الرمادية التي تظهر عبر تصنيف passEligibility: "at-risk" في هذه البطاقة.

الإصدارات
v4.8 (2026-09-17) — تم تسنيب عوائد الحقب الزمنية بطولها الفعلي. تم تسنيب كل معدل مقاس للمدقق (APR المُسلَّم، التفويض، عائد MIRROR، عائد السندات الذاتية للمشغل) بحقبة زمنية للمكافآت مدتها 3.19 يومًا، وهي قيمة تمت إضافتها في 2026-04-04 ووُصِفت بأنها مقاسة من طوابع الكتلة الزمنية على الرغم من أن لا شيء قاسها فعليًا. حقب المكافآت في Flare تبلغ بالضبط 3.5 أيام — تُرجع rewardEpochDurationSeconds في FlareSystemsManager 302,400 وكل بداية حقبة على السلسلة تفصل بينها 3.500 أيام بالضبط — لذا كل معدل مقاس قُرِئ بحوالي 9.7% أعلى لمدة خمسة أشهر ونصف، بما فيها معدلنا نحن. يتم الآن قراءة الطول من هذا العقد. كل APR مقاس ينخفض بنفس النسبة، 3.19 ÷ 3.5 (وسيط الشبكة 9.08% → 8.28%؛ FlareWatch 8.17% → 7.45%). النقاط: فقط Delivery Reliability تتغير، لأنها تقارن المعدل المقاس مع المعدل النظري لرسم المدقق. كان الجانب المنتفخ قد وضع 91% من المدققين عند حد 1.0، أي أنهم يبدو أنهم يدفعون أكثر مما هو ممكن؛ مع طول الحقبة الحقيقي، فإن النسبة الوسيطة المُسلَّمة إلى النظرية هي 0.990. محاكاة على 168 مدققًا بيانات مقاسة قبل الإطلاق: وسيط −0.32 نقطة، 146 يخسرون أقل من نقطة واحدة، 13 يُسلِّمون بالفعل أقل من المعدل المضمون برسمهم يخسرون 2–3.5. يحول المرجع الاحتياطي للصلاحية Community Trust الحقب إلى أيام بنفس الطول ويتم تصحيحه أيضًا؛ لا يحرك نقطة، لأنه يرى 8 حقب كحد أقصى (28 يومًا)، أقل من خطوة 30 يومًا في كلا الجانبين. استخدمت شهادات الأداء الموقعة نفس الطول الخاطئ؛ يتم مراجعة مواصفات إعادة الحساب إلى rev.3 ويتم الاحتفاظ بـ rev.2 حرفيًا مع الكشف عن الخطأ.
v4.7 (2026-08-19) — ضمان ذاتي ثنائي المحور في بُعد Community Trust. اعتمدت الثقة الضمان الذاتي للمشغل فقط كـ نسبة (ضمان الخاص به ÷ إجمالي الحصة)، لذا الضمان الذاتي الكبير المخفف بالتفويض سجل نفس الدرجة مثل ضمان صغير بتلك النسبة — كانت الدرجة عمياء عن رأس المال الفعلي المُلتزم به. عبر الشبكة المباشرة احتفظ 61 من 178 مدقق بـ ≥10M ضمان ذاتي بنسبة <10%، لذا ثلث الحقل كان يحصل على ائتمان ناقص. v4.7 يعتمد الضمان الذاتي على الأفضل من الحصة النسبية (≥10% → +2، 5–10% → +1، دون تغيير) أو الحجم المطلق (min(1, selfBond ÷ 20M) × 2، يصل إلى التشبع عند أعلى عُشر P-chain الشبكة للضمان)، يأخذ max والإشارة الفرعية محدودة بـ +2 — حد الثقة (11) وحد التركيب (100) دون تغيير، وحد FIP-10 المجوّف تحت (<1M FLR → −1) دون تغيير. يعكس ضمان ذاتي ثنائي المحور استخدمت درجة مزود FTSO بالفعل. قبل/بعد على مستوى الحقل عبر جميع 178 مدقق، مؤرشف قبل الشحن: 58 يتحرك لأعلى، لا أحد يتحرك لأسفل، لا تزيد أي درجة بأكثر من نقطة واحدة، وأعلى لوحة الترتيب دون تغيير. عقدتنا الخاصة ترتفع نقطة واحدة (83 → 84) بنفس القاعدة مثل كل مشغل آخر ذو رأسمال جيد — لا مصطلح يذكرنا.
v4.6 (2026-08-13) — مكافأة حجم MIRROR المسلّم. كانت بُعد MIRROR تسجّل فقط التمرير (النسبة من MIRROR التي تصل للمفوضين، = 1 − رسم) وحالة المشاركة — كانت عمياء عن الكمية المسلّمة. مُدقّق يدفع معدل MIRROR مسلّم أعلى بكثير (mirrorAPY، بعد الرسم) من الحقل لم يكسب ائتماناً له، لذا عقدة عائد أعلى فعلياً قد تصنّف أسفل واحدة عائد أقل على أبعاد العائد. v4.6 يضيف مكافأة صغيرة ومحدودة ومرساة بالوسيط: فقط للمُدقّقين النشطين في mirror، clamp((mirrorAPY / networkMedianMirrorAPY − 1.2) × 5, 0, 2). فقط التسليم فوق 1.2× معدل الوسيط للشبكة يكسبها، ويصل الحد الأقصى إلى +2، رفع سقف بُعد MIRROR من 10 إلى 12 (المركب لا يزال محصوراً عند 100). هو مرساة لمعدل الشبكة الوسيط، وليس الحجم، لذا فهو محايد حسب الحجم بناءً على التركيب: عبر الحقل المباشر المكافأة ترتبط سلباً بالسند الذاتي (تفضل المُدقّقين الصغار الذين يسلّمون معدلات عالية، وليس الكبار). تم أرشفة قبل/بعد في جميع أنحاء الحقل لجميع المُدقّقين النشطين قبل الشحن — معظم المُدقّقين لا يتحركون، وأعلى الترتيب بدون تغيير. تنطبق نفس الصيغة على كل مُدقّق، بما في ذلك عقدتنا الخاصة.
v4.5 (2026-07-16) — عقوبة قابلية الرسم المرتفعة. يصل بعد Fee Reasonableness إلى 0/7 بمجرد تجاوز الرسم لمرساة السوق + 20 نقطة (~40% بعد Granite)؛ من هناك حتى رسم بنسبة 100% توقف المركب عن الاستجابة للرسم تماماً، لذا معقّد برسم 100% — واحد حيث لا يحتفظ المفوضون بأي شيء — سجل لا يزال في الأربعينات على أبعاده التي لا تنظر للرسم. في درجة موجهة للمفوض تلك النتيجة تقترب من التنصل، وليست منتصف الجدول. يضيف v4.5 عقوبة مركبة مطبقة كجزء من إجمالي البعد الإيجابي: صفر عند أو أقل من رسم بنسبة 50% (لا حساب مزدوج في النطاق الذي يسعّره البعد Fee بالفعل)، ثم يتسارع خطياً إلى 75% من الدرجة عند رسم بنسبة 100%. ينزل عقدة برسم 100% حول 10/100 — لا تزال مدرجة وترتيبها، بوضوح ليست مرشحة التفويض. إنها دالة نقية للرسم على السلسلة، متطابقة لكل معقّد، بما في ذلك عقدتنا الخاصة.
v4.4 (2026-07-11) — رساء الرسم الواعي لحد Granite. يفرض تحديث Granite (Flare، 2026-07-14) حد أدنى 20% لرسم تفويض المحقق بالبروتوكول. يصبح رساء معقولية الرسم الحد الأقصى(الحد الأدنى النشط الملاحظ، حد البروتوكول): كل رسم عند أو أقل من الحد القانوني الأدنى يحصل على علامات كاملة، وفقط الرسوم فوقه تُعاقب، حسب المسافة. الأساس المنطقي: مع عدم تحديد الكفالة للحصص المرحلية في الاتجاه الأعلى، سيؤدي الربط برسم موروث 2% (أو 0% ما قبل المراجعة) إلى منح درجات لمشغّلي البروتوكول المتوافقين 20% كاستخراجيين تقريباً — وحساب مزدوج لفرق رسم أن العائد الصافي يسعره بالفعل بالمصطلحات المسلّمة. لم يتغير بُعد آخر. عندما يصل الفوج بأكمله إلى الحد، يمنح البُعد علامات كاملة بالتساوي — تتوقف الرسوم عن العد بمجرد ألا يتمكن أحد من المنافسة عليها.
v4.3 (2026-05-14) — تمت إضافة عقوبة الانقطاع النشط كخصم ثابت بعد البُعد. مُضاعِف uptimeReliability الحالي متماثل — 5 عمليات فشل متناثرة عبر 24 حقبة تكلف نفسها من 5 عمليات فشل متتالية — لكن من الناحية التشغيلية تلك إشارات مختلفة جداً: عمليات الفشل المتناثرة تعني عدم الاستقرار المزمن، الانقطاع يعني أن المدقق مكسور الآن. تقرأ v4.3 الدورة المتجاورة من الحقب غير المؤهلة !eligible في رأس سجل المشاركة الحديث للمدقق وتخصم 0 نقطة لـ 0–1 فشل متتالي (التباين الطبيعي / فشل عابر واحد)، 3 نقاط عند 2 (انقطاع متطور)، 6 نقاط عند 3 (انقطاع مستمر)، و10 نقاط عند 4+ (انقطاع نشط مستمر)، مع تحديد المركب عند 0. مُرتقيًا فوق — وليس بديلاً عن — مُضاعِف الموثوقية، لأن الاثنين يلتقطان مخاطر مختلفة. المُحفِّز: حادثة Luganodes من الدرجة الأولى في 2026-05-14، حيث تم فقدان حقب متعددة متتالية مؤخراً بينما كان المندوبون يلتزمون بنشاط بالحصة؛ تتيح إشارة الانقطاع للمندوبين رؤية فشل طاير قبل الالتزام. تُرجع العقوبات كقسم خاص بها في لوحة تفصيل الدرجة بحيث تصل الأبعاد الإيجابية 9 إلى 100.
v4.2 (2026-05-14) — إصلاحان مرتبطان، تم شحنهما معاً رداً على تصحيح عام من AU (@aucc_official) حول درجة Luganodes. (1) يضرب حساب deliveredAPY الآن معدل السعر في الحقبة المكتسبة في `epochsIncluded / epochsObserved` بحيث تعكس APR المعروضة معدل EFFECTIVE الذي يتلقاه المفوض بالفعل على نافذة الملاحظة — بما في ذلك الحقب صفر الأرباح عندما يفشل المدقق في الحد الأدنى لـ FIP-10. حسابت التنفيذ السابق فقط حقبة الكسب وأظهر للمدققين معدل حقبتهم الجيدة، مما أخفى الحد الأدنى من الفشل. (2) اتسعت مُضاعِف موثوقية بُعد وقت التشغيل من وقت التشغيل فقط (epochsUptimeEligible / epochsObserved) إلى مجموعة الحد الأدنى الكاملة لـ FIP-10 (epochsIncluded / epochsObserved). المدقق الذي يحتوي على 100٪ من وقت التشغيل RPC والذي يفشل في توقيع FSP أو معدل تقديم FTSO يأخذ الآن ضربة متناسبة على بُعد وقت التشغيل بغض النظر عن الحد الأدنى الذي فشل فيه. التأثير الصافي على Luganodes على وجه التحديد: ينخفض deliveredAPY من 10.86٪ إلى ~5.43٪ (مطابقة لواقع الدفع بنصف)، يهبط موثوقية وقت التشغيل من 1.0 إلى 0.5، الدرجة تنخفض بشكل ملموس. ينطبق نفس التصحيح على كل مدقق مع `epochsIncluded < epochsObserved` — عبر الشبكة هذا يسطح فجوات جودة المشاركة الحقيقية التي كانت مخفية سابقاً.
v4.1 (2026-05-14) — تم تبديل بُعد العائد الصافي من APR النظري (الصيغة: gross_APR × (1 − fee)) إلى deliveredAPY المقاس من Flare Foundation reward-scripts، مع الرجوع النظري لكل مدقق فقط عندما لا يوجد سجل قياس. المُحفِّز: انخفاض التضخم FIP-16 (5٪ → 3٪) بدأ يعمل في 2026-05-14، ومقام الحصة المؤهلة في الصيغة النظرية انجرف بعيداً عن واقع على السلسلة بحيث يقلل APR النظري من المحصول المُسلَّم بمقدار ~2× عبر الشبكة. يعيد التبديل إلى المقاس أولاً محاذاة مدخل الدرجة مع ما يتلقاه الراهنون فعلاً. تمت إعادة حساب مرساة networkMedianAPR أيضاً باستخدام نفس منهجية المقاس أولاً بحيث تظل مقارنة النسبة متسقة على كلا الجانبين — يجب أن تكون الدرجات تقريباً مستقرة (المدقق عند متوسط الشبكة لا يزال يسجل ~12/18، إلخ)، فقط بناءً على معدلات المُسلَّم الحقيقية بدلاً من مخرجات الصيغة.
v4.0 (2026-05-11) — إصدار رئيسي. دورة v3.7-v3.10 تشكل مجتمعة إعادة كتابة هيكلية لنظام التصنيف، كبيرة بما يكفي لتبرير الترقية. الملخص: تم تغيير الحدود القصوى لبعديْن (الثقة 10→11، السعة 8→7)؛ تمت إعادة كتابة صيغة جودة المشغّل إلى max(verification, FTSO-derived) بحيث لا يمكن للمشاركة أن تضر؛ تم تخطي الأبعاد الأربعة المتبقية (Uptime و Fee و Delivery و Time Remaining) لإزالة حدود الانقطاع؛ تمت إضافة ثلاث مكونات نقاط جديدة (احتفاظ التفويض لمدة 30 يوماً، مسار السندات الذاتية لمدة 30 يوماً، الترقية التلقائية إلى الطبقة المختارة)؛ تم إدخال تجميع مشغّل متعدد العُقد لعدد الثقة والتركيز؛ طول العمر الآن محصّن ضد المسح عبر وجود حقبة reward-scripts؛ تم القضاء على حافزيْن منحرفيْن (عقوبة مشاركة FTSO لجودة المشغّل ومنحدر Uptime 95% المقلوب). كل مدخل للنقاط الآن قابل للتحقق خارجياً — لا توجد قرارات تحريرية حرجة. يمكن للمدققين كسب خط أساس المشغّل المختار +7 من خلال السلوك الملاحظ (ملاحظة 90+ يوماً، 25+ مفوّضين، عدم انخفاض الاحتفاظ، التوافق مع FIP-10)، لا حاجة لإرسال بريد إلى الفريق. انظر إلى إدخالات v3.7-v3.10 أدناه للتغييرات التفصيلية التي تتكون منها هذه الإصدارة.
v3.10 (2026-05-11) — أغلقت آخر فجوة قيمة في النقاط. كان خط أساس المشغّل المختار +7 على جودة المشغّل يتطلب سابقاً إدراجاً يدوياً في قائمة KNOWN_VALIDATORS الخاصة بنا، وهو كان الاختيار التحريري الوحيد المعنوي الذي تبقى بعد دورة مراجعة v3.7-v3.9. يضيف v3.10 مساراً ترقية تلقائية موضوعية: أي مدقق يحتوي على 90+ يوماً من مراقبة FlareWatch، 25+ مفوّضين مجمّعين من المشغّل، احتفاظ غير منخفض (انخفاض 30 يوماً ≤ 15%)، والتوافق مع FIP-10 للسندات الذاتية يندرج تلقائياً ضمن خط الأساس +7 — لا توجد حاجة لمراجعة يدوية. تبقى KNOWN_VALIDATORS كمسار سريع للمشغّلين المؤسسيين الذين لم يتراكموا بعد نافذة 90 يوماً (فكر في إدراج Ankr أو Kiln في يوم الإطلاق)، لكن الحالة النموذجية الآن مؤتمتة بالكامل. جميع المعايير الأربعة مشتقة من على السلسلة أو قريبة من على السلسلة (عدد المفوّضين، الاحتفاظ، السندات الذاتية) بالإضافة إلى طابع الملاحظة الخاص بنا — لا شيء ذاتي، لا بوابات إرسال بريد. التأثير الصافي: يمكن لمدقق كسب طبقة +7 من خلال السلوك وحده. معظم المشغّلين المقيمين على الشبكة بالفعل يستوفون المعايير اليوم.
v3.9 (2026-05-11) — تنظيف حدود الانقطاع عبر الأبعاد الأربعة المتبقية، بعد مراجعة كل جزء من النقاط للإنصاف. تم الإصلاح: (1) منحدر مقلوب منحرف في منحنى Uptime عند 95% — الانتقال من 94.99% → 95.00% خسر 4 نقاط (فرع 95-99% بدأ من 0 بدلاً من مطابقة أقصى الفرع السفلي وهو 4). نفس شكل الحافز العكسي الذي أصلحناه للتو في جودة المشغّل (v3.8). (2) تم تخطي عتبات معقولية الرسوم — قبل v3.9، يمكن لزيادة رسوم 0.01% عبر حد دلو أن تخسر ما يصل إلى 2.5 نقطة. الآن عبارة عن خطي متعدد الأجزاء مع منحدرات متزايدة الانحدار التي تحافظ على قيم الدلو عند الحدود (الرسوم المنخفضة بالكاد معاقبة، الرسوم الاستخراجية معاقبة بشدة). (3) تم تخطي عتبات موثوقية التسليم deliveryRatio — نفس النمط، حتى 2 نقطة من الانقطاعات تم حذفها. (4) تم تخطي عتبات دلو الوقت المتبقي — انقطاعات أصغر (أقصى 2 نقطة عند حد 14 يوماً) ولكن لا تزال موجودة في بعد صغير؛ الآن سلس. تم مراجعة Net Yield و MIRROR Participation و Capacity Profile والتأكد من أنها عادلة (بالفعل خطية / متواصلة). الحد الأقصى الإجمالي دون تغيير عند 100. لا توجد تراجعات في الدرجات حسب التصميم؛ المدققون الوحيدون الذين تتحرك درجاتهم هم من كانوا يجلسون بالضبط على حد دلو سابق.
v3.8 (2026-05-11) — تمت مراجعة بعد جودة المشغّل وإعادة كتابته بعد مراجعة الإنصاف. تم شحن ثلاث إصلاحات معاً. (1) القضاء على حافز منحرف — مشغّل معروف برصيد FTSO متوسط (على سبيل المثال 50) حقق 4 نقاط، لكن نفس المشغّل الذي يسقط من FTSO بالكامل حقق 7 نقاط. تحت v3.8 النقاط هي max(verification baseline, FTSO-derived)، بحيث لا يمكن لمشاركة FTSO إلا أن تساعد، لا تضر أبداً. (2) تم إدخال طبقة التحقق الوسيطة — المشغّلون مع أسماء مكتشفة تلقائياً من Flaremetrics أو FSE (لكن ليسوا بعد في خريطة KNOWN_VALIDATORS المختارة) يحصلون على +3 بدلاً من 0، مما يلطف منحدر 7→0 السابق. (3) يسطح الإشارات الاثنتين في تفصيل الانهيار عندما يفوز التحقق على درجة FTSO منخفضة (على سبيل المثال
v3.7 (2026-05-11) — تمت مراجعة بعد Community Trust وتوسيعه بعد مراجعة إنصاف المشغّل. ثلاث إضافات: (1) تجميع مشغّل متعدد العُقد — المشغّلون الذين يقومون بتشغيل عُقد P-Chain متعددة (AU و FlareBus و Aureus Ox و Kiln وغيرها) لديهم الآن عدد المفوّضين والرصيد الإجمالي المجمّع لإشارات عدد الثقة والتركيز، بحيث لا يتم معاقبتهم لتوزيع نفس قاعدة المفوّض عبر عُقد متعددة. (2) إشارة احتفاظ التفويض 30 يوماً (±0.5 نقطة) — تميز المدققين المتنامين / المستقرين / المتقلصين باستخدام مقارنة نافذة متزلجة. بُعد Trust الذي يعتمد على اللقطة الفوتوغرافية فقط لم يستطع تمييز هذه بعيداً عن بعضها البعض قبل v3.7. (3) مسار السندات الذاتية 30 يوماً (±0.5 نقطة) — يكافئ المشغّلين الذين يزيدون سنداتهم الذاتية بمرور الوقت، ويعاقب من يقومون بفك السندات بصمت. يختلف عن عقوبة التغيير المفاجئ التي تمسك فقط بقطرات واحدة كبيرة. تمت إعادة موازنة الحد: الثقة 10 → 11، السعة 8 → 7. إصلاحات الأخطاء من المراجعة: (أ) السندات الذاتية الصفرية الآن تضرب بشكل صحيح عقوبة sub-FIP-10 (كانت بوابة `selfBondFLR > 0` تترك السندات الذاتية بالضبط 0 للهروب سابقاً). (ب) نسب السندات الذاتية الصغيرة بين أرضية FIP-10 و 5% الآن تقدم النسبة المئوية الفعلية في لوحة الانهيار بحيث يرى المشغّلون ما يغلق الفجوة إلى طبقات +1 / +2. (ج) مكافأة طول العمر الآن محصّنة ضد المسح — يرجع إلى وجود حقبة reward-scripts عندما يكون أول ملاحظ KV طازج بشكل مصطنع.
v3.6 (2026-05-11) — إصلاحان لكشف MIRROR، تم شحنهما معاً. (أ) الكشف الآن يقرأ من مصدريْن كانونيين: أحداث RewardClaimed(claimType=3) على السلسلة من RewardManager V2 وتخصيصات claimType=3 في JSON FSP Merkle الرسمي (نفس البيانات التي تستهلكها أداة التوقيع الخاصة بـ Flare). أي إشارة كافية — تمسك المدققين الذين تم تخصيص MIRROR لهم لكن لم يتم المطالبة بهم على السلسلة بعد. (ب) كشف المراجعة الزائدة عن خطأ صيغة مفتاح منفصل: كان لدى validators:mirror-stats مفاتيح NodeID مختلطة hex20/cb58 (كتب الفهارس على السلسلة hex عندما لم يكن المدقق بعد في قائمة الأسماء المختارة الخاصة بنا)، في حين ابحثت كل مستهلك واجهة مستخدم بواسطة cb58 فقط — بحيث كانت حالة ~95 مدقق غير مرئية للعرض. الآن يتم تطبيع البحث لكل التنسيقات عبر جدول المدققين، لوحة تفصيل الدرجات، MIRROR-stats API العام، بطاقة Staking Positions في صفحة Yield، وجزء موفري FTSO. شهدت المدققات المتأثرة ارتفاع أبعاد مشاركة MIRROR وجودة المشغّل والدرجة الكلية FlareWatch بمقدار 9-10 نقاط في دورة cron التالية. تم اكتشاف ذلك من خلال تقرير موفر FTSO (FlareBus، 2026-05-11) — الفضل والشكر. كان ملاحظاتهم تحسن مادي لرؤية كل مفوّض للشبكة، لا فقط درجاتهم الخاصة.
v3.5 (2026-05-09) — Net Yield الآن يتم تثبيته بالوسيط مقابل APR للشبكة (مدقق عند الوسيط يسجل 12/18، أفضل الأداء تصل إلى 18، الربع الأقل ينخفض إلى 0). امتصت بعد الثقة محاذاة السندات الذاتية كمكون رابع (السندات الذاتية المتناسبة تكافئ الجلد في اللعبة؛ الطابق sub-FIP-10 يأخذ عقوبة صغيرة). شارة جديدة "NEW Xd" تسطح المدققين الذين لاحظتهم FlareWatch فقط لمدة <30 يوماً بحيث يمكن للمراهنين رؤية متى يكون السجل الحافل رقيقاً.
v3.4 (2026-05-09) — بعد Uptime الآن يمزج وقت التشغيل الفوري للـ RPC مع نسبة أهلية حقبة FIP-10 التاريخية. قبل v3.4 كان البعد غير تمييزي (92.9% من المدققات لديها وقت تشغيل 100% RPC). نسبة الموثوقية المشتقة من epochsUptimeEligible / epochsObserved عبر آخر 8 حقب reward-scripts — إشارة سلسلة زمنية تميز بشكل معنوي المدققات التي قد تفشل أحياناً الحد الأدنى من شروط FIP-10 عن تلك التي لا تفشل.
v3.3 (2026-05-09) — بعد التسليم الآن يستخدم معدل الوسط الموزون الزمني بشكل كبير (الحقب الحديثة تحسب أكثر، ثابت الاضمحلال 0.85) ويطبق عقوبة التباين (معامل التباين × 0.5، محدود برسم −30%). محسوبة من بيانات reward-scripts لكل حقبة — حجم العينة ينقل من خلال الكابح الثقة الحالي.
v3.2 (2026-05-09) — Community Trust متعدد الإشارات (العدد + التركيز + طول العمر)؛ تتبع أول-ملاحظ-بواسطة-FlareWatch مستمر في KV للمكافأة طول العمر؛ حافة stake-end (المدققات ضمن 14 يوماً من انتهاء الصلاحية نقاط 0 على الوقت المتبقي منذ لا يمكنهم قبول التفويضات الجديدة تحت FIP-10)؛ صفحة المنهجية أصبحت عامة؛ قناة ملاحظات المشغّل الموجهة؛ إصدار الخوارزمية المختوم على كل سجل درجة مخزنة مؤقتاً.
v3.1 (2026-05-09) — سلك بعد التسليم من بيانات reward-scripts؛ سلس جودة المشغّل (الاستيفاء الخطي)، السعة (وظيفة الخيمة)، والثقة (مقياس السجل)؛ أعاد تصنيف FSP-known + zero claimType=3 كـ MIRROR "غير نشط" بدلاً من "لا توجد بيانات"؛ استمر scoreBreakdown من جانب الخادم بحيث لا يعيد العميل الحساب بدون مدخلات كاملة.
v3 (2026-05-09) — استبدل المكافأة الثنائية الهوية بجودة المشغّل المستمرة. أضاف مشاركة MIRROR كبعد مخصص برسوم الممر. جعل السعة المحدودة محايدة بدلاً من عقوبة 0 نقطة. أزال العد المزدوج APY/Fee عبر Net Yield. معايير معايرة (فئة Top 90+، فئة قوية / جيدة / مقبولة / أقل من الوسيط).
v2 (قبل 2026-05-09) — النقاط الأصلية ذات 8 أبعاد (Uptime / APY / Fee / Identity / Capacity / Trust / Time / Delivery). تم التقاعد بسبب العد المزدوج APY/Fee، عقوبة الهوية الثنائية، عقوبة السعة المحدودة، لا توجد بعد MIRROR. موثقة للإشارة التاريخية.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.