Retsu玄

#dusk $DUSK @Dusk
بعد مراجعة مواد الاستيك الخاصة بـ Dusk لاحظت أن القيد الحقيقي لم يكن على الإطلاق هو الحجم المطلق للاستكة، بقدر ما كان هو العبء التشغيلي المتمثل في إبقاء المُوفّر (provisioner) متصلًا ومُزامنًا. إن Hyperstaking ببساطة ينقل هذا العبء من مُشغّل فردي إلى طبقة عقد ذكية يمكنها الاحتفاظ بالpositions وجمع المكافآت وتوزيعها وفقًا لقواعد قابلة للبرمجة.

فعليًا تعمل الآلية عبر السماح لرأس المال أولًا بالدخول إلى مجمّع (pool)؛ ثم يستدعي المجمّع دالة stake_from_contract الخاصة بعقد التحويل لإنشاء الـposition. لاحقًا يقوم عقد الـStake بإخطار المجمّع نفسه عندما تصبح المكافآت قابلة للمطالبة أو عندما يُطلب إلغاء الاستيك، وبذلك يصبح العقد نفسه هو المدير الفعّال للاستكة. يظل الحد الأدنى البالغ 1000 DUSK ونطاق الاستحقاق التقريبي المكوّن من 4320 بلوك ساريًا، سواء كان المستدعي إنسانًا أو عقدًا.

تظهر الصعوبة عندما يقع المجمّع بين البروتوكول والمستخدم النهائي. يمكن تقييد سيولة الخروج بواسطة قائمة انتظار المجمّع (queue) أو جدول الرسوم أو المحاسبة الداخلية، حتى لو كانت السلسلة الأساسية نفسها لا تفرض أي تأخير لفكّ الربط (unbonding). كما يرث المستخدمون التعرض لأخطاء حساب الحصص (share-calculation)، وفشل الاستدعاءات (callback)، ومنطق توزيع المكافآت، وأي مفاتيح ترقية قد يحتفظ بها العقد. لذلك، يبدو أن إزالة عقد حاضن (custodial node) ما هي إلا نقل لسطح التحكم إلى طبقة أعلى.

ومع ذلك، التصميم يستحق المتابعة لأنه يفتح مسارًا لاستراتيجيات رأس المال التي تعمل بشكل مستمر بدلًا من كونها إجراءات منفصلة من المستخدم. فإذا ثبت أن العقود الخاصة بالمجمّع مفتوحة وقابلة للتدقيق (auditable) وقادرة على تسوية كل حركة توكن على السلسلة (on-chain)، فقد تتحول الآلية نفسها التي تبدو حاليًا غير شفافة إلى بدائية (primitive) متينة للمشاركة المنسقة.

عدتُ عبر صفحات المنتجات الحالية لـ Dusk، ووجدت نفسي أضع افتراضًا واسعًا واحدًا: بما أن الـ mainnet يعمل بالفعل، فقد تعاملت مع كامل المكدس المالي كما لو كان قد وصل إلى المرحلة نفسها. لكن تسميات الحالة غيّرت ذلك التصور.

Dusk L1 يعمل، ويوفر الإجماع والتسوية وتوافر البيانات والمعاملات العامة والمشفّرة، وتنفيذ DuskVM. لا تزال DuskEVM على الـ testnet، حيث تستخدم تطبيقات Solidity أدوات EVM المألوفة وDUSK للغاز، بينما تتم التسوية عبر DuskDS. كذلك فـ hedger موجود أيضًا على الـ testnet، مضيفًا تدفقات EVM سرّية. وما يزال Dusk Trade قيد الإنشاء كطبقة المنتج لعمليات الإلحاق (onboarding)، والتحكم بالوصول، والتداول، وتنسيق المدفوعات، والتسوية.

هذا جعلني أنظر إلى الأمر بشكل مختلف.

