#dusk $DUSK @Dusk
La tokenisation est généralement décrite comme le fait de mettre un actif onchain. En réalité, c’est rarement le cas. Ce qui passe onchain, c’est une revendication sur l’actif, tandis que l’actif lui-même reste dans la base de données du même registre auprès duquel il a toujours vécu — et le cycle de vie y reste avec lui.
Le cycle de vie est la partie coûteuse. Une obligation n’est pas un objet statique. Elle verse des coupons, elle contient un registre des détenteurs, elle fait l’objet d’opérations sur titres, elle est donnée en nantissement en tant que collatéral, elle arrive à échéance. Chacun de ces événements correspond à une conciliation entre des systèmes qui ne partagent pas une source de vérité. En enveloppant l’instrument dans un jeton, on n’élimine aucun de ces éléments. On peut même dire que l’on en ajoute un, car désormais l’enveloppe et l’actif sous-jacent peuvent diverger.
L’émission native est la revendication que @dusk est en train de faire : créer l’instrument onchain dès le départ, avec l’éligibilité, les restrictions de transfert et la logique de règlement exprimées au niveau du protocole plutôt qu’ajoutées après coup. Zedger est le protocole d’actifs conçu pour cela, fonctionnant nativement sur DuskDS, avec Citadel qui gère l’identité et la divulgation sélective afin que l’éligibilité puisse être prouvée sans publier qui est le détenteur.
La difficulté réelle ici est d’ordre juridique, pas technique. Pour qu’une entrée de chaîne soit le registre plutôt qu’un simple miroir de celui-ci, le droit doit le permettre — et c’est précisément ce que le régime pilote DLT de l’UE a été conçu pour tester, dans les limites prévues pour l’instrument et sur une période limitée.
Donc la question qui vaut d’être posée au sujet de $DUSK n’est pas de savoir si l’émission native est meilleure en principe. C’est de savoir si un premier instrument réel est émis de cette façon et survit à ses propres dates de coupon. #dusk
La tokenisation est généralement décrite comme le fait de mettre un actif onchain. En réalité, c’est rarement le cas. Ce qui passe onchain, c’est une revendication sur l’actif, tandis que l’actif lui-même reste dans la base de données du même registre auprès duquel il a toujours vécu — et le cycle de vie y reste avec lui.
Le cycle de vie est la partie coûteuse. Une obligation n’est pas un objet statique. Elle verse des coupons, elle contient un registre des détenteurs, elle fait l’objet d’opérations sur titres, elle est donnée en nantissement en tant que collatéral, elle arrive à échéance. Chacun de ces événements correspond à une conciliation entre des systèmes qui ne partagent pas une source de vérité. En enveloppant l’instrument dans un jeton, on n’élimine aucun de ces éléments. On peut même dire que l’on en ajoute un, car désormais l’enveloppe et l’actif sous-jacent peuvent diverger.
L’émission native est la revendication que @dusk est en train de faire : créer l’instrument onchain dès le départ, avec l’éligibilité, les restrictions de transfert et la logique de règlement exprimées au niveau du protocole plutôt qu’ajoutées après coup. Zedger est le protocole d’actifs conçu pour cela, fonctionnant nativement sur DuskDS, avec Citadel qui gère l’identité et la divulgation sélective afin que l’éligibilité puisse être prouvée sans publier qui est le détenteur.
La difficulté réelle ici est d’ordre juridique, pas technique. Pour qu’une entrée de chaîne soit le registre plutôt qu’un simple miroir de celui-ci, le droit doit le permettre — et c’est précisément ce que le régime pilote DLT de l’UE a été conçu pour tester, dans les limites prévues pour l’instrument et sur une période limitée.
Donc la question qui vaut d’être posée au sujet de $DUSK n’est pas de savoir si l’émission native est meilleure en principe. C’est de savoir si un premier instrument réel est émis de cette façon et survit à ses propres dates de coupon. #dusk