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

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

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

الضعف الصريح: آليات الحرق تبدو أكثر أمانًا عندما تُوصف بمعزل عن العمق الحقيقي للسيولة لدى الرمز، والآن عمق سيولة BABY هو القصة كاملة، لا مجرد هامش فيها.

"الحرق الذي يُفترض أن يزيل العرض بهدوء قد يصبح أيضًا الشيء الذي يحرك السعر بصوت أعلى."

@BabylonLabs_io #baby $BABY $BANK $HOME
ما العامل الأكبر الذي يجعل نموذج حرق BABY يعمل كما هو مقصود؟