تفسيري: لدى Dusk قاعدة تعمل بالفعل، لكن أطروحته المالية الأوسع تعتمد على عدة طبقات متحركة لتصبح جاهزة للإنتاج في الوقت نفسه. إن وجود L1 آمن لا يثبت تلقائيًا أن طبقة EVM ومحرك الخصوصية والجسر وتطبيق المستخدم ستعمل معًا كسير عمل سوقي موثوق.

عدم يقيني يتعلق بخطر التكامل. ما شروط الإصدار والتدقيق التي ستنقل DuskEVM وHedger من الـ testnet إلى الـ mainnet؟ وإذا كان Dusk Trade يعتمد على تلك الطبقات، فكيف سيتم تنسيق التحديثات أو حالات الفشل دون مقاطعة الأهلية أو التداول أو التسوية؟

أريد أن أراقب ذلك على أرض الواقع.

#dusk $DUSK @Dusk

سأبقي الأمر صريحًا هنا: ما لفت انتباهي حول DuskEVM لم يكن مجرد التوافق مع EVM بحد ذاته، بل كيف يمكن لهذا التوافق أن يوسّع المنفعة الحقيقية لـ Dusk.

حاليًا، DuskEVM موجود على الشبكة التجريبية (testnet). فهو يمنح مطوري Solidity محافظًا ومكتبات وأدوات Foundry وHardhat مألوفة، مع استخدام DUSK كرمز الغاز الأصلي (gas) . يتم تنفيذ المعاملات على DuskEVM، بينما تُنشر الحزم (batches) والتعهدات بالحالة (state commitments) على DuskDS بهدف إتاحة البيانات وتسوية العمليات. عمليًا، يمكن أن يؤدي انخفاض الاحتكاك في الأدوات إلى جذب المزيد من البنّائين؛ ويمكن للتطبيقات المفيدة أن تُنتج المزيد من المعاملات؛ وتلك المعاملات تتطلب DUSK للتنفيذ. وبشكل منفصل، فإن رهن DUSK يساعد على تأمين شبكة Dusk الأوسع.

لكن التوافق لا يؤدي تلقائيًا إلى سيولة DEX أو طلب على الاقتراض (lending) أو TVL أو إيرادات. ما زال على البنّائين توفير بنية تحتية موثوقة ومنتجات يعود إليها الناس. هنا يأتي دور Dusk Trade في تنفيذ الاستراتيجية: يتم بناؤه كطبقة التطبيقات للأصول المالية المُرمّزة (tokenized)، لربط عملية استقبال المستخدمين (onboarding) والتداول وتنسيق المدفوعات والتسوية.

رأيي بسيط: تصبح منفعة DUSK ذات معنى عندما يتحول تطوير الشبكة التجريبية إلى استخدام متكرر على الشبكة الرئيسية (mainnet). يمكن للآلية أن تدعم الطلب، لكن لا يزال يتعين كسب التبنّي.

#dusk $DUSK @Dusk

#dusk $DUSK
لقد عدتُ الليلة إلى وثائق @Dusk ، ووجدت نفسي أتعامل مع “finalized” على أنها لحظة واحدة فقط. افترضت أنه بمجرد أن تُصبح معاملة على Dusk نهائية، يجب أن تكون الأموال موجودة فورًا على DuskEVM. جعلت الوثائق هذا الافتراض أبسط مما ينبغي.

على شبكة DuskEVM الاختبارية، يتم تقديم الإيداع وتأكيده (finalized) على Dusk L1، ثم تتم معالجته قبل أن تصبح الموازنة متاحة على DuskEVM. وللسحب مراحل أكثر: البدء على DuskEVM، ثم انتظار الإخراج (output)، ثم إثباته على Dusk L1، وبعد ذلك اجتياز فحوصات النضج المطلوبة وفحوصات “dispute-game”، ثم تأكيده على L1. تحذّر التوثيقات بأن الإتاحة/الإدراج (inclusion) والتنفيذ (execution) والنهائية (finality) ليست حالات متطابقة، وأن الجاهزية ينبغي أن تأتي من حالة البروتوكول بدلًا من مرور الوقت.

