Depuis un moment, je travaille avec la norme XSC de Dusk, et le point qui m’a frappé : l’éligibilité au règlement et l’éligibilité au transfert sont deux couches distinctes, pas une seule. #dusk @Dusk's Phoenix/Moonlight rails fournissent un jeton de sécurité avec une finalité cryptographique en quelques secondes. Mais un transfert XSC nécessite encore que le portefeuille destinataire soit validé par la couche de contrôle d’accès de l’émetteur — sans validation, aucun transfert, quelle que soit la finalité.
Ce n’est pas seulement une vieille documentation de conception. Le cadre STO de Dusk, datant de 2019, décrit le whitelisting afin que les émetteurs puissent tenir à l’écart des parties non éligibles même après la clôture d’une offre. Plus révélateur encore : le site actuel de Dusk indique que la base d’actifs gérés totale de plus de 300 M$ de NPEX est tokenisée sur Dusk maintenant, en fonctionnant sur « access controls, privacy with selective disclosure, deterministic finality » comme une seule pile — ce qui signifie que ce filtrage n’est pas hypothétique : c’est une infrastructure en production adossée à des actifs réels.
Pour moi, ce qui a changé, c’est la prise de conscience que la tokenisation de RWA sur $DUSK SK ne signifie pas une liquidité sans permission. Cela signifie une permission programmable. La chaîne élimine la friction du règlement ; elle ne supprime pas le gardien, elle lui donne simplement des outils plus rapides.
La prochaine chose que je veux vérifier : si une décision de contrôle d’accès sur un actif NPEX émis en conditions réelles — approuver ou bloquer un portefeuille — constitue un événement on-chain consultable, ou si cela n’apparaît que comme un échec de transaction, la justification restant hors chaîne.
#dusk
@Dusk