伊什塔尔

عبارة واحدة تقول "تمت تسوية هذا الربح والخسارة" لا تُعدّ في قواعد العقود الدائمة إلا تصريحًا بانتظار الحسم. وبالاستناد إلى نموذج مجمع السيولة متعدد الأصول في Tribe Perpetual، لنفترض أن مصير مركزٍ ما يعتمد على سلسلة من الأرقام تدفعها أوراكل خارجية. على مستوى الأعمال، ليس المطلوب هو كيفية تمرير الرسالة، بل ما إذا كان الحكم نفسه قائمًا على أساس متين: أيّ مركزٍ تحديدًا تشير إليه هذه الدعوى، وهل بيانات الأسعار المقدَّمة تطابقه، وهل يستطيع العقد على السلسلة إجراء التحقق بصورة مستقلة، وما الصلاحيات التي تمنحها نتيجة التحقق لمحرك التصفية. فإذا غابت عتبةُ القبول، أمكن لأي عقدة أن تقدّم تسعيرًا مُواتيًا؛ وإذا غابت الأدلة القابلة للمراجعة، فقد البروتوكول أساسًا يقبل به أو يرفض. لذلك، تقع oracle verification في الطبقة الوسطى من الحكم التجاري. فهي تحوّل "هذه الجهة أبلغت بهذه الطريقة" إلى "هذه البيانات قابلة للتدقيق"، ثم تسلّم نتيجة التدقيق إلى منطق التصفية. هذا الموقع هو الذي يحدد ما إذا كان يمكن تسوية المراكز بشكل متسق، كما يحدد ما إذا كانت مجموعة السيولة نفسها قادرة على التوسع إلى أزواج أصول أكثر، بدلًا من أن تكون مجرد ملاحظة عن تغذية الأسعار يمكن الاستغناء عنها. أما الأبحاث المتعلقة بنقل الأسعار منخفض الكمون والافتراضات الأمنية للمشتقات على السلسلة، فهي تضع نقطة الصعوبة هنا بالضبط: إذ تناقش الأوراق والحلول البنية التحتية تكلفة الأوراكل القائم على السحب (pull-based) وتأخره وحدود اللعب الاستراتيجي، وتستخدم سيناريو تصفية العقود الدائمة لتوضيح أهمية التحقق من الأسعار بالنسبة للمشتقات على السلسلة. وهذه لا تشكل سوى خلفية بحثية؛ فهي تشرح فقط لماذا يصعب قبول ادعاء السعر، ولا يمكن أن تُصاغ على أنها دليل على أن TMX قد دمج بالفعل حل أوراكل محددًا، فضلًا عن أن تكون دليلًا نهائيًا على معمارية المنتج. وتُظهر ممارسات DEX الدائمة المبكرة أيضًا أن مجمع السيولة لا يحتاج إلى الاعتماد على دفتر أوامر تقليدي كي ينجز تسوية قابلة للتحقق للمراكز عالية الرافعة؛ وهذا يضيف فقط إلى اتجاه أن صناعة السوق بكفاءة في رأس المال لا يلزمها الانتقال إلى CEX، ولا يشارك في عملية الحكم في هذا المقال. وعند العودة إلى ملاحظة حول مركز TMX، لا أترك سوى سؤال واحد: ما المعلومات القابلة للتحقق التي تسند حالة التصفية هذه؟ #termmax @TermMax

عبارة واحدة تقول "تمت تسوية هذا الربح والخسارة" لا تُعدّ في قواعد العقود الدائمة إلا تصريحًا بانتظار الحسم.

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

لذلك، تقع oracle verification في الطبقة الوسطى من الحكم التجاري. فهي تحوّل "هذه الجهة أبلغت بهذه الطريقة" إلى "هذه البيانات قابلة للتدقيق"، ثم تسلّم نتيجة التدقيق إلى منطق التصفية. هذا الموقع هو الذي يحدد ما إذا كان يمكن تسوية المراكز بشكل متسق، كما يحدد ما إذا كانت مجموعة السيولة نفسها قادرة على التوسع إلى أزواج أصول أكثر، بدلًا من أن تكون مجرد ملاحظة عن تغذية الأسعار يمكن الاستغناء عنها.

أما الأبحاث المتعلقة بنقل الأسعار منخفض الكمون والافتراضات الأمنية للمشتقات على السلسلة، فهي تضع نقطة الصعوبة هنا بالضبط: إذ تناقش الأوراق والحلول البنية التحتية تكلفة الأوراكل القائم على السحب (pull-based) وتأخره وحدود اللعب الاستراتيجي، وتستخدم سيناريو تصفية العقود الدائمة لتوضيح أهمية التحقق من الأسعار بالنسبة للمشتقات على السلسلة. وهذه لا تشكل سوى خلفية بحثية؛ فهي تشرح فقط لماذا يصعب قبول ادعاء السعر، ولا يمكن أن تُصاغ على أنها دليل على أن TMX قد دمج بالفعل حل أوراكل محددًا، فضلًا عن أن تكون دليلًا نهائيًا على معمارية المنتج.

وتُظهر ممارسات DEX الدائمة المبكرة أيضًا أن مجمع السيولة لا يحتاج إلى الاعتماد على دفتر أوامر تقليدي كي ينجز تسوية قابلة للتحقق للمراكز عالية الرافعة؛ وهذا يضيف فقط إلى اتجاه أن صناعة السوق بكفاءة في رأس المال لا يلزمها الانتقال إلى CEX، ولا يشارك في عملية الحكم في هذا المقال.

وعند العودة إلى ملاحظة حول مركز TMX، لا أترك سوى سؤال واحد: ما المعلومات القابلة للتحقق التي تسند حالة التصفية هذه؟
#termmax @TermMax

لقد قمت بتفكيك سردية "سعر الفائدة الثابت" الخاصة بـ TermMax وفق مسار الأموال. العنوان الذي يتحدث عن "تثبيت عائد قابل للتنبؤ" لافت للنظر، لكنه ليس حساب ادخار يضع الرموز داخل Vault ثم يوزّع الفائدة تلقائيًا. المسار الفعلي هو: المستخدم يضع عرضًا عند الاستحقاق في دفتر أوامر P2P، ويشتري المُقرض FT لتثبيت سعر الفائدة، بينما يودع المقترض ضمانات للحصول على GT مع الرافعة المالية؛ أما المستخدم الذي يريد سهولة الاستخدام فيضع أمواله في Curator Vault، حيث يقوم هذا الأخير بالتناوب بين مجمعات سيولة معزولة لاقتناص فروق الأسعار. في المنتصف هناك أربع طبقات: مطابقة الأوامر، وحفظ الضمانات، وتصفية الرافعة، وتنظيم الاستراتيجيات. @TermMax_ts يستخدم FT/GT لفصل الدين والرافعة إلى عقود استحقاق، وCurator يلتقط فرق العائد، والتسليم الفعلي يحل محل دعم مجمعات السيولة. هذا أقرب إلى رهن عقاري بسعر فائدة ثابت على أصل سكني ثم تسليمه لمدير صندوق كي ينفذ تداولات برافعة مالية. كون سند الملكية لا يزال في يدك لا يعني أن المقترض لن يُصفّى، ولا يعني أيضًا أن مدير الصندوق سيتمكن من تغطية التكاليف. لكن المخاطر لا يمكن قراءتها من وسم "سعر فائدة ثابت" وحده. سيولة دفتر أوامر P2P مجزأة، وقد تنتهي عروض الأسعار دون أن يطابقها أحد عند الاستحقاق؛ تقلبات الضمانات في جانب الاقتراض قد تؤدي إلى تصفية GT؛ وإذا حدث تعثر في التسليم الفعلي، فستحصل على أصل ضماني مخصوم القيمة بدلًا من رأس المال — وإذا كان الأصل الأساسي رمزًا منخفض السيولة أو RWA، فقد تلتهم خسائر التسييل كامل العائد. اختيار المجمع وإدارة الرسوم في Curator Vault قد يآكلان العائد الصافي؛ والرافعة بنقرة واحدة لا تعني أن نسبة الضمان لن تُكسر في هبوط حاد مفاجئ. الوثائق مليئة بعبارات could و aim to، أما TVL التاريخي والمحافظ المسجلة فهما من الماضي، والاحتفاظ الحقيقي بعد TGE لا يزال مجهولًا. لذلك أنا مع #TMX أركز أكثر على دورة الأموال المغلقة، لا على قائمة البروتوكولات الزرقاء في صفحة التكاملات. إذا أراد TMX إثبات أنه ليس "الفكرة تسبق المنتج"، فعليه أن يكشف في الوقت نفسه عن: معدل نجاح مطابقة الأوامر وزمن التنفيذ، وسجل تصفيات GT والانزلاق السعري، ونسبة الخصم عند التسليم الفعلي، والعائد السنوي بعد الرسوم في Vault وأقصى هبوط، وسجل أمان OFT عبر السلاسل، وكذلك تأثير فتح الرموز على تخفيف عائدات الستيكينغ. سعر الفائدة الثابت يجيب عن سؤال "هل سيتغير العائد؟" لكنه لا يجيب عن سؤال "هل يمكن استرداد أصل رأس المال كاملًا عند الاستحقاق؟". PENDLE MORPHO AAVE #termmax @termmax $BTC

لقد قمت بتفكيك سردية "سعر الفائدة الثابت" الخاصة بـ TermMax وفق مسار الأموال. العنوان الذي يتحدث عن "تثبيت عائد قابل للتنبؤ" لافت للنظر، لكنه ليس حساب ادخار يضع الرموز داخل Vault ثم يوزّع الفائدة تلقائيًا. المسار الفعلي هو: المستخدم يضع عرضًا عند الاستحقاق في دفتر أوامر P2P، ويشتري المُقرض FT لتثبيت سعر الفائدة، بينما يودع المقترض ضمانات للحصول على GT مع الرافعة المالية؛ أما المستخدم الذي يريد سهولة الاستخدام فيضع أمواله في Curator Vault، حيث يقوم هذا الأخير بالتناوب بين مجمعات سيولة معزولة لاقتناص فروق الأسعار. في المنتصف هناك أربع طبقات: مطابقة الأوامر، وحفظ الضمانات، وتصفية الرافعة، وتنظيم الاستراتيجيات.

@TermMax_ts يستخدم FT/GT لفصل الدين والرافعة إلى عقود استحقاق، وCurator يلتقط فرق العائد، والتسليم الفعلي يحل محل دعم مجمعات السيولة. هذا أقرب إلى رهن عقاري بسعر فائدة ثابت على أصل سكني ثم تسليمه لمدير صندوق كي ينفذ تداولات برافعة مالية. كون سند الملكية لا يزال في يدك لا يعني أن المقترض لن يُصفّى، ولا يعني أيضًا أن مدير الصندوق سيتمكن من تغطية التكاليف.

لكن المخاطر لا يمكن قراءتها من وسم "سعر فائدة ثابت" وحده. سيولة دفتر أوامر P2P مجزأة، وقد تنتهي عروض الأسعار دون أن يطابقها أحد عند الاستحقاق؛ تقلبات الضمانات في جانب الاقتراض قد تؤدي إلى تصفية GT؛ وإذا حدث تعثر في التسليم الفعلي، فستحصل على أصل ضماني مخصوم القيمة بدلًا من رأس المال — وإذا كان الأصل الأساسي رمزًا منخفض السيولة أو RWA، فقد تلتهم خسائر التسييل كامل العائد. اختيار المجمع وإدارة الرسوم في Curator Vault قد يآكلان العائد الصافي؛ والرافعة بنقرة واحدة لا تعني أن نسبة الضمان لن تُكسر في هبوط حاد مفاجئ. الوثائق مليئة بعبارات could و aim to، أما TVL التاريخي والمحافظ المسجلة فهما من الماضي، والاحتفاظ الحقيقي بعد TGE لا يزال مجهولًا.

لذلك أنا مع #TMX أركز أكثر على دورة الأموال المغلقة، لا على قائمة البروتوكولات الزرقاء في صفحة التكاملات. إذا أراد TMX إثبات أنه ليس "الفكرة تسبق المنتج"، فعليه أن يكشف في الوقت نفسه عن: معدل نجاح مطابقة الأوامر وزمن التنفيذ، وسجل تصفيات GT والانزلاق السعري، ونسبة الخصم عند التسليم الفعلي، والعائد السنوي بعد الرسوم في Vault وأقصى هبوط، وسجل أمان OFT عبر السلاسل، وكذلك تأثير فتح الرموز على تخفيف عائدات الستيكينغ. سعر الفائدة الثابت يجيب عن سؤال "هل سيتغير العائد؟" لكنه لا يجيب عن سؤال "هل يمكن استرداد أصل رأس المال كاملًا عند الاستحقاق؟".

PENDLE MORPHO AAVE
#termmax @TermMax $BTC

اليوم نغيّر منظورنا التقني ونتعمّق أكثر في نقطة بنيوية ناقصة في تصميم خزينة TermMax: حظر أوامر الاقتراض ضمن نطاق مرتبط بمخزن الأموال. كثير من المستخدمين عند دراسة الورقة البيضاء قد يتخطّون بسهولة هذه المعلمات الطلبية الغامضة، لكن هذا القيد البرمجي الصغير—في الواقع—يقفل مباشرة مساحة بقاء الخزينة في المواجهات الصعبة أمام رياح معاكسة. في بيئة DeFi المعقّدة، فإن استراتيجية عائد ناضجة ليست مجرد إيداع الأموال وكسب الفائدة. عادةً ما يستخدم مديرو الأموال المحترفون أوامر الاقتراض ضمن نطاق لبناء تحوط ثنائي الاتجاه، أو إجراء تعديلات ديناميكية على المراكز ضمن نطاقات سعرية محددة، وذلك لعزل مخاطر الانخفاض من جهة واحدة. لكن TermMax حرَم البروتوكول مباشرةً منظّمي المحتوى من هذه الأدوات. وهذا يؤدي إلى وضعٍ محرج للغاية: بغضّ النظر عن مدى دقة إعداد منظّمي المحتوى للاحتياطي الأولي، وبغض النظر عن كيفية قيامهم بضبط حدود السعة بشكل متكرر، فإن اتجاه استراتيجية كامل مجمع الأموال يُفرض بالقوة ليصبح “مركز شراء ميت” فقط. وعندما يواجه السوق الأوسع عملية نزع رافعة على مستوى النظام، لا يملك منظّمو المحتوى أي وسيلة للتحوط أو الرد لمواجهة ذلك سوى مراقبة جفاف السيولة لأصول الديون الأساسية. إن مساحة الاستراتيجية الناقصة هذه تجعلها بالضرورة لعبة “مخصصة للأسواق الصاعدة” فقط. لكشف حقيقة هذه الاستراتيجية الزائفة المزعومة كأنها تعمل على مدار العام، يكفينا أن نقتطع أيامًا شديدة متعلقة بالأصول الرئيسية حيث يتجاوز الهبوط اليومي في سعرها 15%، ثم نقارن مقدار الانسحاب (الـ drawdown) لهذه الخزينة بفرق الانسحاب لدى بروتوكولات استراتيجيات محايدة من نفس الفئة. إذا ظهرت القيمة الصافية في ظل هذا الضغط كأنها سقوط حر عمودي، فهذا يثبت أن صلاحية التشغيل الممنوحة بهذه الصيغة المبتورة كانت شديدة اللامسؤولية. كمستثمر عقلاني، من غير المسموح أبدًا أن تضع الأموال الثقيلة لدى بروتوكول “نصف مُنجز” يفتقر حتى إلى أدوات التحوط. #termmax @termmax $BTC

اليوم نغيّر منظورنا التقني ونتعمّق أكثر في نقطة بنيوية ناقصة في تصميم خزينة TermMax: حظر أوامر الاقتراض ضمن نطاق مرتبط بمخزن الأموال. كثير من المستخدمين عند دراسة الورقة البيضاء قد يتخطّون بسهولة هذه المعلمات الطلبية الغامضة، لكن هذا القيد البرمجي الصغير—في الواقع—يقفل مباشرة مساحة بقاء الخزينة في المواجهات الصعبة أمام رياح معاكسة.

في بيئة DeFi المعقّدة، فإن استراتيجية عائد ناضجة ليست مجرد إيداع الأموال وكسب الفائدة. عادةً ما يستخدم مديرو الأموال المحترفون أوامر الاقتراض ضمن نطاق لبناء تحوط ثنائي الاتجاه، أو إجراء تعديلات ديناميكية على المراكز ضمن نطاقات سعرية محددة، وذلك لعزل مخاطر الانخفاض من جهة واحدة. لكن TermMax حرَم البروتوكول مباشرةً منظّمي المحتوى من هذه الأدوات.