هذا جعلني أنظر إلى الأمر بشكل مختلف.

تفسيري: الجسر ليس مجرد تأخير يُخفي شيئًا؛ بل يحاول تحويل آلة حالة (state machine) عبر الطبقات إلى شيء يمكن للمحفظة شرحه. التوتر هنا بين الأمان والاعتماد التشغيلي. تُقلّل محاولات إعادة المحاولة الأكثر أمانًا واسترجاع/استعادة التراجع (rollback recovery) وفحوصات التحدّي من نوع واحد من الأعطال، لكن مسارات الاستعادة أيضًا تُركز المسؤولية في مكانٍ ما.

عدم يقيني: أثناء حدوث تراجع (rollback) مع فشل المُرحِّل (relayer)، ماذا يمكن للمستخدم التحقق منه بشكل مستقل قبل تحرير الأموال أو إعادة المحاولة؟ من الذي يمكنه إيقاف عمليات الجسر أو استئنافها، وما حدود تلك الصلاحية إذا طال الطوارئ أكثر مما كان متوقعًا؟

أريد أن أراقب هذا عمليًا.

#termmax @TermMax

عدت الليلة إلى وثائق TermMax بتفسير أولي واحد: أن سعره الثابت جاء بالدرجة الأولى من قفل قرض حتى تاريخ الاستحقاق. غيّرت الآليات هذا التصور.

FT هو مطالبة قابلة للاستبدال بسعر قابل للتداول (fungible) من نوع ERC-20، ويمكن استردادها مقابل رمز دين واحد عند الاستحقاق. XT هو مكمّلها القابل للتداول: 1 FT + 1 XT يساوي رمز دين واحد، ويمضي XT إلى الصفر عند الاستحقاق. GT هو موضع ERC-721 يسجل ضمان الرهن والديْن الخاصين بقرض فردي. ويمكن أيضًا بيع FT قبل الاستحقاق بسعر السيولة المتاحة آنذاك وبمعدلها.

أمر النطاق (range order) هو سلسلة من أوامر متواصلة تم تكوينها بواسطة مُعيّن أو قيّم. يُوزّع منحنى التسعير المجزأ السيولة عبر نطاقات APR، لذلك يتغير معدل ما يحصل عليه المتلقي (taker) مع انتقال الصفقات عبر المنحنى.

هذا جعلني أنظر إليه بشكل مختلف.

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

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

أريد مراقبة ذلك عمليًا.

#dusk $DUSK @Dusk
بدأتُ في البداية الاقتراب من توثيق Dusk بفهمٍ بسيط: إن ترميز السند أو الصندوق يتعلّق أساسًا بتسجيل الملكية في عقدٍ ذكي. ما غيّر منظوري هو إدراكي أن التعقيد الحقيقي يكمن في النظام البيئي المحيط بالرمز—إذ يجب أن تتوافق القواعد المتعلقة بالأهلية والتحويلات والتعامل مع البيانات الخاصة والمدفوعات والتسوية والخدمات المستمرة.

يعالج Dusk ذلك عبر توزيع المسؤوليات عبر معماريته. يقوم DuskVM بتنفيذ عقود Rust وWebAssembly مباشرةً على الطبقة الأولى. يتيح DuskEVM لتطبيقات تعتمد Solidity الاستفادة من أدوات EVM المألوفة، بينما تمضي الدفعات وبيانات ميتاداتا المعاملة والالتزامات بالحالة نحو التسوية النهائية عبر DuskDS. ويستخدم Citadel بيانات الاعتماد وإثباتات المعرفة الصفرية لتمكين المستخدمين من إثبات امتلاكهم لرخصةٍ مُعتمدة دون الكشف عن المعلومات الشخصية أو التفاصيل الكاملة للرخصة على السلسلة؛ ومع ذلك يظل مزودو الخدمة محتفظين بالتحكم في أي المُصدرين والسمات التي يوافقون على التعرف عليها.

