Pham Kim 26

"لقد أرسلتُ لك عن طريق الخطأ مبلغًا إضافيًا، هل يمكنك ردّ الفرق فورًا؟" وصلني هذا الرسالة بعد أربع دقائق من بداية صفقة على Binance P2P، وهي واحدة من أذكى محاولات الاحتيال التي صادفتها.

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

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

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

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

@Binance Vietnam #BinanceP2PAnToan
$ACE

أعتبر أمر Binance P2P منتهي الصلاحية أو مُلغى بمثابة حدّ صارم. إذا تحرّكت الأموال بعد هذا الحدّ، فلا أعيد إنشاء الصفقة القديمة عبر اتفاق خاص. قد يكون السعر المُقتبس قد تغيّر، وقد لا يحمي الضمان (escrow) التحويل المقصود بعد الآن، وقد لا يدعم تسلسل/جدول الأمر الإجراء الذي يريده الطرف الآخر الآن.

كَمُشترٍ، أتحقق من عدّاد وقت الدفع قبل الإرسال. أستخدم فقط المستفيد الظاهر في الأمر النشط، وأدفع من حساب يطابق اسمي الذي تم التحقق منه، ولا أعلم/أعلِّم الدفع إلا بعد أن أرسل فعليًا المبلغ الصحيح تمامًا. إذا أُغلِق الأمر أولًا، لا أُحوِّل وأطلب من البائع أن يطلق يدويًا. أتواصل مع دعم Binance إذا كان قد وقع بالفعل دفع متأخر أو دفع مكرر.

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

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

تحمي KYC والضمان (escrow) والدردشة والاستئناف معاملة منصّة محددة. ليست ضمانًا شاملاً لأي اتفاقات جانبية تُجمع بعد انتهاء الأمر. أُحترم حالة الأمر بقدر ما أُحترم مبلغ الدفع. تسلسلي هو: أمر نشط، مطابقة الهوية، حساب محدد، أموال مُسوّاة، تحرير مُؤكد. إذا تعطل ذلك التسلسل/انكسرت الساعة، أتوقف وأترك دعم Binance يرشد الخطوة التالية.

@Binance Vietnam #BinanceP2PAnToan
$BLESS

قل إن نموذج حوكمة بابل عادل ومعقول فيومئ الناس بالموافقة؛ وقل أيضًا إنه عدم توافق هيكلي ومعقولون يوافقون على ذلك. ردّتا الفعل كلتاهما تتجاوب مع خيار تصميم حقيقي واحد.

حاملو توكن BABY هم من يصوّتون على مقترحات Babylon Genesis، وهو الإعداد القياسي لسلاسل Cosmos SDK التي يمنح فيها التوكن الأصلي حقوق الحوكمة، بما يتسق مع كيفية عمل كل سلسلة مماثلة تقريبًا في هذا النظام البيئي. من جهة أخرى، أصحاب مراكز الـ BTC الذين يضعون عملاتهم فعليًا—وهم الأشخاص الذين يقفلون مليارات الدولارات من البيتكوين لتوفير الأمان الذي تبيعه بابل للشبكات الخارجية—لا يحصلون على تصويت مماثل على السلسلة عبر وضع الـ BTC نفسه. ومن منظور معماري بحت، فهذا منطقي: يتفاعل أصحاب مراكز الـ BTC مع السلسلة الخاصة ببيتكوين، لا مع Babylon Genesis، لذا فإن توجيه الحوكمة عبر التوكن الأصلي هو التصميم التقليدي. لكن من منظور الحوافز يبدو الأمر أغرب: المجموعة التي تتحمل فعلًا مخاطر الإقصاء (slashing) وقفل رأس المال لديها سلطة شكلية أقل من المجموعة التي تحمل توكنًا، والذي—اعتبارًا من منتصف 2026—يتداول بجزء صغير فقط من القيمة التي يقدّمها أصحاب مراكز الـ BTC مجتمعة.

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

