#dusk $DUSK @Dusk
غالبًا ما يوصف الترقيم/التوكنة بأنها وضع أصل على السلسلة (onchain). لكن هذا نادرًا ما يكون صحيحًا. ما يتم وضعه على السلسلة هو مطالبة بالأصل، بينما يبقى الأصل نفسه في قاعدة بيانات المُسجِّل نفسه الذي كان موجودًا فيها دائمًا — وتبقى دورة حياته هناك معه.
دورة الحياة هي الجزء المكلف. السند ليس كائنًا ثابتًا. فهو يدفع كوبونات، ويحتوي على سجل المالكين/الحامليَن (holder register)، ويمر بإجراءات الشركات (corporate actions)، ويُقدَّم كضمان (يُرهن كضمان)، ويحين تاريخ استحقاقه. كل حدث من هذه الأحداث هو عملية مواءمة/توفيق بين أنظمة لا تشارك مصدرًا واحدًا للحقيقة. إن تغليف الأداة في توكن لا يلغي أيًا من ذلك. بل قد يضيف واحدًا؛ لأنه الآن يمكن أن يختلف الغلاف عن الأصل الكامن.
الإصدار الأصلي (Native issuance) هو المطالبة التي يقوم بها @dusk فعلًا: إنشاء الأداة على السلسلة من الأساس، مع تضمين الأهلية، وقيود التحويل، ومنطق التسوية، على مستوى البروتوكول بدلًا من إضافتها لاحقًا. زيدجر (Zedger) هو بروتوكول الأصول المصمم لذلك، ويعمل بشكل أصلي على DuskDS، بينما تتولى Citadel إدارة الهوية والإفصاح الانتقائي بحيث يمكن إثبات الأهلية دون نشر من هو حامل الأداة.
الصعوبة الحقيقية هنا قانونية وليست تقنية. لكي تكون إدخالات السلسلة هي السجل (register) وليس مجرد نسخة مُطابقة/مرآة عنه، يجب أن ينص القانون على ذلك — وهذا ما تم بناء نظام EU's DLT Pilot Regime لاختباره، ضمن حدود الأدوات (instrument caps) ولمدة محدودة.
لذا فإن السؤال الذي يستحق طرحه حول $DUSK ليس ما إذا كان الإصدار الأصلي أفضل من حيث المبدأ. بل ما إذا تم إصدار أول أداة حقيقية بهذه الطريقة وأن تُستكمل حتى تواريخ كوبوناتها الخاصة بها. #dusk
غالبًا ما يوصف الترقيم/التوكنة بأنها وضع أصل على السلسلة (onchain). لكن هذا نادرًا ما يكون صحيحًا. ما يتم وضعه على السلسلة هو مطالبة بالأصل، بينما يبقى الأصل نفسه في قاعدة بيانات المُسجِّل نفسه الذي كان موجودًا فيها دائمًا — وتبقى دورة حياته هناك معه.
دورة الحياة هي الجزء المكلف. السند ليس كائنًا ثابتًا. فهو يدفع كوبونات، ويحتوي على سجل المالكين/الحامليَن (holder register)، ويمر بإجراءات الشركات (corporate actions)، ويُقدَّم كضمان (يُرهن كضمان)، ويحين تاريخ استحقاقه. كل حدث من هذه الأحداث هو عملية مواءمة/توفيق بين أنظمة لا تشارك مصدرًا واحدًا للحقيقة. إن تغليف الأداة في توكن لا يلغي أيًا من ذلك. بل قد يضيف واحدًا؛ لأنه الآن يمكن أن يختلف الغلاف عن الأصل الكامن.
الإصدار الأصلي (Native issuance) هو المطالبة التي يقوم بها @dusk فعلًا: إنشاء الأداة على السلسلة من الأساس، مع تضمين الأهلية، وقيود التحويل، ومنطق التسوية، على مستوى البروتوكول بدلًا من إضافتها لاحقًا. زيدجر (Zedger) هو بروتوكول الأصول المصمم لذلك، ويعمل بشكل أصلي على DuskDS، بينما تتولى Citadel إدارة الهوية والإفصاح الانتقائي بحيث يمكن إثبات الأهلية دون نشر من هو حامل الأداة.
الصعوبة الحقيقية هنا قانونية وليست تقنية. لكي تكون إدخالات السلسلة هي السجل (register) وليس مجرد نسخة مُطابقة/مرآة عنه، يجب أن ينص القانون على ذلك — وهذا ما تم بناء نظام EU's DLT Pilot Regime لاختباره، ضمن حدود الأدوات (instrument caps) ولمدة محدودة.
لذا فإن السؤال الذي يستحق طرحه حول $DUSK ليس ما إذا كان الإصدار الأصلي أفضل من حيث المبدأ. بل ما إذا تم إصدار أول أداة حقيقية بهذه الطريقة وأن تُستكمل حتى تواريخ كوبوناتها الخاصة بها. #dusk