غيّر هذا طريقة رؤيتي للنظام.

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

أنا متحمّس لرؤية كيف ستتجلى هذه الأمور في الاستخدام الواقعي.

#termmax @TermMax

قضيت جزءًا من الليلة الماضية في تتبّع سوق TermMax من التوثيق إلى كود العقد. كان تفسيري الأول أن FT وXT وGT ثلاث تسميات لقرض واحد. FT هي ERC-20 يتم شراؤها بأقل من القيمة الاسمية، ويمكن استردادها بالقيمة الاسمية في رمز الدين عند الاستحقاق، وقابلة للتداول قبل ذلك. XT هي ERC-20 تمثل التزام الفائدة؛ القيمة الحالية المجمعة لـ FT وXT تساوي مبلغ القرض الأولي. GT هي ERC-721 تمثل مركز الاقتراض وتُسجل الضمان والديْن.

الترتيب بنطاق هو سلسلة من أوامر متصلة يُعدّلها مُعيّن أو قيم. يتم بناء منحنى التسعير من مقاطع بحد أقصى لسعر الفائدة السنوية (APR) وحد أدنى لـ XT، ويمكن لسوق واحد أن يحتوي على أوامر نطاق متعددة.

هذا جعلني أنظر إليه بشكل مختلف.

يعرّف ورقة التصميم نسبة الوقت على أنها الأيام حتى الاستحقاق مقسومة على 365. تقوم عقود V2 بحساب الأيام المتبقية وتمرير هذه القيمة إلى منطق المنحنى والتبديل بين FT وXT.

تفسيري هو أن المعدل الذي يراه المستخدم يعكس موضع المنحنى وحركة احتياطي XT والزمن. ماذا يحدث لخروج FT عندما تكون السيولة موجودة في بضع مقاطع فقط؟ أثناء ضغوط السوق، كيف تتفاعل آلية الرجوع للاحتياطي الخاصة بالأوراكل (oracle fallback)، وانزلاق DEX، وقدرة التصفية (liquidation capacity)؟ وكيف ينبغي تقسيم الصلاحيات بين القيمين (curators) والوصّيين (guardians) والمديرين (admins) وحوكمة الرموز (token governance)؟

أريد أن أراقب هذا عمليًا.

#termmax @TermMax
لقد قضيت سنوات في مراقبة التمويل اللامركزي (DeFi) وسعيه وراء تحقيق العائد، وأجد وعد الأسواق ذات السعر الثابت جذابًا. لقد رأيت كثيرًا من الدورات التي جاء فيها وعد “المال السهل” على حساب شيء أكبر: توكن خصم صفري (zero-coupon) يحدد مطالبة عند الاستحقاق، وليس مخرجًا سهل التحويل أو التحقيق.

أمر ما في تصميم TermMax جذب انتباهي في سياق أوامر النطاق (range orders)، حيث يتم التسعير بمعدل على طول منحنى، والأوامر الذرّية (atomic orders) التي تمتد عبر أسواق متعددة عبر مشاركةٍ لمجمع (pool)، وبحث Smart Unwind عن السيولة لفكّ/تحويل مركز دين (debt position)، والتحدي المتمثل في تشتت السيولة عبر الضمانات والأزمنة/الاستحقاقات. تعالج عناصر التصميم هذه كلّها مخاطر نقص السيولة عند الخروج (exit)، لكن مقابل ذلك تقلّ تاحة السيولة في أي لحظة. تبقى حاجة إلى طرفٍ مقابل لشراء الالتزام في أي وقت محدد، وقد لا يكون هذا الطرف المقابل متاحًا دائمًا، مما يؤدي إلى انزلاق (slippage) أو تأخيرات أو حتى غياب تام للسوق. تعترف وثائق Alpha الخاصة بـ TermMax بذلك صراحةً إذ تنص على أن السيولة ليست مضمونة.

