#dusk $DUSK @Dusk Letzte Nacht habe ich nachgesehen, nach welchem Mechanismus eine von Dusk ausgegebene Wertpapier-Emission tatsächlich zur Compliance gezwungen wird. Eigentlich dachte ich, das dürfte Off-Chain passieren – also vermutlich würde irgendein Registrierungs-/Zulassungssystem vor einer Überweisung erst die Berechtigung prüfen, so läuft es bei den meisten Plattformen für tokenisierte Vermögenswerte. Ergebnis: Die Regeln liegen gar nicht Off-Chain.
XSC, also der geheime Wertpapier-Vertragsstandard von Dusk, erlaubt es dem Emittenten, Compliance-Bedingungen direkt in den Token selbst einzubetten – ein Wertpapier kann so programmiert werden, dass es nur zwischen qualifizierten, in der Whitelist geführten Inhabern übertragen werden kann. Diese Prüfung läuft auf Protokollebene ab, nicht indem man im Nachhinein noch einen zusätzlichen Genehmigungsprozess drüberlegt. Die Einschränkung folgt dem Vermögenswert – nicht indem irgendwo anders in einer Datenbank verfolgt wird, wer überhaupt berechtigt ist, ihn zu halten.
Das ist nicht der Ausfallmodus, den ich erwartet hatte. Die meisten „Compliance“-Tokenisierungsansätze, die ich gelesen habe, haben nämlich eine Lücke: Der Token wird on-chain transferiert, aber die eigentliche Berechtigungsprüfung passiert in einem Off-Chain-System, das on-chain gar nicht verifizierbar ist. Wenn dieses System ausfällt, wenn Daten veralten oder wenn es schlicht nicht abgefragt wird, kann on-chain nichts mehr verhindern, dass die Übertragung trotzdem durchrutscht.
In den Design-Details ist eine Sache besonders auffällig: Dieser Standard muss auch den Fall von verlorenen privaten Schlüsseln behandeln, und zwar so, dass dabei keine gesetzlichen Pflichten des Emittenten verletzt werden. Wenn ein Aktionär den Zugriff verliert, schreibt das Wertpapierrecht trotzdem vor, dass er nicht dadurch automatisch sein gesamtes Eigentum verliert. XSC muss dem Emittenten ausreichend Kontrolle geben, um genau das umzusetzen – aber diese Kontrolle darf wiederum kein Hintertürchen werden und damit die Grundannahme „on-chain erzwungene Durchsetzung“ selbst untergraben.
Das erinnert mich an ein Gebäude: Der Aufzug lässt sich nicht einfach durch einen vielleicht gerade abwesenden Sicherheitsdienst unten öffnen, sondern die Karte wird erst direkt am Aufzugseinlass geprüft.
Man muss allerdings klar sagen: Was ich gelesen habe, sind die behaupteten Designziele dieses Standards. Ich habe nicht aus eigener Sicht gesehen, wie ein echter Aktionärsdatensatz im Grenzfall an die Realität stößt – wie es sich bei echtem Schlüsselverlust oder bei Änderungen der Gerichtsbarkeit in tatsächlich regulierten Vermögenswerten konkret verhält, habe ich keine realen Fälle gesehen.
Ich denke auch noch darüber nach: Wird die Berechtigungsprüfung auf Token-Ebene wirklich die Compliance-Lücke schließen – oder wird das Problem nur dorthin verschoben, „wer“ die in den Token eingebettete Regel aktualisieren darf, und „wie schnell“ diese Aktualisierung möglich ist?
@Dusk $DUSK #dusk #BinanceSquareFamily
XSC, also der geheime Wertpapier-Vertragsstandard von Dusk, erlaubt es dem Emittenten, Compliance-Bedingungen direkt in den Token selbst einzubetten – ein Wertpapier kann so programmiert werden, dass es nur zwischen qualifizierten, in der Whitelist geführten Inhabern übertragen werden kann. Diese Prüfung läuft auf Protokollebene ab, nicht indem man im Nachhinein noch einen zusätzlichen Genehmigungsprozess drüberlegt. Die Einschränkung folgt dem Vermögenswert – nicht indem irgendwo anders in einer Datenbank verfolgt wird, wer überhaupt berechtigt ist, ihn zu halten.
Das ist nicht der Ausfallmodus, den ich erwartet hatte. Die meisten „Compliance“-Tokenisierungsansätze, die ich gelesen habe, haben nämlich eine Lücke: Der Token wird on-chain transferiert, aber die eigentliche Berechtigungsprüfung passiert in einem Off-Chain-System, das on-chain gar nicht verifizierbar ist. Wenn dieses System ausfällt, wenn Daten veralten oder wenn es schlicht nicht abgefragt wird, kann on-chain nichts mehr verhindern, dass die Übertragung trotzdem durchrutscht.
In den Design-Details ist eine Sache besonders auffällig: Dieser Standard muss auch den Fall von verlorenen privaten Schlüsseln behandeln, und zwar so, dass dabei keine gesetzlichen Pflichten des Emittenten verletzt werden. Wenn ein Aktionär den Zugriff verliert, schreibt das Wertpapierrecht trotzdem vor, dass er nicht dadurch automatisch sein gesamtes Eigentum verliert. XSC muss dem Emittenten ausreichend Kontrolle geben, um genau das umzusetzen – aber diese Kontrolle darf wiederum kein Hintertürchen werden und damit die Grundannahme „on-chain erzwungene Durchsetzung“ selbst untergraben.
Das erinnert mich an ein Gebäude: Der Aufzug lässt sich nicht einfach durch einen vielleicht gerade abwesenden Sicherheitsdienst unten öffnen, sondern die Karte wird erst direkt am Aufzugseinlass geprüft.
Man muss allerdings klar sagen: Was ich gelesen habe, sind die behaupteten Designziele dieses Standards. Ich habe nicht aus eigener Sicht gesehen, wie ein echter Aktionärsdatensatz im Grenzfall an die Realität stößt – wie es sich bei echtem Schlüsselverlust oder bei Änderungen der Gerichtsbarkeit in tatsächlich regulierten Vermögenswerten konkret verhält, habe ich keine realen Fälle gesehen.
Ich denke auch noch darüber nach: Wird die Berechtigungsprüfung auf Token-Ebene wirklich die Compliance-Lücke schließen – oder wird das Problem nur dorthin verschoben, „wer“ die in den Token eingebettete Regel aktualisieren darf, und „wie schnell“ diese Aktualisierung möglich ist?
@Dusk $DUSK #dusk #BinanceSquareFamily