وهذا يؤدي إلى وضعٍ محرج للغاية: بغضّ النظر عن مدى دقة إعداد منظّمي المحتوى للاحتياطي الأولي، وبغض النظر عن كيفية قيامهم بضبط حدود السعة بشكل متكرر، فإن اتجاه استراتيجية كامل مجمع الأموال يُفرض بالقوة ليصبح “مركز شراء ميت” فقط. وعندما يواجه السوق الأوسع عملية نزع رافعة على مستوى النظام، لا يملك منظّمو المحتوى أي وسيلة للتحوط أو الرد لمواجهة ذلك سوى مراقبة جفاف السيولة لأصول الديون الأساسية.

إن مساحة الاستراتيجية الناقصة هذه تجعلها بالضرورة لعبة “مخصصة للأسواق الصاعدة” فقط. لكشف حقيقة هذه الاستراتيجية الزائفة المزعومة كأنها تعمل على مدار العام، يكفينا أن نقتطع أيامًا شديدة متعلقة بالأصول الرئيسية حيث يتجاوز الهبوط اليومي في سعرها 15%، ثم نقارن مقدار الانسحاب (الـ drawdown) لهذه الخزينة بفرق الانسحاب لدى بروتوكولات استراتيجيات محايدة من نفس الفئة. إذا ظهرت القيمة الصافية في ظل هذا الضغط كأنها سقوط حر عمودي، فهذا يثبت أن صلاحية التشغيل الممنوحة بهذه الصيغة المبتورة كانت شديدة اللامسؤولية. كمستثمر عقلاني، من غير المسموح أبدًا أن تضع الأموال الثقيلة لدى بروتوكول “نصف مُنجز” يفتقر حتى إلى أدوات التحوط.
#termmax @TermMax $BTC

أمسكت الهاتف وفتحت كتاب TermMax الأبيض في تلك الليلة، وكنت أفكر طوال الوقت: هل ما ينقص سوق الإقراض والاقتراض في DeFi حقًا هو عائد أعلى، أم ذلك اليقين بأنك تعرف مسبقًا «كم ستستعيده بعد أن تقرض»؟ الآن معظم البروتوكولات تغيّر الفائدة تبعًا لاستخدام السوق كل دقيقة؛ اليوم يتم قفلها على 4%، وغدًا لا يبدو أمرًا مستبعدًا أن تقفز إلى 12%. @termmax لم يَعجَل TermMax بالمنافسة على APY داخل معدلات فائدة عائمة، بل جعل «يقين الفائدة» هو المنتج الأساسي. الوثائق الرسمية تقولها بوضوح: من خلال بنية ثلاثية للرموز، يتم تقسيم الديون إلى «سندات أصلية/مطالبات رأس المال» و«حقوق العائد المتبقية»، ويعمل كل سوق بترتيب دفتر أوامر مستقل. يقوم Curator برسم منحنى التسعير، وتأتي العزلة الطبيعية بين الـ Vaults. لكن «الفائدة الثابتة» لا تعني أنه يمكنك القفل متى ما تريد. فهمت ذلك بعد قراءة الـ whitepaper: كل سوق آجال مستقلة تشكّل حوضًا خاصًا بها. عندما لا يكون عمق عروض Maker كافيًا، فإن التنفيذ سيرفض مباشرة (revert). لا يوجد ما يضمن تعويضًا من طرف البروتوكول في حال التعثر؛ بل يتم التعامل عبر تسليم فعلي: يحصل المقرض على أصول الضمان بنسبة محددة—فمثلًا إذا أقرضت USDC بهدف الحصول على عائد ثابت، فقد ينتهي بك الأمر إلى استلام WETH. أما الـ APR المعروض على الصفحة فيمكن اعتباره مرجعًا فقط. ومن ناحية الأمان أيضًا يجب توضيح الصورة. يعتمد المشروع على نظام مُنبئَيْن (dual oracles)، وقد تؤثر مخاطر العقود الذكية وكذلك ازدحام الشبكة على عملية التصفية. قدمت DeFiSafety تقييمًا 93%، لكن ارتفاع الدرجة لا يعني عدم وجود «مطبات» على مستوى التشغيل؛ يلزم الاعتماد على Curator المحترف للحفاظ على عمق دفتر الأوامر. لذلك رأيي هو أن TermMax أقرب إلى مجموعة أدوات لعقود فائدة بهيكل آجال (term structure)، ولا علاقة لها تمامًا بحسابات/تخطيط مالي جارٍ (demand/working capital) من هذا النوع. والأفضل التركيز على دقة تسعير Curator، وعمق دفتر الأوامر في كل سوق آجال، إضافةً إلى سيولة أصول الضمان في سيناريوهات التسليم الفعلي—ثم إعادة التقييم بعد TGE ومشاهدة تقلبات سوقية أكثر. ما رأيك في فكرة تصميم يجعل «يقين الفائدة» هو المنتج الأساسي؟ #termmax $BTC

أمسكت الهاتف وفتحت كتاب TermMax الأبيض في تلك الليلة، وكنت أفكر طوال الوقت: هل ما ينقص سوق الإقراض والاقتراض في DeFi حقًا هو عائد أعلى، أم ذلك اليقين بأنك تعرف مسبقًا «كم ستستعيده بعد أن تقرض»؟ الآن معظم البروتوكولات تغيّر الفائدة تبعًا لاستخدام السوق كل دقيقة؛ اليوم يتم قفلها على 4%، وغدًا لا يبدو أمرًا مستبعدًا أن تقفز إلى 12%. @TermMax

لم يَعجَل TermMax بالمنافسة على APY داخل معدلات فائدة عائمة، بل جعل «يقين الفائدة» هو المنتج الأساسي. الوثائق الرسمية تقولها بوضوح: من خلال بنية ثلاثية للرموز، يتم تقسيم الديون إلى «سندات أصلية/مطالبات رأس المال» و«حقوق العائد المتبقية»، ويعمل كل سوق بترتيب دفتر أوامر مستقل. يقوم Curator برسم منحنى التسعير، وتأتي العزلة الطبيعية بين الـ Vaults.

لكن «الفائدة الثابتة» لا تعني أنه يمكنك القفل متى ما تريد. فهمت ذلك بعد قراءة الـ whitepaper: كل سوق آجال مستقلة تشكّل حوضًا خاصًا بها. عندما لا يكون عمق عروض Maker كافيًا، فإن التنفيذ سيرفض مباشرة (revert). لا يوجد ما يضمن تعويضًا من طرف البروتوكول في حال التعثر؛ بل يتم التعامل عبر تسليم فعلي: يحصل المقرض على أصول الضمان بنسبة محددة—فمثلًا إذا أقرضت USDC بهدف الحصول على عائد ثابت، فقد ينتهي بك الأمر إلى استلام WETH. أما الـ APR المعروض على الصفحة فيمكن اعتباره مرجعًا فقط.

ومن ناحية الأمان أيضًا يجب توضيح الصورة. يعتمد المشروع على نظام مُنبئَيْن (dual oracles)، وقد تؤثر مخاطر العقود الذكية وكذلك ازدحام الشبكة على عملية التصفية. قدمت DeFiSafety تقييمًا 93%، لكن ارتفاع الدرجة لا يعني عدم وجود «مطبات» على مستوى التشغيل؛ يلزم الاعتماد على Curator المحترف للحفاظ على عمق دفتر الأوامر.

لذلك رأيي هو أن TermMax أقرب إلى مجموعة أدوات لعقود فائدة بهيكل آجال (term structure)، ولا علاقة لها تمامًا بحسابات/تخطيط مالي جارٍ (demand/working capital) من هذا النوع. والأفضل التركيز على دقة تسعير Curator، وعمق دفتر الأوامر في كل سوق آجال، إضافةً إلى سيولة أصول الضمان في سيناريوهات التسليم الفعلي—ثم إعادة التقييم بعد TGE ومشاهدة تقلبات سوقية أكثر. ما رأيك في فكرة تصميم يجعل «يقين الفائدة» هو المنتج الأساسي؟
#termmax $BTC

بالأمس تأخرت في السهر مرة أخرى، وراجعت آليات التسوية وإدارة المخاطر الخاصة بـ @termmax . في الأصل كنت أريد فقط دراسة كيفية تحديد خط التسوية، وكيف تسير منطق التصفية في ظل ظروف السوق القصوى. لكن كلما حسبت أكثر أصبحت الأمور أكثر إثارة للاهتمام. في المجموعة كان الجميع يمرّرون المشاركات ويتناقشون حول كم يمكن أن يضاعف افتتاح TMX، وهل سيتسبب كبار المستثمرين في ضغوط بيع قوية تؤدي إلى انهيار. ومع ذلك، فإن الورقة البيضاء، من حيث كيفية التعامل مع مخاطر الذيول وبلُغة أنيقة ومرنة، كانت أروع بكثير من تقلبات سعر العملة على المدى القصير. لقد ظلّ DeFi ينادي طوال هذه المدة بدخول المؤسسات، وبأن يحل محل البنوك التقليدية. لكن بمجرد أن يحدث “غراب أسود”، تقع التصفية القسرية، بل وحتى تتصفّى بالكامل ويُمسح الحساب بالقيمة إلى الصفر عبر اجتياز الحد—مستوى إدارة المخاطر هذا… كيف يمكن أن يجذب حقًا أموالًا بحجم مؤثر؟ في السابق، ضمن آليات التسوية التقليدية، كان المُصفّي يعتمد على الأرباح والجزاءات لاقتناص الفرص. كان المقترض يتحمل انزلاقًا كبيرًا من نوع خسائر ضخمة، ومع أي تقلب حاد في السوق بسهولة تنشأ موجات تسوية متتابعة (تصفية تسلسلية)، وكان “الهامش الوقائي” رقيقًا كالورق. بينما يَظهر أن حوض التمويل يحقق عوائد سنوية مرتفعة، إلا أن الأمر في الواقع يعتمد على قيام المستخدمين العاديين بدفع الثمن واستيعاب مخاطر الطرف الذيل. TermMax غيّر طريقة التسوية. فهو يُدخل نسب ضمان قابلة للتعديل عند التحويل، ومنطقة وسادة إنذار مسبق، بالتكامل مع مطابقة عمق “Range Order AMM” على السلسلة. وبهذا تتحول عملية التسوية من “قَطع عنيف وانحدار حاد” إلى “خروج سلس تدريجي”. وحتى إن النظام يمكنه، وفقًا لعمق سيولة الأصول، تعديل مساحة التحكيم والإغلاق (البيع/التسوية) في الوقت الحقيقي. هكذا لا تمنح المُصفّي فرصة للنهب بسوء نية، وفي الوقت نفسه تضمن الاستيعاب الفوري للديون المعدومة الأساسية والتحوط منها. هذا التصميم الذي يُسند إدارة المخاطر بالكامل إلى لعبة رياضية ومطابقة خوارزمية، يعزل مخاطر الذيل داخل “قفص منطقي” صارم. بالطبع لا بد من مراقبة تقلبات السوق بعد TGE، وكذلك حالات انقطاع السيولة، لكن TermMax يحوّل الشيء الذي تخشاه المؤسسات أكثر—وهو “عدم اليقين في التسوية”—إلى وحدة نمطية قياسية لإدارة المخاطر. عند إغلاق الوثائق، لم يخطر ببالي فقط “هل هذا بروتوكول آخر لإصدار العملات سيَصعد أم لا”، بل شعرت أنه حقًا يكمل لوحة الأساس في DeFi. قاعدة أمان متينة كهذه تثير الحماس أكثر من معرفة مقدار ارتفاع TMX. #termmax $BTC

بالأمس تأخرت في السهر مرة أخرى، وراجعت آليات التسوية وإدارة المخاطر الخاصة بـ @TermMax . في الأصل كنت أريد فقط دراسة كيفية تحديد خط التسوية، وكيف تسير منطق التصفية في ظل ظروف السوق القصوى. لكن كلما حسبت أكثر أصبحت الأمور أكثر إثارة للاهتمام. في المجموعة كان الجميع يمرّرون المشاركات ويتناقشون حول كم يمكن أن يضاعف افتتاح TMX، وهل سيتسبب كبار المستثمرين في ضغوط بيع قوية تؤدي إلى انهيار. ومع ذلك، فإن الورقة البيضاء، من حيث كيفية التعامل مع مخاطر الذيول وبلُغة أنيقة ومرنة، كانت أروع بكثير من تقلبات سعر العملة على المدى القصير.

لقد ظلّ DeFi ينادي طوال هذه المدة بدخول المؤسسات، وبأن يحل محل البنوك التقليدية. لكن بمجرد أن يحدث “غراب أسود”، تقع التصفية القسرية، بل وحتى تتصفّى بالكامل ويُمسح الحساب بالقيمة إلى الصفر عبر اجتياز الحد—مستوى إدارة المخاطر هذا… كيف يمكن أن يجذب حقًا أموالًا بحجم مؤثر؟

في السابق، ضمن آليات التسوية التقليدية، كان المُصفّي يعتمد على الأرباح والجزاءات لاقتناص الفرص. كان المقترض يتحمل انزلاقًا كبيرًا من نوع خسائر ضخمة، ومع أي تقلب حاد في السوق بسهولة تنشأ موجات تسوية متتابعة (تصفية تسلسلية)، وكان “الهامش الوقائي” رقيقًا كالورق. بينما يَظهر أن حوض التمويل يحقق عوائد سنوية مرتفعة، إلا أن الأمر في الواقع يعتمد على قيام المستخدمين العاديين بدفع الثمن واستيعاب مخاطر الطرف الذيل.

TermMax غيّر طريقة التسوية. فهو يُدخل نسب ضمان قابلة للتعديل عند التحويل، ومنطقة وسادة إنذار مسبق، بالتكامل مع مطابقة عمق “Range Order AMM” على السلسلة. وبهذا تتحول عملية التسوية من “قَطع عنيف وانحدار حاد” إلى “خروج سلس تدريجي”. وحتى إن النظام يمكنه، وفقًا لعمق سيولة الأصول، تعديل مساحة التحكيم والإغلاق (البيع/التسوية) في الوقت الحقيقي. هكذا لا تمنح المُصفّي فرصة للنهب بسوء نية، وفي الوقت نفسه تضمن الاستيعاب الفوري للديون المعدومة الأساسية والتحوط منها.

هذا التصميم الذي يُسند إدارة المخاطر بالكامل إلى لعبة رياضية ومطابقة خوارزمية، يعزل مخاطر الذيل داخل “قفص منطقي” صارم. بالطبع لا بد من مراقبة تقلبات السوق بعد TGE، وكذلك حالات انقطاع السيولة، لكن TermMax يحوّل الشيء الذي تخشاه المؤسسات أكثر—وهو “عدم اليقين في التسوية”—إلى وحدة نمطية قياسية لإدارة المخاطر. عند إغلاق الوثائق، لم يخطر ببالي فقط “هل هذا بروتوكول آخر لإصدار العملات سيَصعد أم لا”، بل شعرت أنه حقًا يكمل لوحة الأساس في DeFi. قاعدة أمان متينة كهذه تثير الحماس أكثر من معرفة مقدار ارتفاع TMX.
#termmax $BTC

我拉完Babylon最近的链上交互数据后，发现了一个非常魔幻的现象：散户都在盯着双质押的表面APR，却完全忽略了写在智能合约底层的准入天花板。我刚看白皮书时，也理所当然地把BABY塞进了“治理币混口饭吃”的分类里。直到我把FP的入驻条件拆解到底层，才发现大错特错。

BABY 根本不是负责活跃气氛的，它是整个系统不崩盘的底座。

提到“共质押”，人们总以为是天上掉两份馅饼。但Babylon的内核极为严苛：FP节点想吸收更多散户的BTC，它的接单上限完全是被自身质押的BABY数量卡死的。这绝非单纯的利益分配，而是冷冰冰的验资程序。

这背后的博弈很精彩：如果FP可以不质押BABY就去接管BTC，那它作恶的成本就是散户的本金，自己稳赚不赔。BABY的自押要求，就是给节点戴上紧箍咒，让它的个人资产和散户委托同生共死。这不是让你多赚钱的门路，而是让你作恶前先摸摸自己口袋底线的达摩克利斯之剑。

传统的治理代币，逻辑是“持币就有权，涨跌靠喊单”。但在Babylon的生态里，BABY的逻辑是“锁仓才有路，上限靠BTC”。没有BABY，你连当FP的资格都没有。就像在ETH生态里运行Validator必须要有底层资产一样，BABY是Babylon的入场券。

如果说把BTC跨链是资产层面的互通，那BABY更像是一个物理层面上的过载保护开关。BTC提供共识动力，BABY负责给每一个节点限流，确保风险可控。BABY看着是个可以炒作的币，但本质上干的是协议调控的苦力活。这种将节点利益与委托资产强行挂钩的机制，才是维系整个共识安全的核心制动系统。
#baby $BABY