تصميم حوكمة بابل قابل للدفاع عنه، لكنه ليس صحيحًا بشكل واضح. إن توجيه التصويت عبر BABY يتماشى مع ممارسة Cosmos SDK القياسية، لكنه يترك أصحاب مراكز الـ BTC—وهم من يقدّمون رأس مال الأمان الفعلي متعدد المليارات—دون سلطة رسمية مباشرة، وهو توتر تشير إليه أيضًا اقتراحات المشروع الخاصة بالتشارك في الوضع، والتي توحي بأن الأمر لم يُحسم داخليًا بالكامل حتى الآن.

@BabylonLabs_io $BABY #baby
$BLESS

الجسور التي تربط بين بيتكوين وسلسلة أخرى غالبًا ما تعتمد على مجموعة مُرخّصة لاكتشاف الاحتيال، وهي مجموعة مدفوعة من المراقبين بهدف رصد ما إذا حاول شخص ما المطالبة ببيتكوين (BTC) غير المستحقة له. وهذه المجموعة بحد ذاتها تُعد افتراض ثقة. وتُشير ورقة "بايبليون" الخاصة بخزنة بيتكوين (Babylon) الصادرة في أغسطس 2025 إلى أنه لا توجد طريقة معروفة لبناء جسر بيتكوين خالٍ تمامًا من افتراض الثقة اعتمادًا على لغة برمجة بيتكوين كما هي اليوم، إذ لا تزال بيتكوين تفتقر إلى تعليمات العهود (covenant opcodes) مثل OP-CAT.

تتحايل "خزائن بيتكوين الخالية من الثقة" (Trustless Bitcoin Vaults) على هذه الفجوة بطريقة مختلفة. يتم التحقق من مطالبات الاسترداد والتصفية على TBV عبر براهين معرفة صفرية لما حدث على السلسلة المضيفة، مرتبطة بفرعين متخصصين من Aave v4: بوابة/سبوك الإقراض الخاصة بـ Babylon Core Lending Spoke وسبوك تبديل خزنة BTC BTC Vault Swap Spoke. وأي مطالبة تفتقر إلى برهان صالح يمكن الطعن فيها خلال نافذة إثبات الاحتيال (fraud proof window) قبل أن يتم التسوية. ويذهب تصميم Babylon أبعد من ذلك في ضمان أن المودِع (depositor) يكون دائمًا مؤهّلًا ليكون هو المُحاجج (challenger) عن نفسه، بحيث لا يتطلب الدفاع عن BTC بالضرورة وجود مراقب منفصل مدفوع ليحضر في الوقت.

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

لم يكتفِ Babylon بإزالة لجنة المُوقّعين (signer committee) من TBV، بل دفع مهمة اكتشاف الاحتيال إلى الشخص صاحب أكبر قدر من المخاطرة: المودِع. إنها مقايضة مقصودة للملاءمة مقابل نقاء معماري، ولا تؤتي ثمارها إلا للمستخدمين الذين يفهمون ما الذي يدافعون عنه.

@BabylonLabs_io $BABY #baby
$BLESS

Alpha season rồi các con vk ơi, Top gain toàn coin alpha thế này 🤣🤣🤣
$BLESS $memes

لقد شاهدت أشخاصًا يستخدمون LBTC وSolvBTC وBabylon بالتبادل في الجملة نفسها، كما لو كانت هذه 3 أسماء لمنتج واحد. هذا خلط مفهوم. تظهر الثلاثة في نفس محادثات BTCFi، ويعود كل واحد منها إلى بيتكوين مُرهَنة عبر بروتوكول Babylon، ويُروَّج لكل واحد منها كوسيلة لجعل بيتكوين الخاملة منتِجة.