أجد نفسي أتساءل إن كان وعد الإقراض بسعر ثابت ليس هو مصدر الخطر بحد ذاته، بل إنه ببساطة ينقل المشكلة إلى مكان آخر. إن التسليم المادي للضمان هو ما يستند إليه أي التزام، لكن قيمة الضمان قد تتبين أنها أقل من قيمة الالتزام المستحق إذا كان المقرض غير قادر على تسليم الأصل/الأصل المحدد الذي تم الوعد به وقت التصفية (liquidation). التدقيقات (audits)، والكود المفتوح (open code)، وبرامج المكافآت (bounty programs) كلها أمور مفيدة، لكنها لا تُلغي مخاطر فشل العقد (contract failure) أو الأوراكل (oracles) أو تشتت السوق (market fragmentation). من خلال تثبيت الأسعار، يقلل TermMax من خطر “صدمة الأسعار” (rate shocks) لكنه لا يقلل من خطر “صدمة السيولة” (liquidity shocks). هذه هي المقايضة التي أستعد لقبولها باسم تحقيق العائد (yield).

في الليلة الماضية، أعدتُ زيارة وثائق Dusk، وركزت على فهم الدور الفعلي الذي يلعبه $DUSK داخل البروتوكول—وظيفته التقنية لا القصة التي تُحرّكها السوق.

أول شيء كان عليّ فكه هو نموذجَي المعاملات في DuskDS. Moonlight هو المسار المألوف: حسابات عامة، أرصدة مرئية، المرسل، المستلم، المبلغ. أما Phoenix فيعمل باستخدام “ملاحظات” مشفّرة. ولإنفاق واحدة، يزوّد المستخدمُ برهانًا ذا معرفة معدومة يثبت أن قواعد الملكية والرصيد صحيحة. تخيّل أنك تسلّم موظفًا ظرفًا مختومًا، ويُثبت الختم أن كل الخانات المطلوبة قد تم استيفاؤها، دون كشف المحتويات. عندها يسمح مُبطِّل (nullifier) للشبكة برفض الإنفاق الثاني دون تحديد أي ملاحظة من الشجرة العامة تم استخدامها. قرأت هذه الفقرة مرتين—ثم انتزعني إشعار منها—لأن الخصوصية لا تعني “لا شيء يتم التحقق منه”. بل تعني أن الشبكة تتحقق من برهان بدلاً من تفاصيل المعاملة المخفية. ويمكن لمفاتيح العرض (Viewing keys) كشف معلومات بشكل انتقائي.

أخذ الإجماع أيضًا جولة أخرى. لدى Dusk يُسمّى Succinct Attestation: يقوم أصحاب المصلحة (stakers)، أو المُوفِّرون (provisioners)، بإقفال DUSK؛ ثم تُختار كتلة مقترحًا بشكل حتمي وبترجيح وزن الحصة. بعد ذلك تتحقق لجنة واحدة، ثم لجنة أخرى تُصدّق. تصبح التواقيعات المجمّعة بمثابة إشهاد بأن النصاب قد وافق. هكذا فإن $DUSK هو الياجَاز (gas) والحصة الداعمة للمشاركة.

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

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

#termmax @TermMax

عدتُ الليلة الماضية إلى توثيق TermMax. كان تفسيري الأول أن النظام لا يَقفل سوى سعر إقراض ويُصدر إيصالًا. يقول التوثيق إن FT هو رمز ERC-20 يتم شراؤه بسعر أقل من القيمة الاسمية ويمكن استرداده مقابل رمز دين واحد عند الاستحقاق. XT هو رمز ERC-20 الذي يمثل التزام الفائدة؛ إن القيم الحالية لـ FT وXT تساوي مبلغ القرض الأولي. أما GT فهو رمز ERC-721 يسجل الضمان والدين لمركز اقتراض واحد.

