#dusk $DUSK
Ce qui a attiré mon attention n’est pas le chiffre de 300 M€ associé à NPEX, mais un détail plus discret, enfoui dans la documentation de l’infrastructure de marché de Dusk : avant qu’un actif puisse bouger, un portefeuille doit être lié à un participant « Verified ». Pas un KYC effectué une fois puis oublié. Liaison par actif, comme condition de transfert opposable.
Je voulais vérifier ce que cela signifie concrètement sur le plan mécanique, parce que la tokenisation conforme est souvent évoquée de façon un peu vague.
Voici la séquence décrite par Dusk pour un onboarding de type NPEX : un émetteur définit des règles d’éligibilité pour l’actif. Les portefeuilles des investisseurs sont liés à des identifiants vérifiés. À partir de là, la couche du contrat de transfert applique qui est même autorisé à détenir ou à déplacer le token : la restriction se situe au niveau du règlement, pas dans une case à cocher d’une interface. Le règlement lie la jambe « actif » et la jambe « paiement » afin d’obtenir une finalité déterministe, de sorte que vous n’obtenez pas un état où les parts ont été déplacées mais pas le paiement.
Pourquoi c’est important : NPEX est un MTF néerlandais sous supervision de l’AFM. Il ne peut pas simplement pointer vers un ERC-20 public et dire que c’est un titre. Le contrôle d’éligibilité doit être opposable on-chain, pas seulement via l’interface sinon la partie « régulée » n’est qu’une mise en scène.
Le point que je voudrais vérifier et que je n’ai pas vu être entièrement spécifié : que se passe-t-il lorsque l’éligibilité change—un investisseur est-il dérégristré ou une règle de juridiction est mise à jour—pour des tokens déjà détenus ? Le lien est-il révoqué de façon rétroactive, ou ne bloque-t-il que les transferts futurs ?
C’est le test réel de savoir s’il s’agit d’un système d’actifs réellement régulé ou simplement d’un contrôle de conformité au moment de l’émission.
Le déplacement de 300 M€ par NPEX n’est qu’un point de données. Le fait que la logique de contrôle des transferts tienne face à un cas limite réglementaire en conditions réelles est ce qui déterminera si cela se généralise au reste du secteur.
Je suis sincèrement curieux de savoir comment Dusk gère le cas de révocation : quelqu’un a-t-il examiné de près la spécification Transfer contrôlée par Zedger/Hedger assez attentivement pour savoir ?
@Dusk_Foundation $DUSK #dusk
Ce qui a attiré mon attention n’est pas le chiffre de 300 M€ associé à NPEX, mais un détail plus discret, enfoui dans la documentation de l’infrastructure de marché de Dusk : avant qu’un actif puisse bouger, un portefeuille doit être lié à un participant « Verified ». Pas un KYC effectué une fois puis oublié. Liaison par actif, comme condition de transfert opposable.
Je voulais vérifier ce que cela signifie concrètement sur le plan mécanique, parce que la tokenisation conforme est souvent évoquée de façon un peu vague.
Voici la séquence décrite par Dusk pour un onboarding de type NPEX : un émetteur définit des règles d’éligibilité pour l’actif. Les portefeuilles des investisseurs sont liés à des identifiants vérifiés. À partir de là, la couche du contrat de transfert applique qui est même autorisé à détenir ou à déplacer le token : la restriction se situe au niveau du règlement, pas dans une case à cocher d’une interface. Le règlement lie la jambe « actif » et la jambe « paiement » afin d’obtenir une finalité déterministe, de sorte que vous n’obtenez pas un état où les parts ont été déplacées mais pas le paiement.
Pourquoi c’est important : NPEX est un MTF néerlandais sous supervision de l’AFM. Il ne peut pas simplement pointer vers un ERC-20 public et dire que c’est un titre. Le contrôle d’éligibilité doit être opposable on-chain, pas seulement via l’interface sinon la partie « régulée » n’est qu’une mise en scène.
Le point que je voudrais vérifier et que je n’ai pas vu être entièrement spécifié : que se passe-t-il lorsque l’éligibilité change—un investisseur est-il dérégristré ou une règle de juridiction est mise à jour—pour des tokens déjà détenus ? Le lien est-il révoqué de façon rétroactive, ou ne bloque-t-il que les transferts futurs ?
C’est le test réel de savoir s’il s’agit d’un système d’actifs réellement régulé ou simplement d’un contrôle de conformité au moment de l’émission.
Le déplacement de 300 M€ par NPEX n’est qu’un point de données. Le fait que la logique de contrôle des transferts tienne face à un cas limite réglementaire en conditions réelles est ce qui déterminera si cela se généralise au reste du secteur.
Je suis sincèrement curieux de savoir comment Dusk gère le cas de révocation : quelqu’un a-t-il examiné de près la spécification Transfer contrôlée par Zedger/Hedger assez attentivement pour savoir ?
@Dusk_Foundation $DUSK #dusk