Eine Übertragung erfüllt nicht die Anforderungen. Sollte das System sie erkennen, bevor sie passiert, oder nachdem sie passiert ist? Das ist eine Einzelheit, die meine Aufmerksamkeit auf den Dusk gelenkt hat. Bei regulierten Assets kann eine Transaktion Bedingungen unterliegen, etwa hinsichtlich der Berechtigung, der Limits oder von Übertragungsbeschränkungen. Wenn diese Regeln in die Logik von Smart Contracts und in Workflows eingebaut sind, ist die Compliance nicht mehr nur ein nachträglicher Check. Sie kann dabei helfen, festzustellen, ob eine Transaktion überhaupt erst genehmigt werden darf.

Nehmen wir ein Asset, das nur an einen berechtigten Teilnehmer übertragen werden kann. Wenn die Berechtigung innerhalb des Workflows geprüft wird, kann eine nicht konforme Übertragung abgelehnt werden, statt abgeschlossen und anschließend mit den Folgen befasst zu werden. Das ist nur eine kleine Verschiebung im Timing, aber eine große Veränderung darin, wie das System funktioniert. Die Regel rückt näher an die Ausführung heran.

Das bedeutet nicht, dass jede Vorschrift in Code umgewandelt werden kann. Aber Bedingungen, die sich über Logik ausdrücken lassen, müssen nicht zwangsläufig darauf warten, dass sie im Backoffice angewendet werden. Genau das finde ich interessant an Dusk’s Ansatz für programmierbare Compliance. Daher geht es bei der Frage nicht nur darum: „Hat diese Transaktion die Regeln befolgt?“ Eine schärfere Frage lautet: „Wenn sie die Regeln nicht befolgt, warum dann trotzdem durchlaufen lassen?“

@Dusk_Foundation $DUSK #dusk $TUT $EDEN