تجمع أوامر النطاق بين أوامر متتابعة يتم إعدادها بواسطة مُعيّن أو مُقيم للأوامر. يحتوي منحنى تسعيره على مقاطع بحدٍ أعلى لمعدل العائد السنوي APR وحدٍ أدنى لـ XT. ومع تغيّر احتياطي XT بسبب الصفقات، يتحرك السعر المطابق على طول المنحنى.

هذا جعلني أنظر إليه بشكل مختلف.

تستخدم الورقة البيضاء نسبة الوقت عبر قسمة الأيام حتى الاستحقاق على 365؛ بينما تستخدم العقود الأيام المتبقية في حسابات المنحنى. يمكن أيضًا بيع FT قبل الاستحقاق. قراءتي هي أن الخروج المبكر يعتمد على توفر التسعير والسيولة، وليس على الاسترداد عند الاستحقاق وحده.

تفسيري هو أن تحديد السعر يتم التعبير عنه عبر وضع السيولة. كيف يتصرف التنفيذ عندما تَضعف سيولة FT أو عندما تكون معظم السيولة محصورة في مقطع واحد؟ أثناء ضغوط السوق، كيف يتفاعل فشل التبديل (failover) للأوراكل وسيولة DEX وقدرة التصفية ومعلمات البروتوكول؟ كم مقدار التحكم الذي يحتفظ به المُقيمون والأدوار الإدارية؟

أريد مشاهدة ذلك عمليًا.

#dusk $DUSK @Dusk
عدتُ الليلة إلى وثائق Dusk لأن عبارة "DeFi منظَّم" سهلة القول، لكنها أصعب في تخيّلها كنظام.

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

ساعدني الانقسام بين DuskVM وDuskEVM. يشغّل DuskVM عقود Rust/WASM على L1؛ ويمكّن DuskEVM تطبيقات Solidity من نشر البيانات والتسوية عبر DuskDS. قراءتي أن أحد المسارين أقرب لأدوات الخصوصية الأصليّة لدى Dusk، بينما يقلّل الآخر عائق الدخول أمام مطوري Ethereum.

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

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

أين تقع أكبر افتراضات الأمان؟ وهل يمكن أن تتعايش الخصوصية والرقابة التنظيمية والحياد الموثوق دون أن يهيمن أحدها على الآخرين؟

عاجل: 🇺🇸 سجّلت ميلانيا ترامب الآن أدنى نسبة تأييد لزوجة رئيس في تاريخ الولايات المتحدة، لتصل إلى -12.

على مدار العام، قامت بـ 38 ظهورًا علنيًا فقط، ولم تُرَ في الأماكن العامة منذ حضورها نهائي كأس العالم لكرة القدم في 19 يوليو.

#SECCancelsCryptoRulemakingMeeting
#SP500TopsRecord7800

قامت منصة Binance بجدولة صيانة محفظة شبكة BNB Smart Chain (BEP20) بتاريخ 20 أغسطس 2026، الساعة 06:00 بالتوقيت العالمي المنسق (UTC). سيتم تعليق الإيداعات والسحوبات عبر الشبكة بدءًا من الساعة 05:55 بالتوقيت العالمي المنسق (UTC)، ومن المتوقع أن تستمر أعمال الصيانة لمدة تقارب ساعة واحدة.

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

قد يرغب أي شخص يخطط لنقل أصول BEP20 عبر Binance في إتمام العملية قبل بدء فترة التعليق لتجنب أي تأخيرات محتملة.

أعتقد أنه خلال الأشهر الستة إلى الاثني عشر القادمة:

$BTC : $100K - $150K

آخر مرة كانت فيها تقلبات البيتكوين بهذا الانخفاض في سوق هابطة كانت في عام 2022.

$BTC كان في مرحلة التماسك عند القاع ثم اندفع بشكل صاروخي بعد ذلك بقليل.

شيء كبير قادم…

