Ich dachte ursprünglich, dass mit der Prägung eines Private-Equity-Wertpapiers als Token die Verbriefung von Vermögenswerten auf der Blockchain bereits abgeschlossen sei. Nachdem ich den gestern von @Dusk aktualisierten Artikel über den Privatmarkt gelesen und ihn mit der Native-Issuance-Dokumentation abgeglichen hatte, wurde ich jedoch bei einem Punkt eher noch vorsichtiger: Wenn rechtliches Eigentum, Verwahrung, Corporate Actions und Abwicklung weiterhin von einem anderen System bestimmt werden, ist dieser Token vielleicht kein Effizienzwerkzeug, sondern eine weitere Reihe von Datensätzen, die erst noch abgeglichen werden müssen.
Tokenisierung erstellt normalerweise einen Token, der einen Vermögenswert oder einen Rechtsanspruch repräsentiert; dadurch kann er leichter programmiert, verteilt und in Anwendungen eingebunden werden, während der zugrunde liegende Vermögenswert weiterhin in Off-Chain-Registrierungs-, Verwahrungs- oder Abwicklungssystemen verbleiben kann. Die Anforderungen an Native Issuance sind höher: Der Vermögenswert selbst wird rund um das On-Chain-Ledger erstellt und verwaltet, und Emission, Übertragung, Betreuung und Abwicklung nutzen möglichst denselben Eigentumsstatus.
Der eigentliche Test ist, ob eine Private-Placement-Emission sechsmal wieder eingetippt werden muss. Im traditionellen Prozess bearbeiten Emittent, Berater, Administrator, Bank, Verwahrer und Handelsplatz jeweils Strukturgenehmigung, Anlegerzulassung, Zeichnungszuweisung, Aktionärsregister, Zahlung, Übertragung und Nachbetreuung. Alle Parteien führen eine ähnliche, aber nicht ganz identische Aufzeichnung; Fehler entstehen oft an den Übergaben und bei der nachträglichen Bestätigung.
Wenn man diesem alten Prozess nur einen Token hinzufügt, muss der On-Chain-Saldo weiterhin mit dem maßgeblichen Off-Chain-Register abgeglichen werden. Die Übertragung wird zwar on-chain abgeschlossen, muss aber auf die Aktualisierung der Registrierung warten; Dividenden werden anhand der Off-Chain-Liste berechnet und anschließend wieder auf die On-Chain-Inhaber bezogen; und falls ein Streit entsteht, ist unklar, welcher Datensatz Vorrang hat. Technisch wirkt es schneller, operativ entsteht jedoch eine weitere Bruchstelle.
Echte native Emission verändert den Prozess und die Vertrauensgrenzen: Die Anlegerberechtigung kann vor der Zeichnung oder Übertragung geprüft werden, Zuteilung und Eigentumsaktualisierung erfolgen um denselben kontrollierten Status herum, Übertragungsbeschränkungen greifen direkt auf den aktuellen Inhaberdatensatz, Vermögens- und Zahlungsseite werden über denselben Abwicklungsprozess koordiniert, und auch Kuponzahlungen, Abstimmungen, Dividenden und Rücknahmen lesen eine fortlaufende Eigentumshistorie. Die selektive Offenlegung und Zugriffskontrolle von Dusk beantworten die Frage „Wer darf sehen, wer darf handeln?“, während die deterministische Abwicklung von DuskDS die Frage beantwortet „Welcher Status ist bereits endgültig festgelegt?“.
Das ist wichtiger als „Tokens günstiger auszugeben“, weil damit versucht wird, die wiederholte Abstimmung zwischen Emission, Registrierung, Verwahrung, Handel und Service zu reduzieren, statt nur die äußere Form eines Vermögenswerts in ein On-Chain-Symbol zu verwandeln.
Was ist Ihrer Meinung nach bei nativer Emission am schwierigsten zu verbinden?$DUSK #dusk
Tokenisierung erstellt normalerweise einen Token, der einen Vermögenswert oder einen Rechtsanspruch repräsentiert; dadurch kann er leichter programmiert, verteilt und in Anwendungen eingebunden werden, während der zugrunde liegende Vermögenswert weiterhin in Off-Chain-Registrierungs-, Verwahrungs- oder Abwicklungssystemen verbleiben kann. Die Anforderungen an Native Issuance sind höher: Der Vermögenswert selbst wird rund um das On-Chain-Ledger erstellt und verwaltet, und Emission, Übertragung, Betreuung und Abwicklung nutzen möglichst denselben Eigentumsstatus.
Der eigentliche Test ist, ob eine Private-Placement-Emission sechsmal wieder eingetippt werden muss. Im traditionellen Prozess bearbeiten Emittent, Berater, Administrator, Bank, Verwahrer und Handelsplatz jeweils Strukturgenehmigung, Anlegerzulassung, Zeichnungszuweisung, Aktionärsregister, Zahlung, Übertragung und Nachbetreuung. Alle Parteien führen eine ähnliche, aber nicht ganz identische Aufzeichnung; Fehler entstehen oft an den Übergaben und bei der nachträglichen Bestätigung.
Wenn man diesem alten Prozess nur einen Token hinzufügt, muss der On-Chain-Saldo weiterhin mit dem maßgeblichen Off-Chain-Register abgeglichen werden. Die Übertragung wird zwar on-chain abgeschlossen, muss aber auf die Aktualisierung der Registrierung warten; Dividenden werden anhand der Off-Chain-Liste berechnet und anschließend wieder auf die On-Chain-Inhaber bezogen; und falls ein Streit entsteht, ist unklar, welcher Datensatz Vorrang hat. Technisch wirkt es schneller, operativ entsteht jedoch eine weitere Bruchstelle.
Echte native Emission verändert den Prozess und die Vertrauensgrenzen: Die Anlegerberechtigung kann vor der Zeichnung oder Übertragung geprüft werden, Zuteilung und Eigentumsaktualisierung erfolgen um denselben kontrollierten Status herum, Übertragungsbeschränkungen greifen direkt auf den aktuellen Inhaberdatensatz, Vermögens- und Zahlungsseite werden über denselben Abwicklungsprozess koordiniert, und auch Kuponzahlungen, Abstimmungen, Dividenden und Rücknahmen lesen eine fortlaufende Eigentumshistorie. Die selektive Offenlegung und Zugriffskontrolle von Dusk beantworten die Frage „Wer darf sehen, wer darf handeln?“, während die deterministische Abwicklung von DuskDS die Frage beantwortet „Welcher Status ist bereits endgültig festgelegt?“.
Das ist wichtiger als „Tokens günstiger auszugeben“, weil damit versucht wird, die wiederholte Abstimmung zwischen Emission, Registrierung, Verwahrung, Handel und Service zu reduzieren, statt nur die äußere Form eines Vermögenswerts in ein On-Chain-Symbol zu verwandeln.
Was ist Ihrer Meinung nach bei nativer Emission am schwierigsten zu verbinden?$DUSK #dusk
