Binance Square
CryptoDeon
14.8k منشورات

CryptoDeon

Exploring and sharing new insights Daily | Investor and Trader | X (Twitter): @CryptoDeonX
فتح تداول
مُتداول بمُعدّل مرتفع
1.9 سنوات
318 تتابع
3.7K+ المتابعون
17.8K+ إعجاب
منشورات
الحافظة الاستثمارية
·
--
واصلت التفكير في نقاش حوكمة بابل الحالية من الاتجاه الخاطئ. النقاش الواضح هو ما إذا كانت مكافآت BSN ينبغي توزيعها على المساهمين في BABY أو تحويلها عبر مزاد على السلسلة (on-chain) ثم حرقها. وهذا مهم. لكنني أعتقد أن السؤال الأكثر إثارة للاهتمام هو نوع التوقعات التي ينشئها البروتوكول عندما يعتاد الناس على تدفق المكافآت. ليست المكافأة مجرد تحويل اقتصادي. مع مرور الوقت، تصبح جزءًا من سلوك المستخدمين. إذا توقع المشاركون أن كل مصدر جديد للقيمة سيأتي كتوزيع مباشر، ستصبح قرارات الحوكمة المستقبلية أكثر صعوبة، لأن تغيير هذا التوقع يبدأ وكأنه أخذ شيءٍ ما بعيدًا. ومن ناحية أخرى، فإن توجيه القيمة عبر آلية الحرق لا يكافئ المشاركين فورًا. بدلًا من ذلك، فإنه يغيّر ديناميكيات العرض طويلة الأجل للرمز. قد يفيد ذلك الشبكة بشكل مختلف، لكنه أيضًا يطلب من المستخدمين التفكير بما يتجاوز التوزيعة التالية. لا يوجد أي من النهجين صحيحًا بشكل واضح. أحدهما يعطي الأولوية للحوافز الظاهرة. والآخر يعطي الأولوية للحوافز البنيوية. لهذا لا أعتقد أن هذا الاقتراح يتعلق حقًا بمكافآت BSN. بل يتعلق بتحديد ما إذا كانت بابل تريد أن تعمل حوكمةها على تحسين توقعات المشاركين... أم على تحسين السلوك الاقتصادي طويل الأجل. وهما ليسا دائمًا الشيء نفسه. #baby $BABY @babylonlabs_io
واصلت التفكير في نقاش حوكمة بابل الحالية من الاتجاه الخاطئ.

النقاش الواضح هو ما إذا كانت مكافآت BSN ينبغي توزيعها على المساهمين في BABY أو تحويلها عبر مزاد على السلسلة (on-chain) ثم حرقها.

وهذا مهم.

لكنني أعتقد أن السؤال الأكثر إثارة للاهتمام هو نوع التوقعات التي ينشئها البروتوكول عندما يعتاد الناس على تدفق المكافآت.

ليست المكافأة مجرد تحويل اقتصادي.

مع مرور الوقت، تصبح جزءًا من سلوك المستخدمين.

إذا توقع المشاركون أن كل مصدر جديد للقيمة سيأتي كتوزيع مباشر، ستصبح قرارات الحوكمة المستقبلية أكثر صعوبة، لأن تغيير هذا التوقع يبدأ وكأنه أخذ شيءٍ ما بعيدًا.

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

لا يوجد أي من النهجين صحيحًا بشكل واضح.

أحدهما يعطي الأولوية للحوافز الظاهرة.

والآخر يعطي الأولوية للحوافز البنيوية.

لهذا لا أعتقد أن هذا الاقتراح يتعلق حقًا بمكافآت BSN.

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

وهما ليسا دائمًا الشيء نفسه.

#baby $BABY @BabylonLabs_io
اليوم نظرت إلى انقسام حجم “بابل” بشكل مختلف — ليس فقط النسبة، بل ماذا يحدث عندما يلتقي المعروض الجديد بها. في الوقت الحالي، تبلغ $BABY نقلة/عملية تقريبًا حوالي 11.45 مليون دولار في حجم مركزي مقابل 2.95 مليون دولار على منصات DEXs، ما يجعل التنفيذ اللامركزي نحو 21% من إجمالي الحجم. هذه الفجوة ليست جديدة. الجديد هو التوقيت. في 10 أغسطس، ستقوم بابل بإطلاق 136.11 مليون رمز BABY بقيمة تقارب 1.43 مليون دولار، ويمثل ذلك 1.2% من إجمالي المعروض. كنسبة مئوية، فهي صغيرة. لكن عند قياسها مقابل السيولة الفعلية على السلسلة، تصبح الصورة مختلفة — 1.43 مليون دولار قريبة من نصف ما يتم تداوله عبر DEXs في يوم واحد حالياً. سياق سريع لمن هو جديد على الموضوع: حجم CEX يتم تداوله على منصات مثل Binance أو OKX، حيث تحتفظ البورصة بالمفاتيح/الحيازة وتطابق الأوامر داخلياً. أما حجم DEX فهو تداول يتم تسويته على السلسلة عبر عقود ذكية، دون وجود أمين/حافظ. وعندما يكون حجم DEX أرقّ مقارنةً بحجم CEX، فإن اكتشاف السعر ما زال يعتمد غالباً على المنصات المركزية — وليس على “المسارات” غير القائمة على الثقة والتي يقوم عليها الافتراض الخاص بالسهم/التوكن. لذا فإن الاختبار الحقيقي ليس ما إذا كانت بابل تستطيع استيعاب 1.2% من المعروض. بل ما إذا كانت المجمعات اللامركزية قادرة على استيعابه من تلقاء نفسها، أم أنها تحتاج إلى دفاتر أوامر CEX لإبقاء الأسعار متوافقة. إذا كانت مجمعات DEX تعتمد على التحكيم/المراجحة عبر CEX لتظل متوازنة، فسيظل الإطلاق يمر عبر الطبقة المركزية — فقط بشكل غير مباشر. أنا أراقب عمق DEX في الأيام التي تلي 10 أغسطس، وليس شمعة السعر. #baby $BABY @babylonlabs_io
اليوم نظرت إلى انقسام حجم “بابل” بشكل مختلف — ليس فقط النسبة، بل ماذا يحدث عندما يلتقي المعروض الجديد بها.

في الوقت الحالي، تبلغ $BABY نقلة/عملية تقريبًا حوالي 11.45 مليون دولار في حجم مركزي مقابل 2.95 مليون دولار على منصات DEXs، ما يجعل التنفيذ اللامركزي نحو 21% من إجمالي الحجم. هذه الفجوة ليست جديدة. الجديد هو التوقيت.

في 10 أغسطس، ستقوم بابل بإطلاق 136.11 مليون رمز BABY بقيمة تقارب 1.43 مليون دولار، ويمثل ذلك 1.2% من إجمالي المعروض. كنسبة مئوية، فهي صغيرة. لكن عند قياسها مقابل السيولة الفعلية على السلسلة، تصبح الصورة مختلفة — 1.43 مليون دولار قريبة من نصف ما يتم تداوله عبر DEXs في يوم واحد حالياً.

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

لذا فإن الاختبار الحقيقي ليس ما إذا كانت بابل تستطيع استيعاب 1.2% من المعروض. بل ما إذا كانت المجمعات اللامركزية قادرة على استيعابه من تلقاء نفسها، أم أنها تحتاج إلى دفاتر أوامر CEX لإبقاء الأسعار متوافقة. إذا كانت مجمعات DEX تعتمد على التحكيم/المراجحة عبر CEX لتظل متوازنة، فسيظل الإطلاق يمر عبر الطبقة المركزية — فقط بشكل غير مباشر.

أنا أراقب عمق DEX في الأيام التي تلي 10 أغسطس، وليس شمعة السعر.

#baby $BABY @BabylonLabs_io
تمّ التحقق
سحبتُ أرقام الحوكمة الفعلية بدل الكلام العام — إليك مقطعًا جديدًا، نقطة دخول مختلفة عن فكرة «الإيداعات كحاجز»: الجزء من $BABY governance الذي يحتاج حقًا إلى تفكيك ليس الإيداع، بل ما يحدث عندما لا تفعل شيئًا. إيداع المقترح القياسي هو 50,000 BABY، والمسار المُستعجل يحتاج 200,000 BABY للتصويت في نفس اليوم تقريبًا بدل نافذة الثلاثة أيام المعتادة. وبسعر اليوم، حوالي ~$0.01269، فهذا يعني تقريبًا 635 دولارًا للقياسي و2,540 دولارًا للمستعجل — ليس «الجدار الأرستقراطي» الذي يبدو عليه الأمر على الورق، بل أشبه برسوم إيداع معتدلة انكمشت كثيرًا عندما بردت قيمة التوكن من قممها. يصل النصاب (Quorum) إلى 33.4% من المعروض المرهون، بينما عتبة الموافقة هي 50%. لكن هذه هي الآلية التي تحسم معظم النتائج فعليًا: إذا كنت تمتلك BABY ولا تصوّت، فإن تصويت المُتحقق (validator) الخاص بك يُورَّث تلقائيًا نيابةً عنك. صوّت أولًا فيصبح التصويت لك. ابقَ صامتًا وسيصبح صوتك مجرد ما قرره المُتحقق الخاص بك مسبقًا. دليل حوكمة Babylon نفسه يلفت إلى هذا مباشرةً، إذ ينصح المشاركين (stakers) بالتصويت على كل شيء تحديدًا كي لا ينتهون فقط إلى ركوب رأي المُتحقق الخاص بهم افتراضيًا. لذلك، السؤال الحقيقي ليس «هل يستطيع صغار الحائزين (small holders) تحمّل تقديم المقترحات؟». بل كم منهم يدرك أن صمتَه هو بالفعل تصويت، مُرسَل من خلال شخص آخر، في اللحظة التي لا يحضر فيها. اقتراح حرق الانكماش (deflation-burn) الذي نجح العام الماضي مثالٌ جيد للاختبار، يستحق الرجوع للتحقق مما كان عليه معدل حضور الناخبين (staker turnout) فعليًا مقارنةً بالتصويتات المُورَّثة من المُتحققين، بدل الاكتفاء بسؤال الحساب مباشرةً. هل لديك أرقام حضور مُفصّلة حسب «صوت المُشارك مباشرةً» مقابل «موروث من المُتحقق» بالنسبة للمقترحات السابقة، أم أن هذا الانقسام غير معروض أصلًا على منصة المستكشف (explorer) في الوقت الحالي؟ #baby $BABY @babylonlabs_io
سحبتُ أرقام الحوكمة الفعلية بدل الكلام العام — إليك مقطعًا جديدًا، نقطة دخول مختلفة عن فكرة «الإيداعات كحاجز»:

الجزء من $BABY governance الذي يحتاج حقًا إلى تفكيك ليس الإيداع، بل ما يحدث عندما لا تفعل شيئًا.

إيداع المقترح القياسي هو 50,000 BABY، والمسار المُستعجل يحتاج 200,000 BABY للتصويت في نفس اليوم تقريبًا بدل نافذة الثلاثة أيام المعتادة. وبسعر اليوم، حوالي ~$0.01269، فهذا يعني تقريبًا 635 دولارًا للقياسي و2,540 دولارًا للمستعجل — ليس «الجدار الأرستقراطي» الذي يبدو عليه الأمر على الورق، بل أشبه برسوم إيداع معتدلة انكمشت كثيرًا عندما بردت قيمة التوكن من قممها. يصل النصاب (Quorum) إلى 33.4% من المعروض المرهون، بينما عتبة الموافقة هي 50%.

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

لذلك، السؤال الحقيقي ليس «هل يستطيع صغار الحائزين (small holders) تحمّل تقديم المقترحات؟». بل كم منهم يدرك أن صمتَه هو بالفعل تصويت، مُرسَل من خلال شخص آخر، في اللحظة التي لا يحضر فيها.

اقتراح حرق الانكماش (deflation-burn) الذي نجح العام الماضي مثالٌ جيد للاختبار، يستحق الرجوع للتحقق مما كان عليه معدل حضور الناخبين (staker turnout) فعليًا مقارنةً بالتصويتات المُورَّثة من المُتحققين، بدل الاكتفاء بسؤال الحساب مباشرةً.

هل لديك أرقام حضور مُفصّلة حسب «صوت المُشارك مباشرةً» مقابل «موروث من المُتحقق» بالنسبة للمقترحات السابقة، أم أن هذا الانقسام غير معروض أصلًا على منصة المستكشف (explorer) في الوقت الحالي؟

#baby $BABY @BabylonLabs_io
تمّ التحقق
تَتواجد ذاكرة المِجمع (mempool) الخاصّة ببيتكوين الآن بحجم يقارب 179 ميغابايت، مع رسوم تحوم حول 1 ساتوشي لكل vByte—هادئة كما تكون الشبكة تقريبًا. تحقّقت من هذا الرقم متوقّعًا أن يكون غير ذي صلة بـ $BABY. لكنه ليس كذلك. كل نقطة تفتيش يطرحها Babylon لربط الحالة المتعلّقة بسلسلة PoS على بيتكوين تمر عبر معاملة بيتكوين حقيقية: كتابة OP_RETURN يقدّمها Vigilante Submitter، وتدفع ما كانت عليه الأسعار السائدة في ذلك الوقت. مساحة الكتلة في بيتكوين لا تعرف ولا تهتم بأن المعاملة جاءت من Babylon بدلًا من دفعة سحوبات من بورصة أو سكّ Ordinals. إنها مزادٌ واحد مشترك لحوالي 4 ملايين وحدة وزن كل عشر دقائق، ويشارك الجميع في نفس الطابور. هذه هي النقطة السهلة الفَوْت عند قراءة وثائق Babylon بمعزل. في عام 2023، عندما وصلت موجة Ordinals وBRC-20 إلى ذروتها، ارتفعت الرسوم المتوسّطة من نحو 5 sat/vB إلى 100 ثم إلى 300 sat/vB لعدة أشهر—فقط بسبب نشاط غير ذي صلة بطابع NFTs يتنافس على نفس المساحة. فعلت Runes شيئًا مشابهًا في 2024، فدَفعت الرسوم إلى ما يتجاوز 1,000 sat/vB عند القمة. لم يكن لأي من ذلك علاقة بكون سلاسل PoS تحتاج إلى أمان بيتكوين. كان سيؤثر على تكاليف نقاط تفتيش Babylon بنفس القسوة مثل الجميع. لذلك، ليست مصروفات التشغيل لدى Babylon بالنسبة للأمر الذي تبيعه فعلًا—الأمان المرتكز على بيتكوين—محكومة باستخدام Babylon نفسه. بل تُحدَّد بما يتنافس على مساحة بلوك بيتكوين في ذلك الأسبوع: مِنتات الميمكوينات، وتوحيدات البورصات، والتكدّس الناجم عن دورات النصف (halving)، ولا شيء من هذا مما يمكن لـ Babylon التنبؤ به أو التحكم فيه. من المفيد تذكُّر ذلك في المرة القادمة حين تُقدَّم تكاليف نقاط التفتيش على أنها مقياس خاص بـ Babylon. نصف ذلك الرقم لم يكن أصلًا من نصيب Babylon. $BABY #baby @babylonlabs_io
تَتواجد ذاكرة المِجمع (mempool) الخاصّة ببيتكوين الآن بحجم يقارب 179 ميغابايت، مع رسوم تحوم حول 1 ساتوشي لكل vByte—هادئة كما تكون الشبكة تقريبًا. تحقّقت من هذا الرقم متوقّعًا أن يكون غير ذي صلة بـ $BABY . لكنه ليس كذلك.

كل نقطة تفتيش يطرحها Babylon لربط الحالة المتعلّقة بسلسلة PoS على بيتكوين تمر عبر معاملة بيتكوين حقيقية: كتابة OP_RETURN يقدّمها Vigilante Submitter، وتدفع ما كانت عليه الأسعار السائدة في ذلك الوقت. مساحة الكتلة في بيتكوين لا تعرف ولا تهتم بأن المعاملة جاءت من Babylon بدلًا من دفعة سحوبات من بورصة أو سكّ Ordinals. إنها مزادٌ واحد مشترك لحوالي 4 ملايين وحدة وزن كل عشر دقائق، ويشارك الجميع في نفس الطابور.

هذه هي النقطة السهلة الفَوْت عند قراءة وثائق Babylon بمعزل. في عام 2023، عندما وصلت موجة Ordinals وBRC-20 إلى ذروتها، ارتفعت الرسوم المتوسّطة من نحو 5 sat/vB إلى 100 ثم إلى 300 sat/vB لعدة أشهر—فقط بسبب نشاط غير ذي صلة بطابع NFTs يتنافس على نفس المساحة. فعلت Runes شيئًا مشابهًا في 2024، فدَفعت الرسوم إلى ما يتجاوز 1,000 sat/vB عند القمة. لم يكن لأي من ذلك علاقة بكون سلاسل PoS تحتاج إلى أمان بيتكوين. كان سيؤثر على تكاليف نقاط تفتيش Babylon بنفس القسوة مثل الجميع.

لذلك، ليست مصروفات التشغيل لدى Babylon بالنسبة للأمر الذي تبيعه فعلًا—الأمان المرتكز على بيتكوين—محكومة باستخدام Babylon نفسه. بل تُحدَّد بما يتنافس على مساحة بلوك بيتكوين في ذلك الأسبوع: مِنتات الميمكوينات، وتوحيدات البورصات، والتكدّس الناجم عن دورات النصف (halving)، ولا شيء من هذا مما يمكن لـ Babylon التنبؤ به أو التحكم فيه.

من المفيد تذكُّر ذلك في المرة القادمة حين تُقدَّم تكاليف نقاط التفتيش على أنها مقياس خاص بـ Babylon. نصف ذلك الرقم لم يكن أصلًا من نصيب Babylon.

$BABY #baby @BabylonLabs_io
صحيح جزئيًا
افترضت أن كل معاملة على سلسلة مؤمّنة ببابل ترث تلقائياً حتمية بيتكوين النهائية في اللحظة التي تتأكد فيها. لكن عند قراءة التصميم الفعلي، لا يحدث ذلك بالطريقة المتوقعة، والفجوة بين الحتمية السريعة والبطيئة هي الجزء الذي يتخطاه معظم الشُرّاح. تعمل بابل بسرعتين جنباً إلى جنب. المعاملات العادية تحصل على حتمية سريعة، وتُستكمل فوراً عبر إجماع إثبات الحصّة (PoS) الخاص بالسلسلة، وهو نموذج توافق اجتماعي نفسه الذي تستخدمه بالفعل كل سلاسل كوزموس. أمّا أمان على مستوى بيتكوين فلا يتفعّل إلا مع الحتمية البطيئة، حيث ينتظر العميل حتى يتم دفن نقطة تفتيش المعاملة بعددٍ كافٍ من الكتل العميقة على بيتكوين—غالباً بضع ساعات، وأحياناً أقرب إلى دورة كاملة من فترة (epoch)—قبل اعتبارها غير قابلة للعكس حقاً. إليك النسخة المباشرة. الانتظار لساعات للحصول على تأكيد بيتكوين يُهزم الغرض من السلسلة السريعة، لذلك لا يفعله عملياً إلا قلة قليلة جداً للأنشطة اليومية. وهذا يعني أن حجم المعاملات الذي يُسوَّق على أنه «مؤمَّن ببيتكوين» يعمل في معظمه على نفس الإجماع السريع الموثوق اجتماعياً الذي بُنيت بابل كي تبتعد عنه. يوجد ختم/طابع بيتكوين الزمني هناك، كخيار، لكنه خيار اختياري (opt-in)، ولا بد أن تكون له قيمة كافية ليختار شخص ما الانتظار من أجله. لذا فترقية الأمان الحقيقية ليست شاملة، بل انتقائية حسب التصميم. التحويلات عالية القيمة، نزاعات نقاط التفتيش، أي شيء يستحق الانتظار—تحصل على ضمان بيتكوين الفعلي. أما النشاط الروتيني فلا يحصل عليه، لأن أحداً لا يرغب عملياً في المقايضة بين السرعة والأمان. من المفيد معرفة أي فئة تهبط فيها معاملاتك أنت فعلياً، قبل افتراض أن التسمية تغطي كل شيء. $BABY #baby @babylonlabs_io
افترضت أن كل معاملة على سلسلة مؤمّنة ببابل ترث تلقائياً حتمية بيتكوين النهائية في اللحظة التي تتأكد فيها. لكن عند قراءة التصميم الفعلي، لا يحدث ذلك بالطريقة المتوقعة، والفجوة بين الحتمية السريعة والبطيئة هي الجزء الذي يتخطاه معظم الشُرّاح.

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