#SP500TopsRecord7800
#CardanoSplitsDijkstraUpgradeIntoTwoPhases
#SECReviewsSix3xLeveragedCommodityETFs

🇺🇸 البيت الأبيض يعقد أكثر اجتماع مهم للعملات المشفرة على الإطلاق هذا الأسبوع!

بحضور الرئيس ترامب، ورئيس هيئة الأوراق المالية والبورصات (SEC) أتكينز، ورئيس لجنة تداول السلع الآجلة (CFTC) سيليج، وشركات العملات المشفرة Coinbase وRipple وGemini وPolymarket وKalshi وNasdaq وNYSE وCME وDTCC، وغيرهم. ومع ذلك، فإن أكثر التفاصيل لفتًا للانتباه هو الاسم الأخير في تلك القائمة!

DTCC هي الجهة التي تسوي معظم صفقات الأسهم في أمريكا. لماذا يتم التشاور معها بشأن التشريعات إذا كانت تقوم بالفعل بإتمام عمليات التسوية؟ الاستنتاج الوحيد المنطقي هو أن الرئيس ترامب قد أذن ببدء التنفيذ. هذا التطور بالغ الأهمية لدرجة أنه لا يحتاج إلى تفعيل قانون CLARITY.


#IsraelStrikesLebanonKillsHezbollahCommander
#SP500TopsRecord7800
#SP500EarningsBeatExpectations
#USToPressNationsToPickUSOrChinaAICoalition

سوق العملات الرقمية لا ينام أبداً! إليك أهم الملاحظات في الوقت الحالي:
$BTC تواصل الحفاظ على مستوى دعمها الحرج
$ETH تُظهر مؤشرات على زيادة النشاط على السلسلة,
ويبدو أن العملات البديلة تستقر استعداداً لانفراج وشيك.

ما الذي تلاحظه في السوق هذه الأيام؟

#Bitcoin #Ethereum
#IsraelStrikesLebanonKillsHezbollahCommander
#CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECReviewsSix3xLeveragedCommodityETFs

#dusk $DUSK @Dusk

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

لفت انتباهي شيء عن Dusk. في حين تقدم Phoenix عمليات نقل مُشفّرة مدعومة بالملاحظات، بينما تحافظ Moonlight على مسار حساب عام. والأكثر إثارة للاهتمام هو ما يوجد فوق طبقة الدفع نفسها. صُممت عقود Dusk وطبقة الهوية بحيث يمكن لتطبيق ما التحقق من الأهلية، وفرض شروط التحويل أو التسوية، والإفصاح عن حقائق محددة لجهة مُصدِرة أو مُدقِّق دون نشر كل شيء.

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

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

#dusk $DUSK ما المعضلة البالغة التعقيد في عالم البلوك تشين؟

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

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

ترفض شبكة Dusk هذا الاختيار الزائف.

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

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

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

ليست هذه مجرد نظرية من ملف PDF.

في 7 يناير 2026، تشتعل شبكة Dusk الرئيسية. يتم تشغيل DuskEVM. يا مطوري Solidity، أدواتكم جاهزة.

باستخدام NPEX، وهي بورصة هولندية مُرخّصة، ستُدخل Dusk مئات الملايين من الأوراق المالية المُرمّزة على السلسلة. أصول حقيقية. نطاق حقيقي.

وبالتعاون مع Quantoz Payments، أنشأت EURQ، اليورو الرقمي للمال الإلكتروني الملتزم بمعايير MiCA. مُرسَخ وواقعي.

عارٍ جدًا. مظلم جدًا.

تقول Dusk: اختر النور، اختر الظل. أخفِ ما يجب أن يبقى مخفيًا. اكشف ما يجب أن يُرى. ليست معادلة. إنها سيطرة.
@Dusk

#dusk $DUSK
لقد لاحظتُ أن كلما قضيتُ وقتًا أطول في استخدام سلاسل الكتل الشفافة، كلما بدا مفهوم “الشفافية” أكثر تعقيدًا.

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

