Je me rends de plus en plus compte que, pour la RWA, la vraie difficulté n’est pas de “mettre sur la blockchain”, mais de ne pas reproduire à l’identique l’ancien système.
Récemment, en me replongeant dans @Dusk , j’ai remarqué un détail qu’on a facilement tendance à négliger : beaucoup de projets RWA concentrent leurs efforts sur l’étape où “l’actif devient un Token”, alors que les vrais problèmes commencent en réalité après la tokenisation.
Une fois qu’un fonds, qu’une obligation ou un autre actif a été émis, comment l’investisseur entre-t-il, qui est autorisé à le détenir, à qui peut-il être transféré, quand le règlement est-il effectué, quelles informations doivent être divulguées : ce sont là les véritables opérations quotidiennes des actifs financiers. Si ces գործընթաց restent dépendants de tableaux hors chaîne, de validations manuelles et de rapprochements répétés entre différents systèmes, alors la tokenisation risque fort de n’être qu’un habillage blockchain pour l’ancien système financier.
Ce qui m’intéresse dans l’approche de Dusk, c’est justement sa tentative de réunir tous ces processus au sein d’une même infrastructure. Dans l’architecture officielle, DuskDS prend en charge le consensus, la finalité, la disponibilité des données et le règlement ; DuskVM peut exécuter directement des contrats Rust/WASM ; et DuskEVM fournit un environnement d’exécution EVM. L’intérêt n’est pas d’avoir toujours plus de modules, mais de réduire les ruptures entre les règles de l’actif, l’exécution et le règlement final. 
Il y a aussi la voie XSC et Zedger qui mérite qu’on s’y attarde. Dans la conception initiale de Dusk, Zedger a été pensé autour des actifs de type titres financiers, en tenant compte des capacités de compte, des restrictions de transfert, du vote, des dividendes et du règlement conforme. Autrement dit, le cycle de vie de l’actif commence à devenir un objet que le protocole doit gérer, au lieu de simplement émettre un Token puis de repousser toutes les règles hors chaîne. 
Cela m’amène à reconsidérer $DUSK : ce qui mérite vraiment d’être observé n’est pas seulement la confidentialité ou la compatibilité EVM, mais sa capacité à relier émission, éligibilité, transfert, confidentialité et règlement en un flux complet.
Bien sûr, la solidité de l’architecture devra au final être validée par des actifs réels et des institutions réelles. Pour ma part, c’est même là que Dusk devient le plus intéressant à mes yeux — non pas pour savoir s’il peut mettre des actifs financiers sur la blockchain, mais pour voir s’il peut réellement supprimer une partie de ces étapes de friction qui, jusque-là, dépendaient inévitablement d’intermédiaires. #dusk
#dusk $DUSK @Dusk
Récemment, en me replongeant dans @Dusk , j’ai remarqué un détail qu’on a facilement tendance à négliger : beaucoup de projets RWA concentrent leurs efforts sur l’étape où “l’actif devient un Token”, alors que les vrais problèmes commencent en réalité après la tokenisation.
Une fois qu’un fonds, qu’une obligation ou un autre actif a été émis, comment l’investisseur entre-t-il, qui est autorisé à le détenir, à qui peut-il être transféré, quand le règlement est-il effectué, quelles informations doivent être divulguées : ce sont là les véritables opérations quotidiennes des actifs financiers. Si ces գործընթաց restent dépendants de tableaux hors chaîne, de validations manuelles et de rapprochements répétés entre différents systèmes, alors la tokenisation risque fort de n’être qu’un habillage blockchain pour l’ancien système financier.
Ce qui m’intéresse dans l’approche de Dusk, c’est justement sa tentative de réunir tous ces processus au sein d’une même infrastructure. Dans l’architecture officielle, DuskDS prend en charge le consensus, la finalité, la disponibilité des données et le règlement ; DuskVM peut exécuter directement des contrats Rust/WASM ; et DuskEVM fournit un environnement d’exécution EVM. L’intérêt n’est pas d’avoir toujours plus de modules, mais de réduire les ruptures entre les règles de l’actif, l’exécution et le règlement final. 
Il y a aussi la voie XSC et Zedger qui mérite qu’on s’y attarde. Dans la conception initiale de Dusk, Zedger a été pensé autour des actifs de type titres financiers, en tenant compte des capacités de compte, des restrictions de transfert, du vote, des dividendes et du règlement conforme. Autrement dit, le cycle de vie de l’actif commence à devenir un objet que le protocole doit gérer, au lieu de simplement émettre un Token puis de repousser toutes les règles hors chaîne. 
Cela m’amène à reconsidérer $DUSK : ce qui mérite vraiment d’être observé n’est pas seulement la confidentialité ou la compatibilité EVM, mais sa capacité à relier émission, éligibilité, transfert, confidentialité et règlement en un flux complet.
Bien sûr, la solidité de l’architecture devra au final être validée par des actifs réels et des institutions réelles. Pour ma part, c’est même là que Dusk devient le plus intéressant à mes yeux — non pas pour savoir s’il peut mettre des actifs financiers sur la blockchain, mais pour voir s’il peut réellement supprimer une partie de ces étapes de friction qui, jusque-là, dépendaient inévitablement d’intermédiaires. #dusk
#dusk $DUSK @Dusk