لكنها ليست الشيء نفسه، ويهم الفرق إذا كنت تهتم بما الذي تثق به فعليًا. يقوم LBTC الخاص بـ Lombard بالْإصدار والاسترداد عبر Security Consortium يضم عقدًا مؤسسية مثل Galaxy وWintermute، وهي مجموعة أطراف تثق بها لتشغيل هذه العملية بأمانة. يقوم Solv بتوجيه SolvBTC عبر طبقة تجريد الرهن التابعة له Staking Abstraction Layer، ويقوم stBTC الخاص بـ Lorenzo بإصداره عبر Staking Agents مخصّصين مسؤولين عن رهن أموال المستخدمين وإعداد التقارير مع الأدلة. كل واحد من هذه الخيارات شركة مستقلة تُضيف افتراضات ثقة خاصة بها فوق بروتوكول الرهن الأساسي الخاص بـ Babylon. أما Trustless Bitcoin Vaults الخاصة بـ Babylon فهي كائن مختلف تمامًا: بدائية (primitive) من طرف أول حيث تُودَع BTC في خزنة ذاتية الحيازة، ومُسبَق التوقيع (pre-signed)، ومشفّرة ومقيّدة بأدلة إثبات المعرفة الصفرية (zero-knowledge proofs)، دون اتحاد مؤسسات أو وكيل رهن يقوم بإصدار أي شيء نيابةً عنك.

Babylon هي طبقة التسوية والأمان الموجودة تحت LBTC وSolvBTC وstBTC، وليست إعادة تسمية لأيٍّ منها، وTBV هو المنتج الخاص بـ Babylon، ويأتي بجانبهما تلك الأطر/الأغلفة بدل أن يكون موجودًا داخلها.

@BabylonLabs_io $BABY #baby
$WMTX

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

القائمة تشمل Polychain Capital وHack VC وParadigm وGalaxy Digital، واستثمارًا بقيمة 15 مليون دولار من a16z كريبتو تحديدًا، إلى جانب عدة صناديق أخرى. هذه بالفعل قاعدة عميقة من المستثمرين الذين يفهمون البنية التحتية للعملات المشفّرة بما يكفي ليقولوا «لا» لكثير من المقترحات المنافسة لتمويل (DeFi) قائم على بيتكوين. كان الرهان على ضمانات بيتكوين الأصلية (native BTC)، وتقديمها عبر Trustless Bitcoin Vaults وAave v4 بدلًا من نموذج مُغلّف أو مُحوَّل عبر الجسور، اختيارًا حقيقيًا للأطروحة ضمن عدة بدائل.

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

إن اقتناع رأس المال لدى مستثمرين جادين هو إشارة حقيقية إلى الفريق والأطروحة. لكنه ليس إشارة إلى ما إذا كان حامل بيتكوين لديه حافز حملةٍ غير موجود (ولا يتلقى تحفيزًا) يختار بابيلون بدلًا من مجرد الاحتفاظ بـ BTC وعدم فعل شيء به. نقطة الإثبات الثانية هذه لم تحدث بعد.

@BabylonLabs_io $BABY #baby
$GIGGLE

لم يكن حاملو البيتكوين بالتجزئة هم الجمهور الوحيد الذي كان في بال بيبيليون عند تصميم صناديق بيتكوين بلا ثقة (Trustless Bitcoin Vaults)، وأعتقد أن هذا جانب مُقلَّل من أهميته في هذه القصة. تتعاون بيبيليون مع Utila، وهي منصة محافظ مؤسسية متعددة الأطراف (MPC) يثق بها أكثر من 300 مؤسسة، بما في ذلك منصات التداول، وشركات الحفظ، وصناديق التحوط، والبنوك، وذلك لإتاحة الاقتراض المدعوم بالبيتكوين بشكل أصلي مع Aave v4 مباشرةً لعملاء Utila المؤسسيين.

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

الاقتراض المدعوم بالبيتكوين بشكل أصلي عبر صناديق بيتكوين بلا ثقة من بيبيليون متاح بالفعل على شبكة الاختبار العامة (public testnet) مع Aave v4 اليوم، ولا تزال عمليات التكامل المؤسسي، مثل هذا التكامل، تُوصَف بأنها قادمة في الأشهر التالية بدلًا من كونها تعمل فعليًا الآن. الفجوة بين الإعلان وتدفق المؤسسات على أرض الواقع تستحق المتابعة عن كثب.

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

