J’ai passé du temps cette semaine avec la couche de conformité de Dusk Network — en particulier ce que le $DUSK permet réellement lorsque vous dépassez le pitch deck. L’argument architectural est solide : Citadel gère le ZK-KYC à l’onboarding, Hedger applique des règles lors de l’exécution. #dusk @Dusk L’affirmation est que la conformité vit dans la transaction, et non autour d’elle. C’est toute la différence avec chaque autre chaîne RWA.

Puis, l’incident de pont du 16 août est survenu. Activité suspecte sur un portefeuille géré par une équipe, pont mis en pause, aucun fonds utilisateur perdu — ils ont réagi vite. Mais le correctif qui a retenu l’attention : une liste noire de destinataires de Web Wallet, déployée pour bloquer les transferts vers des adresses signalées. Restriction au niveau de l’adresse. Le même outil brutal que la TradFi utilise depuis des décennies. Bloquer l’adresse, pas vérifier la transaction.

Ce n’est pas une critique. En cas de crise, la réponse par défaut est l’outil le plus rapide disponible, et une blocklist est exactement ça. Mais c’est une illustration précise de ce que tout le projet essaie de quitter. La propriété au niveau du token est résolue. Le blocage au niveau de l’adresse est résolu. Ce qui reste vraiment non résolu — et sur quoi le pitch RWA institutionnel dépend — c’est l’application des règles par elles-mêmes lors de l’exécution, à l’intérieur de chaque transaction, de façon déterministe, sans que quelqu’un ait à basculer un interrupteur.

L’architecture de Dusk est orientée vers ce problème correctement. La question que je ne cesse de me poser, c’est de savoir si la couche de conformité ZK va mûrir avant que les institutions qu’elle cherche à convaincre aient réellement besoin de l’utiliser sous pression…