Die meisten Unternehmenssoftware sieht zwar ziemlich hässlich aus, aber Firmen zahlen trotzdem Millionen, um sie am Laufen zu halten. Ich habe mich früher gefragt, warum überhaupt jemand so etwas kauft, bis ich gesehen habe, wie ein Compliance-Team ein Tool freigegeben hat, das die Mitarbeitenden hassen. Die Software war nie dafür gebaut, dass die Menschen, die die Buttons drücken, sie gern nutzen. Sie wurde gekauft, damit der Risikobeauftragte bei einer schiefgehenden Prüfung ein belastbares Protokoll vorweisen kann. Der echte Kunde war im Grunde nur die Person, die die rechtliche Haftung trägt.

Dieses Muster ist mir wieder begegnet, als ich mir Dusk angesehen habe. In der Krypto-Welt ist die Standardannahme, dass man für Retail-Trader oder Token-Emittenten baut. Aber wenn man sich den Settlement-Flow ansieht, braucht es für beide eigentlich diese Architektur gar nicht. Ein Investor möchte einfach schnelle Ausführung, und ein Emittent möchte vor allem Liquidität.

Die Entität, die wirklich Haut im Spiel hat, ist die regulierte Plattform. Ein lizenzierter Exchange-Betreiber gerät dabei in eine miserable Lage: Er kann die Orderbücher der Kunden nicht leaken, aber er kann Trades auch nicht abwickeln, ohne gegenüber einem Regulator Compliance nachzuweisen. Dusk bietet diesem Betreiber im Grunde eine automatisierte Möglichkeit, Transaktionen über Zero-Knowledge-Proofs zu verifizieren und dabei keine Handelsdaten offenzulegen.

Das löst zwar ein echtes Problem für die Plattform, verlagert aber die Vertrauensgrenze an eine heikle Stelle. Es setzt voraus, dass ein Exchange-Betreiber tatsächlich deterministische kryptografische Beweise gegenüber menschlichem rechtlichem Ermessen bevorzugt. Ich bin mir noch immer nicht sicher, ob die schwierigere Aufgabe darin besteht, Veranstaltern kryptografische Privatsphäre zu geben, oder ob es darum geht, einen Exchange-Risikobeauftragten dazu zu bewegen, Code zu vertrauen – statt den eigenen Anwälten –, wenn ein Sonderfall aus dem Ruder läuft.

#dusk $DUSK @Dusk $BTC