Je remarque encore que, quand quelque chose est intégré à un système, tout le monde commence à traiter l’événement de création comme la partie la plus importante. Peut-être parce que la création est facile à voir. Il y a un avant, puis soudain il y a une chose qui n’était pas là auparavant.

Avec un actif financier, toutefois, cette ligne semble trompeuse. Après l’émission, le travail délicat est toujours là. Qui peut le détenir. Qui peut le transférer. Qu’est-ce qui est divulgué. Ce qui se passe quand les investisseurs ont besoin de mises à jour, ou quand l’émetteur prend une mesure affectant l’actif.

C’est la partie de Dusk que j’ai dû relire deux fois. Sa documentation ne s’arrête pas à l’émission. Zedger et Hedger sont décrits autour de l’émission et de la gestion d’actifs réglementés, tandis que le vaste ensemble Dusk inclut l’éligibilité, les contrôles de transfert, la divulgation, le règlement et le service (servicing). Au début, je les ai lus comme des fonctions distinctes entourant le token. Puis j’ai eu l’impression qu’ils réagissaient plutôt à l’action du même actif lorsqu’il évolue dans le temps.

Le modèle de service des actifs numériques de Dusk place les registres, les actions sur le capital, les mises à jour des investisseurs, les votes et les événements de cycle de vie sur une infrastructure partagée. Cela changeait ce que je cherchais à l’origine. Le système ne fait pas qu’enregistrer qu’un actif existe. Il cherche à maintenir les règles et les relevés relatifs à cet actif coordonnés après l’émission.

Je ne suis toujours pas certain où se termine cette frontière. Si un actif continue d’évoluer au fil de la propriété, de l’éligibilité et des actions de l’émetteur, le token est-il l’identité stable de l’actif, ou juste l’endroit où toutes ces règles changeantes finissent par se rencontrer ?

#dusk $DUSK @Dusk $ACE $SNXXB