Ich habe RWA früher gesehen und als Erstes immer gefragt: Wann wird es ausgegeben? Kann man es handeln? Als ich kürzlich den Asset-Flow für die Aufteilung von @Dusk weiter verfolge, ist mir erst aufgefallen, dass ich die viel schwierigere Hälfte übersehen habe: Die Emission ist nur der erste Tag—was passiert am zweiten Tag und danach?
Angenommen, ein Unternehmen emittiert Wertpapiere nativ auf eine Kette. Nach einem Jahr müssen Dividenden ausgeschüttet, außerdem stimmen die Aktionäre ab. Gleichzeitig kann ein bestimmtes Konto aufgrund von Statusänderungen diese Wertpapiere nicht mehr weiter empfangen. Wenn all diese Dinge am Ende wieder über die Broker-Backend-Systeme, Excel und manuelle Neuprüfungen laufen müssen, dann ist „On-Chain“ im Grunde nur die einfachste Etappe erledigt. Tokens lassen sich übertragen—das beweist lediglich, dass das Asset digitalisiert wurde; ob die Regeln langfristig mit dem Asset zusammenlaufen und damit wirklich in den On-Chain-Markt gelangen, entscheidet sich daran.
Dusk stellt diese Art von Problemen in seinen Docs direkt in den regulated asset workflow: Beim Issuance werden eligibility- und lifecycle-rules definiert, bei der Übertragung werden Berechtigungen und Einschränkungen geprüft, und Unternehmensaktionen müssen Zustandsänderungen wie dividend, coupon, burn, split usw. verarbeiten; auch die Mainnet-Docs führen klar shareholder registries und On-Chain-Votings auf. Citadel muss lediglich nachweisen, ob diese Adresse die Bedingungen erfüllt—ohne die komplette Identitätsinfo offenlegen zu müssen. Der Zustand nach Ausführung der Asset-Regeln muss außerdem abschließend so ausgeglichen werden, dass er für alle Beteiligten als gemeinsames Ergebnis anerkannt wird.
Hier habe ich eine deutliche kognitive Umkehr. Früher dachte ich, die wichtigsten Daten von Security Tokens seien die Salden. Nach der Aufteilung habe ich erkannt: Der Saldo ist womöglich das Einfachste. Das wirklich Schwierige ist: Wem gehört dieser Saldo? Kann er ihn aktuell noch halten? Hat er für diese Abstimmung eine Berechtigung? Zählt diese nächste Ausschüttung für ihn? Wenn sich die Regeln ändern, kann er das Asset noch an eine andere Adresse übertragen?
Deshalb bewerte ich heute kein einzelnes Dusk-Modul isoliert als besonders fortschrittlich. Identität, Asset-Regeln, Statusänderungen und Abrechnung müssen durchgehend zusammenarbeiten—wenn eine Ebene aussetzt, springen die Regeln wieder zurück außerhalb der Kette.
Natürlich heißt „sich das in Docs entwerfen lässt“ nicht, dass es auch in ein paar Jahren noch stabil läuft. Komplexe Berechtigungen, Identitäts-Upgrades, regulatorische Änderungen und langfristige Mainnet-Stabilität müssen weiterhin überprüft werden. Wenn ich in Zukunft RWA ansehe, stelle ich eine Frage mehr: Kann dieses Wertpapier auch nach fünf Jahren noch normal On-Chain abstimmen, Zuteilungen erhalten, übertragen, Berechtigungen aktualisieren und am Ende abrechnen? Das ist ein weitaus besserer Test dafür, ob eine Kette eine echte Finanz-Infrastruktur ist, als nur zu prüfen, wie viele Tokens heute ausgegeben wurden.
#dusk $DUSK @Dusk
Angenommen, ein Unternehmen emittiert Wertpapiere nativ auf eine Kette. Nach einem Jahr müssen Dividenden ausgeschüttet, außerdem stimmen die Aktionäre ab. Gleichzeitig kann ein bestimmtes Konto aufgrund von Statusänderungen diese Wertpapiere nicht mehr weiter empfangen. Wenn all diese Dinge am Ende wieder über die Broker-Backend-Systeme, Excel und manuelle Neuprüfungen laufen müssen, dann ist „On-Chain“ im Grunde nur die einfachste Etappe erledigt. Tokens lassen sich übertragen—das beweist lediglich, dass das Asset digitalisiert wurde; ob die Regeln langfristig mit dem Asset zusammenlaufen und damit wirklich in den On-Chain-Markt gelangen, entscheidet sich daran.
Dusk stellt diese Art von Problemen in seinen Docs direkt in den regulated asset workflow: Beim Issuance werden eligibility- und lifecycle-rules definiert, bei der Übertragung werden Berechtigungen und Einschränkungen geprüft, und Unternehmensaktionen müssen Zustandsänderungen wie dividend, coupon, burn, split usw. verarbeiten; auch die Mainnet-Docs führen klar shareholder registries und On-Chain-Votings auf. Citadel muss lediglich nachweisen, ob diese Adresse die Bedingungen erfüllt—ohne die komplette Identitätsinfo offenlegen zu müssen. Der Zustand nach Ausführung der Asset-Regeln muss außerdem abschließend so ausgeglichen werden, dass er für alle Beteiligten als gemeinsames Ergebnis anerkannt wird.
Hier habe ich eine deutliche kognitive Umkehr. Früher dachte ich, die wichtigsten Daten von Security Tokens seien die Salden. Nach der Aufteilung habe ich erkannt: Der Saldo ist womöglich das Einfachste. Das wirklich Schwierige ist: Wem gehört dieser Saldo? Kann er ihn aktuell noch halten? Hat er für diese Abstimmung eine Berechtigung? Zählt diese nächste Ausschüttung für ihn? Wenn sich die Regeln ändern, kann er das Asset noch an eine andere Adresse übertragen?
Deshalb bewerte ich heute kein einzelnes Dusk-Modul isoliert als besonders fortschrittlich. Identität, Asset-Regeln, Statusänderungen und Abrechnung müssen durchgehend zusammenarbeiten—wenn eine Ebene aussetzt, springen die Regeln wieder zurück außerhalb der Kette.
Natürlich heißt „sich das in Docs entwerfen lässt“ nicht, dass es auch in ein paar Jahren noch stabil läuft. Komplexe Berechtigungen, Identitäts-Upgrades, regulatorische Änderungen und langfristige Mainnet-Stabilität müssen weiterhin überprüft werden. Wenn ich in Zukunft RWA ansehe, stelle ich eine Frage mehr: Kann dieses Wertpapier auch nach fünf Jahren noch normal On-Chain abstimmen, Zuteilungen erhalten, übertragen, Berechtigungen aktualisieren und am Ende abrechnen? Das ist ein weitaus besserer Test dafür, ob eine Kette eine echte Finanz-Infrastruktur ist, als nur zu prüfen, wie viele Tokens heute ausgegeben wurden.
#dusk $DUSK @Dusk
