Je pensais autrefois que la partie difficile de la tokenisation des RWA consistait à faire passer l’actif en chaîne.
Plus je regardais @Dusk , plus je me disais que ce n’était peut-être pas la partie la plus compliquée.
Ce qui a attiré mon attention, c’est le workflow autour de l’actif. La conception de l’infrastructure de marché de Dusk commence par la mise en place de l’émetteur et l’éligibilité des investisseurs, puis passe par l’appairage du portefeuille, les contrôles de transfert, le trading, le règlement de l’actif/paiement, et enfin la gestion (service) et la divulgation. Cela m’a amené à regarder l’émission native sous un angle différent.
Prenons une obligation.
Un investisseur ne devrait pas recevoir simplement un token parce qu’il possède un portefeuille. Son éligibilité doit peut-être d’abord être vérifiée. S’il est qualifié, l’actif peut être transféré ; s’il ne l’est pas, le transfert doit respecter la restriction. Plus tard, l’obligation peut nécessiter un service ou un acte sur le capital (corporate action), tandis que le côté paiement doit encore se régler avec l’actif.
C’est cette partie qui m’intéresse.
La tokenisation peut vous donner une représentation numérique d’un actif, pendant que des éléments de sa garde, de son registre ou de son processus de règlement restent ailleurs. La définition de l’émission native par Dusk va plus loin : l’actif peut être créé et géré autour du registre, avec un cycle de vie conçu pour s’appuyer sur des workflows en chaîne.
Et c’est là que je me suis retrouvé bloqué.
Si une plus grande partie du cycle de vie se déplace en chaîne, la question difficile n’est pas de savoir si le code peut imposer une règle de transfert. La question, c’est ce qui se passe lorsque l’état en chaîne doit rester aligné avec la réalité juridique et institutionnelle qui se trouve en dehors du registre.
Dusk peut fournir l’infrastructure pour ce workflow, mais la structure juridique détermine toujours jusqu’où ces enregistrements en chaîne peuvent réellement remplacer les couches traditionnelles.
Du coup, je suis moins intéressé par la simple idée que les RWA seront “tokenisées”.
Ce qui m’intéresse davantage, c’est de savoir si les institutions finiront par avoir suffisamment confiance dans le cycle de vie réel de l’actif pour le déplacer en chaîne.
Si vous émettiez une obligation en chaîne, quelle partie de son cycle de vie continueriez-vous à confier à l’infrastructure traditionnelle ?
@Dusk $DUSK #dusk
Plus je regardais @Dusk , plus je me disais que ce n’était peut-être pas la partie la plus compliquée.
Ce qui a attiré mon attention, c’est le workflow autour de l’actif. La conception de l’infrastructure de marché de Dusk commence par la mise en place de l’émetteur et l’éligibilité des investisseurs, puis passe par l’appairage du portefeuille, les contrôles de transfert, le trading, le règlement de l’actif/paiement, et enfin la gestion (service) et la divulgation. Cela m’a amené à regarder l’émission native sous un angle différent.
Prenons une obligation.
Un investisseur ne devrait pas recevoir simplement un token parce qu’il possède un portefeuille. Son éligibilité doit peut-être d’abord être vérifiée. S’il est qualifié, l’actif peut être transféré ; s’il ne l’est pas, le transfert doit respecter la restriction. Plus tard, l’obligation peut nécessiter un service ou un acte sur le capital (corporate action), tandis que le côté paiement doit encore se régler avec l’actif.
C’est cette partie qui m’intéresse.
La tokenisation peut vous donner une représentation numérique d’un actif, pendant que des éléments de sa garde, de son registre ou de son processus de règlement restent ailleurs. La définition de l’émission native par Dusk va plus loin : l’actif peut être créé et géré autour du registre, avec un cycle de vie conçu pour s’appuyer sur des workflows en chaîne.
Et c’est là que je me suis retrouvé bloqué.
Si une plus grande partie du cycle de vie se déplace en chaîne, la question difficile n’est pas de savoir si le code peut imposer une règle de transfert. La question, c’est ce qui se passe lorsque l’état en chaîne doit rester aligné avec la réalité juridique et institutionnelle qui se trouve en dehors du registre.
Dusk peut fournir l’infrastructure pour ce workflow, mais la structure juridique détermine toujours jusqu’où ces enregistrements en chaîne peuvent réellement remplacer les couches traditionnelles.
Du coup, je suis moins intéressé par la simple idée que les RWA seront “tokenisées”.
Ce qui m’intéresse davantage, c’est de savoir si les institutions finiront par avoir suffisamment confiance dans le cycle de vie réel de l’actif pour le déplacer en chaîne.
Si vous émettiez une obligation en chaîne, quelle partie de son cycle de vie continueriez-vous à confier à l’infrastructure traditionnelle ?
@Dusk $DUSK #dusk