J’essayais de déployer un simple ERC-20 sur le testnet DuskEVM cet après-midi. Rien de sophistiqué — juste un contrat de jeton standard compilé avec Solidity. Le déploiement a abouti, la transaction a été confirmée et l’adresse du contrat est apparue dans l’explorateur.

J’ai supposé que tout était prêt. C’était évident.

C’était le premier décalage.

Déploiement ≠ utilisabilité. Le contrat existait, mais quand j’ai essayé d’y accéder via le module de confidentialité Hedger, rien ne fonctionnait. La couche de chiffrement homomorphe ne s’appliquait pas automatiquement. En fait, les workflows EVM confidentiels ne sont pas de la magie — ils nécessitent une intégration explicite. Hedger utilise le chiffrement homomorphe et des preuves à divulgation nulle de connaissance pour prendre en charge une confidentialité vérifiable pour les applications financières réglementées, mais cette infrastructure ne s’enveloppe pas automatiquement autour de chaque contrat par défaut.

Ce à quoi je reviens sans cesse, c’est l’écart entre « compatible avec l’EVM » et « réellement utilisable pour des actifs réglementés ». DuskEVM offre aux partenaires et aux institutions un chemin Solidity familier, mais la familiarité ne signifie pas que les fonctionnalités de confidentialité sont « plug-and-play ». Les développeurs doivent comprendre où appliquer la confidentialité, comment structurer la divulgation sélective et à quoi ressemblent concrètement les limites de conformité.

C’est là que se situe la vraie friction. Pas dans la chaîne elle-même — mais dans le workflow entre le contrat et la couche de confidentialité.

Que se passe-t-il lorsque des développeurs institutionnels arrivent en s’attendant à un comportement EVM standard et se heurtent à ce décalage, de plein fouet ?

#dusk $DUSK @Dusk