يتلقى الوصي ورقة حصص مكتوب عليها «إيداع قابل للتسييل»، ولا ينبغي أن تكون ردة فعله الأولى اعتبارها وديعة يمكن استردادها في أي وقت. أولًا تتبع هذه الورقة: ما الذي تمثّله هذه الحصة تحديدًا؟ من يمتلك الضمانات الأساسية؟ ماذا تمثّل الحصص؟ وما هي الشروط الخاصة بالسوق أو بالعقود التي يجب أن يمر بها الاسترداد؟ لا يمكن الحكم إلا بعد إكمال هذه السلسلة: هل ما حصل عليه المستخدم هو حصة ضمن آلية النظام، أم منتج يمتلك قدرة تشغيلية كاملة بالفعل.
يمكن أن يبدأ فهم الآلية الأساسية بحقيقة واحدة يمكن التحقق منها: يمكن للعقد الذكي أن يحتفظ بالضمانات على مستوى البروتوكول ويديرها. هذا يفسر لماذا لا يلزم أن تُدار الضمانات فقط بواسطة حسابات عادية مباشرة، كما يضع الأساس لتجميع أصول عدة مشاركين داخل العقد. لكنه لا يجيب الوصي عن كيفية إصدار الحصص، ولا من يتولى التسعير، ولا من يدير عمليات الخروج، ولا يضمن للمستخدم إمكانية الاسترداد وفقًا لما هو متوقع.
انظر إلى تصميم التجميع. عندما تدخل أصول عدة مشاركين إلى عقد واحد، يحتاج النظام إلى تسجيل الحصص الخاصة بكل مشارك والقواعد. وجود الحصص لا يعني عمقًا سوقيًا، وأن العقد يمكنه إدارة الضمانات الأساسية لا يعني أن منتجًا طرفًا ثالثًا أصبح آمنًا أو ملتزمًا أو مستدامًا. عند التقييم، يجب أن تُفصل مسؤوليات: الحيازة، والحصص، والتسعير، والخروج—وتُحدد جهة المسؤول.
إذا كانت الحصص كذلك مُغلّفة على شكل مشتق قابل للتسييل، فستضاف طبقة أخرى من المشاكل: قد ينحرف السعر عن الأصول الأساسية، وقد تكون سيولة التداول غير كافية، وقد يحدث أيضًا فك الارتباط (脱锚). عندها لا يكفي النظر إلى كلمتي «الضمان» فحسب؛ بل يجب التحقق من مخاطر العقد، ومصدر التسعير، ومسار الخروج، وشروط السيولة.
بالنسبة للآليات ذات الصلة بـ @Dusk ، فإن $DUSK ليس التزامًا قابلًا للاسترداد. #dusk يمكنه تفسير كيفية أن العقد الذكي يتكفل بالضمانات على مستوى البروتوكول، لكن لا يمكن تحويل ورقة حصة إلى منتج ناضج، ولا يمكن أن يكون بمثابة مصادقة على حل طرف ثالث.
يجب أن تُكتب نتيجة الإجراءات على النحو التالي: تم التحقق من الآلية الأساسية، وتظل شروط المنتج بانتظار التحقق، ولا يمكن تغطية مخاطر المستخدم باسم واحد موحّد.
لا يمكن للورقة أن تُغني عن إثبات الخروج الكامل.
يرجى إبقاء أثر (سجل).
يمكن أن يبدأ فهم الآلية الأساسية بحقيقة واحدة يمكن التحقق منها: يمكن للعقد الذكي أن يحتفظ بالضمانات على مستوى البروتوكول ويديرها. هذا يفسر لماذا لا يلزم أن تُدار الضمانات فقط بواسطة حسابات عادية مباشرة، كما يضع الأساس لتجميع أصول عدة مشاركين داخل العقد. لكنه لا يجيب الوصي عن كيفية إصدار الحصص، ولا من يتولى التسعير، ولا من يدير عمليات الخروج، ولا يضمن للمستخدم إمكانية الاسترداد وفقًا لما هو متوقع.
انظر إلى تصميم التجميع. عندما تدخل أصول عدة مشاركين إلى عقد واحد، يحتاج النظام إلى تسجيل الحصص الخاصة بكل مشارك والقواعد. وجود الحصص لا يعني عمقًا سوقيًا، وأن العقد يمكنه إدارة الضمانات الأساسية لا يعني أن منتجًا طرفًا ثالثًا أصبح آمنًا أو ملتزمًا أو مستدامًا. عند التقييم، يجب أن تُفصل مسؤوليات: الحيازة، والحصص، والتسعير، والخروج—وتُحدد جهة المسؤول.
إذا كانت الحصص كذلك مُغلّفة على شكل مشتق قابل للتسييل، فستضاف طبقة أخرى من المشاكل: قد ينحرف السعر عن الأصول الأساسية، وقد تكون سيولة التداول غير كافية، وقد يحدث أيضًا فك الارتباط (脱锚). عندها لا يكفي النظر إلى كلمتي «الضمان» فحسب؛ بل يجب التحقق من مخاطر العقد، ومصدر التسعير، ومسار الخروج، وشروط السيولة.
بالنسبة للآليات ذات الصلة بـ @Dusk ، فإن $DUSK ليس التزامًا قابلًا للاسترداد. #dusk يمكنه تفسير كيفية أن العقد الذكي يتكفل بالضمانات على مستوى البروتوكول، لكن لا يمكن تحويل ورقة حصة إلى منتج ناضج، ولا يمكن أن يكون بمثابة مصادقة على حل طرف ثالث.
يجب أن تُكتب نتيجة الإجراءات على النحو التالي: تم التحقق من الآلية الأساسية، وتظل شروط المنتج بانتظار التحقق، ولا يمكن تغطية مخاطر المستخدم باسم واحد موحّد.
لا يمكن للورقة أن تُغني عن إثبات الخروج الكامل.
يرجى إبقاء أثر (سجل).