Quand j’ai redécouvert Dusk, je pensais voir seulement une L1 de type « privacy » ajoutant la compatibilité EVM.

Mais j’ai constaté que le changement réel concerne l’architecture.

Dusk sépare progressivement l’exécution des applications et la compensation financière.

Désormais, DuskDS sert de couche de règlement et de disponibilité des données en dessous, tandis que DuskEVM offre un environnement EVM équivalent basé sur OP Stack, permettant aux développeurs de faire entrer Solidity et les outils Ethereum grand public dans Dusk. Parallèlement, DuskVM conserve toujours la voie native Rust/WASM, afin de prendre en charge les applications qui ont besoin d’accéder directement à la L1, ou qui requièrent des capacités de confidentialité ou de ZK.

Cela a modifié ma compréhension du positionnement initial de Dusk.

Auparavant, le récit central tournait davantage autour de : confidentialité + conformité + actifs financiers.

Aujourd’hui, l’orientation ressemble davantage à : rendre compatibles avec l’écosystème de développement existant des infrastructures financières réglementées.

C’est crucial, car les institutions n’ont pas seulement besoin de technologies de confidentialité.

Elles ont aussi besoin que les portefeuilles, les outils de développement, la liquidité, les applications, le règlement et l’interopérabilité puissent fonctionner ensemble.

Dusk vise désormais clairement DuskEVM pour les actifs tokenisés et la DeFi, tandis que Hedger apporte des fonctionnalités liées à la confidentialité dans l’environnement EVM. Dans le même temps, la couche DuskDS conserve, en arrière-plan, les modèles de transactions de Phoenix et Moonlight.

Mais il existe aussi une réalité qu’il faut affronter.

Le 16 janvier 2026, Dusk a subi un incident de sécurité : un portefeuille à signature de pont a été compromis. Dusk indique que ce n’est pas une défaillance de la couche de consensus ni du protocole central. Ensuite, l’architecture de pont a été repensée, avec notamment une isolation des signatures, une isolation du traitement des événements, des frontières de sécurité plus strictes et une réduction de l’exposition du portefeuille « hot wallet ».

Par la suite, AEGIS a également identifié et traité 39 problèmes de sécurité, dont 7 problèmes critiques liés à la VM, à la sérialisation, au mécanisme de frais de Phoenix et à la cryptographie BLS.

Ainsi, ce qui m’intéresse désormais n’est plus de savoir si Dusk peut « supporter l’EVM ».

La question est plutôt de savoir si cette architecture modulaire peut transformer la compatibilité EVM en une activité financière réellement conforme et réglementée.

DuskEVM deviendra-t-il finalement le pont clé reliant la liquidité native crypto et la couche de règlement conforme de Dusk ?#dusk $DUSK @Dusk