قبل #termmax كنت أبحث في DeFi، ولديّ حركة ثابتة للغاية.
أفتح بروتوكولًا، ولا أنظر إلى APY ولا إلى TVL، بل أذهب مباشرةً لتفحّص الصلاحيات.
مرة رأيت مشروعًا يكتب “لامركزية عالية”. ثم نزلت إلى الأسفل، فوجدت أن معظم المعلمات الأساسية يمكن تعديلها بواسطة المسؤول مباشرةً تقريبًا. في تلك اللحظة كانت ردة فعلي الأولى هي إغلاق الصفحة.
لأنّه، في النهاية، وضع المال في عقدٍ ذكي لا يعني أن الخطر يختفي تلقائيًا.
ما جعلني مؤخرًا أعيد التفكير في هذه المسألة هو تصميم Timelock لدى TermMax.
لم يقل ببساطة إن “المدير لا يستطيع التعديل”. بل وضع مدة انتظار لتعديل المعلمات الحساسة.
وفقًا لآلية الجهة الرسمية، يجب أن يمر تعديل المعلمات بـ Submit → Wait → Accept: يتم التقديم أولًا، ثم الانتظار، وأخيرًا يمكن التنفيذ؛ وخلال فترة الانتظار يمكن لـ Guardian أيضًا إلغاء التعديل. مدة الانتظار الافتراضية هي يوم واحد، ويمكن ضبطها حتى 30 يومًا. والأكثر إثارة للاهتمام هو أن العمليات التي تقلّل المخاطر يمكن تنفيذها بسرعة أكبر، بينما تتطلب التعديلات التي تزيد المخاطر المرور بفترة الانتظار الكاملة.
لأن المؤسسات المالية في الواقع تعمل بالطريقة نفسها.
الخطر الحقيقي ليس في “أن شخصًا لديه المفتاح”، بل في ما إذا كان بإمكانه بعد الحصول على المفتاح فتح الباب فورًا.
إذا حدث تغيير كبير ومفاجئ في معلمة ما، فسوف يحتاج السوق على الأقل إلى معرفة ما الذي حدث، وتقييم الأثر، وضبط المراكز، بل وربما حتى الخروج.
لذلك يبدو أن Timelock مجرد مكوّن تقني، لكن جوهره في الواقع هو منح السوق وقتًا.
بالطبع، هو ليس تأمينًا ولا يمكنه القضاء على مخاطر العقود الذكية.
لكنني أزداد اقتناعًا بأن بروتوكول DeFi ناضجًا لا ينبغي أن يكتفي بإخبار المستخدم:
“من يمكنه تعديل القواعد.”
بل يجب أيضًا أن يخبر المستخدم:
“كم من الوقت لديك لمعرفة التغيير قبل أن تصبح القواعد مختلفة؟”
الأولى هي إدارة الصلاحيات.
والثانية هي إدارة المخاطر الحقيقية.
@TermMax #TermMax
أفتح بروتوكولًا، ولا أنظر إلى APY ولا إلى TVL، بل أذهب مباشرةً لتفحّص الصلاحيات.
مرة رأيت مشروعًا يكتب “لامركزية عالية”. ثم نزلت إلى الأسفل، فوجدت أن معظم المعلمات الأساسية يمكن تعديلها بواسطة المسؤول مباشرةً تقريبًا. في تلك اللحظة كانت ردة فعلي الأولى هي إغلاق الصفحة.
لأنّه، في النهاية، وضع المال في عقدٍ ذكي لا يعني أن الخطر يختفي تلقائيًا.
ما جعلني مؤخرًا أعيد التفكير في هذه المسألة هو تصميم Timelock لدى TermMax.
لم يقل ببساطة إن “المدير لا يستطيع التعديل”. بل وضع مدة انتظار لتعديل المعلمات الحساسة.
وفقًا لآلية الجهة الرسمية، يجب أن يمر تعديل المعلمات بـ Submit → Wait → Accept: يتم التقديم أولًا، ثم الانتظار، وأخيرًا يمكن التنفيذ؛ وخلال فترة الانتظار يمكن لـ Guardian أيضًا إلغاء التعديل. مدة الانتظار الافتراضية هي يوم واحد، ويمكن ضبطها حتى 30 يومًا. والأكثر إثارة للاهتمام هو أن العمليات التي تقلّل المخاطر يمكن تنفيذها بسرعة أكبر، بينما تتطلب التعديلات التي تزيد المخاطر المرور بفترة الانتظار الكاملة.
لأن المؤسسات المالية في الواقع تعمل بالطريقة نفسها.
الخطر الحقيقي ليس في “أن شخصًا لديه المفتاح”، بل في ما إذا كان بإمكانه بعد الحصول على المفتاح فتح الباب فورًا.
إذا حدث تغيير كبير ومفاجئ في معلمة ما، فسوف يحتاج السوق على الأقل إلى معرفة ما الذي حدث، وتقييم الأثر، وضبط المراكز، بل وربما حتى الخروج.
لذلك يبدو أن Timelock مجرد مكوّن تقني، لكن جوهره في الواقع هو منح السوق وقتًا.
بالطبع، هو ليس تأمينًا ولا يمكنه القضاء على مخاطر العقود الذكية.
لكنني أزداد اقتناعًا بأن بروتوكول DeFi ناضجًا لا ينبغي أن يكتفي بإخبار المستخدم:
“من يمكنه تعديل القواعد.”
بل يجب أيضًا أن يخبر المستخدم:
“كم من الوقت لديك لمعرفة التغيير قبل أن تصبح القواعد مختلفة؟”
الأولى هي إدارة الصلاحيات.
والثانية هي إدارة المخاطر الحقيقية.
@TermMax #TermMax
