Je suis parti à la recherche du pipeline au nom exact dont tout le monde parle sans cesse autour des flux d’actifs réglementés sur Dusk, en m’attendant à quelque chose de court et accrocheur, trois ou quatre étapes, facile à répéter. Ce que les documents indiquaient en réalité était plus long et bien moins “citationnable” : création de l’émetteur, onboarding des investisseurs, contrôles de transfert, négociation ou distribution, règlement, puis gestion et divulgation. Six étapes, mappées à un tableau de compétences, pas à un slogan.

Ce qui a retenu mon attention n’était pas une étape en particulier : c’était l’endroit où se placent les contrôles de transfert et la divulgation. Ce ne sont pas des modules de conformité greffés après coup ; ce sont des capacités natives de la même couche de base qui gère le règlement, l’éligibilité et la confidentialité. La configuration de l’émetteur et l’onboarding des investisseurs ont lieu sur la même infrastructure qui impose ensuite qui est même autorisé à détenir ou à déplacer l’actif.

Une chose qu’il vaut la peine de dire honnêtement toutefois : la documentation est claire sur le fait que des applications différentes peuvent implémenter ce workflow de manière différente. Dusk fournit les blocs de construction et les parcours d’exécution, pas une séquence fixe imposée. Ainsi, disposer de ces briques sur une seule couche de base ne revient pas à ce que chaque application les assemble automatiquement correctement. Cette distinction entre « l’infrastructure le permet » et « l’application l’implémente réellement de bout en bout » me semble être la partie à surveiller, surtout quand de vrais produits commenceront à être livrés par-dessus.

#dusk $DUSK @Dusk $TUT $HEMI