Wenn jemand mit den technischen Dokumenten von Dusk zu einem Anwalt geht und fragt, ob diese Vermögenswerte bereits konform sind, nicken ich ihm nicht einfach zu. Als ich die Seite „Assets & Regulations“ für @Dusk aufgeschlagen habe, dachte ich zunächst, dass „Not legal advice“ nur ein üblicher Disclaimer sei. Doch beim Lesen habe ich erkannt, dass damit eine klare Haftungslinie gezogen wird: $DUSK kann Identitätsnachweise, Wallet-Bindungen, Übertragungsbeschränkungen und Offenlegungslogik als ausführbare Komponenten umsetzen – aber es ersetzt nicht die Pflicht des Emittenten, Vermögenskategorien zu klassifizieren, Erlaubnisanträge zu stellen und die Zuständigkeit je Rechtsraum zu beurteilen. Für RWA-Organisationen ist das sehr real: Ingenieure kümmern sich darum, wer halten darf, wer empfangen kann und an welcher Stelle die Genehmigung scheitert. Das Juristenteam soll hingegen beantworten, was für ein Vermögenswert das ist, wer ihn emittiert, wer ihn verkauft und wer für die Erbringung der Dienstleistung verantwortlich ist. Sobald diese beiden Fragen wie eine einzige Tabelle behandelt werden, entsteht für ein Projekt die peinliche Situation: „On-chain passiert, aber der Markt kann es nicht verkaufen“.
Stell dir vor, eine Organisation deployt erst einmal Zugangs- und Übertragungsregeln und nimmt dann „on-chain ausgeführt“ als Go-Live-Kriterium. Wenn später Emissionsdokumente oder Verkaufsberechtigungen erneut geprüft werden und daraufhin gestoppt werden muss, dann ist das nicht nur irgendeine Funktion – sondern die gesamte Emission und der Handel der Assets. Entwickler gehen davon aus, die Arbeit sei erledigt, doch der Emittent muss am Ende Verzögerungen, erneute Prüfungen und die erneute Abstimmung bezahlen. Deshalb werde ich „programmable compliance“ von @Dusk nicht als regulatorisches Siegel formulieren. Seine Anziehungskraft liegt darin, einen Teil regulatorischer Anforderungen in ausführbare und überprüfbare Infrastruktur zu übersetzen – aber es kann nicht die Unterschrift für die rechtliche Verantwortlichkeit ersetzen. Als Nächstes werde ich mir ansehen, ob bei jedem Asset-Workflow die Verantwortlichkeit öffentlich angegeben ist, welcher Rechtsraum gilt und wie die Zuordnung zu den technischen Regeln aussieht – denn dann ist es das, worüber $DUSK wirklich diskutiert: ob sich reale Finanzanforderungen und On-chain-Regeln überhaupt decken. #dusk
Stell dir vor, eine Organisation deployt erst einmal Zugangs- und Übertragungsregeln und nimmt dann „on-chain ausgeführt“ als Go-Live-Kriterium. Wenn später Emissionsdokumente oder Verkaufsberechtigungen erneut geprüft werden und daraufhin gestoppt werden muss, dann ist das nicht nur irgendeine Funktion – sondern die gesamte Emission und der Handel der Assets. Entwickler gehen davon aus, die Arbeit sei erledigt, doch der Emittent muss am Ende Verzögerungen, erneute Prüfungen und die erneute Abstimmung bezahlen. Deshalb werde ich „programmable compliance“ von @Dusk nicht als regulatorisches Siegel formulieren. Seine Anziehungskraft liegt darin, einen Teil regulatorischer Anforderungen in ausführbare und überprüfbare Infrastruktur zu übersetzen – aber es kann nicht die Unterschrift für die rechtliche Verantwortlichkeit ersetzen. Als Nächstes werde ich mir ansehen, ob bei jedem Asset-Workflow die Verantwortlichkeit öffentlich angegeben ist, welcher Rechtsraum gilt und wie die Zuordnung zu den technischen Regeln aussieht – denn dann ist es das, worüber $DUSK wirklich diskutiert: ob sich reale Finanzanforderungen und On-chain-Regeln überhaupt decken. #dusk
