Viele Menschen haben ein festes Bild von Privacy-Chains: Privatsphäre heißt gleichbedeutend mit Anti-Regulierung, und sobald die Aufsicht ein Projekt im Visier hat, ist es mit der Compliance vorbei.
Die @Dusk Whitepaper ist in diesem Punkt allerdings das Überraschendste: Es weicht der Regulierung nicht aus, sondern macht die regulatorischen Anforderungen zu Designvorgaben – in das Transaktionsmodell integriert. Das Ganze ist schwarz auf weiß niedergeschrieben: sieben Punkte.
Im Whitepaper, Abschnitt Zedger: Jeder Nutzer kann nur ein Konto haben. Nur Whitelist-Nutzer dürfen handeln. Der Empfänger muss das Gutschreiben explizit genehmigen; bevor die Genehmigung erfolgt, bleibt der Betrag weiter beim Konto des Absenders verbucht. Jede Änderung des Kontostands seit Kontoerstellung muss protokolliert werden; dabei werden Transaktionssaldo, Abstimmungssaldo und Dividendensaldos getrennt erfasst.
Die von der Asset-Seite benannte Partei kann jederzeit aus jedem historischen Snapshot den Equity-Table (Kapital-/Beteiligungstabelle) erneut darstellen.
Mein Eindruck: Das ist nicht wirklich eine technische Dokumentation, sondern eher eine Checkliste für regulatorische Wertpapier-Compliance. Erst kommen die Regulierungsanforderungen, dann die Code-Umsetzung – und die Reihenfolge ist umgekehrt zu der von den meisten Public Chains.
Am spannendsten finde ich, dass in der SMST-Struktur jeder Knoten handelbares Guthaben, abstimmbares Guthaben und Dividendenguthaben getrennt speichert. Dahinter steckt im Grunde das Design für die Aktionärsrechte.
Das Token ist nicht nur ein Vermögenswert, sondern auch Träger von Stimmrechten und Dividendenrechten.
Auch die passenden Funktionen untermauern das: CREATE (Konto eröffnen), SEND (Überweisung initiieren), ACCEPT (Empfänger genehmigt), SETTLE (Abwicklung nach dem Genehmigungszeitpunkt), CLAIM (Rückholung, wenn der Empfänger ablehnt oder es abläuft) – plus VOTE (Abstimmen) und PUSH DIVIDEND, bei dem die Dividenden direkt vom Smart Contract zugeschoben werden.
Wichtig: Es ist „Push“ statt „Claim“. Sämtliche Compliance-Aktionen werden in den Smart-Contract-Flow eingebettet – nicht auf „gutem Menschenverstand“ bzw. „Regulierung durch Personen“, sondern auf Code.
Der Abschnitt zu den verwandten Arbeiten im Whitepaper macht außerdem selbst einen Quervergleich: Tezos fügt nur im Smart-Contract-Layer eine begrenzte Anonymitätsfunktion hinzu, Polymesh verlagert Teile von Privacy-Eigenschaften in Off-Chain-Bereiche.
Der On-Chain-Support für Privacy bei Findora ist ebenfalls nur begrenzt. Der Ansatz von Dusk ist, Whitelist, Genehmigungsprozess und die Aufzeichnung der Equity-Tabelle vollständig in die Protokollebene zu pressen und die On-Chain-Nachweisbarkeit über Zero-Knowledge-Proofs sicherzustellen – sodass man nur die Gültigkeit sieht, aber nicht die Details.
Ich denke, dieser Unterschied ist die eigentliche reale Eintrittsbarriere für den Compliance-Track – nicht die bloßen vier Worte „Privacy unterstützen“.
Natürlich hat meine Einschätzung eine Voraussetzung: Es gibt reale Emissionsfälle für tokenisierte Wertpapiere, und das Whitelist-Mechanismus-Setup setzt voraus, dass Emittenten bei der Durchführung mitziehen. Wenn On-Chain langfristig keine Calls für Asset-, Abstimmungs- und Dividendenfunktionen stattfinden, dann ist selbst ein noch so vollständiges Design letztlich ein Leerlauf. Maßgeblich ist die praktische Umsetzung am XSC-Standard: Wie sieht es bei echten emittierten Wertpapieren aus?
$DUSK #dusk
Die @Dusk Whitepaper ist in diesem Punkt allerdings das Überraschendste: Es weicht der Regulierung nicht aus, sondern macht die regulatorischen Anforderungen zu Designvorgaben – in das Transaktionsmodell integriert. Das Ganze ist schwarz auf weiß niedergeschrieben: sieben Punkte.
Im Whitepaper, Abschnitt Zedger: Jeder Nutzer kann nur ein Konto haben. Nur Whitelist-Nutzer dürfen handeln. Der Empfänger muss das Gutschreiben explizit genehmigen; bevor die Genehmigung erfolgt, bleibt der Betrag weiter beim Konto des Absenders verbucht. Jede Änderung des Kontostands seit Kontoerstellung muss protokolliert werden; dabei werden Transaktionssaldo, Abstimmungssaldo und Dividendensaldos getrennt erfasst.
Die von der Asset-Seite benannte Partei kann jederzeit aus jedem historischen Snapshot den Equity-Table (Kapital-/Beteiligungstabelle) erneut darstellen.
Mein Eindruck: Das ist nicht wirklich eine technische Dokumentation, sondern eher eine Checkliste für regulatorische Wertpapier-Compliance. Erst kommen die Regulierungsanforderungen, dann die Code-Umsetzung – und die Reihenfolge ist umgekehrt zu der von den meisten Public Chains.
Am spannendsten finde ich, dass in der SMST-Struktur jeder Knoten handelbares Guthaben, abstimmbares Guthaben und Dividendenguthaben getrennt speichert. Dahinter steckt im Grunde das Design für die Aktionärsrechte.
Das Token ist nicht nur ein Vermögenswert, sondern auch Träger von Stimmrechten und Dividendenrechten.
Auch die passenden Funktionen untermauern das: CREATE (Konto eröffnen), SEND (Überweisung initiieren), ACCEPT (Empfänger genehmigt), SETTLE (Abwicklung nach dem Genehmigungszeitpunkt), CLAIM (Rückholung, wenn der Empfänger ablehnt oder es abläuft) – plus VOTE (Abstimmen) und PUSH DIVIDEND, bei dem die Dividenden direkt vom Smart Contract zugeschoben werden.
Wichtig: Es ist „Push“ statt „Claim“. Sämtliche Compliance-Aktionen werden in den Smart-Contract-Flow eingebettet – nicht auf „gutem Menschenverstand“ bzw. „Regulierung durch Personen“, sondern auf Code.
Der Abschnitt zu den verwandten Arbeiten im Whitepaper macht außerdem selbst einen Quervergleich: Tezos fügt nur im Smart-Contract-Layer eine begrenzte Anonymitätsfunktion hinzu, Polymesh verlagert Teile von Privacy-Eigenschaften in Off-Chain-Bereiche.
Der On-Chain-Support für Privacy bei Findora ist ebenfalls nur begrenzt. Der Ansatz von Dusk ist, Whitelist, Genehmigungsprozess und die Aufzeichnung der Equity-Tabelle vollständig in die Protokollebene zu pressen und die On-Chain-Nachweisbarkeit über Zero-Knowledge-Proofs sicherzustellen – sodass man nur die Gültigkeit sieht, aber nicht die Details.
Ich denke, dieser Unterschied ist die eigentliche reale Eintrittsbarriere für den Compliance-Track – nicht die bloßen vier Worte „Privacy unterstützen“.
Natürlich hat meine Einschätzung eine Voraussetzung: Es gibt reale Emissionsfälle für tokenisierte Wertpapiere, und das Whitelist-Mechanismus-Setup setzt voraus, dass Emittenten bei der Durchführung mitziehen. Wenn On-Chain langfristig keine Calls für Asset-, Abstimmungs- und Dividendenfunktionen stattfinden, dann ist selbst ein noch so vollständiges Design letztlich ein Leerlauf. Maßgeblich ist die praktische Umsetzung am XSC-Standard: Wie sieht es bei echten emittierten Wertpapieren aus?
$DUSK #dusk