إليك النسخة المباشرة. الانتظار لساعات للحصول على تأكيد بيتكوين يُهزم الغرض من السلسلة السريعة، لذلك لا يفعله عملياً إلا قلة قليلة جداً للأنشطة اليومية. وهذا يعني أن حجم المعاملات الذي يُسوَّق على أنه «مؤمَّن ببيتكوين» يعمل في معظمه على نفس الإجماع السريع الموثوق اجتماعياً الذي بُنيت بابل كي تبتعد عنه. يوجد ختم/طابع بيتكوين الزمني هناك، كخيار، لكنه خيار اختياري (opt-in)، ولا بد أن تكون له قيمة كافية ليختار شخص ما الانتظار من أجله.

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

من المفيد معرفة أي فئة تهبط فيها معاملاتك أنت فعلياً، قبل افتراض أن التسمية تغطي كل شيء.

$BABY #baby @BabylonLabs_io
تُسوّق بابل نفسها في جملة واحدة: لا التفاف، لا جسور، حيازة ذاتية كاملة. كنت أصدق ذلك تمامًا حتى تحققت من أين يتدفّق معظم حجم الـ BTC المَرهَن الفعلي. جزء كبير منه لا يُرهَن محليًا على الإطلاق. بل يمر عبر LBTC من لومبارد، وهو مُعرّف سيولة (رمز حَصّة سيولة) مرهون بشكل سائل. وهو رمز ERC-20 يُتداول عبر إيثريوم وسولانا وسلاسل أخرى، ومدعوم بنسبة 1:1 بعملة BTC التي يَرهِنها لومبارد في بابل نيابةً عن المستخدم. وبعبارات بسيطة: أنت تُودِع بيتكوين، ويقوم لومبارد بترهينها، وتحصل على رمز سند/IOU قابل للتداول بدلًا من الاحتفاظ بـ BTC المَرهَن مباشرة. وهذا الـ IOU هو بالضبط نوع الغلاف الذي بُنيت دعوة بابل بأكملها لتجنّبه. إليك لماذا يختاره الناس على أي حال، وليست هناك منطقٌ غير معقول. يشمل إلغاء الرهن المحلي عبر بابل فترة فك ارتباط تقارب 7 أيام. واسترداد LBTC إلى BTC المحلي يستغرق حتى 10 أيام بعد إضافة دورة إعادة موازنة لومبارد الخاصة فوق ذلك. لذلك يوجد LBTC تحديدًا لتوفير السيولة وإتاحة وصول إلى التمويل اللامركزي (DeFi)، مع إمكانية تداوله عبر أكثر من 70 منصة، بينما تبقى BTC الأساسية محبوسة عبر نفس فترة انتظار فك الارتباط. أما حيازة دعم البيتكوين الفعلي فتقع لدى ما يسميه لومبارد «Security Consortium»، حيث تقوم عقد مؤسسية مثل Galaxy وWintermute وOKX بصك الرمز واسترداده معًا. وهكذا توجد الآن نموذجَين مختلفين للثقة متكدسين فوق بعضهما البعض، يرتديان نفس ملصق «ترهين البيتكوين». الرهن المحلي عبر بابل مباشرةً هو النسخة التي لا تتطلب الثقة (trustless)، والحيازة الذاتية (self-custodial) التي صُمّم البروتوكول ليكون عليها. أما الحصول على تعرّض عبر LBTC فيعني الثقة في اتحاد مؤسسات مُسمّاة لإدارة الحيازة والاسترداد بشكل صحيح، وهو ما يشكّل مخاطر مختلفة بشكل ملموس عن المخاطر التي تدّعي بنية بابل أنها تُزيلها. ما أراقبه فعليًا هو ما إذا كان التعرّض المُلتف مثل LBTC يستمر في التقدّم على الرهن المحلي المباشر، لأن ذلك سيعني أن قاعدة الأمان الفعلية تتجمّع بهدوء حول مجموعة صغيرة من أعضاء الاتحاد، حتى بينما يظل البروتوكول الأساسي نفسه مطابقًا لما يَعد به من كونه بلا ثقة (trustless) حرفيًا. $BABY #baby @babylonlabs_io
تُسوّق بابل نفسها في جملة واحدة: لا التفاف، لا جسور، حيازة ذاتية كاملة. كنت أصدق ذلك تمامًا حتى تحققت من أين يتدفّق معظم حجم الـ BTC المَرهَن الفعلي.

جزء كبير منه لا يُرهَن محليًا على الإطلاق. بل يمر عبر LBTC من لومبارد، وهو مُعرّف سيولة (رمز حَصّة سيولة) مرهون بشكل سائل. وهو رمز ERC-20 يُتداول عبر إيثريوم وسولانا وسلاسل أخرى، ومدعوم بنسبة 1:1 بعملة BTC التي يَرهِنها لومبارد في بابل نيابةً عن المستخدم. وبعبارات بسيطة: أنت تُودِع بيتكوين، ويقوم لومبارد بترهينها، وتحصل على رمز سند/IOU قابل للتداول بدلًا من الاحتفاظ بـ BTC المَرهَن مباشرة. وهذا الـ IOU هو بالضبط نوع الغلاف الذي بُنيت دعوة بابل بأكملها لتجنّبه.

إليك لماذا يختاره الناس على أي حال، وليست هناك منطقٌ غير معقول. يشمل إلغاء الرهن المحلي عبر بابل فترة فك ارتباط تقارب 7 أيام. واسترداد LBTC إلى BTC المحلي يستغرق حتى 10 أيام بعد إضافة دورة إعادة موازنة لومبارد الخاصة فوق ذلك. لذلك يوجد LBTC تحديدًا لتوفير السيولة وإتاحة وصول إلى التمويل اللامركزي (DeFi)، مع إمكانية تداوله عبر أكثر من 70 منصة، بينما تبقى BTC الأساسية محبوسة عبر نفس فترة انتظار فك الارتباط. أما حيازة دعم البيتكوين الفعلي فتقع لدى ما يسميه لومبارد «Security Consortium»، حيث تقوم عقد مؤسسية مثل Galaxy وWintermute وOKX بصك الرمز واسترداده معًا.

وهكذا توجد الآن نموذجَين مختلفين للثقة متكدسين فوق بعضهما البعض، يرتديان نفس ملصق «ترهين البيتكوين». الرهن المحلي عبر بابل مباشرةً هو النسخة التي لا تتطلب الثقة (trustless)، والحيازة الذاتية (self-custodial) التي صُمّم البروتوكول ليكون عليها. أما الحصول على تعرّض عبر LBTC فيعني الثقة في اتحاد مؤسسات مُسمّاة لإدارة الحيازة والاسترداد بشكل صحيح، وهو ما يشكّل مخاطر مختلفة بشكل ملموس عن المخاطر التي تدّعي بنية بابل أنها تُزيلها.

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

$BABY #baby @BabylonLabs_io
تمّ التحقق
رقم العائد الذي يظهر في لوحات الحصص لـ BABY يتراوح تقريبًا بين 15 و20 بالمئة سنويًا. كدت أعتبر ذلك دليلًا على أن شبكات Bitcoin Secured Networks كانت تدفع أموالًا حقيقية مقابل أمن البيتكوين. ثم تتبعت مصدر ذلك العائد فعليًا، واتضح أنه ليس كذلك. يمتلك BABY معدل تضخم سنوي يبلغ 8 بالمئة، مقسّم بالتساوي: 4 بالمئة تُصك لمُحصّلي حصص BTC، و4 بالمئة لمُحصّلي حصص BABY. هذه هي طبقة التمويل الأساسية التي تموّل تقريبًا معظم العائد المُعلن حاليًا. وبشكل منفصل، توجد مزايدة على المكافآت يمكن لفرق BSNs التي تتكامل بالفعل توجيه جزء من مكافآتها إلى الشبكة، حيث يتم تقديم عروض على BABY ثم حرقه. لكن تدفق هذه المزايدة لا يزال صغيرًا مقارنةً بخط الأساس الناتج عن التضخم، لأن معظم النظام البيئي ما زال عبارة عن Babylon Genesis نفسه: شبكة BSN واحدة، وليس بعد سوقًا تدفع فيه شبكاتٌ مستقلة مقابل الأمن. إليك النسخة المبسطة لماذا يهم هذا الفرق. العائد الممول عبر التضخم ليس دليلًا على أن أحدًا يقدّر الأمن الذي يتم بيعه. إنه مجرد توكنات جديدة تُصك وتُمنح لمن قام بقفل BTC أو BABY أولًا. أما الطلب الحقيقي فيظهر فقط في آلية المزايدة والحرق المنفصلة، عندما تضع سلاسل خارجية قيمةً على الطاولة مقابل أمن مدعوم بالبيتكوين، بدل أن تقوم Babylon بالدفع لمحصّليها هي لإثبات الحضور. حاليًا، تمتلك Babylon ما يقارب 57,000 BTC مُرهونة، وكانت قيمتها وقت الذروة في إجمالي القيمة المقفلة (TVL) تتجاوز 5.6 مليار دولار، ما يبدو كتأكيد ساحق. لكن TVL يقيس مقدار الـ BTC التي تم قفلها، وليس مقدار ما تكون أي سلسلة PoS راغبة في دفعه لاستئجار ذلك الأمن. هذه أسئلة مختلفة بإجابات مختلفة. ما يهمني فعليًا هو ما إذا كانت جهة المزايدة والحرق ستبدأ فعلًا بتحمل وزن حقيقي مقابل إعانة الـ 8 بالمئة مع دخول المزيد من الشبكات إلى الخدمة، أم أن العائد سيظل مجرد شيء تموّله Babylon لنفسها. #baby $BABY @babylonlabs_io
رقم العائد الذي يظهر في لوحات الحصص لـ BABY يتراوح تقريبًا بين 15 و20 بالمئة سنويًا. كدت أعتبر ذلك دليلًا على أن شبكات Bitcoin Secured Networks كانت تدفع أموالًا حقيقية مقابل أمن البيتكوين. ثم تتبعت مصدر ذلك العائد فعليًا، واتضح أنه ليس كذلك.

