goat111

من الآن فصاعدًا، كل من يقول إنه ملك التوقعات، فليُخرج هذا الترتيب

لكن صاحب المركز الأول مبالغ فيه جدًا، فقد راهن بكل شيء ووصل إلى ٢٠٠ ألف نقطة في اليوم الأول

أما أنا، فبذلت كل ما بوسعي ولم أحصل إلا على ٩٠٠٠ نقطة#币安神算子

في زاوية لا يلتفت إليها أحد، أدرجت منصة Predict عقود ما قبل التداول لـAster

وصلت القيمة المخففة بالكامل (FDV) إلى 5 مليارات في ذروتها، وهي الآن عند 2 مليار

من شاركوا في جمعها لا بد أنهم حققوا ثروة

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

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

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

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

تابعوا باستمرار مستجدات التطوير لدى $NIL و@Nillion

أجروا أبحاثكم الخاصة (DYOR)، وهذا ليس نصيحة استثمارية

#nil $NIL @Nillion

إطلاق جديد على Booster

⭐ شارك مقابل خصم نقطتين، إجمالي المكافآت 10U، والمقاعد المتاحة 10,000
سارعوا بالمشاركة إذا كنتم مهتمين

المهمة الأولى

1. تابعوا الحساب الرسمي لـ bstock

2. تداولوا رموز أسهم bstock بقيمة تعادل 100U؛ يُنصح بشراء Apple أو QQQ بقيمة 101U

المهمة الثانية
1. تابعوا الحساب الرسمي لـ flap

2. أعيدوا نشر المقالة ذات الصلة

3. اشتروا وبِيعوا عملة ميم للأسهم بقيمة 10U؛ يُنصح بشراء عملة «牛来» بقيمة 11U

⚠️ جهّزوا 11U من BNB، واختاروا وفقًا للقيمة السوقية. انتبهوا كي لا تشتروا عملة مقلّدة، ويمكنكم عند الحاجة مقارنة عنوان العقد (CA).

اتضح أن هناك كثيرًا من الأجانب ما زالوا يشاركون في أنشطة Alpha!

لكن أنشطة Binance تراجعت فعلًا في الآونة الأخيرة، سواء مسابقات التداول الفوري أو Alpha أو Booster، وحتى المنشورات القصيرة (مهام صنّاع المحتوى) لم يعد لها وجود منذ سبتمبر.

لا أدري إن كان السبب ركود السوق الشديد، أم أن Binance بدأت تحوّل تركيزها من العملات المشفرة إلى الأسهم.

آمل أن تعود السوق الصاعدة التي تخص صغار المستثمرين يومًا ما.

الصورة أدناه 👇🏻 هي مطلب لأحد المؤثرين الأجانب على منصة تواصل اجتماعي.

HYPE$HYPE هل تم إدراجه في Binance الفوري الآن؟

هل يعني ذلك أنه في المستقبل سيتم بشكل رسمي أن نكون وسيطًا + بورصة للتداول المشفّر؟

الـIPO الأول لأصول “الأسهم” على السلسلة من Binance كان فعليًا عبر Polymarket… فهل هذا يعني أن Polymarket لم يعد يُصدر عملات؟

تم ضبط وقت الافتتاح على 9.24، الساعة الخامسة مساءً.

إليك نقاط الانتباه التالية:
1: يتم ذلك على PancakeSwap، ويُفترض أنه مثل الاكتتاب الأولي لـ ALPHA.

2: ما تحصل عليه هو عملة فحسب، دون أي حقوق ملكية للمساهمين.

3: يتم تحديد المبالغ المخصصة حسب نقاط Alpha، ومستوى شارة Trencher، ومستوى bStocks على السلسلة.

21 بنكًا عالميًا يلتزمون بإنشاء شركة عملة مستقرة مشتركة

وفقًا لتقرير من CoinDesk، تعهّدت 21 من أكبر البنوك العالمية، بما في ذلك بنك أوف أميركا سيتي جروب وجولدمان ساكس ودويتشه بنك ويو بي إس، بتأسيس شركة عملة مستقرة مشتركة.

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

وهذا هو التحالف الثاني من نوعه بين عمالقة القطاع الذي يطلق عملة مستقرة هذا العام؛ والسابقة كانت OUSD.

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

مسابقة ألفا للتداول

لماذا لا تكون الإعلانات بالتقليدية والمبسطة متطابقة؟ 🤔
$IN $AIA

