#dusk $DUSK @Dusk
Je fouillais dans la documentation de Dusk pour comprendre ce que signifie réellement, au niveau du protocole, « la confidentialité par défaut, l’auditabilité quand c’est nécessaire », parce que cette formule apparaît partout dans leurs supports RWA et que je voulais savoir qui fait l’audit.
En fin de compte, la norme XSC intègre des clés de consultation optionnelles liées à la couche de conformité — ainsi, lorsqu’un security token est émis via XSC, l’émetteur (ou un régulateur désigné) peut détenir une clé capable de déchiffrer des détails de transaction qui restent invisibles pour tout le monde sur la chaîne. Je suis retourné deux fois dans la documentation parce que je l’avais d’abord lue comme une confidentialité de bout en bout totale, du type qu’on obtient avec une transaction chiffrée « shielded » classique. Ce n’est pas exactement ça. Il s’agit d’une confidentialité vis-à-vis du public, pas nécessairement vis-à-vis du contrepartiste qui applique les règles de conformité.
Ce n’est pas un défaut, c’est le but même : on ne peut pas avoir un security token conforme à la MiFID ou à la MiCA sans qu’il existe quelqu’un capable de prouver, à la demande, la détention et la circulation des fonds. Mais cela signifie que la garantie de confidentialité est, par conception, asymétrique, et je ne pense pas que ce soit évident pour quelqu’un qui lit « confidentiel » sur la page d’accueil et suppose une anonymité symétrique, comme avec une crypto-monnaie de confidentialité.
L’incitation que cela crée est intéressante : les émetteurs se sentent à l’aise pour placer de véritables titres sur une chaîne publique précisément parce qu’ils conservent de la visibilité. Les utilisateurs obtiennent de la confidentialité vis-à-vis des inconnus, pas vis-à-vis du système qui les gère. Ça vaut le coup de se demander combien de détenteurs savent réellement qui détient cette clé pour un actif donné.
Je fouillais dans la documentation de Dusk pour comprendre ce que signifie réellement, au niveau du protocole, « la confidentialité par défaut, l’auditabilité quand c’est nécessaire », parce que cette formule apparaît partout dans leurs supports RWA et que je voulais savoir qui fait l’audit.
En fin de compte, la norme XSC intègre des clés de consultation optionnelles liées à la couche de conformité — ainsi, lorsqu’un security token est émis via XSC, l’émetteur (ou un régulateur désigné) peut détenir une clé capable de déchiffrer des détails de transaction qui restent invisibles pour tout le monde sur la chaîne. Je suis retourné deux fois dans la documentation parce que je l’avais d’abord lue comme une confidentialité de bout en bout totale, du type qu’on obtient avec une transaction chiffrée « shielded » classique. Ce n’est pas exactement ça. Il s’agit d’une confidentialité vis-à-vis du public, pas nécessairement vis-à-vis du contrepartiste qui applique les règles de conformité.
Ce n’est pas un défaut, c’est le but même : on ne peut pas avoir un security token conforme à la MiFID ou à la MiCA sans qu’il existe quelqu’un capable de prouver, à la demande, la détention et la circulation des fonds. Mais cela signifie que la garantie de confidentialité est, par conception, asymétrique, et je ne pense pas que ce soit évident pour quelqu’un qui lit « confidentiel » sur la page d’accueil et suppose une anonymité symétrique, comme avec une crypto-monnaie de confidentialité.
L’incitation que cela crée est intéressante : les émetteurs se sentent à l’aise pour placer de véritables titres sur une chaîne publique précisément parce qu’ils conservent de la visibilité. Les utilisateurs obtiennent de la confidentialité vis-à-vis des inconnus, pas vis-à-vis du système qui les gère. Ça vaut le coup de se demander combien de détenteurs savent réellement qui détient cette clé pour un actif donné.