يمتلك BABY معدل تضخم سنوي يبلغ 8 بالمئة، مقسّم بالتساوي: 4 بالمئة تُصك لمُحصّلي حصص BTC، و4 بالمئة لمُحصّلي حصص BABY. هذه هي طبقة التمويل الأساسية التي تموّل تقريبًا معظم العائد المُعلن حاليًا. وبشكل منفصل، توجد مزايدة على المكافآت يمكن لفرق BSNs التي تتكامل بالفعل توجيه جزء من مكافآتها إلى الشبكة، حيث يتم تقديم عروض على BABY ثم حرقه. لكن تدفق هذه المزايدة لا يزال صغيرًا مقارنةً بخط الأساس الناتج عن التضخم، لأن معظم النظام البيئي ما زال عبارة عن Babylon Genesis نفسه: شبكة BSN واحدة، وليس بعد سوقًا تدفع فيه شبكاتٌ مستقلة مقابل الأمن.

إليك النسخة المبسطة لماذا يهم هذا الفرق. العائد الممول عبر التضخم ليس دليلًا على أن أحدًا يقدّر الأمن الذي يتم بيعه. إنه مجرد توكنات جديدة تُصك وتُمنح لمن قام بقفل BTC أو BABY أولًا. أما الطلب الحقيقي فيظهر فقط في آلية المزايدة والحرق المنفصلة، عندما تضع سلاسل خارجية قيمةً على الطاولة مقابل أمن مدعوم بالبيتكوين، بدل أن تقوم Babylon بالدفع لمحصّليها هي لإثبات الحضور.

حاليًا، تمتلك Babylon ما يقارب 57,000 BTC مُرهونة، وكانت قيمتها وقت الذروة في إجمالي القيمة المقفلة (TVL) تتجاوز 5.6 مليار دولار، ما يبدو كتأكيد ساحق. لكن TVL يقيس مقدار الـ BTC التي تم قفلها، وليس مقدار ما تكون أي سلسلة PoS راغبة في دفعه لاستئجار ذلك الأمن. هذه أسئلة مختلفة بإجابات مختلفة.

ما يهمني فعليًا هو ما إذا كانت جهة المزايدة والحرق ستبدأ فعلًا بتحمل وزن حقيقي مقابل إعانة الـ 8 بالمئة مع دخول المزيد من الشبكات إلى الخدمة، أم أن العائد سيظل مجرد شيء تموّله Babylon لنفسها.

#baby $BABY @BabylonLabs_io
تمّ التحقق
عقوبة الإقدام بالقطع (slashing) عند التوقيع المزدوج على بابل تبلغ 0.1% من عملات BTC المرهونة. عندما قرأت هذا الرقم لأول مرة، شعرت بالاطمئنان: رقم صغير ومحتوٍ وقابل للبقاء. ثم قرأت كيف تعمل عملية الرهن/التكديس المتعدد (multi-staking) فعليًا، فتوقف الرقم عن رواية القصة كاملة. المرحلة 3 من بابل تتيح إيداع BTC واحد لتأمين عدة شبكات “Bitcoin Secured Networks” في الوقت نفسه، وليس بابل جينيسس فقط. يحتفظ مزوّد نهائية (finality provider) واحد بمجموعة مفاتيح توقيع مُسجّلة مسبقًا، ويمكنه توقيع نقاط التحقق (checkpoints) عبر عدة BSNs باستخدام نفس الرصيد/الاستثمار الأساسي المُرهَن. هذه هي الفكرة كاملة: قفل واحد، وشبكات كثيرة، ومصادر عائد أكثر من إيداع واحد بدلًا من تقسيم BTC إلى مراكز منفصلة. إليك ما لا يلتقطه رقم الـ0.1% هذا. إنه لكل حدث قطع (slashing)، وليس لكل رصيد مرهون. فإذا أساء مزوّد نهائية التصرف وتمت ملاحظته/إمساكه على شبكة واحدة، فهذا يعني اقتطاع 0.1% واحدة. لكن إذا كان المزود نفسه—باستخدام نفس الرصيد المشترك المرهَن—يؤمّن أيضًا ثلاث أو أربع BSNs أخرى في الوقت نفسه، تصبح الأمانة والجاهزية (uptime) لهذا المشغل الواحد الآن عاملًا حاسمًا يتحمّل عليه كل شيء في آن واحد. والسؤال البنيوي نفسه تمامًا الذي كان على نموذج إعادة الرهن (restaking) لدى EigenLayer أن يتعامل معه على الإيثيريوم: فإعادة استخدام الضمانات تعني أن خطأ خدمة واحدة يمكن أن يمتد أبعد من الخدمة التي حدث فيها الخلل. لذلك، المخاطر ليست في نسبة القطع نفسها على وجه التحديد. إنها المخاطرة الترابطية (correlation). لا يراهن صاحب BTC المرهون على أمان مزوّد نهائية واحد فقط بعد الآن؛ بل يراهن على استمرار ذلك المزود في التحلّي بالأمانة والبقاء متصلًا بالإنترنت عبر كل شبكة تلامسها مفاتيحه، وبكل ذلك في وقت واحد، ضمن حقل من قرابة 250 مزوّد نهائية يتنافسون على هذا القدر من الثقة. الشرط الذي أراقبه: ما إذا كانت الـBSNs التي يتم إلحاقها (onboarding) عبر multi-staking ستبدأ بالكشف عن تداخل/تشابه مزوّدي النهائية بشكل مشترك، بالطريقة التي تكشف بها بروتوكولات الإقراض عن مخاطر الضمانات المشتركة، أم أن هذه الترابطية ستبقى غير مرئية حتى يتضح ذلك بالطريقة الصعبة حين يتسبب مشغل واحد سيئ في وقوع المشكلة. $BABY #baby @babylonlabs_io
عقوبة الإقدام بالقطع (slashing) عند التوقيع المزدوج على بابل تبلغ 0.1% من عملات BTC المرهونة. عندما قرأت هذا الرقم لأول مرة، شعرت بالاطمئنان: رقم صغير ومحتوٍ وقابل للبقاء. ثم قرأت كيف تعمل عملية الرهن/التكديس المتعدد (multi-staking) فعليًا، فتوقف الرقم عن رواية القصة كاملة.

المرحلة 3 من بابل تتيح إيداع BTC واحد لتأمين عدة شبكات “Bitcoin Secured Networks” في الوقت نفسه، وليس بابل جينيسس فقط. يحتفظ مزوّد نهائية (finality provider) واحد بمجموعة مفاتيح توقيع مُسجّلة مسبقًا، ويمكنه توقيع نقاط التحقق (checkpoints) عبر عدة BSNs باستخدام نفس الرصيد/الاستثمار الأساسي المُرهَن. هذه هي الفكرة كاملة: قفل واحد، وشبكات كثيرة، ومصادر عائد أكثر من إيداع واحد بدلًا من تقسيم BTC إلى مراكز منفصلة.

إليك ما لا يلتقطه رقم الـ0.1% هذا. إنه لكل حدث قطع (slashing)، وليس لكل رصيد مرهون. فإذا أساء مزوّد نهائية التصرف وتمت ملاحظته/إمساكه على شبكة واحدة، فهذا يعني اقتطاع 0.1% واحدة. لكن إذا كان المزود نفسه—باستخدام نفس الرصيد المشترك المرهَن—يؤمّن أيضًا ثلاث أو أربع BSNs أخرى في الوقت نفسه، تصبح الأمانة والجاهزية (uptime) لهذا المشغل الواحد الآن عاملًا حاسمًا يتحمّل عليه كل شيء في آن واحد. والسؤال البنيوي نفسه تمامًا الذي كان على نموذج إعادة الرهن (restaking) لدى EigenLayer أن يتعامل معه على الإيثيريوم: فإعادة استخدام الضمانات تعني أن خطأ خدمة واحدة يمكن أن يمتد أبعد من الخدمة التي حدث فيها الخلل.

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

الشرط الذي أراقبه: ما إذا كانت الـBSNs التي يتم إلحاقها (onboarding) عبر multi-staking ستبدأ بالكشف عن تداخل/تشابه مزوّدي النهائية بشكل مشترك، بالطريقة التي تكشف بها بروتوكولات الإقراض عن مخاطر الضمانات المشتركة، أم أن هذه الترابطية ستبقى غير مرئية حتى يتضح ذلك بالطريقة الصعبة حين يتسبب مشغل واحد سيئ في وقوع المشكلة.

