Als ich „Atomic Settlement“ sah, dachte ich, die eigentliche Schwierigkeit bei DvP bestehe darin, dass die Asset- und die Zahlungsleg zugleich ausfallen. Heute, nach dem erneuten Durchgehen der Markt-Infrastruktur-Dokumentation für @Dusk , bin ich bei einer noch schwierigeren Ebene stehen geblieben: Atomizität und Determinismus können zwar ein „halb erledigtes“ Geschäft verhindern, aber sie sagen Institutionen nicht, was zu tun ist, wenn ein Scheitern endgültig eingetreten ist.
Das offizielle Framework von Dusk versucht, Zutrittsentscheidungen, Adresszuordnung, eingeschränkt übertragbare Transfers, Zahlungsabstimmung und die finale Abwicklung in einen einzigen Markt-Workflow zu integrieren; DuskDS liefert nach der ratification in der Chain eine deterministische Endgültigkeit. Diese Kombination kann die teuerste Art von Problem in der klassischen Wertpapierabwicklung verändern – die beteiligten Parteien müssen nicht immer wieder über mehrere Ledger hinweg verifizieren, ob „das Asset wirklich gegeben wurde“ und ob „das Geld wirklich angekommen ist“.
Doch sobald man die Szene in eine Anleihe-Subscription verlagert, tauchen sofort Ausnahmen auf. Anleger durchlaufen zunächst einen Berechtigungscheck, wobei Cash reserviert wird und Anteile auf die Lieferung warten; bei der Einreichung kann es jedoch passieren, dass die Berechtigung abläuft, das Guthaben nicht ausreicht, die Signaturparteien offline sind, das Custody-Interface-Timeout überschreitet oder der externe Zahlungsstatus nicht synchronisiert ist. Wenn beide „Beine“ tatsächlich von denselben atomaren Bedingungen gesteuert werden, ist das beste Ergebnis, dass Erfolg oder Misserfolg gemeinsam eintreten. Aber „gemeinsam scheitern“ ist nur das On-Chain-Ergebnis – nicht der komplette Business-Closed-Loop.
Genau an dieser Stelle sehe ich den Mehrwert der Dusk-Richtung, aber die Belege reichen mir noch nicht. Die Endgültigkeit von DuskDS macht die Fehlergrenzen klarer: In einem finalen Block ist Erfolg oder Fehler nicht länger schwebend, und ein Ausführungsfehler hat ein nachprüfbares Ergebnis. Doch auf der Dusk-Trade-Website ist es am selben Tag weiterhin als „Building“ markiert und es gibt ein Waitlist-Setup; öffentlich verfügbare Unterlagen liefern keine Produktionsdaten zur DvP-Finalisierungsrate, zur Verteilung von Ausnahmen oder zu Eingriffen durch Menschen.
Auch die Risiken sind sehr konkret. Erstens: Wenn es an ausgereiften Autorisierungs- und Audit-Tools fehlt, könnte die Untersuchung von Ausnahmen sogar langsamer werden – besonders bei Privatsphäre und selektiver Offenlegung. Zweitens: Wenn das Asset-Leg und das Zahlungs-Leg über unterschiedliche Systeme laufen, wird die Grenze der Atomizität kleiner; dann rückt die manuelle Kompensation wieder in den Prozess hinein. Technische Endgültigkeit kann zwar nicht scheitern, aber Business-Zusagen werden möglicherweise trotzdem nicht eingelöst.
Was meinst du: Sollte eine Institution bei der Abnahme von DvP zuerst auf die Geschwindigkeit des A-normativen Pfads schauen, auf B – automatische Wiederherstellung bei Ausnahmen – oder auf C – Abgleich über Systeme hinweg? #dusk $DUSK
Das offizielle Framework von Dusk versucht, Zutrittsentscheidungen, Adresszuordnung, eingeschränkt übertragbare Transfers, Zahlungsabstimmung und die finale Abwicklung in einen einzigen Markt-Workflow zu integrieren; DuskDS liefert nach der ratification in der Chain eine deterministische Endgültigkeit. Diese Kombination kann die teuerste Art von Problem in der klassischen Wertpapierabwicklung verändern – die beteiligten Parteien müssen nicht immer wieder über mehrere Ledger hinweg verifizieren, ob „das Asset wirklich gegeben wurde“ und ob „das Geld wirklich angekommen ist“.
Doch sobald man die Szene in eine Anleihe-Subscription verlagert, tauchen sofort Ausnahmen auf. Anleger durchlaufen zunächst einen Berechtigungscheck, wobei Cash reserviert wird und Anteile auf die Lieferung warten; bei der Einreichung kann es jedoch passieren, dass die Berechtigung abläuft, das Guthaben nicht ausreicht, die Signaturparteien offline sind, das Custody-Interface-Timeout überschreitet oder der externe Zahlungsstatus nicht synchronisiert ist. Wenn beide „Beine“ tatsächlich von denselben atomaren Bedingungen gesteuert werden, ist das beste Ergebnis, dass Erfolg oder Misserfolg gemeinsam eintreten. Aber „gemeinsam scheitern“ ist nur das On-Chain-Ergebnis – nicht der komplette Business-Closed-Loop.
Genau an dieser Stelle sehe ich den Mehrwert der Dusk-Richtung, aber die Belege reichen mir noch nicht. Die Endgültigkeit von DuskDS macht die Fehlergrenzen klarer: In einem finalen Block ist Erfolg oder Fehler nicht länger schwebend, und ein Ausführungsfehler hat ein nachprüfbares Ergebnis. Doch auf der Dusk-Trade-Website ist es am selben Tag weiterhin als „Building“ markiert und es gibt ein Waitlist-Setup; öffentlich verfügbare Unterlagen liefern keine Produktionsdaten zur DvP-Finalisierungsrate, zur Verteilung von Ausnahmen oder zu Eingriffen durch Menschen.
Auch die Risiken sind sehr konkret. Erstens: Wenn es an ausgereiften Autorisierungs- und Audit-Tools fehlt, könnte die Untersuchung von Ausnahmen sogar langsamer werden – besonders bei Privatsphäre und selektiver Offenlegung. Zweitens: Wenn das Asset-Leg und das Zahlungs-Leg über unterschiedliche Systeme laufen, wird die Grenze der Atomizität kleiner; dann rückt die manuelle Kompensation wieder in den Prozess hinein. Technische Endgültigkeit kann zwar nicht scheitern, aber Business-Zusagen werden möglicherweise trotzdem nicht eingelöst.
Was meinst du: Sollte eine Institution bei der Abnahme von DvP zuerst auf die Geschwindigkeit des A-normativen Pfads schauen, auf B – automatische Wiederherstellung bei Ausnahmen – oder auf C – Abgleich über Systeme hinweg? #dusk $DUSK
