Dr Roosh
233 منشورات
Dr Roosh
إبلاغ
حظر المُستخدم
35 تتابع
14 المتابعون
78 إعجاب
منشورات
PINNED
·
--
#dusk $DUSK @Dusk_Foundation
قرأت «الأوراق المقطّعة» لـ Dusk، وبينما كنت أتابع سطرًا بعد سطر توقف عندي ما يلي: لا تتم إعادة ضبط التحذيرات والأخطاء إلا عندما يكسب مُقدِّم الخدمة مكافأة — أي أنه أنتج فعلاً أو صوّت على كتلة. لا يوجد مؤقّت. ولا يوجد تلاشي تلقائي. المشاركة فقط هي التي تمحو السجل.
عمليات اللطم اللطيفة على $DUSK SK لا تحرق الرصيد. فالخطأ ينقل جزءًا منه إلى مجمع المكافآت ويقلّص الحجم الفعلي للعقدة، ما يخفض فرص اختيارها في اللجنة التالية. لذلك يحتاج المُقدِّم المُعاقَب إلى أن يتم اختياره مرة أخرى لإعادة ضبط أخطائه — لكن العقوبة هي نفسها ما يجعل الاختيار أقل احتمالًا من البداية.
وهذا هو الجزء الذي لم أكن قد انتبهت إليه. ليست المسألة فقط «العُقد السيئة تُعاقَب». بل هو نظام يتطلب التعافي من خلال نفس الباب الذي أصبح أصعب في الدخول. #dusk يقدّمه على أنه يحمي الاعتمادية، ومن الناحية الميكانيكية يفعل ذلك — إذ تُهمَّش المتأخرات، ويُكافَأ وقت التوفر. لكن طريق العودة يعتمد كليًا على أن يتم اختياره مرة أخرى، لا على الانتظار حتى يمر الوقت.
جدير بالتدقيق: كم عدد الـ epochs عادةً التي يحتاجها مُقدِّم خدمة معلّق على @Dusk_Foundation ليعود إلى لجنة نشطة بعد خطأ واحد.
#dusk $DUSK @Dusk
قرأت «الأوراق المقطّعة» لـ Dusk، وبينما كنت أتابع سطرًا بعد سطر توقف عندي ما يلي: لا تتم إعادة ضبط التحذيرات والأخطاء إلا عندما يكسب مُقدِّم الخدمة مكافأة — أي أنه أنتج فعلاً أو صوّت على كتلة. لا يوجد مؤقّت. ولا يوجد تلاشي تلقائي. المشاركة فقط هي التي تمحو السجل.
عمليات اللطم اللطيفة على $DUSK SK لا تحرق الرصيد. فالخطأ ينقل جزءًا منه إلى مجمع المكافآت ويقلّص الحجم الفعلي للعقدة، ما يخفض فرص اختيارها في اللجنة التالية. لذلك يحتاج المُقدِّم المُعاقَب إلى أن يتم اختياره مرة أخرى لإعادة ضبط أخطائه — لكن العقوبة هي نفسها ما يجعل الاختيار أقل احتمالًا من البداية.
وهذا هو الجزء الذي لم أكن قد انتبهت إليه. ليست المسألة فقط «العُقد السيئة تُعاقَب». بل هو نظام يتطلب التعافي من خلال نفس الباب الذي أصبح أصعب في الدخول. #dusk يقدّمه على أنه يحمي الاعتمادية، ومن الناحية الميكانيكية يفعل ذلك — إذ تُهمَّش المتأخرات، ويُكافَأ وقت التوفر. لكن طريق العودة يعتمد كليًا على أن يتم اختياره مرة أخرى، لا على الانتظار حتى يمر الوقت.
جدير بالتدقيق: كم عدد الـ epochs عادةً التي يحتاجها مُقدِّم خدمة معلّق على @Dusk ليعود إلى لجنة نشطة بعد خطأ واحد.
قرأت «الأوراق المقطّعة» لـ Dusk، وبينما كنت أتابع سطرًا بعد سطر توقف عندي ما يلي: لا تتم إعادة ضبط التحذيرات والأخطاء إلا عندما يكسب مُقدِّم الخدمة مكافأة — أي أنه أنتج فعلاً أو صوّت على كتلة. لا يوجد مؤقّت. ولا يوجد تلاشي تلقائي. المشاركة فقط هي التي تمحو السجل.
عمليات اللطم اللطيفة على $DUSK SK لا تحرق الرصيد. فالخطأ ينقل جزءًا منه إلى مجمع المكافآت ويقلّص الحجم الفعلي للعقدة، ما يخفض فرص اختيارها في اللجنة التالية. لذلك يحتاج المُقدِّم المُعاقَب إلى أن يتم اختياره مرة أخرى لإعادة ضبط أخطائه — لكن العقوبة هي نفسها ما يجعل الاختيار أقل احتمالًا من البداية.
وهذا هو الجزء الذي لم أكن قد انتبهت إليه. ليست المسألة فقط «العُقد السيئة تُعاقَب». بل هو نظام يتطلب التعافي من خلال نفس الباب الذي أصبح أصعب في الدخول. #dusk يقدّمه على أنه يحمي الاعتمادية، ومن الناحية الميكانيكية يفعل ذلك — إذ تُهمَّش المتأخرات، ويُكافَأ وقت التوفر. لكن طريق العودة يعتمد كليًا على أن يتم اختياره مرة أخرى، لا على الانتظار حتى يمر الوقت.
جدير بالتدقيق: كم عدد الـ epochs عادةً التي يحتاجها مُقدِّم خدمة معلّق على @Dusk ليعود إلى لجنة نشطة بعد خطأ واحد.
2
1
369
·
--
عندما تتبعت أين يحدث نشاط Shiba Inu فعليًا، بدا لي أن المنظومة التي ظللت أقرأ عنها والمكان الذي أستطيع استخدامه فيه هما مكانان مختلفان. توصف Shiba Inu بأنها شبكة آخذة في النمو، تضم Shibarium وخدمة أسماء وعالمًا افتراضيًا وحرقًا للرموز، لكن المسار الذي اتبعته كان ينتهي دائمًا عند الشيء نفسه: أشخاص يشترون ويحتفظون ويراقبون $SHIB . وكان خيار التصميم الوحيد الذي ظل عالقًا في ذهني هو الحرق. يُقدَّم الحرق على أنه وسيلة لتقليل المعروض، لكنه لا يُولّد طلبًا إلا إذا أنفق أحدهم SHIB على شيء يؤدي إلى حرقه، ومعدل الحرق الذي رأيته كان مدفوعًا في معظمه بتحويلات صغيرة وعمليات حرق نظمتها المجتمعات، لا بأشخاص يدفعون مقابل خدمة. يتحدث حاملو #ShibaInu عن الندرة أكثر مما يتحدثون عن أي شيء قد يستخدمون الرمز من أجله. ويشير @Shibtoken-1 إلى المطورين والتطبيقات، وهما موجودان بالفعل، لكنني واجهت صعوبة في العثور على موقف تكون فيه الحاجة إلى الرمز فعلية، لا مجرد الاحتفاظ به. لا أريد التقليل من شأن المنظومة، فبناء شيء ما يستغرق وقتًا، والاستخدام في مراحله الأولى يكون محدودًا دائمًا. ومع ذلك، ظللت أتساءل عما إذا كان بإمكان رمز أن يحقق طلبًا يتجاوز المضاربة حين تكون ميزته الأبرز وعدًا بشأن السعر، وكيف سيبدو أول سبب حقيقي لإنفاقه.
عندما تتبعت أين يحدث نشاط Shiba Inu فعليًا، بدا لي أن المنظومة التي ظللت أقرأ عنها والمكان الذي أستطيع استخدامه فيه هما مكانان مختلفان. توصف Shiba Inu بأنها شبكة آخذة في النمو، تضم Shibarium وخدمة أسماء وعالمًا افتراضيًا وحرقًا للرموز، لكن المسار الذي اتبعته كان ينتهي دائمًا عند الشيء نفسه: أشخاص يشترون ويحتفظون ويراقبون $SHIB . وكان خيار التصميم الوحيد الذي ظل عالقًا في ذهني هو الحرق. يُقدَّم الحرق على أنه وسيلة لتقليل المعروض، لكنه لا يُولّد طلبًا إلا إذا أنفق أحدهم SHIB على شيء يؤدي إلى حرقه، ومعدل الحرق الذي رأيته كان مدفوعًا في معظمه بتحويلات صغيرة وعمليات حرق نظمتها المجتمعات، لا بأشخاص يدفعون مقابل خدمة. يتحدث حاملو #ShibaInu عن الندرة أكثر مما يتحدثون عن أي شيء قد يستخدمون الرمز من أجله. ويشير @Shibtoken إلى المطورين والتطبيقات، وهما موجودان بالفعل، لكنني واجهت صعوبة في العثور على موقف تكون فيه الحاجة إلى الرمز فعلية، لا مجرد الاحتفاظ به. لا أريد التقليل من شأن المنظومة، فبناء شيء ما يستغرق وقتًا، والاستخدام في مراحله الأولى يكون محدودًا دائمًا. ومع ذلك، ظللت أتساءل عما إذا كان بإمكان رمز أن يحقق طلبًا يتجاوز المضاربة حين تكون ميزته الأبرز وعدًا بشأن السعر، وكيف سيبدو أول سبب حقيقي لإنفاقه.
113
·
--
عندما نظرت إلى ما كان يشكّل نشاط Solana فعليًا خلال مهمة CreatorPad، أخذ الخط الفاصل بين استخدام الشبكة والتداول عليها يتلاشى. تُسوَّق Solana بوصفها سلسلة للمدفوعات والتطبيقات والمنتجات الاستهلاكية، لكن المعاملات التي استطعت تتبّعها بسهولة أكبر كانت عمليات مبادلة، وإطلاق عملات ميمية، وروبوتات توجّه الأوامر عبر مجمّعات منصات التداول اللامركزية. والسلوك الوحيد الذي ظل عالقًا في ذهني هو مدى انخفاض تكلفة كل إجراء: فرسم لا يتجاوز جزءًا من السنت يعني أن بإمكان الروبوت تنفيذ آلاف المحاولات، وتُحتسب كل واحدة منها ضمن النشاط. لذا، تعبّر أرقام الإنتاجية المعلنة عن السعة، ويملأ هذه السعة من يجد أن ملأها يدرّ عليه أكبر ربح. لا أعتقد أن هذا يجعل الاستخدام زائفًا، إذ لا يزال يُنفَق $SOL على كل واحدة من تلك المعاملات. لكن التكلفة المنخفضة نفسها التي تجعل #Solana مناسبة للمدفوعات تجعلها مناسبة جدًا للمضاربة أيضًا، ويبدو الاثنان متطابقين عند قياسهما بعدد المعاملات. يمكن لـ @Square-Creator-bd6246d0f618 القول إن الشبكة نشطة، وسيكون ذلك صحيحًا. وظللت أتساءل كيف تبدو السلسلة خلال أسبوع هادئ من ناحية الأسعار: هل سيتراجع النشاط، أم أن هناك شيئًا آخر تحته بالفعل لم أستطع رؤيته من موقعي؟
#sol
عندما نظرت إلى ما كان يشكّل نشاط Solana فعليًا خلال مهمة CreatorPad، أخذ الخط الفاصل بين استخدام الشبكة والتداول عليها يتلاشى. تُسوَّق Solana بوصفها سلسلة للمدفوعات والتطبيقات والمنتجات الاستهلاكية، لكن المعاملات التي استطعت تتبّعها بسهولة أكبر كانت عمليات مبادلة، وإطلاق عملات ميمية، وروبوتات توجّه الأوامر عبر مجمّعات منصات التداول اللامركزية. والسلوك الوحيد الذي ظل عالقًا في ذهني هو مدى انخفاض تكلفة كل إجراء: فرسم لا يتجاوز جزءًا من السنت يعني أن بإمكان الروبوت تنفيذ آلاف المحاولات، وتُحتسب كل واحدة منها ضمن النشاط. لذا، تعبّر أرقام الإنتاجية المعلنة عن السعة، ويملأ هذه السعة من يجد أن ملأها يدرّ عليه أكبر ربح. لا أعتقد أن هذا يجعل الاستخدام زائفًا، إذ لا يزال يُنفَق $SOL على كل واحدة من تلك المعاملات. لكن التكلفة المنخفضة نفسها التي تجعل #Solana مناسبة للمدفوعات تجعلها مناسبة جدًا للمضاربة أيضًا، ويبدو الاثنان متطابقين عند قياسهما بعدد المعاملات. يمكن لـ @Solana القول إن الشبكة نشطة، وسيكون ذلك صحيحًا. وظللت أتساءل كيف تبدو السلسلة خلال أسبوع هادئ من ناحية الأسعار: هل سيتراجع النشاط، أم أن هناك شيئًا آخر تحته بالفعل لم أستطع رؤيته من موقعي؟
#sol
#sol
125
·
--
تمّ التحقق
كنت جالسًا مع معيار Dusk XSC، والجزء الذي علِق في ذهني: الاستحقاق والتأهيل للإستيطان والتحويل طبقتان منفصلتان، وليستا طبقة واحدة. إن #dusk @Dusk's Phoenix/Moonlight rails يمنحان رمزًا أمنيًا بخصوصية تشفيرية حاسمة خلال ثوانٍ. لكن ما يزال تحويل XSC يحتاج إلى أن يتم مسح/تطهير محفظة الاستقبال بواسطة طبقة التحكم بالوصول الخاصة بالجهة المُصدِرة — لا يوجد تطهير، لا يوجد تحويل، بغض النظر عن الحسم الزمني.
هذا ليس مجرد وثائق تصميم قديمة. إطار عمل STO الخاص بـ Dusk في عام 2019 يصف الإتاحة بالاستثناء (whitelisting) بحيث يمكن للمُصدِرين إبقاء الأطراف غير المؤهلة خارج الدائرة حتى بعد إغلاق الطرح. والأكثر دلالة: موقع Dusk الحالي يذكر أن قاعدة الأصول المُدارة الكاملة لـ NPEX البالغة 300 مليون دولار+ تم تحويلها إلى رموز على Dusk الآن، تعمل ضمن "ضوابط وصول، خصوصية مع إفصاح انتقائي، حسم حتمي" كحزمة واحدة — ما يعني أن هذا الحاجز ليس افتراضًا، بل بنية تحتية تعمل فعليًا تحت أصول حقيقية.
ما الذي تغيّر بالنسبة لي؟ إدراك أن RWA المرمّزة على $DUSK SK لا تعني سيولة بلا إذن. بل تعني إذنًا قابلًا للبرمجة. السلسلة تقضي على احتكاك التسوية؛ لكنها لا تُزيل بوّابة الدخول، بل تمنح بوّابة الدخول أدوات أسرع.
الخطوة التالية التي أريد التحقق منها: هل قرار التحكم بالوصول على أصل مُصدر من NPEX على شبكة حية — الموافقة على محفظة أو حجبها — يُعد حدثًا يمكن استعلامه على السلسلة، أم أنه يظهر فقط كمعاملة تفشل، مع الاحتفاظ بالسبب/التبرير على خادم خارج السلسلة (off-chain).
#dusk
@Dusk_Foundation
كنت جالسًا مع معيار Dusk XSC، والجزء الذي علِق في ذهني: الاستحقاق والتأهيل للإستيطان والتحويل طبقتان منفصلتان، وليستا طبقة واحدة. إن #dusk @Dusk's Phoenix/Moonlight rails يمنحان رمزًا أمنيًا بخصوصية تشفيرية حاسمة خلال ثوانٍ. لكن ما يزال تحويل XSC يحتاج إلى أن يتم مسح/تطهير محفظة الاستقبال بواسطة طبقة التحكم بالوصول الخاصة بالجهة المُصدِرة — لا يوجد تطهير، لا يوجد تحويل، بغض النظر عن الحسم الزمني.
هذا ليس مجرد وثائق تصميم قديمة. إطار عمل STO الخاص بـ Dusk في عام 2019 يصف الإتاحة بالاستثناء (whitelisting) بحيث يمكن للمُصدِرين إبقاء الأطراف غير المؤهلة خارج الدائرة حتى بعد إغلاق الطرح. والأكثر دلالة: موقع Dusk الحالي يذكر أن قاعدة الأصول المُدارة الكاملة لـ NPEX البالغة 300 مليون دولار+ تم تحويلها إلى رموز على Dusk الآن، تعمل ضمن "ضوابط وصول، خصوصية مع إفصاح انتقائي، حسم حتمي" كحزمة واحدة — ما يعني أن هذا الحاجز ليس افتراضًا، بل بنية تحتية تعمل فعليًا تحت أصول حقيقية.
ما الذي تغيّر بالنسبة لي؟ إدراك أن RWA المرمّزة على $DUSK SK لا تعني سيولة بلا إذن. بل تعني إذنًا قابلًا للبرمجة. السلسلة تقضي على احتكاك التسوية؛ لكنها لا تُزيل بوّابة الدخول، بل تمنح بوّابة الدخول أدوات أسرع.
الخطوة التالية التي أريد التحقق منها: هل قرار التحكم بالوصول على أصل مُصدر من NPEX على شبكة حية — الموافقة على محفظة أو حجبها — يُعد حدثًا يمكن استعلامه على السلسلة، أم أنه يظهر فقط كمعاملة تفشل، مع الاحتفاظ بالسبب/التبرير على خادم خارج السلسلة (off-chain).
#dusk
@Dusk
هذا ليس مجرد وثائق تصميم قديمة. إطار عمل STO الخاص بـ Dusk في عام 2019 يصف الإتاحة بالاستثناء (whitelisting) بحيث يمكن للمُصدِرين إبقاء الأطراف غير المؤهلة خارج الدائرة حتى بعد إغلاق الطرح. والأكثر دلالة: موقع Dusk الحالي يذكر أن قاعدة الأصول المُدارة الكاملة لـ NPEX البالغة 300 مليون دولار+ تم تحويلها إلى رموز على Dusk الآن، تعمل ضمن "ضوابط وصول، خصوصية مع إفصاح انتقائي، حسم حتمي" كحزمة واحدة — ما يعني أن هذا الحاجز ليس افتراضًا، بل بنية تحتية تعمل فعليًا تحت أصول حقيقية.
ما الذي تغيّر بالنسبة لي؟ إدراك أن RWA المرمّزة على $DUSK SK لا تعني سيولة بلا إذن. بل تعني إذنًا قابلًا للبرمجة. السلسلة تقضي على احتكاك التسوية؛ لكنها لا تُزيل بوّابة الدخول، بل تمنح بوّابة الدخول أدوات أسرع.
الخطوة التالية التي أريد التحقق منها: هل قرار التحكم بالوصول على أصل مُصدر من NPEX على شبكة حية — الموافقة على محفظة أو حجبها — يُعد حدثًا يمكن استعلامه على السلسلة، أم أنه يظهر فقط كمعاملة تفشل، مع الاحتفاظ بالسبب/التبرير على خادم خارج السلسلة (off-chain).
#dusk
@Dusk
6
4
836
·
--
تمّ التحقق
تحديث ورقة Dusk البيضاء الخاصة به يحتوي على سطر لم أتوقعه: كان نموذج المعاملة المحمية (Phoenix) بروتوكول إخفاء هوية — يَحجب هوية المُرسِل حتى عن المُستلم. غيّرت Dusk ذلك. أضافت طريقةً للمُستلم لتحديد من أرسل معاملة Phoenix، وسمّتها انتقالًا من "السرّية" إلى "الخصوصية". $DUSK #dusk @Dusk_Foundation k فعلوا ذلك تحديدًا للبقاء ملتزمين بقواعد الاتحاد الأوروبي.
ما تغيّر بالنسبة لي: هذا ليس مجرد خيار واجهة (UI) أو ميزة اختيارية؛ إنه تراجع في الضمان الأساسي لنموذج الخصوصية الرائد. في السابق، لم يكن بإمكان أي أحد تتبّع من دفع لمن، حتى الشخص الذي يستلم الأموال. الآن، يستطيع المُستلم دائمًا. لقد بقيت صياغة "الخصوصية" في العلامة التجارية، لكن الخاصية الأساسية للإخفاء تحتها لم تعد موجودة.
إنها مفاضلة معقولة لسلسلة تستهدف المؤسسات الخاضعة للتنظيم. لكن هذا يعني أن سرّية Phoenix أضيق مما توحي به المواد التسويقية — فهي مخفية عن السجلّ العام، وليست عن طرفك المتعامل معه.
جدير بالتحقق: ما إذا كانت تحليلات الجهات الخارجية أو المحافظ تعرض بالفعل هوية المُرسِل من معاملات Phoenix في الواقع، أم أن هذه الإمكانية ما زالت موجودة لكنها غير مستخدمة.
تحديث ورقة Dusk البيضاء الخاصة به يحتوي على سطر لم أتوقعه: كان نموذج المعاملة المحمية (Phoenix) بروتوكول إخفاء هوية — يَحجب هوية المُرسِل حتى عن المُستلم. غيّرت Dusk ذلك. أضافت طريقةً للمُستلم لتحديد من أرسل معاملة Phoenix، وسمّتها انتقالًا من "السرّية" إلى "الخصوصية". $DUSK #dusk @Dusk k فعلوا ذلك تحديدًا للبقاء ملتزمين بقواعد الاتحاد الأوروبي.
ما تغيّر بالنسبة لي: هذا ليس مجرد خيار واجهة (UI) أو ميزة اختيارية؛ إنه تراجع في الضمان الأساسي لنموذج الخصوصية الرائد. في السابق، لم يكن بإمكان أي أحد تتبّع من دفع لمن، حتى الشخص الذي يستلم الأموال. الآن، يستطيع المُستلم دائمًا. لقد بقيت صياغة "الخصوصية" في العلامة التجارية، لكن الخاصية الأساسية للإخفاء تحتها لم تعد موجودة.
إنها مفاضلة معقولة لسلسلة تستهدف المؤسسات الخاضعة للتنظيم. لكن هذا يعني أن سرّية Phoenix أضيق مما توحي به المواد التسويقية — فهي مخفية عن السجلّ العام، وليست عن طرفك المتعامل معه.
جدير بالتحقق: ما إذا كانت تحليلات الجهات الخارجية أو المحافظ تعرض بالفعل هوية المُرسِل من معاملات Phoenix في الواقع، أم أن هذه الإمكانية ما زالت موجودة لكنها غير مستخدمة.
ما تغيّر بالنسبة لي: هذا ليس مجرد خيار واجهة (UI) أو ميزة اختيارية؛ إنه تراجع في الضمان الأساسي لنموذج الخصوصية الرائد. في السابق، لم يكن بإمكان أي أحد تتبّع من دفع لمن، حتى الشخص الذي يستلم الأموال. الآن، يستطيع المُستلم دائمًا. لقد بقيت صياغة "الخصوصية" في العلامة التجارية، لكن الخاصية الأساسية للإخفاء تحتها لم تعد موجودة.
إنها مفاضلة معقولة لسلسلة تستهدف المؤسسات الخاضعة للتنظيم. لكن هذا يعني أن سرّية Phoenix أضيق مما توحي به المواد التسويقية — فهي مخفية عن السجلّ العام، وليست عن طرفك المتعامل معه.
جدير بالتحقق: ما إذا كانت تحليلات الجهات الخارجية أو المحافظ تعرض بالفعل هوية المُرسِل من معاملات Phoenix في الواقع، أم أن هذه الإمكانية ما زالت موجودة لكنها غير مستخدمة.
5
2
1.5k
·
--
قضيتُ مساءً في مقارنة توثيق Dusk بما تبيّنه فعليًا سلوك إجماعها، والتفصيلة التي علِقت بي ليست طبقة الخصوصية — بل إن Dusk @Dusk_Foundation $DUSK #dusk يقوم بتقسيم توليد الكتل عن المصادقة/اعتماد الكتل إلى لجنتين منفصلتين بدل أن تقوم مجموعة واحدة من المدققين بالعملين معًا. تعامل معظم السلاسل مع الإجماع كدور واحد يرتدي قبّعتين. هنا يقوم المُولِّد بتحسين الإنتاجية، ويقوم المُصادِق بتحسين سلامة الوصول النهائي (finality)، وهدفان ليسا بالضرورة متوافقين تلقائيًا. ما لم أجد له جوابًا واضحًا، لا في الوثائق ولا في نشاط شبكة الاختبار، هو ماذا يحدث عندما تتعارض اللجنتان فعليًا — ليس أن أحد المدققين يتوقف عن العمل، بل انقسام حقيقي في الحكم بين التوليد والمصادقة. تبيّن المعمارية أن لديها مسارًا للحل مدمجًا، إذ لم تتوقف السلسلة تحت الظروف العادية، لكن عبارة "لم تتوقف حتى الآن" وعبارة "تُحلّ بشكل نظيف عند وجود خلاف عدائي" هما ادعاءان مختلفان. لا يكاد يُختبر هذا المسار في الاستخدام الحالي تقريبًا، لأن معظم النشاط ما زال خفيفًا وتعاونيًا. إنها مفاضلة تصميمية غير مرئية الآن ولا تصبح واضحة إلا عندما يختبرها أحدٌ تحت الضغط. أتساءل كيف يبدو ذلك عمليًا.
قضيتُ مساءً في مقارنة توثيق Dusk بما تبيّنه فعليًا سلوك إجماعها، والتفصيلة التي علِقت بي ليست طبقة الخصوصية — بل إن Dusk @Dusk $DUSK #dusk يقوم بتقسيم توليد الكتل عن المصادقة/اعتماد الكتل إلى لجنتين منفصلتين بدل أن تقوم مجموعة واحدة من المدققين بالعملين معًا. تعامل معظم السلاسل مع الإجماع كدور واحد يرتدي قبّعتين. هنا يقوم المُولِّد بتحسين الإنتاجية، ويقوم المُصادِق بتحسين سلامة الوصول النهائي (finality)، وهدفان ليسا بالضرورة متوافقين تلقائيًا. ما لم أجد له جوابًا واضحًا، لا في الوثائق ولا في نشاط شبكة الاختبار، هو ماذا يحدث عندما تتعارض اللجنتان فعليًا — ليس أن أحد المدققين يتوقف عن العمل، بل انقسام حقيقي في الحكم بين التوليد والمصادقة. تبيّن المعمارية أن لديها مسارًا للحل مدمجًا، إذ لم تتوقف السلسلة تحت الظروف العادية، لكن عبارة "لم تتوقف حتى الآن" وعبارة "تُحلّ بشكل نظيف عند وجود خلاف عدائي" هما ادعاءان مختلفان. لا يكاد يُختبر هذا المسار في الاستخدام الحالي تقريبًا، لأن معظم النشاط ما زال خفيفًا وتعاونيًا. إنها مفاضلة تصميمية غير مرئية الآن ولا تصبح واضحة إلا عندما يختبرها أحدٌ تحت الضغط. أتساءل كيف يبدو ذلك عمليًا.
7
6
346
·
--
إيقاع غروب الشمس مضبوط على «يستقر خلال ثوانٍ، حسم نهائي حتمي، دون إعادة تنظيم» — صحيح بمجرد أن تتم إسناد كتلة لشاهد. لكن وثائق الإجماع تستخدم مصطلحًا لم أكن قد لاحظته من قبل: «إسناد فاشل»، حيث تصوّت أغلبية لجنة على أنه غير صالح، ويجب إعادة تكرار الجولة بلجنة جديدة. $DUSK #dusk @Dusk_Foundation
هذا ليس مجرد تنظير للمواصفات. تُظهر سجلات هندسة فريق Dusk قبل البث على الشبكة الرئيسية أن الفريق يعمل صراحةً على «تجاوز التكرارات التي تنتهي بمهلة» وإصلاح خطأ «حالة إجماع غير قابلة للاسترداد» مرتبط بحدث انقسام — مشاكل حقيقية في آلية التكرار، وليست حالات طرفية افتراضية.
لذلك فإن الحسم النهائي الحتمي خاصية ناتج، وليس مسارًا. بمجرد اعتماده، تصبح الكتلة نهائية بشكل تشفيري — دون تذبذب احتمالي مثل سلاسل ناكاموتو. لكن الوصول إلى حالة الاعتماد يتوقف على أن تضرب اللجنة النصاب في محاولة بعينها، ويمكن أن تفشل عمليات التكرار وتُعاد المحاولة.
ما تغيّر بالنسبة لي هو رؤية «الحسم النهائي مقابل TPS» كمحور خاطئ. نوع الحسم النهائي يحدد مستوى اليقين بمجرد استقرار شيء ما. بينما يحدد الإنتاجية مدى سرعتك للوصول إلى ذلك، وكم مرة قد تحتاج لإعادة المحاولة في الطريق.
جدير بالتحقق: ما هو المعدل الحالي على الشبكة الرئيسية لعمليات الإسناد الفاشل وتكرارات الإعادة، الآن بعد أن أصبحت إصلاحات ما قبل الشبكة الرئيسية حيّة؟
إيقاع غروب الشمس مضبوط على «يستقر خلال ثوانٍ، حسم نهائي حتمي، دون إعادة تنظيم» — صحيح بمجرد أن تتم إسناد كتلة لشاهد. لكن وثائق الإجماع تستخدم مصطلحًا لم أكن قد لاحظته من قبل: «إسناد فاشل»، حيث تصوّت أغلبية لجنة على أنه غير صالح، ويجب إعادة تكرار الجولة بلجنة جديدة. $DUSK #dusk @Dusk
هذا ليس مجرد تنظير للمواصفات. تُظهر سجلات هندسة فريق Dusk قبل البث على الشبكة الرئيسية أن الفريق يعمل صراحةً على «تجاوز التكرارات التي تنتهي بمهلة» وإصلاح خطأ «حالة إجماع غير قابلة للاسترداد» مرتبط بحدث انقسام — مشاكل حقيقية في آلية التكرار، وليست حالات طرفية افتراضية.
لذلك فإن الحسم النهائي الحتمي خاصية ناتج، وليس مسارًا. بمجرد اعتماده، تصبح الكتلة نهائية بشكل تشفيري — دون تذبذب احتمالي مثل سلاسل ناكاموتو. لكن الوصول إلى حالة الاعتماد يتوقف على أن تضرب اللجنة النصاب في محاولة بعينها، ويمكن أن تفشل عمليات التكرار وتُعاد المحاولة.
ما تغيّر بالنسبة لي هو رؤية «الحسم النهائي مقابل TPS» كمحور خاطئ. نوع الحسم النهائي يحدد مستوى اليقين بمجرد استقرار شيء ما. بينما يحدد الإنتاجية مدى سرعتك للوصول إلى ذلك، وكم مرة قد تحتاج لإعادة المحاولة في الطريق.
جدير بالتحقق: ما هو المعدل الحالي على الشبكة الرئيسية لعمليات الإسناد الفاشل وتكرارات الإعادة، الآن بعد أن أصبحت إصلاحات ما قبل الشبكة الرئيسية حيّة؟
هذا ليس مجرد تنظير للمواصفات. تُظهر سجلات هندسة فريق Dusk قبل البث على الشبكة الرئيسية أن الفريق يعمل صراحةً على «تجاوز التكرارات التي تنتهي بمهلة» وإصلاح خطأ «حالة إجماع غير قابلة للاسترداد» مرتبط بحدث انقسام — مشاكل حقيقية في آلية التكرار، وليست حالات طرفية افتراضية.
لذلك فإن الحسم النهائي الحتمي خاصية ناتج، وليس مسارًا. بمجرد اعتماده، تصبح الكتلة نهائية بشكل تشفيري — دون تذبذب احتمالي مثل سلاسل ناكاموتو. لكن الوصول إلى حالة الاعتماد يتوقف على أن تضرب اللجنة النصاب في محاولة بعينها، ويمكن أن تفشل عمليات التكرار وتُعاد المحاولة.
ما تغيّر بالنسبة لي هو رؤية «الحسم النهائي مقابل TPS» كمحور خاطئ. نوع الحسم النهائي يحدد مستوى اليقين بمجرد استقرار شيء ما. بينما يحدد الإنتاجية مدى سرعتك للوصول إلى ذلك، وكم مرة قد تحتاج لإعادة المحاولة في الطريق.
جدير بالتحقق: ما هو المعدل الحالي على الشبكة الرئيسية لعمليات الإسناد الفاشل وتكرارات الإعادة، الآن بعد أن أصبحت إصلاحات ما قبل الشبكة الرئيسية حيّة؟
6
4
283
·
--
عرض الترجمة
#dusk $DUSK @Dusk_Foundation Something about Citadel's timeline didn't line up when I checked the dates.
Citadel — Dusk's own zero-knowledge KYC/identity protocol — was first presented back in January 2023, and its SDK shipped in November 2023, well before mainnet. This is the piece that's supposed to let DUSK reconcile privacy with regulation: users prove attributes without exposing them, institutions onboard RWA investors without centralized KYC.
Here's the part that stopped me. Dusk's own post-mainnet roadmap, published the same week mainnet went live in January 2025, still listed "ZK KYC/AML using Citadel" as something to integrate — not something already running for RWA onboarding. Two years of the component existing, and the actual use case it was built for was still on the to-do list at mainnet launch.
That's not a knock on the tech — the repo's live on GitHub, actively maintained. What changed for me was realizing "Citadel exists" and "Citadel is doing the compliance work on live RWA issuance" are two different claims, and dusk's marketing tends to collapse them into one.
Worth checking: has any Dusk-issued RWA or security token actually routed onboarding through Citadel in production, or is KYC for those deals still happening off-chain today.
#dusk $DUSK @Dusk Something about Citadel's timeline didn't line up when I checked the dates.
Citadel — Dusk's own zero-knowledge KYC/identity protocol — was first presented back in January 2023, and its SDK shipped in November 2023, well before mainnet. This is the piece that's supposed to let DUSK reconcile privacy with regulation: users prove attributes without exposing them, institutions onboard RWA investors without centralized KYC.
Here's the part that stopped me. Dusk's own post-mainnet roadmap, published the same week mainnet went live in January 2025, still listed "ZK KYC/AML using Citadel" as something to integrate — not something already running for RWA onboarding. Two years of the component existing, and the actual use case it was built for was still on the to-do list at mainnet launch.
That's not a knock on the tech — the repo's live on GitHub, actively maintained. What changed for me was realizing "Citadel exists" and "Citadel is doing the compliance work on live RWA issuance" are two different claims, and dusk's marketing tends to collapse them into one.
Worth checking: has any Dusk-issued RWA or security token actually routed onboarding through Citadel in production, or is KYC for those deals still happening off-chain today.
Citadel — Dusk's own zero-knowledge KYC/identity protocol — was first presented back in January 2023, and its SDK shipped in November 2023, well before mainnet. This is the piece that's supposed to let DUSK reconcile privacy with regulation: users prove attributes without exposing them, institutions onboard RWA investors without centralized KYC.
Here's the part that stopped me. Dusk's own post-mainnet roadmap, published the same week mainnet went live in January 2025, still listed "ZK KYC/AML using Citadel" as something to integrate — not something already running for RWA onboarding. Two years of the component existing, and the actual use case it was built for was still on the to-do list at mainnet launch.
That's not a knock on the tech — the repo's live on GitHub, actively maintained. What changed for me was realizing "Citadel exists" and "Citadel is doing the compliance work on live RWA issuance" are two different claims, and dusk's marketing tends to collapse them into one.
Worth checking: has any Dusk-issued RWA or security token actually routed onboarding through Citadel in production, or is KYC for those deals still happening off-chain today.
14
3
295
·
--
عرض الترجمة
The detail that changed how I read $TMX was the April V2 change adding market and pool whitelist checks to three separate components: TermMaxRouterV2, MakerHelper, and TermMaxVaultV2 — plus automatic whitelist registration to factories.
That's not a security checkbox, it's a topology change. Splitting checks across Router, Helper, and Vault reduces reliance on any single contract, but all three now reference the same whitelist state. Decentralization here doesn't remove the trust boundary — it relocates it into shared authorization.
Next step: pick one gated action — vault deposit/withdrawal is the cleanest candidate since it's user-facing and continuously exercised — and trace what happens to it if the whitelist entry for its market is revoked mid-position. That answer tells you whether the shared dependency is a formality or a live kill switch.
#Termmax
@termmax
The detail that changed how I read $TMX was the April V2 change adding market and pool whitelist checks to three separate components: TermMaxRouterV2, MakerHelper, and TermMaxVaultV2 — plus automatic whitelist registration to factories.
That's not a security checkbox, it's a topology change. Splitting checks across Router, Helper, and Vault reduces reliance on any single contract, but all three now reference the same whitelist state. Decentralization here doesn't remove the trust boundary — it relocates it into shared authorization.
Next step: pick one gated action — vault deposit/withdrawal is the cleanest candidate since it's user-facing and continuously exercised — and trace what happens to it if the whitelist entry for its market is revoked mid-position. That answer tells you whether the shared dependency is a formality or a live kill switch.
#Termmax
@TermMax
That's not a security checkbox, it's a topology change. Splitting checks across Router, Helper, and Vault reduces reliance on any single contract, but all three now reference the same whitelist state. Decentralization here doesn't remove the trust boundary — it relocates it into shared authorization.
Next step: pick one gated action — vault deposit/withdrawal is the cleanest candidate since it's user-facing and continuously exercised — and trace what happens to it if the whitelist entry for its market is revoked mid-position. That answer tells you whether the shared dependency is a formality or a live kill switch.
#Termmax
@TermMax
8
4
312
·
--
تمّ التحقق
عرض الترجمة
TermMax describes its physical delivery mechanism in plain terms: when there's no liquidity to liquidate collateral, lenders get the borrower's collateral instead. Read that alone and it sounds like a backstop. Then I checked @termmax $TMX Risks docs for #TermMax and found narrower wording: physical delivery "mitigates" shortfall risk — it doesn't remove it.
The gap sits in the liquidation formula itself. TermMax caps how much collateral can be pulled from a defaulted position at a fixed maximum, built to stop borrowers from being over-liquidated. If a fast market move leaves that capped collateral short of what's owed, lenders receive a proportional share of what remains, not their full position back.
What changed for me was seeing the technical Risks page frame this more cautiously than the general product description does. Security here isn't an insurance-style promise — it's bounded loss-sharing, closer to how a clearinghouse haircuts positions in a fast market than how "collateral delivered as compensation" reads on its own.
Worth checking next: how often that liquidation cap has actually bound during real volatility, and what proportional payout lenders received relative to their original position.
TermMax describes its physical delivery mechanism in plain terms: when there's no liquidity to liquidate collateral, lenders get the borrower's collateral instead. Read that alone and it sounds like a backstop. Then I checked @TermMax $TMX Risks docs for #TermMax and found narrower wording: physical delivery "mitigates" shortfall risk — it doesn't remove it.
The gap sits in the liquidation formula itself. TermMax caps how much collateral can be pulled from a defaulted position at a fixed maximum, built to stop borrowers from being over-liquidated. If a fast market move leaves that capped collateral short of what's owed, lenders receive a proportional share of what remains, not their full position back.
What changed for me was seeing the technical Risks page frame this more cautiously than the general product description does. Security here isn't an insurance-style promise — it's bounded loss-sharing, closer to how a clearinghouse haircuts positions in a fast market than how "collateral delivered as compensation" reads on its own.
Worth checking next: how often that liquidation cap has actually bound during real volatility, and what proportional payout lenders received relative to their original position.
The gap sits in the liquidation formula itself. TermMax caps how much collateral can be pulled from a defaulted position at a fixed maximum, built to stop borrowers from being over-liquidated. If a fast market move leaves that capped collateral short of what's owed, lenders receive a proportional share of what remains, not their full position back.
What changed for me was seeing the technical Risks page frame this more cautiously than the general product description does. Security here isn't an insurance-style promise — it's bounded loss-sharing, closer to how a clearinghouse haircuts positions in a fast market than how "collateral delivered as compensation" reads on its own.
Worth checking next: how often that liquidation cap has actually bound during real volatility, and what proportional payout lenders received relative to their original position.
9
6
387
·
--
تمّ التحقق
التفصيل الذي أوقفني في تصميم Citadel: الترخيص الذي يتيح للمستخدم أن يثبت امتثالاً بشكلٍ خاص ليس ملكاً له بالكامل.
يوقَّع من قِبل مزوّد الترخيص، ويرتبط تشفيرياً بعنوان الخفاء الخاص بالمستخدم (لذا لا يمكن نقله)، ويُسجَّل في شجرة ميركل يمكن للمزوّد تحديثها لإلغاء الترخيص. يُنشئ المستخدم إثباتاً ذا معرفةٍ صفرية بالملكية والاستمرار في تلك الشجرة؛ ومع ذلك يظلّ مزوّد الخدمة هو من يقرر ما إذا كان سيتم قبول الإثبات وما إذا كان الترخيص سيظل صالحاً.
تؤكد تسليمات Dusk الخاصة بشهر ديسمبر 2023 أن حزمة Citadel SDK قد تم شحنها وتم دمجها في محفظة الويب قبل الإطلاق على mainnet. المكوّن موجود. يبقى غير مُتحقق ما إذا كان أي مزوّد خدمة يُصدر تراخيص أو يلغيها بنشاط على mainnet حتى اليوم.
$DUSK K #dusk @Dusk_Foundation تعزّز Foundation الخصوصية المالية باعتبارها حقاً. تعيد البنية توجيه ذلك الحق عبر طرف يمكنه قطع الوصول في أي وقت.
الإلغاء ليس خللاً؛ بل هو الطريقة التي تمنع بها المنظومة إعادة استخدام التراخيص أو إساءة استخدامها بعد إصدارها. لكنه يعني أن “الحق” يعمل أكثر مثل إذنٍ قائم: خاصاً افتراضياً، ومشروطاً بتعاون المُصدِر المستمر.
ما تغيّر بالنسبة لي هو إدراكي أن الإفصاح الانتقائي وقابلية الإلغاء يشكلان آلية واحدة وليس ميزتين منفصلتين. تُخفي المعرفة الصفرية ما الذي تثبته. ومن يقرر ما إذا كان بإمكانك الاستمرار في إثباته هو سؤال مختلف—والقرار حالياً يقع لدى مزوّد الخدمة.
لا يزال مفتوحاً: ما إذا كان أي مزوّد قد نشر معايير إلغاء واضحة، وما إذا كان ترخيص Citadel قد تم بالفعل إلغاؤه على mainnet منذ الإطلاق.
التفصيل الذي أوقفني في تصميم Citadel: الترخيص الذي يتيح للمستخدم أن يثبت امتثالاً بشكلٍ خاص ليس ملكاً له بالكامل.
يوقَّع من قِبل مزوّد الترخيص، ويرتبط تشفيرياً بعنوان الخفاء الخاص بالمستخدم (لذا لا يمكن نقله)، ويُسجَّل في شجرة ميركل يمكن للمزوّد تحديثها لإلغاء الترخيص. يُنشئ المستخدم إثباتاً ذا معرفةٍ صفرية بالملكية والاستمرار في تلك الشجرة؛ ومع ذلك يظلّ مزوّد الخدمة هو من يقرر ما إذا كان سيتم قبول الإثبات وما إذا كان الترخيص سيظل صالحاً.
تؤكد تسليمات Dusk الخاصة بشهر ديسمبر 2023 أن حزمة Citadel SDK قد تم شحنها وتم دمجها في محفظة الويب قبل الإطلاق على mainnet. المكوّن موجود. يبقى غير مُتحقق ما إذا كان أي مزوّد خدمة يُصدر تراخيص أو يلغيها بنشاط على mainnet حتى اليوم.
$DUSK K #dusk @Dusk تعزّز Foundation الخصوصية المالية باعتبارها حقاً. تعيد البنية توجيه ذلك الحق عبر طرف يمكنه قطع الوصول في أي وقت.
الإلغاء ليس خللاً؛ بل هو الطريقة التي تمنع بها المنظومة إعادة استخدام التراخيص أو إساءة استخدامها بعد إصدارها. لكنه يعني أن “الحق” يعمل أكثر مثل إذنٍ قائم: خاصاً افتراضياً، ومشروطاً بتعاون المُصدِر المستمر.
ما تغيّر بالنسبة لي هو إدراكي أن الإفصاح الانتقائي وقابلية الإلغاء يشكلان آلية واحدة وليس ميزتين منفصلتين. تُخفي المعرفة الصفرية ما الذي تثبته. ومن يقرر ما إذا كان بإمكانك الاستمرار في إثباته هو سؤال مختلف—والقرار حالياً يقع لدى مزوّد الخدمة.
لا يزال مفتوحاً: ما إذا كان أي مزوّد قد نشر معايير إلغاء واضحة، وما إذا كان ترخيص Citadel قد تم بالفعل إلغاؤه على mainnet منذ الإطلاق.
يوقَّع من قِبل مزوّد الترخيص، ويرتبط تشفيرياً بعنوان الخفاء الخاص بالمستخدم (لذا لا يمكن نقله)، ويُسجَّل في شجرة ميركل يمكن للمزوّد تحديثها لإلغاء الترخيص. يُنشئ المستخدم إثباتاً ذا معرفةٍ صفرية بالملكية والاستمرار في تلك الشجرة؛ ومع ذلك يظلّ مزوّد الخدمة هو من يقرر ما إذا كان سيتم قبول الإثبات وما إذا كان الترخيص سيظل صالحاً.
تؤكد تسليمات Dusk الخاصة بشهر ديسمبر 2023 أن حزمة Citadel SDK قد تم شحنها وتم دمجها في محفظة الويب قبل الإطلاق على mainnet. المكوّن موجود. يبقى غير مُتحقق ما إذا كان أي مزوّد خدمة يُصدر تراخيص أو يلغيها بنشاط على mainnet حتى اليوم.
$DUSK K #dusk @Dusk تعزّز Foundation الخصوصية المالية باعتبارها حقاً. تعيد البنية توجيه ذلك الحق عبر طرف يمكنه قطع الوصول في أي وقت.
الإلغاء ليس خللاً؛ بل هو الطريقة التي تمنع بها المنظومة إعادة استخدام التراخيص أو إساءة استخدامها بعد إصدارها. لكنه يعني أن “الحق” يعمل أكثر مثل إذنٍ قائم: خاصاً افتراضياً، ومشروطاً بتعاون المُصدِر المستمر.
ما تغيّر بالنسبة لي هو إدراكي أن الإفصاح الانتقائي وقابلية الإلغاء يشكلان آلية واحدة وليس ميزتين منفصلتين. تُخفي المعرفة الصفرية ما الذي تثبته. ومن يقرر ما إذا كان بإمكانك الاستمرار في إثباته هو سؤال مختلف—والقرار حالياً يقع لدى مزوّد الخدمة.
لا يزال مفتوحاً: ما إذا كان أي مزوّد قد نشر معايير إلغاء واضحة، وما إذا كان ترخيص Citadel قد تم بالفعل إلغاؤه على mainnet منذ الإطلاق.
7
3
1.1k
·
--
عرض الترجمة
Looking at TermMax’s liquidation docs and the physical delivery rule changed how I saw the fixed-rate claim.
On $TMX #TermMax @termmax if a loan reaches maturity unpaid and the two-hour liquidation window closes without full clearance, the system does not simply force a cash recovery or write-off. It forms a redemption pool of remaining debt tokens plus the collateral itself. FT holders then redeem according to their share of outstanding FTs and receive a proportional allocation of both assets.
That’s not the usual DeFi pattern of selling collateral to repay lenders strictly in the debt token. Here the residual risk is transferred as direct asset exposure. What first appeared as pure fixed-rate lending starts to function more like a contingent claim on the collateral when the clean repayment path fails.
What changed for me was realizing the rate lock comes with this secondary delivery mechanic built into the design from the start.
Next check: how often post-maturity positions actually reach physical delivery versus full liquidation clearance across live markets.
Looking at TermMax’s liquidation docs and the physical delivery rule changed how I saw the fixed-rate claim.
On $TMX #TermMax @TermMax if a loan reaches maturity unpaid and the two-hour liquidation window closes without full clearance, the system does not simply force a cash recovery or write-off. It forms a redemption pool of remaining debt tokens plus the collateral itself. FT holders then redeem according to their share of outstanding FTs and receive a proportional allocation of both assets.
That’s not the usual DeFi pattern of selling collateral to repay lenders strictly in the debt token. Here the residual risk is transferred as direct asset exposure. What first appeared as pure fixed-rate lending starts to function more like a contingent claim on the collateral when the clean repayment path fails.
What changed for me was realizing the rate lock comes with this secondary delivery mechanic built into the design from the start.
Next check: how often post-maturity positions actually reach physical delivery versus full liquidation clearance across live markets.
On $TMX #TermMax @TermMax if a loan reaches maturity unpaid and the two-hour liquidation window closes without full clearance, the system does not simply force a cash recovery or write-off. It forms a redemption pool of remaining debt tokens plus the collateral itself. FT holders then redeem according to their share of outstanding FTs and receive a proportional allocation of both assets.
That’s not the usual DeFi pattern of selling collateral to repay lenders strictly in the debt token. Here the residual risk is transferred as direct asset exposure. What first appeared as pure fixed-rate lending starts to function more like a contingent claim on the collateral when the clean repayment path fails.
What changed for me was realizing the rate lock comes with this secondary delivery mechanic built into the design from the start.
Next check: how often post-maturity positions actually reach physical delivery versus full liquidation clearance across live markets.
4
647
·
--
تمّ التحقق
عرض الترجمة
Looking at the docs again… every concrete workflow listed for Dusk—regulated securities, institutional DeFi, confidential payments, DvP—routes through Citadel for eligibility. Identity is not treated as its own sector. It is the gate.
Dusk ($DUSK ) #dusk @Duskfoundation built the credential layer so finance can stay private while still enforcing residency or accreditation. Once verified, selective disclosure lets the same proof gate transfers and positions without re-exposing the underlying data. Gaming never shows up in that stack. The privacy model and the public/shielded transaction split were shaped around market data that cannot sit in the clear.
What changed for me was realizing identity is load-bearing for finance rather than a parallel vertical. Without that binding, the compliance rules inside the asset contracts lose their on-chain force.
Next check: whether any live product surface outside securities or lending actually reuses those same Citadel credentials for access control.
@Dusk_Foundation
Looking at the docs again… every concrete workflow listed for Dusk—regulated securities, institutional DeFi, confidential payments, DvP—routes through Citadel for eligibility. Identity is not treated as its own sector. It is the gate.
Dusk ($DUSK ) #dusk @Duskfoundation built the credential layer so finance can stay private while still enforcing residency or accreditation. Once verified, selective disclosure lets the same proof gate transfers and positions without re-exposing the underlying data. Gaming never shows up in that stack. The privacy model and the public/shielded transaction split were shaped around market data that cannot sit in the clear.
What changed for me was realizing identity is load-bearing for finance rather than a parallel vertical. Without that binding, the compliance rules inside the asset contracts lose their on-chain force.
Next check: whether any live product surface outside securities or lending actually reuses those same Citadel credentials for access control.
@Dusk
Dusk ($DUSK ) #dusk @Duskfoundation built the credential layer so finance can stay private while still enforcing residency or accreditation. Once verified, selective disclosure lets the same proof gate transfers and positions without re-exposing the underlying data. Gaming never shows up in that stack. The privacy model and the public/shielded transaction split were shaped around market data that cannot sit in the clear.
What changed for me was realizing identity is load-bearing for finance rather than a parallel vertical. Without that binding, the compliance rules inside the asset contracts lose their on-chain force.
Next check: whether any live product surface outside securities or lending actually reuses those same Citadel credentials for access control.
@Dusk
8
3
617
·
--
تمّ التحقق
تقع نقطتان في مستندات Hyperstaking بجوار بعضهما بطريقة لم أكن قد ربطتها من قبل. أولًا: يمكن لعقد أن يقوم بالـ staking نيابةً عن المودعين وأن يوزّع المكافآت بمنطقه الخاص — يصبح العقد نفسه هو مشارك الـ staking، وليس المودع الفردي. ثانيًا، بشكل منفصل، في مستندات tokenomics: #dusk slashing تُعدّ soft — لا يوجد حرق، بل تخفيض في المشاركة الفعّالة والمكافآت الممنوحة لمقدّم الخدمة (الـ provisioner) على الخطأ.
عندما تجمع هاتين النقطتين معًا، يظهر سؤال مفتوح حقيقي، وليس إجابة لدي: إذا كان العقد هو الـ provisioner، وجرى تنفيذ الـ soft-slashed على الـ provisioner نفسه، فكيف ينعكس تخفيض المكافآت على المودعين الذين يقفون خلفه؟ تصف المستندات آليتَي العمل هاتين كل واحدة على حدة. ولا يذكر أي منهما كيف تتفاعلان بمجرد أن يصبح عقدٌ ما وسيطًا بين المودع والعقوبة.
Sozu هو حاليًا المسبح (pool) الوحيد المذكور بالاسم في Hyperstaking، وكان ما يزال في مرحلة بيتا حتى آخر تحديث رأيته — لذا لم يحدث ذلك في أي مكان حتى الآن، لا على السلسلة ولا غيرها.
ما سأتحقق منه بعد ذلك: ما إذا كانت مستندات Dusk أو Sozu تحدد كيفية تقسيم عقوبة الـ soft-slashing بين مودعي الـ pool، أو ما إذا كان ذلك غير محدد.
$DUSK
@Dusk_Foundation
تقع نقطتان في مستندات Hyperstaking بجوار بعضهما بطريقة لم أكن قد ربطتها من قبل. أولًا: يمكن لعقد أن يقوم بالـ staking نيابةً عن المودعين وأن يوزّع المكافآت بمنطقه الخاص — يصبح العقد نفسه هو مشارك الـ staking، وليس المودع الفردي. ثانيًا، بشكل منفصل، في مستندات tokenomics: #dusk slashing تُعدّ soft — لا يوجد حرق، بل تخفيض في المشاركة الفعّالة والمكافآت الممنوحة لمقدّم الخدمة (الـ provisioner) على الخطأ.
عندما تجمع هاتين النقطتين معًا، يظهر سؤال مفتوح حقيقي، وليس إجابة لدي: إذا كان العقد هو الـ provisioner، وجرى تنفيذ الـ soft-slashed على الـ provisioner نفسه، فكيف ينعكس تخفيض المكافآت على المودعين الذين يقفون خلفه؟ تصف المستندات آليتَي العمل هاتين كل واحدة على حدة. ولا يذكر أي منهما كيف تتفاعلان بمجرد أن يصبح عقدٌ ما وسيطًا بين المودع والعقوبة.
Sozu هو حاليًا المسبح (pool) الوحيد المذكور بالاسم في Hyperstaking، وكان ما يزال في مرحلة بيتا حتى آخر تحديث رأيته — لذا لم يحدث ذلك في أي مكان حتى الآن، لا على السلسلة ولا غيرها.
ما سأتحقق منه بعد ذلك: ما إذا كانت مستندات Dusk أو Sozu تحدد كيفية تقسيم عقوبة الـ soft-slashing بين مودعي الـ pool، أو ما إذا كان ذلك غير محدد.
$DUSK
@Dusk
عندما تجمع هاتين النقطتين معًا، يظهر سؤال مفتوح حقيقي، وليس إجابة لدي: إذا كان العقد هو الـ provisioner، وجرى تنفيذ الـ soft-slashed على الـ provisioner نفسه، فكيف ينعكس تخفيض المكافآت على المودعين الذين يقفون خلفه؟ تصف المستندات آليتَي العمل هاتين كل واحدة على حدة. ولا يذكر أي منهما كيف تتفاعلان بمجرد أن يصبح عقدٌ ما وسيطًا بين المودع والعقوبة.
Sozu هو حاليًا المسبح (pool) الوحيد المذكور بالاسم في Hyperstaking، وكان ما يزال في مرحلة بيتا حتى آخر تحديث رأيته — لذا لم يحدث ذلك في أي مكان حتى الآن، لا على السلسلة ولا غيرها.
ما سأتحقق منه بعد ذلك: ما إذا كانت مستندات Dusk أو Sozu تحدد كيفية تقسيم عقوبة الـ soft-slashing بين مودعي الـ pool، أو ما إذا كان ذلك غير محدد.
$DUSK
@Dusk
5
4
689
·
--
تمّ التحقق
عرض الترجمة
Wait — the thing "protecting" your DuskEVM trade from bots right now isn't even the fancy tech.
Everyone talks about Hedger, DuskEVM's ($DUSK #dusk @DuskFoundation) privacy engine — homomorphic encryption plus ZK proofs, encrypted balances, real cryptography. That's not what's stopping front-running today though.
I checked the docs. DuskEVM currently runs sequencer-only. No public mempool. One sequencer, nothing for bots to watch and jump ahead of. That's the actual mechanism.
So there are two different "privacy" stories stacked on top of each other, and it's easy to credit the wrong one. Hedger is real cryptographic privacy, audit-ready by design. Front-running protection is something else — a side effect of having one sequencer with nothing exposed.
Here's what I haven't found yet: any doc or roadmap saying whether DuskEVM's sequencer stays single or opens up over time. If it ever becomes multi-party or public, this specific protection would need something to replace it. That's not confirmed anywhere I've seen — just a question the current setup raises.
Curious if anyone's tracked DuskEVM's actual sequencer roadmap. Genuinely don't know the answer here.
@Dusk_Foundation
Wait — the thing "protecting" your DuskEVM trade from bots right now isn't even the fancy tech.
Everyone talks about Hedger, DuskEVM's ($DUSK #dusk @DuskFoundation) privacy engine — homomorphic encryption plus ZK proofs, encrypted balances, real cryptography. That's not what's stopping front-running today though.
I checked the docs. DuskEVM currently runs sequencer-only. No public mempool. One sequencer, nothing for bots to watch and jump ahead of. That's the actual mechanism.
So there are two different "privacy" stories stacked on top of each other, and it's easy to credit the wrong one. Hedger is real cryptographic privacy, audit-ready by design. Front-running protection is something else — a side effect of having one sequencer with nothing exposed.
Here's what I haven't found yet: any doc or roadmap saying whether DuskEVM's sequencer stays single or opens up over time. If it ever becomes multi-party or public, this specific protection would need something to replace it. That's not confirmed anywhere I've seen — just a question the current setup raises.
Curious if anyone's tracked DuskEVM's actual sequencer roadmap. Genuinely don't know the answer here.
@Dusk
Everyone talks about Hedger, DuskEVM's ($DUSK #dusk @DuskFoundation) privacy engine — homomorphic encryption plus ZK proofs, encrypted balances, real cryptography. That's not what's stopping front-running today though.
I checked the docs. DuskEVM currently runs sequencer-only. No public mempool. One sequencer, nothing for bots to watch and jump ahead of. That's the actual mechanism.
So there are two different "privacy" stories stacked on top of each other, and it's easy to credit the wrong one. Hedger is real cryptographic privacy, audit-ready by design. Front-running protection is something else — a side effect of having one sequencer with nothing exposed.
Here's what I haven't found yet: any doc or roadmap saying whether DuskEVM's sequencer stays single or opens up over time. If it ever becomes multi-party or public, this specific protection would need something to replace it. That's not confirmed anywhere I've seen — just a question the current setup raises.
Curious if anyone's tracked DuskEVM's actual sequencer roadmap. Genuinely don't know the answer here.
@Dusk
8
5
864
·
--
ذهبت أبحث عن كيفية تعامل «سيتيادل» من «سيتادل» فعليًا مع بيانات الاعتماد الملغاة. اتضح أن الإجابة ليست «السلسلة هي التي تتحقق منه». يتيح بروتوكول «سيتيادل» من شبكة «ديـسك» $DUSK #dusk للمستخدم أن يثبت أن الجلسة صالحة تشفيريًا — أي أن «مزود رخصة» حقيقيًا قام بتوقيع رخصة حقيقية — لكن وفقًا للوثائق، فإن هذا الإثبات لا يحدد سياسة الخدمة.
القرار هنا يعود إلى «مزود الخدمة». ووفقًا لوثائق «@Duskfoundation» نفسها، يحدد مزود الخدمة أي مزودي رخصة يثق بهم، وما هي السمات التي يقبلها، وما إذا كانت الجلسة منتهية أو ملغاة، وما إذا كان يمكن إعادة استخدام ملف تعريف الارتباط الخاص بالجلسة. ولا شيء من ذلك مكتوب في التحقق على السلسلة نفسه.
بالنسبة لي، ما تغيّر هو إدراكي أن «اعرف عميلك مع الحفاظ على الخصوصية» هنا لا يعني أن السلسلة تفرض الامتثال. السمات الشخصية لا تُكتب أبدًا في سلسلة الكتل — وهذا مذكور صراحةً في الوثائق. لكن انتهاء الصلاحية والإلغاء والثقة في المُصدر هي قرارات سياسة يتخذها كل مزود خدمة بشكل مستقل، خارج السلسلة، دون أن يفرض أي شيء على السلسلة اتساقًا بينهم.
@Dusk_Foundation
ذهبت أبحث عن كيفية تعامل «سيتيادل» من «سيتادل» فعليًا مع بيانات الاعتماد الملغاة. اتضح أن الإجابة ليست «السلسلة هي التي تتحقق منه». يتيح بروتوكول «سيتيادل» من شبكة «ديـسك» $DUSK #dusk للمستخدم أن يثبت أن الجلسة صالحة تشفيريًا — أي أن «مزود رخصة» حقيقيًا قام بتوقيع رخصة حقيقية — لكن وفقًا للوثائق، فإن هذا الإثبات لا يحدد سياسة الخدمة.
القرار هنا يعود إلى «مزود الخدمة». ووفقًا لوثائق «@Duskfoundation» نفسها، يحدد مزود الخدمة أي مزودي رخصة يثق بهم، وما هي السمات التي يقبلها، وما إذا كانت الجلسة منتهية أو ملغاة، وما إذا كان يمكن إعادة استخدام ملف تعريف الارتباط الخاص بالجلسة. ولا شيء من ذلك مكتوب في التحقق على السلسلة نفسه.
بالنسبة لي، ما تغيّر هو إدراكي أن «اعرف عميلك مع الحفاظ على الخصوصية» هنا لا يعني أن السلسلة تفرض الامتثال. السمات الشخصية لا تُكتب أبدًا في سلسلة الكتل — وهذا مذكور صراحةً في الوثائق. لكن انتهاء الصلاحية والإلغاء والثقة في المُصدر هي قرارات سياسة يتخذها كل مزود خدمة بشكل مستقل، خارج السلسلة، دون أن يفرض أي شيء على السلسلة اتساقًا بينهم.
@Dusk
القرار هنا يعود إلى «مزود الخدمة». ووفقًا لوثائق «@Duskfoundation» نفسها، يحدد مزود الخدمة أي مزودي رخصة يثق بهم، وما هي السمات التي يقبلها، وما إذا كانت الجلسة منتهية أو ملغاة، وما إذا كان يمكن إعادة استخدام ملف تعريف الارتباط الخاص بالجلسة. ولا شيء من ذلك مكتوب في التحقق على السلسلة نفسه.
بالنسبة لي، ما تغيّر هو إدراكي أن «اعرف عميلك مع الحفاظ على الخصوصية» هنا لا يعني أن السلسلة تفرض الامتثال. السمات الشخصية لا تُكتب أبدًا في سلسلة الكتل — وهذا مذكور صراحةً في الوثائق. لكن انتهاء الصلاحية والإلغاء والثقة في المُصدر هي قرارات سياسة يتخذها كل مزود خدمة بشكل مستقل، خارج السلسلة، دون أن يفرض أي شيء على السلسلة اتساقًا بينهم.
@Dusk
10
4
857
·
--
قضيت بعد الظهر أتصفّح مستودعات Dusk بدلًا من مجرد قراءة عرض الـpitch deck. #Dusk $DUSK @DuskFoundation — "الخصوصية على سلسلة عامة" هي الفكرة الأساسية في عالم TradFi، لذلك أردت أن أرى ما الذي يتحرّك فعليًا، لا ما الذي يُقال فقط.
وهذا ما لفت انتباهي: duskevm-genesis، المستودع الذي يحتوي على بلوك التأسيس (genesis block) وإعدادات rollup، كانت فيه عمليات دمج (commits) يومي 8 أغسطس و10 أغسطس 2026. ليس كود تسوية RWA. ليس عقدًا للأوراق المالية. إعدادات التأسيس وروول أب — الأشياء المملة التي لا يلتقط لها أحد صورًا.
وفي الوقت نفسه، كانت أكثر ثنائية نشاطًا لدى DUSK، DUSK/USDT على Binance، تُنجز حوالي 117 ألف دولار في حجم تداول خلال 24 ساعة عندما تحققت، مقابل إجمالي يقارب 3.07 مليون دولار عبر 51 سوقًا (CoinGecko). وبالنسبة لمشروع أطروحته كاملة هي "أن المؤسسات ستتعامل أخيرًا على سلسلة عامة"، فهذا مؤشر ضعيف.
جعلني هذا أعيد التفكير في طريقة صياغتي من البداية — افترضت أن الخصوصية المتوافقة تعني تدفّقًا مؤسسيًا غير مرئي يعمل في الخلفية. لكن ما وجدته بدلًا من ذلك هو أن البنية التحتية ما زالت قيد التوصيل بهدوء، في حين أن القيمة السوقية لا تزال أقل من 50 مليون دولار.
فما الذي يأتي أولًا هنا — المؤسسات التي يواصل Dusk وعدها، أم أن البنية التحتية أخيرًا تلحق بما تقوله الـpitch؟
@Dusk_Foundation
قضيت بعد الظهر أتصفّح مستودعات Dusk بدلًا من مجرد قراءة عرض الـpitch deck. #Dusk $DUSK @DuskFoundation — "الخصوصية على سلسلة عامة" هي الفكرة الأساسية في عالم TradFi، لذلك أردت أن أرى ما الذي يتحرّك فعليًا، لا ما الذي يُقال فقط.
وهذا ما لفت انتباهي: duskevm-genesis، المستودع الذي يحتوي على بلوك التأسيس (genesis block) وإعدادات rollup، كانت فيه عمليات دمج (commits) يومي 8 أغسطس و10 أغسطس 2026. ليس كود تسوية RWA. ليس عقدًا للأوراق المالية. إعدادات التأسيس وروول أب — الأشياء المملة التي لا يلتقط لها أحد صورًا.
وفي الوقت نفسه، كانت أكثر ثنائية نشاطًا لدى DUSK، DUSK/USDT على Binance، تُنجز حوالي 117 ألف دولار في حجم تداول خلال 24 ساعة عندما تحققت، مقابل إجمالي يقارب 3.07 مليون دولار عبر 51 سوقًا (CoinGecko). وبالنسبة لمشروع أطروحته كاملة هي "أن المؤسسات ستتعامل أخيرًا على سلسلة عامة"، فهذا مؤشر ضعيف.
جعلني هذا أعيد التفكير في طريقة صياغتي من البداية — افترضت أن الخصوصية المتوافقة تعني تدفّقًا مؤسسيًا غير مرئي يعمل في الخلفية. لكن ما وجدته بدلًا من ذلك هو أن البنية التحتية ما زالت قيد التوصيل بهدوء، في حين أن القيمة السوقية لا تزال أقل من 50 مليون دولار.
فما الذي يأتي أولًا هنا — المؤسسات التي يواصل Dusk وعدها، أم أن البنية التحتية أخيرًا تلحق بما تقوله الـpitch؟
@Dusk
وهذا ما لفت انتباهي: duskevm-genesis، المستودع الذي يحتوي على بلوك التأسيس (genesis block) وإعدادات rollup، كانت فيه عمليات دمج (commits) يومي 8 أغسطس و10 أغسطس 2026. ليس كود تسوية RWA. ليس عقدًا للأوراق المالية. إعدادات التأسيس وروول أب — الأشياء المملة التي لا يلتقط لها أحد صورًا.
وفي الوقت نفسه، كانت أكثر ثنائية نشاطًا لدى DUSK، DUSK/USDT على Binance، تُنجز حوالي 117 ألف دولار في حجم تداول خلال 24 ساعة عندما تحققت، مقابل إجمالي يقارب 3.07 مليون دولار عبر 51 سوقًا (CoinGecko). وبالنسبة لمشروع أطروحته كاملة هي "أن المؤسسات ستتعامل أخيرًا على سلسلة عامة"، فهذا مؤشر ضعيف.
جعلني هذا أعيد التفكير في طريقة صياغتي من البداية — افترضت أن الخصوصية المتوافقة تعني تدفّقًا مؤسسيًا غير مرئي يعمل في الخلفية. لكن ما وجدته بدلًا من ذلك هو أن البنية التحتية ما زالت قيد التوصيل بهدوء، في حين أن القيمة السوقية لا تزال أقل من 50 مليون دولار.
فما الذي يأتي أولًا هنا — المؤسسات التي يواصل Dusk وعدها، أم أن البنية التحتية أخيرًا تلحق بما تقوله الـpitch؟
@Dusk
18
4
394
·
--
إن قيود دائرة فينكس قراءتها أوقفتني. في Dusk $DUSK #dusk لدى @Duskfoundation، لا يقوم عقد التحويل أبدًا بالتحقق من القيم الفعلية للملاحظة أو من أي ورقة ميركل يتم إنفاقها.
بل يتحقق فقط من إثبات PLONK بأن المدخلات الخاصة تحقق خمس شروط: أن تجزئة الملاحظة تفتح مقابل جذر ميركل حديث للملاحظات، وأن المُثبت يعرف مفتاح سرّ الملاحظة، وأن المُبطِل (nullifier) يساوي Poseidon(npk′ ‖ position)، وأن الالتزامات الخاصة بالمخرجات تفتح بشكل صحيح، وأن مجموع قيم المدخلات يساوي المخرجات بالإضافة إلى الرسوم وأي إيداع.
يتم نشر المُبطلات نفسها حتى يتمكن الشبكة من رفض إعادة الاستخدام. وبما أن كل مُبطِل مشتق من مفتاح الملاحظة وموضعها المخفيين، فلا يستطيع أي مراقب ربط مُبطِل بملاحظة/ورقة محددة. إن شرط الصحة موجود بالكامل داخل تحقق الدائرة؛ ولا تظهر المحتويات أبدًا على السجل.
ما تغير بالنسبة لي هو إدراكي أن حماية من الإنفاق المزدوج وسلامة الرصيد كلاهما يوجدان داخل الإثبات وليس في أي حالة ظاهرة.
الفحص التالي: ما إذا كانت مُبطلات كل معاملة مقبولة من Phoenix والمُنَشَرة تظل فريدة داخل مجموعة المُبطلات على السلسلة بعد اكتمال/نهائية المعاملة.
@Dusk_Foundation
إن قيود دائرة فينكس قراءتها أوقفتني. في Dusk $DUSK #dusk لدى @Duskfoundation، لا يقوم عقد التحويل أبدًا بالتحقق من القيم الفعلية للملاحظة أو من أي ورقة ميركل يتم إنفاقها.
بل يتحقق فقط من إثبات PLONK بأن المدخلات الخاصة تحقق خمس شروط: أن تجزئة الملاحظة تفتح مقابل جذر ميركل حديث للملاحظات، وأن المُثبت يعرف مفتاح سرّ الملاحظة، وأن المُبطِل (nullifier) يساوي Poseidon(npk′ ‖ position)، وأن الالتزامات الخاصة بالمخرجات تفتح بشكل صحيح، وأن مجموع قيم المدخلات يساوي المخرجات بالإضافة إلى الرسوم وأي إيداع.
يتم نشر المُبطلات نفسها حتى يتمكن الشبكة من رفض إعادة الاستخدام. وبما أن كل مُبطِل مشتق من مفتاح الملاحظة وموضعها المخفيين، فلا يستطيع أي مراقب ربط مُبطِل بملاحظة/ورقة محددة. إن شرط الصحة موجود بالكامل داخل تحقق الدائرة؛ ولا تظهر المحتويات أبدًا على السجل.
ما تغير بالنسبة لي هو إدراكي أن حماية من الإنفاق المزدوج وسلامة الرصيد كلاهما يوجدان داخل الإثبات وليس في أي حالة ظاهرة.
الفحص التالي: ما إذا كانت مُبطلات كل معاملة مقبولة من Phoenix والمُنَشَرة تظل فريدة داخل مجموعة المُبطلات على السلسلة بعد اكتمال/نهائية المعاملة.
@Dusk
بل يتحقق فقط من إثبات PLONK بأن المدخلات الخاصة تحقق خمس شروط: أن تجزئة الملاحظة تفتح مقابل جذر ميركل حديث للملاحظات، وأن المُثبت يعرف مفتاح سرّ الملاحظة، وأن المُبطِل (nullifier) يساوي Poseidon(npk′ ‖ position)، وأن الالتزامات الخاصة بالمخرجات تفتح بشكل صحيح، وأن مجموع قيم المدخلات يساوي المخرجات بالإضافة إلى الرسوم وأي إيداع.
يتم نشر المُبطلات نفسها حتى يتمكن الشبكة من رفض إعادة الاستخدام. وبما أن كل مُبطِل مشتق من مفتاح الملاحظة وموضعها المخفيين، فلا يستطيع أي مراقب ربط مُبطِل بملاحظة/ورقة محددة. إن شرط الصحة موجود بالكامل داخل تحقق الدائرة؛ ولا تظهر المحتويات أبدًا على السجل.
ما تغير بالنسبة لي هو إدراكي أن حماية من الإنفاق المزدوج وسلامة الرصيد كلاهما يوجدان داخل الإثبات وليس في أي حالة ظاهرة.
الفحص التالي: ما إذا كانت مُبطلات كل معاملة مقبولة من Phoenix والمُنَشَرة تظل فريدة داخل مجموعة المُبطلات على السلسلة بعد اكتمال/نهائية المعاملة.
@Dusk
2
242
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
المواضيع الرائجة
BinancePick
2.2M مشاهدات
123,501 يقومون بالنقاش
انضم إلى #موسم_الأرباح: توقّع الأرباح على Binance Pick وشاركنا رأيك على Binance Square!
Binance Square Official
·384 إعجاب
·330.3k مشاهدات
EarningsSeason
4.7M مشاهدات
22,730 يقومون بالنقاش
USQ3GDPAndSeptemberPCEDueNextWeek
42,772 مشاهدات
689 يقومون بالنقاش