$BABY #baby @BabylonLabs_io
يوجد في وثائق بابيلون جملةٌ تُفكّك بهدوء الكلمة التي يستخدمها الجميع لوصف «القطع/الخصم» الخاصة بها: "trustless". كنتُ أظنّ أن EOTS يقوم بكل العمل لوحده: فالحسابات تلتقط توقيعَين مزدوجَين، ثم يحدث العقاب، دون الحاجة إلى لجنة. لكن قراءة شروط الإنفاق الفعلية غيّرت ذلك. لا يستطيع Bitcoin Script التعبير بشكلٍ أصلي عن: "إذا قام موفّرُ النهائيّة هذا بتوقيع مزدوج، فاقطع رصيده." لذلك تُنشئ بابيلون مسار العقاب بشكلٍ مختلف. عند وقت الإيداع، تُقفل أموالك داخل UTXO يتطلب توقيعات منك ومن نصابٍ من لجنة التعهّد، تُجمع مسبقًا. فإذا قام موفّرُ النهائيّة لاحقًا بالتوقيع المزدوج، فإن حسابات EOTS تُسرّب المفتاح الخاص بهم، ويمدّ هذا المفتاح المُتسرب التوقيعَ النهائي الذي كانت مجموعةُ التوقيعات المتعددة المُعدة مسبقًا تنتظره بالفعل. إذن، الجزء الأنيق—أن الحسابات تلتقط الفاعلين السيئين تلقائيًا—حقيقي، لكنه قطعةٌ أخيرة في بنيةٍ ما، وليس البنية كاملة. يجب أن توجد توقيعات اللجنة قبل حدوث أي سوء تصرّف، وإلا فلن يوجد مسارٌ قابلٌ للعقاب أصلًا. يظهر «اللاموثوقية» في النهاية. كل ما قبل ذلك يعتمد على أن تكون اللجنة موجودة وصادقة ومتّصلة بالإنترنت في وقت الإيداع. وهذا يُعيد صياغة ما يستحق المراقبة فعليًا: ليس ما إذا كانت التشفير يعمل (فهذا الجزء ثابت). بل ما إذا ظلت لجنةُ التعهّد لامركزية ومتاحة مع توسّع بابيلون عبر المزيد من الشبكات المؤمّنة بتقنية Bitcoin، لأن إذا خَفَّت هذه الطبقة فلن يفشل مسارُ القطع بشكلٍ صارخ؛ بل سيتوقف عن الوجود بالنسبة للإيداعات الجديدة قبل أن يراجع أي شخص الأمر. سواء بدأت تركيبة اللجنة والتوافر/الجاهزية في تلقّي التدقيق نفسه الذي يتلقاه TVL وأرقام الإيداع (staking)، أو ظلّت شرطًا غير مرئيّ لا يسأل عنه أحد حتى فوات الأوان. $BABY #baby @babylonlabs_io
يوجد في وثائق بابيلون جملةٌ تُفكّك بهدوء الكلمة التي يستخدمها الجميع لوصف «القطع/الخصم» الخاصة بها: "trustless". كنتُ أظنّ أن EOTS يقوم بكل العمل لوحده: فالحسابات تلتقط توقيعَين مزدوجَين، ثم يحدث العقاب، دون الحاجة إلى لجنة. لكن قراءة شروط الإنفاق الفعلية غيّرت ذلك.

لا يستطيع Bitcoin Script التعبير بشكلٍ أصلي عن: "إذا قام موفّرُ النهائيّة هذا بتوقيع مزدوج، فاقطع رصيده." لذلك تُنشئ بابيلون مسار العقاب بشكلٍ مختلف. عند وقت الإيداع، تُقفل أموالك داخل UTXO يتطلب توقيعات منك ومن نصابٍ من لجنة التعهّد، تُجمع مسبقًا. فإذا قام موفّرُ النهائيّة لاحقًا بالتوقيع المزدوج، فإن حسابات EOTS تُسرّب المفتاح الخاص بهم، ويمدّ هذا المفتاح المُتسرب التوقيعَ النهائي الذي كانت مجموعةُ التوقيعات المتعددة المُعدة مسبقًا تنتظره بالفعل.

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

وهذا يُعيد صياغة ما يستحق المراقبة فعليًا: ليس ما إذا كانت التشفير يعمل (فهذا الجزء ثابت). بل ما إذا ظلت لجنةُ التعهّد لامركزية ومتاحة مع توسّع بابيلون عبر المزيد من الشبكات المؤمّنة بتقنية Bitcoin، لأن إذا خَفَّت هذه الطبقة فلن يفشل مسارُ القطع بشكلٍ صارخ؛ بل سيتوقف عن الوجود بالنسبة للإيداعات الجديدة قبل أن يراجع أي شخص الأمر.

سواء بدأت تركيبة اللجنة والتوافر/الجاهزية في تلقّي التدقيق نفسه الذي يتلقاه TVL وأرقام الإيداع (staking)، أو ظلّت شرطًا غير مرئيّ لا يسأل عنه أحد حتى فوات الأوان.

$BABY #baby @BabylonLabs_io
لم يكن ما حدث في عملية فك القفل بتاريخ 10 يوليو يبدو صحيحًا عندما جلست فعليًا مع الأرقام، لذلك توقفت عن الافتراض وذهبت للتحقق. لا تقدم BABY عمليات فك قفل «قَفْز ثم هبوط» (cliff-and-dump) بالطريقة التي تفعلها كثير من الرموز. الفريق والمستشارون والمستثمرون الأوائل يفكون 1/36 من حصتهم كل شهر تمامًا حتى أبريل 2029، وهي تدفّق خطّي بطيء بدل تاريخٍ مخيف واحد على التقويم. لم يكن 10 يوليو حدثًا خاصًا، بل كان مجرد واحد من تلك الأشهر الستة والثلاثين المتطابقة. من بين حوالي 3.99 مليار توكن كانت تتداول بالفعل، أضاف هذا الإصدار شريحة متوقعة ومعروفة—شيئًا لا يمكن لأي شخص لديه مخطط استحقاق (vesting) ألا يراه قادمًا قبل عام. وهذا الجزء هو الذي يهم فعلًا، وسهل فهمه بشكل عكسي. فك القفل المُجدول والخطي ليس «صدمة في العرض»، بل هو مُسعَّر مسبقًا من قِبل أي شخص ينتبه، لأن السوق يعرف الحسابات الدقيقة منذ نشر الجدول. ما يُحرّك السعر ليس عملية فك القفل نفسها، بل ما إذا كانت الطلبات الجديدة، وزيادة تدفّق BTC إلى الإيداع/الاستيداع (staking) وTBV، ومزيد من عمليات التكامل مثل صفقة Gomining الأخيرة، تنمو أسرع من ذلك التدفّق الشهري الثابت من السيولة الجديدة التي تصل إلى البورصات. لذا لم تكن الحقيقة هي السؤال «كم مقدار فك القفل هذا الشهر». السؤال الحقيقي هو ما إذا كان جانب البروتوكول—BTC المُؤمَّن، والفُتُحات/فتح الخزائن (vaults)، والاستخدام الفعلي—يتضاعف بسرعة كافية لامتصاص مزيدٍ من 36 شهرًا أخرى من نفس التدفّق دون أن يلاحظ أحد ذلك كضغط على الإطلاق. الشرط الذي أتابعه: هل نمو BTC داخل الخزائن يبقى متقدمًا على وتيرة فك القفل الشهرية خلال هذه المراحل القليلة القادمة، أم أن التدفق يبدأ في تجاوز الطلب بهدوء، كما تفعل التسريبات البطيئة عادةً. $BABY #baby #BinanceSquareFamily @babylonlabs_io
لم يكن ما حدث في عملية فك القفل بتاريخ 10 يوليو يبدو صحيحًا عندما جلست فعليًا مع الأرقام، لذلك توقفت عن الافتراض وذهبت للتحقق.

لا تقدم BABY عمليات فك قفل «قَفْز ثم هبوط» (cliff-and-dump) بالطريقة التي تفعلها كثير من الرموز. الفريق والمستشارون والمستثمرون الأوائل يفكون 1/36 من حصتهم كل شهر تمامًا حتى أبريل 2029، وهي تدفّق خطّي بطيء بدل تاريخٍ مخيف واحد على التقويم. لم يكن 10 يوليو حدثًا خاصًا، بل كان مجرد واحد من تلك الأشهر الستة والثلاثين المتطابقة. من بين حوالي 3.99 مليار توكن كانت تتداول بالفعل، أضاف هذا الإصدار شريحة متوقعة ومعروفة—شيئًا لا يمكن لأي شخص لديه مخطط استحقاق (vesting) ألا يراه قادمًا قبل عام.

وهذا الجزء هو الذي يهم فعلًا، وسهل فهمه بشكل عكسي. فك القفل المُجدول والخطي ليس «صدمة في العرض»، بل هو مُسعَّر مسبقًا من قِبل أي شخص ينتبه، لأن السوق يعرف الحسابات الدقيقة منذ نشر الجدول. ما يُحرّك السعر ليس عملية فك القفل نفسها، بل ما إذا كانت الطلبات الجديدة، وزيادة تدفّق BTC إلى الإيداع/الاستيداع (staking) وTBV، ومزيد من عمليات التكامل مثل صفقة Gomining الأخيرة، تنمو أسرع من ذلك التدفّق الشهري الثابت من السيولة الجديدة التي تصل إلى البورصات.

لذا لم تكن الحقيقة هي السؤال «كم مقدار فك القفل هذا الشهر». السؤال الحقيقي هو ما إذا كان جانب البروتوكول—BTC المُؤمَّن، والفُتُحات/فتح الخزائن (vaults)، والاستخدام الفعلي—يتضاعف بسرعة كافية لامتصاص مزيدٍ من 36 شهرًا أخرى من نفس التدفّق دون أن يلاحظ أحد ذلك كضغط على الإطلاق.

الشرط الذي أتابعه: هل نمو BTC داخل الخزائن يبقى متقدمًا على وتيرة فك القفل الشهرية خلال هذه المراحل القليلة القادمة، أم أن التدفق يبدأ في تجاوز الطلب بهدوء، كما تفعل التسريبات البطيئة عادةً.

