Je me suis mis à fixer un organigramme de flux de paiement de dividendes jusqu’à ce qu’il cesse d’avoir du sens. DTC vers courtier vers sous-conservateur vers actionnaire : quatre “sauts”, et j’ai supposé que le goulot d’étranglement se trouvait quelque part dans la vitesse de traitement. Ce n’est pas le cas. Plus j’y regardais, plus je comprenais que le coût réel se cache dans la réconciliation : chaque maillon de cette chaîne met à jour ses propres registres indépendamment, puis tout le monde compare les notes après coup. C’est là que vont effectivement les 58 Md$ par an de coûts liés aux opérations sur titres.
Ce qui m’a frappé en creusant la conception XSC de DUSK, c’est qu’elle n’essaie pas de rendre chaque saut plus rapide. Elle supprime carrément le besoin de réconciliation entre les différents acteurs : une exécution, un résultat, et chaque détenteur lit à partir de la même source au lieu de quatre parties qui calculent séparément puis se recoupent. C’est à ce moment-là que l’approche de DUSK commence à me sembler différente de la plupart des infrastructures que j’avais examinées auparavant.
C’est aussi là que la distinction entre tokenisation et issuance native s’est éclaircie pour moi. Envelopper une action dans un token repose encore sur la même plomberie DTC que vous avez ajoutée, pas remplacée. Une émission native sur quelque chose comme DUSK pose une question plus directe : avez-vous encore besoin de milliers d’agents payeurs qui traitent indépendamment le même événement de dividende s’il existe une seule couche de règlement dont tout le monde se sert ? L’ensemble de l’architecture de DUSK semble parier sur la réponse étant “non”.
Je bloque encore, toutefois, sur la question de la responsabilité. Si un contrat DUSK calcule mal un paiement, qui est redevable : la chaîne, l’émetteur, l’agent payeur qui existait auparavant ? Je ne pense pas que ce point soit encore tranché, et je ne suis pas sûr qu’on doive le passer sous silence uniquement parce que l’architecture est plus propre.
#dusk $DUSK @Dusk
Ce qui m’a frappé en creusant la conception XSC de DUSK, c’est qu’elle n’essaie pas de rendre chaque saut plus rapide. Elle supprime carrément le besoin de réconciliation entre les différents acteurs : une exécution, un résultat, et chaque détenteur lit à partir de la même source au lieu de quatre parties qui calculent séparément puis se recoupent. C’est à ce moment-là que l’approche de DUSK commence à me sembler différente de la plupart des infrastructures que j’avais examinées auparavant.
C’est aussi là que la distinction entre tokenisation et issuance native s’est éclaircie pour moi. Envelopper une action dans un token repose encore sur la même plomberie DTC que vous avez ajoutée, pas remplacée. Une émission native sur quelque chose comme DUSK pose une question plus directe : avez-vous encore besoin de milliers d’agents payeurs qui traitent indépendamment le même événement de dividende s’il existe une seule couche de règlement dont tout le monde se sert ? L’ensemble de l’architecture de DUSK semble parier sur la réponse étant “non”.
Je bloque encore, toutefois, sur la question de la responsabilité. Si un contrat DUSK calcule mal un paiement, qui est redevable : la chaîne, l’émetteur, l’agent payeur qui existait auparavant ? Je ne pense pas que ce point soit encore tranché, et je ne suis pas sûr qu’on doive le passer sous silence uniquement parce que l’architecture est plus propre.
#dusk $DUSK @Dusk
