La plupart des projets du marché suivent une voie de type « émission de tokens puis rattrapage des tickets » : on fait d’abord monter les tokens, on creuse la liquidité, puis côté conformité ? On finit par demander à un cabinet d’avocats de produire un avis, et c’est réglé. Pour être un peu cru : sous l’œil attentif des régulateurs, je ne suis pas sûr qu’un tel modèle tienne plusieurs cycles de marché haussier.
Jusqu’à ce que je démonte, en détail, les standards Zedger et XSC de @Dusk , je me suis rendu compte que certaines équipes avaient réellement réfléchi à tout. Elles ont codé directement, au niveau du contrat, des logiques de conformité comme la vérification des investisseurs qualifiés, les restrictions de cession et les votes liés aux distributions. Avant que chaque transaction ne soit réglée, elle passe d’abord par une vérification de conformité : si c’est validé, on génère un justificatif on-chain et on autorise ; si ce n’est pas validé, la transaction est bloquée sur place. Ce n’est pas une question d’attendre que la transaction soit sur la chaîne puis de chercher qui blâmer : c’est à la source qu’on refuse toute action non conforme. Cette logique de « vérification préalable » est assez similaire, dans son esprit, à la logique de base de gestion des risques de transaction chez Newton ; simplement, Dusk l’a appliquée à un niveau plus sensible : la mise en œuvre réglementaire.
La couche données s’appuie sur la mémoire au sein de comptes privés pour réaliser une boucle de vérification de bout en bout. En théorie, c’est un cran au-dessus des projets qui dépendent d’un contrôle manuel hors chaîne. La fiabilité de la tarification fournie par RedStone a déjà été validée sur plus de 110 chaînes ; je ne suis donc pas trop inquiet sur ce point.
Mais je dois le dire : dans les informations publiques actuelles, il y a un point qui m’empêche de dormir tranquille — le pouvoir de modification des règles n’est pas clairement établi.
Même si le contrat intelligent fonctionne parfaitement, si, dans les coulisses, il y a une sorte de « porte dérobée administrateur » capable de modifier des paramètres ou des règles à tout moment, la capacité de résistance du système face aux risques devient alors très incertaine. Que se passe-t-il si la politique réglementaire change ? Qui déclenche la modification si les règles fiscales évoluent ? Y a-t-il des contraintes obligatoires comme un time-lock et des signatures multiples ? À l’heure actuelle, je ne vois pas de réponses claires à ces questions clés.
Mon avis : la direction est bonne, mais la route est encore longue. Transformer les règles de conformité en capacité fondamentale on-chain, c’est une approche que je juge prometteuse sur le long terme. Mais Dusk doit encore être validé par une épreuve avec des volumes de fonds réels : un test qui marche avec quelques millions de dollars ne prouve pas forcément que ça restera stable avec des dizaines de milliards. Par la suite, je vais surtout surveiller le déploiement de DuskTrade en collaboration avec NPEX : si tout le flux — appariement des transactions, compensation et règlement, vérification de conformité — fonctionne de bout en bout, alors seulement on pourra dire que cette voie est réellement praticable.
Vous pensez que la conformité native on-chain est une solution finale, ou bien qu’elle est trop idéalisée ? Discutons-en dans la section commentaires.
#dusk $DUSK @Dusk
Jusqu’à ce que je démonte, en détail, les standards Zedger et XSC de @Dusk , je me suis rendu compte que certaines équipes avaient réellement réfléchi à tout. Elles ont codé directement, au niveau du contrat, des logiques de conformité comme la vérification des investisseurs qualifiés, les restrictions de cession et les votes liés aux distributions. Avant que chaque transaction ne soit réglée, elle passe d’abord par une vérification de conformité : si c’est validé, on génère un justificatif on-chain et on autorise ; si ce n’est pas validé, la transaction est bloquée sur place. Ce n’est pas une question d’attendre que la transaction soit sur la chaîne puis de chercher qui blâmer : c’est à la source qu’on refuse toute action non conforme. Cette logique de « vérification préalable » est assez similaire, dans son esprit, à la logique de base de gestion des risques de transaction chez Newton ; simplement, Dusk l’a appliquée à un niveau plus sensible : la mise en œuvre réglementaire.
La couche données s’appuie sur la mémoire au sein de comptes privés pour réaliser une boucle de vérification de bout en bout. En théorie, c’est un cran au-dessus des projets qui dépendent d’un contrôle manuel hors chaîne. La fiabilité de la tarification fournie par RedStone a déjà été validée sur plus de 110 chaînes ; je ne suis donc pas trop inquiet sur ce point.
Mais je dois le dire : dans les informations publiques actuelles, il y a un point qui m’empêche de dormir tranquille — le pouvoir de modification des règles n’est pas clairement établi.
Même si le contrat intelligent fonctionne parfaitement, si, dans les coulisses, il y a une sorte de « porte dérobée administrateur » capable de modifier des paramètres ou des règles à tout moment, la capacité de résistance du système face aux risques devient alors très incertaine. Que se passe-t-il si la politique réglementaire change ? Qui déclenche la modification si les règles fiscales évoluent ? Y a-t-il des contraintes obligatoires comme un time-lock et des signatures multiples ? À l’heure actuelle, je ne vois pas de réponses claires à ces questions clés.
Mon avis : la direction est bonne, mais la route est encore longue. Transformer les règles de conformité en capacité fondamentale on-chain, c’est une approche que je juge prometteuse sur le long terme. Mais Dusk doit encore être validé par une épreuve avec des volumes de fonds réels : un test qui marche avec quelques millions de dollars ne prouve pas forcément que ça restera stable avec des dizaines de milliards. Par la suite, je vais surtout surveiller le déploiement de DuskTrade en collaboration avec NPEX : si tout le flux — appariement des transactions, compensation et règlement, vérification de conformité — fonctionne de bout en bout, alors seulement on pourra dire que cette voie est réellement praticable.
Vous pensez que la conformité native on-chain est une solution finale, ou bien qu’elle est trop idéalisée ? Discutons-en dans la section commentaires.
#dusk $DUSK @Dusk