$BABY #baby #BinanceSquareFamily @BabylonLabs_io
صحيح جزئيًا
كنت أعبث بفكرة إلغاء قفل جزء فقط من بيتكوين (BTC) من "خزنة بيتكوين بدون طرف موثوق" (Trustless Bitcoin Vault)، كما لو كنت تسحب جزءًا فقط من حساب ادخار، لكنني اصطدمت بجدار لم أتوقعه. لا تقوم TBV بالسحوبات الجزئية. إما إدخال الخزنة كاملة وإخراجها كاملة. قطعة واحدة، وليس عدة قطع. في البداية شعرت أن هذا مجرد قيد في تجربة المستخدم، وربما تصميم كسول. لكن بعد التفكير فيه أكثر، أظن أن العكس هو الصحيح. إثبات فداء (redeem) جزئي لبيتكوين، دون فورك (fork) وبدون أوامر/أكواد جديدة، يعني إثبات كسر/جزء من حدث باستخدام منطق السكربت الذي لم يكن مُصممًا أصلًا للتعبير عن الكسور بشكل أنيق. فداء الخزنة كاملة يتجاوز هذه المشكلة تمامًا. إيداع واحد، حالة واحدة، إثبات نظيف واحد. البساطة ليست ميزة مفقودة، بل هي ما يحافظ على أن التحقق يبقى أمينًا على سلسلة لا تسمح لك أن تنحني القواعد من أجلك. وهذه نقطة قد يسهل تفويتها إذا كنت جديدًا: كل تصميم للـ DeFi الأصلي لبيتكوين (BTC-native) يجب أن يختار بين المرونة وقابلية الإثبات، وغالبًا لا يمكن الجمع بينهما. اختارت Babylon قابلية الإثبات. هذا التنازل هو سبب جلوسهم بهدوء على أكثر من 56,000 BTC في خزائن الرهان (staking vaults)، كما أنهم سحبوا دعمًا جديدًا هذا العام من a16z. المؤسسات لا تلحق بالمرونة، بل تلحق بما يمكن إثباته. ما أعود للتفكير فيه باستمرار هو ما إذا كان هذا التنازل يتوسع مع الوقت. فداء الخزنة كاملة يكون نظيفًا عندما تكون الخزائن صغيرة وشخصية. يصبح أقل نظافة عندما تبدأ عمليات التكاملات، مثل صفقة Gomining الأخيرة، في توجيه ألف BTC في كل مرة عبر نفس بوابة الخروج التي تعمل بنظام "الكل أو لا شيء". الشرط الذي أراقبه: هل تتكيف التكاملات واسعة النطاق مع فداء الخزنة كاملة كما هو، أم أنها تتفكك بهدوء إلى عدة خزائن أصغر فقط لاستعادة سلوك السحب الجزئي من خلال الباب الجانبي. $BABY #baby @babylonlabs_io
كنت أعبث بفكرة إلغاء قفل جزء فقط من بيتكوين (BTC) من "خزنة بيتكوين بدون طرف موثوق" (Trustless Bitcoin Vault)، كما لو كنت تسحب جزءًا فقط من حساب ادخار، لكنني اصطدمت بجدار لم أتوقعه. لا تقوم TBV بالسحوبات الجزئية. إما إدخال الخزنة كاملة وإخراجها كاملة. قطعة واحدة، وليس عدة قطع.

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

وهذه نقطة قد يسهل تفويتها إذا كنت جديدًا: كل تصميم للـ DeFi الأصلي لبيتكوين (BTC-native) يجب أن يختار بين المرونة وقابلية الإثبات، وغالبًا لا يمكن الجمع بينهما. اختارت Babylon قابلية الإثبات. هذا التنازل هو سبب جلوسهم بهدوء على أكثر من 56,000 BTC في خزائن الرهان (staking vaults)، كما أنهم سحبوا دعمًا جديدًا هذا العام من a16z. المؤسسات لا تلحق بالمرونة، بل تلحق بما يمكن إثباته.

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

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

$BABY #baby @BabylonLabs_io
لاحظتُ الأمر لأول مرة أثناء مشاهدتي لسير عملية طحن (grind) داخل نقابة — عشرات اللاعبين يجمعون الموارد لساعات، ويصنعون الأدوات دون توقف، ولم تتحرك $BABY بالكاد على الإطلاق. ولم يبدأ الرمز (token) في التفاعل إلا عندما قام شخصٌ فعلًا بِنَقل (mint) أو إيداع عنصر على السلسلة (on-chain). عندها اتضح لي: $BABY لا تُسعِّر النشاط. بل تُسعِّر اللحظة التي يتوقف فيها الجهد عن كونه غير مرئي ويصبح دائمًا. الزراعة والصناعة والطحن — كل ذلك يحدث خارج السلسلة (off-chain)، دون تسعير، ودون تسجيله في السوق. لا يظهر الطلب إلا عند التحويل (conversion)، تلك الخطوة الواحدة التي تُطبع فيها دقيقة اللاعب في شيء يتعيّن على السلسلة أن تعترف به. وهذا يعني أن اللعبة قد تبدو نابضة بالحياة تمامًا — خوادم ممتلئة، وصناعة مستمرة، ونقابات مشغولة — بينما يفرغ طلب التوكن بهدوء، لأن اللاعبين تعلّموا تأخير أو تجنب الخطوة النهائية. يستمر ظهور النشاط على السطح مدةً طويلة بعد أن توقف الشيء الذي تسعّره $BABY فعليًا عن الحدوث تحته. جدير بالملاحظة: هل يبقى معدل التحويل ثابتًا مع نمو قاعدة اللاعبين؟ أم أن نمو اللاعبين يتوقف عن التحول إلى نمو في تلك اللحظة الواحدة. #baby #BinanceSquare @babylonlabs_io
لاحظتُ الأمر لأول مرة أثناء مشاهدتي لسير عملية طحن (grind) داخل نقابة — عشرات اللاعبين يجمعون الموارد لساعات، ويصنعون الأدوات دون توقف، ولم تتحرك $BABY بالكاد على الإطلاق. ولم يبدأ الرمز (token) في التفاعل إلا عندما قام شخصٌ فعلًا بِنَقل (mint) أو إيداع عنصر على السلسلة (on-chain).

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

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

جدير بالملاحظة: هل يبقى معدل التحويل ثابتًا مع نمو قاعدة اللاعبين؟ أم أن نمو اللاعبين يتوقف عن التحول إلى نمو في تلك اللحظة الواحدة.

#baby #BinanceSquare @BabylonLabs_io
استمررت في التحديق في شاشة "خطة المضاعف" مرة أخرى هذا الصباح، لكن هذه المرة لم أكن أنظر إلى العوائد. كنت أراقب ما الذي تفعله عملية تأجيل الاستحقاق فعليًا بالرمز نفسه، لا فقط بما يخص حصتي أنا. وهذا هو الجزء الذي لفت انتباهي. أي شخص يختار تأجيل 4 أو 8 أشهر لا يكتفي بتجميد رموزه هو فقط من أجل مضاعف أكبر لاحقًا. بل إنه أيضًا يزيل هذا المعروض من التداول مباشرة عند TGE، عندما يظهر GRVT في السوق الفوري ويتوجه إلى إدراجات CEX من الفئة الأولى. غالبًا ما يعني المعروض الأقل المتداول عند الإطلاق ضغط بيع ابتدائي أضعف واكتشاف سعر أكثر نظافة ضمن نافذة مبكرة. لذلك، ليس المضاعف مجرد مكافأة على الصبر. بل هو أيضًا تعويض عن القيام بمهمة يستفيد منها التبادل نفسه — إبقاء المعروض خارج السوق خلال أكثر مرحلة هشاشة لاكتشاف السعر، مباشرة بعد الإطلاق. هذا يعيد صياغة القرار قليلًا. المطالبة فورًا ليست فقط "يقين الآن" كما كنت أعتقد سابقًا. إنها أيضًا إضافة إلى ضغط البيع نفسه الذي يكون سعر TGE المبكر حساسًا له أكثر ما يكون. إن التأجيل ليس فقط "رقمًا أكبر ربما لاحقًا"؛ بل إنه يدعم بهدوء الظروف التي قد تجعل هذا الرقم الأكبر ممكنًا أصلًا. الالتسجيل مفتوح حتى 27 يوليو 2026، الساعة 00:00 بالتوقيت العالمي UTC، والاختيارات نهائية، ويقع مجمع التأجيل ضمن حصة الموسم الثاني الثابتة البالغة 18% من إجمالي المعروض البالغ 1B. سواء تحقق ذلك فعليًا كما هو مُصمم أم لا يعتمد على مقدار ذلك المعروض المُسجل الذي ينتهي به الأمر إلى اختيار التأجيل بدلًا من المطالبة الفورية، لأن معدل التأجيل الضعيف لن يغير صورة ضغط البيع كثيرًا على الإطلاق. #grvt #BinanceSquare @grvt_io
استمررت في التحديق في شاشة "خطة المضاعف" مرة أخرى هذا الصباح، لكن هذه المرة لم أكن أنظر إلى العوائد. كنت أراقب ما الذي تفعله عملية تأجيل الاستحقاق فعليًا بالرمز نفسه، لا فقط بما يخص حصتي أنا.

وهذا هو الجزء الذي لفت انتباهي. أي شخص يختار تأجيل 4 أو 8 أشهر لا يكتفي بتجميد رموزه هو فقط من أجل مضاعف أكبر لاحقًا. بل إنه أيضًا يزيل هذا المعروض من التداول مباشرة عند TGE، عندما يظهر GRVT في السوق الفوري ويتوجه إلى إدراجات CEX من الفئة الأولى. غالبًا ما يعني المعروض الأقل المتداول عند الإطلاق ضغط بيع ابتدائي أضعف واكتشاف سعر أكثر نظافة ضمن نافذة مبكرة.

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

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

الالتسجيل مفتوح حتى 27 يوليو 2026، الساعة 00:00 بالتوقيت العالمي UTC، والاختيارات نهائية، ويقع مجمع التأجيل ضمن حصة الموسم الثاني الثابتة البالغة 18% من إجمالي المعروض البالغ 1B.

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

#grvt #BinanceSquare @grvt_io
مقالة
تم حل مشكلة التفويض. لكن مشكلة الموافقة ليست محلولة بعد.ما جذبني في البداية لم يكن التكنولوجيا نفسها. بل كان الوعد الكامن وراءها — أنه يمكنك تحديد نواياك مرة واحدة وبوضوح، مع وضع حدود حقيقية مرتبطة بها، ثم الابتعاد. وستقوم الأتمتة بنقل تلك النوايا للأمام بأمانة دون أن تتطلب وجودك في كل خطوة. هذا الوعد مُقنع فعلًا. وكلما نظرت إلى معمارية بروتوكول نيوتن، ازداد فهمي لسبب جذبها اهتمامًا جديًا من أشخاص لا ينجذبون بسهولة. النهج التقني صارم في جوانب لا تتوفر في أغلب الأتمتة ضمن التمويل اللامركزي. يتم فرض السياسات عند نقطة التنفيذ، لا بعده. برهانٌ تشفيري يثبت أن الوكيل ظل ضمن الصلاحيات المحددة له. وسجلٌّ قابل للتحقق يستطيع أي شخص فحصه. ليست هذه ادعاءات تسويقية. بل قرارات تصميمية حقيقية تعكس مستوى غير معتاد من العناية بالفجوة بين ما يُفترض أن يفعله النظام وبين ما يفعله فعليًا وقت التشغيل.

تم حل مشكلة التفويض. لكن مشكلة الموافقة ليست محلولة بعد.

