Je pensais qu’en transformant des placements privés en token, on avait simplement terminé la mise à la chaîne des actifs. Mais après avoir lu l’article sur le marché des placements privés mis à jour hier (@Dusk ), puis en le rapprochant de la documentation Native Issuance, je suis au contraire plus inquiet d’un point : si le droit de propriété légal, la conservation (custody), les actions de la société et la compensation sont toujours déterminés par un autre système, ce token n’est peut-être pas un outil d’efficacité, mais plutôt une nouvelle série d’enregistrements à rapprocher.

La tokenisation crée généralement un token qui représente un actif ou une revendication de droit ; elle peut rendre l’actif plus facile à programmer, à distribuer et à intégrer dans des applications. Mais l’actif sous-jacent peut rester hors chaîne, enregistré, conservé ou compensé dans un système différent. Les exigences de la Native issuance sont plus élevées : l’actif lui-même est créé et géré autour d’un grand livre en chaîne ; l’émission, le transfert, le service et la compensation utilisent autant que possible le même état de propriété.

Le vrai test, c’est qu’une émission en placement privé doit être saisie six fois de manière répétée. Dans les processus traditionnels, l’émetteur, le conseiller, le gestionnaire, la banque, le dépositaire (custodian) et la plate-forme de négociation traitent chacun séparément l’approbation de la structure, l’éligibilité des investisseurs, l’attribution des souscriptions, le registre des porteurs, le paiement, le transfert et les services ultérieurs. Chaque partie conserve un enregistrement similaire mais pas identique. Les erreurs surviennent souvent lors des transferts et des validations a posteriori.

Si l’on se contente d’ajouter un token à l’ancien processus, il faut quand même faire correspondre les soldes on-chain avec le registre de référence off-chain. Le transfert est effectué on-chain, mais il faut attendre la mise à jour du registre. Les dividendes sont calculés à partir de la liste off-chain, puis on revient expliquer les détenteurs on-chain. En cas de litige, on ne sait pas non plus quel jeu d’enregistrements a priorité. Techniquement, cela semble plus rapide ; opérationnellement, cela crée au contraire un nouveau point de rupture.

Ce que change vraiment la Native issuance, c’est le processus et la frontière de confiance : l’éligibilité des investisseurs peut être vérifiée avant la souscription ou le transfert ; l’attribution et la mise à jour de la propriété se produisent autour d’un même état contrôlé ; les restrictions de transfert s’appliquent directement à l’enregistrement du détenteur actuel ; les « jambes » de l’actif et les « jambes » du paiement sont coordonnées selon le même processus de compensation ; les paiements d’intérêts (coupon), le vote, les dividendes et le rachat lisent un historique continu des droits de propriété. La divulgation sélective et le contrôle d’accès de Dusk répondent à « qui peut voir, qui peut faire ». La compensation déterministe de DuskDS répond à « quel état est déjà définitivement réglé ».

C’est plus important que « émettre des tokens moins cher », parce que cela vise à réduire les rapprochements en double entre l’émission, l’enregistrement, la conservation, la négociation et le service—et pas seulement à changer l’apparence de l’actif en un symbole on-chain.

Selon vous, quel est le point le plus difficile à faire fonctionner dans la Native issuance ? $DUSK #dusk