انتبه أكثر لتغيّرات الحالة على سلسلة Babylon، وستكتشف أن كل يوم هناك مزوّد نهائية (Finality Provider - FP) يدخل ويخرج من القائمة النشطة. كثير من المستثمرين يشعرون بالحيرة، لكن السبب كله مكتوب في قواعد القبول الخاصة بالعقد الذكي. في Babylon عندما تلعب دور التست (الاستيكينغ)، إذا لم تأخذ نسبة الاكتتاب الذاتي لـ $BABY على محمل الجد، فالضرر في النهاية لن يصيب إلا محفظتك أنت. هذه المنظومة أعقد من مجرد استيكينغ ETH وحده؛ فهي تعتمد على تحقق طبقتين. الطبقة الأساسية هي شبكة $BTC غير قابلة للنقض، وهي المسؤولة عن التوثيق القطعي لطوابع زمن UTXO؛ أما الطبقة السطحية فهي شبكة مشتركة للعقوبات مبنية بواسطة BABY. يعمل الـ FP كعقدة وسيطة، ولكي يحقق أرباحًا من “استقطاب العملاء”، يجب أن يضع BABY الخاص به ويربطه مع أموال التفويض لدى الجميع، بحيث يحقق الحد الأدنى من النسبة المطلوبة من النظام. وهذا يشبه سيف دَموقليس المعلّق فوق رأس العقدة. إذا كانت أموال العقدة الخاصة قليلة جدًا، فحتى مع تراجع السوق قليلًا، أو إذا تضخمت أموال التفويض فجأة، ستنحرف نسبة الضمان (staked ratio) لديها عن الحد. في اللحظة التالية، سيتم طردها من المجموعة الفعالة، وسيتوقف فورًا عائدات BTC لجميع المفوضين. وإذا تم تفعيل slash أشد خطورة، فلن يتم تدمير حصص طبقة BABY فقط عبر آلة الحالة BSN، بل سيتم أيضًا سحب المفتاح الخاص من جانب BTC مباشرةً عبر آلية EOTS للمصادرة. بالإضافة إلى ذلك، لا ينبغي أن نُخدع بالنظرة السطحية للأرقام المرتفعة في الاكتتاب الذاتي. تذكّر أن BABY لديه دورة إلغاء/تحرير (unlock). إذا كان الـ FP يستخدم مخصصات قريبة من التحرير المبكر للتظاهر بالاكتمال، فسيكون ذلك بمثابة قنبلة مؤقتة. بمجرد قيامهم بالتصفيه النقدية (cashing out)، سيتعيّن على المفوضين مواجهة فترة طويلة مدتها 14 يومًا لفك الارتباط (解绑) دون أي عائد. ومن خلال استخدام فهارس (indexers) متقدمة للتحقق من الطبيعة الحقيقية لأموال العقدة، وجعل نسبة الاكتتاب الذاتي شرطًا صارمًا للفلترة (hard filter)، فهذا هو الوضع الصحيح للمشاركة في منظومة Babylon. #baby $BABY

انتبه أكثر لتغيّرات الحالة على سلسلة Babylon، وستكتشف أن كل يوم هناك مزوّد نهائية (Finality Provider - FP) يدخل ويخرج من القائمة النشطة. كثير من المستثمرين يشعرون بالحيرة، لكن السبب كله مكتوب في قواعد القبول الخاصة بالعقد الذكي. في Babylon عندما تلعب دور التست (الاستيكينغ)، إذا لم تأخذ نسبة الاكتتاب الذاتي لـ $BABY على محمل الجد، فالضرر في النهاية لن يصيب إلا محفظتك أنت.

هذه المنظومة أعقد من مجرد استيكينغ ETH وحده؛ فهي تعتمد على تحقق طبقتين. الطبقة الأساسية هي شبكة $BTC غير قابلة للنقض، وهي المسؤولة عن التوثيق القطعي لطوابع زمن UTXO؛ أما الطبقة السطحية فهي شبكة مشتركة للعقوبات مبنية بواسطة BABY. يعمل الـ FP كعقدة وسيطة، ولكي يحقق أرباحًا من “استقطاب العملاء”، يجب أن يضع BABY الخاص به ويربطه مع أموال التفويض لدى الجميع، بحيث يحقق الحد الأدنى من النسبة المطلوبة من النظام.

وهذا يشبه سيف دَموقليس المعلّق فوق رأس العقدة. إذا كانت أموال العقدة الخاصة قليلة جدًا، فحتى مع تراجع السوق قليلًا، أو إذا تضخمت أموال التفويض فجأة، ستنحرف نسبة الضمان (staked ratio) لديها عن الحد. في اللحظة التالية، سيتم طردها من المجموعة الفعالة، وسيتوقف فورًا عائدات BTC لجميع المفوضين. وإذا تم تفعيل slash أشد خطورة، فلن يتم تدمير حصص طبقة BABY فقط عبر آلة الحالة BSN، بل سيتم أيضًا سحب المفتاح الخاص من جانب BTC مباشرةً عبر آلية EOTS للمصادرة.

بالإضافة إلى ذلك، لا ينبغي أن نُخدع بالنظرة السطحية للأرقام المرتفعة في الاكتتاب الذاتي. تذكّر أن BABY لديه دورة إلغاء/تحرير (unlock). إذا كان الـ FP يستخدم مخصصات قريبة من التحرير المبكر للتظاهر بالاكتمال، فسيكون ذلك بمثابة قنبلة مؤقتة. بمجرد قيامهم بالتصفيه النقدية (cashing out)، سيتعيّن على المفوضين مواجهة فترة طويلة مدتها 14 يومًا لفك الارتباط (解绑) دون أي عائد. ومن خلال استخدام فهارس (indexers) متقدمة للتحقق من الطبيعة الحقيقية لأموال العقدة، وجعل نسبة الاكتتاب الذاتي شرطًا صارمًا للفلترة (hard filter)، فهذا هو الوضع الصحيح للمشاركة في منظومة Babylon.
#baby $BABY

عندما أراقب لوحة حَقْن/تَسْتِيك (staking) Babylon Genesis، أكثر ما يجعل حاملي BABY يشعرون بعدم اليقين ليس إجمالي مبلغ الـ staking المتذبذب، بل تحديدًا كم يومًا تفصل بين "الكمية المتداولة" و"الكمية القابلة فعليًا للبيع". وهذا مثل القول: ليس الأمر نفسه تمامًا أن "قدّم استقالته" لا يعني تلقائيًا أن "المكتب سيُفرَّغ غدًا". إن عملية فكّ الارتباط لـ BABY على السلسلة تمرّ عبر عدة إيقاعات: إلغاء التفويض (undelegation) على السلسلة، ثم فترة تبريد مدتها 21 يومًا، ثم انتظار الفتح التلقائي، وبعدها تعود الأرصدة من جديد إلى كونها transferable. فإذا قام مُجمِّع بيانات باحتساب هذه القطع من العملات ضمن العرض المتداول في اللحظة التي تبدأ فيها فترة التبريد، أو ظلّ يحبسها في خانة "staking" طوال مدة التبريد، فإن ضغط التخفيف الناتج عن FDV المعروض مقارنةً بالضغط الحقيقي للبيع الفعلي لا يختلف فقط—بل يفصل بينهما تمامًا فرق التوقيت بمقدار نافذة unbonding كاملة. أنا أُقدّر أن المتصفح الرسمي يفصل unbonding لوحده، لأن ذلك على الأقل يجعل المستخدم يرى "القطع التي في الطريق". لكن اللوحات في الاتجاه الآخر غالبًا لا تملك هذا الصبر. فبدافع أن تعرض "نسبة staking" أو "القيمة السوقية المتداولة" بشكل جميل، إما أن تحسب كل الرموز في فترة التبريد كأنها مخزونة في مستودع (dead/locked)؛ أو عند انتهاء المدة تحسبها مباشرة كمياه جارية (liquid). وبين هذين الحدّين، منطقة الرمادي لمدة 21 يومًا تُختصر وتُتجاوز بسطر واحد. المطلوب التحذّر الحقيقي منه: أن أحدهم يستخدم مخططًا يقول إن "نسبة الـ staking تجاوزت 70%" ليشرح مدى ارتفاع مستوى قفل سيولة BABY، دون أن يتحقق من كم من هذا الـ 70% تم بالفعل الضغط فيه على زر الخروج، وكم ما يزال في طابور المغادرة. BABY خلال فترة التبريد لا يمكنه أن يُفوَّض مجددًا لأكل العوائد، وفي الوقت نفسه لم يعد بعد إلى المحفظة ليُقصف للبيع (dump)؛ إنه دفعة من "قطع أُعلنت النية فيها لكنها لم تتحقق بعد". ومن السهل جدًا ضمن منهجيات الإحصاء أن تُستغل هذه القطع من الطرفين كلٌ بما يخدمه. لذلك، عند مراجعة دفتر حسابات BABY على السلسلة، سأبدأ أولًا بنَفَس/عمق قائمة unbonding وتوزيع تواريخ الانتهاء، ثم أسأل: في اللوحة، هل "Staked" و"Circulating" تُحسبان على أي كتلة كحدّ فاصل؟ وهل تم إدراج أرصدة التبريد ضمن التداول أم لا. كلما اعتمدت قصة BABY أكثر على سردية "تداول منخفض، وstaking مرتفع" (ندرة)، كلما لم يعد تقسيم هذه الأرقام مجرد مسألة ملخص واحد من الواجهة الأمامية. لوحة البيانات الجيدة لا تختصر الحالات المعقدة في رقم جميل واحد، بل تجعل الشخص يرى فورًا: أي القطع ما زالت "تتكدس/تنتظر خلف القضبان"، وأيّها "قدّمت طلبات الإفراج المشروط"، وأيّها فعلاً حصل على أمر/تصريح التحرير. IDOL BEAT #baby $BABY

عندما أراقب لوحة حَقْن/تَسْتِيك (staking) Babylon Genesis، أكثر ما يجعل حاملي BABY يشعرون بعدم اليقين ليس إجمالي مبلغ الـ staking المتذبذب، بل تحديدًا كم يومًا تفصل بين "الكمية المتداولة" و"الكمية القابلة فعليًا للبيع".

وهذا مثل القول: ليس الأمر نفسه تمامًا أن "قدّم استقالته" لا يعني تلقائيًا أن "المكتب سيُفرَّغ غدًا". إن عملية فكّ الارتباط لـ BABY على السلسلة تمرّ عبر عدة إيقاعات: إلغاء التفويض (undelegation) على السلسلة، ثم فترة تبريد مدتها 21 يومًا، ثم انتظار الفتح التلقائي، وبعدها تعود الأرصدة من جديد إلى كونها transferable. فإذا قام مُجمِّع بيانات باحتساب هذه القطع من العملات ضمن العرض المتداول في اللحظة التي تبدأ فيها فترة التبريد، أو ظلّ يحبسها في خانة "staking" طوال مدة التبريد، فإن ضغط التخفيف الناتج عن FDV المعروض مقارنةً بالضغط الحقيقي للبيع الفعلي لا يختلف فقط—بل يفصل بينهما تمامًا فرق التوقيت بمقدار نافذة unbonding كاملة.

أنا أُقدّر أن المتصفح الرسمي يفصل unbonding لوحده، لأن ذلك على الأقل يجعل المستخدم يرى "القطع التي في الطريق". لكن اللوحات في الاتجاه الآخر غالبًا لا تملك هذا الصبر. فبدافع أن تعرض "نسبة staking" أو "القيمة السوقية المتداولة" بشكل جميل، إما أن تحسب كل الرموز في فترة التبريد كأنها مخزونة في مستودع (dead/locked)؛ أو عند انتهاء المدة تحسبها مباشرة كمياه جارية (liquid). وبين هذين الحدّين، منطقة الرمادي لمدة 21 يومًا تُختصر وتُتجاوز بسطر واحد.

المطلوب التحذّر الحقيقي منه: أن أحدهم يستخدم مخططًا يقول إن "نسبة الـ staking تجاوزت 70%" ليشرح مدى ارتفاع مستوى قفل سيولة BABY، دون أن يتحقق من كم من هذا الـ 70% تم بالفعل الضغط فيه على زر الخروج، وكم ما يزال في طابور المغادرة. BABY خلال فترة التبريد لا يمكنه أن يُفوَّض مجددًا لأكل العوائد، وفي الوقت نفسه لم يعد بعد إلى المحفظة ليُقصف للبيع (dump)؛ إنه دفعة من "قطع أُعلنت النية فيها لكنها لم تتحقق بعد". ومن السهل جدًا ضمن منهجيات الإحصاء أن تُستغل هذه القطع من الطرفين كلٌ بما يخدمه.

لذلك، عند مراجعة دفتر حسابات BABY على السلسلة، سأبدأ أولًا بنَفَس/عمق قائمة unbonding وتوزيع تواريخ الانتهاء، ثم أسأل: في اللوحة، هل "Staked" و"Circulating" تُحسبان على أي كتلة كحدّ فاصل؟ وهل تم إدراج أرصدة التبريد ضمن التداول أم لا. كلما اعتمدت قصة BABY أكثر على سردية "تداول منخفض، وstaking مرتفع" (ندرة)، كلما لم يعد تقسيم هذه الأرقام مجرد مسألة ملخص واحد من الواجهة الأمامية.

لوحة البيانات الجيدة لا تختصر الحالات المعقدة في رقم جميل واحد، بل تجعل الشخص يرى فورًا: أي القطع ما زالت "تتكدس/تنتظر خلف القضبان"، وأيّها "قدّمت طلبات الإفراج المشروط"، وأيّها فعلاً حصل على أمر/تصريح التحرير.
IDOL BEAT
#baby $BABY

يا إلهي، القسم العاشر من «الكتاب الأبيض» وضع لـBABY «ختم حوكمة»! وبمجرد أن تقلب للصفحة التالية، سترى أن هذا الختم يتحول مباشرةً إلى مفتاح تشغيل آلة لطباعة النقود. ظاهرها كله في محله، لكن الحقيقة كلها منحرفة. في كريبتو، «الحوكمة» هي أكثر غطاءٍ عمليّ كحلٍ ومرنٍ للتجمّل. يمكن لحائزي BABY التصويت لاختيار قوالب خزائن (vault) وتعديل الرسوم وتحديد أي سلاسل PoS يمكنها الاتصال—يبدو كأنهم يمسكون بمقود السيارة. لكن الشيء الذي يتم لحامه فعليًا هو نصّ الستاكينغ في القسم 8 ومسار EOTS في القسم 9: نسب التصفية، نافذة التحدّي، شروط المصادرة/الغرامات—كل ذلك تمت صَبّه وتثبيته مسبقًا في BitVM3. يمكن تجاوز تصويت الـSnapshot، لكن نصوص البيتكوين لا تتعرف على إجماع خارج السلسلة. وهكذا انكمشت سلطة «التحكم» من «تعديل المسار» إلى «لصق ملصقات». والأكثر خفاءً هو هيكل المصالح: لكي يُمكن لـBABY أن يحقق فاعلية الحوكمة، يجب أن يقوم بالحوكمة عبر ستاكٍ مشترك. أما سلاسل PoS التي يتم اختيارها عبر التصويت، فهي تحدد مباشرةً أيضًا أمان قفل BABY نفسه ومعدل العائد. المراقب يوقع/يملي الامتحان بيده، والدرجات ترتبط براتبه. لكن الأكثر إثارة للتأمل هو الإيقاع الزمني. ذروة تحرير رموز الفريق والمؤسسات تتزامن بدقة مع لحظة إطلاق أول قوالب الخزائن ومع بدء مقترحات الحوكمة. إذا كانت سلطة الحوكمة لها قيمة مستقلة فعلًا، فكان ينبغي أن يكون منحنى التحرير متدرجًا كالماء على مهل؛ لكنه اختار أن يتناغم مع «حدث الحوكمة». ومع ذلك، فإن «genesis parameters» هي فعليًا أول تصويت حقيقي—في تلك الجولة، لم يصل الدعوة إلا المترجم والمطلعين من الداخل. بصراحة، وسم «الحوكمة» يبدو أقدر على اجتياز فحوص الامتثال من وسم «أداة مضاربة». لكن الخطة تفترض افتراضًا واحدًا: أن كل BTC الصامتة تنتظر من حائزي BABY أن يقرروا مصيرها. هذه الجملة حين يخرجها مشروعٌ من فم القائمين عليه تشبه تمامًا بيع «ملصق ضمان اجتياز» عند بوابة قاعة امتحان الثانوية. وعندما تقف الحيتان المستغرقة حقًا على قدميها وتقوم آلاف الخزائن بتنشيط استخراج EOTS في الوقت نفسه، يكون حائزو BABY ما زالوا يصوتون للجولة السابعة على سؤال: «هل سيتم إطلاق قالب الخزينة التاسع أم لا؟». دقة سلطة الحوكمة وبكسل المخاطر النظامية ليستا على نفس الطبقة أصلًا. هل تعتقد أن BABY هو ملاح الـBTC، أم أنه «سجل قيادة» (داتا/سجل الرحلة) خاص بالمشروع؟ إخلاء مسؤولية: صباح اليوم فحصت المحفظة الباردة—وBTC ما زالت هناك مسترخية. لا توجد BABY، ولا التزام بالحوكمة، ولا عدّ تنازلي للإطلاق. الأمر مجرد انحياز لفئة متكدسي العملات؛ واستثمارك، تذكّر مبدأ TITANIC—Trust In Trezor, Avoid Nonsense Investment Contracts。 #baby $BABY

