Ce qui me fait revenir, concernant les titres tokenisés, c’est que l’éligibilité n’est pas une fonctionnalité qu’on ajoute plus tard. Elle doit être structurelle, sinon ce n’est pas vraiment conforme, simplement présenté comme tel. Les primitives de contrôle d’accès de Dusk sont conçues pour gérer, au niveau du protocole, les vérifications d’éligibilité des investisseurs, le statut d’accréditation, la juridiction et des contraintes similaires, plutôt que de passer par un arbitre hors chaîne greffé sur un contrat public.
Pourquoi cette distinction est importante : l’application hors chaîne dépend du fait que quelqu’un vérifie réellement, de façon systématique, à chaque fois. Les primitives on-chain font en sorte que la vérification fasse partie de la logique même de la transaction, ce qui constitue en principe une garantie plus forte, mais seulement si les données sous-jacentes d’identité et d’attestation qui alimentent ces vérifications sont elles-mêmes dignes de confiance. La confidentialité ajoute une autre couche de tension ici, car vérifier l’éligibilité sans exposer l’identité complète de l’investisseur est un problème plus difficile que de le vérifier à ciel ouvert. Ce que je ne sais pas encore, c’est comment ces primitives gèrent les cas limites, les changements de juridiction, la révocation de l’accréditation et les attestations contestées. Je préfère les voir testées dans des scénarios réels, imparfaits, plutôt que dans une documentation soignée. J’observe comment les émetteurs configurent concrètement ces contrôles dans la pratique.

@Dusk #dusk $DUSK