#baby $BABY لقد قمتُ بإعادة التحقق من قواعد انتهاء صلاحية TBV في شبكة الاختبار العامة الحالية مرةً أخرى، ولم أكتشف إلا بعد ذلك أن الصفحة مكتوب فيها أيضًا «Expired»، وأن المسؤولية الكامنة ليست هي نفسها تمامًا. النوع الأول هو أنه بعد حوالي 24 ساعة من إرسال الطلب، إذا لم يكن الطرفان المشاركان خارج السلسلة قد أنهيا التحضير، فإن الخزنة تصبح غير صالحة، وسيقوم النظام بإرجاع رسوم الإيداع. النوع الثاني هو أن العملية وصلت إلى مرحلة Verified، لكن المستخدم لم يُكمل تفعيل الحساب خلال حوالي 48 ساعة؛ عندها أيضًا تنتهي صلاحية الخزنة، ولكن لأن أعمال التنسيق السابقة كانت قد تمت، فلن تُسترد الرسوم. $BTC
لكن انتهاء الصلاحية لا يعني سحب BTC. معاملة Pre-PegIn نفسها تتضمن مخرجًا للرد (refund). بعد انتهاء فترة قفل شبكة الاختبار الحالية التي تبلغ قرابة 3 أيام، يمكن للمودِع أن يوقّع مباشرةً باستخدام مفاتيح Bitcoin الأصلية لاسترجاع الأصول عبر مسار الرد، دون الحاجة إلى استمرار تعاون مزود الخدمة. لنفترض أن تكلفة بناء المركز هي F؛ فعند فشل التحضير من جهة البروتوكول، تكون خسارة المستخدم 0. أما إذا أخطأ المستخدم نافذة التفعيل، فخسارته هي F. توجد طرق لعودة رأس المال، لكن إعادة الرسوم لا تعني أن BTC سيتحرر فورًا، وكون BTC يمكن استرجاعه في النهاية لا يعني أيضًا أن عملية الفشل بأكملها لا تتضمن وقتًا وتكاليف تشغيلية.
لذلك، ما يقلقني أكثر هو ما إذا كان بدءًا من @BabylonLabs_io سيتم عرض سبب انتهاء الصلاحية ونتيجة الرسوم ووقت العد التنازلي للرد بشكل منفصل. إن عرض «Expired» فقط يجعل من السهل خلط «النظام لم يكن جاهزًا» مع «لم يقم المستخدم بالخطوة الأخيرة»، ويجعل من غير الواضح أين تقع المسؤولية فعليًا. بالنسبة للمستخدمين العاديين، ما يستحق المراقبة أكثر من إجمالي حجم القفل هو: ما نسبته كل سبب انتهاء صلاحية على حدة، وكم يستغرق من انتهاء الصلاحية حتى يتم استرجاع BTC فعليًا، وكم شخصًا يخسر الرسوم دون داعٍ بسبب تفويت نافذة التفعيل. $BABY إذا كان الهدف هو تكوين احتياج طويل الأمد، فالمبدأ ليس أن تكون جميع العمليات ناجحة إلى الأبد، بل أن يُعرف المستخدم فورًا إلى أين ذهبت كل الأموال عند حدوث فشل. #baby
لكن انتهاء الصلاحية لا يعني سحب BTC. معاملة Pre-PegIn نفسها تتضمن مخرجًا للرد (refund). بعد انتهاء فترة قفل شبكة الاختبار الحالية التي تبلغ قرابة 3 أيام، يمكن للمودِع أن يوقّع مباشرةً باستخدام مفاتيح Bitcoin الأصلية لاسترجاع الأصول عبر مسار الرد، دون الحاجة إلى استمرار تعاون مزود الخدمة. لنفترض أن تكلفة بناء المركز هي F؛ فعند فشل التحضير من جهة البروتوكول، تكون خسارة المستخدم 0. أما إذا أخطأ المستخدم نافذة التفعيل، فخسارته هي F. توجد طرق لعودة رأس المال، لكن إعادة الرسوم لا تعني أن BTC سيتحرر فورًا، وكون BTC يمكن استرجاعه في النهاية لا يعني أيضًا أن عملية الفشل بأكملها لا تتضمن وقتًا وتكاليف تشغيلية.
لذلك، ما يقلقني أكثر هو ما إذا كان بدءًا من @BabylonLabs_io سيتم عرض سبب انتهاء الصلاحية ونتيجة الرسوم ووقت العد التنازلي للرد بشكل منفصل. إن عرض «Expired» فقط يجعل من السهل خلط «النظام لم يكن جاهزًا» مع «لم يقم المستخدم بالخطوة الأخيرة»، ويجعل من غير الواضح أين تقع المسؤولية فعليًا. بالنسبة للمستخدمين العاديين، ما يستحق المراقبة أكثر من إجمالي حجم القفل هو: ما نسبته كل سبب انتهاء صلاحية على حدة، وكم يستغرق من انتهاء الصلاحية حتى يتم استرجاع BTC فعليًا، وكم شخصًا يخسر الرسوم دون داعٍ بسبب تفويت نافذة التفعيل. $BABY إذا كان الهدف هو تكوين احتياج طويل الأمد، فالمبدأ ليس أن تكون جميع العمليات ناجحة إلى الأبد، بل أن يُعرف المستخدم فورًا إلى أين ذهبت كل الأموال عند حدوث فشل. #baby