@BabylonLabs_io $BABY #baby
$COTI

التصفية على البيتكوين تواجه مشكلة توقيت لا تواجهها التصفية على الإيثيريوم. الاسترداد الأصلي للـ BTC من محفظة (vault) يعمل وفق إيقاع التسوية الخاص بالبيتكوين نفسه، ولا توجد طريقة لتسريع ذلك دون منح شخص ما تحكماً وصنْعياً (custodial control) بالعملات، وهو ما سيُفشل الفكرة بالكامل من تصميم النظام من الأساس.

تكمن إجابة Babylon وAave في فك ارتباط الحدثين. عندما تتم تصفية محفظة، يتم تحويلها فوراً إلى WBTC، بحيث تستقر مصلحة المقرض مباشرةً وفق خط إيثيريوم الزمني. أما الاسترداد الفعلي للـ BTC الأصلي فيحدث بعد ذلك بشكل منفصل، وفق خط البيتكوين الزمني الخاص به، دون أن يعرقل ذلك حل القروض لأي طرف آخر في السوق. وهناك فائدة ثانية مدرجة أيضاً. تمتلك Aave حالياً ما يقارب 5 مليارات دولار من إمداد WBTC، والذي وصفت Babylon أنه غير مستغل بما يكفي في جانب الاقتراض؛ لذا فإن تمرير تسوية التصفية عبره يعيد أيضاً بعض ذلك الـ WBTC الخامل إلى العمل.

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

Babylon ليست خالية من التغلّف (wrap) من البداية إلى النهاية؛ إنها خالية من التغلّف في المسار الذي سيسلكه معظم المستخدمين فعلياً. وعند مرحلة التصفية تحديداً، اختارت Babylon السرعة للمقرض على النقاء لخروج المقترض، وهو تبادل يمكن الدفاع عنه، لكنه تبادل مع ذلك.

@BabylonLabs_io $BABY #baby
$BANK

قل "Bitcoin plus DeFi" إلى أغلب متصفحي/مستخدمي كريبتو نيتفز، وستقفز عقولهم مباشرةً إلى جسر أو سلاسل جانبية. لفّ عملتك، وأرسلها عبر، واعتمد على مجموعة مُتحققين أو multisig في الطرف الآخر، وتمنَّ أن الجسر نفسه لا يصبح العنوان لسبب خاطئ. سنوات من استغلالات الجسور درّبت هذا الانعكاس لسبب وجيه.

يتم خلط "Trustless Bitcoin Vaults" باستمرار في نفس الدفتر الذهني، وهو دفترك غير صحيح. تصميم Babylon لا ينقل BTC خارج شبكة بيتكوين على الإطلاق؛ فالعملة تُقفل في Taproot UTXO ضمن شروط تُفرض عبر السكريبت وتظل هناك طوال دورة الإقراض/الاقتراض، بحيث لا يرى Ethereum سوى برهانًا تشفيريًا على الحالة المُقفلة عبر عميل خفيف بدلًا من الحيازة الفعلية للأصل نفسه. لا توجد سلسلة تنفيذ منفصلة تحتفظ بمسبح من BTC مُجسر كما تتطلب نماذج السلاسل الجانبية. ثم تقوم معمارية الأروَحة الخاصة بـ Aave v4 بإعادة توجيه الاقتراض استنادًا إلى هذا البرهان، وليس استنادًا إلى توكن مُجسر موجود في احتياطي شخص ما.

إن وصف ذلك بأنه "جسر آخر" يفوّت الفرق الهندسي الحقيقي، وبصراحة يقلّل من شأن المشكلة الأصعب التي اختارت Babylon حلّها. الجسور تنقل القيمة. هذا ينقل برهان القيمة بينما تبقى العملة في مكانها تمامًا كما بدأت.

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

@BabylonLabs_io $BABY #baby
$DEXE $BANK