هبوطٌ سلس، ومع ذلك فخطة «أنزي» هي الأقوى؛ لقد وفّرت الضمانات لإخوتي في مسابقة التداول
$KII

كتبتُ Dusk على مدار أسبوعين متتاليين، ولم أكتشف ذلك عند تنظيم الملفات أن حكمي قد تغيّر مرتين.

في البداية اعتبرته سلسلة بلوكشين خصوصية، ثم دفعته معلومات التعاون والتراخيص إلى طرفٍ آخر، كدت أظن أن «المنظومة المالية الخاضعة للتنظيم كاملة قد اكتملت».

لكن حين أفصل حالات كل طبقة على حدة، لم تكن النتيجة بهذه الروعة، لكنها باتت أقرب للواقع. طبقة DuskDS الأصلية L1 أصبحت بالفعل Live، وهي مسؤولة عن مرحلة الحسم وتوافر البيانات والنشر وحسابات الخصوصية؛ وDuskEVM تستوعب مطوري Solidity، بينما يقوم Hedger بتعزيز قدرات السرية. Citadel يتولى الهوية والإفصاح الانتقائي؛ وNPEX و21X يقدمان واجهات سوق وتنظيم مختلفة؛ أما Dusk Trade فيعيد تغليف القبول والتداول والتسوية في نقطة دخول واحدة.

والأمر المثير للاهتمام أن كون المكدس التقني «له هذه الطبقة» ليس هو نفسه أن المنتج «نضج إلى هذه الدرجة». أثناء مراجعة الموقع الرسمي، ما زالوا يصنّفون Dusk Trade على أنه Building، بينما يصنّفون DuskEVM وHedger على أنهما Testnet؛ وDusk Connect ومحفظة جديدة هما Developer Preview. تشغيل الطبقة الأساسية الأصلية لا يعني أن تجربة التداول، أو الخروج عبر السلاسل، أو السيولة قد اكتملت جميعها.

لدى الموقع الرسمي أيضًا عدة أرقام يمكن بسهولة جعلها عناوين كبيرة: تأكيد إصدار من أكثر من 300M يورو للمؤسسات، وصول لأكثر من 50K مستخدم، و210M+ تم توظيفها كضمان، وحسم بنحو 10 ثوانٍ.

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

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

لقد أثبت Dusk أنه ليس مجرد فكرة. والخطوة التالية هي إثبات وجود أشخاص يستخدمونه بشكل مستمر.

عندما تمنحون درجة لمشروع بنية تحتية، هل تركزون أكثر على اكتمال التقنية، أم على الأعمال الحقيقية الواقعة بالفعل؟
#dusk $DUSK @Dusk

الساعة الواحدة صباحًا أنهيت إعادة فحص حادثة جسر Dusk وتحليل AEGIS معًا حتى آخر لحظة، وقبل أن أغلق الصفحة شعرت فجأة بشيء من الخوف: قبل أيام قليلة كدت أقبل خيارين “سهليْن جدًا” — “ليس ثغرة L1 لذلك لا شيء” أو “بما أن الجسر حدثت له مشكلة، إذن فالسلسلة كاملة غير آمنة”.

الواقع أعقد بكثير من الشعارات. في 16 يناير 2026، حصل المهاجمون على صلاحيات محفظة التوقيع المستخدمة لخدمة جسر Dusk إلى EVM.

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

والأمر المثير للاهتمام أن نقطة الإصلاح ليست مجرد “استبدال مفتاح”. فالتصميم الجديد يفصل استقبال الأحداث، والاحتفاظ بالمهام بشكل دائم، وإطلاق الأموال، وجهاز التوقيع المخصص. تتم إدارة المعاملات عبر آلة حالات مثل seen وsubmitted وcompleted وfailed وstuck؛ وتحتفظ المحفظة الساخنة فقط برصيد يلزم مؤقتًا، وعندما لا تكفي الأموال يتم الإيقاف، ثم يَقوم صندوق بارد بالإمداد يدويًا.

سأضرب مثالًا بسيطًا: تحويل شاحنة نقل أموال مملوءة بالكامل إلى نظام مقصورات وحصص وحدود وتصاريح تدريجية.

