#dusk $DUSK @Dusk

J’ai continué à revenir à un détail inconfortable après avoir fouillé dans la conception XSC de Dusk.

Le point intéressant n’est pas de publier le registre du capital d’une entreprise privée sur une chaîne. C’est ce qui se passe pour l’agent de transfert une fois que le registre lui-même devient programmable.

Noms, classes d’actions, restrictions de transfert, acheteurs éligibles : au lieu d’exposer toutes ces données de propriété sur un registre transparent et d’ajouter la conformité ensuite, XSC fait de la confidentialité une partie de l’actif. Des règles peuvent s’exécuter à l’intérieur du contrat, tandis que la visibilité est configurée selon les personnes qui ont réellement besoin de voir quoi.

J’ai parcouru le testnet et, honnêtement, c’est ce qui m’a marqué. On avait l’impression que ce n’était pas tant de la crypto que de la configuration d’autorisations dans une feuille de calcul. Pour les valeurs mobilières, ce type d’UX plutôt ennuyeuse pourrait en fait être une fonctionnalité.

Puis est venu le compromis.

Si le contrat devient le registre, la gestion des clés fait discrètement partie du système de tenue des registres. Perdre une clé critique ne met pas seulement l’accès aux actifs en danger : vous pourriez aussi perdre l’accès à l’historique nécessaire pour établir la propriété et la conformité.

Un registraire traditionnel a des procédures pour cela.
Le code ne supprime pas le problème. Il peut simplement le déplacer.

Alors je me demande : XSC remplace-t-il vraiment l’agent de transfert, ou réduit-il le travail à la gestion des exceptions humaines que les smart contracts ne peuvent pas ?

@Dusk #dusk $DUSK

XSC peut-il remplacer l’agent de transfert ?