يا إلهي، القسم العاشر من «الكتاب الأبيض» وضع لـBABY «ختم حوكمة»! وبمجرد أن تقلب للصفحة التالية، سترى أن هذا الختم يتحول مباشرةً إلى مفتاح تشغيل آلة لطباعة النقود. ظاهرها كله في محله، لكن الحقيقة كلها منحرفة.

في كريبتو، «الحوكمة» هي أكثر غطاءٍ عمليّ كحلٍ ومرنٍ للتجمّل. يمكن لحائزي BABY التصويت لاختيار قوالب خزائن (vault) وتعديل الرسوم وتحديد أي سلاسل PoS يمكنها الاتصال—يبدو كأنهم يمسكون بمقود السيارة. لكن الشيء الذي يتم لحامه فعليًا هو نصّ الستاكينغ في القسم 8 ومسار EOTS في القسم 9: نسب التصفية، نافذة التحدّي، شروط المصادرة/الغرامات—كل ذلك تمت صَبّه وتثبيته مسبقًا في BitVM3. يمكن تجاوز تصويت الـSnapshot، لكن نصوص البيتكوين لا تتعرف على إجماع خارج السلسلة. وهكذا انكمشت سلطة «التحكم» من «تعديل المسار» إلى «لصق ملصقات».

والأكثر خفاءً هو هيكل المصالح: لكي يُمكن لـBABY أن يحقق فاعلية الحوكمة، يجب أن يقوم بالحوكمة عبر ستاكٍ مشترك. أما سلاسل PoS التي يتم اختيارها عبر التصويت، فهي تحدد مباشرةً أيضًا أمان قفل BABY نفسه ومعدل العائد. المراقب يوقع/يملي الامتحان بيده، والدرجات ترتبط براتبه.

لكن الأكثر إثارة للتأمل هو الإيقاع الزمني. ذروة تحرير رموز الفريق والمؤسسات تتزامن بدقة مع لحظة إطلاق أول قوالب الخزائن ومع بدء مقترحات الحوكمة. إذا كانت سلطة الحوكمة لها قيمة مستقلة فعلًا، فكان ينبغي أن يكون منحنى التحرير متدرجًا كالماء على مهل؛ لكنه اختار أن يتناغم مع «حدث الحوكمة». ومع ذلك، فإن «genesis parameters» هي فعليًا أول تصويت حقيقي—في تلك الجولة، لم يصل الدعوة إلا المترجم والمطلعين من الداخل.

بصراحة، وسم «الحوكمة» يبدو أقدر على اجتياز فحوص الامتثال من وسم «أداة مضاربة». لكن الخطة تفترض افتراضًا واحدًا: أن كل BTC الصامتة تنتظر من حائزي BABY أن يقرروا مصيرها. هذه الجملة حين يخرجها مشروعٌ من فم القائمين عليه تشبه تمامًا بيع «ملصق ضمان اجتياز» عند بوابة قاعة امتحان الثانوية. وعندما تقف الحيتان المستغرقة حقًا على قدميها وتقوم آلاف الخزائن بتنشيط استخراج EOTS في الوقت نفسه، يكون حائزو BABY ما زالوا يصوتون للجولة السابعة على سؤال: «هل سيتم إطلاق قالب الخزينة التاسع أم لا؟». دقة سلطة الحوكمة وبكسل المخاطر النظامية ليستا على نفس الطبقة أصلًا.

هل تعتقد أن BABY هو ملاح الـBTC، أم أنه «سجل قيادة» (داتا/سجل الرحلة) خاص بالمشروع؟

إخلاء مسؤولية: صباح اليوم فحصت المحفظة الباردة—وBTC ما زالت هناك مسترخية. لا توجد BABY، ولا التزام بالحوكمة، ولا عدّ تنازلي للإطلاق. الأمر مجرد انحياز لفئة متكدسي العملات؛ واستثمارك، تذكّر مبدأ TITANIC—Trust In Trezor, Avoid Nonsense Investment Contracts。
#baby $BABY

التحقيق في محفظة التوقيعات المتعددة الخاصة بي في عطلة نهاية الأسبوع وترتيبها داخل المنزل، والتبديل المتكرر بين العناوين، جعلني أشعر بعمق أكبر بآليات عزل الأموال. وعلى هذا المنوال، عدتُ مرة أخرى لفتح ورقة Babylon البيضاء عن TBV (Trustless Bitcoin Vault). وعندما قرأت بعناية فصل منطق التصفية، انجذبت إلى طريقة معالجة تُشبه “الاقتراض عبر تجميع خزائن متعددة”. في الواقع، هنا الكثير من الخفايا. كما يعرف الجميع، بيئة ETH تميل إلى الحالة العالمية؛ فالأموال تبدو وكأنها في حوض صبغ كبير: السيولة جيدة لكن المخاطر تتركز. أما BTC فهو يصرّ على بنية UTXO، ويبحث عن عزل فيزيائي صارم. ضمن إطار TBV، عندما تودع ثلاث دفعات من الـ “بِتـشِي” (الـ BTC)، ستحصل على ثلاث خزائن مستقلة لا علاقة بينها. وعند الاقتراض، لا يستخدم آلية “تجميع الأموال” كما هو الحال في بعض التصاميم، بل يستفيد بذكاء من “الخصم عبر بادئة/Prefix”: يتم تحصيل الرسوم واحدًا تلو الآخر على امتداد ترتيب الإيداع، ويتوقف عند اكتمال المبلغ. الخزائن التي تم لمسها والخزائن التي لم يتم لمسها معزولة تمامًا على مستوى كود العقد. إن هذا التصميم الذي يستبدل مشاركة الحالة بترتيب للقراءة فقط يُعدّ رائعًا، ويرفع الأمان إلى أقصى حد. لكن المشكلة تظهر أيضًا: بعد الانتهاء من قراءة المستند، تختفي عملية السداد/إعادة الشراء (الاسترداد/الفك) ببساطة. هل سيتم فك التجميد عكسًا حسب نفس المسار—كما يحدث عند تتبع الخيط ثم الرجوع خطوة خطوة بالعكس؟ أم سيتم تسجيل كل خزنة على حدة بسجل سداد مستقل؟ وبما أن شبكة الاختبار تستخدم توكنات اختبار بلا قيمة، فإن الفراغ على مستوى المنتج يمكن أن يُستغل بسهولة لتجاوز الأمور. يحافظ TBV على بنية رأس المال التي لا يجوز التنازل عنها، لكن الجزء المنطقي الناقص في النصف الثاني—بالنسبة لمشاركة توكن BABY في الحوكمة وتوزيع العوائد—هو بالتأكيد قنبلة موقوتة. فإذا تعثرت آلية التصفية الأساسية، فلن يكون هناك معنى لرؤية القيمة التي يرسمها BABY. ما رأيكم؟ هل ستصبح طريقة معالجة UTXO عبر “اصطفاف لخصم الأموال” هي القاعدة المعيارية في الصناعة مستقبلًا؟ لنتحاور. #baby $BABY

التحقيق في محفظة التوقيعات المتعددة الخاصة بي في عطلة نهاية الأسبوع وترتيبها داخل المنزل، والتبديل المتكرر بين العناوين، جعلني أشعر بعمق أكبر بآليات عزل الأموال. وعلى هذا المنوال، عدتُ مرة أخرى لفتح ورقة Babylon البيضاء عن TBV (Trustless Bitcoin Vault). وعندما قرأت بعناية فصل منطق التصفية، انجذبت إلى طريقة معالجة تُشبه “الاقتراض عبر تجميع خزائن متعددة”. في الواقع، هنا الكثير من الخفايا.

كما يعرف الجميع، بيئة ETH تميل إلى الحالة العالمية؛ فالأموال تبدو وكأنها في حوض صبغ كبير: السيولة جيدة لكن المخاطر تتركز. أما BTC فهو يصرّ على بنية UTXO، ويبحث عن عزل فيزيائي صارم. ضمن إطار TBV، عندما تودع ثلاث دفعات من الـ “بِتـشِي” (الـ BTC)، ستحصل على ثلاث خزائن مستقلة لا علاقة بينها. وعند الاقتراض، لا يستخدم آلية “تجميع الأموال” كما هو الحال في بعض التصاميم، بل يستفيد بذكاء من “الخصم عبر بادئة/Prefix”: يتم تحصيل الرسوم واحدًا تلو الآخر على امتداد ترتيب الإيداع، ويتوقف عند اكتمال المبلغ. الخزائن التي تم لمسها والخزائن التي لم يتم لمسها معزولة تمامًا على مستوى كود العقد.

إن هذا التصميم الذي يستبدل مشاركة الحالة بترتيب للقراءة فقط يُعدّ رائعًا، ويرفع الأمان إلى أقصى حد. لكن المشكلة تظهر أيضًا: بعد الانتهاء من قراءة المستند، تختفي عملية السداد/إعادة الشراء (الاسترداد/الفك) ببساطة. هل سيتم فك التجميد عكسًا حسب نفس المسار—كما يحدث عند تتبع الخيط ثم الرجوع خطوة خطوة بالعكس؟ أم سيتم تسجيل كل خزنة على حدة بسجل سداد مستقل؟ وبما أن شبكة الاختبار تستخدم توكنات اختبار بلا قيمة، فإن الفراغ على مستوى المنتج يمكن أن يُستغل بسهولة لتجاوز الأمور.

يحافظ TBV على بنية رأس المال التي لا يجوز التنازل عنها، لكن الجزء المنطقي الناقص في النصف الثاني—بالنسبة لمشاركة توكن BABY في الحوكمة وتوزيع العوائد—هو بالتأكيد قنبلة موقوتة. فإذا تعثرت آلية التصفية الأساسية، فلن يكون هناك معنى لرؤية القيمة التي يرسمها BABY. ما رأيكم؟ هل ستصبح طريقة معالجة UTXO عبر “اصطفاف لخصم الأموال” هي القاعدة المعيارية في الصناعة مستقبلًا؟ لنتحاور.
#baby $BABY

ركضتُ أمس الساعة الحادية عشرة حتى انتهاء عملية الإيداع/الستيك لـ Babylon، وأغلقتُ صفقة الـ BTC خلال أكثر من أربعين دقيقة. كنتُ أراقب إثباتات الستيك داخل المحفظة، وفجأة أدركت: هذه الأموال ليست "يمكن سحبها في أي وقت". @BabylonLabs_io تذكر الوثائق الرسمية "14-day unbonding window"، لكن ماذا تعني فعليًا هذه الأربعة عشر يومًا؟ كثيرون لا يحسبونها بدقة. يتم حبس الـ BTC داخل الـ vault، وبعد إرسال طلب unbonding ينتقل إلى حالة "بانتظار فك القفل". خلال هذه الأيام الأربعة عشر، إذا هبط السعر بسرعة، فلن يكون لديك حتى صلاحية إيقاف الخسارة. والمشكلة الأشد هو أنه إذا تم رصد أن الـ Finality Provider قام بتوقيع مزدوج خلال هذه الفترة، يتم تفعيل EOTS وبالتالي يحدث slashing، وسيُخصَم رأس المال منك بنسبة وفقًا للآلية. تتراكب ثلاث مخاطر معًا: مخاطر السوق، ومخاطر تعرّض المفاتيح، ومخاطر العقوبة. لقد فتحتُ فصل "slashing time window" في الوثائق، ووجدت أن نافذة صلاحية معاملات العقوبة تتداخل مع فترة unbonding. يمكن للـ FP أن يبدأ بسوء التصرف في بداية الفترة، وقد تُجمّع معاملة العقوبة في نهاية الفترة فقط داخل كتل Bitcoin. بعد أن يبدأ المستخدم عملية الاسترداد (redeem)، قد يستغرق الأمر حتى أربعة عشر يومًا إضافة إلى عدد من تأكيدات الكتل، قبل أن تتأكد فعليًا من أن رأس المال مكتمل بالكامل. هذا النوع من "تعليق عدم اليقين" يصبح أبطأ وأقل قابلية للتحكم بسبب فواصل إصدار الكتل في Bitcoin. ثم مسألة إثباتات الستيك. المرحلة الأولى من شبكة Babylon الرئيسية لا توفر مشتقات سيولة (LST)، لذلك يتم حبس الـ BTC على الشبكة الرئيسية، وعلى سلسلة PoS تحصل على نقاط أمان، بينما السيولة شبه معدومة. إذا كان BABY سيحتاج مستقبلًا أن يؤدي دور "وسادة/احتياطي سيولة"، فلابد أن ينتقل نموذج التوكن من الحوكمة البحتة إلى إصدار أصول. لكن مع وجود تضخم سنوي 8% لتعويض طبقة سيولة قد لا تُستخدم فعليًا، تصبح قيمة العائد مقارنة بالتكلفة (الجدوى) صعبة الحساب. وهناك نقطة أخرى كلما فكرت فيها أكثر شعرت بعدم ارتياح: عندما يختار المستخدم FP، فإن الترتيب في الأعلى دائمًا لأولئك العقد التابعة لكبار المالكين. لكي يجذب الـ FP الأصغر الستيكينغ، يحتاج إلى تراكم سمعة، ما يؤدي طبيعيًا إلى تركّز في القمة. الـ FP في القمة إذا تأثر بـ slashing ستكون مساحة تأثيره هائلة. وإذا تعاونوا على "سوء تصرف ناعم"—أي إجراء فحص انتقائي لعلامات finality لبعض سلاسل PoS—فإن EOTS لن يُفعَّل أصلًا لأن توقيعًا مزدوجًا لن يحدث. Bitcoin Script يمكنه فقط معالجة "الانتهاك الواضح"، ولا يستطيع التعامل مع "التقصير/عدم الفعل". لذلك أصبحت قلقًا لم يعد مجرد: "هل يمكن تشغيلها تقنيًا؟" بل صار: "ما مدى اتساع المخاطر التي يتحملها المستخدم العادي بعد تشغيلها؟" إن unbonding لمدة أربعة عشر يومًا لا يهم في سوق صاعدة، لكنه في ظل ظروف استثنائية يعني الفرق بين الحياة والموت. هل ترى أن هذه تكلفة سلامة ضرورية أم أنها عيب صارخ في تجربة المستخدم؟ #baby $BABY

ركضتُ أمس الساعة الحادية عشرة حتى انتهاء عملية الإيداع/الستيك لـ Babylon، وأغلقتُ صفقة الـ BTC خلال أكثر من أربعين دقيقة. كنتُ أراقب إثباتات الستيك داخل المحفظة، وفجأة أدركت: هذه الأموال ليست "يمكن سحبها في أي وقت". @BabylonLabs_io

تذكر الوثائق الرسمية "14-day unbonding window"، لكن ماذا تعني فعليًا هذه الأربعة عشر يومًا؟ كثيرون لا يحسبونها بدقة. يتم حبس الـ BTC داخل الـ vault، وبعد إرسال طلب unbonding ينتقل إلى حالة "بانتظار فك القفل". خلال هذه الأيام الأربعة عشر، إذا هبط السعر بسرعة، فلن يكون لديك حتى صلاحية إيقاف الخسارة.

والمشكلة الأشد هو أنه إذا تم رصد أن الـ Finality Provider قام بتوقيع مزدوج خلال هذه الفترة، يتم تفعيل EOTS وبالتالي يحدث slashing، وسيُخصَم رأس المال منك بنسبة وفقًا للآلية. تتراكب ثلاث مخاطر معًا: مخاطر السوق، ومخاطر تعرّض المفاتيح، ومخاطر العقوبة.

لقد فتحتُ فصل "slashing time window" في الوثائق، ووجدت أن نافذة صلاحية معاملات العقوبة تتداخل مع فترة unbonding. يمكن للـ FP أن يبدأ بسوء التصرف في بداية الفترة، وقد تُجمّع معاملة العقوبة في نهاية الفترة فقط داخل كتل Bitcoin. بعد أن يبدأ المستخدم عملية الاسترداد (redeem)، قد يستغرق الأمر حتى أربعة عشر يومًا إضافة إلى عدد من تأكيدات الكتل، قبل أن تتأكد فعليًا من أن رأس المال مكتمل بالكامل. هذا النوع من "تعليق عدم اليقين" يصبح أبطأ وأقل قابلية للتحكم بسبب فواصل إصدار الكتل في Bitcoin.