أما AEGIS فهو قصة أخرى: دفعت عملية التدقيق الداخلي 39 إجراء إصلاح، تم تصنيف 7 منها على أنها “مستوى حرج”، وتشمل الأسباب الجذرية مثل عزل VM وإلغاء التسلسل (anti-deserialization) وربط رسوم Phoenix بالاسترداد، وقيام BLS بتزوير. وتقول الجهة الرسمية إنه لم يتم العثور حتى الآن على أدلة على استغلال هذه المشكلات الحرجة سابقًا. لا يمكن خلط حدث الجسر وAEGIS في نفس الثغرة، ولا يمكن اعتبار أن المخاطر انعدمت فقط لأنهما تم إصلاحهما.

لذلك حُكمي الآن هو: ليست ثغرة إجماع، لا يعني ذلك أنها ليست مشكلة أمان للمستخدم؛ إعادة الفحص العامة تستحق الإشادة، لكنها لا تغني عن الاستقرار طويل الأمد والتحقق من طرف ثالث.

عندما تقيّمون سلسلة ما، هل تحسبون الجسر والعمليات التشغيلية ضمن درجة أمان البروتوكول؟
#dusk $DUSK @Dusk

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

عند الحديث عن تقنية Dusk، غالبًا ما يركز الجميع على DuskDS أو Phoenix أو DuskEVM، ونادرًا من يتحدث بجدية عن Dusk Connect. كانت Web Wallet السابقة عبارة عن صفحات مستقلة نسبيًا، مما يجعل من الصعب على dApp اكتشاف المحفظة بشكل معياري وطلب التوقيع.

في أبريل 2026، افتتح Dusk Connect رسميًا. وهو يستلهم فكرة اكتشاف المحافظ من EIP-6963، ويستخدم واجهة Provider موحدة للتعامل مع الوصول إلى الحسابات والتوقيع والمعاملات وتبديل الشبكات؛ كما أن Dusk Wallet الجديدة تستعد لتغطية المتصفح وسطح المكتب والهواتف المحمولة، وتدعم التحويل والستيكينغ واستلام المكافآت وصلاحيات dApp.

والأمر المثير للاهتمام أن “بروتوكول الاتصال” و“أمان المحفظة” طبقتان مختلفتان. يتولى Dusk Connect جعل التطبيق يعثر على المحفظة وإرسال الطلبات، لكنه لا يحتفظ بمفتاح المستخدم؛ فالمحفظة الجديدة هي التي تتولى تخزين المفتاح محليًا.

كتب المسؤولون الرسميون أيضًا أن طرف الإضافة يستخدم PBKDF2 مع AES-GCM، بينما الطرف الأصلي يستخدم Stronghold وArgon2، مع إضافة قفل تلقائي، وتراجع/إرجاء عند فشل فتح القفل، وتفويض حسب المصدر.

وهذا قد يجعل الدعاية تخلط الأمر بسهولة في جملة واحدة مثل “لقد تحسنّت تجربة محفظة Dusk”. في الحقيقة، الواجهة الموحدة تجعل الدخول أسهل، لكنها لا تعني أن كل تفويض سيكون آمنًا.

قد تظل مواقع التصيد قادرة على إقناع المستخدمين بالتوقيع، كما أن صياغة الصلاحيات غير الواضحة قد تجعل المستخدم يسلم وصولًا لا ينبغي منحه. فضلًا عن ذلك، فإن كلا المستودعين ما زالا Developer Preview حتى الآن.

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

عندما تستخدمون المحفظة، هل تراجعون الصلاحيات بجدية، أم أنكم تؤكدون تقريبًا خطوة بخطوة إلى أن تنتهي؟
#dusk $DUSK @Dusk

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

عند الحديث عن المزايا التنظيمية لـ Dusk، كثير من المقالات تذكر NPEX و21X وMTF وDLT-TSS مرة واحدة، وكأن جميع هذه التراخيص مدمجة بالكامل داخل بروتوكول Dusk. لكن عند تفكيك الصورة، نجد أن NPEX و21X يغطّيان نقاطًا مختلفة.

فـ NPEX هي جهة سوق خاضعة للتنظيم في هولندا، وتتضمن المواد الرسمية إشارة إلى قدراتها في MTF وBroker وECSP: يتم ذلك ضمن خط واحد يشمل السوق الثانوية، والبحث عن الأصول وتنفيذ الأوامر، وخدمات التمويل الجماعي في الاتحاد الأوروبي.

أما 21X فقد حصل على ترخيص DLT-TSS بموجب نظام DLT Pilot Regime في الاتحاد الأوروبي، ما يسمح—ضمن إطار محدد—بدمج التداول والتسوية، واستخدام سلاسل بلوكتشين عامة لا تتطلب ترخيصًا. حاليًا، يُعد Dusk مشاركًا في تداول 21X، بينما ما يزال التكامل الأعمق ضمن DuskEVM مخططًا له.

