J’ai terminé hier un script d’automatisation pour le règlement d’actifs, et comme j’avais fini trop tôt, je me suis mis à fouiller le modèle de jeton de Zedger associé au @Dusk . En lisant les détails d’interaction, j’ai failli ne pas réagir tellement c’était contre-intuitif : sur Dusk, pour transférer des actifs de titres, le destinataire doit explicitement cliquer sur « consentir » ; sinon, le transfert n’est jamais considéré comme véritablement achevé, et les actifs restent indéfiniment à l’adresse d’origine. Habitué que j’étais à jouer sur les chaînes EVM — « émettre une requête, puis c’est on-chain, et hop, réception instantanée » — ma première réaction a été : quelle idée de retomber dans un design qui ressemble à l’époque où il fallait confirmer par e-mail ?
Mais je suis du genre à croire au « survivre d’abord ». En posant tout à plat, en comparant cette logique avec les procédures traditionnelles de registre et de compensation des titres, j’ai fini par comprendre. Dans la finance réglementée, la cession d’actions n’est jamais un simple transfert unilatéral : c’est le prestataire de registre et de compensation qui confirme l’éligibilité de l’acheteur, puis qui renomme le titulaire sur la liste des détenteurs. Dusk a intégré cette « confirmation bilatérale » directement dans la couche protocolaire — si la whitelist n’est pas conforme ou si l’utilisateur n’appose pas sa signature volontairement, on ne peut tout simplement pas « récupérer » l’identité d’actionnaire.
En y réfléchissant bien, cela élimine directement trois douleurs critiques : premièrement, les attaques de poussière : auparavant, toutes sortes de monnaies poubelles venaient spammer votre adresse, tandis que sur Zedger, elles sont rejetées d’entrée ; deuxièmement, la répartition des responsabilités et la conformité : des positions non consenties ne sont pas valables, et les limites de responsabilité sont nettes ; troisièmement, les litiges de règlement : cela résout enfin l’écart de temps du modèle traditionnel DvP (livraison contre paiement) — signature = finalité, plus de tiraillements dans un état intermédiaire.
Cela dit, côté développement, j’ai aussi quelques doutes. Pour chaque règlement, une signature supplémentaire, c’est une friction bien réelle, surtout pour quelqu’un qui exécute des scripts à haute fréquence et des traitements automatisés par lots. À l’avenir, comment Dusk va trouver l’équilibre entre un « consentement strictement explicite » et l’« automatisation par lots » pour les règlements, je vais continuer à surveiller de près le dépôt de code.
Et vous, vous pensez que des institutions accepteront cette approche de « confirmation de réception » qui sacrifie un peu de fluidité d’interaction au nom de la conformité ? Faites-moi part de vos avis en commentaires.
@Dusk #dusk $DUSK
Mais je suis du genre à croire au « survivre d’abord ». En posant tout à plat, en comparant cette logique avec les procédures traditionnelles de registre et de compensation des titres, j’ai fini par comprendre. Dans la finance réglementée, la cession d’actions n’est jamais un simple transfert unilatéral : c’est le prestataire de registre et de compensation qui confirme l’éligibilité de l’acheteur, puis qui renomme le titulaire sur la liste des détenteurs. Dusk a intégré cette « confirmation bilatérale » directement dans la couche protocolaire — si la whitelist n’est pas conforme ou si l’utilisateur n’appose pas sa signature volontairement, on ne peut tout simplement pas « récupérer » l’identité d’actionnaire.
En y réfléchissant bien, cela élimine directement trois douleurs critiques : premièrement, les attaques de poussière : auparavant, toutes sortes de monnaies poubelles venaient spammer votre adresse, tandis que sur Zedger, elles sont rejetées d’entrée ; deuxièmement, la répartition des responsabilités et la conformité : des positions non consenties ne sont pas valables, et les limites de responsabilité sont nettes ; troisièmement, les litiges de règlement : cela résout enfin l’écart de temps du modèle traditionnel DvP (livraison contre paiement) — signature = finalité, plus de tiraillements dans un état intermédiaire.
Cela dit, côté développement, j’ai aussi quelques doutes. Pour chaque règlement, une signature supplémentaire, c’est une friction bien réelle, surtout pour quelqu’un qui exécute des scripts à haute fréquence et des traitements automatisés par lots. À l’avenir, comment Dusk va trouver l’équilibre entre un « consentement strictement explicite » et l’« automatisation par lots » pour les règlements, je vais continuer à surveiller de près le dépôt de code.
Et vous, vous pensez que des institutions accepteront cette approche de « confirmation de réception » qui sacrifie un peu de fluidité d’interaction au nom de la conformité ? Faites-moi part de vos avis en commentaires.
@Dusk #dusk $DUSK