ثم مسألة إثباتات الستيك. المرحلة الأولى من شبكة Babylon الرئيسية لا توفر مشتقات سيولة (LST)، لذلك يتم حبس الـ BTC على الشبكة الرئيسية، وعلى سلسلة PoS تحصل على نقاط أمان، بينما السيولة شبه معدومة. إذا كان BABY سيحتاج مستقبلًا أن يؤدي دور "وسادة/احتياطي سيولة"، فلابد أن ينتقل نموذج التوكن من الحوكمة البحتة إلى إصدار أصول. لكن مع وجود تضخم سنوي 8% لتعويض طبقة سيولة قد لا تُستخدم فعليًا، تصبح قيمة العائد مقارنة بالتكلفة (الجدوى) صعبة الحساب.

وهناك نقطة أخرى كلما فكرت فيها أكثر شعرت بعدم ارتياح: عندما يختار المستخدم FP، فإن الترتيب في الأعلى دائمًا لأولئك العقد التابعة لكبار المالكين. لكي يجذب الـ FP الأصغر الستيكينغ، يحتاج إلى تراكم سمعة، ما يؤدي طبيعيًا إلى تركّز في القمة. الـ FP في القمة إذا تأثر بـ slashing ستكون مساحة تأثيره هائلة. وإذا تعاونوا على "سوء تصرف ناعم"—أي إجراء فحص انتقائي لعلامات finality لبعض سلاسل PoS—فإن EOTS لن يُفعَّل أصلًا لأن توقيعًا مزدوجًا لن يحدث. Bitcoin Script يمكنه فقط معالجة "الانتهاك الواضح"، ولا يستطيع التعامل مع "التقصير/عدم الفعل".

لذلك أصبحت قلقًا لم يعد مجرد: "هل يمكن تشغيلها تقنيًا؟" بل صار: "ما مدى اتساع المخاطر التي يتحملها المستخدم العادي بعد تشغيلها؟" إن unbonding لمدة أربعة عشر يومًا لا يهم في سوق صاعدة، لكنه في ظل ظروف استثنائية يعني الفرق بين الحياة والموت. هل ترى أن هذه تكلفة سلامة ضرورية أم أنها عيب صارخ في تجربة المستخدم؟
#baby $BABY

عند الساعة الرابعة صباحًا، كنت أحدّق في معادلة إيجار الـBSN الخاصة بـBabylon، والبرد يسري في ظهري. هذا الأسبوع فقط حوّلت جزءًا من أرباح الموجات مرة أخرى إلى BTC. في البداية كنت أُعجب بفكرة أن رهن «البيج بيك» ودمجه مع الشبكة الناضجة. مئة عقدة تُنشئ الكتل، وستون مُرَهِنين ينجزون التأكيد النهائي—فالميكانيكية فعلاً دقيقة وذكية. لكن عندما راجعت كيف يتم «استئجار» أمان سلسلة الاستهلاك باستخدام BTC، وجدت في دفتر حوكمة الإيجارات عدة بنود لا يمكن تفسيرها بوضوح. في نموذج Babylon للأمان المشترك، الفكرة الأساسية هي أن مُرَهِني BTC يَؤجِرون الأمان لسلسلة الاستهلاك مقابل عائد من الإيجار. لكن سلطة تسعير الإيجار ليست بيد المُرَهِنين. سلسلة الاستهلاك تدفع الإيجار إلى البروتوكول، والبروتوكول يوزّع ذلك حسب صيغة داخلية ما—وهذه الصيغة هي «الصندوق الأسود». وبناءً على خبرتي في الامتثال المالي في لندن، فإن أي نموذج لتوزيع العائدات يفتقر إلى منحنى تسعير إيجار قابل للتدقيق لحظيًا، سيؤدي حتمًا في الظروف القصوى إلى حدوث ضغط/تدافع على الإيجارات. الـBTC التي تراهنها تتحمل مخاطر الـslash كاملة، بينما توزيع الإيجار يمر عبر بروتوكول على مرحلتين: اقتطاع ثانٍ ثم إعادة توزيع. هذا يشبه أن السيد لاو يوقّر البيت للوسيط، والوسيط يؤجره بدوره للسيد لاو آخر—والإيجار الذي يصل للسيد لاو ليس سعر السوق ولا يمكنه أن يقرر لمن يُؤجَّر، لأن العقود تُوقّع بالنيابة من خلال وسيط. وفي نهاية الشهر عند تسوية الحسابات، دائمًا توجد بضعة بنود في المعاملات لا يمكن تفسيرها، فيبقى السيد لاو عاجزًا عن شيء سوى التحديق. إذا لم يتم إنشاء مسار شفاف بين توزيع الإيجار وتحمل المخاطر، فإن أي تعثر في سداد إيجار سلسلة الاستهلاك أو أي تعديل في معاملات التوزيع على مستوى البروتوكول سيؤثر مباشرة على عائد المُرَهِنين الفعلي. إن وضع نموذج العائدات في صندوق أسود غير شفاف لتوزيع الإيجار يشبه اختيار طلبات في بار دون رؤية تفاصيل الفاتورة؛ وفي النهاية عند الدفع تكتشف أنك دُفعت عليك عدة مشروبات أكثر مما ينبغي. نفور فسيولوجي. في الوقت الحالي، تمسك تدفقات رأس المال من ناحية السوق قويّ، ويوجد دعم من المشترين لزيادة حجم القفل. لكن بالنسبة للتخصيص بالحصة الكبيرة، فإن شفافية حوكمة الإيجار هي حجر الأساس. قد يتجاهل السوق على المدى القصير صندوق العائدات الأسود، لكن التعرض غير المُغلَق للإيجارات سيظل موجودًا دائمًا. إذا استطاعت المجموعة إضافة آلية تسعير وتوزيع للإيجارات قابلة للتدقيق لحظيًا في التكرارات اللاحقة، فسترتفع درجة الحتمية بمقدار مستوى واحد. نصيحتي للجميع: عند بناء مركز، احتفظوا بمستوى من التبجيل/الحذر تجاه منطق توزيع إيجار BSN. @babylonlabs_io تفضلوا إلى قسم تعليقات ساحة باينانس وتحدثوا: هل حسبتم كم طبقة من الإيجار تم اقتطاعها منكم؟ #baby $BABY

عند الساعة الرابعة صباحًا، كنت أحدّق في معادلة إيجار الـBSN الخاصة بـBabylon، والبرد يسري في ظهري.

هذا الأسبوع فقط حوّلت جزءًا من أرباح الموجات مرة أخرى إلى BTC. في البداية كنت أُعجب بفكرة أن رهن «البيج بيك» ودمجه مع الشبكة الناضجة. مئة عقدة تُنشئ الكتل، وستون مُرَهِنين ينجزون التأكيد النهائي—فالميكانيكية فعلاً دقيقة وذكية. لكن عندما راجعت كيف يتم «استئجار» أمان سلسلة الاستهلاك باستخدام BTC، وجدت في دفتر حوكمة الإيجارات عدة بنود لا يمكن تفسيرها بوضوح.

في نموذج Babylon للأمان المشترك، الفكرة الأساسية هي أن مُرَهِني BTC يَؤجِرون الأمان لسلسلة الاستهلاك مقابل عائد من الإيجار. لكن سلطة تسعير الإيجار ليست بيد المُرَهِنين. سلسلة الاستهلاك تدفع الإيجار إلى البروتوكول، والبروتوكول يوزّع ذلك حسب صيغة داخلية ما—وهذه الصيغة هي «الصندوق الأسود». وبناءً على خبرتي في الامتثال المالي في لندن، فإن أي نموذج لتوزيع العائدات يفتقر إلى منحنى تسعير إيجار قابل للتدقيق لحظيًا، سيؤدي حتمًا في الظروف القصوى إلى حدوث ضغط/تدافع على الإيجارات. الـBTC التي تراهنها تتحمل مخاطر الـslash كاملة، بينما توزيع الإيجار يمر عبر بروتوكول على مرحلتين: اقتطاع ثانٍ ثم إعادة توزيع. هذا يشبه أن السيد لاو يوقّر البيت للوسيط، والوسيط يؤجره بدوره للسيد لاو آخر—والإيجار الذي يصل للسيد لاو ليس سعر السوق ولا يمكنه أن يقرر لمن يُؤجَّر، لأن العقود تُوقّع بالنيابة من خلال وسيط. وفي نهاية الشهر عند تسوية الحسابات، دائمًا توجد بضعة بنود في المعاملات لا يمكن تفسيرها، فيبقى السيد لاو عاجزًا عن شيء سوى التحديق.

إذا لم يتم إنشاء مسار شفاف بين توزيع الإيجار وتحمل المخاطر، فإن أي تعثر في سداد إيجار سلسلة الاستهلاك أو أي تعديل في معاملات التوزيع على مستوى البروتوكول سيؤثر مباشرة على عائد المُرَهِنين الفعلي. إن وضع نموذج العائدات في صندوق أسود غير شفاف لتوزيع الإيجار يشبه اختيار طلبات في بار دون رؤية تفاصيل الفاتورة؛ وفي النهاية عند الدفع تكتشف أنك دُفعت عليك عدة مشروبات أكثر مما ينبغي. نفور فسيولوجي.

في الوقت الحالي، تمسك تدفقات رأس المال من ناحية السوق قويّ، ويوجد دعم من المشترين لزيادة حجم القفل. لكن بالنسبة للتخصيص بالحصة الكبيرة، فإن شفافية حوكمة الإيجار هي حجر الأساس. قد يتجاهل السوق على المدى القصير صندوق العائدات الأسود، لكن التعرض غير المُغلَق للإيجارات سيظل موجودًا دائمًا. إذا استطاعت المجموعة إضافة آلية تسعير وتوزيع للإيجارات قابلة للتدقيق لحظيًا في التكرارات اللاحقة، فسترتفع درجة الحتمية بمقدار مستوى واحد. نصيحتي للجميع: عند بناء مركز، احتفظوا بمستوى من التبجيل/الحذر تجاه منطق توزيع إيجار BSN.
@BabylonLabs_io
تفضلوا إلى قسم تعليقات ساحة باينانس وتحدثوا: هل حسبتم كم طبقة من الإيجار تم اقتطاعها منكم؟
#baby $BABY

لقد أدرت إدارة الصلاحيات لسنوات طويلة، وهذه أول مرة أشعر فيها أننا قد يكون قد ساوينا بين "عدد الموقّعين" و"الأمان". منطق أغلب منصات DeFi هو: كلما زاد عدد الموقّعين، زادت لا مركزية البروتوكول. ثم اتضح أننا جمعنا الترقية والإيقاف ونقل الأصول كلها داخل عقد متعدد التواقيع واحد. يكفي تسريب مفتاح خاص واحد لتصبح التهديدات شاملة للنظام بأكمله. بصراحة، في كل مرة أرى تصميم "حزمة متعددة التواقيع واحدة تتولى كل شيء"، أشعر بشيء من القلق—ليس لأن عدد الموقّعين غير كافٍ، بل لأن دقة تجزئة الصلاحيات تتركز بشكل مبالغ فيه. أثناء بحثي مؤخرًا في Trustless Bitcoin Vaults لـ @babylonlabs_io ، لاحظت أن توجههم في التعامل مع الصلاحيات هو بالعكس: سكربت Bitcoin لا يعترف إلا بأمر واحد—ما إذا كانت توقيعات المفتاح العام متطابقة مع قفل زمني. إنشاء الـ vault وفك قفله يتحكمان فيه بالكامل بدائيات (primitives) السكربت، ولا توجد admin key، ولا لجنة متعددة التواقيع يمكنها تعديل القواعد لاحقًا. كأنها دكان قديم للعم تشين: ماكينة الكاش لا تهتم بوجه صاحب الدكان ولا تقبل إلا كلمة السر—والعم تشين يريد فتح باب خلفي، فلا يمكنه ذلك. هذا التقسيم في المهام محوري. في DeFi التقليدي، يتم ربط "توزيع الصلاحيات" بـ"تنفيذ الصلاحيات" معًا. أما TBV فيفصل بينهما: تُكتب قواعد الصلاحيات بشكل ثابت مرة واحدة عند إنشاء السكربت، ثم يصبح التنفيذ آليًا بالكامل لاحقًا. في جانب Ethereum، تعمل vaultBTC ومسارات التصفية داخل Aave Spoke مستقل، وبين سكربت Bitcoin وسكربت Bitcoin يتم تمرير نتائج التنفيذ فقط، وليس تمرير أي تغييرات في الصلاحيات. طبعًا لا ينبغي أن نبالغ في القول. إذا فقد المستخدم مفتاحه الخاص، فبعد انتهاء مدة القفل الزمني ستُطلق BTC تلقائيًا إلى العنوان المحدد؛ وهذا "التلقائي" بحد ذاته غير قابل للعكس. كنت قد قلت إن العم تشين لا يستطيع فتح باب خلفي، لكن إذا تم اختراق كلمة المرور فالباب الخلفي يُفتح—في بعض الأحيان تكون الصلابة المطلقة أشد صعوبة في الاسترداد من المخاطر المرنة. كما أن نموذج الصلاحيات لـ Aave Spoke ولـ Bitcoin script لغتان مختلفتان، وهل تم تدقيق منطق التحقق الذي يربط بينهما بشكل كافٍ؟ وما زال TBV لم يصل بالكامل إلى نقطة النهاية. مهما كان ما يفعله TBV الخاص بـ BABY مبهرًا، فإن فلسفته الأساسية تُختصر في جملة واحدة: الأمان ليس شيئًا يُبنى عبر حشد عدد أكبر من الموقّعين متعدد التواقيع، بل عبر تقليل الأمور التي تحتاج إلى قرارات صلاحيات. نعتقد دائمًا أن الأمان يعني كم شخص يراقب، لكن TBV يشير لاتجاه آخر—الأمان يعني كم أمر لا يحتاج أصلًا إلى شخص يراجع أو يتخذ قرارًا. هذه ليست مشكلة صلاحيات، بل مشكلة فهم كيفية توزيع السلطة. @babylonlabs_io #baby $BABY

لقد أدرت إدارة الصلاحيات لسنوات طويلة، وهذه أول مرة أشعر فيها أننا قد يكون قد ساوينا بين "عدد الموقّعين" و"الأمان".

منطق أغلب منصات DeFi هو: كلما زاد عدد الموقّعين، زادت لا مركزية البروتوكول. ثم اتضح أننا جمعنا الترقية والإيقاف ونقل الأصول كلها داخل عقد متعدد التواقيع واحد. يكفي تسريب مفتاح خاص واحد لتصبح التهديدات شاملة للنظام بأكمله. بصراحة، في كل مرة أرى تصميم "حزمة متعددة التواقيع واحدة تتولى كل شيء"، أشعر بشيء من القلق—ليس لأن عدد الموقّعين غير كافٍ، بل لأن دقة تجزئة الصلاحيات تتركز بشكل مبالغ فيه.

أثناء بحثي مؤخرًا في Trustless Bitcoin Vaults لـ @BabylonLabs_io ، لاحظت أن توجههم في التعامل مع الصلاحيات هو بالعكس: سكربت Bitcoin لا يعترف إلا بأمر واحد—ما إذا كانت توقيعات المفتاح العام متطابقة مع قفل زمني. إنشاء الـ vault وفك قفله يتحكمان فيه بالكامل بدائيات (primitives) السكربت، ولا توجد admin key، ولا لجنة متعددة التواقيع يمكنها تعديل القواعد لاحقًا. كأنها دكان قديم للعم تشين: ماكينة الكاش لا تهتم بوجه صاحب الدكان ولا تقبل إلا كلمة السر—والعم تشين يريد فتح باب خلفي، فلا يمكنه ذلك.

هذا التقسيم في المهام محوري. في DeFi التقليدي، يتم ربط "توزيع الصلاحيات" بـ"تنفيذ الصلاحيات" معًا. أما TBV فيفصل بينهما: تُكتب قواعد الصلاحيات بشكل ثابت مرة واحدة عند إنشاء السكربت، ثم يصبح التنفيذ آليًا بالكامل لاحقًا. في جانب Ethereum، تعمل vaultBTC ومسارات التصفية داخل Aave Spoke مستقل، وبين سكربت Bitcoin وسكربت Bitcoin يتم تمرير نتائج التنفيذ فقط، وليس تمرير أي تغييرات في الصلاحيات.

