هذا الأسبوع رتّبت وثائق رهن @Dusk من حالة التفعيل إلى الخروج على طول الخط، ثم اكتشفت أن الجملتين «الحد الأدنى 1000 DUSK، ولا توجد فترة انتظار بموجب اتفاقية» هما الأكثر عرضة لسوء الفهم. الرهن المباشر ليس مجرد أن تضغط على العملة وتنتظر معدل فائدة ثابتًا؛ بل يتطلب تشغيل provisioner مستمر ومتصل بالإنترنت وبعمله بشكل طبيعي. العائد يعتمد على ما إذا تم اختيارك للمشاركة في التوافق (consensus) وعلى نسبة الرهن الفعّال، وليس وعدًا بعائد ثابت من البروتوكول.

هناك أيضًا تفاصيل ضمن الجدول الزمني. يبدأ الـ stake الجديد فعاليته فقط عند «الحدّ التالي للـ epoch وما بعده». التقدير الرسمي بناءً على زمن إصدار الكتل المستهدف عادةً يكون حوالي 6—12 ساعة، لكن الأَدق دائمًا هو ما يظهر في المحفظة تحت «active from block». أمّا الخروج نفسه فلا توجد له فترة قفل بروتوكولية، لكنّه لا يقوم تلقائيًا بسحب المكافآت المتراكمة معًا؛ عملية سحب مكافآت withdraw هي إجراء منفصل.

الأكثر لفتًا للانتباه بالعكس هو الرهن الإضافي (top-up): بعد أن تصبح الحصة الأصلية active، فإن الجزء المضاف من top-up يدخل بنسبة 90% مباشرة إلى active، بينما يبقى 10% مسجّلًا كـ locked stake. الجزء المُقفل يظل ملكك، لكنه لا يشارك في الـ consensus. ولإعادة أخذ الطرف المتبقي، قد تحتاج إلى إلغاء الرهن بالكامل (unstake) للحصة المتبقية. هذا التصميم ليس سيئًا في ذاته، لكنه قد يجعل من يركّز فقط على APR الظاهر على اللوحة يحسب كفاءة رأس المال بشكل خاطئ.

يمكن لِبرك الأطراف الثالثة أن تُزيل عتبة متطلبات التشغيل (الـ运维)، لكن الاستضافة (custody) والعقود وطريقة تشغيل الجهة المشغّلة وقواعد الخروج تتحول إلى مجموعة أخرى من المخاطر. لذلك عندما أرى أن $DUSK سيتم رهنها، فالأمر لن يكون مجرد سؤال «كم العائد؟»، بل أيضًا: من الذي يمتلك العقد (node)؟ وكيف تُقسَّم المكافآت؟ وكيف تُدار الأجزاء locked؟ أما المستخدم #dusk فربما يكون أكثر ملاءمة لتشغيل عقدته بنفسه، أم أنه يفضّل قبول طبقة مخاطر من وجود pool مقابل عمليات أبسط؟