تجاوز إلى المحتوى الرئيسي
شعار Avana

إطار المخاطر

كيف تقترح Avana وتراجع وتنفّذ تغيّرات المخاطر عبر Hub وSpokes ضمان LP.

نظرة عامة

يعرّف إطار مخاطر Avana كيف تُقترَح تغيّرات المعلمات وتُفحَص وتُنفَّذ عبر Hub وSpokes ضمان LP. يغطي الضوابط المستخدمة عندما يعدّل البروتوكول سقوف التوريد والاقتراض، وإعدادات LT/LTV، ومدخلات معدل الفائدة، وحالة السوق، ومعلمات أخرى تعتمد على الأسعار والاستخدام وعمق الـ pool والتركيز والتقلب وسلوك الـ peg وقواطع الدائرة وصحة المركز والحالة ذات الصلة.

ضمان LP ليس فئة أصول متجانسة واحدة. يمكن لـ LPs المستقرة وLPs الأصول المترابطة وpools المرجّحة والسيولة المركّزة وتصاميم AMM أخرى أن تملك كل منها مسار خاصاً بالتقييم والتصفية وفشل الـ spoke. يوجد الإطار حتى تنعكس تلك الفروقات في عملية التحديث بدلاً من إخفائها خلف إعداد مخاطر عام واحد.

تبقى ثلاثة أدوار منفصلة طوال هذه العملية: Avana Risk Initiator وAvana Risk Guardian وAvana Risk Defender. الطرف الذي يوصي بتغيّر روتيني ليس نفس الطرف الذي يفحصه بشكل مستقل، والدور الذي يمكنه التصرف أثناء الطوارئ أضيق عمداً من المسار الروتيني.

قاعدة التشغيل: reducing risk should be easier than expanding it.

المبادئ الأساسية

فصل الأدوار

يُعيّن الإطار الاقتراح والمراجعة والاحتواء الطارئ لأطراف مختلفة حتى لا يتحكم طرف واحد بالمسار الكامل وحده.

تنفيذ مقيّد

تُنفَّذ تغيّرات المخاطر الروتينية فقط عندما تبقى داخل حدود السياسة المعرّفة مسبقاً وتجتاز فحوصات التحقق.

اتساق عام

يجب أن يكون التحديث الموصوف علناً هو نفس التحديث الذي يُدرَج فعلياً للتنفيذ.

وعي Spoke

يحمل كل spoke لضمان LP قواعد إدراج وافتراضات أوراكل ومسار تصفية وملف مخاطر خاصاً به.

تباين دفاعي

العملية منحازة عمداً بحيث يكون تقليص المخاطر أسرع وأبسط من توسيعها.

الأدوار

Avana Risk Initiator

الدور الذي يعد ويوصي بتغيّرات المخاطر الروتينية لـ Hub وSpokes ضمان LP.

  • انشر المبرر وصنّف التحديث كدفاعي أو موجّه للنمو
  • قدّم التحديثات الروتينية إلى مسار التنفيذ المقفول زمنياً
  • أوص بسقوف توريد وسقوف اقتراض وLT/LTV وعامل احتياطي وتغيّرات معدل فائدة داخل النطاقات المعتمدة
  • ابدأ تقليل المخاطر على مستوى الـ spoke وعلىboarding الـ pool داخل قوالب spoke معتمدة مسبقاً

Avana Risk Guardian

المراجع المستقل ذو سلطة النقض على التغيّرات الروتينية المُدرجة.

  • تحقق من أن التحديث المُدرج يطابق الإفصاح العام
  • تأكد من بقاء الإجراء داخل حدود السياسة المعتمدة
  • ارفض تحديثات مبنية على افتراضات أوراكل أو سيولة أو تصفية غير صالحة
  • ألغِ تحديثاً مُدرَجاً خلال نافذة القفل الزمني عندما يخلق عدم استقرار واضحاً على مستوى spoke أو hub

Avana Risk Defender

دور للطوارئ فقط يُستخدم لاحتواء الحوادث عندما يكون مسار القفل الزمني العادي بطيئاً جداً.

  • خفّض سقوف الاقتراض أو التوريد إلى مستويات دفاعية
  • جمّد الاقتراض الجديد على spoke أو جمّد استخدام الضمان لـ pool أو قالب أو spoke
  • عطّل محوّلاً أو مسار اقتراض محدداً عند تحقق شروط فشل معرّفة مسبقاً
  • احظر إنشاء دين جديد تحت ظروف الطوارئ دون استخدام ذلك للتحسين الروتيني أو إجراءات النمو

تدفق التحديث