تُروّج بابل لبروتوكولها الخاص بالـ staking بناءً على غياب الحضانة من طرف ثالث: لا توجد شركة تمتلك جهازك من نوع BTC، ولا يوجد مشغّل جسر يمكنه الاختفاء بالأموال. وتأتي لجنة العهد (covenant committee) بجانب هذا الطرح بطريقة تبدو غير مريحة بعض الشيء. فهي عبارة عن مجموعة متعددة التوقيعات من أطراف خارجية تُلزم تواقيعها قانونًا قبل أن تصبح معاملة فك الارتباط (unbonding) أو التقطيع (slashing) صالحة، مع هيكل M-of-N مفروض مباشرة داخل سكربت بيتكوين. وعلى وثائق شبكة الاختبار الخاصة بها (testnet) على نحوٍ خاص، كان لدى تلك اللجنة 9 أعضاء إجمالًا، وكانت 3 من تلك المقاعد التسعة، أي ثلث كامل، تُدار بواسطة مؤسسة بابل (Babylon Foundation) نفسها.

إن طرفًا لم تختره أنت، ويمتلك حصةً معتبرة من قوة التوقيع المطلوبة لتحريك أموالك عبر مسارٍ مُعتمد، يُعد شكلًا من أشكال التعرض لطرفٍ مقابل (counterparty exposure)، حتى إن كان أضيق من حاضنٍ يمتلك مفاتيحك مباشرة. يعترف مدونة مؤسسة بابل نفسها بهذا بشكل مباشر، إذ تصف افتراض الثقة خلف هذا النوع من اللجان بأنه مُختزل إلى «الأمانة الوجودية» (existential honesty)، بمعنى أن مُوقّعًا واحدًا أمينًا يكفي، لا أن هذا الافتراض مُلغى بالكامل، وتقترح تعهّدات (covenants) مشفّرة اقتصادية قابلة للتقطيع كحلٍّ في نهاية المطاف.

لم تحقق بابل حتى الآن انعدام الثقة من طرف ثالث الذي توحي به صياغة «بدون حضانة»؛ على الأقل ليس بعد. فـ لجنة العهد (covenant committee) تبقى اعتمادًا حقيقيًا، والمؤسسة موجودة داخلها. إن الذي أنجزته هو اعتمادٌ أضيق من الحضانة، مع خطته الخاصة لتضييقه أكثر. هاتان ادعاءان مختلفان، ولا واحد منهما صحيح بالكامل اليوم.

@BabylonLabs_io $BABY #baby
$LAB

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

يعمل Genesis في Babylon على تشغيل مسارين للأمان منفصلين في آن واحد. تؤمّن CometBFT السلسلة عبر تفويض BABY، بينما يؤمّن مجموعة مختلفة تمامًا من المشاركين، مزوّدو الإنهاء (finality providers)، عبر تفويض Bitcoin. ويمكن أن يتم خصم (slashing) المسارين بشكل مستقل إذا أساء المشاركون السلوك. تموّل السلسلة كلا الطرفين من البئر نفسه: يحمل BABY تضخمًا سنويًا قدره 8%، مُقسّمًا بالتساوي تمامًا إلى نصفين؛ 4% تتدفق إلى مُحصّلي/حائزي BABY، و4% الأخرى إلى حائزي Bitcoin، أي تقسيم متساوٍ دون أن يقوم أحد الطرفين بدعم الآخر. وحتى تسجيل التعهد يتم عبر معاملة ضمن Cosmos SDK تستهلك BABY فقط كرسوم (gas)، نظرًا لأن BABY نفسه لم يُصدر أبدًا كـ ERC-20.

القرار بتشغيل مسارين بدلًا من مسار واحد هو رهان بأن كلًا من الوزن الاقتصادي لـ Bitcoin والوزن الاقتصادي لـ BABY كلاهما ضروري، ولا يكفي أي منهما وحده. إن ربط الأمان بـ BABY فقط سيجعل الأمن الاقتصادي-اللامركزي مرتبطًا برمز جديد قليل التداول؛ أما ربطه بـ تفويض Bitcoin فقط فسيترك الإجماع دون رمز تكون حاملوه لديهم حوافز لإدارة السلسلة نفسها.