طبعًا لا ينبغي أن نبالغ في القول. إذا فقد المستخدم مفتاحه الخاص، فبعد انتهاء مدة القفل الزمني ستُطلق BTC تلقائيًا إلى العنوان المحدد؛ وهذا "التلقائي" بحد ذاته غير قابل للعكس. كنت قد قلت إن العم تشين لا يستطيع فتح باب خلفي، لكن إذا تم اختراق كلمة المرور فالباب الخلفي يُفتح—في بعض الأحيان تكون الصلابة المطلقة أشد صعوبة في الاسترداد من المخاطر المرنة. كما أن نموذج الصلاحيات لـ Aave Spoke ولـ Bitcoin script لغتان مختلفتان، وهل تم تدقيق منطق التحقق الذي يربط بينهما بشكل كافٍ؟ وما زال TBV لم يصل بالكامل إلى نقطة النهاية.

مهما كان ما يفعله TBV الخاص بـ BABY مبهرًا، فإن فلسفته الأساسية تُختصر في جملة واحدة: الأمان ليس شيئًا يُبنى عبر حشد عدد أكبر من الموقّعين متعدد التواقيع، بل عبر تقليل الأمور التي تحتاج إلى قرارات صلاحيات. نعتقد دائمًا أن الأمان يعني كم شخص يراقب، لكن TBV يشير لاتجاه آخر—الأمان يعني كم أمر لا يحتاج أصلًا إلى شخص يراجع أو يتخذ قرارًا. هذه ليست مشكلة صلاحيات، بل مشكلة فهم كيفية توزيع السلطة.
@BabylonLabs_io
#baby $BABY

الدقيقة التاسعة: إلى أي خطوة يجب ترقية الاستنتاج؟ توجد في سلسلة عقوبات EOTS الخاصة بالرقم @babylonlabs_io سجلا لشبكة اختبار عامة: بعد أن قامت جهة Finality Provider بإثارة شبهة التوقيع المزدوج، حدثت خلال 8 دقائق و42 ثانية، وتم وسم حصة الضمان المقابلة في البروتوكول على أنها slashable. لا يمكن أن يكون الجواب إلا "تمت إكمال إجراء وسم العقوبة في تلك المرة"، ولا يجوز كتابته مباشرةً "نموذج الأمان لا يُخترق". سبب العطل يعود إلى ساعتين منبه/كرونومتر مربوطتين على جهاز مشي واحد. تبدأ السريعة بالعد من لحظة إثارة شبهة التوقيع المزدوج، وتغطي فقط إجراء وسم البروتوكول. توقفت عند الدقيقة 8 و42 ثانية، ويمكنها تأكيد نجاح عملية كشف واحدة؛ لكنها لا تستطيع رؤية سجلّات هذا الـProvider خلال 47 يوماً متواصلة من الإنتاج العادي قبل ذلك، ولا تلاحظ مخططات إدارة المفاتيح الخاصة مع النسخ الاحتياطي لدى أي Provider آخر. فإذا تعاملت مع السريعة كتقييم شامل للبدنية، فستُرقّي مرة اندفاع إلى سرعة «SOP» للياقة بأكملها. لا توجد لدى السلوو/البطيئة إشارة انتهاء الحصة في الدقيقة التاسعة. كما أنها تحمل تعاوناً وظروفاً طويلة الأمد: في الـExplorer العام توجد بالفعل سجلات لِـProvider جرى اختراقه بسبب عيوب في خطة نسخ مفاتيح المفوض/الخاص، لكن لم يتم اكتشاف الأمر في الوقت المناسب؛ وهذه الـ8 دقائق و42 ثانية هي مجرد سجل لاختبار شبكة ثنائي/شبكة تجريبية «single» وليست مقام/معدل استجابة لِجميع الـProvider في الشبكة الرئيسية. كما أن خاصية "قابل للاستخراج" في EOTS تعتمد على أن يقوم المراقبون أسفل السلسلة بتقديم برهان احتيال بشكل فعّال، وما تزال درجة لا مركزية شبكة المراقبة واستدامة الحوافز تحت الملاحظة، كما لا توجد شهادة تقوم مقام «الأمان المطلق» أيضاً. ولا يمكن لأي من هذه الأمور الثلاثة أن تُقرأ من السريعة. وعكس ذلك، فإن عدم كشف واحد لا يعني الحكم بأن السلوو/البطيئة غير فعّالة إلى الأبد. الحالة التي يمكن الصدق بها الآن هي: يمكن إكمال وسم العقوبة لمرة واحدة، لكن تغطية المراقبة عبر الشبكات والمرونة في الشبكة الرئيسية لا تزال تفتقر إلى أدلة مختلفة. وعندما ترى مجدداً "8 دقائق و42 ثانية"، اسأل أولاً: من أي لحظة يبدأ العدّ؟ وأي إجراء يقوم به جهاز المشي؟ ولا يلزم استعجال تبديل تصنيف الأمان في الدقيقة التاسعة. #baby $BABY

الدقيقة التاسعة: إلى أي خطوة يجب ترقية الاستنتاج؟

توجد في سلسلة عقوبات EOTS الخاصة بالرقم @BabylonLabs_io سجلا لشبكة اختبار عامة: بعد أن قامت جهة Finality Provider بإثارة شبهة التوقيع المزدوج، حدثت خلال 8 دقائق و42 ثانية، وتم وسم حصة الضمان المقابلة في البروتوكول على أنها slashable. لا يمكن أن يكون الجواب إلا "تمت إكمال إجراء وسم العقوبة في تلك المرة"، ولا يجوز كتابته مباشرةً "نموذج الأمان لا يُخترق".

سبب العطل يعود إلى ساعتين منبه/كرونومتر مربوطتين على جهاز مشي واحد.

تبدأ السريعة بالعد من لحظة إثارة شبهة التوقيع المزدوج، وتغطي فقط إجراء وسم البروتوكول. توقفت عند الدقيقة 8 و42 ثانية، ويمكنها تأكيد نجاح عملية كشف واحدة؛ لكنها لا تستطيع رؤية سجلّات هذا الـProvider خلال 47 يوماً متواصلة من الإنتاج العادي قبل ذلك، ولا تلاحظ مخططات إدارة المفاتيح الخاصة مع النسخ الاحتياطي لدى أي Provider آخر. فإذا تعاملت مع السريعة كتقييم شامل للبدنية، فستُرقّي مرة اندفاع إلى سرعة «SOP» للياقة بأكملها.

لا توجد لدى السلوو/البطيئة إشارة انتهاء الحصة في الدقيقة التاسعة. كما أنها تحمل تعاوناً وظروفاً طويلة الأمد: في الـExplorer العام توجد بالفعل سجلات لِـProvider جرى اختراقه بسبب عيوب في خطة نسخ مفاتيح المفوض/الخاص، لكن لم يتم اكتشاف الأمر في الوقت المناسب؛ وهذه الـ8 دقائق و42 ثانية هي مجرد سجل لاختبار شبكة ثنائي/شبكة تجريبية «single» وليست مقام/معدل استجابة لِجميع الـProvider في الشبكة الرئيسية. كما أن خاصية "قابل للاستخراج" في EOTS تعتمد على أن يقوم المراقبون أسفل السلسلة بتقديم برهان احتيال بشكل فعّال، وما تزال درجة لا مركزية شبكة المراقبة واستدامة الحوافز تحت الملاحظة، كما لا توجد شهادة تقوم مقام «الأمان المطلق» أيضاً. ولا يمكن لأي من هذه الأمور الثلاثة أن تُقرأ من السريعة.

وعكس ذلك، فإن عدم كشف واحد لا يعني الحكم بأن السلوو/البطيئة غير فعّالة إلى الأبد. الحالة التي يمكن الصدق بها الآن هي: يمكن إكمال وسم العقوبة لمرة واحدة، لكن تغطية المراقبة عبر الشبكات والمرونة في الشبكة الرئيسية لا تزال تفتقر إلى أدلة مختلفة. وعندما ترى مجدداً "8 دقائق و42 ثانية"، اسأل أولاً: من أي لحظة يبدأ العدّ؟ وأي إجراء يقوم به جهاز المشي؟ ولا يلزم استعجال تبديل تصنيف الأمان في الدقيقة التاسعة.
#baby $BABY

الساعة الثانية فجرًا، أخرجت مرة أخرى حاشية الرقم في فقرة 5.1 من ورقة الـ@babylonlabs_io البيضاء: "على المتحدّين تحمل تكاليف التحقق على السلسلة بأنفسهم." تراكمت ثلاثة أعواد في مِرمى الرماد، وحسبت أمرًا واحدًا—لا داعي لِـلاو تشانغ أن يتحمّل هذا الحساب. افصلها لتفهم. المقترض والمُصفّي يراقب كلٌ منهما الآخر؛ إذا سحب أحدهما بطريقة خبيثة، يتحداه الطرف الآخر فورًا. يبدو الأمر مثاليًا للتوازن بين الأطراف، أليس كذلك؟ لكن بدء تحدٍّ واحد يتطلب إنهاء تحقق دوائر تشفير بحجم 43 جيجابايت من البيانات، وقد تكون رسوم الغاز أعلى من فوائد الـBTC التي قفلتها. هذا يشبه مقولة البار: "إذا وجدتَ خمرًا مزيفًا أبلغ عنه، وسنعطيك كأس خمر حقيقي"—لكن رقم الهاتف للإبلاغ اتصال دولي، فاتورته أغلى من ثمن الكأس. أودع لاو تشانغ 0.5 BTC، بعائد سنوي بضعة نقاط فقط. أودع دا تشانغ خمسمئة، ويُبقي عقد AWS تعمل. داخل الخزنة توجد عملية سحب مشبوهة؛ ينظر لاو تشانغ إلى تقدير الغاز، فيختار الصمت. ينقر دا تشانغ الماوس بخفة، تُقدَّم عملية التحدي، فتُجمع كل التعويضات الأمنية. قصّت Babylon على المحكمة، لكنها نقلت رسوم التقاضي إلى السلسلة، وزاد حسابات ZK من رفع العتبة. فما الذي تفعله الـBABY؟ في القسم العاشر من الورقة البيضاء يُقال إنك تدفع الغاز وتشارك في الحوكمة. لكن الـBABY ليست مجرد تذكرة؛ إنها وحدة تسعير رسوم التقاضي. تريد أن تكون متحدّيًا؟ اشترِ BABY لتغطي الغاز. تريد خفض تكلفة التحدي؟ حوّل رصيدك إلى عتبة الحوكمة. لكن غاز التحدي وحده قد استبعد تسعين بالمئة من صغار المستثمرين؛ وفي بركة التصويت يجلس فقط من يستطيعون دفع تكلفة التحدي. "تحسين التكلفة" الذي يراهنون عليه لا يحسّن تكلفة غيرهم—بل يُحسّن تكلفة أنفسهم، لا تكلفة لاو تشانغ. في نظرية الألعاب يُسمّى هذا "قيد المشاركة" غير محقق—لأن النموذج يفترض أن الجميع قادر على الدخول، بينما الواقع أن أغلب الناس لا يستطيعون حتى لمس طاولة الورق. موقفي: من الناحية الورقية كل شيء متماسك، بشرط أن حق التحدي يكون فعليًا مفتوحًا. عندما تجعل تكاليف السلسلة التحدي سلاحًا حصريًا للكبار أصحاب رأس المال، تنزلق هذه الآلية من "نزع الثقة" إلى "توزيع العدالة وفق رأس المال". لا يحتاج دا تشانغ إلى سحب خبيث؛ يكفي أن يضمن بقاء تكلفة التحدي دائمًا أعلى من عائد صغار المستثمرين، ليتمتع بتفسير قواعد اللعبة في صمتهم. على طريقتنا القديمة: DYOR. لا تظن أن "الإشراف المتبادل" يعني عدلًا تلقائيًا—امسح أولًا ما في جيبك من BABY، وهل تكفي لدفع غاز قول الحقيقة مرة واحدة. اذهب إلى قسم التعليقات في باينانس وقُمْ بعرض كشف حسابك. #baby BABY #baby $BABY

الساعة الثانية فجرًا، أخرجت مرة أخرى حاشية الرقم في فقرة 5.1 من ورقة الـ@BabylonLabs_io البيضاء: "على المتحدّين تحمل تكاليف التحقق على السلسلة بأنفسهم." تراكمت ثلاثة أعواد في مِرمى الرماد، وحسبت أمرًا واحدًا—لا داعي لِـلاو تشانغ أن يتحمّل هذا الحساب.

افصلها لتفهم. المقترض والمُصفّي يراقب كلٌ منهما الآخر؛ إذا سحب أحدهما بطريقة خبيثة، يتحداه الطرف الآخر فورًا. يبدو الأمر مثاليًا للتوازن بين الأطراف، أليس كذلك؟ لكن بدء تحدٍّ واحد يتطلب إنهاء تحقق دوائر تشفير بحجم 43 جيجابايت من البيانات، وقد تكون رسوم الغاز أعلى من فوائد الـBTC التي قفلتها.

هذا يشبه مقولة البار: "إذا وجدتَ خمرًا مزيفًا أبلغ عنه، وسنعطيك كأس خمر حقيقي"—لكن رقم الهاتف للإبلاغ اتصال دولي، فاتورته أغلى من ثمن الكأس. أودع لاو تشانغ 0.5 BTC، بعائد سنوي بضعة نقاط فقط. أودع دا تشانغ خمسمئة، ويُبقي عقد AWS تعمل. داخل الخزنة توجد عملية سحب مشبوهة؛ ينظر لاو تشانغ إلى تقدير الغاز، فيختار الصمت. ينقر دا تشانغ الماوس بخفة، تُقدَّم عملية التحدي، فتُجمع كل التعويضات الأمنية.

قصّت Babylon على المحكمة، لكنها نقلت رسوم التقاضي إلى السلسلة، وزاد حسابات ZK من رفع العتبة.

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

في نظرية الألعاب يُسمّى هذا "قيد المشاركة" غير محقق—لأن النموذج يفترض أن الجميع قادر على الدخول، بينما الواقع أن أغلب الناس لا يستطيعون حتى لمس طاولة الورق.

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

على طريقتنا القديمة: DYOR. لا تظن أن "الإشراف المتبادل" يعني عدلًا تلقائيًا—امسح أولًا ما في جيبك من BABY، وهل تكفي لدفع غاز قول الحقيقة مرة واحدة. اذهب إلى قسم التعليقات في باينانس وقُمْ بعرض كشف حسابك. #baby BABY
#baby $BABY

مرحلة 2 الخاصة بـ BABY، كنت أتابعها لثلاث دورات بالفعل。 في الجولة الأولى، راهنت على الربع الرابع من عام 2024. في ذلك الوقت كانت Phase 1 قد أُطلقت للتو، وتم قفل أكثر من خمسين ألف BTC داخل العقود مثل اللحم المجمّد، وفي مجموعات المجتمع كان الجميع يعدّون النبض لبدء سلسلة PoS. في ليلة رأس السنة، كنت أجلس أمام متصفح البوابة وأنتظر إشارة الشبكة الرئيسية، لكن الذي جاءني لم يكن إشعارًا من الشبكة، بل ورقة تقول: "متابعة التحقق". عندها، قالت المرحلة 2 إنها ستُدفع إلى 2025. قلت لنفسي إن النماذج الأمنية لا ضرر من مراجعتها لعدة جولات؛ ومعلمات التشغيل الخاصة بـ Finality Provider لا يمكن تركها لحدس عابر. في الجولة الثانية، عدّلت توقعاتي إلى ما بعد عيد الربيع الصيني في 2025. النتيجة أن الجهات الرسمية لم تقدم تاريخًا محددًا، بل اكتفت بجملة من نوع حساء القطع: "قريبًا سيتم الإطلاق". حتى الجولة الثالثة، ثبّت Babylon تاريخ 10 أبريل في التقويم أخيرًا. لكن الآن لم أعد في حالة انتظار—بل كأنني أنتظر مقاولًا وعد أكثر من مرة ولم يوفِ: ما تريد تأكيده هو هل سيأتي هذه المرة فعلًا أم لا. التأخير مرة يُسمّى حذرًا، والتأخير مرتين يحتاج إلى تفسير، أما تغيير الموعد مرارًا فليس ما يُستنزف دائمًا هو الصبر فقط، بل هو سقف ثقة المجتمع بقدرة التنفيذ. خلال هذه الفترة، لم يكن دور @babylonlabs_io بلا حركة: فقد وزّع 600 مليون BABY على المساهمين الأوائل، وذكر حوض تحفيز المجتمع نسبة 15%، كما أجروا Staking مزدوجًا بحيث يعطي BTC وBABY معًا الشبكة "الحراسة". بالنسبة لمجتمع صبر نصف سنة، هذا بمثابة حلوى. لكن المشكلة أن الحلوى قد تُسكت المشاعر، إلا أنها لا تعوّض فجوات الثقة التي يمزّقها عدم اليقين على المدى الطويل. ما يهم كبار متابعي العجلة حقًا ليس كمية اللحم في الوعاء، بل هل ستُفتح هذه الوجبة في موعدها. لن أُنكر Babylon بالكامل بسبب التأجيل؛ نموذج الأمان الذي تم تحسينه صار بوابة حصينة للجميع. لكن مشروعًا يحتاج حتى في مرحلة الشبكة الرئيسية إلى تثبيت التاريخ ثلاث مرات، من الصعب ألا يثير المزيد من التفكير: هل ستصبح جداول Multi-staking وموعد EVM mainnet أيضًا "شيكات مرسومة على رمال الشاطئ"؟ إذا كان Q4 حقًا سيتم تسليمه في موعده، يمكن تحويل كل انتظارٍ سابق إلى مقدمات. لكن إن تكرر التعثر مرة أخرى، فلن يكون ما يُستهلك هو الوقت فقط، بل أيضًا قلوب الناس. وفي النهاية، دع ارتفاع البلوكات على السلسلة هو من يشهد وحده. #babylon BABY #baby $BABY $BTC