والأمر المثير للاهتمام أن هاتين الشراكتين ليستا مجرد “ختم متكرر”. NPEX أقرب إلى كونه بوابة للأصول والجهات المُصدِرة والمستثمرين، بينما 21X يشبه قناة تنظيمية لتداول الأوراق المالية الرقمية وتسويتها، وDusk في المنتصف يوفر الخصوصية والهوية وتقنيات التسوية. من حيث المنطق، يجتمع الثلاثة بسلاسة، لكن “جمعهم” لا يعني ضمّ المسؤوليات القانونية تلقائيًا.

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

عندما أراجع مثل هذه المشاريع الآن، أسأل أولًا: لمن تعود التراخيص؟ وما نوع الأصول التي تغطيها؟ ومن يتحمل مسؤولية المستخدمين؟

هل أنتم تركزون أكثر على عدد التراخيص في شراكات المشروع، أم أنكم تهتمون فعلًا بمكان إجراء أول صفقة حقيقية تحت اسم الكيان القانوني؟
#dusk $DUSK @Dusk

بردت القهوة مرتين ولم أحتسها حتى الآن، فحين كنت أقارن بين الإعلانين اللذين صدرَا عن Dusk وChainlink ذهابًا وإيابًا، أدركت فجأة شيئًا: كنت قد خلطت تقريبًا بين “قابلية الربط عبر السلاسل” و“وجود السيولة” كأنهما الشيء نفسه.

عند الحديث عن RWA لـDusk، كثير من المقالات بمجرد أن ترى CCIP تندفع مباشرة إلى عبارة “ربط الأصول عبر السلاسل بالكامل، والسيولة ستنطلق”. لكن هذا التعاون كما تطرحه الجهة الرسمية ينقسم في الواقع إلى خطّين.

الأول هو قابلية التشغيل البيني: يقوم Dusk وNPEX باستخدام CCIP ومعيار CCT لتهيئة مسارات عبر السلاسل للأصول الخاضعة للرقابة على شبكة DuskEVM، مع بقاء عقد إصدار الأصول تحت سيطرة المُصدر، كما يمكن ضبط حدود للسرعة وآليات للترقية. أما الخط الثاني فهو البيانات: يتولّى DataLink جلب بيانات التداول الرسمية من NPEX إلى السلسلة، بينما توفّر Data Streams تحديثات سعر بأقل زمن تأخير، تُستخدم في التسعير والامتثال والتسوية.

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

وقد انتبهت كذلك إلى طريقة صياغة الكلمات: مواد رسمية كثيرة تستخدم تعبيرات تقدّمية مثل adopting وintegrating وwill.

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

قبل قليل كدت أُسحَب بفكرة مثل: “الاتصال بـChainlink = اكتملت السيولة”. أما الآن فأميل أكثر لفصل الصورة: هل تم تشغيل الربط؟ وهل البيانات موثوقة؟ وهل توجد جهة تتداول الأصل فعليًا؟

عندما تقيمون التعاون عبر السلاسل، هل ستضعون تركيزًا أكبر على قائمة التطبيقات/الأنظمة المتصلة، أم على حجم التبادل الفعلي عبر السلاسل وعمق التنفيذ؟ اتركوا رأيكم في قسم التعليقات.
#dusk $DUSK @Dusk

في عطلة نهاية الأسبوع، رتّبت صفحات إصدار عدة مشاريع RWA لتصفحها معًا، وعندما رأيت عبارة “Tokenized Securities” انتابني فجأة قدرٌ من اليقظة: يبدو أنني كنت—في السابق—أفترض تلقائيًا أنه إذا حوّلنا الأسهم أو السندات إلى توكنات، فقد اكتمل الأمر من ناحية “إسنادها إلى السلسلة”.

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

الخطوة التي يريد Dusk دفعها—“الإصدار الأصلي” (Native Issuance)—تتقدم إلى أبعد من ذلك: يدخل الأصل، منذ لحظة إنشائه، ضمن سير عمل رقمي واحد. من يحق له الحيازة، ومتى يمكنه التحويل، وكيف يتم إتمام تسوية DvP، وكيف تُنفّذ الإجراءات المؤسسية (Corporate Actions)—كل ذلك يُنسّق حول نفس الأصل الموجّه على السلسلة. الفرق يشبه إلى حد ما تحويل تذكرة ورقية إلى رمز استجابة سريعة (QR)، وبين إعادة تصميم نظام بيع التذاكر والتحقق منها وتغيير الموعد وإلغاء التذكرة بالكامل: الأولى تغيّر “الوسيط”، أما الثانية فتُغيّر “العملية”.