لا يختار Babylon بين أمان Bitcoin ومواءمة الحوافز لـ BABY، بل يمول كليهما في الوقت نفسه بمكافأة تضخم مقسمة بالتساوي. وهذا يكشف عن فريق غير راغب في رهان ميزانية الأمان الكاملة للسلسلة على أصل واحد، حتى عندما يكون أحد هذين الأصلين ذا قيمة أكبر بكثير من الآخر.

@BabylonLabs_io $BABY #baby
$PIEVERSE

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

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

صُممت خزائن بابل تحدياً لذلك الافتراض تحديداً. يتم حبس البيتكوين داخل UTXO محكومة بقواعد تشفيرية محددة مسبقاً ومعاملات (Transactions) مُوقَّعة مسبقاً، وفكّ الحبس يتطلب تقديم برهان إثبات معرفة صفرية (Zero-Knowledge Proof) بدل توقيع وصيّ. ثم يعمل البيتكوين المحبوس—وهو بيتكوين أصلي—كضمان للإقراض أو لإصدار عملات مستقرة (Stablecoin) على سلاسل خارجية بما في ذلك إيثريوم وكوسموس، دون أن يتم سكّ رمزٍ مُغلَّف على الإطلاق. تعمل الآلية كاملة على البيتكوين كما هو موجود الآن، دون أي أوبركات/تعليمات (Opcodes) جديدة ودون الحاجة إلى شوكة برمجية (Soft Fork) كي يصبح أيٌّ من هذا ممكناً.

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

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

@BabylonLabs_io $BABY #baby
$DEXE

من كان صاحبَ منزلٍ استأجرتُه منه في السابق، كان يواصل رفع العدد الإجمالي للوحدات في المبنى عبر تحويل غرف التخزين إلى استوديوهات؛ وهذا يعني—من الناحية التقنية—عرضًا أكثر، وإيرادًا أكثر، ومن الناحية التقنية أيضًا يخفف من شعور كل وحدة على حدة بأنها “مميزة” للعيش فيها. ظهرت الزيادة والتخفيف في عملية تجديد واحدة.

لا لدى BABY حد أقصى ثابت للمعروض. تصف أدوات تتبّع نمط التوكنومكس جدول الإصدار بأنه يمتد إلى أجل غير مسمى بدلًا من أن يُقفل عند رقم نهائي كما يفعل بيتكوين (21 مليونًا). يغطي التخصيص الأولي المخطط 10 مليارات توكن عبر فئات المستثمرين والفريق والنظام البيئي والبحث والتطوير والمجتمع، لكن الإصدار المستمر بعد هذا الأساس لا يكون مُقيَّدًا—بنفس الصرامة—بتصميم البروتوكول. يقدّم المؤيدون ذلك على أنه أمر ضروري: فالنمو في مجموعة المدققين ومقدمي الحسم النهائي (finality) مع حوافز مجتمعية طويلة الأمد يتطلب تدفقًا مستمرًا للتوكنات بدل تخصيص لمرة واحدة ينفد. يشير المنتقدون إلى الآلية نفسها باعتبارها ضغط بيع هيكليًا؛ إذ إن نحو 3.99 مليار BABY متداول بالفعل، ويُضاف المزيد عبر الاستحقاق (vesting) والإصدارات المستقبلية كل شهر، ما يخفف من حصة حاملي التوكنات الحاليين في الشبكة بغض النظر عن نمو الاستخدام. القراءتان تنطلقان من الحقيقة نفسها: معروض غير مقيد يتوسع باستمرار، يغذي توكن الحوكمة والغاز الذي يعتمد جزءًا من قيمته على الندرة وجزءًا على طلب الاستخدام الذي يواكب الإصدار الجديد. تضيف السجلات السعرية لـ BABY سياقًا: قمة في أبريل 2025 قرب 0.1661 دولار، تلتها هبـوطـة تقارب 93 بالمئة إلى 0.0107 دولار في مارس 2026، ما يعني أن السوق كان يسعّر بالفعل شكلًا من أشكال جدل التخفيف هذا.

