#dusk $DUSK @Dusk A token peut exister en chaîne tout en laissant le système financier majoritairement inchangé.
C’est, je pense, l’un des éléments de Dusk qui est facile à manquer.
Prenez une PME régulée en matière de sécurité. Le fait de faire passer l’instrument sur une blockchain n’est qu’une étape. Les investisseurs doivent encore être intégrés, l’éligibilité doit être gérée, la propriété doit être enregistrée, les transactions doivent avoir lieu, les informations à divulguer doivent parvenir aux bonnes parties, et, enfin, les volets « actif » et « paiement » doivent se règler.
Si chacune de ces étapes dépend toujours de systèmes distincts et d’une phase de rapprochement, le token lui-même n’a pas résolu le problème plus vaste.
C’est pourquoi la direction actuelle de Dusk a attiré mon attention.
Son architecture de base sépare le règlement et la disponibilité des données via DuskDS, de l’exécution via DuskVM et DuskEVM. Par-dessus, Dusk Trade est en cours de développement autour de flux de travail pratiques comme la découverte d’actifs, l’onboarding des investisseurs, le trading, la coordination des paiements et le règlement.
Il existe aussi un exemple concret de marché qui soutient cette thèse.
NPEX, une bourse de valeurs néerlandaise autorisée opérant un MTF, travaille avec Dusk sur une infrastructure basée sur la blockchain pour émettre, négocier et régler des instruments financiers régulés.
Et le dernier document de Dusk fait la même distinction que je trouve intéressante : la tokenisation devient plus utile lorsqu’elle relie le cycle de vie de la propriété, plutôt que de se contenter de créer une représentation numérique d’un actif.
Je commence donc à regarder Dusk moins comme un endroit où « déposer des RWA onchain » et davantage comme un pari sur quelque chose de plus difficile :
Le workflow financier lui-même peut-il devenir programmable ?
Car la vraie percée ne sera peut-être pas de créer le token.
Elle pourrait plutôt consister à supprimer l’empilement de processus déconnectés que le token était censé remplacer.
C’est, je pense, l’un des éléments de Dusk qui est facile à manquer.
Prenez une PME régulée en matière de sécurité. Le fait de faire passer l’instrument sur une blockchain n’est qu’une étape. Les investisseurs doivent encore être intégrés, l’éligibilité doit être gérée, la propriété doit être enregistrée, les transactions doivent avoir lieu, les informations à divulguer doivent parvenir aux bonnes parties, et, enfin, les volets « actif » et « paiement » doivent se règler.
Si chacune de ces étapes dépend toujours de systèmes distincts et d’une phase de rapprochement, le token lui-même n’a pas résolu le problème plus vaste.
C’est pourquoi la direction actuelle de Dusk a attiré mon attention.
Son architecture de base sépare le règlement et la disponibilité des données via DuskDS, de l’exécution via DuskVM et DuskEVM. Par-dessus, Dusk Trade est en cours de développement autour de flux de travail pratiques comme la découverte d’actifs, l’onboarding des investisseurs, le trading, la coordination des paiements et le règlement.
Il existe aussi un exemple concret de marché qui soutient cette thèse.
NPEX, une bourse de valeurs néerlandaise autorisée opérant un MTF, travaille avec Dusk sur une infrastructure basée sur la blockchain pour émettre, négocier et régler des instruments financiers régulés.
Et le dernier document de Dusk fait la même distinction que je trouve intéressante : la tokenisation devient plus utile lorsqu’elle relie le cycle de vie de la propriété, plutôt que de se contenter de créer une représentation numérique d’un actif.
Je commence donc à regarder Dusk moins comme un endroit où « déposer des RWA onchain » et davantage comme un pari sur quelque chose de plus difficile :
Le workflow financier lui-même peut-il devenir programmable ?
Car la vraie percée ne sera peut-être pas de créer le token.
Elle pourrait plutôt consister à supprimer l’empilement de processus déconnectés que le token était censé remplacer.
