Qu'est-ce que les tokens de sécurité et la conformité par code sur les marchés de la cryptographie ?
Les jetons de sécurité sont des représentations sur blockchain de titres réglementés, donc leur propriété et leur transfert doivent suivre les mêmes contraintes légales que les instruments traditionnels.
Le "conformité par code" est le modèle de conception où ces contraintes sont appliquées de manière déterministe au moment où une action de jeton se produit, en utilisant des vérifications de contrats intelligents, des données d'identité et des contrôles administratifs.
Points clés
- Un jeton de sécurité représente un titre ou un contrat d'investissement et est soumis aux mêmes règles que les instruments financiers traditionnels en vertu des lois fédérales américaines sur les valeurs mobilières.
- Conformité par codeLes systèmes crypto appliquent des décisions d'autorisation ou de refus au moment de la création, du transfert, de la destruction ou de l'approbation, renvoyant souvent des codes d'état standardisés au lieu d'étiquettes vagues "KYC'd".
- Les normes de restriction au niveau des jetons se concentrent sur les vérifications programmables et les contrôles administratifs comme le gel et la révocation, tandis que les autorisations au niveau de la chaîne ou du compte déterminent qui peut même toucher au règlement.
- Les propositions d'interopérabilité poussent la conformité vers des objets d'identité et de données portables afin que le même "actif" réglementé puisse être exposé à travers plusieurs interfaces sans perdre la transparence des restrictions.Les jetons de sécurité et la conformité par codeLes actifs réglementés ne deviennent pas "moins réglementés" parce que le tableau des capitaux est un "contrat intelligent".
- Le document d'architecture déposé par Prometheum auprès de la SEC précise que les valeurs mobilières sur blockchain représentent un titre ou un contrat d'investissement et restent soumis aux mêmes règles et réglementations que les instruments financiers traditionnels aux États-Unis, ce qui signifie que les lois fédérales sur les valeurs mobilières s'appliquent toujours.
- Ce cadre est le point de départ pour expliquer les jetons de sécurité : le jeton est un emballage autour d'un cycle de vie réglementé, pas un laissez-passer gratuit autour de celui-ci.
La conformité par code est mieux comprise comme un moteur de risque de lieu. Chaque action qui change la propriété ou le contrôle est forcée à passer par une porte qui renvoie une décision d'autorisation ou de refus, idéalement avec une raison lisible par machine. Le choix de conception qui compte est l'endroit où cette porte se trouve : à l'intérieur du contrat de jeton, à l'intérieur des objets de données d'identité et de conformité partagés, ou à l'intérieur d'un environnement de règlement autorisé qui n'admet que des comptes approuvés.
C'est pourquoi "jetons de sécurité contre jetons d'utilité" n'est pas un débat cosmétique sur les métadonnées. Un jeton d'utilité peut souvent traiter le transfert comme un droit par défaut. Un jeton de sécurité ne peut généralement pas le faire, car l'éligibilité, la juridiction et le statut légal peuvent changer au fil du temps.
C'est aussi pourquoi les discussions sur la "tokenisation" qui restent au niveau marketing manquent le point opérationnel. Quiconque cherche ce qu'est la tokenisation cherche généralement les mécanismes pour transformer une réclamation légale en état programmable.
Les jetons de sécurité sont le cas où cet état doit être défendable devant un régulateur et fonctionnel pour des intermédiaires comme un "agent de transfert".Comment fonctionnent les restrictions de transfert en chaîneL'ERC-1462 traite la conformité comme un précontrôle déterministe qui s'exécute avant que le jeton ne fasse quoi que ce soit d'irréversible.
Il ajoute des fonctions de vérification explicites pour les actions clés qui comptent : checkTransferAllowed, checkTransferFromAllowed, checkMintAllowed et checkBurnAllowed. Les méthodes ERC-20 du jeton sont censées consulter ces vérifications en remplaçant transfer, transferFrom et approve, puis appliquer le résultat.
Le détail important est que l'ERC-1462 ne réduit pas la décision à un booléen. Les fonctions de vérification renvoient des codes d'état standardisés via l'ERC-1066, avec 0x11 signifiant Autorisé et 0x10 signifiant Non autorisé, plus de la place pour des codes spécifiques à l'émetteur. Cela semble être une délicatesse pour les développeurs jusqu'à ce que cela touche un flux de travail utilisateur.
Un système de portefeuille, de courtier ou d'agent de transfert peut faire surface "non autorisé car KYC manquant" contre "non autorisé car bloc de juridiction" contre "échec hors chaîne", au lieu d'un retour générique qui force des tickets de support et un tri manuel.
L'ERC-1462 fait également place à la partie désordonnée que les marchés réglementés ont toujours : les litiges et la documentation. L'EIP nomme KYC et AML comme exigences et inclut explicitement la capacité de verrouiller des jetons pour un compte et de restreindre les transferts en raison d'un litige légal.
Il définit également des crochets de documents optionnels, attachDocument et lookupDocument, qui font référence à des documents légaux hors chaîne par URI et hachage de contenu.
C'est la posture de conformité par code dans sa forme la plus honnête : application en chaîne plus un pont délibéré vers la réalité légale hors chaîne.Contrôles de conformité courants dans les normes de jetonsL'ERC-1404 est une norme de jeton restreint construite autour des contrôles que les émetteurs et les lieux continuent de demander lorsqu'ils essaient de gérer des flux réglementés sur des rails publics.
Le site souligne la nécessité de connaître les détenteurs de jetons et de maintenir une liste blanche d'adresses d'investisseurs, ce qui est le sens opérationnel derrière un "jeton de liste blanche" et l'idée plus large d'un "jeton autorisé".
Il mentionne également des restrictions complexes qui apparaissent dans les feuilles de conditions et les mémos de conseil, comme le blocage des transferts entre des juridictions spécifiques et l'application de limites maximales de propriété.La partie la plus révélatrice est l'outil administratif. L'ERC-1404 énumère les fonctionnalités couramment mises en œuvre, y compris la capacité de geler un jeton, de révoquer et de réaffecter, de créer plusieurs listes et d'approuver ou de rejeter une transaction. Ce ne sont pas des cas marginaux. Ce sont des leviers de remédiation. Si un transfert est ultérieurement trouvé en violation d'une restriction, ou si une "adresse" devient sanctionnée, ou si un ordre du tribunal arrive, un jeton de sécurité de qualité production a besoin d'un moyen d'arrêter, de défaire ou de réécrire l'état.L'ERC-1404 décrit également la séparation des rôles, avec des exemples comme Propriétaire ou Émetteur, un Administrateur qui peut être un agent de transfert ou un lieu de négociation, et un rôle d'Investisseur qui peut envoyer et recevoir. Ce modèle de rôle est là où "la conformité par code" cesse d'être un slogan et devient un système d'exploitation. Quelqu'un doit être autorisé à geler, révoquer et réaffecter, et le contrat de jeton devient le point d'application pour ces permissions.C'est aussi là que les normes de jetons de sécurité divergent en philosophie. L'ERC-1462 plaide pour une base étroite que les émetteurs étendent avec leur propre logique. L'ERC-1404 penche vers un ensemble d'outils restreints plus complet. Les deux essaient de résoudre le même problème au niveau de l'écran : lorsque l'utilisateur clique sur envoyer, le jeton se règle ou non, et le système doit expliquer pourquoi.Identité, garde et flux de travail réglementés
Un contrat de jeton peut bloquer les transferts, mais il ne peut pas intégrer un humain. C'est pourquoi la conformité par code s'étend souvent à l'identité, à la garde et aux flux de travail de lieu qui entourent le jeton. L'architecture de Prometheum est un exemple clair de permissions au niveau de la chaîne ou du compte : elle décrit un modèle de chaîne de base et d'utilité séparé, avec des activités réglementées sur une chaîne de base utilisant un modèle de comptes autorisés et une disponibilité en modèle ouvert sur la chaîne d'utilité.
Le mécanisme de filtrage n'est pas subtil. Prometheum déclare que les parties interagissant avec sa chaîne de base doivent être capables de créer un compte avec un courtier-négociant et de passer les exigences de diligence raisonnable et de KYC/AML. C'est le KYC en chaîne comme choix de conception système, pas juste une case à cocher.
Cela pousse l'application "à gauche", donc l'environnement de règlement lui-même est autorisé avant même qu'un transfert de jeton ne soit tenté.Prometheum définit également un Jeton de Sécurité Intelligent comme un titre enregistré aux États-Unis qui peut également être utilisé comme un jeton dans des applications distribuées sur blockchain, et elle décrit des mécanismes pour déplacer ces jetons entre des portefeuilles "Maître" et "Personnel". Le point est la garde et la tenue de dossiers. L'architecture décrit des Portefeuilles Maîtres utilisés par des sociétés de compensation pour la comptabilité sur la chaîne de base et des Portefeuilles Personnels qui se comportent davantage comme des portefeuilles de chaîne publique sur la chaîne d'utilité. Les services d'agent de transfert sont décrits comme maintenant un dossier complet de propriété en combinant des données de blockchain publique avec des données de titulaires de compte privés provenant de courtiers-négociants.Voici la comparaison clé : les vérifications au niveau des jetons essaient de rendre l'actif portable à travers les environnements, tandis que les environnements de règlement autorisés essaient de faire de l'environnement lui-même le périmètre de conformité. Les deux peuvent produire une expérience de jeton autorisé. Ils mettent juste la porte à des endroits différents.
Interopérabilité et couches de données évolutives
Le travail d'interopérabilité essaie d'empêcher chaque émetteur de réinventer la même pile de conformité à l'intérieur de chaque contrat de jeton.
L'annexe d'interopérabilité EIP-7208 décrit l'ERC-1400 comme fournissant des interfaces pour émettre et racheter des jetons de sécurité, gérer les restrictions de propriété et de transfert, et donner aux détenteurs de jetons de la transparence sur la façon dont des sous-ensembles de soldes se comportent par rapport aux restrictions, droits et obligations.
Cette "transparence des sous-ensembles" est importante car les jetons réglementés ont souvent des tranches, des verrouillages ou des contraintes spécifiques à une catégorie qu'un seul numéro de solde ne peut pas exprimer.
La même annexe soutient que les objets de données peuvent stocker et modifier des données en chaîne pour les jetons de sécurité, telles que des informations de conformité ou des détails de propriété, et que la logique de gestion d'identité personnalisée peut être intégrée lors de l'intégration avec les normes de jetons de sécurité. C'est le changement architectural : au lieu de coder chaque règle dans un seul contrat de jeton, l'état de conformité et la logique d'identité peuvent vivre dans une couche de données partagée que plusieurs interfaces peuvent lire.
C'est là que l'erc 3643 et l'erc 1400 apparaissent comme des cibles d'intégration pratiques. L'annexe mentionne explicitement l'emballage des actifs émis sous l'ERC-1400 dans un objet de données de coffre et leur exposition à travers des interfaces de gestion de données, y compris l'ERC-3643.
Elle affirme également que la séparation du stockage permet de nouvelles fonctionnalités qui ne faisaient pas partie de l'interface originale, y compris le contrôle d'accès basé sur les rôles et la récupération basée sur l'identité.
Pour les constructeurs, c'est le pont vers les conversations "erc 3643 contre erc 1400 expliquées" : l'interface qu'un lieu veut et l'état de conformité dont un émetteur a besoin n'ont pas à être soudés ensemble pour toujours.La même direction apparaît dans les primitives d'identité utilisées par les piles de jetons autorisés, telles que onchainid, où l'identité et les réclamations peuvent être référencées en chaîne pour soutenir la logique d'éligibilité. L'objectif commun est la composabilité sans perdre la clarté des restrictions, afin que les portefeuilles et les lieux puissent prédire si un transfert sera validé avant de le soumettre.Limites et compromis de la conformité codéeLe premier compromis est le déterminisme contre la discrétion. L'ERC-1462 permet la logique définie par l'émetteur à l'intérieur des fonctions de vérification et permet même des requêtes hors chaîne via un oracle. Cela signifie que "la conformité par code" peut encore dépendre de la vérification d'identité hors chaîne, du filtrage des sanctions et des déterminations légales. Le code peut appliquer la décision au moment de l'action, mais il ne peut pas éliminer le besoin d'un processus légal qui décide ce que la politique devrait être.Le deuxième compromis est la portabilité contre le contrôle du périmètre. Les restrictions au niveau des tokens, comme les vérifications de style ERC-1462 ou les transferts restreints de style ERC-1404, maximisent les chances qu'un token de sécurité puisse se déplacer entre portefeuilles et lieux tout en portant son règlement avec lui. Les permissions au niveau de la chaîne ou du compte, comme le modèle de chaîne Core de Prometheum, maximisent le contrôle en restreignant qui peut même participer à un règlement réglementé. Cela ressemble davantage à la plomberie traditionnelle des marchés, mais cela réduit la composabilité ouverte car l'environnement n'est pas sans permission.
Le troisième compromis est l'expérience utilisateur en cas d'échec. Un revert est un instrument brutal. L'approche par code d'état d'ERC-1462 via ERC-1066 est une tentative directe de rendre les échecs lisibles afin qu'un utilisateur puisse corriger la bonne chose, que ce soit un KYC manquant, un blocage de juridiction ou un échec hors chaîne.
Les systèmes qui n'implémentent qu'une vérification de token sur liste blanche sans codes de raison tendent à transférer le coût vers le support et la gestion manuelle des exceptions.Enfin, la conformité codée crée un pouvoir administratif qui doit être gouverné. Le gel, la révocation et la réaffectation d'ERC-1404, les permissions multi-listes et les contrôles d'approbation ou de rejet sont conçus pour une remédiation réglementée. Ils signifient également que l'émetteur ou l'administrateur peut intervenir dans les soldes. Ce n'est pas un bug dans les marchés réglementés, mais c'est une contrainte de conception qui doit être explicite dans les divulgations et dans la façon dont les intégrations traitent l'actif.La prise
J'ai vu des équipes présenter un token de sécurité comme "ERC-20 plus KYC" et ensuite être surprises par le premier jour opérationnel difficile : un transfert contesté, un changement de juridiction ou un lieu demandant un code de raison clair au lieu d'un revert générique.
L'insistance d'ERC-1462 sur des fonctions de vérification explicites et des codes d'état ERC-1066 est la chose la plus proche dans cette pile d'un moteur de risque de niveau lieu. Si le système ne peut pas expliquer pourquoi il a bloqué un transfert, il n'est pas prêt pour un flux réglementé.
Le modèle mental le plus clair est de choisir l'emplacement de la porte tôt et d'assumer les conséquences. Les vérifications au niveau des tokens gardent l'actif portable. Les permissions au niveau de la chaîne ou du compte, comme la chaîne Core de Prometheum, gardent le périmètre étroit.
L'erreur coûteuse est de mélanger les deux sans une source de vérité claire pour l'identité et les restrictions, puis de découvrir que chaque portefeuille et intégration voit une version différente de "autorisé".
Sources
Propositions d'Amélioration d'Ethereum
ERC-1404
Commission des valeurs mobilières et des échanges des États-Unis
Propositions d'Amélioration d'Ethereum
Frequently Asked Questions
Les tokens de sécurité sont-ils toujours soumis à la législation sur les valeurs mobilières s'ils sont sur une blockchain ?
Oui. Le document d'architecture déposé par Prometheum auprès de la SEC indique que les tokens représentant un titre ou un contrat d'investissement sont soumis aux mêmes règles et réglementations que les instruments financiers traditionnels aux États-Unis, ce qui signifie que les lois fédérales sur les valeurs mobilières s'appliquent.
Comment la conformité par code crypto bloque-t-elle réellement un transfert ?
Des normes comme l'ERC-1462 ajoutent des fonctions de vérification qui sont consultées par transfer, transferFrom, mint, burn et approve. La vérification renvoie un code d'état standardisé via l'ERC-1066, et le token est censé revenir en arrière lorsque l'action est interdite.
Qu'est-ce qu'un token de liste blanche et pourquoi les tokens de sécurité utilisent-ils des listes blanches ?
Un token de liste blanche utilise une liste d'adresses d'investisseurs approuvées qui sont autorisées à détenir ou à recevoir l'actif. L'ERC-1404 met en avant la liste blanche comme un moyen de suivre les détenteurs de tokens et d'appliquer des contraintes d'éligibilité telles que des politiques réservées aux accrédités ou des vérifications de sanctions.
Quels contrôles administratifs les tokens autorisés ont-ils généralement besoin ?
L'ERC-1404 énumère les contrôles couramment mis en œuvre, y compris le gel, la révocation et la réaffectation, la création de plusieurs listes, et l'approbation ou le rejet d'une transaction. Ces contrôles existent pour soutenir les exigences de remédiation et opérationnelles dans les marchés réglementés.
Quelle est la différence entre les restrictions au niveau des tokens et une chaîne de règlement autorisée ?
Les modèles de restriction au niveau des tokens intègrent des vérifications à l'intérieur du contrat de token, de sorte que le token porte son règlement partout où il va. Les modèles de règlement autorisés contrôlent l'accès au niveau du compte ou de la chaîne, comme la chaîne Core de Prometheum où les participants doivent s'enregistrer auprès d'un courtier et passer des vérifications AML/KYC avant d'interagir avec des transferts réglementés.