لا تكسب حالة النمو ولا حالة التخفيف بالكامل هنا. يمكن للمعروض اللانهائي تمويل نظام بيئي ينضج، أو قد يَتآكل—بهدوء—قيمة الحامِلين، ويعتمد ما يحدث فعلًا على نمو الطلب الذي لا تستطيع Babylon ضمانه وحدها بالكامل.

@BabylonLabs_io $BABY #baby
$DEXE

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

تواجه GRVT انقسامًا مشابهًا. في ديسمبر 2024 حصلت على ترخيص فئة M للأصول الرقمية المُعدّلة (Modified Digital Asset Business License) من هيئة النقد في برمودا، والذي تصفه الشركة ومعظم التغطيات الإعلامية بأنه يجعلها أول بورصة عالمية لتداول المشتقات على السلسلة (onchain derivatives) بشكل مُنظّم. ويتم تكرار هذه الصفة باستمرار في التسويق والمراجعات. وفي المقابل، فإن الجهة التشغيلية وراء التطبيق، وهي GRVT Technologies Pte Ltd، مقيمة في سنغافورة، ويَحمل إدراج المتجر الخاص بالتطبيق نفسه بيانًا استهلاكيًا مباشرًا لسوق سنغافورة: GRVT ليست مرخّصة ولا مُعتمدة ولا مُفوَّضة ولا مُعيّنة ولا مُعترفًا بها ولا مُسجَّلة، ولا تخضع خلاف ذلك لأي تنظيم بموجب أي تشريع تُديره هيئة النقد في سنغافورة، ولا يحصل المستخدمون هناك على أي من الضمانات التنظيمية التي يوفّرها عادةً إشراف MAS. لذا، فإن الإجابة الصادقة عن "هل GRVT مُنظّمة؟" تنقسم بحسب الولاية القضائية بدل أن تنتهي إلى كلمة واحدة فقط. برمودا: نعم، ضمن فئة ترخيص مُعدّلة. سنغافورة: لا بشكل صريح، وفقًا لصياغة الشركة نفسها. كما أن المنصة تسعى للحصول على ترخيص أوسع من برمودا إلى جانب التواصل مع منظمي الاتحاد الأوروبي والشرق الأوسط، إلا أن أيًا من ذلك لم يُستكمل بعد. ومن شأن أن يقرأ مستخدمٌ عنوان "أول منصة DEX مُنظّمة في العالم" بمعزل عن السياق أن يفترض بشكل معقول تغطية أوسع من مجرد ترخيص مُعدّل واحد داخل ولاية قضائية صغيرة بعينها، بينما سيحصل مستخدمٌ مقيم في سنغافورة يقرأ التفاصيل الدقيقة في صفحة متجر التطبيقات على الانطباع المعاكس تمامًا.

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

@grvt_io #grvt
$LAB $VELVET

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

