في الليلة الماضية، عندما كنت أتصفح مستندات TermMax الأمنية، اكتشفت أن تغيير الإعدادات الأساسية لا يسري فورًا. إعدادات Vault في TermMax تتضمن ثلاث خطوات: Submit → Wait → Accept: يقوم CURATOR بتقديم التغييرات، ويستطيع GUARDIAN خلال فترة الانتظار مراجعتها أو إلغاؤها، ويحتفظ Vault Owner بسلطة الإشراف. فترة الانتظار الافتراضية هي يوم واحد، ويمكن ضبطها ضمن النطاق من 1 إلى 30 يومًا.

أعتبرها أشبه بتذكرة تغيير لإحدى جهات التداول: يتم إغلاق المقترح، ثم يقوم فريق مراقبة المخاطر المناوب بمراجعته، ولا يُسمح بتحميله إلى قاعدة البيانات إلا بعد انتهاء العدّاد. التغييرات الخاصة بمصدر الـ Oracle لا يمكن تقديمها واستلامها إلا بواسطة DEFAULT_ADMIN_ROLE، ويتم تحديثها بشكل منفصل لكل أصل؛ وعند تعطل المصدر الأساسي يمكن التبديل فورًا إلى مصدر احتياطي. هذا التصميم يضيف نافذة مراقبة كما ويُدخل توزيع الصلاحيات الثلاث إلى فحوصات الأمان.

القفل الزمني يؤخر فقط تفعيل الإعدادات أو تغيير مصادر البيانات، لكنه لا يمكنه إثبات أن السعر الحالي دقيق، ولا يمكنه أن يحل محل المراقبة على السلسلة. ترتيب فحوصاتي هو: أولًا أراجع قائمة التنفيذ والوقت المتبقي، ثم أتحقق من سجلات الإلغاء وعناوين الأدوار، وأخيرًا أقارن الانحرافات بين المصدر الأساسي والاحتياطي وحالة التبديل. إذا لم يقم GUARDIAN بالمراجعة لفترة طويلة، وكانت مفاتيح الإدارة مركزة، فانتظار يوم إضافي يعني فقط تأجيل تجسيد المخاطر ليوم لاحق. الهيكل يضع كوابحًا، لكن من يراقب لوحة القياس عليه أن يجيب بما تسمح به سجلات التشغيل.@TermMax

#termmax