مرحلة 2 الخاصة بـ BABY، كنت أتابعها لثلاث دورات بالفعل。

في الجولة الأولى، راهنت على الربع الرابع من عام 2024. في ذلك الوقت كانت Phase 1 قد أُطلقت للتو، وتم قفل أكثر من خمسين ألف BTC داخل العقود مثل اللحم المجمّد، وفي مجموعات المجتمع كان الجميع يعدّون النبض لبدء سلسلة PoS. في ليلة رأس السنة، كنت أجلس أمام متصفح البوابة وأنتظر إشارة الشبكة الرئيسية، لكن الذي جاءني لم يكن إشعارًا من الشبكة، بل ورقة تقول: "متابعة التحقق". عندها، قالت المرحلة 2 إنها ستُدفع إلى 2025. قلت لنفسي إن النماذج الأمنية لا ضرر من مراجعتها لعدة جولات؛ ومعلمات التشغيل الخاصة بـ Finality Provider لا يمكن تركها لحدس عابر.

في الجولة الثانية، عدّلت توقعاتي إلى ما بعد عيد الربيع الصيني في 2025. النتيجة أن الجهات الرسمية لم تقدم تاريخًا محددًا، بل اكتفت بجملة من نوع حساء القطع: "قريبًا سيتم الإطلاق". حتى الجولة الثالثة، ثبّت Babylon تاريخ 10 أبريل في التقويم أخيرًا. لكن الآن لم أعد في حالة انتظار—بل كأنني أنتظر مقاولًا وعد أكثر من مرة ولم يوفِ: ما تريد تأكيده هو هل سيأتي هذه المرة فعلًا أم لا. التأخير مرة يُسمّى حذرًا، والتأخير مرتين يحتاج إلى تفسير، أما تغيير الموعد مرارًا فليس ما يُستنزف دائمًا هو الصبر فقط، بل هو سقف ثقة المجتمع بقدرة التنفيذ.

خلال هذه الفترة، لم يكن دور @babylonlabs_io بلا حركة: فقد وزّع 600 مليون BABY على المساهمين الأوائل، وذكر حوض تحفيز المجتمع نسبة 15%، كما أجروا Staking مزدوجًا بحيث يعطي BTC وBABY معًا الشبكة "الحراسة". بالنسبة لمجتمع صبر نصف سنة، هذا بمثابة حلوى. لكن المشكلة أن الحلوى قد تُسكت المشاعر، إلا أنها لا تعوّض فجوات الثقة التي يمزّقها عدم اليقين على المدى الطويل. ما يهم كبار متابعي العجلة حقًا ليس كمية اللحم في الوعاء، بل هل ستُفتح هذه الوجبة في موعدها.

لن أُنكر Babylon بالكامل بسبب التأجيل؛ نموذج الأمان الذي تم تحسينه صار بوابة حصينة للجميع. لكن مشروعًا يحتاج حتى في مرحلة الشبكة الرئيسية إلى تثبيت التاريخ ثلاث مرات، من الصعب ألا يثير المزيد من التفكير: هل ستصبح جداول Multi-staking وموعد EVM mainnet أيضًا "شيكات مرسومة على رمال الشاطئ"؟ إذا كان Q4 حقًا سيتم تسليمه في موعده، يمكن تحويل كل انتظارٍ سابق إلى مقدمات. لكن إن تكرر التعثر مرة أخرى، فلن يكون ما يُستهلك هو الوقت فقط، بل أيضًا قلوب الناس. وفي النهاية، دع ارتفاع البلوكات على السلسلة هو من يشهد وحده. #babylon BABY
#baby $BABY $BTC

الآن أراقب BABY، ولن أسأل أولًا ما إذا كان مجرد ميم آخر يعتمد على استمرار الحياة عبر العاطفة. التوكنات متعددة السلاسل التي تُقدِّم انكماشًا حقيقيًا يجب أن تجيب عن سؤال داخل أعماق العقد: كل تحويل تُسحب منه 6%—من لحظة خصمها إلى أن تتحول لتضخيم LP وارتدادات في المحفظة—فكم الفاصل الزمني في التسوية بينهما؟ وعندما تتكدس السلسلة بالكامل كأنها موقف سيارات، هل ستتعطل هذه «خطوط الفوترة» الضريبية؟ عقد BabyDoge يقتطع الضريبة لحظة إجراء التحويل؛ يتكدس التوكن أولًا في عنوان العقد، ثم بعد الوصول إلى عتبة معينة يقوم بعملية swap مرة واحدة لإضافته إلى الحوض. عندما تكون أحجام التداول اليومية وفيرة، يبدو كل شيء «سلسًا»: خصم الضريبة، تجميع الحوض، ثم التوزيع/الـreflections. لكن عندما تتقلب السوق بعنف، تُكدَّس في المطبخ فجأة أوعية «قذرة»: تحدث تحوّلات كثيرة في وقت واحد، فتتمدد محفظة الضرائب خلال وقت قصير، ويُجبَر تفعيل الـswap التلقائي على التواتر بشكل أسرع. وكل عملية swap تضرب عمق الحوض من الاتجاه العكسي. أما وصول مكافآت الارتداد فيعتمد على اجتياز حالة العقد؛ وإذا صار الغاز أغلى والكتل ممتلئة، تتحول «الـreflections» من حافز فوري إلى سندات تأجيل بالدفع. والجانب عبر السلاسل أكثر غموضًا. على BSC وEthereum وSolana تعمل نسخ مطابقة لعقد BABY، لكن جسر الربط ليس تبادلًا ذريًا؛ توجد فجوة تأكيد بين عملية الإصدار (mint) وعملية القفل (lock). في العادة تختبئ المشكلة تحت غطاء السيولة، لكن بمجرد ظهور ضغط بيع مركز على سلسلة ما، تتكشف فورًا لا تماثلية عمق الأحواض على طرفي الجسر. أنت تظنها 1:1 مرتبطًا، ثم عندما ينحسر المدّ تعرف أي جهة كانت تسبح عارية. في نموذج التوكن توجد أرقام تدمير تبدو جميلة وسردية «الارتداد/الانعكاس»، وتقدر على إشعال العاطفة على المدى القصير؛ لكن على المدى الطويل يعتمد الأمر على السمك الحقيقي لقاعدة الضريبة على السلسلة. إذا كان حجم التداول يعتمد على FOMO قصير الأجل، فسوف ينكمش حوض الضرائب، وستنخفض بشكل هامشي كل من الإضافة التلقائية إلى الحوض وتوزيعات الـreflections. حتى لو تكدست أصفار في عنوان التدمير، لن تدعم السعر. الخطوة التالية أريد تفكيك عدة مؤشرات صارمة: الانزلاق العكسي الناتج عن swap الخاص بالعقد الضريبي مقارنةً بالحوض الرئيسي، والوسيط الزمني لتأخر وصول الارتداد عندما يرتفع الغاز، ومدى انحراف فرق السعر اللحظي بين أحواض BSC وEthereum، وما إذا كانت سجلات الإصدار/القفل على جسر عبر السلاسل تحت التوازي العالي تتطابق مع بعضها. نقاط قوة BABY لا تكمن في «تغليف الانكماش الفائق»، بل في ما إذا كان بإمكانه تحويل هذه الأنابيب الخمس—خصم الضريبة، التصفية، الإضافة إلى الحوض، الارتداد/الـreflections، وربط عبر السلاسل—إلى حلقة مغلقة محكمة لا تتسرب. يمكن للسرد أن يخدع المبتدئين، لكن أداء العقد تحت ضغط حقيقي على السلسلة لا يمكن خداعه. #baby $BABY $BTC

الآن أراقب BABY، ولن أسأل أولًا ما إذا كان مجرد ميم آخر يعتمد على استمرار الحياة عبر العاطفة. التوكنات متعددة السلاسل التي تُقدِّم انكماشًا حقيقيًا يجب أن تجيب عن سؤال داخل أعماق العقد: كل تحويل تُسحب منه 6%—من لحظة خصمها إلى أن تتحول لتضخيم LP وارتدادات في المحفظة—فكم الفاصل الزمني في التسوية بينهما؟ وعندما تتكدس السلسلة بالكامل كأنها موقف سيارات، هل ستتعطل هذه «خطوط الفوترة» الضريبية؟

عقد BabyDoge يقتطع الضريبة لحظة إجراء التحويل؛ يتكدس التوكن أولًا في عنوان العقد، ثم بعد الوصول إلى عتبة معينة يقوم بعملية swap مرة واحدة لإضافته إلى الحوض. عندما تكون أحجام التداول اليومية وفيرة، يبدو كل شيء «سلسًا»: خصم الضريبة، تجميع الحوض، ثم التوزيع/الـreflections. لكن عندما تتقلب السوق بعنف، تُكدَّس في المطبخ فجأة أوعية «قذرة»: تحدث تحوّلات كثيرة في وقت واحد، فتتمدد محفظة الضرائب خلال وقت قصير، ويُجبَر تفعيل الـswap التلقائي على التواتر بشكل أسرع. وكل عملية swap تضرب عمق الحوض من الاتجاه العكسي. أما وصول مكافآت الارتداد فيعتمد على اجتياز حالة العقد؛ وإذا صار الغاز أغلى والكتل ممتلئة، تتحول «الـreflections» من حافز فوري إلى سندات تأجيل بالدفع.

والجانب عبر السلاسل أكثر غموضًا. على BSC وEthereum وSolana تعمل نسخ مطابقة لعقد BABY، لكن جسر الربط ليس تبادلًا ذريًا؛ توجد فجوة تأكيد بين عملية الإصدار (mint) وعملية القفل (lock). في العادة تختبئ المشكلة تحت غطاء السيولة، لكن بمجرد ظهور ضغط بيع مركز على سلسلة ما، تتكشف فورًا لا تماثلية عمق الأحواض على طرفي الجسر. أنت تظنها 1:1 مرتبطًا، ثم عندما ينحسر المدّ تعرف أي جهة كانت تسبح عارية.

في نموذج التوكن توجد أرقام تدمير تبدو جميلة وسردية «الارتداد/الانعكاس»، وتقدر على إشعال العاطفة على المدى القصير؛ لكن على المدى الطويل يعتمد الأمر على السمك الحقيقي لقاعدة الضريبة على السلسلة. إذا كان حجم التداول يعتمد على FOMO قصير الأجل، فسوف ينكمش حوض الضرائب، وستنخفض بشكل هامشي كل من الإضافة التلقائية إلى الحوض وتوزيعات الـreflections. حتى لو تكدست أصفار في عنوان التدمير، لن تدعم السعر.

الخطوة التالية أريد تفكيك عدة مؤشرات صارمة: الانزلاق العكسي الناتج عن swap الخاص بالعقد الضريبي مقارنةً بالحوض الرئيسي، والوسيط الزمني لتأخر وصول الارتداد عندما يرتفع الغاز، ومدى انحراف فرق السعر اللحظي بين أحواض BSC وEthereum، وما إذا كانت سجلات الإصدار/القفل على جسر عبر السلاسل تحت التوازي العالي تتطابق مع بعضها.

نقاط قوة BABY لا تكمن في «تغليف الانكماش الفائق»، بل في ما إذا كان بإمكانه تحويل هذه الأنابيب الخمس—خصم الضريبة، التصفية، الإضافة إلى الحوض، الارتداد/الـreflections، وربط عبر السلاسل—إلى حلقة مغلقة محكمة لا تتسرب. يمكن للسرد أن يخدع المبتدئين، لكن أداء العقد تحت ضغط حقيقي على السلسلة لا يمكن خداعه.
#baby $BABY $BTC

لقد قضيت هذين الأسبوعين في قراءة وثائق شبكة الاختبار من Babylon، وكلما قرأت أكثر شعرت أن هناك شيئًا غير سليم. من حيث المظهر يبدو الأمر كأنه يبحث عن عوائد لبيتكوين، لكن في الواقع إنه يقوم بأمر أكثر خفاءً: تحويل الخصائص الأمنية لـ"BTC" من "أصل سلبي" إلى "موارد قابلة للجدولة". كان لدى لاو تشانغ عدة بيتكوينات احتفظ بها لمدة خمس سنوات دون أن يتحرك منها شيء. في السابق كان يريد أن تُدر هذه الكومة عائدًا—لكن الطريق كان في غاية التعقيد: إما أن يرسلها إلى بورصة ويوقّع سلسلة من البروتوكولات، أو أن ينقلها إلى إيثيريوم ليصير WBTC. في كل خطوة كان يوزّع مخاطر المفتاح الخاص إلى جهات خارجية. جوهريًا، الأمر ليس أن BTC تعمل لصالحه، بل أنه يعمل لصالح الجسور ومنصات الحفظ المختلفة. غيرت Babylon أسلوبها. فهي لا تسألك هل ستستخدم جسورًا أم لا، ولا هل ستعبر أم لا، ولا حتى هل ستستخدم الحفظ أم لا. كل ما تسأل عنه سؤال واحد فقط: هل أنت مستعد أن تقفل جزءًا من BTC في سكربت بيتكوين الأصلي لفترة، لتعمل كحارس أمن للآخرين؟ أما الباقي—مدة القفل، ولمن تكون الحراسة، وكيف تُعوّض إن حدثت عملية "القطع" (slash)، وكيف يُحسب العائد—فكل ذلك يصبح مُحوَّلًا إلى بروتوكولات ومُؤتمتًا. هذا ما يسمونه "التجريد الأمني". يبدو كأنه ستاكينغ، لكن في الحقيقة هو بناء مركز لجدولة الأمن على السلسلة الرئيسية لـBTC. الكثيرون لم يلاحظوا انتقال السلطة الكامن هنا. عندما يقوم عدد كبير من BTC على مدى طويل بتقديم الأمان عبر هذا المسار، فإن ما ينحصر في الراكَم ليس مجرد رقم TVL، بل يتحول إلى نفوذ في الأمن الاقتصادي لبيتكوين. سواء أقفلت لمدة ثلاثة أشهر أم ثلاث سنوات، وهل تفضّل أن تُسهم كـ Finality Provider على شبكة Cosmos، أم أن تمنح هذا الأمان لشبكة جديدة تقوم بتأمين الإطلاق، ومدى قدرتك على تحمّل تعرض slash—هذه الاختيارات في النهاية ستتحول إلى مواد أولية لتحسين تسعير الأمن عبر البروتوكولات. ببساطة، سوق أمن البلوك تشين في المستقبل ربما لن يُقاس فقط بمن يملك كمية أكبر من الأصول المُكدّسة، بل بمن يملك "خريطة سلوك" حاملي BTC. أما بروتوكولات الستاكينغ الأخرى، فهي غالبًا لا تتجاوز أن تكون مجرد "وسيط للحراسة". أما Babylon، فهدفها أن تكون "الشبكة الكهربائية الوطنية" لأمن بيتكوين—جدولة موحّدة، تسعير على طبقات، وتوزيع عند الطلب. الفرق فقط هو أن الشبكة الكهربائية الوطنية تُدير الكهرباء، بينما #Babylon تريد إدارة قوة ردع البيتكوين. لكن في الوقت الحالي، ما زالت السوق تُسعّر ذلك وفقًا لنمو TVL ومعدل عوائد الستاكينغ. وإذا لم يحدث اعتماد حقيقي لاحقًا—أي إذا لم يكن هناك عدد كافٍ من سلاسل PoS مستعدة لدفع ثمن هذا الأمان—فإن "الشبكة الكهربائية الوطنية" قد تتحول بسهولة إلى منافسة من أجل جذب الودائع بعوائد مرتفعة. #baby $BABY $BTC

لقد قضيت هذين الأسبوعين في قراءة وثائق شبكة الاختبار من Babylon، وكلما قرأت أكثر شعرت أن هناك شيئًا غير سليم. من حيث المظهر يبدو الأمر كأنه يبحث عن عوائد لبيتكوين، لكن في الواقع إنه يقوم بأمر أكثر خفاءً: تحويل الخصائص الأمنية لـ"BTC" من "أصل سلبي" إلى "موارد قابلة للجدولة".

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