أطلقت GRVT سوقها الفوري على شبكة الاختبار (testnet) في 29 أبريل 2026، قبل أشهر من أي تصريح عام بشأن تاريخ إطلاق السوق الفوري على الشبكة الرئيسية (mainnet). جاء ذلك بعد أن كانت المنصة قد بنت سمعتها بالفعل تقريبًا بالكامل على العقود الآجلة الدائمة (perpetual futures)، عبر نحو 168 سوقًا، لذا كان الفوري يمثل منطق مطابقة وتسوية جديدًا فعلًا وليس مجرد إضافة بسيطة كميزة ثانوية. كان تشغيله على testnet يعني أن المستخدمين والمُتكاملين الحقيقيين يمكنهم توجيه الطلبات، واختبار الحالات الحدّية، وإظهار الأخطاء مقابل نوع سوق لم تكن المنصة قد شغّلته فعليًا من قبل، دون تعريض دولار واحد من حجم تداول فوري حقيقي للخطر إذا حدث شيء ما. غالبًا ما تقوم البورصات المنافسة بإرسال المنتجات الجديدة مباشرة إلى mainnet تحت ضغط الوقت الناتج عن إطلاق رموز (token) أو جداول التسويق، مع قبول المخاطرة بأن يتم اكتشاف الأخطاء الأولى من قِبل مستخدمين يدفعون بدلًا من المُختبرين. وُضع طرح GRVT للسوق الفوري ضمن خارطة طريق أوسع لعام 2026 وتحت ضغط مواعيد نهائية حقيقي من جهته، بعد سلسلة من الإعلانات المرتبطة بأشهر محددة، ومع ذلك أدخل الفريق مرحلة testnet قبل السماح لأوامر الفوري بلمس أموال حقيقية. إن ترتيب الخطوات هذا يضحّي بسرعة الوصول إلى السوق مقابل فرصة أقل لوقوع فشل مُحرِج أو مكلف بمجرد بدء تدفق رأس المال الحقيقي عبر نوع أوامر لم تكن المنصة قد شغّلته فعليًا من قبل.

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

@grvt_io #grvt
$LAB

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

تستقر سلسلة GRVT عبر نظام إثباتات ZKsync، وغالبًا ما يُوصَف الكلام حول إثباتات المعرفة الصفرية بشكل فضفاض على أنه تحقق فوري من كل معاملة عند حدوثها. لكن في الواقع، يُظهر الرصد المستقل من L2BEAT أن عمليات إرسال إثباتات ZKsync Era تصل إلى Ethereum تقريبًا كل 38 دقيقة في المتوسط، مع تحديثات الحالة التي تتبع إيقاعًا مشابهًا يبلغ نحو 29 دقيقة، وليس لكل معاملة على حدة. ومع ذلك، فهذا يبقى سريعًا وفق معايير البلوك تشين، ولا يُعدّ ذلك خللًا؛ إذ يتم تجميع الإثباتات عمدًا لجعل كل إثبات اقتصاديًا للتحقق عليه على طبقة Ethereum الأساسية بدلًا من التحقق من كل صفقة على حدة. لكن هذا يعني أن إثبات تداولك على Ethereum أقرب إلى كون تداولك مُضمَّن ضمن دفعة يتم إثباتها تقريبًا كل نصف ساعة، أكثر من كونه ضمانًا فوريًا لكل صفقة.

سجل الرصد نفسه فجوة حقيقية في قابلية التشغيل (liveness) في يونيو 2026، حيث لم تصل أي عمليات إرسال إثباتات لمدة تزيد عن 10 ساعات مقارنة بإيقاع 38 دقيقة المعتاد؛ وهذه شذوذ وليس القاعدة، لكنها موثقة وجديرة بالمعرفة بغض النظر عن مدى ندرتها.

@grvt_io #grvt
$LAB

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

توجد هذه الآلية فقط لإبقاء سعر العقد الدائم مرتبطًا بمؤشر السعر الفوري (spot index). عندما تكون العقود الدائمة أغلى من الفوري، يدفع الطويلون القصيرين لتقليص هذه العلاوة وصولًا إلى الصفر. وعندما تكون أرخص، يدفع القصيرون الطويلين بدلًا من ذلك. ليست GRVT طرفًا مقابلًا يستخرج قيمة من أي من الجانبين، بل هي المكان الذي يعيد توزيع المدفوعات بين مجموعتين من المتداولين، وهما بحكم بنيتهما يتراهنان ضد بعضهما البعض على اتجاه السعر. يأتي دخل GRVT الخاص بها من رسوم التداول على جانب المتلقي (taker) وصانع السوق (maker)، وهي بند منفصل تمامًا عن آلية التمويل.

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

@grvt_io #grvt
$LAB

Về lòng đất thật rồi 😳
$LAB

LAB chính thức xả mạnh, bay khoảng 80% trong 2 ngày
$LAB