Tous ceux qui ont déjà mené une audit de conformité ont un sentiment commun : le plus difficile n’est pas l’examen en lui-même, mais de prouver que le client n’a commis aucune infraction, tout en ne divulguant pas entièrement sa vie privée. La méthode traditionnelle consiste à vérifier les relevés de transactions, les documents d’identité et les justificatifs d’adresse ; puis, après l’audit, il faut encore archiver. Chaque dossier archivé représente un risque.
C’est pourquoi, quand je vois Dusk jouer la carte du « respect de la conformité et de la confidentialité », ma première réaction est de regarder comment il gère cette contradiction. La couche d’identité de Citadel emprunte la voie de la divulgation sélective : les utilisateurs détiennent des justificatifs délivrés par une institution ; lors des transactions, ils utilisent des preuves à connaissance nulle, un outil cryptographique qui ne révèle pas les informations spécifiques mais permet de prouver que « je remplis les conditions ». La preuve montre que les exigences sont satisfaites, sans devoir remettre les originaux. Moonlight traite les transferts standards via des comptes publics. Phoenix utilise une UTXO de confidentialité, semblable au modèle des sorties de transactions non dépensées de type Bitcoin : chaque transaction est isolée séparément, sans exposer les soldes, et il gère les transactions sensibles. Deux voies séparées sont donc suivies : l’une pour les transactions sensibles, l’autre pour les transferts ordinaires. @Dusk
Pour les actifs soumis à réglementation, cette logique tient : le transfert d’actifs doit à la fois passer par des contrôles de conformité et protéger la confidentialité, et on ne peut pas sacrifier le KYC au nom de la confidentialité.
Je ne cherche pas à l’embellir. La racine de confiance de Citadel repose sur le certificateur : qui a le droit de délivrer les justificatifs, comment ils sont révoqués, et si des institutions qui disparaissent laissent des justificatifs anciens qui restent valables ou non—ce n’est pas un problème que la cryptographie peut résoudre, c’est un problème de gouvernance. En tournant la page des documents, on constate que les détails de la mise en œuvre du mécanisme de révocation sont plutôt légers. Les juridictions multiples posent aussi problème : la définition d’« investisseurs qualifiés » dans l’Union européenne n’est pas identique à celle des États-Unis ; les justificatifs ne peuvent donc pas être réutilisés directement. En avril 2026, une faille dans une base cryptographique a certes été corrigée, mais cela pousse à se demander : y a-t-il encore d’autres problèmes ?
L’écosystème est aussi léger. GitHub est mis à jour lentement, il y a peu d’applications tierces, et la documentation est peu adaptée aux débutants. L’orientation technique est bonne, mais personne ne construit le bâtiment : même une bonne fondation reste un terrain vague.
Mon avis : Dusk a réussi à s’attaquer à ce problème technique difficile—« conformité et confidentialité à la fois »—et la direction est correcte. Le reste, ce sont des négociations commerciales et des échanges avec les régulateurs, et ces deux aspects coûtent beaucoup plus de temps que l’écriture de code.
Si on veut pousser une institution agréée à renoncer à sa “forteresse” de données clients, sur quoi peut-on la faire céder ? #dusk $DUSK
C’est pourquoi, quand je vois Dusk jouer la carte du « respect de la conformité et de la confidentialité », ma première réaction est de regarder comment il gère cette contradiction. La couche d’identité de Citadel emprunte la voie de la divulgation sélective : les utilisateurs détiennent des justificatifs délivrés par une institution ; lors des transactions, ils utilisent des preuves à connaissance nulle, un outil cryptographique qui ne révèle pas les informations spécifiques mais permet de prouver que « je remplis les conditions ». La preuve montre que les exigences sont satisfaites, sans devoir remettre les originaux. Moonlight traite les transferts standards via des comptes publics. Phoenix utilise une UTXO de confidentialité, semblable au modèle des sorties de transactions non dépensées de type Bitcoin : chaque transaction est isolée séparément, sans exposer les soldes, et il gère les transactions sensibles. Deux voies séparées sont donc suivies : l’une pour les transactions sensibles, l’autre pour les transferts ordinaires. @Dusk
Pour les actifs soumis à réglementation, cette logique tient : le transfert d’actifs doit à la fois passer par des contrôles de conformité et protéger la confidentialité, et on ne peut pas sacrifier le KYC au nom de la confidentialité.
Je ne cherche pas à l’embellir. La racine de confiance de Citadel repose sur le certificateur : qui a le droit de délivrer les justificatifs, comment ils sont révoqués, et si des institutions qui disparaissent laissent des justificatifs anciens qui restent valables ou non—ce n’est pas un problème que la cryptographie peut résoudre, c’est un problème de gouvernance. En tournant la page des documents, on constate que les détails de la mise en œuvre du mécanisme de révocation sont plutôt légers. Les juridictions multiples posent aussi problème : la définition d’« investisseurs qualifiés » dans l’Union européenne n’est pas identique à celle des États-Unis ; les justificatifs ne peuvent donc pas être réutilisés directement. En avril 2026, une faille dans une base cryptographique a certes été corrigée, mais cela pousse à se demander : y a-t-il encore d’autres problèmes ?
L’écosystème est aussi léger. GitHub est mis à jour lentement, il y a peu d’applications tierces, et la documentation est peu adaptée aux débutants. L’orientation technique est bonne, mais personne ne construit le bâtiment : même une bonne fondation reste un terrain vague.
Mon avis : Dusk a réussi à s’attaquer à ce problème technique difficile—« conformité et confidentialité à la fois »—et la direction est correcte. Le reste, ce sont des négociations commerciales et des échanges avec les régulateurs, et ces deux aspects coûtent beaucoup plus de temps que l’écriture de code.
Si on veut pousser une institution agréée à renoncer à sa “forteresse” de données clients, sur quoi peut-on la faire céder ? #dusk $DUSK