#dusk $DUSK @Dusk Hier soir, je suis allé vérifier selon quel mécanisme une valeur mobilière émise par Dusk est contrainte à la conformité. Je pensais au départ que cette partie devait se faire hors chaîne : probablement qu’un certain système d’enregistrement effectue une vérification des qualifications avant le transfert, comme le font la plupart des plateformes d’actifs tokenisés. Résultat : les règles ne sont pas du tout hors chaîne.
XSC, c’est-à-dire la norme des contrats de valeurs mobilières confidentielles de Dusk, permet à l’émetteur d’intégrer directement les conditions de conformité dans le token lui-même. Une valeur mobilière peut être programmée de façon à n’être transférable qu’entre porteurs éligibles, figurant sur une liste blanche. Ce contrôle s’effectue au niveau du protocole : il ne repose pas sur une procédure d’approbation ajoutée a posteriori. Les restrictions suivent l’actif, et non pas un système de base de données qui traque ailleurs qui a le droit de le détenir.
Ce n’est pas le mode d’échec que j’attendais. La plupart des propositions de tokenisation « conforme » que j’ai lues présentent en fait une faille : le token se transfère on-chain, mais la véritable vérification de l’éligibilité se fait dans un système hors chaîne que la chaîne ne peut pas vérifier. Si ce système tombe en panne, si les données expirent, ou s’il n’est simplement pas interrogé, rien on-chain ne peut empêcher ce transfert.
Un détail dans la conception a particulièrement attiré mon attention : cette norme doit aussi gérer le cas de clés privées perdues, tout en ne violant pas les obligations légales de l’émetteur. Si un actionnaire perd l’accès, le droit des valeurs mobilières stipule quand même qu’il ne perdra pas pour autant la propriété. XSC doit donner à l’émetteur assez de contrôle pour honorer ce point, mais ce contrôle ne doit pas non plus devenir une porte dérobée qui affaiblirait l’hypothèse même de « l’exécution contraignante on-chain ».
Ça me rappelle un immeuble : l’ascenseur valide la carte pour ouvrir, plutôt que de compter sur un gardien en bas qui serait éventuellement parti en pause.
Il faut dire clairement que je parle des objectifs de conception que cette norme prétend atteindre, et non de l’observation directe d’un registre réel des actionnaires heurtant des cas limites : dans la pratique, je n’ai vu aucun exemple concret sur ce qui se passe lorsque l’on perd réellement une clé ou lorsque la juridiction change sur des actifs réellement réglementés.
Je me pose encore la question : au niveau du token, imposer une vérification d’éligibilité, est-ce que cela comble vraiment la faille de conformité, ou est-ce que le problème a simplement été déplacé vers « qui a le droit de mettre à jour la règle intégrée dans le token, et avec quelle rapidité » ?
@Dusk $DUSK #dusk #BinanceSquareFamily
XSC, c’est-à-dire la norme des contrats de valeurs mobilières confidentielles de Dusk, permet à l’émetteur d’intégrer directement les conditions de conformité dans le token lui-même. Une valeur mobilière peut être programmée de façon à n’être transférable qu’entre porteurs éligibles, figurant sur une liste blanche. Ce contrôle s’effectue au niveau du protocole : il ne repose pas sur une procédure d’approbation ajoutée a posteriori. Les restrictions suivent l’actif, et non pas un système de base de données qui traque ailleurs qui a le droit de le détenir.
Ce n’est pas le mode d’échec que j’attendais. La plupart des propositions de tokenisation « conforme » que j’ai lues présentent en fait une faille : le token se transfère on-chain, mais la véritable vérification de l’éligibilité se fait dans un système hors chaîne que la chaîne ne peut pas vérifier. Si ce système tombe en panne, si les données expirent, ou s’il n’est simplement pas interrogé, rien on-chain ne peut empêcher ce transfert.
Un détail dans la conception a particulièrement attiré mon attention : cette norme doit aussi gérer le cas de clés privées perdues, tout en ne violant pas les obligations légales de l’émetteur. Si un actionnaire perd l’accès, le droit des valeurs mobilières stipule quand même qu’il ne perdra pas pour autant la propriété. XSC doit donner à l’émetteur assez de contrôle pour honorer ce point, mais ce contrôle ne doit pas non plus devenir une porte dérobée qui affaiblirait l’hypothèse même de « l’exécution contraignante on-chain ».
Ça me rappelle un immeuble : l’ascenseur valide la carte pour ouvrir, plutôt que de compter sur un gardien en bas qui serait éventuellement parti en pause.
Il faut dire clairement que je parle des objectifs de conception que cette norme prétend atteindre, et non de l’observation directe d’un registre réel des actionnaires heurtant des cas limites : dans la pratique, je n’ai vu aucun exemple concret sur ce qui se passe lorsque l’on perd réellement une clé ou lorsque la juridiction change sur des actifs réellement réglementés.
Je me pose encore la question : au niveau du token, imposer une vérification d’éligibilité, est-ce que cela comble vraiment la faille de conformité, ou est-ce que le problème a simplement été déplacé vers « qui a le droit de mettre à jour la règle intégrée dans le token, et avec quelle rapidité » ?
@Dusk $DUSK #dusk #BinanceSquareFamily