وهذا ما يجعل @Dusk مثيرًا للاهتمام بالنسبة لي.

لا يكتفي “ديڤسك” بجعل كل شيء خاصًا. بل إن بنيته المعمارية تتيح نماذج رؤية مختلفة. “Moonlight” شفّافة ومبنية على الحساب، بينما “Phoenix” تتيح عمليات نقل UTXO مُحصّنة. في معاملات “Phoenix”، تكون هوية المرسل والمستلم والمبلغ المُحوَّل مخفية عن عامة الناس، بينما يمكن للأطراف المعنية وحاملي مفتاح العرض المناسب الوصول إلى المعلومات ذات الصلة.

إذن، الفكرة المهمة ليست “الخصوصية مقابل الشفافية”. بل هي قابلية برمجة الرؤية.

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

ولا تقف إيثريوم ساكنة أيضًا. تواصل تقنيات الخصوصية التطور هناك، وحتى أن عمليات ZK-rollups لا ينبغي التعامل معها تلقائيًا كنُظم معاملات خاصة، لأن دورها الأساسي هو التوسع عبر إثباتات الصحة.

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

قد تكون هذه الحدود أكثر أهمية لتبنّي المؤسسات من مجرد جعل كل معاملة علنية.

#dusk $DUSK
لقد لاحظت أن أصعب جزء في جلب الأصول الواقعية إلى البلوك تشين ليس عملية التحويل إلى توكنات. بل ما يحدث بعد وصول الأصول.

الأسواق المنظمة تتطلب التحقق من الهوية، والقيود على التحويل، وقابلية التدقيق، والخصوصية التجارية. تعتمد التمويلات اللامركزية على بنية تحتية مفتوحة وقابلية التركيب. إن جعل تلك الأنظمة تتعايش دون أن يقوض ذلك متطلباتها الأساسية هو التحدي الحقيقي—وهو ما يجعل من الجدير فحص @Dusk وDusk Trade.

يتم بناء Dusk Trade كطبقة تطبيق للأصول المالية المُمَثلة بتوكنات، مع تدفقات عمل تشمل استقبال المستثمرين، وربط المحافظ، والتحويلات الخاضعة للرقابة، وتنسيق المدفوعات، وتسوية متوافقة.

تحت ذلك، تجمع شبكة Dusk الحية بين الحسم الحتمي مع نماذج معاملات موجهة للخصوصية وإمكانيات الكشف الانتقائي. توفر DuskEVM، وهي حاليًا على شبكة اختبار، بيئة متوافقة مع Solidity متصلة ببنية تسوية Dusk.

وتم تصميم Hedger، أيضًا على شبكة اختبار، لإتاحة تدفقات عمل EVM سرّية عبر التشفير المتماثل (homomorphic encryption) وإثباتات المعرفة الصفرية. الهدف هو الحفاظ على سرية الأرصدة الحساسة وتفاصيل المعاملات مع الحفاظ على قابلية التحقق من التنفيذ والمراجعة المصرّح بها.

يربط شراكة NPEX هذه الأطروحة بالبنية التحتية الأوروبية المنظمة. ومع ذلك، فإن الشراكة المنظمة ليست موافقة على النموذج الكامل على السلسلة، وتقنية شبكة الاختبار ليست تسوية إنتاجية.

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

تقوم DUSK بالفعل بالدفع مقابل التنفيذ، وتدعم الرهن (staking) وتساعد في تأمين النظام البيئي. غير المبرهن حتى الآن هو ما إذا كانت النشاطات المالية الحية ستخلق طلبًا مستدامًا على نطاق واسع.

سأتابع التقدم التنظيمي، والإصدار المباشر، وحجم التسوية، والاستخدام المؤسسي المتكرر—لا الأهداف الترويجية.

هل يمكن للضوابط المنظمة وقابلية تركيب DeFi أن تتعايش حقًا على نطاق واسع؟