ما جذبني في البداية لم يكن التكنولوجيا نفسها. بل كان الوعد الكامن وراءها — أنه يمكنك تحديد نواياك مرة واحدة وبوضوح، مع وضع حدود حقيقية مرتبطة بها، ثم الابتعاد. وستقوم الأتمتة بنقل تلك النوايا للأمام بأمانة دون أن تتطلب وجودك في كل خطوة.
هذا الوعد مُقنع فعلًا. وكلما نظرت إلى معمارية بروتوكول نيوتن، ازداد فهمي لسبب جذبها اهتمامًا جديًا من أشخاص لا ينجذبون بسهولة. النهج التقني صارم في جوانب لا تتوفر في أغلب الأتمتة ضمن التمويل اللامركزي. يتم فرض السياسات عند نقطة التنفيذ، لا بعده. برهانٌ تشفيري يثبت أن الوكيل ظل ضمن الصلاحيات المحددة له. وسجلٌّ قابل للتحقق يستطيع أي شخص فحصه. ليست هذه ادعاءات تسويقية. بل قرارات تصميمية حقيقية تعكس مستوى غير معتاد من العناية بالفجوة بين ما يُفترض أن يفعله النظام وبين ما يفعله فعليًا وقت التشغيل.
السؤال الذي بقيت جالسًا أتأمله لم يكن متعلقًا بالتكنولوجيا. كان متعلقًا بالمساءلة. @NewtonProtocol يمكن التحقق من أن الوكيل التزم بقواعده. البرهان التشفيري حقيقي — كل تقييم للسياسة يترك سجلًا، كل إجراء ضمن الأذونات المحددة يمكن إقراره. وهذا بصدق أكثر مما تقدمه معظم الأتمتة في التمويل اللامركزي اليوم. لكن إليك الأمر. التنفيذ القابل للتحقق والحكم القابل للتحقق مشكلتان مختلفتان. نيوتن يحل الأولى بعناية. الثانية ما تزال إلى حد كبير على عاتق من كتب القواعد. بعبارات بسيطة: إذا ضبط مدير الخزنة حدًا للإنفاق اتضح أنه واسع جدًا، أو حدّد مُحفّز إعادة توازن كان منطقيًا في الأسواق الهادئة لكنه لم يكن مناسبًا للأوضاع المتقلبة، فإن نيوتن يفرض تلك القواعد بشكل صحيح. تعمل السياسة، يُنتَج البرهان، تستقر المعاملة. لقد عمل كل شيء كما صُمِّم. وقد تكون النتيجة مع ذلك سيئة. هذا ليس خللًا في بنية النظام بالضبط. لا يمكن لأي طبقة إنفاذ أن تجعل الحكم البشري أفضل. لكن هذا يطرح سؤالًا لم يجب عليه البروتوكول بالكامل بعد — عندما تكون السياسة صحيحة لكن القواعد التي بُنيت عليها كانت خاطئة، أين تقع المساءلة؟ مع المشغل الذي قام بتكوينها؟ مع المطور الذي نشر القالب؟ مع المستخدم الذي فعّلها دون أن يقرأ بالكامل ما وافق عليه؟ التمويل التقليدي يحل ذلك عبر الترخيص والواجب الائتماني والتنظيم. أما التشفير فيحله عبر توثيق لا يقرأه أحد وشروط خدمة تُنكر كل شيء. نيوتن يقف الآن في منتصف هذه الفجوة. طبقة الإنفاذ يجري بناؤها بعناية. أما طبقة المساءلة حول من يصمم القواعد، ومن يقوم بتدقيقها، ومن يجيب عندما تفشل — فهذا الجزء ما يزال إلى حد كبير طموحًا. سواء تم حسم ذلك مع مرور الوقت ربما يهم أكثر من أي إنجاز تقني آخر في خريطة الطريق. $NEWT @NewtonProtocol #Newt
السؤال الذي بقيت جالسًا أتأمله لم يكن متعلقًا بالتكنولوجيا. كان متعلقًا بالمساءلة.

@NewtonProtocol يمكن التحقق من أن الوكيل التزم بقواعده. البرهان التشفيري حقيقي — كل تقييم للسياسة يترك سجلًا، كل إجراء ضمن الأذونات المحددة يمكن إقراره. وهذا بصدق أكثر مما تقدمه معظم الأتمتة في التمويل اللامركزي اليوم.

لكن إليك الأمر. التنفيذ القابل للتحقق والحكم القابل للتحقق مشكلتان مختلفتان. نيوتن يحل الأولى بعناية. الثانية ما تزال إلى حد كبير على عاتق من كتب القواعد.

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

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

التمويل التقليدي يحل ذلك عبر الترخيص والواجب الائتماني والتنظيم. أما التشفير فيحله عبر توثيق لا يقرأه أحد وشروط خدمة تُنكر كل شيء.

نيوتن يقف الآن في منتصف هذه الفجوة. طبقة الإنفاذ يجري بناؤها بعناية. أما طبقة المساءلة حول من يصمم القواعد، ومن يقوم بتدقيقها، ومن يجيب عندما تفشل — فهذا الجزء ما يزال إلى حد كبير طموحًا.

سواء تم حسم ذلك مع مرور الوقت ربما يهم أكثر من أي إنجاز تقني آخر في خريطة الطريق.

$NEWT @NewtonProtocol #Newt
كنتُ أُعيد قراءة آليات «خطة المضاعِف» الفعلية على مركز مساعدة GRVT هذا الصباح، بعيدًا عن لغة التسويق، ولاحظتُ شيئًا لم أكن قد أخذته في الحسبان من قبل. تخصيص الموسم الثاني ثابت عند 18% من إجمالي إمداد GRVT البالغ 1 مليار. كما أن إجمالي تخصيص المجتمع والإيردروب (المنح الجوية) محدود عند 28%. هذا ليس رقمًا يتغير؛ إنه ثابت قبل أن يسجّل أي شخص. فلمّا كانت «خطة المضاعِف» تتيح حتى 4 أضعاف مخصّصك عند تأجيل الاستحقاق، فمن أين تأتي هذه الزيادة في الحجم فعليًا؟ لا يمكن أن تأتي من توكنات جديدة؛ فالإمداد ثابت ولا توجد زيادة إصدار إضافية. لا بد أنها تأتي من نفس «المسبح» الذي يستقي منه الجميع. وهذا يعني أن الخطة ليست حقًا تكافئ الصبر بقيمة جديدة. إنها تعيد توزيع فطيرة ثابتة. كل شخص يأخذ مضاعفًا أكبر عبر الانتظار، يكون في الواقع يقلّص ما يتبقى من الحصة للمسبح مقارنةً بمن يطالبون فورًا. إنها تقسيمة محصلتها صفر (zero-sum) مُقدَّمة على أنها مكافأة ولاء. التسجيل مفتوح الآن حتى 27 يوليو 2026، 00:00 بتوقيت UTC، والاختيار نهائي بمجرد اتخاذه. لا أحد يعلم بعد ما هي نسبة المشاركين الذين سيختارون المضاعِف مقابل المطالبة الفورية، وهذه النسبة بالذات هي ما يحدد إن كان التأجيل يستحق العناء. إذا اندفع معظم الناس للمطالبة فورًا، فسيحصل القليل الذين تأجلوا على حصة أكبر بكثير. أما إذا كان معظم الناس يؤجلون، فإن المضاعِف يضعف تلقائيًا مقابل نفسه وتنكمش «المكافأة» حتى تقترب من الصفر. أتساءل أي اتجاه ستأخذ به أرقام التسجيل فعليًا بمجرد إغلاق النافذة. #grvt #BinanceSquare @grvt_io
كنتُ أُعيد قراءة آليات «خطة المضاعِف» الفعلية على مركز مساعدة GRVT هذا الصباح، بعيدًا عن لغة التسويق، ولاحظتُ شيئًا لم أكن قد أخذته في الحسبان من قبل.

تخصيص الموسم الثاني ثابت عند 18% من إجمالي إمداد GRVT البالغ 1 مليار. كما أن إجمالي تخصيص المجتمع والإيردروب (المنح الجوية) محدود عند 28%. هذا ليس رقمًا يتغير؛ إنه ثابت قبل أن يسجّل أي شخص.

فلمّا كانت «خطة المضاعِف» تتيح حتى 4 أضعاف مخصّصك عند تأجيل الاستحقاق، فمن أين تأتي هذه الزيادة في الحجم فعليًا؟ لا يمكن أن تأتي من توكنات جديدة؛ فالإمداد ثابت ولا توجد زيادة إصدار إضافية. لا بد أنها تأتي من نفس «المسبح» الذي يستقي منه الجميع.

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

التسجيل مفتوح الآن حتى 27 يوليو 2026، 00:00 بتوقيت UTC، والاختيار نهائي بمجرد اتخاذه. لا أحد يعلم بعد ما هي نسبة المشاركين الذين سيختارون المضاعِف مقابل المطالبة الفورية، وهذه النسبة بالذات هي ما يحدد إن كان التأجيل يستحق العناء.

إذا اندفع معظم الناس للمطالبة فورًا، فسيحصل القليل الذين تأجلوا على حصة أكبر بكثير. أما إذا كان معظم الناس يؤجلون، فإن المضاعِف يضعف تلقائيًا مقابل نفسه وتنكمش «المكافأة» حتى تقترب من الصفر.

أتساءل أي اتجاه ستأخذ به أرقام التسجيل فعليًا بمجرد إغلاق النافذة.

#grvt #BinanceSquare @grvt_io
مقالة
Trustless كانت دائمًا تبسيطًا. يبدو أن نيوتن يعرف ذلك.هناك شيء ظلّ يلازمني هذا الأسبوع ولم أستطع صياغته بشكل واضح حتى الآن. يتعلق الأمر بكلمة استخدمتها التشفير كثيرًا لدرجة أنها توقفت عن حمل المعنى. تلك الكلمة هي «trustless». لقد كنت أفكر فيه بشكل مختلف مؤخرًا. ليس كنوع من النقد للفكرة، بل كإعادة تقييم صادقة لما بنيناه فعلًا. كان «ثِقَلَسْس» دائمًا هو الهدف — إزالة الحاجة إلى الاعتماد على أي مؤسسة، أو أي شخص، أو أي سلطة. استبدال الثقة البشرية بالرياضيّات. لتدعَ الكود هو الذي يقرر. كانت طموحًا أنيقًا، وفي بعض النواحي الضيقة كان يعمل.