تتبع التغيّرات الروتينية مسار ثابتاً حتى يتمكن البروتوكول من تمييز صيانة المعلمات العادية عن الاحتواء الطارئ. التسلسل القياسي هو إشعار عام، وتقديم، وفحوصات حدود، وقفل زمني، ومراجعة Guardian، وتنفيذ إذا لم يُنقَض الاقتراح.

1

إشعار عام

ينشر Risk Initiator التغيّر المقصود وسبب الحاجة إليه والنطاق المتوقع تأثره.

2

Submission

يضع Risk Initiator التغيّر المقترح في مسار التنفيذ الذي يستخدمه الإطار.

3

Validation

تؤكّد فحوصات الإطار أن التحديث يبقى داخل القيود المعرّفة مسبقاً وحدود السياسة المعتمدة.

4

Timelock

إذا نجح التحقق، يدخل التغيّر نافذة قفل زمني بدلاً من التنفيذ فوراً.

5

مراجعة Guardian

خلال القفل الزمني، يراجع Risk Guardian الحمولة المُدرجة الدقيقة ويمكنه إلغاءها إن لزم.

6

Execution

إذا نجا التغيّر من المراجعة، يُنفَّذ تلقائياً بعد انتهاء القفل الزمني.

7

مسار الطوارئ

إذا تحققت ظروف الطوارئ، يمكن لـ Risk Defender استخدام مسار دفاعياً منفصلاً بسلطة أضيق.

فئات المعلمات

لا تحمل كل تغيّرات المعلمات نفس المخاطر، لذا يجمعها الإطار حسب مقدار السلطة التي يجب أن تتطلبها وسرعة تمكّنها من التحرك.

تغيّرات دفاعية

هذه أسرع التغيّرات الروتينية لأنها تقلص تعرض البروتوكول.

  • خفض سقوف الاقتراض
  • خفض سقوف التوريد
  • تخفيض LTV أو عتبة التصفية
  • تجميد الاقتراض أو استخدام الضمان
  • تشديد إعدادات الـ spoke

تغيّرات روتينية محدودة

تتبع مسار Initiator -> Guardian -> قفل زمني القياسي داخل الحدود المعتمدة.

  • زيادات سقوف متواضعة
  • ضبط معلمات متواضع داخل النطاقات المعتمدة
  • إضافة pools جديدة داخل قالب spoke موجود

تغيّرات على مستوى الحوكمة

هذه خارج الإطار الروتيني وتتطلب مسار قرار أعلى مستوى.

  • إنشاء عائلة spoke جديدة
  • تفعيل بدائية LP جديدة
  • إضافة نموذج أوراكل جديد
  • تفعيل محوّل تصفية جديد
  • توسيع سطح المخاطر مادياً بما يتجاوز الافتراضات المعتمدة مسبقاً

الإفصاح العام

يجب نشر كل تحديث روتيني قبل التقديم بصيغة تتيح للمطوّرين والمستخدمين والمراجعين مقارنة الإشعار بالإجراء الدقيق الذي سيُدرَج لاحقاً.

الحد الأدنى لمعيار الإفصاح

  • الـ spoke المتأثر
  • الـ pools أو القوالب المتأثرة
  • المعلمات الحالية
  • المعلمات المقترحة
  • سبب التحديث
  • ما إذا كان التحديث دفاعياً أو موجّهاً للنمو
  • توقيت التقديم المتوقع
  • نافذة القفل الزمني المتوقعة
  • التبعيات أو الافتراضات ذات الصلة

يجعل الإفصاح المتسق مراجعة الاقتراح أسهل لاكتشاف زحف النطاق أو الافتراضات غير المتطابقة أو أخطاء التنفيذ البسيطة.

إجراءات الطوارئ

إجراءات الطوارئ للاحتواء، لا للضبط الروتيني. يجب استخدامها نادراً، وإبقاؤها ضيقة قدر الإمكان، وتنظيمها حتى يتمكن البروتوكول من العودة إلى المسار القياسي بمجرد فهم المخاطر الفورية. يجب أن يتصرف Risk Defender فقط عندما يجعل شرط فشل معرّف أو محتمل جداً مسار القفل الزمني العادي غير آمناً.

مشغّلات الطوارئ

  • عدم اتساق الأوراكل
  • تدهور مسار التصفية
  • سلوك pool غير طبيعي
  • فشل تبعية wrapper
  • اختراق على مستوى المحوّل
  • عدم استقرار مفاجئ على مستوى spoke

الإفصاح المطلوب بعد الإجراء

  • The trigger
  • الإجراء المتخذ
  • المدة المقصودة
  • المسار للعودة إلى التشغيل العادي

توجد سلطة الطوارئ فقط لحالات فشل معرّفة أو محتملة جداً يكون فيها انتظار المسار المقفول زمنياً العادي غير آمناً. ليست مسار للنمو الروتيني أو التحسين.

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