#dusk $DUSK @Dusk
Ich habe in Dusk-Dokumenten herumgestöbert, um zu verstehen, was „Privacy by default, Auditability when required“ auf Protokollebene tatsächlich bedeutet, weil dieser Satz überall in ihren RWA-Materialien auftaucht und ich wissen wollte, wer das Audit durchführt.
Erstellt: Der XSC-Standard sieht optionale Viewing-Keys vor, die an die Compliance-Schicht gekoppelt sind – sodass, wenn ein Security Token über XSC ausgegeben wird, der Emittent (oder ein bezeichneter Regulator) einen Schlüssel halten kann, der Transaktionsdetails entschlüsselt, die vor allen anderen auf der On-Chain-Seite verborgen bleiben. Ich bin zweimal zurück in die Doku gegangen, weil ich es zunächst als vollständige Ende-zu-Ende-Privatsphäre verstanden hatte, so wie man sie bei einer typischen „shielded transaction“ bekommt. So ist es nicht. Es ist Privatsphäre gegenüber der Öffentlichkeit, nicht notwendigerweise gegenüber dem Gegenüber, das die Compliance-Regeln ausführt.
Das ist kein Fehler, sondern der eigentliche Zweck – ohne dass jemand auf Abruf nachweisen kann, dass er Eigentümer ist und wie die Gelder fließen, bekommt man keinen MiFID- oder MiCA-konformen Security Token. Aber das bedeutet, dass die Datenschutzgarantie asymmetrisch ist, und ich glaube, das ist für jemanden nicht offensichtlich, der „confidential“ auf der Startseite liest und von einer symmetrischen Anonymität wie bei einer Privacy Coin ausgeht.
Die dadurch entstehende Anreizstruktur ist interessant: Emittenten fühlen sich wohl dabei, echte Wertpapiere auf einer öffentlichen Kette zu platzieren – genau deshalb, weil sie weiterhin Sichtbarkeit behalten. Nutzer erhalten Privatsphäre gegenüber Fremden, nicht gegenüber dem System, das sie verwaltet. Es lohnt sich zu fragen, wie viele Inhaber tatsächlich wissen, wer diesen Schlüssel für ein bestimmtes Asset hält.
Ich habe in Dusk-Dokumenten herumgestöbert, um zu verstehen, was „Privacy by default, Auditability when required“ auf Protokollebene tatsächlich bedeutet, weil dieser Satz überall in ihren RWA-Materialien auftaucht und ich wissen wollte, wer das Audit durchführt.
Erstellt: Der XSC-Standard sieht optionale Viewing-Keys vor, die an die Compliance-Schicht gekoppelt sind – sodass, wenn ein Security Token über XSC ausgegeben wird, der Emittent (oder ein bezeichneter Regulator) einen Schlüssel halten kann, der Transaktionsdetails entschlüsselt, die vor allen anderen auf der On-Chain-Seite verborgen bleiben. Ich bin zweimal zurück in die Doku gegangen, weil ich es zunächst als vollständige Ende-zu-Ende-Privatsphäre verstanden hatte, so wie man sie bei einer typischen „shielded transaction“ bekommt. So ist es nicht. Es ist Privatsphäre gegenüber der Öffentlichkeit, nicht notwendigerweise gegenüber dem Gegenüber, das die Compliance-Regeln ausführt.
Das ist kein Fehler, sondern der eigentliche Zweck – ohne dass jemand auf Abruf nachweisen kann, dass er Eigentümer ist und wie die Gelder fließen, bekommt man keinen MiFID- oder MiCA-konformen Security Token. Aber das bedeutet, dass die Datenschutzgarantie asymmetrisch ist, und ich glaube, das ist für jemanden nicht offensichtlich, der „confidential“ auf der Startseite liest und von einer symmetrischen Anonymität wie bei einer Privacy Coin ausgeht.
Die dadurch entstehende Anreizstruktur ist interessant: Emittenten fühlen sich wohl dabei, echte Wertpapiere auf einer öffentlichen Kette zu platzieren – genau deshalb, weil sie weiterhin Sichtbarkeit behalten. Nutzer erhalten Privatsphäre gegenüber Fremden, nicht gegenüber dem System, das sie verwaltet. Es lohnt sich zu fragen, wie viele Inhaber tatsächlich wissen, wer diesen Schlüssel für ein bestimmtes Asset hält.
