Maxine Agency
1.2k منشورات
Maxine Agency
إبلاغ
حظر المُستخدم
مُتداول مُتكرر
5.4 سنوات
32 تتابع
461 المتابعون
958 إعجاب
منشورات
الكل
اقتباسات
كان هناك وقت كنت أعتقد فيه أن RWA أمر بسيط للغاية: رفع الأصول إلى البلوك تشين، وتقسيم ملكية الحقوق ثم إتاحة الوصول لعدد أكبر من الناس بحيث يزيد السيولة تلقائيًا.
لكن كلما قرأت أكثر عن Dusk، أدركت أن الرمزنة لا تحل سوى جزء “تمثيل الأصول”، بينما يبقى وراء ذلك في السوق سلسلة من الأسئلة الأصعب التي يجب أن يجيب عنها الواقع.
يمكن ترميز أي سند أو ورقة مالية تقنيًا بسهولة. لكن من المسموح له بالشراء؟ ولمن يمكن تحويل الأصل؟ وكيف تُعترف بحقوق الملكية؟ وكيف يتم التسوية؟ وأي جهة تتحمل المسؤولية إذا نشأ نزاع؟ كل ذلك يعتمد على الإطار القانوني وبنية التشغيل.
لذلك بدأت أفصل بين مفهوميْن اثنين.
تساعد الرمزنة على جعل الأصول أسهل في الإصدار والمتابعة والتحويل داخل بيئة رقمية. أما السيولة فتحتاج إلى مشترين وبائعين، وإمكانية نقل فعلية، وثقة كافية حتى يكون الطرفان على استعداد لإجراء الصفقات.
وهنا أجد أن مسار Dusk لافت للانتباه.
لا ينظر Dusk إلى RWA على أنه مجرد سكّ رمز واحد ووضعه على الـ explorer. فمع الأصول الخاضعة للإدارة، يجب أن تسير معًا الإدارة والخصوصية والأهلية والإفصاح الانتقائي والتسوية، لأن “permissionless” لا يعني بالضرورة أنه مناسب تمامًا للواقع مع الأوراق المالية.
في رأيي، أكبر مشكلة في RWA ليست عدد الأصول التي يمكن للبلوك تشين احتواؤها.
بل ما إذا كانت تلك البنية قادرة على تحويل حقوق الملكية الرقمية إلى سوق يرغب المشاركون فعليًا في التداول فيه.
إذا كانت القوانين لا تزال تحدد من يمكنه الشراء وما زال من الصعب نقل الأصول، فقد يقلل البلوك تشين الاحتكاك لكنه لا يضمن خلق سيولة جديدة.
قد يعني ذلك فقط تشغيل السيولة القديمة بكفاءة أكبر.
@Dusk_Foundation $DUSK #dusk
$DEBIT $TMX
كان هناك وقت كنت أعتقد فيه أن RWA أمر بسيط للغاية: رفع الأصول إلى البلوك تشين، وتقسيم ملكية الحقوق ثم إتاحة الوصول لعدد أكبر من الناس بحيث يزيد السيولة تلقائيًا.
لكن كلما قرأت أكثر عن Dusk، أدركت أن الرمزنة لا تحل سوى جزء “تمثيل الأصول”، بينما يبقى وراء ذلك في السوق سلسلة من الأسئلة الأصعب التي يجب أن يجيب عنها الواقع.
يمكن ترميز أي سند أو ورقة مالية تقنيًا بسهولة. لكن من المسموح له بالشراء؟ ولمن يمكن تحويل الأصل؟ وكيف تُعترف بحقوق الملكية؟ وكيف يتم التسوية؟ وأي جهة تتحمل المسؤولية إذا نشأ نزاع؟ كل ذلك يعتمد على الإطار القانوني وبنية التشغيل.
لذلك بدأت أفصل بين مفهوميْن اثنين.
تساعد الرمزنة على جعل الأصول أسهل في الإصدار والمتابعة والتحويل داخل بيئة رقمية. أما السيولة فتحتاج إلى مشترين وبائعين، وإمكانية نقل فعلية، وثقة كافية حتى يكون الطرفان على استعداد لإجراء الصفقات.
وهنا أجد أن مسار Dusk لافت للانتباه.
لا ينظر Dusk إلى RWA على أنه مجرد سكّ رمز واحد ووضعه على الـ explorer. فمع الأصول الخاضعة للإدارة، يجب أن تسير معًا الإدارة والخصوصية والأهلية والإفصاح الانتقائي والتسوية، لأن “permissionless” لا يعني بالضرورة أنه مناسب تمامًا للواقع مع الأوراق المالية.
في رأيي، أكبر مشكلة في RWA ليست عدد الأصول التي يمكن للبلوك تشين احتواؤها.
بل ما إذا كانت تلك البنية قادرة على تحويل حقوق الملكية الرقمية إلى سوق يرغب المشاركون فعليًا في التداول فيه.
إذا كانت القوانين لا تزال تحدد من يمكنه الشراء وما زال من الصعب نقل الأصول، فقد يقلل البلوك تشين الاحتكاك لكنه لا يضمن خلق سيولة جديدة.
قد يعني ذلك فقط تشغيل السيولة القديمة بكفاءة أكبر.
@Dusk $DUSK #dusk
$DEBIT $TMX
لكن كلما قرأت أكثر عن Dusk، أدركت أن الرمزنة لا تحل سوى جزء “تمثيل الأصول”، بينما يبقى وراء ذلك في السوق سلسلة من الأسئلة الأصعب التي يجب أن يجيب عنها الواقع.
يمكن ترميز أي سند أو ورقة مالية تقنيًا بسهولة. لكن من المسموح له بالشراء؟ ولمن يمكن تحويل الأصل؟ وكيف تُعترف بحقوق الملكية؟ وكيف يتم التسوية؟ وأي جهة تتحمل المسؤولية إذا نشأ نزاع؟ كل ذلك يعتمد على الإطار القانوني وبنية التشغيل.
لذلك بدأت أفصل بين مفهوميْن اثنين.
تساعد الرمزنة على جعل الأصول أسهل في الإصدار والمتابعة والتحويل داخل بيئة رقمية. أما السيولة فتحتاج إلى مشترين وبائعين، وإمكانية نقل فعلية، وثقة كافية حتى يكون الطرفان على استعداد لإجراء الصفقات.
وهنا أجد أن مسار Dusk لافت للانتباه.
لا ينظر Dusk إلى RWA على أنه مجرد سكّ رمز واحد ووضعه على الـ explorer. فمع الأصول الخاضعة للإدارة، يجب أن تسير معًا الإدارة والخصوصية والأهلية والإفصاح الانتقائي والتسوية، لأن “permissionless” لا يعني بالضرورة أنه مناسب تمامًا للواقع مع الأوراق المالية.
في رأيي، أكبر مشكلة في RWA ليست عدد الأصول التي يمكن للبلوك تشين احتواؤها.
بل ما إذا كانت تلك البنية قادرة على تحويل حقوق الملكية الرقمية إلى سوق يرغب المشاركون فعليًا في التداول فيه.
إذا كانت القوانين لا تزال تحدد من يمكنه الشراء وما زال من الصعب نقل الأصول، فقد يقلل البلوك تشين الاحتكاك لكنه لا يضمن خلق سيولة جديدة.
قد يعني ذلك فقط تشغيل السيولة القديمة بكفاءة أكبر.
@Dusk $DUSK #dusk
$DEBIT $TMX
1
1
410
بدأت أجد DUSK أكثر إثارة للاهتمام في الأيام التي لا يعود فيها المخطط (chart) جذابًا جدًا
في فترة من الوقت، كنت أنظر إلى Dusk بشكل أساسي من خلال السعر. عندما يرتفع الحجم (volume) بقوة ويتحرك الـ chart بسرعة، يكون الانطباع أن المشروع يتم إعادة تسعيره بواسطة السوق.
لكن كلما تابعت أكثر، أدركت أن السعر لا يعكس إلا الانتباه الموجود في الوقت الحالي. والأصعب هو معرفة ما إذا كان هذا الانتباه سيتحول إلى احتياج حقيقي لاستخدام الشبكة.
بالنسبة لي، فإن DuskEVM خطوة مهمة في هذه القصة. المطورون المعتادون على Solidity وأدوات Ethereum يمكنهم الوصول إلى Dusk بسهولة أكبر، بينما تظل طبقة التسوية والخصوصية الخاصة محافظَة على جوانب التميّز في النظام.
ما أريد رؤيته لاحقًا ليس مجرد إضافة إشعار partnership.
أريد أن أعرف: بعد أن يصبح دخول المطورين أسهل، هل يبقون لبناء المنتج؟ هل التطبيق يُنشئ معاملات بشكل منتظم؟ هل يتم فعلاً إصدار الأصول المُرمّزة (tokenized) وإتمام التسوية، أم أنها تظهر فقط ضمن خريطة الطريق (roadmap).
تزداد أهمية هذا السؤال لأن $DUSK ما زالت تُصدر لتقديم المكافآت للشبكة. يمكن للانبعاثات (Emission) أن تُغذي الـ staking وأن تدعم الأمان في المراحل الأولى، لكن على المدى الطويل ما زال يجب استيعاب تلك الكمية من الرموز الجديدة عبر طلبٍ حقيقي.
إذا نمت النشاطات ببطء أبطأ من العرض، فإن شمعة جميلة (candle) لن تغيّر الكثير.
أما إذا بدأ الاستخدام في الارتفاع بشكل منتظم حتى بعد أن ينتهي حماس السوق، فسأعتبر ذلك إشارة أَثمن من أي موجة اختراق (breakout).
يخبرني الـ chart بما يولي إليه المتداولون اهتمامًا.
وبالنسبة لنشاط الشبكة الجديد، فهو يخبرني ما إذا كان Dusk يقترب من اقتصادٍ حقيقي أم لا.
@Dusk_Foundation #dusk $TMX $STAR
بدأت أجد DUSK أكثر إثارة للاهتمام في الأيام التي لا يعود فيها المخطط (chart) جذابًا جدًا
في فترة من الوقت، كنت أنظر إلى Dusk بشكل أساسي من خلال السعر. عندما يرتفع الحجم (volume) بقوة ويتحرك الـ chart بسرعة، يكون الانطباع أن المشروع يتم إعادة تسعيره بواسطة السوق.
لكن كلما تابعت أكثر، أدركت أن السعر لا يعكس إلا الانتباه الموجود في الوقت الحالي. والأصعب هو معرفة ما إذا كان هذا الانتباه سيتحول إلى احتياج حقيقي لاستخدام الشبكة.
بالنسبة لي، فإن DuskEVM خطوة مهمة في هذه القصة. المطورون المعتادون على Solidity وأدوات Ethereum يمكنهم الوصول إلى Dusk بسهولة أكبر، بينما تظل طبقة التسوية والخصوصية الخاصة محافظَة على جوانب التميّز في النظام.
ما أريد رؤيته لاحقًا ليس مجرد إضافة إشعار partnership.
أريد أن أعرف: بعد أن يصبح دخول المطورين أسهل، هل يبقون لبناء المنتج؟ هل التطبيق يُنشئ معاملات بشكل منتظم؟ هل يتم فعلاً إصدار الأصول المُرمّزة (tokenized) وإتمام التسوية، أم أنها تظهر فقط ضمن خريطة الطريق (roadmap).
تزداد أهمية هذا السؤال لأن $DUSK ما زالت تُصدر لتقديم المكافآت للشبكة. يمكن للانبعاثات (Emission) أن تُغذي الـ staking وأن تدعم الأمان في المراحل الأولى، لكن على المدى الطويل ما زال يجب استيعاب تلك الكمية من الرموز الجديدة عبر طلبٍ حقيقي.
إذا نمت النشاطات ببطء أبطأ من العرض، فإن شمعة جميلة (candle) لن تغيّر الكثير.
أما إذا بدأ الاستخدام في الارتفاع بشكل منتظم حتى بعد أن ينتهي حماس السوق، فسأعتبر ذلك إشارة أَثمن من أي موجة اختراق (breakout).
يخبرني الـ chart بما يولي إليه المتداولون اهتمامًا.
وبالنسبة لنشاط الشبكة الجديد، فهو يخبرني ما إذا كان Dusk يقترب من اقتصادٍ حقيقي أم لا.
@Dusk #dusk $TMX $STAR
في فترة من الوقت، كنت أنظر إلى Dusk بشكل أساسي من خلال السعر. عندما يرتفع الحجم (volume) بقوة ويتحرك الـ chart بسرعة، يكون الانطباع أن المشروع يتم إعادة تسعيره بواسطة السوق.
لكن كلما تابعت أكثر، أدركت أن السعر لا يعكس إلا الانتباه الموجود في الوقت الحالي. والأصعب هو معرفة ما إذا كان هذا الانتباه سيتحول إلى احتياج حقيقي لاستخدام الشبكة.
بالنسبة لي، فإن DuskEVM خطوة مهمة في هذه القصة. المطورون المعتادون على Solidity وأدوات Ethereum يمكنهم الوصول إلى Dusk بسهولة أكبر، بينما تظل طبقة التسوية والخصوصية الخاصة محافظَة على جوانب التميّز في النظام.
ما أريد رؤيته لاحقًا ليس مجرد إضافة إشعار partnership.
أريد أن أعرف: بعد أن يصبح دخول المطورين أسهل، هل يبقون لبناء المنتج؟ هل التطبيق يُنشئ معاملات بشكل منتظم؟ هل يتم فعلاً إصدار الأصول المُرمّزة (tokenized) وإتمام التسوية، أم أنها تظهر فقط ضمن خريطة الطريق (roadmap).
تزداد أهمية هذا السؤال لأن $DUSK ما زالت تُصدر لتقديم المكافآت للشبكة. يمكن للانبعاثات (Emission) أن تُغذي الـ staking وأن تدعم الأمان في المراحل الأولى، لكن على المدى الطويل ما زال يجب استيعاب تلك الكمية من الرموز الجديدة عبر طلبٍ حقيقي.
إذا نمت النشاطات ببطء أبطأ من العرض، فإن شمعة جميلة (candle) لن تغيّر الكثير.
أما إذا بدأ الاستخدام في الارتفاع بشكل منتظم حتى بعد أن ينتهي حماس السوق، فسأعتبر ذلك إشارة أَثمن من أي موجة اختراق (breakout).
يخبرني الـ chart بما يولي إليه المتداولون اهتمامًا.
وبالنسبة لنشاط الشبكة الجديد، فهو يخبرني ما إذا كان Dusk يقترب من اقتصادٍ حقيقي أم لا.
@Dusk #dusk $TMX $STAR
2
2
203
أنا مهتم أكثر بـ$DUSK عندما يتوقف السعر عن الارتفاع
إن الاندفاع القوي دائمًا ما يسحب الانتباه نحو Dusk، لكنني لا أريد استخدام شموع كدليل على أن فرضية المشروع صحيحة.
ما أراه جديرًا بالمتابعة أكثر موجود في جانب البنية التحتية.
يعمل Dusk على حل مشكلة صعبة إلى حد ما في التمويل على السلسلة (onchain): يجب التحقق من الأصول والالتزام باللوائح، لكن الشركة لا يمكنها أيضًا الكشف عن كامل المراكز أو الهوية أو سجل المعاملات لأي شخص يطّلع على blockchain.
XSC وselective disclosure وDuskEVM كلها تدور حول تلك الحدود.
أما EURQ فيجعل القصة أكثر واقعية، لأن الأوراق المالية المُمَثَّلة عبر الترميز لا تحتاج فقط إلى أن تُنقل إلى السلسلة. بل تحتاج أيضًا إلى وسيلة دفع مناسبة بحيث يمكن تسوية الأموال والأصول ضمن النظام البيئي نفسه.
برأيي، هذه هي الجزئية الأسهل التي يمكن تجاهلها.
يمكن لأي blockchain أن يُرمِّز السندات أو الصناديق، لكن إذا كانت خطوة الدفع لا تزال تتطلب الالتفاف إلى النظام التقليدي، فإن تجربة onchain لن تحل سوى نصف المسألة.
لذلك لست متحمسًا جدًا إذا كان DUSK سيرتفع مع حجم تداول فقط خلال بضعة أيام.
قد يجلب الزخم المتداولين، لكن لا يضمن بقاؤهم.
ما أريد رؤيته بعد أن يبرد السوق هو ما إذا كانت أحجام التداول والمعاملات الفعلية التي يتم فيها settlement للأصول، وكذلك الحاجة إلى استخدام DUSK، تستمر في الزيادة أم لا.
إذا ظل النشاط موجودًا حتى بعد أن يفقد المخطط جاذبيته، عندها فقط يصبح الاندفاع أكثر معنى خارج نطاق المضاربة.
@Dusk_Foundation #dusk $UAI $LAB
أنا مهتم أكثر بـ$DUSK عندما يتوقف السعر عن الارتفاع
إن الاندفاع القوي دائمًا ما يسحب الانتباه نحو Dusk، لكنني لا أريد استخدام شموع كدليل على أن فرضية المشروع صحيحة.
ما أراه جديرًا بالمتابعة أكثر موجود في جانب البنية التحتية.
يعمل Dusk على حل مشكلة صعبة إلى حد ما في التمويل على السلسلة (onchain): يجب التحقق من الأصول والالتزام باللوائح، لكن الشركة لا يمكنها أيضًا الكشف عن كامل المراكز أو الهوية أو سجل المعاملات لأي شخص يطّلع على blockchain.
XSC وselective disclosure وDuskEVM كلها تدور حول تلك الحدود.
أما EURQ فيجعل القصة أكثر واقعية، لأن الأوراق المالية المُمَثَّلة عبر الترميز لا تحتاج فقط إلى أن تُنقل إلى السلسلة. بل تحتاج أيضًا إلى وسيلة دفع مناسبة بحيث يمكن تسوية الأموال والأصول ضمن النظام البيئي نفسه.
برأيي، هذه هي الجزئية الأسهل التي يمكن تجاهلها.
يمكن لأي blockchain أن يُرمِّز السندات أو الصناديق، لكن إذا كانت خطوة الدفع لا تزال تتطلب الالتفاف إلى النظام التقليدي، فإن تجربة onchain لن تحل سوى نصف المسألة.
لذلك لست متحمسًا جدًا إذا كان DUSK سيرتفع مع حجم تداول فقط خلال بضعة أيام.
قد يجلب الزخم المتداولين، لكن لا يضمن بقاؤهم.
ما أريد رؤيته بعد أن يبرد السوق هو ما إذا كانت أحجام التداول والمعاملات الفعلية التي يتم فيها settlement للأصول، وكذلك الحاجة إلى استخدام DUSK، تستمر في الزيادة أم لا.
إذا ظل النشاط موجودًا حتى بعد أن يفقد المخطط جاذبيته، عندها فقط يصبح الاندفاع أكثر معنى خارج نطاق المضاربة.
@Dusk #dusk $UAI $LAB
إن الاندفاع القوي دائمًا ما يسحب الانتباه نحو Dusk، لكنني لا أريد استخدام شموع كدليل على أن فرضية المشروع صحيحة.
ما أراه جديرًا بالمتابعة أكثر موجود في جانب البنية التحتية.
يعمل Dusk على حل مشكلة صعبة إلى حد ما في التمويل على السلسلة (onchain): يجب التحقق من الأصول والالتزام باللوائح، لكن الشركة لا يمكنها أيضًا الكشف عن كامل المراكز أو الهوية أو سجل المعاملات لأي شخص يطّلع على blockchain.
XSC وselective disclosure وDuskEVM كلها تدور حول تلك الحدود.
أما EURQ فيجعل القصة أكثر واقعية، لأن الأوراق المالية المُمَثَّلة عبر الترميز لا تحتاج فقط إلى أن تُنقل إلى السلسلة. بل تحتاج أيضًا إلى وسيلة دفع مناسبة بحيث يمكن تسوية الأموال والأصول ضمن النظام البيئي نفسه.
برأيي، هذه هي الجزئية الأسهل التي يمكن تجاهلها.
يمكن لأي blockchain أن يُرمِّز السندات أو الصناديق، لكن إذا كانت خطوة الدفع لا تزال تتطلب الالتفاف إلى النظام التقليدي، فإن تجربة onchain لن تحل سوى نصف المسألة.
لذلك لست متحمسًا جدًا إذا كان DUSK سيرتفع مع حجم تداول فقط خلال بضعة أيام.
قد يجلب الزخم المتداولين، لكن لا يضمن بقاؤهم.
ما أريد رؤيته بعد أن يبرد السوق هو ما إذا كانت أحجام التداول والمعاملات الفعلية التي يتم فيها settlement للأصول، وكذلك الحاجة إلى استخدام DUSK، تستمر في الزيادة أم لا.
إذا ظل النشاط موجودًا حتى بعد أن يفقد المخطط جاذبيته، عندها فقط يصبح الاندفاع أكثر معنى خارج نطاق المضاربة.
@Dusk #dusk $UAI $LAB
1
2
580
يُشعل JubJub انتباهي إلى أكثر الأجزاء التي نادرًا ما يُشار إليها في قصة الخصوصية لدى Dusk
عندما نتحدث عن Dusk، يكون أوضح ما يمكن رؤيته هو معاملات سرية (confidential transactions)، والإفصاح الانتقائي (selective disclosure)، أو الأصول المالية الخاصة. لكن كلما قرأت أكثر في طبقات الشيفرة أسفل ذلك، وجدت أن JubJub أكثر إثارة للاهتمام بكثير مما يوحي به اسمه.
JubJub هي منحنى إهليلجي صُمّم ليعمل بكفاءة في بيئة صديقة لـ SNARK. ومع Dusk، هذا مهم لأن الخصوصية ليست مجرد إخفاء البيانات على الواجهة. يجب أن تكون إثباتات المعرفة الصفرية قادرة على التحقق من أن المعاملة تلتزم بالقواعد الصحيحة دون إجبار البيانات الحساسة على الانكشاف.
تُظهر Phoenix هذا الدور بوضوح. تُبنى العناوين المُحصّنة (shielded) في Phoenix من نقاط على JubJub، بينما يقوم Dusk أيضًا بضم بدائيات مثل Schnorr وPoseidon وPLONK ضمن مكدس التشفير الخاص به.
ما يعجبني هنا هو أن Dusk لا يحاول تحويل JubJub إلى سردية منفصلة. الأمر يشبه قطعة ميكانيكية عميقة داخل المحرك: لا يحتاج المستخدمون تقريبًا إلى معرفة أنها موجودة، لكن اختيار بدائيات غير مناسبة قد يجعل الإثبات أثقل أو أصعب في التكامل.
بالطبع، لا يصنع مكدس تشفير جميل بحد ذاته اعتمادًا (adoption). ما زال يجب أن يثبت Dusk أن المطورين والمؤسسات والأصول الحقيقية تحتاج فعلًا إلى هذا البنية التحتية.
لكن إذا كنت تريد فهم ما إذا كانت سلسلة خصوصية ما تقدم عملًا هندسيًا جادًا أم لا، فأنا أعتقد أنه ينبغي أن تنظر إلى ما تحت كلمات التسويق.
أحيانًا يكون أكثر ما يستحق المشاهدة هو الجزء الذي لا يملك رمز تداول (ticker)، ولا حملة، ولا أحد يروج له.
@Dusk_Foundation $DUSK #dusk $AOP $4
يُشعل JubJub انتباهي إلى أكثر الأجزاء التي نادرًا ما يُشار إليها في قصة الخصوصية لدى Dusk
عندما نتحدث عن Dusk، يكون أوضح ما يمكن رؤيته هو معاملات سرية (confidential transactions)، والإفصاح الانتقائي (selective disclosure)، أو الأصول المالية الخاصة. لكن كلما قرأت أكثر في طبقات الشيفرة أسفل ذلك، وجدت أن JubJub أكثر إثارة للاهتمام بكثير مما يوحي به اسمه.
JubJub هي منحنى إهليلجي صُمّم ليعمل بكفاءة في بيئة صديقة لـ SNARK. ومع Dusk، هذا مهم لأن الخصوصية ليست مجرد إخفاء البيانات على الواجهة. يجب أن تكون إثباتات المعرفة الصفرية قادرة على التحقق من أن المعاملة تلتزم بالقواعد الصحيحة دون إجبار البيانات الحساسة على الانكشاف.
تُظهر Phoenix هذا الدور بوضوح. تُبنى العناوين المُحصّنة (shielded) في Phoenix من نقاط على JubJub، بينما يقوم Dusk أيضًا بضم بدائيات مثل Schnorr وPoseidon وPLONK ضمن مكدس التشفير الخاص به.
ما يعجبني هنا هو أن Dusk لا يحاول تحويل JubJub إلى سردية منفصلة. الأمر يشبه قطعة ميكانيكية عميقة داخل المحرك: لا يحتاج المستخدمون تقريبًا إلى معرفة أنها موجودة، لكن اختيار بدائيات غير مناسبة قد يجعل الإثبات أثقل أو أصعب في التكامل.
بالطبع، لا يصنع مكدس تشفير جميل بحد ذاته اعتمادًا (adoption). ما زال يجب أن يثبت Dusk أن المطورين والمؤسسات والأصول الحقيقية تحتاج فعلًا إلى هذا البنية التحتية.
لكن إذا كنت تريد فهم ما إذا كانت سلسلة خصوصية ما تقدم عملًا هندسيًا جادًا أم لا، فأنا أعتقد أنه ينبغي أن تنظر إلى ما تحت كلمات التسويق.
أحيانًا يكون أكثر ما يستحق المشاهدة هو الجزء الذي لا يملك رمز تداول (ticker)، ولا حملة، ولا أحد يروج له.
@Dusk $DUSK #dusk $AOP $4
عندما نتحدث عن Dusk، يكون أوضح ما يمكن رؤيته هو معاملات سرية (confidential transactions)، والإفصاح الانتقائي (selective disclosure)، أو الأصول المالية الخاصة. لكن كلما قرأت أكثر في طبقات الشيفرة أسفل ذلك، وجدت أن JubJub أكثر إثارة للاهتمام بكثير مما يوحي به اسمه.
JubJub هي منحنى إهليلجي صُمّم ليعمل بكفاءة في بيئة صديقة لـ SNARK. ومع Dusk، هذا مهم لأن الخصوصية ليست مجرد إخفاء البيانات على الواجهة. يجب أن تكون إثباتات المعرفة الصفرية قادرة على التحقق من أن المعاملة تلتزم بالقواعد الصحيحة دون إجبار البيانات الحساسة على الانكشاف.
تُظهر Phoenix هذا الدور بوضوح. تُبنى العناوين المُحصّنة (shielded) في Phoenix من نقاط على JubJub، بينما يقوم Dusk أيضًا بضم بدائيات مثل Schnorr وPoseidon وPLONK ضمن مكدس التشفير الخاص به.
ما يعجبني هنا هو أن Dusk لا يحاول تحويل JubJub إلى سردية منفصلة. الأمر يشبه قطعة ميكانيكية عميقة داخل المحرك: لا يحتاج المستخدمون تقريبًا إلى معرفة أنها موجودة، لكن اختيار بدائيات غير مناسبة قد يجعل الإثبات أثقل أو أصعب في التكامل.
بالطبع، لا يصنع مكدس تشفير جميل بحد ذاته اعتمادًا (adoption). ما زال يجب أن يثبت Dusk أن المطورين والمؤسسات والأصول الحقيقية تحتاج فعلًا إلى هذا البنية التحتية.
لكن إذا كنت تريد فهم ما إذا كانت سلسلة خصوصية ما تقدم عملًا هندسيًا جادًا أم لا، فأنا أعتقد أنه ينبغي أن تنظر إلى ما تحت كلمات التسويق.
أحيانًا يكون أكثر ما يستحق المشاهدة هو الجزء الذي لا يملك رمز تداول (ticker)، ولا حملة، ولا أحد يروج له.
@Dusk $DUSK #dusk $AOP $4
2
2
202
يعمل Dusk على التحول من “سلسلة خصوصية” إلى بنية تحتية متعددة الطبقات وأكثر وضوحًا
في السابق، عندما كنت أنظر إلى Dusk، كان اهتمامي تقريبًا منصبًا على الخصوصية فقط. وهذا مفهوم، لأن المشروع قضى عدة سنوات في بناء بنية تحتية للتمويل السري قبل إطلاق mainnet في بداية عام 2025.
لكن كلما تابعت التحديثات اللاحقة، وجدت أن الجزء الأكثر جدارة بالملاحظة هو الطريقة التي يفصل بها Dusk كل مهمة من مهام الشبكة إلى وحدات مستقلة.
يركز DuskDS على الإجماع (consensus) والـ staking وتوافر البيانات (data availability) والتسوية (settlement). بينما يهيئ DuskEVM بيئة مألوفة أكثر لمطوري Solidity. ما زالت الخصوصية موجودة، لكن لم تعد شرطًا إلزاميًا لكل تطبيق.
برأيي، هذا تغيير مهم جدًا.
إن بلوكتشين تمتلك تقنية خصوصية قوية، لكن تُجبر المطورين على تعلم الكثير من الأشياء الجديدة، فستعمل تلقائيًا على تضييق دائرة من يمكنهم البناء عليها. إدخال EVM يساعد على تقليل تكلفة التحول، بينما تظل طبقات التسوية والخصوصية المنفصلة محافظةً على ما يجعل Dusk مختلفًا عن أي سلسلة EVM عادية.
لذلك، أرى التحديثات مثل blob transactions أو PLONK V2 كجزء من تجهيزات البنية التحتية أكثر من كونها “ميزة جديدة”.
لكن التصميم الجميل على الورق لا يقول الكثير.
ما أريد رؤيته هو: هل سيحافظ DuskEVM على نشاط المطورين على المدى الطويل؟ وهل ستزداد كمية المعاملات فعليًا؟ وأي أصول مالية في النهاية سيتم تسويتها عبر DuskDS بدلًا من أن تقف عند مجرد عروض (demo) أو إعلانات (announcement).
إذا ظهرت هذه الأرقام، فسيكون لفصل التنفيذ عن التسوية معنى عملي.
وإن لم تظهر، فـ Dusk يكون قد حل مشكلة التصميم فقط، لكنه لم يحل مشكلة التبنّي (adoption).
@Dusk_Foundation $DUSK #dusk
$UP $MarsCoin
يعمل Dusk على التحول من “سلسلة خصوصية” إلى بنية تحتية متعددة الطبقات وأكثر وضوحًا
في السابق، عندما كنت أنظر إلى Dusk، كان اهتمامي تقريبًا منصبًا على الخصوصية فقط. وهذا مفهوم، لأن المشروع قضى عدة سنوات في بناء بنية تحتية للتمويل السري قبل إطلاق mainnet في بداية عام 2025.
لكن كلما تابعت التحديثات اللاحقة، وجدت أن الجزء الأكثر جدارة بالملاحظة هو الطريقة التي يفصل بها Dusk كل مهمة من مهام الشبكة إلى وحدات مستقلة.
يركز DuskDS على الإجماع (consensus) والـ staking وتوافر البيانات (data availability) والتسوية (settlement). بينما يهيئ DuskEVM بيئة مألوفة أكثر لمطوري Solidity. ما زالت الخصوصية موجودة، لكن لم تعد شرطًا إلزاميًا لكل تطبيق.
برأيي، هذا تغيير مهم جدًا.
إن بلوكتشين تمتلك تقنية خصوصية قوية، لكن تُجبر المطورين على تعلم الكثير من الأشياء الجديدة، فستعمل تلقائيًا على تضييق دائرة من يمكنهم البناء عليها. إدخال EVM يساعد على تقليل تكلفة التحول، بينما تظل طبقات التسوية والخصوصية المنفصلة محافظةً على ما يجعل Dusk مختلفًا عن أي سلسلة EVM عادية.
لذلك، أرى التحديثات مثل blob transactions أو PLONK V2 كجزء من تجهيزات البنية التحتية أكثر من كونها “ميزة جديدة”.
لكن التصميم الجميل على الورق لا يقول الكثير.
ما أريد رؤيته هو: هل سيحافظ DuskEVM على نشاط المطورين على المدى الطويل؟ وهل ستزداد كمية المعاملات فعليًا؟ وأي أصول مالية في النهاية سيتم تسويتها عبر DuskDS بدلًا من أن تقف عند مجرد عروض (demo) أو إعلانات (announcement).
إذا ظهرت هذه الأرقام، فسيكون لفصل التنفيذ عن التسوية معنى عملي.
وإن لم تظهر، فـ Dusk يكون قد حل مشكلة التصميم فقط، لكنه لم يحل مشكلة التبنّي (adoption).
@Dusk $DUSK #dusk
$UP $MarsCoin
في السابق، عندما كنت أنظر إلى Dusk، كان اهتمامي تقريبًا منصبًا على الخصوصية فقط. وهذا مفهوم، لأن المشروع قضى عدة سنوات في بناء بنية تحتية للتمويل السري قبل إطلاق mainnet في بداية عام 2025.
لكن كلما تابعت التحديثات اللاحقة، وجدت أن الجزء الأكثر جدارة بالملاحظة هو الطريقة التي يفصل بها Dusk كل مهمة من مهام الشبكة إلى وحدات مستقلة.
يركز DuskDS على الإجماع (consensus) والـ staking وتوافر البيانات (data availability) والتسوية (settlement). بينما يهيئ DuskEVM بيئة مألوفة أكثر لمطوري Solidity. ما زالت الخصوصية موجودة، لكن لم تعد شرطًا إلزاميًا لكل تطبيق.
برأيي، هذا تغيير مهم جدًا.
إن بلوكتشين تمتلك تقنية خصوصية قوية، لكن تُجبر المطورين على تعلم الكثير من الأشياء الجديدة، فستعمل تلقائيًا على تضييق دائرة من يمكنهم البناء عليها. إدخال EVM يساعد على تقليل تكلفة التحول، بينما تظل طبقات التسوية والخصوصية المنفصلة محافظةً على ما يجعل Dusk مختلفًا عن أي سلسلة EVM عادية.
لذلك، أرى التحديثات مثل blob transactions أو PLONK V2 كجزء من تجهيزات البنية التحتية أكثر من كونها “ميزة جديدة”.
لكن التصميم الجميل على الورق لا يقول الكثير.
ما أريد رؤيته هو: هل سيحافظ DuskEVM على نشاط المطورين على المدى الطويل؟ وهل ستزداد كمية المعاملات فعليًا؟ وأي أصول مالية في النهاية سيتم تسويتها عبر DuskDS بدلًا من أن تقف عند مجرد عروض (demo) أو إعلانات (announcement).
إذا ظهرت هذه الأرقام، فسيكون لفصل التنفيذ عن التسوية معنى عملي.
وإن لم تظهر، فـ Dusk يكون قد حل مشكلة التصميم فقط، لكنه لم يحل مشكلة التبنّي (adoption).
@Dusk $DUSK #dusk
$UP $MarsCoin
1
1
198
تمّ التحقق
93% أمن TermMax ملفت للنظر، لكنني لا أعتبره دليلاً نهائياً
غالباً ما أتصفح بسرعة صفحات الأمن لأن معظم البروتوكولات تتضمن نفس مجموعة الكلمات المفتاحية: التدقيق (audit)، برنامج مكافآت الأخطاء (bug bounty)، المراقبة (monitoring)، وtimelock. لكن TermMax جعلني أتوقف عندما رأيت أن DeFiSafety منحته 93%—وهو نفس المستوى الذي تستخدمه المشاريع للمقارنة مع Aave V3.
هذا الرقم جيد، لكن برأيي الأهم هو طريقة فهمه أكثر من كونه مجرد درجة.
لا تقوم DeFiSafety بمراجعة كود الذكي مباشرةً. بل تقيم العملية، والوثائق، ومدى الشفافية، وكيف يطبق البروتوكول ممارسات الأمان. لذلك فإن 93% تعني أن لدى TermMax عملية أمنية مبنية بشكل جيد—وليست دليلاً على أن عقده الذكي ثبت أنه «آمن بنسبة 93%».
بالنظر إلى التكديس الحالي (stack)، لدى TermMax عدة طبقات مختلفة: audit لاكتشاف الأخطاء قبل النشر، وbug bounty لفتح مساحة إضافية للتحقق، وHypernative لمتابعة الحالات غير الطبيعية بعد تشغيل النظام، وtimelock لإبطاء التغييرات الحساسة. كل طبقة تتعامل مع نوع مختلف من المخاطر.
لكن هناك شيئاً لا يمكن شراؤه بالـaudit.
وهو سجلّ النجاة عبر السوق الحقيقي.
لدى Aave V3 ميزة لأنها تعمل منذ سنوات عديدة ومرت بمواقف ضغط كثيرة. لا يملك TermMax حتى الآن نفس مقدار البيانات القتالية (على أرض الواقع).
لذلك لن أسأل: هل TermMax آمن؟
أريد أن أعرف كيف يتفاعل stack الأمن هذا عندما تتذبذب السيولة بقوة، أو يتعرض الـoracle لضغط، أو يظهر edge case حقيقي على الشبكة الرئيسية (mainnet).
الدرجات تخبرنا إلى أي مدى يستعد البروتوكول بشكل جدي.
وسجلّ الأداء (track record) الجديد يخبرنا إلى أي حدّ تتحمل تلك الاستعدادات الواقع.
@termmax #TermMax
$BEAT $BTC $ARX
93% أمن TermMax ملفت للنظر، لكنني لا أعتبره دليلاً نهائياً
غالباً ما أتصفح بسرعة صفحات الأمن لأن معظم البروتوكولات تتضمن نفس مجموعة الكلمات المفتاحية: التدقيق (audit)، برنامج مكافآت الأخطاء (bug bounty)، المراقبة (monitoring)، وtimelock. لكن TermMax جعلني أتوقف عندما رأيت أن DeFiSafety منحته 93%—وهو نفس المستوى الذي تستخدمه المشاريع للمقارنة مع Aave V3.
هذا الرقم جيد، لكن برأيي الأهم هو طريقة فهمه أكثر من كونه مجرد درجة.
لا تقوم DeFiSafety بمراجعة كود الذكي مباشرةً. بل تقيم العملية، والوثائق، ومدى الشفافية، وكيف يطبق البروتوكول ممارسات الأمان. لذلك فإن 93% تعني أن لدى TermMax عملية أمنية مبنية بشكل جيد—وليست دليلاً على أن عقده الذكي ثبت أنه «آمن بنسبة 93%».
بالنظر إلى التكديس الحالي (stack)، لدى TermMax عدة طبقات مختلفة: audit لاكتشاف الأخطاء قبل النشر، وbug bounty لفتح مساحة إضافية للتحقق، وHypernative لمتابعة الحالات غير الطبيعية بعد تشغيل النظام، وtimelock لإبطاء التغييرات الحساسة. كل طبقة تتعامل مع نوع مختلف من المخاطر.
لكن هناك شيئاً لا يمكن شراؤه بالـaudit.
وهو سجلّ النجاة عبر السوق الحقيقي.
لدى Aave V3 ميزة لأنها تعمل منذ سنوات عديدة ومرت بمواقف ضغط كثيرة. لا يملك TermMax حتى الآن نفس مقدار البيانات القتالية (على أرض الواقع).
لذلك لن أسأل: هل TermMax آمن؟
أريد أن أعرف كيف يتفاعل stack الأمن هذا عندما تتذبذب السيولة بقوة، أو يتعرض الـoracle لضغط، أو يظهر edge case حقيقي على الشبكة الرئيسية (mainnet).
الدرجات تخبرنا إلى أي مدى يستعد البروتوكول بشكل جدي.
وسجلّ الأداء (track record) الجديد يخبرنا إلى أي حدّ تتحمل تلك الاستعدادات الواقع.
@TermMax #TermMax
$BEAT $BTC $ARX
غالباً ما أتصفح بسرعة صفحات الأمن لأن معظم البروتوكولات تتضمن نفس مجموعة الكلمات المفتاحية: التدقيق (audit)، برنامج مكافآت الأخطاء (bug bounty)، المراقبة (monitoring)، وtimelock. لكن TermMax جعلني أتوقف عندما رأيت أن DeFiSafety منحته 93%—وهو نفس المستوى الذي تستخدمه المشاريع للمقارنة مع Aave V3.
هذا الرقم جيد، لكن برأيي الأهم هو طريقة فهمه أكثر من كونه مجرد درجة.
لا تقوم DeFiSafety بمراجعة كود الذكي مباشرةً. بل تقيم العملية، والوثائق، ومدى الشفافية، وكيف يطبق البروتوكول ممارسات الأمان. لذلك فإن 93% تعني أن لدى TermMax عملية أمنية مبنية بشكل جيد—وليست دليلاً على أن عقده الذكي ثبت أنه «آمن بنسبة 93%».
بالنظر إلى التكديس الحالي (stack)، لدى TermMax عدة طبقات مختلفة: audit لاكتشاف الأخطاء قبل النشر، وbug bounty لفتح مساحة إضافية للتحقق، وHypernative لمتابعة الحالات غير الطبيعية بعد تشغيل النظام، وtimelock لإبطاء التغييرات الحساسة. كل طبقة تتعامل مع نوع مختلف من المخاطر.
لكن هناك شيئاً لا يمكن شراؤه بالـaudit.
وهو سجلّ النجاة عبر السوق الحقيقي.
لدى Aave V3 ميزة لأنها تعمل منذ سنوات عديدة ومرت بمواقف ضغط كثيرة. لا يملك TermMax حتى الآن نفس مقدار البيانات القتالية (على أرض الواقع).
لذلك لن أسأل: هل TermMax آمن؟
أريد أن أعرف كيف يتفاعل stack الأمن هذا عندما تتذبذب السيولة بقوة، أو يتعرض الـoracle لضغط، أو يظهر edge case حقيقي على الشبكة الرئيسية (mainnet).
الدرجات تخبرنا إلى أي مدى يستعد البروتوكول بشكل جدي.
وسجلّ الأداء (track record) الجديد يخبرنا إلى أي حدّ تتحمل تلك الاستعدادات الواقع.
@TermMax #TermMax
$BEAT $BTC $ARX
1
2
715
يقلّل Citadel مشاركة البيانات المطلوبة، لكنه يجعلني منتبهًا أكثر إلى جهة إصدار بيانات الاعتماد
النقطة التي أعجبتني في Citadel هي أن المستخدم لا يحتاج إلى تقديم ملف KYC كامل لكل طرف يريد التحقق منه.
بعد إتمام الفحص، يمكن استخدام بيانات اعتماد لإثبات أشياء محددة مثل الاختصاص القضائي أو حالة المستثمر أو استيفاء شرط امتثال معيّن. تحصل جهة التحقق على المعلومات الضرورية فقط بدلًا من مجموعة بيانات الهوية بأكملها.
في البداية ظننت أن الأمر ببساطة تقليل الثقة.
لكن عند التدقيق، تبيّن أن الثقة لا تختفي بل تُنقل إلى موضع آخر.
إذا وافقت عدة مؤسسات على بيانات اعتماد واحدة، يصبح قرار المُصدر الأولي أكثر وزنًا. يمكن إعادة استخدام تقييم واحد عدة مرات، لذلك قد تنتشر أي أخطاء في مرحلة إصدار بيانات الاعتماد بدلًا من أن تؤثر فقط في معاملة واحدة.
والوقت يجعل المسألة أكثر تعقيدًا. قد تكون بيانات الاعتماد صحيحة اليوم لكنها لا تكون صحيحة بعد بضعة أشهر. يمكن أن تتغير حالة العقوبات (sanctions) أو الاختصاص القضائي (jurisdiction) أو الأهلية (eligibility).
لذلك، بالنسبة لي، الجزء الأهم في Citadel لا يقتصر على الإخفاء الانتقائي. بل يتعلق أيضًا بالحداثة (freshness) والإلغاء (revocation) ومسؤولية المُصدر عندما تتغير البيانات الأساسية.
سأهتم كذلك بعدد بيانات الاعتماد التي يتم فعلًا إعادة استخدامها، أكثر من عدد عمليات التكامل التي يتم الإعلان عنها.
فالحفاظ على الخصوصية يعالج سؤال “كم يجب أن يرى طرف التحقق”.
أما عندما تكون بيانات الاعتماد خاطئة أو قديمة، فإن السؤال الأصعب يبقى كما هو: من يتحمل المسؤولية عن قرار وثقته منظومة بأكملها؟
@Dusk_Foundation $DUSK #dusk
$APR $BNB
يقلّل Citadel مشاركة البيانات المطلوبة، لكنه يجعلني منتبهًا أكثر إلى جهة إصدار بيانات الاعتماد
النقطة التي أعجبتني في Citadel هي أن المستخدم لا يحتاج إلى تقديم ملف KYC كامل لكل طرف يريد التحقق منه.
بعد إتمام الفحص، يمكن استخدام بيانات اعتماد لإثبات أشياء محددة مثل الاختصاص القضائي أو حالة المستثمر أو استيفاء شرط امتثال معيّن. تحصل جهة التحقق على المعلومات الضرورية فقط بدلًا من مجموعة بيانات الهوية بأكملها.
في البداية ظننت أن الأمر ببساطة تقليل الثقة.
لكن عند التدقيق، تبيّن أن الثقة لا تختفي بل تُنقل إلى موضع آخر.
إذا وافقت عدة مؤسسات على بيانات اعتماد واحدة، يصبح قرار المُصدر الأولي أكثر وزنًا. يمكن إعادة استخدام تقييم واحد عدة مرات، لذلك قد تنتشر أي أخطاء في مرحلة إصدار بيانات الاعتماد بدلًا من أن تؤثر فقط في معاملة واحدة.
والوقت يجعل المسألة أكثر تعقيدًا. قد تكون بيانات الاعتماد صحيحة اليوم لكنها لا تكون صحيحة بعد بضعة أشهر. يمكن أن تتغير حالة العقوبات (sanctions) أو الاختصاص القضائي (jurisdiction) أو الأهلية (eligibility).
لذلك، بالنسبة لي، الجزء الأهم في Citadel لا يقتصر على الإخفاء الانتقائي. بل يتعلق أيضًا بالحداثة (freshness) والإلغاء (revocation) ومسؤولية المُصدر عندما تتغير البيانات الأساسية.
سأهتم كذلك بعدد بيانات الاعتماد التي يتم فعلًا إعادة استخدامها، أكثر من عدد عمليات التكامل التي يتم الإعلان عنها.
فالحفاظ على الخصوصية يعالج سؤال “كم يجب أن يرى طرف التحقق”.
أما عندما تكون بيانات الاعتماد خاطئة أو قديمة، فإن السؤال الأصعب يبقى كما هو: من يتحمل المسؤولية عن قرار وثقته منظومة بأكملها؟
@Dusk $DUSK #dusk
$APR $BNB
النقطة التي أعجبتني في Citadel هي أن المستخدم لا يحتاج إلى تقديم ملف KYC كامل لكل طرف يريد التحقق منه.
بعد إتمام الفحص، يمكن استخدام بيانات اعتماد لإثبات أشياء محددة مثل الاختصاص القضائي أو حالة المستثمر أو استيفاء شرط امتثال معيّن. تحصل جهة التحقق على المعلومات الضرورية فقط بدلًا من مجموعة بيانات الهوية بأكملها.
في البداية ظننت أن الأمر ببساطة تقليل الثقة.
لكن عند التدقيق، تبيّن أن الثقة لا تختفي بل تُنقل إلى موضع آخر.
إذا وافقت عدة مؤسسات على بيانات اعتماد واحدة، يصبح قرار المُصدر الأولي أكثر وزنًا. يمكن إعادة استخدام تقييم واحد عدة مرات، لذلك قد تنتشر أي أخطاء في مرحلة إصدار بيانات الاعتماد بدلًا من أن تؤثر فقط في معاملة واحدة.
والوقت يجعل المسألة أكثر تعقيدًا. قد تكون بيانات الاعتماد صحيحة اليوم لكنها لا تكون صحيحة بعد بضعة أشهر. يمكن أن تتغير حالة العقوبات (sanctions) أو الاختصاص القضائي (jurisdiction) أو الأهلية (eligibility).
لذلك، بالنسبة لي، الجزء الأهم في Citadel لا يقتصر على الإخفاء الانتقائي. بل يتعلق أيضًا بالحداثة (freshness) والإلغاء (revocation) ومسؤولية المُصدر عندما تتغير البيانات الأساسية.
سأهتم كذلك بعدد بيانات الاعتماد التي يتم فعلًا إعادة استخدامها، أكثر من عدد عمليات التكامل التي يتم الإعلان عنها.
فالحفاظ على الخصوصية يعالج سؤال “كم يجب أن يرى طرف التحقق”.
أما عندما تكون بيانات الاعتماد خاطئة أو قديمة، فإن السؤال الأصعب يبقى كما هو: من يتحمل المسؤولية عن قرار وثقته منظومة بأكملها؟
@Dusk $DUSK #dusk
$APR $BNB
4
3
189
صحيح جزئيًا
كلما واجهت Dusk مشكلة، زاد اهتمامي بمن يتولى زمام استعادة الشبكة
عند قراءة جزء الـ consensus الخاص بـ Dusk، أرى أن الآلية العادية ليست أكثر ما يستدعي القلق. ما هو مثير للاهتمام هو اللحظة التي لا تتمكن فيها الشبكة من الوصول إلى quorum باستمرار.
بعد 16 iteration فاشلة، ينتقل Succinct Attestation إلى وضع الطوارئ. يتم إلغاء timeout لكل خطوة، ويمكن فتح عدة iterations في الوقت نفسه لزيادة فرصة العثور على block صالح. إذا وصل أكثر من candidate إلى consensus في آن واحد، يتم تفضيل block الخاصة بالـ iteration الأقل.
يساعد هذا التصميم الشبكة على عدم التعطل فقط بسبب بعض الـ provisioners البطيئين أو الذين فقدوا الاتصال. لكن ذلك جعلني منتبهًا أيضًا إلى خط فاصل آخر: عندما تسوء ظروف الشبكة، تصبح إمكانية الاستعادة أكثر اعتمادًا بشكل واضح على توزيع الـ stake.
في السيناريو الأخير، لا يتم إنشاء emergency block إلا عندما يطلبها فريق الـ provisioner وأن تمتلك الأغلبية من إجمالي stake في الشبكة. وفي حين يرغب المرء في المشاركة مباشرة في الـ consensus، يحتاج الـ provisioner حاليًا إلى stake بحد أدنى 1.000 DUSK.
لذلك لا أنظر إلى الـ staking فقط على أنه وسيلة لكسب المكافآت. بل إنه يحدد أيضًا من يملك وزناً عندما يحتاج النظام إلى الخروج من حالة غير طبيعية.
برأيي، الاختبار الأهم لـ Dusk ليس يومًا تعمل فيه الشبكة بسلاسة. بل هو عندما يزيد الازدحام، وتتأخر بعض الـ nodes، وتستمر اللجان (committees) في التبدل—وهل تتمكن الشبكة من التعافي دون أن يتم حشر سلطة اتخاذ القرار بشكل مفرط في مجموعة كبيرة من الـ stake.
قد تكون آلية recovery مضمونة تقنيًا.
لكن إذا كانت سلطة إنقاذ الشبكة تتزايد تركّزًا مع الـ stake، فالتـ decentralization هي ما ينبغي قياسه بدقة أكبر.
@Dusk_Foundation $DUSK #dusk
$ONDO $BTC
كلما واجهت Dusk مشكلة، زاد اهتمامي بمن يتولى زمام استعادة الشبكة
عند قراءة جزء الـ consensus الخاص بـ Dusk، أرى أن الآلية العادية ليست أكثر ما يستدعي القلق. ما هو مثير للاهتمام هو اللحظة التي لا تتمكن فيها الشبكة من الوصول إلى quorum باستمرار.
بعد 16 iteration فاشلة، ينتقل Succinct Attestation إلى وضع الطوارئ. يتم إلغاء timeout لكل خطوة، ويمكن فتح عدة iterations في الوقت نفسه لزيادة فرصة العثور على block صالح. إذا وصل أكثر من candidate إلى consensus في آن واحد، يتم تفضيل block الخاصة بالـ iteration الأقل.
يساعد هذا التصميم الشبكة على عدم التعطل فقط بسبب بعض الـ provisioners البطيئين أو الذين فقدوا الاتصال. لكن ذلك جعلني منتبهًا أيضًا إلى خط فاصل آخر: عندما تسوء ظروف الشبكة، تصبح إمكانية الاستعادة أكثر اعتمادًا بشكل واضح على توزيع الـ stake.
في السيناريو الأخير، لا يتم إنشاء emergency block إلا عندما يطلبها فريق الـ provisioner وأن تمتلك الأغلبية من إجمالي stake في الشبكة. وفي حين يرغب المرء في المشاركة مباشرة في الـ consensus، يحتاج الـ provisioner حاليًا إلى stake بحد أدنى 1.000 DUSK.
لذلك لا أنظر إلى الـ staking فقط على أنه وسيلة لكسب المكافآت. بل إنه يحدد أيضًا من يملك وزناً عندما يحتاج النظام إلى الخروج من حالة غير طبيعية.
برأيي، الاختبار الأهم لـ Dusk ليس يومًا تعمل فيه الشبكة بسلاسة. بل هو عندما يزيد الازدحام، وتتأخر بعض الـ nodes، وتستمر اللجان (committees) في التبدل—وهل تتمكن الشبكة من التعافي دون أن يتم حشر سلطة اتخاذ القرار بشكل مفرط في مجموعة كبيرة من الـ stake.
قد تكون آلية recovery مضمونة تقنيًا.
لكن إذا كانت سلطة إنقاذ الشبكة تتزايد تركّزًا مع الـ stake، فالتـ decentralization هي ما ينبغي قياسه بدقة أكبر.
@Dusk $DUSK #dusk
$ONDO $BTC
عند قراءة جزء الـ consensus الخاص بـ Dusk، أرى أن الآلية العادية ليست أكثر ما يستدعي القلق. ما هو مثير للاهتمام هو اللحظة التي لا تتمكن فيها الشبكة من الوصول إلى quorum باستمرار.
بعد 16 iteration فاشلة، ينتقل Succinct Attestation إلى وضع الطوارئ. يتم إلغاء timeout لكل خطوة، ويمكن فتح عدة iterations في الوقت نفسه لزيادة فرصة العثور على block صالح. إذا وصل أكثر من candidate إلى consensus في آن واحد، يتم تفضيل block الخاصة بالـ iteration الأقل.
يساعد هذا التصميم الشبكة على عدم التعطل فقط بسبب بعض الـ provisioners البطيئين أو الذين فقدوا الاتصال. لكن ذلك جعلني منتبهًا أيضًا إلى خط فاصل آخر: عندما تسوء ظروف الشبكة، تصبح إمكانية الاستعادة أكثر اعتمادًا بشكل واضح على توزيع الـ stake.
في السيناريو الأخير، لا يتم إنشاء emergency block إلا عندما يطلبها فريق الـ provisioner وأن تمتلك الأغلبية من إجمالي stake في الشبكة. وفي حين يرغب المرء في المشاركة مباشرة في الـ consensus، يحتاج الـ provisioner حاليًا إلى stake بحد أدنى 1.000 DUSK.
لذلك لا أنظر إلى الـ staking فقط على أنه وسيلة لكسب المكافآت. بل إنه يحدد أيضًا من يملك وزناً عندما يحتاج النظام إلى الخروج من حالة غير طبيعية.
برأيي، الاختبار الأهم لـ Dusk ليس يومًا تعمل فيه الشبكة بسلاسة. بل هو عندما يزيد الازدحام، وتتأخر بعض الـ nodes، وتستمر اللجان (committees) في التبدل—وهل تتمكن الشبكة من التعافي دون أن يتم حشر سلطة اتخاذ القرار بشكل مفرط في مجموعة كبيرة من الـ stake.
قد تكون آلية recovery مضمونة تقنيًا.
لكن إذا كانت سلطة إنقاذ الشبكة تتزايد تركّزًا مع الـ stake، فالتـ decentralization هي ما ينبغي قياسه بدقة أكبر.
@Dusk $DUSK #dusk
$ONDO $BTC
5
3
612
لم يكن إجمالي القيمة المقفلة (TVL) الكبير بالضرورة كافيًا للحكم على كفاءة استخدام رأس المال لدى TermMax
ما يثير اهتمامي في DeFi هو أن السيولة قد تبدو “سميكة جدًا” على لوحة المعلومات، لكنها في الواقع تبقى ساكنة لفترة طويلة بين كل مرة يتم فيها تنفيذ أوامر التبادل. رأس المال ما زال موجودًا هناك، لكن ليس دائمًا يكون في المكان المناسب حيث توجد حاجة فعلية لاقتراضه.
لفتت انتباهي Atomic Orders لدى TermMax لأنه يعالج هذه النقطة بشكل صحيح.
بدلًا من تقسيم السيولة إلى أجزاء منفصلة لكل سوق (market) أو لكل أجل/فترة (tenor)، يمكن لمصدر رأسمال واحد أن يخدم أوامر متعددة مختلفة. إذا كانت هذه الآلية تعمل بكفاءة، فقد لا يظهر كل دولار سيولة مرة واحدة في TVL فحسب، بل يمكن أيضًا إعادة استخدامه عبر فرص ائتمانية متعددة.
لذلك أعتقد أن TVL وحده لا يكفي لتقييم TermMax.
قد يكون للبروتوكول TVL مرتفع، لكن معظم رأس المال قد يكون في انتظار دون أن يحقق بالضرورة أفضل نتيجة من نظام أصغر مع معدل دوران رأس مال (capital turnover) أعلى. مع Atomic Orders، ما أريد أن أراه هو سرعة عودة رأس المال إلى دائرة التنفيذ (tied/turned back)، وعدد مرات إعادة استخدامه، وحجم credit volume الذي يدعمه فعليًا كل دولار من السيولة.
لكن السيولة المشتركة لديها نقطة أخرى يجب التحقق منها.
يمكن لعدد من الأسواق أن يبدو أنها أعمق عندما تُستخدم نفس السيولة المشتركة. ومع ذلك، إذا زادت احتياجات الاقتراض بشكل حاد في عدة أماكن في الوقت نفسه، فستظهر الحدود الفعلية للسيولة المتاحة. يمكن توزيع رأس المال بكفاءة أكبر، لكن ذلك لا يعني أنها تصبح غير محدودة.
برأيي، هذه هي الـ metric التي تستحق الاهتمام فعلًا في TermMax.
ليس فقط كم قدر من الأموال يحتفظ به البروتوكول، بل كم مرة يمكن لكل دولار من رأس المال أن “يعمل” قبل أن يبدأ النظام في ملامسة حدود السيولة.
@termmax #TermMax
$SKYAI $BTC $BNB
لم يكن إجمالي القيمة المقفلة (TVL) الكبير بالضرورة كافيًا للحكم على كفاءة استخدام رأس المال لدى TermMax
ما يثير اهتمامي في DeFi هو أن السيولة قد تبدو “سميكة جدًا” على لوحة المعلومات، لكنها في الواقع تبقى ساكنة لفترة طويلة بين كل مرة يتم فيها تنفيذ أوامر التبادل. رأس المال ما زال موجودًا هناك، لكن ليس دائمًا يكون في المكان المناسب حيث توجد حاجة فعلية لاقتراضه.
لفتت انتباهي Atomic Orders لدى TermMax لأنه يعالج هذه النقطة بشكل صحيح.
بدلًا من تقسيم السيولة إلى أجزاء منفصلة لكل سوق (market) أو لكل أجل/فترة (tenor)، يمكن لمصدر رأسمال واحد أن يخدم أوامر متعددة مختلفة. إذا كانت هذه الآلية تعمل بكفاءة، فقد لا يظهر كل دولار سيولة مرة واحدة في TVL فحسب، بل يمكن أيضًا إعادة استخدامه عبر فرص ائتمانية متعددة.
لذلك أعتقد أن TVL وحده لا يكفي لتقييم TermMax.
قد يكون للبروتوكول TVL مرتفع، لكن معظم رأس المال قد يكون في انتظار دون أن يحقق بالضرورة أفضل نتيجة من نظام أصغر مع معدل دوران رأس مال (capital turnover) أعلى. مع Atomic Orders، ما أريد أن أراه هو سرعة عودة رأس المال إلى دائرة التنفيذ (tied/turned back)، وعدد مرات إعادة استخدامه، وحجم credit volume الذي يدعمه فعليًا كل دولار من السيولة.
لكن السيولة المشتركة لديها نقطة أخرى يجب التحقق منها.
يمكن لعدد من الأسواق أن يبدو أنها أعمق عندما تُستخدم نفس السيولة المشتركة. ومع ذلك، إذا زادت احتياجات الاقتراض بشكل حاد في عدة أماكن في الوقت نفسه، فستظهر الحدود الفعلية للسيولة المتاحة. يمكن توزيع رأس المال بكفاءة أكبر، لكن ذلك لا يعني أنها تصبح غير محدودة.
برأيي، هذه هي الـ metric التي تستحق الاهتمام فعلًا في TermMax.
ليس فقط كم قدر من الأموال يحتفظ به البروتوكول، بل كم مرة يمكن لكل دولار من رأس المال أن “يعمل” قبل أن يبدأ النظام في ملامسة حدود السيولة.
@TermMax #TermMax
$SKYAI $BTC $BNB
ما يثير اهتمامي في DeFi هو أن السيولة قد تبدو “سميكة جدًا” على لوحة المعلومات، لكنها في الواقع تبقى ساكنة لفترة طويلة بين كل مرة يتم فيها تنفيذ أوامر التبادل. رأس المال ما زال موجودًا هناك، لكن ليس دائمًا يكون في المكان المناسب حيث توجد حاجة فعلية لاقتراضه.
لفتت انتباهي Atomic Orders لدى TermMax لأنه يعالج هذه النقطة بشكل صحيح.
بدلًا من تقسيم السيولة إلى أجزاء منفصلة لكل سوق (market) أو لكل أجل/فترة (tenor)، يمكن لمصدر رأسمال واحد أن يخدم أوامر متعددة مختلفة. إذا كانت هذه الآلية تعمل بكفاءة، فقد لا يظهر كل دولار سيولة مرة واحدة في TVL فحسب، بل يمكن أيضًا إعادة استخدامه عبر فرص ائتمانية متعددة.
لذلك أعتقد أن TVL وحده لا يكفي لتقييم TermMax.
قد يكون للبروتوكول TVL مرتفع، لكن معظم رأس المال قد يكون في انتظار دون أن يحقق بالضرورة أفضل نتيجة من نظام أصغر مع معدل دوران رأس مال (capital turnover) أعلى. مع Atomic Orders، ما أريد أن أراه هو سرعة عودة رأس المال إلى دائرة التنفيذ (tied/turned back)، وعدد مرات إعادة استخدامه، وحجم credit volume الذي يدعمه فعليًا كل دولار من السيولة.
لكن السيولة المشتركة لديها نقطة أخرى يجب التحقق منها.
يمكن لعدد من الأسواق أن يبدو أنها أعمق عندما تُستخدم نفس السيولة المشتركة. ومع ذلك، إذا زادت احتياجات الاقتراض بشكل حاد في عدة أماكن في الوقت نفسه، فستظهر الحدود الفعلية للسيولة المتاحة. يمكن توزيع رأس المال بكفاءة أكبر، لكن ذلك لا يعني أنها تصبح غير محدودة.
برأيي، هذه هي الـ metric التي تستحق الاهتمام فعلًا في TermMax.
ليس فقط كم قدر من الأموال يحتفظ به البروتوكول، بل كم مرة يمكن لكل دولار من رأس المال أن “يعمل” قبل أن يبدأ النظام في ملامسة حدود السيولة.
@TermMax #TermMax
$SKYAI $BTC $BNB
2
2
728
أصبح لدى P2P الآن طبقة إضافية بعنوان “التحقق”، وأرى أن هذه التفاصيل تستحق المراجعة قبل تنفيذ أي أمر
في الأيام السابقة، عندما استخدمت Binance P2P، لاحظت أن بعض التجار (Merchant) أضافوا ملصق “التحقق” أسفل الإعلان مباشرةً. عند النقر لعرضه بدقة، قد تظهر ضمن متطلبات المعلن خطوات إضافية مثل التحقق من هوية شخص حقيقي، أو وثائق هوية بصور، أو حتى KYC إضافي.
أكثر نقطة لفتت انتباهي هي أن هذه المتطلبات لا تظهر في الخطوة الأخيرة، بل تُعرض فورًا قبل تنفيذ الأمر.
أي أنه قبل الضغط على “بيع” (Bán)، يجب على المستخدم فتح قسم شروط التاجر (Merchant) وقراءته بعناية. وإذا كان الإعلان يطلب تحققًا إضافيًا لا أرغب في تقديمه أو لا أستطيع استيفاءه، فمن الأفضل التوقف من البداية بدلًا من فتح Order ثم اكتشاف الأمر لاحقًا.
برأيي، هذه طبقة تحقق تعد منطقية إلى حد كبير لمعاملات P2P، خصوصًا مع التجار الذين يتعاملون مع كميات كبيرة. وعندما تكون هوية الطرفين أوضح، يصبح مطابقة بيانات الشخص الذي قام بالدفع، ومصدر الأموال، ومعالجة النزاعات لاحقًا أسهل أيضًا.
لكن وجود تحقق لا يعني أنني أتجاهل خطوات الأمان الأخرى.
عند بيع USDT، ما زلت أتحقق من أن الأموال قد دخلت بالفعل إلى حسابي قبل أن أُطلق (Release). وعند الشراء، ما زلت أحوّل إلى الحساب الصحيح المعروض في الأمر (Order) وأحتفظ بجميع المراسلات داخل Binance. وإذا طلب التاجر إرسال المستندات عبر قناة خارج المنصة، فلن أتبع ذلك لمجرد أن الإعلان يحمل ملصق “التحقق”.
الاستنتاج الذي خرجت به هو أنني كنت سابقًا أركز غالبًا على السعر وCompletion Rate وعدد الأوامر.
الآن سأضيف عنصرًا آخر: ماذا يطلب التاجر مني أن أتحقق منه قبل إجراء المعاملة.
قراءة التفاصيل لمدة 10 ثوانٍ قبل تنفيذ الأمر أسهل بكثير من التعامل مع Order غير مناسب بعد ذلك.
@Binance_Vietnam #BinanceP2PAnToan
$BTC $ON $EDGE
أصبح لدى P2P الآن طبقة إضافية بعنوان “التحقق”، وأرى أن هذه التفاصيل تستحق المراجعة قبل تنفيذ أي أمر
في الأيام السابقة، عندما استخدمت Binance P2P، لاحظت أن بعض التجار (Merchant) أضافوا ملصق “التحقق” أسفل الإعلان مباشرةً. عند النقر لعرضه بدقة، قد تظهر ضمن متطلبات المعلن خطوات إضافية مثل التحقق من هوية شخص حقيقي، أو وثائق هوية بصور، أو حتى KYC إضافي.
أكثر نقطة لفتت انتباهي هي أن هذه المتطلبات لا تظهر في الخطوة الأخيرة، بل تُعرض فورًا قبل تنفيذ الأمر.
أي أنه قبل الضغط على “بيع” (Bán)، يجب على المستخدم فتح قسم شروط التاجر (Merchant) وقراءته بعناية. وإذا كان الإعلان يطلب تحققًا إضافيًا لا أرغب في تقديمه أو لا أستطيع استيفاءه، فمن الأفضل التوقف من البداية بدلًا من فتح Order ثم اكتشاف الأمر لاحقًا.
برأيي، هذه طبقة تحقق تعد منطقية إلى حد كبير لمعاملات P2P، خصوصًا مع التجار الذين يتعاملون مع كميات كبيرة. وعندما تكون هوية الطرفين أوضح، يصبح مطابقة بيانات الشخص الذي قام بالدفع، ومصدر الأموال، ومعالجة النزاعات لاحقًا أسهل أيضًا.
لكن وجود تحقق لا يعني أنني أتجاهل خطوات الأمان الأخرى.
عند بيع USDT، ما زلت أتحقق من أن الأموال قد دخلت بالفعل إلى حسابي قبل أن أُطلق (Release). وعند الشراء، ما زلت أحوّل إلى الحساب الصحيح المعروض في الأمر (Order) وأحتفظ بجميع المراسلات داخل Binance. وإذا طلب التاجر إرسال المستندات عبر قناة خارج المنصة، فلن أتبع ذلك لمجرد أن الإعلان يحمل ملصق “التحقق”.
الاستنتاج الذي خرجت به هو أنني كنت سابقًا أركز غالبًا على السعر وCompletion Rate وعدد الأوامر.
الآن سأضيف عنصرًا آخر: ماذا يطلب التاجر مني أن أتحقق منه قبل إجراء المعاملة.
قراءة التفاصيل لمدة 10 ثوانٍ قبل تنفيذ الأمر أسهل بكثير من التعامل مع Order غير مناسب بعد ذلك.
@Binance Vietnam #BinanceP2PAnToan
$BTC $ON $EDGE
في الأيام السابقة، عندما استخدمت Binance P2P، لاحظت أن بعض التجار (Merchant) أضافوا ملصق “التحقق” أسفل الإعلان مباشرةً. عند النقر لعرضه بدقة، قد تظهر ضمن متطلبات المعلن خطوات إضافية مثل التحقق من هوية شخص حقيقي، أو وثائق هوية بصور، أو حتى KYC إضافي.
أكثر نقطة لفتت انتباهي هي أن هذه المتطلبات لا تظهر في الخطوة الأخيرة، بل تُعرض فورًا قبل تنفيذ الأمر.
أي أنه قبل الضغط على “بيع” (Bán)، يجب على المستخدم فتح قسم شروط التاجر (Merchant) وقراءته بعناية. وإذا كان الإعلان يطلب تحققًا إضافيًا لا أرغب في تقديمه أو لا أستطيع استيفاءه، فمن الأفضل التوقف من البداية بدلًا من فتح Order ثم اكتشاف الأمر لاحقًا.
برأيي، هذه طبقة تحقق تعد منطقية إلى حد كبير لمعاملات P2P، خصوصًا مع التجار الذين يتعاملون مع كميات كبيرة. وعندما تكون هوية الطرفين أوضح، يصبح مطابقة بيانات الشخص الذي قام بالدفع، ومصدر الأموال، ومعالجة النزاعات لاحقًا أسهل أيضًا.
لكن وجود تحقق لا يعني أنني أتجاهل خطوات الأمان الأخرى.
عند بيع USDT، ما زلت أتحقق من أن الأموال قد دخلت بالفعل إلى حسابي قبل أن أُطلق (Release). وعند الشراء، ما زلت أحوّل إلى الحساب الصحيح المعروض في الأمر (Order) وأحتفظ بجميع المراسلات داخل Binance. وإذا طلب التاجر إرسال المستندات عبر قناة خارج المنصة، فلن أتبع ذلك لمجرد أن الإعلان يحمل ملصق “التحقق”.
الاستنتاج الذي خرجت به هو أنني كنت سابقًا أركز غالبًا على السعر وCompletion Rate وعدد الأوامر.
الآن سأضيف عنصرًا آخر: ماذا يطلب التاجر مني أن أتحقق منه قبل إجراء المعاملة.
قراءة التفاصيل لمدة 10 ثوانٍ قبل تنفيذ الأمر أسهل بكثير من التعامل مع Order غير مناسب بعد ذلك.
@Binance Vietnam #BinanceP2PAnToan
$BTC $ON $EDGE
1
2
1.8k
·
--
صاعد
سعر ثابت مقابل سعر عائم، أعتقد أن الإجابة تعتمد على ما تريد التحكم فيه
كلما نظرت إلى TermMax، أدركت أن الإقراض بسعر ثابت ليس مجرد “فائدة أكثر استقرارًا”. بل هو تبادل جزء من المرونة مقابل القدرة على معرفة التكاليف أو العوائد مسبقًا تقريبًا من البداية.
إذا قمت بإقراض 100.000 دولار لمدة 12 شهرًا بسعر ثابت، فأنا أعرف بشكل قريب جدًا من الدقة ما أضعه من رأس مال في مقابل أي مستوى عائد، ومتى سينتهي ذلك القرض. هذا مفيد إذا كان الهدف هو التخطيط لتدفقات النقد أو الحفاظ على استراتيجية مستقرة دون الحاجة إلى متابعة الفائدة يوميًا.
لكن الثمن هو الفرصة.
قد يتغير السوق بسرعة أكبر من مدة القرض. قد تكون أسعار الفائدة الجديدة أعلى من تلك التي تم تثبيتها. قد يكون هناك pool آخر أكثر جاذبية. أو ببساطة قد أريد سحب رأس المال مبكرًا للانتقال إلى استراتيجية أخرى.
أما سعر العائم، فهو بالعكس. أحافظ على المرونة لكن يجب أن أقبل أن العائد يتغير باستمرار وأنه أصعب في التنبؤ.
لذلك أرى أن السعر الثابت والعائم لا يتنافسان على طريقة “أيّهما أفضل بشكل مطلق”. إنهما يعالجان احتياجَين مختلفين.
يناسب السعر الثابت عندما تكون لدي أولوية للثبات وأريد معرفة النتيجة المالية لمركز ما مسبقًا.
ويُعدّ السعر العائم أفضل عندما أضع قيمة أعلى للسيولة والقدرة على تغيير الاستراتيجية.
إذا كان لدي 100.000 دولار للإقراض لمدة 12 شهرًا، فمن المحتمل ألا أختار جانبًا واحدًا بالكامل. سأقسّم رأس المال: 60 ألف دولار لتثبيت سعر ثابت يخلق أساسًا بعائد يمكن التنبؤ به، والجزء المتبقي أحتفظ به عائمًا كي أبقى قادرًا على التحرك عندما تتغير ظروف السوق.
وبالنسبة لك، إذا كان عليك الاختيار بينهما، هل الأهم في الأشهر الـ12 القادمة هو اليقين أم المرونة؟
@termmax #TermMax
$BNB $RICE $APR
سعر ثابت مقابل سعر عائم، أعتقد أن الإجابة تعتمد على ما تريد التحكم فيه
كلما نظرت إلى TermMax، أدركت أن الإقراض بسعر ثابت ليس مجرد “فائدة أكثر استقرارًا”. بل هو تبادل جزء من المرونة مقابل القدرة على معرفة التكاليف أو العوائد مسبقًا تقريبًا من البداية.
إذا قمت بإقراض 100.000 دولار لمدة 12 شهرًا بسعر ثابت، فأنا أعرف بشكل قريب جدًا من الدقة ما أضعه من رأس مال في مقابل أي مستوى عائد، ومتى سينتهي ذلك القرض. هذا مفيد إذا كان الهدف هو التخطيط لتدفقات النقد أو الحفاظ على استراتيجية مستقرة دون الحاجة إلى متابعة الفائدة يوميًا.
لكن الثمن هو الفرصة.
قد يتغير السوق بسرعة أكبر من مدة القرض. قد تكون أسعار الفائدة الجديدة أعلى من تلك التي تم تثبيتها. قد يكون هناك pool آخر أكثر جاذبية. أو ببساطة قد أريد سحب رأس المال مبكرًا للانتقال إلى استراتيجية أخرى.
أما سعر العائم، فهو بالعكس. أحافظ على المرونة لكن يجب أن أقبل أن العائد يتغير باستمرار وأنه أصعب في التنبؤ.
لذلك أرى أن السعر الثابت والعائم لا يتنافسان على طريقة “أيّهما أفضل بشكل مطلق”. إنهما يعالجان احتياجَين مختلفين.
يناسب السعر الثابت عندما تكون لدي أولوية للثبات وأريد معرفة النتيجة المالية لمركز ما مسبقًا.
ويُعدّ السعر العائم أفضل عندما أضع قيمة أعلى للسيولة والقدرة على تغيير الاستراتيجية.
إذا كان لدي 100.000 دولار للإقراض لمدة 12 شهرًا، فمن المحتمل ألا أختار جانبًا واحدًا بالكامل. سأقسّم رأس المال: 60 ألف دولار لتثبيت سعر ثابت يخلق أساسًا بعائد يمكن التنبؤ به، والجزء المتبقي أحتفظ به عائمًا كي أبقى قادرًا على التحرك عندما تتغير ظروف السوق.
وبالنسبة لك، إذا كان عليك الاختيار بينهما، هل الأهم في الأشهر الـ12 القادمة هو اليقين أم المرونة؟
@TermMax #TermMax
$BNB $RICE $APR
كلما نظرت إلى TermMax، أدركت أن الإقراض بسعر ثابت ليس مجرد “فائدة أكثر استقرارًا”. بل هو تبادل جزء من المرونة مقابل القدرة على معرفة التكاليف أو العوائد مسبقًا تقريبًا من البداية.
إذا قمت بإقراض 100.000 دولار لمدة 12 شهرًا بسعر ثابت، فأنا أعرف بشكل قريب جدًا من الدقة ما أضعه من رأس مال في مقابل أي مستوى عائد، ومتى سينتهي ذلك القرض. هذا مفيد إذا كان الهدف هو التخطيط لتدفقات النقد أو الحفاظ على استراتيجية مستقرة دون الحاجة إلى متابعة الفائدة يوميًا.
لكن الثمن هو الفرصة.
قد يتغير السوق بسرعة أكبر من مدة القرض. قد تكون أسعار الفائدة الجديدة أعلى من تلك التي تم تثبيتها. قد يكون هناك pool آخر أكثر جاذبية. أو ببساطة قد أريد سحب رأس المال مبكرًا للانتقال إلى استراتيجية أخرى.
أما سعر العائم، فهو بالعكس. أحافظ على المرونة لكن يجب أن أقبل أن العائد يتغير باستمرار وأنه أصعب في التنبؤ.
لذلك أرى أن السعر الثابت والعائم لا يتنافسان على طريقة “أيّهما أفضل بشكل مطلق”. إنهما يعالجان احتياجَين مختلفين.
يناسب السعر الثابت عندما تكون لدي أولوية للثبات وأريد معرفة النتيجة المالية لمركز ما مسبقًا.
ويُعدّ السعر العائم أفضل عندما أضع قيمة أعلى للسيولة والقدرة على تغيير الاستراتيجية.
إذا كان لدي 100.000 دولار للإقراض لمدة 12 شهرًا، فمن المحتمل ألا أختار جانبًا واحدًا بالكامل. سأقسّم رأس المال: 60 ألف دولار لتثبيت سعر ثابت يخلق أساسًا بعائد يمكن التنبؤ به، والجزء المتبقي أحتفظ به عائمًا كي أبقى قادرًا على التحرك عندما تتغير ظروف السوق.
وبالنسبة لك، إذا كان عليك الاختيار بينهما، هل الأهم في الأشهر الـ12 القادمة هو اليقين أم المرونة؟
@TermMax #TermMax
$BNB $RICE $APR
2
1
506
خصوصية Dusk لا تصبح حقًا موثوقة إلا عندما تكون الشبكة تحت ضغط
الأمر الذي غيّر طريقتي في النظر إلى Phoenix هو إدراكي أن عدم رؤية شيء ما لا يعني أنه لا يمكن التحقق منه
بالنسبة للمعاملات المحمية (shielded)، لا يستطيع المراقبون العلنيون رؤية المُرسِل أو المُستقبِل أو المبلغ كما في Moonlight، لكن يجب أن تتحقق الشبكة من المعاملة قبل قبول الحالة. بعد ذلك، يقوم DuskDS بإرسال الكتلة عبر الاقتراح (proposal) والتحقق (validation) والمصادقة (ratification) لتحقيق نهائية حتمية (deterministic finality).
في الظروف العادية، يكون هذا النموذج مناسبًا ومتماسكًا. الجزء الذي أريد التعمق فيه هو عندما تزدحم الشبكة.
إذا كانت المعاملات العامة والخاصة (confidential) تضغط على النظام معًا، فستستمر اللجنة (committee) في تغييرها، بينما يبدأ بعض الـ provisioners باللحاق متأخرين، عندها لا تصبح الخصوصية هي السؤال الوحيد. يجب على الشبكة أيضًا الحفاظ على قابلية البقاء (liveness) والنهائية (finality) دون خفض معايير التحقق.
النقطة التي أراها معقولة هي أن Dusk لا يعتبر جميع الأخطاء متشابهة. فقدان الـ provisioner للمهمة يمكن أن يترتب عليه عقوبة خفيفة (soft penalty)، بينما قد تؤدي السلوكيات التي يمكن إثبات أنها خاطئة مثل التصويت غير الصالح أو توقيع تعارض (conflicting signature) إلى عقوبة شديدة (hard penalty).
برأيي، هذا هو الاختبار الذي يستحق المشاهدة أكثر من مجرد معاملة خاصة تعمل بسلاسة.
النظام الجيد للخصوصية لا يحتاج فقط إلى إخفاء البيانات عندما تسير الأمور بشكل طبيعي. بل يجب أن يحافظ على القدرة على التحقق عندما تنحرف العقد عن الإيقاع، وتدور اللجنة، ويزداد حمل الشبكة بشكل كبير.
إذا استطاع Dusk الحفاظ على هذا الحد الفاصل، عندها تصبح الخصوصية فعلًا خاصية من خصائص البنية التحتية وليست مجرد تجربة داخل التطبيق على مستوى المحفظة.
@Dusk_Foundation $DUSK #dusk
$RICE $BTW
خصوصية Dusk لا تصبح حقًا موثوقة إلا عندما تكون الشبكة تحت ضغط
الأمر الذي غيّر طريقتي في النظر إلى Phoenix هو إدراكي أن عدم رؤية شيء ما لا يعني أنه لا يمكن التحقق منه
بالنسبة للمعاملات المحمية (shielded)، لا يستطيع المراقبون العلنيون رؤية المُرسِل أو المُستقبِل أو المبلغ كما في Moonlight، لكن يجب أن تتحقق الشبكة من المعاملة قبل قبول الحالة. بعد ذلك، يقوم DuskDS بإرسال الكتلة عبر الاقتراح (proposal) والتحقق (validation) والمصادقة (ratification) لتحقيق نهائية حتمية (deterministic finality).
في الظروف العادية، يكون هذا النموذج مناسبًا ومتماسكًا. الجزء الذي أريد التعمق فيه هو عندما تزدحم الشبكة.
إذا كانت المعاملات العامة والخاصة (confidential) تضغط على النظام معًا، فستستمر اللجنة (committee) في تغييرها، بينما يبدأ بعض الـ provisioners باللحاق متأخرين، عندها لا تصبح الخصوصية هي السؤال الوحيد. يجب على الشبكة أيضًا الحفاظ على قابلية البقاء (liveness) والنهائية (finality) دون خفض معايير التحقق.
النقطة التي أراها معقولة هي أن Dusk لا يعتبر جميع الأخطاء متشابهة. فقدان الـ provisioner للمهمة يمكن أن يترتب عليه عقوبة خفيفة (soft penalty)، بينما قد تؤدي السلوكيات التي يمكن إثبات أنها خاطئة مثل التصويت غير الصالح أو توقيع تعارض (conflicting signature) إلى عقوبة شديدة (hard penalty).
برأيي، هذا هو الاختبار الذي يستحق المشاهدة أكثر من مجرد معاملة خاصة تعمل بسلاسة.
النظام الجيد للخصوصية لا يحتاج فقط إلى إخفاء البيانات عندما تسير الأمور بشكل طبيعي. بل يجب أن يحافظ على القدرة على التحقق عندما تنحرف العقد عن الإيقاع، وتدور اللجنة، ويزداد حمل الشبكة بشكل كبير.
إذا استطاع Dusk الحفاظ على هذا الحد الفاصل، عندها تصبح الخصوصية فعلًا خاصية من خصائص البنية التحتية وليست مجرد تجربة داخل التطبيق على مستوى المحفظة.
@Dusk $DUSK #dusk
$RICE $BTW
الأمر الذي غيّر طريقتي في النظر إلى Phoenix هو إدراكي أن عدم رؤية شيء ما لا يعني أنه لا يمكن التحقق منه
بالنسبة للمعاملات المحمية (shielded)، لا يستطيع المراقبون العلنيون رؤية المُرسِل أو المُستقبِل أو المبلغ كما في Moonlight، لكن يجب أن تتحقق الشبكة من المعاملة قبل قبول الحالة. بعد ذلك، يقوم DuskDS بإرسال الكتلة عبر الاقتراح (proposal) والتحقق (validation) والمصادقة (ratification) لتحقيق نهائية حتمية (deterministic finality).
في الظروف العادية، يكون هذا النموذج مناسبًا ومتماسكًا. الجزء الذي أريد التعمق فيه هو عندما تزدحم الشبكة.
إذا كانت المعاملات العامة والخاصة (confidential) تضغط على النظام معًا، فستستمر اللجنة (committee) في تغييرها، بينما يبدأ بعض الـ provisioners باللحاق متأخرين، عندها لا تصبح الخصوصية هي السؤال الوحيد. يجب على الشبكة أيضًا الحفاظ على قابلية البقاء (liveness) والنهائية (finality) دون خفض معايير التحقق.
النقطة التي أراها معقولة هي أن Dusk لا يعتبر جميع الأخطاء متشابهة. فقدان الـ provisioner للمهمة يمكن أن يترتب عليه عقوبة خفيفة (soft penalty)، بينما قد تؤدي السلوكيات التي يمكن إثبات أنها خاطئة مثل التصويت غير الصالح أو توقيع تعارض (conflicting signature) إلى عقوبة شديدة (hard penalty).
برأيي، هذا هو الاختبار الذي يستحق المشاهدة أكثر من مجرد معاملة خاصة تعمل بسلاسة.
النظام الجيد للخصوصية لا يحتاج فقط إلى إخفاء البيانات عندما تسير الأمور بشكل طبيعي. بل يجب أن يحافظ على القدرة على التحقق عندما تنحرف العقد عن الإيقاع، وتدور اللجنة، ويزداد حمل الشبكة بشكل كبير.
إذا استطاع Dusk الحفاظ على هذا الحد الفاصل، عندها تصبح الخصوصية فعلًا خاصية من خصائص البنية التحتية وليست مجرد تجربة داخل التطبيق على مستوى المحفظة.
@Dusk $DUSK #dusk
$RICE $BTW
6
2
100
قم بشراء/بيع USDT عبر التداول السريع على Binance P2P: خطوات سريعة لكن الخطوة الأخيرة يجب أن تتأكد منها جيدًا
لقد جرّبت للتو سير عملية البيع ضمن قسم «التداول السريع» ووجدت أنها سهلة الاستخدام إذا اتّبعت كل خطوة كما ينبغي.
أولًا، ادخل إلى P2P → التداول السريع → اختر البيع ثم أدخل عدد USDT الذي تريد بيعه. في الصورة التي جرّبت فيها، استخدمت 10$. يعرض النظام مبلغ VND التقريبي للتحقق قبل المتابعة.
الخطوة التالية هي اختيار طريقة استلام الأموال. في وقت قيامي بالإجراء، كانت التحويلات البنكية بسعر 25.506đ/USDT، بينما كان MoMo بسعر 25.455đ/USDT. عادةً أقارن بين السعرين، لأنّه حتى عند بيع نفس كمية USDT، قد يختلف المبلغ الفعلي المستلم.
بعد اختيار التحويل البنكي، يقوم Binance بربط الطلب مع Merchant GiaoDichTuDong_247. السعر النهائي في الطلب هو 25.506đ/USDT والمبلغ المتوقع للاستلام هو 254.804đ.
من هذه النقطة لا تحتاج للبحث عن مشترٍ بنفسك. كل ما عليك فعله هو انتظار قيام الطرف المقابل بتحويل المبلغ إلى حساب البنك المُسجّل.
وهذه أيضًا هي أهم خطوة.
عندما يُعلمك Binance أن المشتري قد قام بالدفع، أفتح تطبيق البنك بنفسي دائمًا للتحقق. يجب مطابقة مبلغ الدفع بالضبط، وحالة المعاملة، وخصوصًا اسم المُحوِّل. إذا لم يكن اسم المُرسل الفعلي مطابقًا لاسم المشتري الظاهر في الطلب (Order)، فلن أضغط على فتح القفل، وسأستخدم «اعتراض/تقديم شكوى (Khiếu nại)» للتعامل مع الأمر.
فقط عندما تتطابق جميع المعلومات، أختار «تم الاستلام» ثم أؤكد فتح قفل USDT.
بعد الإطلاق (release)، سيتم نقل الطلب إلى «اكتمل» وسيتم تسجيل 10 USDT على أنها تمت بنجاح.
يساعد التداول السريع على الاستغناء عن خطوة البحث عن Merchant، لكن لا يُلغي خطوة التحقق الأخيرة.
السرعة في التنفيذ، والتأنّي بثوانٍ قليلة للتحقق من الأموال—هذه هي الطريقة التي أراها الأكثر أمانًا.
@Binance_Vietnam #BinanceP2PAnToan
$RICE $BTW $M
قم بشراء/بيع USDT عبر التداول السريع على Binance P2P: خطوات سريعة لكن الخطوة الأخيرة يجب أن تتأكد منها جيدًا
لقد جرّبت للتو سير عملية البيع ضمن قسم «التداول السريع» ووجدت أنها سهلة الاستخدام إذا اتّبعت كل خطوة كما ينبغي.
أولًا، ادخل إلى P2P → التداول السريع → اختر البيع ثم أدخل عدد USDT الذي تريد بيعه. في الصورة التي جرّبت فيها، استخدمت 10$. يعرض النظام مبلغ VND التقريبي للتحقق قبل المتابعة.
الخطوة التالية هي اختيار طريقة استلام الأموال. في وقت قيامي بالإجراء، كانت التحويلات البنكية بسعر 25.506đ/USDT، بينما كان MoMo بسعر 25.455đ/USDT. عادةً أقارن بين السعرين، لأنّه حتى عند بيع نفس كمية USDT، قد يختلف المبلغ الفعلي المستلم.
بعد اختيار التحويل البنكي، يقوم Binance بربط الطلب مع Merchant GiaoDichTuDong_247. السعر النهائي في الطلب هو 25.506đ/USDT والمبلغ المتوقع للاستلام هو 254.804đ.
من هذه النقطة لا تحتاج للبحث عن مشترٍ بنفسك. كل ما عليك فعله هو انتظار قيام الطرف المقابل بتحويل المبلغ إلى حساب البنك المُسجّل.
وهذه أيضًا هي أهم خطوة.
عندما يُعلمك Binance أن المشتري قد قام بالدفع، أفتح تطبيق البنك بنفسي دائمًا للتحقق. يجب مطابقة مبلغ الدفع بالضبط، وحالة المعاملة، وخصوصًا اسم المُحوِّل. إذا لم يكن اسم المُرسل الفعلي مطابقًا لاسم المشتري الظاهر في الطلب (Order)، فلن أضغط على فتح القفل، وسأستخدم «اعتراض/تقديم شكوى (Khiếu nại)» للتعامل مع الأمر.
فقط عندما تتطابق جميع المعلومات، أختار «تم الاستلام» ثم أؤكد فتح قفل USDT.
بعد الإطلاق (release)، سيتم نقل الطلب إلى «اكتمل» وسيتم تسجيل 10 USDT على أنها تمت بنجاح.
يساعد التداول السريع على الاستغناء عن خطوة البحث عن Merchant، لكن لا يُلغي خطوة التحقق الأخيرة.
السرعة في التنفيذ، والتأنّي بثوانٍ قليلة للتحقق من الأموال—هذه هي الطريقة التي أراها الأكثر أمانًا.
@Binance Vietnam #BinanceP2PAnToan
$RICE $BTW $M
لقد جرّبت للتو سير عملية البيع ضمن قسم «التداول السريع» ووجدت أنها سهلة الاستخدام إذا اتّبعت كل خطوة كما ينبغي.
أولًا، ادخل إلى P2P → التداول السريع → اختر البيع ثم أدخل عدد USDT الذي تريد بيعه. في الصورة التي جرّبت فيها، استخدمت 10$. يعرض النظام مبلغ VND التقريبي للتحقق قبل المتابعة.
الخطوة التالية هي اختيار طريقة استلام الأموال. في وقت قيامي بالإجراء، كانت التحويلات البنكية بسعر 25.506đ/USDT، بينما كان MoMo بسعر 25.455đ/USDT. عادةً أقارن بين السعرين، لأنّه حتى عند بيع نفس كمية USDT، قد يختلف المبلغ الفعلي المستلم.
بعد اختيار التحويل البنكي، يقوم Binance بربط الطلب مع Merchant GiaoDichTuDong_247. السعر النهائي في الطلب هو 25.506đ/USDT والمبلغ المتوقع للاستلام هو 254.804đ.
من هذه النقطة لا تحتاج للبحث عن مشترٍ بنفسك. كل ما عليك فعله هو انتظار قيام الطرف المقابل بتحويل المبلغ إلى حساب البنك المُسجّل.
وهذه أيضًا هي أهم خطوة.
عندما يُعلمك Binance أن المشتري قد قام بالدفع، أفتح تطبيق البنك بنفسي دائمًا للتحقق. يجب مطابقة مبلغ الدفع بالضبط، وحالة المعاملة، وخصوصًا اسم المُحوِّل. إذا لم يكن اسم المُرسل الفعلي مطابقًا لاسم المشتري الظاهر في الطلب (Order)، فلن أضغط على فتح القفل، وسأستخدم «اعتراض/تقديم شكوى (Khiếu nại)» للتعامل مع الأمر.
فقط عندما تتطابق جميع المعلومات، أختار «تم الاستلام» ثم أؤكد فتح قفل USDT.
بعد الإطلاق (release)، سيتم نقل الطلب إلى «اكتمل» وسيتم تسجيل 10 USDT على أنها تمت بنجاح.
يساعد التداول السريع على الاستغناء عن خطوة البحث عن Merchant، لكن لا يُلغي خطوة التحقق الأخيرة.
السرعة في التنفيذ، والتأنّي بثوانٍ قليلة للتحقق من الأموال—هذه هي الطريقة التي أراها الأكثر أمانًا.
@Binance Vietnam #BinanceP2PAnToan
$RICE $BTW $M
1
1
619
TermMax قد يكون مناسبًا للاحتياجات طويلة الأمد، لكن ما زال يجب إثبات أن المستخدمين يرغبون في تغيير عاداتهم
كلما قرأت أكثر عن TermMax، أدركت أن أهم سؤال لا يتعلق بما إذا كان الإقراض بسعر ثابت (fixed rate lending) منطقيًا أم لا. ماليًا، الأمر مفهوم لأن المقترض يعرف مسبقًا تكلفة التمويل، ويعرف المُقرض مسبقًا العائد، وكلاهما لديه تاريخ استحقاق واضح.
ولكن DeFi لا يفتقر إلى المنتجات المعقولة
الأصعب هو إقناع المستخدمين بمغادرة سوق المال (money market) المعتاد. قد تكون أسعار الفائدة المتغيرة مزعجة، لكن بالمقابل تحصل على سيولة أعلى، وإجراءات أبسط، ولا يتطلب الأمر التفكير كثيرًا في مدة الاستحقاق. بالنسبة لكثيرين، تكون هذه الراحة كافية.
لا يخلق TermMax فرقًا حقيقيًا إلا عندما تكون قابلية اليقين بشأن تكلفة التمويل أكثر قيمة من المرونة التي يمتلكها المستخدم حاليًا.
يتضح ذلك أكثر مع الرافعة المالية (leverage). إذا كانت استراتيجية ما تعتمد على هامش ربح ضئيل، فإن معرفة تكلفة التمويل مسبقًا قد تساعد على حساب المراكز بدقة أكبر. لكن بالنسبة لمن يودع أصولًا فقط لكسب عائد، قد لا تكون ميزة السعر الثابت قوية بما يكفي لتغيير سلوكهم.
لذلك أعتقد أن XP أو نقاط النشاط (Activity Points) تحل جزءًا من مشكلة جذب الاهتمام الأولي فقط. قد تجلب حجم تداول (volume) وتُدخل المستخدمين إلى النظام، لكنها لا تجيب عن السؤال الأصعب: بعد أن تنخفض قيمة المكافآت، هل سيعودون لأن المنتج نفسه جيد، أم لا؟
أنا لا أشك في أن الطلب على الدخل الثابت (fixed income) سيكون أكبر مع نضج سوق الكريبتو
لكن ما لست متأكدًا منه هو التوقيت
إذا أراد TermMax إثبات توافق المنتج مع احتياج السوق (product market fit)، فسأنظر إلى نسبة المستخدمين الذين يعودون، وما إذا كانت السيولة تُحافظ عليها بعد الحوافز (incentives)، وهل يسهم السعر الثابت فعلًا في إدارة رأس المال لديهم بشكل أفضل من الخيارات الحالية أم لا
@termmax #TermMax
$BTC $LAB $X
TermMax قد يكون مناسبًا للاحتياجات طويلة الأمد، لكن ما زال يجب إثبات أن المستخدمين يرغبون في تغيير عاداتهم
كلما قرأت أكثر عن TermMax، أدركت أن أهم سؤال لا يتعلق بما إذا كان الإقراض بسعر ثابت (fixed rate lending) منطقيًا أم لا. ماليًا، الأمر مفهوم لأن المقترض يعرف مسبقًا تكلفة التمويل، ويعرف المُقرض مسبقًا العائد، وكلاهما لديه تاريخ استحقاق واضح.
ولكن DeFi لا يفتقر إلى المنتجات المعقولة
الأصعب هو إقناع المستخدمين بمغادرة سوق المال (money market) المعتاد. قد تكون أسعار الفائدة المتغيرة مزعجة، لكن بالمقابل تحصل على سيولة أعلى، وإجراءات أبسط، ولا يتطلب الأمر التفكير كثيرًا في مدة الاستحقاق. بالنسبة لكثيرين، تكون هذه الراحة كافية.
لا يخلق TermMax فرقًا حقيقيًا إلا عندما تكون قابلية اليقين بشأن تكلفة التمويل أكثر قيمة من المرونة التي يمتلكها المستخدم حاليًا.
يتضح ذلك أكثر مع الرافعة المالية (leverage). إذا كانت استراتيجية ما تعتمد على هامش ربح ضئيل، فإن معرفة تكلفة التمويل مسبقًا قد تساعد على حساب المراكز بدقة أكبر. لكن بالنسبة لمن يودع أصولًا فقط لكسب عائد، قد لا تكون ميزة السعر الثابت قوية بما يكفي لتغيير سلوكهم.
لذلك أعتقد أن XP أو نقاط النشاط (Activity Points) تحل جزءًا من مشكلة جذب الاهتمام الأولي فقط. قد تجلب حجم تداول (volume) وتُدخل المستخدمين إلى النظام، لكنها لا تجيب عن السؤال الأصعب: بعد أن تنخفض قيمة المكافآت، هل سيعودون لأن المنتج نفسه جيد، أم لا؟
أنا لا أشك في أن الطلب على الدخل الثابت (fixed income) سيكون أكبر مع نضج سوق الكريبتو
لكن ما لست متأكدًا منه هو التوقيت
إذا أراد TermMax إثبات توافق المنتج مع احتياج السوق (product market fit)، فسأنظر إلى نسبة المستخدمين الذين يعودون، وما إذا كانت السيولة تُحافظ عليها بعد الحوافز (incentives)، وهل يسهم السعر الثابت فعلًا في إدارة رأس المال لديهم بشكل أفضل من الخيارات الحالية أم لا
@TermMax #TermMax
$BTC $LAB $X
كلما قرأت أكثر عن TermMax، أدركت أن أهم سؤال لا يتعلق بما إذا كان الإقراض بسعر ثابت (fixed rate lending) منطقيًا أم لا. ماليًا، الأمر مفهوم لأن المقترض يعرف مسبقًا تكلفة التمويل، ويعرف المُقرض مسبقًا العائد، وكلاهما لديه تاريخ استحقاق واضح.
ولكن DeFi لا يفتقر إلى المنتجات المعقولة
الأصعب هو إقناع المستخدمين بمغادرة سوق المال (money market) المعتاد. قد تكون أسعار الفائدة المتغيرة مزعجة، لكن بالمقابل تحصل على سيولة أعلى، وإجراءات أبسط، ولا يتطلب الأمر التفكير كثيرًا في مدة الاستحقاق. بالنسبة لكثيرين، تكون هذه الراحة كافية.
لا يخلق TermMax فرقًا حقيقيًا إلا عندما تكون قابلية اليقين بشأن تكلفة التمويل أكثر قيمة من المرونة التي يمتلكها المستخدم حاليًا.
يتضح ذلك أكثر مع الرافعة المالية (leverage). إذا كانت استراتيجية ما تعتمد على هامش ربح ضئيل، فإن معرفة تكلفة التمويل مسبقًا قد تساعد على حساب المراكز بدقة أكبر. لكن بالنسبة لمن يودع أصولًا فقط لكسب عائد، قد لا تكون ميزة السعر الثابت قوية بما يكفي لتغيير سلوكهم.
لذلك أعتقد أن XP أو نقاط النشاط (Activity Points) تحل جزءًا من مشكلة جذب الاهتمام الأولي فقط. قد تجلب حجم تداول (volume) وتُدخل المستخدمين إلى النظام، لكنها لا تجيب عن السؤال الأصعب: بعد أن تنخفض قيمة المكافآت، هل سيعودون لأن المنتج نفسه جيد، أم لا؟
أنا لا أشك في أن الطلب على الدخل الثابت (fixed income) سيكون أكبر مع نضج سوق الكريبتو
لكن ما لست متأكدًا منه هو التوقيت
إذا أراد TermMax إثبات توافق المنتج مع احتياج السوق (product market fit)، فسأنظر إلى نسبة المستخدمين الذين يعودون، وما إذا كانت السيولة تُحافظ عليها بعد الحوافز (incentives)، وهل يسهم السعر الثابت فعلًا في إدارة رأس المال لديهم بشكل أفضل من الخيارات الحالية أم لا
@TermMax #TermMax
$BTC $LAB $X
1
1
186
·
--
صاعد
يُجبرني Dusk Trade على التفكير في أن “النيوبروكر” على السلسلة لا ينبغي تقييمه اعتمادًا على الواجهة
إذا نظرنا فقط من جهة المستخدم، تبدو Dusk Trade أشبه بمكان للعثور على الأصول المُرمّزة والتداول فيها، لكن ما يهمني أكثر يقع خلف شاشة منصة البيع والشراء.
بالنسبة للأصول الخاضعة للإدارة، لا يكفي أن تتطابق الأوامر مع السعر. يجب على المشتري اجتياز عملية onboarding، واستيفاء شروط الملكية، وربط محفظته، ولا يتم الكشف إلا عن البيانات الضرورية لمن يملك الصلاحية. تقوم Dusk Trade بتجميع هذه الخطوات كلها ضمن سير عمل واحد، كما أنها تُنسّق بين جزء الأصول وجزء المدفوعات قبل التسوية (settlement).
برأيي، هذا هو جوهر معنى النيوبروكر في سياق RWA. القيمة لا تكمن في تحويل السندات أو الصناديق إلى توكنات ثم وضعها في تطبيق جديد. الأهم والأصعب هو جعل الملكية وشروط التداول وخصوصية البيانات والتسوية تعمل معًا بسلاسة.
لكنني ما زلت لا أريد تقييم Dusk Trade من خلال قائمة الانتظار (waitlist).
عدد المسجلين لا يخبرنا إلا بوجود فضول. والأهم للمراقبة هو: أي الأصول الحقيقية يضعها المُصدر (issuer) على المنصة، وكم عدد الحسابات المؤهلة فعليًا للقيام بعمليات تداول، ومدى قيمة التداولات التي تم تسويتها فعليًا عبر النظام.
حتى الآن، ما زال Dusk يصف Dusk Trade على أنها منتج قيد الإنشاء. لذلك بالنسبة لي، فإن المحطة الأهم ليست عدد الأشخاص الذين ينتظرون الانضمام إلى التطبيق، بل اللحظة التي يبدأ فيها MMF أو السندات أو الأصول المُنظّمة الأخرى في توليد حجم تداول حقيقي.
قد يجذب السرد (narrative) الانتباه.
أما التسوية الحقيقية فهي التي تُثبت وجود السوق.
@Dusk_Foundation $DUSK #dusk
$CLO $LAB
يُجبرني Dusk Trade على التفكير في أن “النيوبروكر” على السلسلة لا ينبغي تقييمه اعتمادًا على الواجهة
إذا نظرنا فقط من جهة المستخدم، تبدو Dusk Trade أشبه بمكان للعثور على الأصول المُرمّزة والتداول فيها، لكن ما يهمني أكثر يقع خلف شاشة منصة البيع والشراء.
بالنسبة للأصول الخاضعة للإدارة، لا يكفي أن تتطابق الأوامر مع السعر. يجب على المشتري اجتياز عملية onboarding، واستيفاء شروط الملكية، وربط محفظته، ولا يتم الكشف إلا عن البيانات الضرورية لمن يملك الصلاحية. تقوم Dusk Trade بتجميع هذه الخطوات كلها ضمن سير عمل واحد، كما أنها تُنسّق بين جزء الأصول وجزء المدفوعات قبل التسوية (settlement).
برأيي، هذا هو جوهر معنى النيوبروكر في سياق RWA. القيمة لا تكمن في تحويل السندات أو الصناديق إلى توكنات ثم وضعها في تطبيق جديد. الأهم والأصعب هو جعل الملكية وشروط التداول وخصوصية البيانات والتسوية تعمل معًا بسلاسة.
لكنني ما زلت لا أريد تقييم Dusk Trade من خلال قائمة الانتظار (waitlist).
عدد المسجلين لا يخبرنا إلا بوجود فضول. والأهم للمراقبة هو: أي الأصول الحقيقية يضعها المُصدر (issuer) على المنصة، وكم عدد الحسابات المؤهلة فعليًا للقيام بعمليات تداول، ومدى قيمة التداولات التي تم تسويتها فعليًا عبر النظام.
حتى الآن، ما زال Dusk يصف Dusk Trade على أنها منتج قيد الإنشاء. لذلك بالنسبة لي، فإن المحطة الأهم ليست عدد الأشخاص الذين ينتظرون الانضمام إلى التطبيق، بل اللحظة التي يبدأ فيها MMF أو السندات أو الأصول المُنظّمة الأخرى في توليد حجم تداول حقيقي.
قد يجذب السرد (narrative) الانتباه.
أما التسوية الحقيقية فهي التي تُثبت وجود السوق.
@Dusk $DUSK #dusk
$CLO $LAB
إذا نظرنا فقط من جهة المستخدم، تبدو Dusk Trade أشبه بمكان للعثور على الأصول المُرمّزة والتداول فيها، لكن ما يهمني أكثر يقع خلف شاشة منصة البيع والشراء.
بالنسبة للأصول الخاضعة للإدارة، لا يكفي أن تتطابق الأوامر مع السعر. يجب على المشتري اجتياز عملية onboarding، واستيفاء شروط الملكية، وربط محفظته، ولا يتم الكشف إلا عن البيانات الضرورية لمن يملك الصلاحية. تقوم Dusk Trade بتجميع هذه الخطوات كلها ضمن سير عمل واحد، كما أنها تُنسّق بين جزء الأصول وجزء المدفوعات قبل التسوية (settlement).
برأيي، هذا هو جوهر معنى النيوبروكر في سياق RWA. القيمة لا تكمن في تحويل السندات أو الصناديق إلى توكنات ثم وضعها في تطبيق جديد. الأهم والأصعب هو جعل الملكية وشروط التداول وخصوصية البيانات والتسوية تعمل معًا بسلاسة.
لكنني ما زلت لا أريد تقييم Dusk Trade من خلال قائمة الانتظار (waitlist).
عدد المسجلين لا يخبرنا إلا بوجود فضول. والأهم للمراقبة هو: أي الأصول الحقيقية يضعها المُصدر (issuer) على المنصة، وكم عدد الحسابات المؤهلة فعليًا للقيام بعمليات تداول، ومدى قيمة التداولات التي تم تسويتها فعليًا عبر النظام.
حتى الآن، ما زال Dusk يصف Dusk Trade على أنها منتج قيد الإنشاء. لذلك بالنسبة لي، فإن المحطة الأهم ليست عدد الأشخاص الذين ينتظرون الانضمام إلى التطبيق، بل اللحظة التي يبدأ فيها MMF أو السندات أو الأصول المُنظّمة الأخرى في توليد حجم تداول حقيقي.
قد يجذب السرد (narrative) الانتباه.
أما التسوية الحقيقية فهي التي تُثبت وجود السوق.
@Dusk $DUSK #dusk
$CLO $LAB
2
1
97
الأسبوع الماضي، صديقي لعب صفقة alpha وربح 20 ألف دولار، فقرر بيع USDT لالتقاط القاع. قال إن أمر P2P في ذلك اليوم كان يبدو طبيعيًا جدًا. كان المال قد دخل بالكامل، واسم المُحوِّل قريب جدًا من المعلومات الموجودة في الطلب، ومحتوى التحويل لم يكن فيه شيء غير معتاد، لذلك قام بإطلاق (release) الصفقة مباشرة دون تفكير.
بعد بضعة أيام، تواصل البنك معه مرة أخرى ليطلب مصدر الأموال، ثم قام بقفل حسابه البنكي.
جعلتني هذه الحالة أدرك أمرًا: الـ escrow يحمي العملات المشفرة أثناء إجراء المعاملة، لكنه لا يستطيع أن يتكلم بدل البائع حول من أين تأتي أموال الـ fiat قبل أن تصل إلى حساب البنك.
هذا النوع من المخاطر لا يظهر فورًا على الشاشة. بمجرد إتمام الطلب ومغادرة USDT للمحفظة، قد يظهر السؤال عن مصدر الأموال.
كلما أجريت المزيد من المعاملات، كنت أرى أن التصرف تلقائيًا أحيانًا يكون أخطر من كونك مبتدئًا. بعد عشرات الأوامر السلسة، يصبح من السهل أن تظن أن المبلغ صحيح، وأن المشتري محترم، وأن لدى Merchant سجلًا جيدًا، وبالتالي أن كل شيء سيكون على ما يرام.
لكن هذه الإشارات لا تعوض التحقق من المُحوِّل.
عند بيع P2P، أولوِّي دائمًا لاستخدام حساب دفع مطابق اسمه مع الشخص المذكور في الطلب، وأحافظ على كل المراسلات داخل Binance، وأحتفظ برقم Order ID مع مستندات البنك. إذا كانت الأموال قادمة من حساب طرف ثالث أو كانت هناك معلومات لا تتطابق، لا أستنتج الأسباب بنفسي ثم أُطلق الصفقة لكي تنتهي.
ليس كل معاملة يكون فيها الاسم مختلفًا تكون فيها مشكلة، لكن إذا لم أفهم بوضوح مصدر الأموال، فلا يوجد لدي سبب يجعلني أُسرع في فتح قفل العملات المشفرة.
السلامة في P2P ليست فقط تجنب خسارة USDT مباشرة داخل الصفقة
أحيانًا تكون أيضًا ضمانًا بأنه بعد بضعة أيام، ما زلت أملك أدلة كافية لشرح مسار تدفق الأموال التي مرت عبر حسابي بشكل واضح.
@Binance_Vietnam #BinanceP2PAnToan
$APR $CLO $BTC
الأسبوع الماضي، صديقي لعب صفقة alpha وربح 20 ألف دولار، فقرر بيع USDT لالتقاط القاع. قال إن أمر P2P في ذلك اليوم كان يبدو طبيعيًا جدًا. كان المال قد دخل بالكامل، واسم المُحوِّل قريب جدًا من المعلومات الموجودة في الطلب، ومحتوى التحويل لم يكن فيه شيء غير معتاد، لذلك قام بإطلاق (release) الصفقة مباشرة دون تفكير.
بعد بضعة أيام، تواصل البنك معه مرة أخرى ليطلب مصدر الأموال، ثم قام بقفل حسابه البنكي.
جعلتني هذه الحالة أدرك أمرًا: الـ escrow يحمي العملات المشفرة أثناء إجراء المعاملة، لكنه لا يستطيع أن يتكلم بدل البائع حول من أين تأتي أموال الـ fiat قبل أن تصل إلى حساب البنك.
هذا النوع من المخاطر لا يظهر فورًا على الشاشة. بمجرد إتمام الطلب ومغادرة USDT للمحفظة، قد يظهر السؤال عن مصدر الأموال.
كلما أجريت المزيد من المعاملات، كنت أرى أن التصرف تلقائيًا أحيانًا يكون أخطر من كونك مبتدئًا. بعد عشرات الأوامر السلسة، يصبح من السهل أن تظن أن المبلغ صحيح، وأن المشتري محترم، وأن لدى Merchant سجلًا جيدًا، وبالتالي أن كل شيء سيكون على ما يرام.
لكن هذه الإشارات لا تعوض التحقق من المُحوِّل.
عند بيع P2P، أولوِّي دائمًا لاستخدام حساب دفع مطابق اسمه مع الشخص المذكور في الطلب، وأحافظ على كل المراسلات داخل Binance، وأحتفظ برقم Order ID مع مستندات البنك. إذا كانت الأموال قادمة من حساب طرف ثالث أو كانت هناك معلومات لا تتطابق، لا أستنتج الأسباب بنفسي ثم أُطلق الصفقة لكي تنتهي.
ليس كل معاملة يكون فيها الاسم مختلفًا تكون فيها مشكلة، لكن إذا لم أفهم بوضوح مصدر الأموال، فلا يوجد لدي سبب يجعلني أُسرع في فتح قفل العملات المشفرة.
السلامة في P2P ليست فقط تجنب خسارة USDT مباشرة داخل الصفقة
أحيانًا تكون أيضًا ضمانًا بأنه بعد بضعة أيام، ما زلت أملك أدلة كافية لشرح مسار تدفق الأموال التي مرت عبر حسابي بشكل واضح.
@Binance Vietnam #BinanceP2PAnToan
$APR $CLO $BTC
بعد بضعة أيام، تواصل البنك معه مرة أخرى ليطلب مصدر الأموال، ثم قام بقفل حسابه البنكي.
جعلتني هذه الحالة أدرك أمرًا: الـ escrow يحمي العملات المشفرة أثناء إجراء المعاملة، لكنه لا يستطيع أن يتكلم بدل البائع حول من أين تأتي أموال الـ fiat قبل أن تصل إلى حساب البنك.
هذا النوع من المخاطر لا يظهر فورًا على الشاشة. بمجرد إتمام الطلب ومغادرة USDT للمحفظة، قد يظهر السؤال عن مصدر الأموال.
كلما أجريت المزيد من المعاملات، كنت أرى أن التصرف تلقائيًا أحيانًا يكون أخطر من كونك مبتدئًا. بعد عشرات الأوامر السلسة، يصبح من السهل أن تظن أن المبلغ صحيح، وأن المشتري محترم، وأن لدى Merchant سجلًا جيدًا، وبالتالي أن كل شيء سيكون على ما يرام.
لكن هذه الإشارات لا تعوض التحقق من المُحوِّل.
عند بيع P2P، أولوِّي دائمًا لاستخدام حساب دفع مطابق اسمه مع الشخص المذكور في الطلب، وأحافظ على كل المراسلات داخل Binance، وأحتفظ برقم Order ID مع مستندات البنك. إذا كانت الأموال قادمة من حساب طرف ثالث أو كانت هناك معلومات لا تتطابق، لا أستنتج الأسباب بنفسي ثم أُطلق الصفقة لكي تنتهي.
ليس كل معاملة يكون فيها الاسم مختلفًا تكون فيها مشكلة، لكن إذا لم أفهم بوضوح مصدر الأموال، فلا يوجد لدي سبب يجعلني أُسرع في فتح قفل العملات المشفرة.
السلامة في P2P ليست فقط تجنب خسارة USDT مباشرة داخل الصفقة
أحيانًا تكون أيضًا ضمانًا بأنه بعد بضعة أيام، ما زلت أملك أدلة كافية لشرح مسار تدفق الأموال التي مرت عبر حسابي بشكل واضح.
@Binance Vietnam #BinanceP2PAnToan
$APR $CLO $BTC
1
2
955
TermMax لا يزيل حالة عدم اليقين؛ بل يحدد تسعيرًا غير مؤكد قبل بدء التداول
في البداية اعتقدت أن الإقراض بسعر ثابت جذاب لأنه يساعد المقترض على الهروب من تذبذب أسعار الفائدة. اختر مدة، ثبّت مستوى التكلفة، واعرف مسبقًا كم يجب أن تدفع عند الاستحقاق. يبدو الأمر وكأنه نقيض تام تقريبًا لبقية عالم DeFi.
لكن عند قراءة آلية TermMax بتأنٍ، أدركت أن “الثابت” لا يعني اختفاء المخاطر.
تم تصميم FT بشكل يشبه سند صفر قسيمة: فهو يمثل الحق في استلام كمية محددة من توكن الدَّين في يوم الاستحقاق. وبفضل ذلك يعرف المُقرض مسبقًا قيمة ما سيحصل عليه، بينما يستطيع المقترض تثبيت تكلفة رأس المال من البداية.
والشيء المثير للاهتمام أن نفس البنية الأساسية تدعم الرافعة المالية والاستراتيجيات التي تسعى إلى تحقيق عائد إضافي.
أما @termmax فلا “يمسح” عدم اليقين من السوق. بل ينقل الجزء غير المؤكد إلى لحظة التسعير. عندما يتكوّن سعر ثابت، ما زال يتعين على المشاركين أن يقرروا ما إذا كان هذا المستوى يعكس توقعات الفائدة والسيولة والمخاطر خلال كامل مدة العقد بشكل صحيح أم لا.
إذا تغيّر السوق بعد فتح المركز، فلن يتغير العقد وفقًا لذلك. يحصل المستخدمون على قدر من اليقين، لكن بالمقابل يقبلون احتمال أن يصبح السعر الذي تم تثبيته لاحقًا أقل جاذبية من سعر السوق.
برأيي، هذه هي النقطة الأكثر لفتًا للانتباه في #TermMax .
السعر الثابت ليس وعدًا بأن DeFi سيتوقف عن التذبذب. إنه طريقة لتحويل تذبذب المستقبل إلى سعر يمكن الموافقة عليه اليوم.
السؤال الذي يهمني ليس مقدار المخاطر التي يمكن لـ TermMax إزالتها، بل مدى دقة تسعير سوقه لتلك المخاطر قبل أن يقوم المستخدم بتثبيت المدة والالتزام برأس مال فعلي.
$BTC $BNB $X
TermMax لا يزيل حالة عدم اليقين؛ بل يحدد تسعيرًا غير مؤكد قبل بدء التداول
في البداية اعتقدت أن الإقراض بسعر ثابت جذاب لأنه يساعد المقترض على الهروب من تذبذب أسعار الفائدة. اختر مدة، ثبّت مستوى التكلفة، واعرف مسبقًا كم يجب أن تدفع عند الاستحقاق. يبدو الأمر وكأنه نقيض تام تقريبًا لبقية عالم DeFi.
لكن عند قراءة آلية TermMax بتأنٍ، أدركت أن “الثابت” لا يعني اختفاء المخاطر.
تم تصميم FT بشكل يشبه سند صفر قسيمة: فهو يمثل الحق في استلام كمية محددة من توكن الدَّين في يوم الاستحقاق. وبفضل ذلك يعرف المُقرض مسبقًا قيمة ما سيحصل عليه، بينما يستطيع المقترض تثبيت تكلفة رأس المال من البداية.
والشيء المثير للاهتمام أن نفس البنية الأساسية تدعم الرافعة المالية والاستراتيجيات التي تسعى إلى تحقيق عائد إضافي.
أما @TermMax فلا “يمسح” عدم اليقين من السوق. بل ينقل الجزء غير المؤكد إلى لحظة التسعير. عندما يتكوّن سعر ثابت، ما زال يتعين على المشاركين أن يقرروا ما إذا كان هذا المستوى يعكس توقعات الفائدة والسيولة والمخاطر خلال كامل مدة العقد بشكل صحيح أم لا.
إذا تغيّر السوق بعد فتح المركز، فلن يتغير العقد وفقًا لذلك. يحصل المستخدمون على قدر من اليقين، لكن بالمقابل يقبلون احتمال أن يصبح السعر الذي تم تثبيته لاحقًا أقل جاذبية من سعر السوق.
برأيي، هذه هي النقطة الأكثر لفتًا للانتباه في #TermMax .
السعر الثابت ليس وعدًا بأن DeFi سيتوقف عن التذبذب. إنه طريقة لتحويل تذبذب المستقبل إلى سعر يمكن الموافقة عليه اليوم.
السؤال الذي يهمني ليس مقدار المخاطر التي يمكن لـ TermMax إزالتها، بل مدى دقة تسعير سوقه لتلك المخاطر قبل أن يقوم المستخدم بتثبيت المدة والالتزام برأس مال فعلي.
$BTC $BNB $X
في البداية اعتقدت أن الإقراض بسعر ثابت جذاب لأنه يساعد المقترض على الهروب من تذبذب أسعار الفائدة. اختر مدة، ثبّت مستوى التكلفة، واعرف مسبقًا كم يجب أن تدفع عند الاستحقاق. يبدو الأمر وكأنه نقيض تام تقريبًا لبقية عالم DeFi.
لكن عند قراءة آلية TermMax بتأنٍ، أدركت أن “الثابت” لا يعني اختفاء المخاطر.
تم تصميم FT بشكل يشبه سند صفر قسيمة: فهو يمثل الحق في استلام كمية محددة من توكن الدَّين في يوم الاستحقاق. وبفضل ذلك يعرف المُقرض مسبقًا قيمة ما سيحصل عليه، بينما يستطيع المقترض تثبيت تكلفة رأس المال من البداية.
والشيء المثير للاهتمام أن نفس البنية الأساسية تدعم الرافعة المالية والاستراتيجيات التي تسعى إلى تحقيق عائد إضافي.
أما @TermMax فلا “يمسح” عدم اليقين من السوق. بل ينقل الجزء غير المؤكد إلى لحظة التسعير. عندما يتكوّن سعر ثابت، ما زال يتعين على المشاركين أن يقرروا ما إذا كان هذا المستوى يعكس توقعات الفائدة والسيولة والمخاطر خلال كامل مدة العقد بشكل صحيح أم لا.
إذا تغيّر السوق بعد فتح المركز، فلن يتغير العقد وفقًا لذلك. يحصل المستخدمون على قدر من اليقين، لكن بالمقابل يقبلون احتمال أن يصبح السعر الذي تم تثبيته لاحقًا أقل جاذبية من سعر السوق.
برأيي، هذه هي النقطة الأكثر لفتًا للانتباه في #TermMax .
السعر الثابت ليس وعدًا بأن DeFi سيتوقف عن التذبذب. إنه طريقة لتحويل تذبذب المستقبل إلى سعر يمكن الموافقة عليه اليوم.
السؤال الذي يهمني ليس مقدار المخاطر التي يمكن لـ TermMax إزالتها، بل مدى دقة تسعير سوقه لتلك المخاطر قبل أن يقوم المستخدم بتثبيت المدة والالتزام برأس مال فعلي.
$BTC $BNB $X
2
1
223
لا يتحدث Halving الخاصة بـ Dusk معي عن مقدار ربح الإيداع
في البداية اعتقدت أنه يكفي النظر إلى جدول إصدار Dusk لتقدير عائد staking بدقة إلى حد ما، لكن عند وضع رقم الانبعاث مقارنةً بكمية DUSK التي يتم إيداعها فعليًا، أدركت أن هذين الأمرين مرتبطان، لكنهما ليسا شيئًا واحدًا.
وفقًا للآلية الحالية، تقوم الشبكة بإصدار 19.8 DUSK لكل بلوك. إجمالي كمية الإصدار المتوقعة هو 500 مليون DUSK خلال 36 عامًا، وتنخفض سرعة الانبعاث إلى النصف بعد كل أربع سنوات. هذا الجزء يمكن توقعه بسهولة لأنه مُحدد على مستوى البروتوكول.
لكن عائد كل من يقوم بالإيداع يعتمد على متغيرات أخرى.
إذا زاد إجمالي الإيداع النشط، فإن حصة كل مُحقق/validator أو مُفوّض/delegator من إجمالي حصة المكافآت ستصبح أصغر، بافتراض أن العوامل الأخرى ثابتة. بالإضافة إلى ذلك، توجد درجة المشاركة في الإجماع ورسوم المعاملات. لذلك حتى مع نفس مستوى الانبعاث لكل بلوك، يمكن أن يتغير APY الفعلي بشكل ملحوظ.
وهنا أخطأتُ سابقًا بين مفهومين.
يشير Halving فقط إلى معدل إدخال DUSK الجديدة إلى نظام حصة المكافآت. ولا يخبرك بمقدار الـ stake الخاص بك الذي سيحصل عليه. إن جدول إصدار ثابت يجعل مصدر العرض الخاص بالمكافآت أكثر قابلية للتنبؤ، لكنه لا يلغي المنافسة بين المشاركين في staking.
لذلك إذا كنت أريد تقييم staking، فلن أكتفي بالنظر إلى جدول halving. سأتابع أيضًا إجمالي الإيداع النشط ومعدل تغيّر هذه الكمية بمرور الوقت.
كلما أصبح الانبعاث أسهل في التنبؤ، زادت أهمية المنافسة بين من يقومون بالإيداع باعتبارها متغيرًا رئيسيًا.
برأيي، في حالة Dusk، السؤال الذي يستحق الاهتمام ليس “كم تكون المكافأة لكل بلوك؟” بل “كم عدد DUSK التي تتنافس جميعها للحصول على تلك المكافآت؟”
@Dusk_Foundation $DUSK #dusk
$STBL $LAB
لا يتحدث Halving الخاصة بـ Dusk معي عن مقدار ربح الإيداع
في البداية اعتقدت أنه يكفي النظر إلى جدول إصدار Dusk لتقدير عائد staking بدقة إلى حد ما، لكن عند وضع رقم الانبعاث مقارنةً بكمية DUSK التي يتم إيداعها فعليًا، أدركت أن هذين الأمرين مرتبطان، لكنهما ليسا شيئًا واحدًا.
وفقًا للآلية الحالية، تقوم الشبكة بإصدار 19.8 DUSK لكل بلوك. إجمالي كمية الإصدار المتوقعة هو 500 مليون DUSK خلال 36 عامًا، وتنخفض سرعة الانبعاث إلى النصف بعد كل أربع سنوات. هذا الجزء يمكن توقعه بسهولة لأنه مُحدد على مستوى البروتوكول.
لكن عائد كل من يقوم بالإيداع يعتمد على متغيرات أخرى.
إذا زاد إجمالي الإيداع النشط، فإن حصة كل مُحقق/validator أو مُفوّض/delegator من إجمالي حصة المكافآت ستصبح أصغر، بافتراض أن العوامل الأخرى ثابتة. بالإضافة إلى ذلك، توجد درجة المشاركة في الإجماع ورسوم المعاملات. لذلك حتى مع نفس مستوى الانبعاث لكل بلوك، يمكن أن يتغير APY الفعلي بشكل ملحوظ.
وهنا أخطأتُ سابقًا بين مفهومين.
يشير Halving فقط إلى معدل إدخال DUSK الجديدة إلى نظام حصة المكافآت. ولا يخبرك بمقدار الـ stake الخاص بك الذي سيحصل عليه. إن جدول إصدار ثابت يجعل مصدر العرض الخاص بالمكافآت أكثر قابلية للتنبؤ، لكنه لا يلغي المنافسة بين المشاركين في staking.
لذلك إذا كنت أريد تقييم staking، فلن أكتفي بالنظر إلى جدول halving. سأتابع أيضًا إجمالي الإيداع النشط ومعدل تغيّر هذه الكمية بمرور الوقت.
كلما أصبح الانبعاث أسهل في التنبؤ، زادت أهمية المنافسة بين من يقومون بالإيداع باعتبارها متغيرًا رئيسيًا.
برأيي، في حالة Dusk، السؤال الذي يستحق الاهتمام ليس “كم تكون المكافأة لكل بلوك؟” بل “كم عدد DUSK التي تتنافس جميعها للحصول على تلك المكافآت؟”
@Dusk $DUSK #dusk
$STBL $LAB
في البداية اعتقدت أنه يكفي النظر إلى جدول إصدار Dusk لتقدير عائد staking بدقة إلى حد ما، لكن عند وضع رقم الانبعاث مقارنةً بكمية DUSK التي يتم إيداعها فعليًا، أدركت أن هذين الأمرين مرتبطان، لكنهما ليسا شيئًا واحدًا.
وفقًا للآلية الحالية، تقوم الشبكة بإصدار 19.8 DUSK لكل بلوك. إجمالي كمية الإصدار المتوقعة هو 500 مليون DUSK خلال 36 عامًا، وتنخفض سرعة الانبعاث إلى النصف بعد كل أربع سنوات. هذا الجزء يمكن توقعه بسهولة لأنه مُحدد على مستوى البروتوكول.
لكن عائد كل من يقوم بالإيداع يعتمد على متغيرات أخرى.
إذا زاد إجمالي الإيداع النشط، فإن حصة كل مُحقق/validator أو مُفوّض/delegator من إجمالي حصة المكافآت ستصبح أصغر، بافتراض أن العوامل الأخرى ثابتة. بالإضافة إلى ذلك، توجد درجة المشاركة في الإجماع ورسوم المعاملات. لذلك حتى مع نفس مستوى الانبعاث لكل بلوك، يمكن أن يتغير APY الفعلي بشكل ملحوظ.
وهنا أخطأتُ سابقًا بين مفهومين.
يشير Halving فقط إلى معدل إدخال DUSK الجديدة إلى نظام حصة المكافآت. ولا يخبرك بمقدار الـ stake الخاص بك الذي سيحصل عليه. إن جدول إصدار ثابت يجعل مصدر العرض الخاص بالمكافآت أكثر قابلية للتنبؤ، لكنه لا يلغي المنافسة بين المشاركين في staking.
لذلك إذا كنت أريد تقييم staking، فلن أكتفي بالنظر إلى جدول halving. سأتابع أيضًا إجمالي الإيداع النشط ومعدل تغيّر هذه الكمية بمرور الوقت.
كلما أصبح الانبعاث أسهل في التنبؤ، زادت أهمية المنافسة بين من يقومون بالإيداع باعتبارها متغيرًا رئيسيًا.
برأيي، في حالة Dusk، السؤال الذي يستحق الاهتمام ليس “كم تكون المكافأة لكل بلوك؟” بل “كم عدد DUSK التي تتنافس جميعها للحصول على تلك المكافآت؟”
@Dusk $DUSK #dusk
$STBL $LAB
7
2
141
استخدمت Binance P2P منذ عام 2022، وكلما طالت مدة التداول قلَّ اهتمامي بموضوع “اصطياد السعر الجميل”
قمت بمراجعة صور التداول بتاريخ 21/1/2022 ووجدت أمر بيع بقيمة 1.656 USDT، تلقيت مقابل ذلك 38.836.512đ، أي ما يعادل حوالي 23.452đ/USDT.
وعند النظر مجددًا، أدركت أنني استخدمت Binance P2P منذ وقت طويل. في البداية كنت مهتمًا بأمر واحد فقط: التاجر الذي يشتري بسعر أعلى هو من أختاره. بعد سنوات عديدة، تغيرت طريقة تداولِي كثيرًا.
أول نصيحة هي ألا تراقب السعر فقط. فرق بضعة عشرات من الدونغ لكل USDT ليس جديرًا بأن يُضحى به مقابل شريك يرد ببطء، أو شروط معقّدة، أو سجل تداول غير مستقر. كنت دائمًا أتحقق من Completion Rate، عدد الأوامر المكتملة، حدود التداول، وطريقة الدفع قبل فتح الأمر.
كما أنني أنظر إلى عدة إعلانات في نفس الوقت لأعرف الصورة العامة. أن يكون الإعلان في أعلى الصفحة لا يعني بالضرورة أنه بأفضل سعر، لذلك قد تساعد بضع ثوانٍ للمقارنة على تجنب أمر بسعر منحرف كثيرًا.
النصيحة الثانية: عند بيع USDT لا أفرج عنه إلا بعد أن أفتح تطبيق البنك بنفسي وأرى أن الأموال دخلت فعلًا. صورة تحويل، أو SMS، أو رسالة مثل “لقد حولت بالفعل” لا يمكنها أن تعوض هذه الخطوة.
النصيحة الثالثة: جميع المراسلات التي أجريها أبقيها داخل Order Chat. إذا طلب الشريك الانتقال إلى Zalo أو Telegram أو تغيير حساب استلام الأموال أو التعامل خارج Binance، أتوقف فورًا.
وبالنسبة للأوامر الكبيرة، غالبًا ما أقسمها إلى أجزاء أصغر. تساعد هذه الطريقة على التحكم بشكل أفضل في تدفق الأموال وتقليل الضغط عندما تنشأ مشكلة في صفقة ما.
وأخيرًا، أعطي دائمًا الأولوية للإجراءات لا للسرعة. إن P2P الفعّال ليس أسرع تداول أو مجرد ربح بضع عشرات الآلاف.
بل هو اللحظة التي تتدفق فيها الأموال بشكل صحيح، وتتطابق المعلومات، وتكون الأدلة كافية، ولا أضطر إلى المراهنة على حدسي.
@Binance_Vietnam #BinanceP2PAnToan
$BTC $APR $LAB
استخدمت Binance P2P منذ عام 2022، وكلما طالت مدة التداول قلَّ اهتمامي بموضوع “اصطياد السعر الجميل”
قمت بمراجعة صور التداول بتاريخ 21/1/2022 ووجدت أمر بيع بقيمة 1.656 USDT، تلقيت مقابل ذلك 38.836.512đ، أي ما يعادل حوالي 23.452đ/USDT.
وعند النظر مجددًا، أدركت أنني استخدمت Binance P2P منذ وقت طويل. في البداية كنت مهتمًا بأمر واحد فقط: التاجر الذي يشتري بسعر أعلى هو من أختاره. بعد سنوات عديدة، تغيرت طريقة تداولِي كثيرًا.
أول نصيحة هي ألا تراقب السعر فقط. فرق بضعة عشرات من الدونغ لكل USDT ليس جديرًا بأن يُضحى به مقابل شريك يرد ببطء، أو شروط معقّدة، أو سجل تداول غير مستقر. كنت دائمًا أتحقق من Completion Rate، عدد الأوامر المكتملة، حدود التداول، وطريقة الدفع قبل فتح الأمر.
كما أنني أنظر إلى عدة إعلانات في نفس الوقت لأعرف الصورة العامة. أن يكون الإعلان في أعلى الصفحة لا يعني بالضرورة أنه بأفضل سعر، لذلك قد تساعد بضع ثوانٍ للمقارنة على تجنب أمر بسعر منحرف كثيرًا.
النصيحة الثانية: عند بيع USDT لا أفرج عنه إلا بعد أن أفتح تطبيق البنك بنفسي وأرى أن الأموال دخلت فعلًا. صورة تحويل، أو SMS، أو رسالة مثل “لقد حولت بالفعل” لا يمكنها أن تعوض هذه الخطوة.
النصيحة الثالثة: جميع المراسلات التي أجريها أبقيها داخل Order Chat. إذا طلب الشريك الانتقال إلى Zalo أو Telegram أو تغيير حساب استلام الأموال أو التعامل خارج Binance، أتوقف فورًا.
وبالنسبة للأوامر الكبيرة، غالبًا ما أقسمها إلى أجزاء أصغر. تساعد هذه الطريقة على التحكم بشكل أفضل في تدفق الأموال وتقليل الضغط عندما تنشأ مشكلة في صفقة ما.
وأخيرًا، أعطي دائمًا الأولوية للإجراءات لا للسرعة. إن P2P الفعّال ليس أسرع تداول أو مجرد ربح بضع عشرات الآلاف.
بل هو اللحظة التي تتدفق فيها الأموال بشكل صحيح، وتتطابق المعلومات، وتكون الأدلة كافية، ولا أضطر إلى المراهنة على حدسي.
@Binance Vietnam #BinanceP2PAnToan
$BTC $APR $LAB
قمت بمراجعة صور التداول بتاريخ 21/1/2022 ووجدت أمر بيع بقيمة 1.656 USDT، تلقيت مقابل ذلك 38.836.512đ، أي ما يعادل حوالي 23.452đ/USDT.
وعند النظر مجددًا، أدركت أنني استخدمت Binance P2P منذ وقت طويل. في البداية كنت مهتمًا بأمر واحد فقط: التاجر الذي يشتري بسعر أعلى هو من أختاره. بعد سنوات عديدة، تغيرت طريقة تداولِي كثيرًا.
أول نصيحة هي ألا تراقب السعر فقط. فرق بضعة عشرات من الدونغ لكل USDT ليس جديرًا بأن يُضحى به مقابل شريك يرد ببطء، أو شروط معقّدة، أو سجل تداول غير مستقر. كنت دائمًا أتحقق من Completion Rate، عدد الأوامر المكتملة، حدود التداول، وطريقة الدفع قبل فتح الأمر.
كما أنني أنظر إلى عدة إعلانات في نفس الوقت لأعرف الصورة العامة. أن يكون الإعلان في أعلى الصفحة لا يعني بالضرورة أنه بأفضل سعر، لذلك قد تساعد بضع ثوانٍ للمقارنة على تجنب أمر بسعر منحرف كثيرًا.
النصيحة الثانية: عند بيع USDT لا أفرج عنه إلا بعد أن أفتح تطبيق البنك بنفسي وأرى أن الأموال دخلت فعلًا. صورة تحويل، أو SMS، أو رسالة مثل “لقد حولت بالفعل” لا يمكنها أن تعوض هذه الخطوة.
النصيحة الثالثة: جميع المراسلات التي أجريها أبقيها داخل Order Chat. إذا طلب الشريك الانتقال إلى Zalo أو Telegram أو تغيير حساب استلام الأموال أو التعامل خارج Binance، أتوقف فورًا.
وبالنسبة للأوامر الكبيرة، غالبًا ما أقسمها إلى أجزاء أصغر. تساعد هذه الطريقة على التحكم بشكل أفضل في تدفق الأموال وتقليل الضغط عندما تنشأ مشكلة في صفقة ما.
وأخيرًا، أعطي دائمًا الأولوية للإجراءات لا للسرعة. إن P2P الفعّال ليس أسرع تداول أو مجرد ربح بضع عشرات الآلاف.
بل هو اللحظة التي تتدفق فيها الأموال بشكل صحيح، وتتطابق المعلومات، وتكون الأدلة كافية، ولا أضطر إلى المراهنة على حدسي.
@Binance Vietnam #BinanceP2PAnToan
$BTC $APR $LAB
1
3
428
إن رؤية مفتاح غسق جعلتني أفكر أكثر في “حقّ الاطلاع”
عندما قرأت عن فينيكس، لاحظت في البداية الجزء الخاص بالمعاملات الذي يتم إخفاؤه عن المراقبة العامة، لكن ما جعل الأمر أكثر صعوبة بالنسبة لي كان ما يُعرف بالإفصاح الانتقائي.
تتيح فينيكس لمُلاكها مشاركة مفتاح العرض كي يتمكن طرفٌ آخر من التعرف على المخرجات التابعة لهم، ثم قراءة الجزء ذي القيمة المقابلة باستخدام البيانات المُشفرة. وهذا يتوافق مع أعمال التدقيق أو إعداد التقارير، لأن من يحتاج للتحقق يمكنه الاطلاع على معلومات كافية دون تحويل المعاملة برمتها إلى بيانات عامة.
لكن من هنا يبرز سؤالٌ أقلّ ما يُتداول: إلى متى ينبغي أن يستمر “حقّ الاطلاع”؟
للتدقيق وقت بداية ووقت نهاية. أما مفتاح العرض فهو حق وصول قائم على التشفير. فإذا شاركت مؤسسة ما هذا المفتاح مع المدققين، فالأهم ليس فقط من يطّلع، بل أيضًا ما نطاق البيانات التي يراها، وكيف تتم إدارة المفتاح، وماذا يحدث عندما تكتمل الأهداف الأصلية.
في رأيي، هذه هي المسألة الأكثر واقعية في الخصوصية أكثر من مجرد إخفاء الرصيد عن الـ explorer.
يمكن للسلسلة أن تمنع الجمهور من رؤية بيانات فينيكس، لكن بمجرد الإفصاح بشكلٍ صحيح وشرعي، لا يمكن للنظام أن يجعل نسخ الطرف المُستلم تختفي تلقائيًا. لذلك فالخصوصية لا تنتهي عند التشفير وحده؛ بل تعتمد كذلك على حوكمة صلاحيات الوصول وعلى الإجراءات خارج السلسلة.
ما أريد متابعته في #dusk l هو كيفية تقييد “سلطة الاطلاع” فعليًا.
من الذي يُسمح له بالاطلاع؟ وأي جزء يُسمح له برؤيته ولمدة كم؟
إذا استطاع الإفصاح الانتقائي الإجابة عن هذه الأسئلة الثلاثة، عندها فقط تصبح الخصوصية حقًا أداةً للمالية المُدارة.
@Dusk_Foundation $DUSK $Q $BASED
إن رؤية مفتاح غسق جعلتني أفكر أكثر في “حقّ الاطلاع”
عندما قرأت عن فينيكس، لاحظت في البداية الجزء الخاص بالمعاملات الذي يتم إخفاؤه عن المراقبة العامة، لكن ما جعل الأمر أكثر صعوبة بالنسبة لي كان ما يُعرف بالإفصاح الانتقائي.
تتيح فينيكس لمُلاكها مشاركة مفتاح العرض كي يتمكن طرفٌ آخر من التعرف على المخرجات التابعة لهم، ثم قراءة الجزء ذي القيمة المقابلة باستخدام البيانات المُشفرة. وهذا يتوافق مع أعمال التدقيق أو إعداد التقارير، لأن من يحتاج للتحقق يمكنه الاطلاع على معلومات كافية دون تحويل المعاملة برمتها إلى بيانات عامة.
لكن من هنا يبرز سؤالٌ أقلّ ما يُتداول: إلى متى ينبغي أن يستمر “حقّ الاطلاع”؟
للتدقيق وقت بداية ووقت نهاية. أما مفتاح العرض فهو حق وصول قائم على التشفير. فإذا شاركت مؤسسة ما هذا المفتاح مع المدققين، فالأهم ليس فقط من يطّلع، بل أيضًا ما نطاق البيانات التي يراها، وكيف تتم إدارة المفتاح، وماذا يحدث عندما تكتمل الأهداف الأصلية.
في رأيي، هذه هي المسألة الأكثر واقعية في الخصوصية أكثر من مجرد إخفاء الرصيد عن الـ explorer.
يمكن للسلسلة أن تمنع الجمهور من رؤية بيانات فينيكس، لكن بمجرد الإفصاح بشكلٍ صحيح وشرعي، لا يمكن للنظام أن يجعل نسخ الطرف المُستلم تختفي تلقائيًا. لذلك فالخصوصية لا تنتهي عند التشفير وحده؛ بل تعتمد كذلك على حوكمة صلاحيات الوصول وعلى الإجراءات خارج السلسلة.
ما أريد متابعته في #dusk l هو كيفية تقييد “سلطة الاطلاع” فعليًا.
من الذي يُسمح له بالاطلاع؟ وأي جزء يُسمح له برؤيته ولمدة كم؟
إذا استطاع الإفصاح الانتقائي الإجابة عن هذه الأسئلة الثلاثة، عندها فقط تصبح الخصوصية حقًا أداةً للمالية المُدارة.
@Dusk $DUSK $Q $BASED
عندما قرأت عن فينيكس، لاحظت في البداية الجزء الخاص بالمعاملات الذي يتم إخفاؤه عن المراقبة العامة، لكن ما جعل الأمر أكثر صعوبة بالنسبة لي كان ما يُعرف بالإفصاح الانتقائي.
تتيح فينيكس لمُلاكها مشاركة مفتاح العرض كي يتمكن طرفٌ آخر من التعرف على المخرجات التابعة لهم، ثم قراءة الجزء ذي القيمة المقابلة باستخدام البيانات المُشفرة. وهذا يتوافق مع أعمال التدقيق أو إعداد التقارير، لأن من يحتاج للتحقق يمكنه الاطلاع على معلومات كافية دون تحويل المعاملة برمتها إلى بيانات عامة.
لكن من هنا يبرز سؤالٌ أقلّ ما يُتداول: إلى متى ينبغي أن يستمر “حقّ الاطلاع”؟
للتدقيق وقت بداية ووقت نهاية. أما مفتاح العرض فهو حق وصول قائم على التشفير. فإذا شاركت مؤسسة ما هذا المفتاح مع المدققين، فالأهم ليس فقط من يطّلع، بل أيضًا ما نطاق البيانات التي يراها، وكيف تتم إدارة المفتاح، وماذا يحدث عندما تكتمل الأهداف الأصلية.
في رأيي، هذه هي المسألة الأكثر واقعية في الخصوصية أكثر من مجرد إخفاء الرصيد عن الـ explorer.
يمكن للسلسلة أن تمنع الجمهور من رؤية بيانات فينيكس، لكن بمجرد الإفصاح بشكلٍ صحيح وشرعي، لا يمكن للنظام أن يجعل نسخ الطرف المُستلم تختفي تلقائيًا. لذلك فالخصوصية لا تنتهي عند التشفير وحده؛ بل تعتمد كذلك على حوكمة صلاحيات الوصول وعلى الإجراءات خارج السلسلة.
ما أريد متابعته في #dusk l هو كيفية تقييد “سلطة الاطلاع” فعليًا.
من الذي يُسمح له بالاطلاع؟ وأي جزء يُسمح له برؤيته ولمدة كم؟
إذا استطاع الإفصاح الانتقائي الإجابة عن هذه الأسئلة الثلاثة، عندها فقط تصبح الخصوصية حقًا أداةً للمالية المُدارة.
@Dusk $DUSK $Q $BASED
4
2
275
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
المواضيع الرائجة
HKCompletesFirstHKDStablecoinUseCase
7,025 مشاهدات
270 يقومون بالنقاش
#hkcompletesfirsthkdstablecoinusecase
🇭🇰 انتظر، عملة مستقرة أخرى؟ 🤯 هونغ كونغ أنهت للتو أول حالة استخدام لاستثمار أصول رقمية باستخدام HKDAP، وهي عملة مستقرة مدعومة بالدولار الهونغ كونغي (HKD) ومنظمة في هونغ كونغ ومغطاة من Standard Chartered.
هل نتجه نحو عالم يكون فيه لدينا عدد كبير من العملات المستقرة مثل عدد العملات الورقية؟ سيكون الأمر فوضويًا تمامًا إذا أنشأت كل دولة عملتها الخاصة! 🌀 تخيّل التبديل من USD إلى HKD إلى EUR لكن عبر عملات مستقرة.
ماذا يجب أن يفعل المتداولون؟
💵 اتبع العملة الورقية: راقب كيف تؤثر العملات المستقرة الإقليمية على السيولة.
💵 حافظ على السيولة: التزم بالعملات المستقرة السائدة مثل USDT/USDC للتداول السريع.
💵 كن مستعدًا: العملات المستقرة المنظمة ستأتي سواء أحببنا ذلك أم لا.
ليس نصيحة مالية! 🚫
متابعة من فضلكم
$BTC
$ETH
$BNB
#HongKongCrypto #stablecoin #HKDAP
Shamika Metting
·1 إعجاب
·750 مشاهدات
VietnamPlansFirstCryptoLicensesIn2026
5,290 مشاهدات
178 يقومون بالنقاش
BTCBreaks80K
209,165 مشاهدات
3,378 يقومون بالنقاش