#dusk $DUSK @Dusk
Tokenisierung wird üblicherweise so beschrieben, dass ein Vermögenswert onchain gestellt wird. In der Praxis ist das selten der Fall. Was onchain passiert, ist eine Behauptung/Anspruch auf den Vermögenswert, während der Vermögenswert selbst in der Datenbank des ursprünglichen Registerbetreibers bleibt, in der er immer schon gespeichert war — und der Lebenszyklus ebenfalls dort mit ihm.
Der Lebenszyklus ist der kostspielige Teil. Eine Anleihe ist kein statisches Objekt. Sie zahlt Kupons, sie führt ein Inhaberregister, sie durchläuft Unternehmensmaßnahmen, sie wird als Sicherheiten verpfändet, sie läuft aus. Jedes dieser Ereignisse ist eine Abstimmung zwischen Systemen, die keine gemeinsame „Quelle der Wahrheit“ haben. Das Einwickeln des Instruments in einen Token beseitigt keines dieser Dinge. Man könnte sogar sagen, es kommt noch eins hinzu, weil nun die Hülle und der zugrunde liegende Vermögenswert voneinander abweichen können.
Nativer Emissionsprozess ist der Anspruch, den @dusk tatsächlich verfolgt: das Instrument überhaupt erst onchain zu erstellen — mit Berechtigung, Übertragungsbeschränkungen und Abwicklungslogik, die in der Protokollschicht ausgedrückt werden, statt später „drangeklebt“ zu werden. Zedger ist das Asset-Protokoll dafür, nativ auf DuskDS ausgeführt, wobei Citadel Identität und selektive Offenlegung übernimmt, sodass die Berechtigung nachgewiesen werden kann, ohne zu veröffentlichen, wer der Inhaber ist.
Die ehrliche Schwierigkeit liegt hier im Recht, nicht in der Technik. Damit ein Ketteneintrag das Register und nicht nur ein Spiegel davon ist, muss das Gesetz es so festlegen — genau dafür wurde das EU-„DLT-Pilot-Regime“ geschaffen, um es zu testen, innerhalb der Instrumentengrenzen und für einen begrenzten Zeitraum.
Die Frage, die sich über $DUSK lohnt zu stellen, lautet also nicht, ob die native Emission im Prinzip besser ist. Sondern ob ein erstes echtes Instrument auf diese Weise ausgegeben wird und die eigenen Kupondaten überlebt. #dusk
Tokenisierung wird üblicherweise so beschrieben, dass ein Vermögenswert onchain gestellt wird. In der Praxis ist das selten der Fall. Was onchain passiert, ist eine Behauptung/Anspruch auf den Vermögenswert, während der Vermögenswert selbst in der Datenbank des ursprünglichen Registerbetreibers bleibt, in der er immer schon gespeichert war — und der Lebenszyklus ebenfalls dort mit ihm.
Der Lebenszyklus ist der kostspielige Teil. Eine Anleihe ist kein statisches Objekt. Sie zahlt Kupons, sie führt ein Inhaberregister, sie durchläuft Unternehmensmaßnahmen, sie wird als Sicherheiten verpfändet, sie läuft aus. Jedes dieser Ereignisse ist eine Abstimmung zwischen Systemen, die keine gemeinsame „Quelle der Wahrheit“ haben. Das Einwickeln des Instruments in einen Token beseitigt keines dieser Dinge. Man könnte sogar sagen, es kommt noch eins hinzu, weil nun die Hülle und der zugrunde liegende Vermögenswert voneinander abweichen können.
Nativer Emissionsprozess ist der Anspruch, den @dusk tatsächlich verfolgt: das Instrument überhaupt erst onchain zu erstellen — mit Berechtigung, Übertragungsbeschränkungen und Abwicklungslogik, die in der Protokollschicht ausgedrückt werden, statt später „drangeklebt“ zu werden. Zedger ist das Asset-Protokoll dafür, nativ auf DuskDS ausgeführt, wobei Citadel Identität und selektive Offenlegung übernimmt, sodass die Berechtigung nachgewiesen werden kann, ohne zu veröffentlichen, wer der Inhaber ist.
Die ehrliche Schwierigkeit liegt hier im Recht, nicht in der Technik. Damit ein Ketteneintrag das Register und nicht nur ein Spiegel davon ist, muss das Gesetz es so festlegen — genau dafür wurde das EU-„DLT-Pilot-Regime“ geschaffen, um es zu testen, innerhalb der Instrumentengrenzen und für einen begrenzten Zeitraum.
Die Frage, die sich über $DUSK lohnt zu stellen, lautet also nicht, ob die native Emission im Prinzip besser ist. Sondern ob ein erstes echtes Instrument auf diese Weise ausgegeben wird und die eigenen Kupondaten überlebt. #dusk