والأمر اللافت أن الإصدار الأصلي يبدو أكثر شمولًا، لكنه يحمل أيضًا المشكلات نفسها—معًا. يمكن للعقود الذكية أن تقيد التحويل، لكنها لا تستطيع من تلقاء نفسها أن تحدد ما إذا كانت السجلات على السلسلة تُعد—قانونيًا—قائمة على أنها “السجل النهائي” لقائمة المساهمين. كذلك، فاستعادة الحقوق بعد فقدان المحفظة، وما المسؤوليات التي يتحملها مزود الحفظ (الـCustodian)، وما إذا كانت السلطات القضائية المختلفة تعترف بالسجل ذاته، ليست أمورًا يمكن حلها بمجرد كتابة بضع أسطر من التعليمات البرمجية. ومسار DLT-TSS الذي تقوده NPEX وDusk، والأهم فيه فعلًا ليس مجرد إضافة اختصار جديد للترخيص؛ بل ما إذا كان يمكن ربط المسؤولية القانونية بتسوية الأصول على السلسلة.

وهذه هي الفخاخ التي أراها أكثر سهولة في RWA الآن: أرقام الإصدار تكون لافتة للنظر، لكن الخدمات اللاحقة غالبًا لا يطرحها أحد سؤالًا. أنا بالأحرى أريد أن أرى توزيع الأرباح، والتصويت، والاسترداد، وكيف تتم استعادة الحقوق بعد فقدان مفتاح التوقيع—هل تمر فعلاً عبر العملية الكاملة. عندما تحكمون على مشروع RWA، هل تنظرون أولًا إلى حجم الإصدار، أم إلى عدد المراحل في “حياة الأصل” التي تُسجّل فعليًا على السلسلة؟
#dusk $DUSK @Dusk

في الآونة الأخيرة، تم استدعاء الجهات المعنية مع 7 منصات قطار طرف ثالث بسبب “المساعدة في الترجيح/الاغتنام للشراء قبل غيرها” والإعلانات المدفوعة لاختيار المقاعد. وظهرت في الوسط رواية غريبة: هل “Range Order” لدى TermMax، أليس في الأساس “باقة تسريع شراء التذاكر” على السلسلة؟

بعد أن قرأت وثائق TermMax، أريد أن أقول فقط: هذا الكلام مبالغ فيه جدًا. هذا التشبيه لا يرى سوى “الانتظار”، ولا يرى من يضع القواعد. “تسريع” شراء التذاكر قد يجعل الناس يظنون أن الدفع يمكن أن يغيّر ترتيب إصدار التذاكر؛ لكن Range Order لا يبيع أولوية، ولا يضمن إتمام الصفقة. صانع السوق أو Curator يحدد نطاقات APR المسبقة، والسعة، والمنحنى؛ وبعد أن يرى المستخدمون عروض الأسعار، يختارون بأنفسهم.

إذا شعرت أن 8%—10% مناسب، فضع أوامر الشراء فقط ضمن النطاق الموافق؛ وما دام معدل الفائدة في السوق لا “يدخل” نطاقك، فلن تتم الصفقة. يمكن تبسيط المنطق إلى: APR = f(q, t)، حيث q هي كمية الصفقات المنجزة، وt هو المدة المتبقية. كما يمكن لأوامر بأمد/نطاقات متعددة أن تُقسّم التمويل؛ مثلًا، 80% في نطاق أكثر استقرارًا و20% في انتظار معدل فائدة أعلى—كأنه تقسيم أوامر بسعر محدد إلى درجات، لكن النِّسب مجرد مثال آلي.

أما الفائدة الثابتة فليست شيئًا يُكتب اعتباطًا من المنصّة. FT تمثل حق استبدال أصول الدين عند الاستحقاق، وXT هي الجزء المكمّل؛ يتحقق الشرط 1 FT + 1 XT = 1 وحدة من أصل الدين. وGT يسجل الضمانات المرهونة والدين. إذا كان سعر FT هو p، وكان عدد الأيام حتى الاستحقاق d، ومع تجاهل الرسوم، فإن العائد السنوي التقريبي يكون: APR ≈ (1÷p−1)×365÷d. يحدد الخصم، والأجل، والمنحنى معًا معدل الفائدة، ويمكن التحقق من أوامر المستخدمين وحالة الاحتياط على السلسلة.

