Ich habe Dusk neu untersucht und dachte zuerst, ich sähe nur eine datenschutzorientierte L1, die um EVM-Kompatibilität erweitert wurde.

Doch mir wurde klar: Die eigentliche Veränderung betrifft die Architektur.

Dusk trennt die Ausführung von Anwendungen und die Finanzabwicklung nach und nach voneinander.

Heute steht DuskDS als zugrunde liegende Abwicklungs- und Data-Availability-Schicht bereit, während DuskEVM eine EVM-äquivalente Umgebung auf Basis von OP Stack bietet, in die Solidity und gängige Ethereum-Tools zu Dusk kommen können. Gleichzeitig behält DuskVM den ursprünglichen nativen Rust/WASM-Pfad bei und unterstützt Anwendungen, die direkt auf L1 zugreifen oder Datenschutz- bzw. ZK-Fähigkeiten benötigen.

Das hat mein Verständnis davon verändert, wie Dusk ursprünglich positioniert war.

Früher bestand die zentrale Erzählung vor allem aus: Datenschutz + Compliance + Finanzanlagen.

Heute geht die Ausrichtung deutlich eher dahin, regulatorisch-konforme Finanzinfrastruktur mit dem bestehenden Entwickler-Ökosystem kompatibel zu machen.

Das ist wichtig, denn Einrichtungen brauchen nicht nur Datenschutztechnologie.

Sie benötigen außerdem, dass Wallets, Entwicklerwerkzeuge, Liquidität, Anwendungen, Abwicklung und Interoperabilität gemeinsam funktionieren.

Dusk richtet DuskEVM nun klar auf tokenisierte Assets und DeFi aus, während Hedger datenschutzbezogene Funktionen in die EVM-Umgebung bringt. Gleichzeitig behält DuskDS auf der Basisschicht weiterhin das Transaktionsmodell von Phoenix und Moonlight bei.

Aber hier gibt es auch eine Realität, der man sich stellen muss.

Am 16. Januar 2026 kam es bei Dusk zu einem Sicherheitsvorfall: Eine Brücken-Signature-Wallet wurde kompromittiert.

Dusk erklärte, dass dies kein Scheitern der Konsensschicht oder des Kernprotokolls ist. Danach wurde die Bridge-Architektur neu entworfen – unter anderem mit Signatur-Isolation, Isolation der Ereignisverarbeitung, strengeren Sicherheitsgrenzen und einer Reduzierung der Offenlegung von Hot-Wallets.

Anschließend identifizierte und behandelte AEGIS weitere 39 Sicherheitsprobleme, darunter sieben schwerwiegende Fälle im Zusammenhang mit VM, Serialisierung, der Phoenix-Gebührenlogik und BLS-Kryptografie.

Daher richte ich meinen Fokus inzwischen nicht mehr darauf, ob Dusk „EVM unterstützt“.

Vielmehr darauf, ob diese modulare Architektur die EVM-Kompatibilität tatsächlich in reale, regulatorisch konforme Finanzaktivitäten umwandeln kann.

Wird DuskEVM letztlich zur entscheidenden Brücke werden, die kryptonative Liquidität mit Dusk-konformer Abwicklung verbindet?#dusk $DUSK @Dusk