Je pensais auparavant qu’une fois les actions « tokenisées » et le contrat émis, le travail était terminé. Le XSC de Dusk m’a donné un rappel : il est défini comme un standard de contrat confidentiel, adaptable aux exigences métier en matière de contraintes de confidentialité et de règles de conformité. Et pour les actifs réglementés, le véritable problème n’est pas seulement le contrat lui-même : ce sont le statut des détenteurs et les restrictions de transfert, ainsi que les droits qui suivent, que des rustines manuelles ne peuvent pas maintenir dans la durée.

J’assimile un Token classique à une simple plaque d’adresse, tandis que le XSC doit traiter plutôt l’ensemble des règles de gestion immobilière. Qui a le droit de détenir ? Qui peut recevoir ? Quel transfert doit échouer ? Tout cela doit être jugé conjointement par des pièces d’identité, la liaison avec le portefeuille et la logique du contrat. Les dividendes ou paiements d’intérêts, le vote, la récupération après perte de clés, ainsi que les rapports d’audit font aussi partie du cycle de vie de l’actif.

@Dusk Dusk ne cherche pas à faire changer les titres d’habillage on-chain ; il veut que les règles suivent l’actif lorsqu’il circule.

Mais le contrat ne comprend pas automatiquement le droit. Dans différentes régions, les conditions d’éligibilité doivent être définies par l’émetteur et des professionnels. Une erreur de configuration de la liste blanche ou des autorisations peut soit exclure des investisseurs réellement qualifiés, soit inclure des personnes qui ne devraient pas y avoir accès. La récupération et les opérations forcées donnent à l’émetteur une capacité de remédiation, mais elles introduisent aussi un risque d’abus de privilèges. Je me concentre donc surtout sur la capacité de Dusk à faire en sorte que ces rôles laissent des traces et puissent être audités.

La tokenisation, c’est seulement l’affichage ; ce qui détermine si c’est un « actif », c’est la possibilité d’exécuter les règles sur le long terme.

#dusk $DUSK