Trustless كانت دائمًا تبسيطًا. يبدو أن نيوتن يعرف ذلك.

هناك شيء ظلّ يلازمني هذا الأسبوع ولم أستطع صياغته بشكل واضح حتى الآن. يتعلق الأمر بكلمة استخدمتها التشفير كثيرًا لدرجة أنها توقفت عن حمل المعنى. تلك الكلمة هي «trustless».
لقد كنت أفكر فيه بشكل مختلف مؤخرًا. ليس كنوع من النقد للفكرة، بل كإعادة تقييم صادقة لما بنيناه فعلًا. كان «ثِقَلَسْس» دائمًا هو الهدف — إزالة الحاجة إلى الاعتماد على أي مؤسسة، أو أي شخص، أو أي سلطة. استبدال الثقة البشرية بالرياضيّات. لتدعَ الكود هو الذي يقرر. كانت طموحًا أنيقًا، وفي بعض النواحي الضيقة كان يعمل.
قضيت جزءًا من اليوم أحاول كسر إعداد وكيل نيوتن للغة الطبيعية — ليس بطريقة خبيثة، بل فقط أفكر في ما يحدث عندما تلتقي الإنجليزية المبسطة بكود دقيق. التجربة سلسة فعلًا. تكتب شيئًا مثل "أعد موازنة محفظتي إذا تجاوز أي أصل منفرد 30%" والنظام يحوّل ذلك إلى سياسة قابلة للتنفيذ فعليًا مع إرفاق zkPermissions. لا Solidity. لا ملفات إعدادات. الفجوة بين النية والتنفيذ تبدو أصغر من أي شيء استخدمته من قبل في التمويل اللامركزي. ثم بدأت أطرح الأسئلة اللاحقة الواضحة، وتعقّدت السلاسة بسرعة. 30% من ماذا بالضبط؟ قيمة المحفظة الحالية وقت حدوث الشرط؟ القيمة في وقت إنشاء الإذن؟ الإيداع الأولي؟ هذه التفسيرات الثلاثة تنتج محفزات إعادة موازنة مختلفة في سوق متقلب، أحيانًا بفروقات كبيرة جدًا. "أي أصل منفرد" — هل يشمل ذلك المراكز المرهونة؟ توكنات مجمع السيولة؟ الإصدارات الملتفّة من نفس الأصل المحتفظ بها عبر بروتوكولات مختلفة؟ البروتوكول لا يسيء فهمك. هذه هي المشكلة. فهو يفهمك بدقة وينفّذ تمامًا ما تقوله النسخة المُحللة من تعليمك، وربما لا يكون هذا هو ما كنت تقصده عندما كتبته في جملة عادية. يجعل نيوتن فرض السياسات موثوقًا. لكنه لا يجعل تأليف السياسات موثوقًا. هاتان مشكلتان مختلفتان، والثانية لا تُحلّها بنية تحتية أفضل — بل تُحلّها إعدادات افتراضية أفضل، ومعاينات تفسير أوضح، وربما بعض الحالات الحديّة المؤلمة التي تُعلّم النظام البيئي ما الذي تحتاجه كلمة "إعادة الموازنة" لتحديده قبل أن يمكن أتمتتها بأمان. أفضل أن تُظهر لي طبقة اللغة الطبيعية السياسة المُحللة بصياغة واضحة قبل أن أؤكدها، بدلًا من اكتشاف عدم تطابق التفسير بعد ثلاثة أسابيع عندما نفّذ الوكيل ما قلته حرفيًا تمامًا وشيئًا لا يشبه ما كنت أقصده $NEWT @NewtonProtocol #Newt
قضيت جزءًا من اليوم أحاول كسر إعداد وكيل نيوتن للغة الطبيعية — ليس بطريقة خبيثة، بل فقط أفكر في ما يحدث عندما تلتقي الإنجليزية المبسطة بكود دقيق.

التجربة سلسة فعلًا. تكتب شيئًا مثل "أعد موازنة محفظتي إذا تجاوز أي أصل منفرد 30%" والنظام يحوّل ذلك إلى سياسة قابلة للتنفيذ فعليًا مع إرفاق zkPermissions. لا Solidity. لا ملفات إعدادات. الفجوة بين النية والتنفيذ تبدو أصغر من أي شيء استخدمته من قبل في التمويل اللامركزي.

ثم بدأت أطرح الأسئلة اللاحقة الواضحة، وتعقّدت السلاسة بسرعة.

30% من ماذا بالضبط؟ قيمة المحفظة الحالية وقت حدوث الشرط؟ القيمة في وقت إنشاء الإذن؟ الإيداع الأولي؟ هذه التفسيرات الثلاثة تنتج محفزات إعادة موازنة مختلفة في سوق متقلب، أحيانًا بفروقات كبيرة جدًا. "أي أصل منفرد" — هل يشمل ذلك المراكز المرهونة؟ توكنات مجمع السيولة؟ الإصدارات الملتفّة من نفس الأصل المحتفظ بها عبر بروتوكولات مختلفة؟

البروتوكول لا يسيء فهمك. هذه هي المشكلة. فهو يفهمك بدقة وينفّذ تمامًا ما تقوله النسخة المُحللة من تعليمك، وربما لا يكون هذا هو ما كنت تقصده عندما كتبته في جملة عادية.

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

أفضل أن تُظهر لي طبقة اللغة الطبيعية السياسة المُحللة بصياغة واضحة قبل أن أؤكدها، بدلًا من اكتشاف عدم تطابق التفسير بعد ثلاثة أسابيع عندما نفّذ الوكيل ما قلته حرفيًا تمامًا وشيئًا لا يشبه ما كنت أقصده

$NEWT @NewtonProtocol #Newt
عدت لقراءه الصيغة الدقيقة التي يستخدمها GRVT لعملية اقتطاع المبلغ، لأنني أدركت أن النقاش السابق الذي رأيته لم يوضحها فعليًا. هي عجز صندوق التأمين مقسومًا على حقوق الملكية الإجمالية للعملاء. هذا المقام هو الجزء الذي غيّر طريقة رؤيتي للأمر. يعني أن عملية الاقتطاع ليست عقوبة ثابتة مرتبطة بحجم العجز فقط. بل هي نسبة تتحرك بحسب مقدار إجمالي رأس مال العملاء الموجود في البورصة في تلك اللحظة بالذات. نفس العجز، لكن مع حقوق ملكية إجمالية أكبر على المنصة، وتقل رسوم السحب تلقائيًا. نفس العجز، لكن مع حقوق ملكية إجمالية أقل، وتصبح الرسوم أكثر حدة. لذلك فإن النمو يعمل بهدوء كوسادة امتصاص للصدمات. فقاعدة مستخدمين أكبر لا تبدو فقط أكثر صحة على لوحة المعلومات، بل إنها رياضيًا تُخفف العبء الذي يتحمله أي مستخدم يقوم بالسحب خلال حدث عجز. وهذا يعني أيضًا أن العكس صحيح: عندما يصيب العجز فترة أكثر هدوءًا، مع أموال أقل متوقفة على المنصة، ينتج عن ذلك اقتطاع أكثر حدة بالنسبة لنفس العجز بالدولار. هذا ليس خللًا بالضبط؛ إنه مجرد خاصية لا يعلن عنها أحد. حجم الخسارة التي تتحملها أنت شخصيًا يعتمد بدرجة أقل على سبب حدوث العجز وبدرجة أكبر على مقدار رأس المال غير المرتبط الذي كان موجودًا في GRVT في اليوم الذي احتجت فيه إلى الخروج. سواء كانت هذه ميزة تُسهم في الاستقرار أو أنها مخاطرة توقيت مخفية، فغالبًا يعتمد على مدى سرعة انخفاض حقوق الملكية الإجمالية للعملاء نفسها خلال نفس حدث الضغط الذي تسبب في العجز أولًا. #grvt #BinanceSquare @grvt_io
عدت لقراءه الصيغة الدقيقة التي يستخدمها GRVT لعملية اقتطاع المبلغ، لأنني أدركت أن النقاش السابق الذي رأيته لم يوضحها فعليًا.

هي عجز صندوق التأمين مقسومًا على حقوق الملكية الإجمالية للعملاء. هذا المقام هو الجزء الذي غيّر طريقة رؤيتي للأمر.

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

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

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

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

#grvt #BinanceSquare @grvt_io
مقالة
لماذا يجعل نموذج الترخيص ذو الطبقتين لدى نيوتن أفكّر بشكل مختلف بشأن موافقات المحافظبينما كنت أراجع التوثيق التقني لبروتوكول نيوتن، كنت أعود باستمرار إلى تمييزٍ مفاده أن معظم تفاعلات المحافظ تنكمش إلى خطوة واحدة. كلما نظرت أكثر، ازددت قناعة بأن فصل هذه الخطوة إلى طبقتين منفصلتين قد يكون أحد أكثر القرارات المعمارية تأثيرًا في المشروع — حتى لو لم يقم نيوتن بتسميته رسميًا كميزة موحدة. دعني أشرح المشكلة أولاً، لأن فهمها يستحق العناء حقًا قبل النظر إلى الحل.

لماذا يجعل نموذج الترخيص ذو الطبقتين لدى نيوتن أفكّر بشكل مختلف بشأن موافقات المحافظ

بينما كنت أراجع التوثيق التقني لبروتوكول نيوتن، كنت أعود باستمرار إلى تمييزٍ مفاده أن معظم تفاعلات المحافظ تنكمش إلى خطوة واحدة. كلما نظرت أكثر، ازددت قناعة بأن فصل هذه الخطوة إلى طبقتين منفصلتين قد يكون أحد أكثر القرارات المعمارية تأثيرًا في المشروع — حتى لو لم يقم نيوتن بتسميته رسميًا كميزة موحدة.
دعني أشرح المشكلة أولاً، لأن فهمها يستحق العناء حقًا قبل النظر إلى الحل.
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
خريطة الموقع
تفضيلات ملفات تعريف الارتباط
شروط وأحكام المنصّة