عندما قمتُ بتفكيك/التحليل لسير عمل تسوية TBV لرقم @BabylonLabs_io ، كانت أكثر انطباعية بالنسبة لي هي أن: من يَقوم بالتسوية لا يكسب “مكسبًا تحكميًا على مستوى الثواني”، بل يتحمّل جزءًا من المخاطر على مدى فترة من الزمن.

لنفترض أن BTC هبطت إلى خطّ التسوية. عندها يقوم liquidator بدفع USDC مقدمًا لسداد دين المقترض، وقد تكون عملية العقد والتوقيع سريعة. لكن المشكلة تأتي بعد ذلك، إذ تشير الوثائق إلى claim delay وchallenge period، ما يعني أن liquidator لن يحصل فورًا على الضمانات على شكل BTC، بل يجب أن ينتظر نهاية نافذة الإجراء. لقد تم بالفعل دفع الأموال مقدمًا، وما زال BTC لم يُستلم. خلال هذه الفترة، كيف يتحرك السعر—فإن المخاطر تكون عمليًا على عاتق liquidator.$BTC

وهذا يختلف كثيرًا عن منطق التسوية في DeFi التقليدي. فمعظم بروتوكولات الإقراض تتم على خطوة واحدة: سداد الدين، ثم استلام الضمانات، ثم الاستفادة من الخصم. نافذة المخاطر قصيرة جدًا. وبسبب أن TBV يحتاج إلى الاحتفاظ بآلية التحدّي في BitVM3، يتم تقسيم العملية إلى جزئين: الدفع أولًا، ثم الاستلام/الاحتياز لاحقًا. حدود الأمان أقوى، لكن الحسابات الاقتصادية لـliquidator تصبح أكثر تعقيدًا.$BABY

لذلك لا يمكن النظر فقط إلى BitVM3 والاعتقاد أن تكلفة النزاع منخفضة جدًا. النزاعات على السلسلة رخيصة، لكن هذا لا يعني أن التسوية رخيصة. ما يهم liquidator فعليًا هو: تجميد/احتجاز رأس المال، تقلبات BTC، الغاز، وتكلفة الفرصة لهذه فترة الانتظار، وهل توجد تعويضات كافية عن هذا الانتظار.#baby

إذا لم تكن التعويضات كافية، فقد يطلب liquidator خصمًا أعلى؛ وعندما يكون الخصم أعلى، يزداد الضغط على المقترضين. أما إذا كان الخصم غير كافٍ، فقد لا يرغب أحد في إجراء التسوية، فتتراكم مخاطر الديون المعدومة داخل النظام.

تصميم تسوية Babylon TBV ليس لنسخ تجربة “ثوانٍ” كما في Aave، بل لاستخدام نموذج أمان أقوى مقابل عتبة مشاركة أثقل. الأشخاص الذين يستطيعون تقبّل فترة الانتظار وتقلبات السعر هم وحدهم من سيقبلون أن يكونوا liquidator.$ETH