Honnêtement, tokeniser des actifs du monde réel semble facile jusqu’à ce qu’on pense à ce qui se passe après la création du token.
Mettre des obligations, des actions ou des fonds on-chain, c’est une chose. Leur faire respecter des règles de conformité tout en permettant la confidentialité, c’est beaucoup plus difficile.
C’est la partie qui m’intéresse dans le <t-2/>$DUSK
L’idée est d’intégrer la conformité directement dans la logique de l’actif, afin que les transferts puissent suivre des règles prédéfinies au lieu de dépendre uniquement de processus manuels.
Il y a ensuite la Livraison contre Paiement. Le principe de base est simple : l’actif et le paiement se déplacent ensemble de manière atomique. Soit les deux sont réglés, soit aucun des deux ne l’est. Cela peut réduire le risque de contrepartie et le risque de règlement.
Le côté développeurs, lui aussi, est logique. DuskEVM offre aux développeurs Solidity un parcours familier, tandis que DuskVM permet des contrats natifs axés sur la confidentialité grâce à Rust et à des capacités de preuves à divulgation nulle.
Mais voici le hic.
Une bonne architecture ne crée pas automatiquement un marché financier.
Le <t-2/>@Dusk a encore besoin de vrais émetteurs, investisseurs, développeurs, liquidité et d’un usage concret. Les incitations au staking peuvent attirer la participation, mais elles ne prouvent pas, à elles seules, l’existence d’une demande organique.
Je m’intéresse donc moins au nombre de fonctionnalités présentes sur le papier qu’au fait de savoir si de réelles activités financières commencent à circuler grâce à elles.
La technologie est intéressante.
Maintenant, il faut qu’elle soit adoptée pour prouver qu’elle compte.
@Dusk
#dusk $DUSK
Mettre des obligations, des actions ou des fonds on-chain, c’est une chose. Leur faire respecter des règles de conformité tout en permettant la confidentialité, c’est beaucoup plus difficile.
C’est la partie qui m’intéresse dans le <t-2/>$DUSK
L’idée est d’intégrer la conformité directement dans la logique de l’actif, afin que les transferts puissent suivre des règles prédéfinies au lieu de dépendre uniquement de processus manuels.
Il y a ensuite la Livraison contre Paiement. Le principe de base est simple : l’actif et le paiement se déplacent ensemble de manière atomique. Soit les deux sont réglés, soit aucun des deux ne l’est. Cela peut réduire le risque de contrepartie et le risque de règlement.
Le côté développeurs, lui aussi, est logique. DuskEVM offre aux développeurs Solidity un parcours familier, tandis que DuskVM permet des contrats natifs axés sur la confidentialité grâce à Rust et à des capacités de preuves à divulgation nulle.
Mais voici le hic.
Une bonne architecture ne crée pas automatiquement un marché financier.
Le <t-2/>@Dusk a encore besoin de vrais émetteurs, investisseurs, développeurs, liquidité et d’un usage concret. Les incitations au staking peuvent attirer la participation, mais elles ne prouvent pas, à elles seules, l’existence d’une demande organique.
Je m’intéresse donc moins au nombre de fonctionnalités présentes sur le papier qu’au fait de savoir si de réelles activités financières commencent à circuler grâce à elles.
La technologie est intéressante.
Maintenant, il faut qu’elle soit adoptée pour prouver qu’elle compte.
@Dusk
#dusk $DUSK
