@Dusk_Foundation Passé l’après-midi à parcourir la documentation des actifs gérés de Dusk et une chose n’a cessé de me revenir en tête même après avoir fermé l’onglet.
La plupart des discussions sur la RWA commencent par le token. On met un actif on-chain, puis on ajoute des règles pour le déplacer ou le restreindre. Dusk part dans l’autre sens — des contraintes réelles d’un marché géré.
Un actif réglementé a besoin de plus qu’un transfert. Il lui faut des contrôles d’éligibilité, des règles de transfert pouvant échouer avec des raisons claires, une divulgation sélective pour les émetteurs ou les superviseurs, des parcours de récupération, des opérations sur titres, du reporting, et un règlement coordonné de la jambe « actif » et de la jambe « paiement ». #dusk
Dusk traite tout cela comme des éléments de premier plan. Citadel gère l’identité et la divulgation sélective. Les contrats peuvent appliquer des listes d’autorisation et des restrictions. Phoenix et Moonlight offrent le choix entre des flux protégés et des flux transparents. Le règlement repose sur une finalité déterministe via l’Attestation succincte. Le protocole n’impose pas à chaque application la même forme. Il fournit les blocs afin qu’un émetteur ou un lieu puisse assembler ce dont ses règles ont besoin.
Cette conception est réelle.
Ce qui revenait en boucle, c’est à quel point on ne voit encore que très peu du workflow complet. Les éléments existent. Les flux d’actifs gérés en production qui utilisent réellement ensemble l’éligibilité, la divulgation sélective, la récupération et le règlement coordonné restent rares. La plupart des activités semblent encore plus simples.
Je réfléchis encore à savoir si le fait de disposer de l’ensemble complet des blocs de construction suffit, ou si la partie la plus difficile consiste à faire démarrer l’assemblage chez les institutions qui ont besoin du cycle de vie complet d’un actif géré.
$DUSK
La plupart des discussions sur la RWA commencent par le token. On met un actif on-chain, puis on ajoute des règles pour le déplacer ou le restreindre. Dusk part dans l’autre sens — des contraintes réelles d’un marché géré.
Un actif réglementé a besoin de plus qu’un transfert. Il lui faut des contrôles d’éligibilité, des règles de transfert pouvant échouer avec des raisons claires, une divulgation sélective pour les émetteurs ou les superviseurs, des parcours de récupération, des opérations sur titres, du reporting, et un règlement coordonné de la jambe « actif » et de la jambe « paiement ». #dusk
Dusk traite tout cela comme des éléments de premier plan. Citadel gère l’identité et la divulgation sélective. Les contrats peuvent appliquer des listes d’autorisation et des restrictions. Phoenix et Moonlight offrent le choix entre des flux protégés et des flux transparents. Le règlement repose sur une finalité déterministe via l’Attestation succincte. Le protocole n’impose pas à chaque application la même forme. Il fournit les blocs afin qu’un émetteur ou un lieu puisse assembler ce dont ses règles ont besoin.
Cette conception est réelle.
Ce qui revenait en boucle, c’est à quel point on ne voit encore que très peu du workflow complet. Les éléments existent. Les flux d’actifs gérés en production qui utilisent réellement ensemble l’éligibilité, la divulgation sélective, la récupération et le règlement coordonné restent rares. La plupart des activités semblent encore plus simples.
Je réfléchis encore à savoir si le fait de disposer de l’ensemble complet des blocs de construction suffit, ou si la partie la plus difficile consiste à faire démarrer l’assemblage chez les institutions qui ont besoin du cycle de vie complet d’un actif géré.
$DUSK