Auf Dusk ist mir nicht so sehr wichtig, ob ich "illegale Transaktionen stoppen kann", sondern ob das System nach dem Stoppen klar kommunizieren kann, was passiert ist. Denn die Realität regulierter Vermögenswerte ist: Die Ablehnung einer Transaktion ist selbst ein Ereignis, und man muss in der Lage sein zu antworten: "Welche Regel hat hier gegriffen?"
@dusk_foundation Der harte Punkt dieses Pfades liegt darin: Die Ablehnung erfolgt nicht durch Frontend-Hinweise und auch nicht durch manuelle Rückmeldungen des Betriebs, sondern geschieht vor der Statusänderung. Das bedeutet, wenn diese Transaktion den Status von A nach B ändern möchte, überprüft das System zunächst, ob dieser Schritt die Regelkombination erfüllt; solange dies nicht der Fall ist, bleibt der Status unverändert und die Transaktion wird nicht wirksam.
Aber noch schwieriger ist es, "erklärbar" zu sein. Wenn die Ablehnung nur einen Fehlercode übrig lässt, wird die Compliance-Prüfung, die Benutzerbeschwerde und sogar das Debugging für Entwickler zusammenbrechen. Damit Dusk funktioniert, muss die Ablehnung kategorisiert werden können: Ist es, dass der Status des Vermögenswerts nicht erlaubt ist (gesperrt/pausiert/eingeschränkt), sind die Kontobedingungen nicht erfüllt (Berechtigung/Obergrenze/Einschränkungen), oder gibt es Konflikte in der Regelkombination selbst? Nur wenn kategorisiert werden kann, gibt es eine nachfolgende Bearbeitung: Regeln anpassen, Konto wechseln, warten oder direkt verbieten.
Deshalb beobachte ich den Fortschritt von Dusk mit einem klaren Fokus: Wenn eine Transaktion abgelehnt wird, was gibt das System dann tatsächlich an, ist es eine "verwirrende Fehlermeldung" oder eine "Ablehnung, die auf die Regel zutrifft"? Erstere ist eine Konzeptkette, letztere ähnelt einem regulierten Transaktionssystem.