لكن لا تخلط “تنفيذ الكود” بترجمة “سلامة أصل المبلغ”. هبوط الضمانات قد يسبب تصفية (Liquidation)، ومخاطر الأوركل (الأوراكل)، والعقود، والسيولة عند الخروج لن تختفي بمجرد أن كل شيء على السلسلة. FT ليست وديعة بنكية، وليست كذلك تعويضًا مضمونًا بلا شروط.

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

الأولى لا تضيف مصادر تذاكر، والثانية لا تمحو المخاطر. Range Order يمنح المستخدم صلاحية تحديد السعر، لكنه أيضًا يترك للمستخدم كلفة عدم تنفيذ الصفقة.
#termmax @TermMax

قبل أن أخلط بين Dusk Trade وDuskEVM وDuskDS أثناء القراءة، كنت أشعر أن هناك الكثير من المصطلحات. لكن بعد إعادة فصلها، أصبحت المنطقية أوضح.

يتولى DuskDS مهمة الإجماع، والنتائج النهائية الحتمية، وتوافر البيانات، ونماذج تداول Moonlight وPhoenix؛ بينما يتيح DuskVM تشغيل عقود Rust/WASM مباشرة على طبقة L1 الأصلية؛ ويوفر DuskEVM بيئة تطبيقات Solidity؛ أما Dusk Trade فيقوم بدوره بتغليف آليات القبول والشراء والبيع والتسوية في منتج يمكن للمستخدمين التعامل معه.

يشبه ذلك سوق الأوراق المالية: فـ DuskDS هو دفتر الأستاذ ومركز التسوية، وDuskVM وDuskEVM هما مسارا تطوير أعمال مختلفان، بينما Dusk Trade هو نافذة/شباك التداول الموجهة للمستثمرين.

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

لا يمكن للأصول الخاضعة للرقابة أن تقبل عبارة: «على الأرجح لن يحدث تراجع/rollback»؛ يحتاج السوق إلى حالة نهائية واضحة.

وانتقلت أسئلتي أيضًا: هل قد يحول التصميم متعدد الطبقات المخاطر من أداء السلسلة الواحدة إلى تعقيدات الرسائل بين الطبقات والجسور (bridges) والتشغيل/الصيانة (ops)؟ ميزة أن تكون النهاية/الجلاء النهائي في الطبقة السفلية سريعًا تعتبر نقطة قوة، لكن لا يستفيد المستخدمون حقًا من تسوية أنظف إلا إذا تمكنت الطبقات العليا من وراثتها بشكل صحيح.
#dusk $DUSK @Dusk

عند دراسة TermMax Vault، أكثر ما يهمّني هو: من الذي يتخذ القرارات نيابةً عن المستخدم.

يتوافق Vault مع معيار ERC-4626. فعندما يودع المستخدم أصولًا يحصل على حصص، ثم يقوم Curator بتخصيص الأموال إلى عدة أسواق مختلفة تستخدم نفس أصل الدين، وذلك عبر تنفيذ الاستراتيجية بأوامر Range Order.

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

لفهم الحصص يمكن استخدام علاقة أساسية: صافي القيمة لكل حصة ≈ صافي أصول Vault ÷ إجمالي الحصص المتداولة. وتكون نتائج المستخدم مرتبطة بتغير صافي القيمة، ثم يتم خصم رسوم الأداء وتكاليف التداول. كما أن عوائد الاستراتيجية التي يعرضها الموقع لا تعني أنها ستصل فعليًا في النهاية.

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

يشبه الأمر تسليم المال إلى مدير صندوق، وفي الوقت نفسه منح موظف إدارة المخاطر زر إيقاف مؤقت. وأنا أؤيد فصل الأدوار والأقفال الزمنية غير المتناظرة، لأنها تترك للمستخدم نافذة للمراقبة؛ لكن Curator ما يزال يتحكم في اختيار السوق والمنحنيات والتخصيص.

خلاصة قولي هي أن Vault خفّض عتبة التشغيل، لكنه لم يقم نيابةً عن المستخدم بإجراء العناية الواجبة على مدير الإدارة والأصول الأساسية وقدرة الخروج.
#termmax @TermMax