غيرت Babylon أسلوبها. فهي لا تسألك هل ستستخدم جسورًا أم لا، ولا هل ستعبر أم لا، ولا حتى هل ستستخدم الحفظ أم لا. كل ما تسأل عنه سؤال واحد فقط: هل أنت مستعد أن تقفل جزءًا من BTC في سكربت بيتكوين الأصلي لفترة، لتعمل كحارس أمن للآخرين؟ أما الباقي—مدة القفل، ولمن تكون الحراسة، وكيف تُعوّض إن حدثت عملية "القطع" (slash)، وكيف يُحسب العائد—فكل ذلك يصبح مُحوَّلًا إلى بروتوكولات ومُؤتمتًا. هذا ما يسمونه "التجريد الأمني". يبدو كأنه ستاكينغ، لكن في الحقيقة هو بناء مركز لجدولة الأمن على السلسلة الرئيسية لـBTC.

الكثيرون لم يلاحظوا انتقال السلطة الكامن هنا. عندما يقوم عدد كبير من BTC على مدى طويل بتقديم الأمان عبر هذا المسار، فإن ما ينحصر في الراكَم ليس مجرد رقم TVL، بل يتحول إلى نفوذ في الأمن الاقتصادي لبيتكوين. سواء أقفلت لمدة ثلاثة أشهر أم ثلاث سنوات، وهل تفضّل أن تُسهم كـ Finality Provider على شبكة Cosmos، أم أن تمنح هذا الأمان لشبكة جديدة تقوم بتأمين الإطلاق، ومدى قدرتك على تحمّل تعرض slash—هذه الاختيارات في النهاية ستتحول إلى مواد أولية لتحسين تسعير الأمن عبر البروتوكولات.

ببساطة، سوق أمن البلوك تشين في المستقبل ربما لن يُقاس فقط بمن يملك كمية أكبر من الأصول المُكدّسة، بل بمن يملك "خريطة سلوك" حاملي BTC. أما بروتوكولات الستاكينغ الأخرى، فهي غالبًا لا تتجاوز أن تكون مجرد "وسيط للحراسة". أما Babylon، فهدفها أن تكون "الشبكة الكهربائية الوطنية" لأمن بيتكوين—جدولة موحّدة، تسعير على طبقات، وتوزيع عند الطلب.

الفرق فقط هو أن الشبكة الكهربائية الوطنية تُدير الكهرباء، بينما #Babylon تريد إدارة قوة ردع البيتكوين.

لكن في الوقت الحالي، ما زالت السوق تُسعّر ذلك وفقًا لنمو TVL ومعدل عوائد الستاكينغ. وإذا لم يحدث اعتماد حقيقي لاحقًا—أي إذا لم يكن هناك عدد كافٍ من سلاسل PoS مستعدة لدفع ثمن هذا الأمان—فإن "الشبكة الكهربائية الوطنية" قد تتحول بسهولة إلى منافسة من أجل جذب الودائع بعوائد مرتفعة.
#baby $BABY $BTC

قواعد BABY للأطفال الرضع: لا ينبغي أن تقارن فقط من يملك أكثر BTC “مقفلًا” في صندوقه قبل أيام تحدثت مع BABY، وكان حديثي عن: “كيف نُوقظ البيتكوين الموجود في المحفظة الباردة”. اليوم زاوية أشد: كلما قفلت BTC أكثر في بروتوكول، فهذا لا يعني أن المودِعين أكثر أمانًا. في مجال الولائم يحدث هذا كثيرًا.#BTC أنت ترى بعينيك ثلاث زجاجات تدخل إلى الخزنة، مقابل بطاقة حفظ نُسخ مشروبات. في المرة القادمة التي تأتي فيها للاستلام يقول موظف الكاونتر: البطاقة صحيحة، لكن الشخص الذي فتح الزجاجة تغيّر، والقواعد تغيّرت، وبطاقتك لا يمكن استبدالها إلا بالمنتجات المحددة—عندما أودعتَ لم يخبرك أحد، وعندما تغيّرت القواعد لم يطلبوا منك التوقيع. لذلك أنا مهتم بـ @babylonlabs_io ليس فقط فيما إذا كان بإمكانه قفل BTC، بل أيضًا بما يحدث بعد قفله: من يمسك بالقلم الذي يغيّر القواعد. في هيكل الإيداع المزدوج لدى Babylon يوجد “فجوة حوكمة” مخفية: مُودِعو BTC هم الذين يدفعون لشراء الأمان، لكن حقوق التصويت على الحوكمة بيد حاملي BABY. ترقية البروتوكول، شروط الـ slash، ومعاملات الرسوم—كلها تُقررها صناديق/حَمَلة BABY المرهونة. أما جانب BTC فيقوم فقط بالإيداع، ولا يشارك في التعديل. الأمر ليس بهذه الضجة حول “عائدات إيداع البيتكوين”، لكنه مهم جدًا. لأن إيداع عبر السلاسل هو الأكثر خوفًا ليس من تقلبات العائد وحدها. والأكثر خوفًا أن تكون بطاقة الإيداع واحدة عندما تُسلّم مشروبك، ثم تواجه مجموعة قواعد مختلفة عند الاستلام. قائمة المزودين تتغير، عتبة الـ slash تتعدل، وفترة فك القفل تتبدل—وفي النهاية قد يتم خصم ذلك كله من رأس المال. BTC لم يغادر سلسلة البيتكوين فعليًا، لكن بمجرد تفويضه، تصبح مجموعة أخرى هي من “تتحكم بكيفية فتح تلك الزجاجة”. ما الذي يجب أن تفعله العقود/البروتوكولات بشكل احترافي؟ ليس أن تضع APY على الطاولة إلى الأبد. بل أن تجعل من يودع مشروبه يرى قائمة الأطباق/الزجاجات الجديدة أولًا عندما تريد تغيير القواعد. بالنسبة للمودِعين العاديين: ليس ضروريًا أن يراجعوا اقتراحات الحوكمة يوميًا. لكن على الأقل يجب أن يعرفوا: لمن يُدار BTC الذي أودعوه؟ ومن يستطيع تغيير رسوم فتح الزجاجة؟ وما الحد الأقصى لدرجة التغيّر المسموح بها في القواعد؟ إذا كانت “زجاجة الكاونتر” ما تزال موجودة لكن القواعد تبدلت بالفعل، فلا تشرب بقوة من أجل تلك الفائدة القليلة. لذلك اليوم عندما أنظر إلى #babylon، لست أكثر اهتمامًا بكلمة “TVL” وحدها. أنا أكثر اهتمامًا بـ “ثبات/مرساة القواعد”. إذا استطاع Babylon أن يقلل قلق مُودِعي BTC بشأن العائد، وفي الوقت نفسه يجعل كل تفويض يلتزم بحدود الحوكمة، وشفافية الـ slash، وآليات الخروج—فإنه لا يبيع “كسبًا من الفائدة” فقط، بل يقدم تجربة إيداع/استضافة على السلسلة يمكن توقعها. لكن الذي يجعل الناس راغبين في جولة إيداع جديدة فعلًا هو أنه عند الاستلام لن يتم تغيير قائمة الزجاجات في اللحظة الأخيرة. #baby $BABY

قواعد BABY للأطفال الرضع: لا ينبغي أن تقارن فقط من يملك أكثر BTC “مقفلًا” في صندوقه

قبل أيام تحدثت مع BABY، وكان حديثي عن: “كيف نُوقظ البيتكوين الموجود في المحفظة الباردة”.

اليوم زاوية أشد: كلما قفلت BTC أكثر في بروتوكول، فهذا لا يعني أن المودِعين أكثر أمانًا.

في مجال الولائم يحدث هذا كثيرًا.#BTC

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

لذلك أنا مهتم بـ @babylonlabs_io ليس فقط فيما إذا كان بإمكانه قفل BTC، بل أيضًا بما يحدث بعد قفله: من يمسك بالقلم الذي يغيّر القواعد.

في هيكل الإيداع المزدوج لدى Babylon يوجد “فجوة حوكمة” مخفية: مُودِعو BTC هم الذين يدفعون لشراء الأمان، لكن حقوق التصويت على الحوكمة بيد حاملي BABY. ترقية البروتوكول، شروط الـ slash، ومعاملات الرسوم—كلها تُقررها صناديق/حَمَلة BABY المرهونة. أما جانب BTC فيقوم فقط بالإيداع، ولا يشارك في التعديل.

الأمر ليس بهذه الضجة حول “عائدات إيداع البيتكوين”، لكنه مهم جدًا.

لأن إيداع عبر السلاسل هو الأكثر خوفًا ليس من تقلبات العائد وحدها.

والأكثر خوفًا أن تكون بطاقة الإيداع واحدة عندما تُسلّم مشروبك، ثم تواجه مجموعة قواعد مختلفة عند الاستلام.

قائمة المزودين تتغير، عتبة الـ slash تتعدل، وفترة فك القفل تتبدل—وفي النهاية قد يتم خصم ذلك كله من رأس المال. BTC لم يغادر سلسلة البيتكوين فعليًا، لكن بمجرد تفويضه، تصبح مجموعة أخرى هي من “تتحكم بكيفية فتح تلك الزجاجة”.

ما الذي يجب أن تفعله العقود/البروتوكولات بشكل احترافي؟

ليس أن تضع APY على الطاولة إلى الأبد.

بل أن تجعل من يودع مشروبه يرى قائمة الأطباق/الزجاجات الجديدة أولًا عندما تريد تغيير القواعد.

بالنسبة للمودِعين العاديين: ليس ضروريًا أن يراجعوا اقتراحات الحوكمة يوميًا. لكن على الأقل يجب أن يعرفوا: لمن يُدار BTC الذي أودعوه؟ ومن يستطيع تغيير رسوم فتح الزجاجة؟ وما الحد الأقصى لدرجة التغيّر المسموح بها في القواعد؟ إذا كانت “زجاجة الكاونتر” ما تزال موجودة لكن القواعد تبدلت بالفعل، فلا تشرب بقوة من أجل تلك الفائدة القليلة.

لذلك اليوم عندما أنظر إلى #babylon، لست أكثر اهتمامًا بكلمة “TVL” وحدها.

أنا أكثر اهتمامًا بـ “ثبات/مرساة القواعد”.

إذا استطاع Babylon أن يقلل قلق مُودِعي BTC بشأن العائد، وفي الوقت نفسه يجعل كل تفويض يلتزم بحدود الحوكمة، وشفافية الـ slash، وآليات الخروج—فإنه لا يبيع “كسبًا من الفائدة” فقط، بل يقدم تجربة إيداع/استضافة على السلسلة يمكن توقعها.

لكن الذي يجعل الناس راغبين في جولة إيداع جديدة فعلًا هو أنه عند الاستلام لن يتم تغيير قائمة الزجاجات في اللحظة الأخيرة.
#baby $BABY

الساعة الثانية والنصف فجراً، كنت أحدّق في ورقة نية تسوية RWA في نظام GRVT، وفجأة ضحكت. أهذه هي البورصة الهجينة من الجيل القادم التي يُفترض أنها ستوصل التمويل التقليدي بالعالم على السلسلة؟ كنت في البداية متحمساً لدراسة GRVT. مكدس zkSync، حلقة إغلاق من أربع طبقات، خزان استراتيجيات—كلها تبدو مُبهرة. لكن بعد أن جرّبت وفككتها من الداخل أدركت—هذا ليس “شفافية على السلسلة”، بل تغليفاً لعلب سوداء خارج السلسلة بإثباتات zk بطريقة جميلة جداً. أريد رؤية سجلات تنفيذ المطابقة الحقيقية، فلماذا لا أرى إلا الجذر (Merkle root) بعد التجميع؟ طلبي يُطابق على السلسلة فعلاً، أم أن صناع السوق يطّلعون عليه مسبقاً؟ أما نظام النقاط فصعب الفهم أكثر. في البداية كان الاندفاع عالياً ثم لاحقاً زاد التخفيف بقسوة—أهذا تعدين أم دفع “ضريبة الوقت”؟ طبقة الإقفال بنظام العضوية مع عمولات على مراحل وجلب الناس—أخي في الواقع نظر وقال: أليس هذا مجرد “ضريبة رأس مستوية” على شكل دعاية/تجنيد مقنّع على طريقة أشبه بالاحتيال؟ عندما أُطلق الـMainnet ظننت أنه ثمة بوابة لمنتجات مشتقة شفافة، ثم اتضح أن صغار المستثمرين هم من يضعون الذهب الحقيقي لإكمال دور صندوق GLP وصناع السوق كحجر عتبة. تقول التسوية الخاصة بـRWA إنها “أصول مادية مُسجلة على السلسلة”، لكن معامل الخصم يتم التحكم به في صندوق أسود. سألت خدمة العملاء عن نموذج التقييم، فقدموا لي ورقة بيضاء مليئة بعبارة “سيتم الإفصاح عنه قريباً”. والأكثر سخرية أن GRVT تتحدث عن مسار امتثال للمؤسسات، لكن على أرض الواقع يتم ترجيع المستخدمين بسبب آليات معقدة، والمؤسسات لم يُنقص منها شيء من متطلبات KYC. فما هذا بالضبط؟ بنية تحتية لامركزية، أم مسرحية “ثقوا بنا” القديمة؟ مجرد بدلة جديدة بمعمار zk وهجين جديد. هل تحويل عدم الشفافية إلى خصوصية، وتحويل الإقفال إلى مزايا عضوية—يُحسب حصناً منيعاً؟ قال لي لاو تشانغ وهو يسلّم علبة مشروب تقطير فاخر: “حلوة كما في الإعلان، طعمه يغري… لكن إن عضّيت، ستجدها كلها دقيق.” أخذت العلبة ولم أجب。 #grvt @grvt_io $BTC

الساعة الثانية والنصف فجراً، كنت أحدّق في ورقة نية تسوية RWA في نظام GRVT، وفجأة ضحكت.

أهذه هي البورصة الهجينة من الجيل القادم التي يُفترض أنها ستوصل التمويل التقليدي بالعالم على السلسلة؟

كنت في البداية متحمساً لدراسة GRVT. مكدس zkSync، حلقة إغلاق من أربع طبقات، خزان استراتيجيات—كلها تبدو مُبهرة. لكن بعد أن جرّبت وفككتها من الداخل أدركت—هذا ليس “شفافية على السلسلة”، بل تغليفاً لعلب سوداء خارج السلسلة بإثباتات zk بطريقة جميلة جداً. أريد رؤية سجلات تنفيذ المطابقة الحقيقية، فلماذا لا أرى إلا الجذر (Merkle root) بعد التجميع؟ طلبي يُطابق على السلسلة فعلاً، أم أن صناع السوق يطّلعون عليه مسبقاً؟

أما نظام النقاط فصعب الفهم أكثر. في البداية كان الاندفاع عالياً ثم لاحقاً زاد التخفيف بقسوة—أهذا تعدين أم دفع “ضريبة الوقت”؟ طبقة الإقفال بنظام العضوية مع عمولات على مراحل وجلب الناس—أخي في الواقع نظر وقال: أليس هذا مجرد “ضريبة رأس مستوية” على شكل دعاية/تجنيد مقنّع على طريقة أشبه بالاحتيال؟

عندما أُطلق الـMainnet ظننت أنه ثمة بوابة لمنتجات مشتقة شفافة، ثم اتضح أن صغار المستثمرين هم من يضعون الذهب الحقيقي لإكمال دور صندوق GLP وصناع السوق كحجر عتبة. تقول التسوية الخاصة بـRWA إنها “أصول مادية مُسجلة على السلسلة”، لكن معامل الخصم يتم التحكم به في صندوق أسود. سألت خدمة العملاء عن نموذج التقييم، فقدموا لي ورقة بيضاء مليئة بعبارة “سيتم الإفصاح عنه قريباً”.

والأكثر سخرية أن GRVT تتحدث عن مسار امتثال للمؤسسات، لكن على أرض الواقع يتم ترجيع المستخدمين بسبب آليات معقدة، والمؤسسات لم يُنقص منها شيء من متطلبات KYC. فما هذا بالضبط؟ بنية تحتية لامركزية، أم مسرحية “ثقوا بنا” القديمة؟ مجرد بدلة جديدة بمعمار zk وهجين جديد.

هل تحويل عدم الشفافية إلى خصوصية، وتحويل الإقفال إلى مزايا عضوية—يُحسب حصناً منيعاً؟ قال لي لاو تشانغ وهو يسلّم علبة مشروب تقطير فاخر: “حلوة كما في الإعلان، طعمه يغري… لكن إن عضّيت، ستجدها كلها دقيق.” أخذت العلبة ولم أجب。

#grvt @grvt_io $BTC