Ich habe es noch einmal nachgelesen, wie Dusk die Tokenisierung und die native Ausgabe voneinander abgrenzt – eine harte Formulierung: Tokenisierung „digitale Hülle in einem kaputten System“, native Ausgabe – das, wofür es sich zu bemühen lohnt.
Der Unterschied ist konkret. Die Tokenisierung umhüllt einen Vermögenswert, der danach in alten Datenbanken unter alten Prozessen weiterlebt. Die native Ausgabe schafft den Vermögenswert direkt on-chain – mit Compliance und Berechnungsregeln auf Protokoll-Ebene ab dem ersten Tag – ohne dass man das Token mit dem Original abgleichen muss.
Aber ich habe bereits geprüft, worauf sich dieses Versprechen für Dusk stützt: eine Partnerschaft mit NPEX, deren Antrag im Rahmen des EU DLT Pilot Regime bis heute als „designed for“, aber nicht „launched“ beschrieben wird. Die native Ausgabe erfordert nicht nur eine Architektur, sondern auch eine lizenzierte Plattform, die sie tatsächlich umsetzt – und diese Plattform wird noch vorbereitet.
Der architektonische Unterschied ist real, nicht ausgedacht – die Einbindung von Compliance in das Protokoll ist schwieriger, als einen Vermögenswert nur mit einem Etikett zu versehen. Die Entscheidung für „schwieriger“, während man auf die Einsatzbereitschaft wartet, ist eine konsequente Wahl.
$DUSK bleibt als Token des Netzwerks, in dem diese Architektur bereits technisch existiert.
Kann man die native Ausgabe heute schon als eine Möglichkeit von Dusk bezeichnen, wenn die einzige genannte regulierte Plattform dafür den Antrag noch vorbereitet?
@Dusk_Foundation #dusk
Der Unterschied ist konkret. Die Tokenisierung umhüllt einen Vermögenswert, der danach in alten Datenbanken unter alten Prozessen weiterlebt. Die native Ausgabe schafft den Vermögenswert direkt on-chain – mit Compliance und Berechnungsregeln auf Protokoll-Ebene ab dem ersten Tag – ohne dass man das Token mit dem Original abgleichen muss.
Aber ich habe bereits geprüft, worauf sich dieses Versprechen für Dusk stützt: eine Partnerschaft mit NPEX, deren Antrag im Rahmen des EU DLT Pilot Regime bis heute als „designed for“, aber nicht „launched“ beschrieben wird. Die native Ausgabe erfordert nicht nur eine Architektur, sondern auch eine lizenzierte Plattform, die sie tatsächlich umsetzt – und diese Plattform wird noch vorbereitet.
Der architektonische Unterschied ist real, nicht ausgedacht – die Einbindung von Compliance in das Protokoll ist schwieriger, als einen Vermögenswert nur mit einem Etikett zu versehen. Die Entscheidung für „schwieriger“, während man auf die Einsatzbereitschaft wartet, ist eine konsequente Wahl.
$DUSK bleibt als Token des Netzwerks, in dem diese Architektur bereits technisch existiert.
Kann man die native Ausgabe heute schon als eine Möglichkeit von Dusk bezeichnen, wenn die einzige genannte regulierte Plattform dafür den Antrag noch vorbereitet?
@Dusk_Foundation #dusk