Die meisten Projekte auf dem Markt verfolgen den Weg „Token ausgeben und dann die Fahrkarten nachträglich ergänzen“: Erst die Token hochschnellen lassen, zuerst die Liquidität „ausgraben“, Compliance? Danach holt man sich einfach eine Kanzlei, die ein Gutachten abgibt – und damit ist es erledigt. Ganz ehrlich: Ich bin mir nicht sicher, ob dieses Modell unter den Augen der Aufsicht mehrere Bullenmärkte durchsteht.
Als ich jedoch die Zedger- und XSC-Standards mit der Nummer @Dusk auseinandernehme, wurde mir klar, dass es Teams gibt, die das Thema durchdacht haben. Sie kodieren Compliance-Logik wie die Verifikation qualifizierter Investoren, Übertragungsbeschränkungen und Dividenden-Abstimmungen direkt als harte Regeln in der Vertragsschicht. Bevor jede Transaktion abgerechnet wird, läuft zuerst eine Compliance-Prüfung – bestanden, wird ein On-Chain-Nachweis freigeschaltet; nicht bestanden, bleibt die Transaktion direkt an Ort und Stelle blockiert. Man wartet nicht darauf, dass Transaktionen on-chain gehen und sucht dann nach jemandem, der zur Verantwortung gezogen werden kann, sondern schließt nicht-konforme Handlungen bereits an der Quelle aus.
Dieser Ansatz der „vorverlagerten Prüfung“ ist in der grundlegenden Logik ähnlich wie das von Newton verwendete Transaktions-/Risikomanagement – nur setzt Dusk ihn auf einem noch sensibleren Gebiet ein: der Umsetzung regulatorischer Vorgaben.
Die Validierungsschicht basiert auf einer Implementierung im Speicher privater Konten, wodurch der Compliance-Closed-Loop entsteht. Theoretisch liegt das eine Ebene weiter als bei Projekten, die auf manuelle Offline-Prüfungen setzen. Die Zuverlässigkeit der Preisstellung von RedStone wurde bereits auf über 110 Ketten verifiziert, und bei diesem Teil mache ich mir nicht allzu große Sorgen.
Aber ich muss sagen: In den derzeit öffentlich verfügbaren Informationen gibt es einen Punkt, der mich nicht richtig ruhig schlafen lässt – die Unklarheit bezüglich der Berechtigung, Regeln zu ändern.
Selbst wenn der Smart Contract noch so elegant läuft: Wenn dahinter ein „Admin-Backdoor“ steckt, mit der man jederzeit Parameter und Regeln ändern kann, dann steht die Robustheit des Systems auf dem Prüfstand. Was passiert, wenn sich die Regulierungspolitik ändert? Wer löst Änderungen aus, wenn sich Steuervorschriften anpassen? Gibt es verbindliche Einschränkungen durch Time-Locks und Multi-Signature? Auf diese entscheidenden Fragen sehe ich derzeit keine eindeutigen Antworten.
Meine Einschätzung: Die Richtung stimmt, der Weg ist aber noch lang. Die Idee, regulatorische Regeln als On-Chain-Basisfähigkeit umzusetzen, halte ich langfristig für vielversprechend. Dusk muss jedoch noch durch Tests mit echten Größenordnungen beweisen: Ob ein Test mit einigen Millionen US-Dollar funktioniert, heißt nicht, dass auch ein Volumen von zig Milliarden stabil bleibt.
In der Folge werde ich besonders auf die Umsetzung von DuskTrade achten, das mit NPEX kooperiert. Erst wenn der gesamte Prozess durchgehend läuft – von der Order-Matching-Phase über Abwicklung und Clearing bis hin zur Compliance-Validierung – kann man wirklich sagen, dass dieser Weg praktikabel ist.
Was meint ihr: Ist „On-Chain-native Compliance“ die endgültige Lösung oder zu idealistisch? Diskutiert es gern im Kommentarbereich.
#dusk $DUSK @Dusk
Als ich jedoch die Zedger- und XSC-Standards mit der Nummer @Dusk auseinandernehme, wurde mir klar, dass es Teams gibt, die das Thema durchdacht haben. Sie kodieren Compliance-Logik wie die Verifikation qualifizierter Investoren, Übertragungsbeschränkungen und Dividenden-Abstimmungen direkt als harte Regeln in der Vertragsschicht. Bevor jede Transaktion abgerechnet wird, läuft zuerst eine Compliance-Prüfung – bestanden, wird ein On-Chain-Nachweis freigeschaltet; nicht bestanden, bleibt die Transaktion direkt an Ort und Stelle blockiert. Man wartet nicht darauf, dass Transaktionen on-chain gehen und sucht dann nach jemandem, der zur Verantwortung gezogen werden kann, sondern schließt nicht-konforme Handlungen bereits an der Quelle aus.
Dieser Ansatz der „vorverlagerten Prüfung“ ist in der grundlegenden Logik ähnlich wie das von Newton verwendete Transaktions-/Risikomanagement – nur setzt Dusk ihn auf einem noch sensibleren Gebiet ein: der Umsetzung regulatorischer Vorgaben.
Die Validierungsschicht basiert auf einer Implementierung im Speicher privater Konten, wodurch der Compliance-Closed-Loop entsteht. Theoretisch liegt das eine Ebene weiter als bei Projekten, die auf manuelle Offline-Prüfungen setzen. Die Zuverlässigkeit der Preisstellung von RedStone wurde bereits auf über 110 Ketten verifiziert, und bei diesem Teil mache ich mir nicht allzu große Sorgen.
Aber ich muss sagen: In den derzeit öffentlich verfügbaren Informationen gibt es einen Punkt, der mich nicht richtig ruhig schlafen lässt – die Unklarheit bezüglich der Berechtigung, Regeln zu ändern.
Selbst wenn der Smart Contract noch so elegant läuft: Wenn dahinter ein „Admin-Backdoor“ steckt, mit der man jederzeit Parameter und Regeln ändern kann, dann steht die Robustheit des Systems auf dem Prüfstand. Was passiert, wenn sich die Regulierungspolitik ändert? Wer löst Änderungen aus, wenn sich Steuervorschriften anpassen? Gibt es verbindliche Einschränkungen durch Time-Locks und Multi-Signature? Auf diese entscheidenden Fragen sehe ich derzeit keine eindeutigen Antworten.
Meine Einschätzung: Die Richtung stimmt, der Weg ist aber noch lang. Die Idee, regulatorische Regeln als On-Chain-Basisfähigkeit umzusetzen, halte ich langfristig für vielversprechend. Dusk muss jedoch noch durch Tests mit echten Größenordnungen beweisen: Ob ein Test mit einigen Millionen US-Dollar funktioniert, heißt nicht, dass auch ein Volumen von zig Milliarden stabil bleibt.
In der Folge werde ich besonders auf die Umsetzung von DuskTrade achten, das mit NPEX kooperiert. Erst wenn der gesamte Prozess durchgehend läuft – von der Order-Matching-Phase über Abwicklung und Clearing bis hin zur Compliance-Validierung – kann man wirklich sagen, dass dieser Weg praktikabel ist.
Was meint ihr: Ist „On-Chain-native Compliance“ die endgültige Lösung oder zu idealistisch? Diskutiert es gern im Kommentarbereich.
#dusk $DUSK @Dusk
