Rédigé par : @JayLovesPotato, Four Pillars
Compilé par : AididiaoJP, Foresight News
Points clés
Les standards de jetons réglementés sur l'EVM ne convergent pas vers une norme unique, mais se répartissent clairement selon les fonctionnalités. Ainsi, l'ERC-1450, l'ERC-3643 et l'ERC-7943 ne doivent pas être considérés comme des standards concurrents, mais plutôt comme des composants complémentaires respectivement responsables de l'émission, de l'identité, de l'exécution et de l'intégration.
Note : En termes simples, un standard de jeton réglementé est un ensemble de spécifications techniques conçues pour les « jetons soumis à une régulation ». Les jetons ordinaires (comme un ERC-20 standard) peuvent être transférés et détenus librement, avec peu de restrictions. En revanche, un jeton réglementé (Regulated Token) correspond généralement à des actifs réels soumis à une régulation financière comme des titres, des parts de fonds, des obligations, des RWA (actifs du monde réel), etc. Il transforme le jeton, passant de « transférable par n'importe qui » à une technologie respectant les exigences réglementaires.
Les différences clés entre les blockchains ne résident pas dans la présence ou l'absence de fonctionnalités de régulation, mais dans l'endroit où ces fonctionnalités sont implémentées et exécutées. L'EVM conserve une grande flexibilité au niveau du contrat d'actif individuel ; Solana et les blockchains basées sur Move placent davantage de fonctionnalités dans des cadres de jetons partagés ; Stellar et XRPL les intègrent directement au registre ; Canton et Avalanche L1 étendent même cette logique aux couches de marché et d'exploitation du réseau.
La compétitivité future des standards de jetons réglementés dépendra probablement davantage de leur capacité à s'adapter aux changements réglementaires que du nombre de leurs fonctionnalités. Une approche plus pragmatique consiste à construire une pile de conformité : standardiser les fonctions d'exécution récurrentes comme le gel, le transfert forcé, la validation préalable au transfert, tout en décomposant les politiques spécifiques aux produits (comme les fournisseurs d'identité, les règles des juridictions, les plafonds de détention) en modules remplaçables.
Même dans l'environnement EVM d'Ethereum, le plus familier aux institutions, plusieurs ERC répondent à des besoins similaires pour les jetons réglementés. Ils prennent généralement en charge les restrictions de transfert, les vérifications d'éligibilité des investisseurs, le gel, le transfert forcé et la récupération d'actifs perdus. Cependant, les structures juridiques et les permissions opérationnelles qu'ils supposent diffèrent de manière significative.
En dehors de l'EVM, d'autres blockchains ont également intégré des fonctionnalités comparables au niveau des programmes de jetons, du registre ou du réseau, élargissant ainsi les voies de réalisation des actifs réglementés.
Cela reflète en partie l'absence de structure claire pour les standards de jetons réglementés. La raison fondamentale est que les fonctionnalités requises pour les actifs réglementés sont difficiles à intégrer dans une seule spécification. Qui maintient le registre juridique des titres ? Quelle institution certifie l'éligibilité des investisseurs ? Quel degré de contrôle l'opérateur doit-il conserver en cas d'incident ? Ces questions varient selon les produits et les juridictions.
Ainsi, le marché évolue vers une architecture où ces fonctionnalités sont réparties sur plusieurs couches et combinées selon les besoins, plutôt que de chercher un standard unique et autosuffisant.
Les standards de jetons réglementés sur l'EVM
Les premiers standards tentaient souvent de copier directement les structures opérationnelles de la finance traditionnelle dans le contrat de jeton. Sous l'ERC-1450, l'agent de transfert enregistré (Registered Transfer Agent) est non seulement responsable de l'émission et du rachat, mais aussi de l'exécution de chaque transfert, les utilisateurs ordinaires étant interdits d'appeler les fonctions `transfer` et `approve`. Cela clarifie qui maintient le registre légal et qui est responsable de répondre aux injonctions judiciaires ou à la perte de clés. Cependant, cela s'éloigne également de l'hypothèse de fluidité sans permission des actifs sous-jacente aux DEX et protocoles de prêt traditionnels.
L'ERC-3643, quant à lui, répartit les fonctions de régulation entre le contrat de jeton, un registre d'identité (Identity Registry), un registre des émetteurs de confiance (Trusted Issuers Registry) et des modules de conformité indépendants, plutôt que de les centraliser sous une autorité unique. Les transferts sont validés par rapport à des attestations émises par des entités de confiance, incluant l'état KYC, la résidence et l'éligibilité d'investisseur ; les émetteurs peuvent également ajouter des règles comme le nombre d'investisseurs ou des plafonds de détention nationaux. Conserver la structure ERC-20 de base tout en permettant le remplacement de règles individuelles constitue un avantage significatif. Le prix à payer est la charge opérationnelle liée à la coordination de multiples contrats, émetteurs d'identité et rôles de gestion des privilèges.
L'ERC-7943, plus récent, adopte une approche différente : il ne définit pas la politique de régulation elle-même, mais expose un ensemble d'interfaces génériques, incluant `canSend`, `canReceive`, `canTransfer`, des fonctions de requête des soldes gelés et de transfert forcé. Cela permet aux portefeuilles, exchanges, dépositaires et services DeFi d'interagir de manière cohérente avec différents actifs réglementés. En d'autres termes, l'ERC-3643 est une pile pour créer des jetons réglementés, tandis que l'ERC-7943 se rapproche davantage d'une couche d'intégration reliant plusieurs piles. L'ajout récent du support de l'ERC-7943 par l'implémentation CMTAT illustre davantage comment cette interface minimale peut se superposer à des standards d'émission existants.
L'ERC-7518 et l'ERC-8047 répondent à des besoins plus spécifiques. L'ERC-7518 applique différentes catégories d'actions, juridictions et conditions de période de blocage à une partition unique d'ERC-1155 ; l'ERC-8047 enregistre la lignée parent-enfant lors des mouvements d'actifs, permettant une exécution ciblée sur des flux de fonds spécifiques plutôt que sur l'ensemble d'un compte. Le premier permet une distinction plus claire des droits au sein d'un même actif ; le second permet un suivi et une exécution plus précis a posteriori. Ils sont plus susceptibles de servir de modules complétant une pile de conformité plus large, plutôt que de remplacer un standard universel comme l'ERC-3643.
Où les autres blockchains placent-elles les fonctions de régulation ?
L'approche de Solana se caractérise par le placement de fonctionnalités récurrentes pour les jetons dans une couche partagée plus bas niveau. Des fonctions comme les Transfer Hooks, le Délégué Permanent (Permanent Delegate) et le Transfert Confidentiel (Confidential Transfer) sont fournies via la bibliothèque générique Token Extensions, tandis que le Solana Attestation Service permet aux applications de réutiliser des informations hors chaîne, comme l'état KYC, la géolocalisation et l'éligibilité des investisseurs. Cela réduit le besoin pour chaque émetteur de reconstruire et d'auditer indépendamment les mêmes fonctionnalités. Cependant, l'intégration peut encore être fragmentée lorsqu'un portefeuille ou un protocole ne supporte pas une extension donnée ; de plus, pour les actifs configurés avec des contrôles d'émetteur puissants comme le Permanent Delegate, les applications DeFi doivent les considérer comme une couche supplémentaire de risque de contrepartie.
Stellar et XRPL exposent l'autorisation, le gel et la récupération comme des attributs natifs des actifs du registre. Ces contrôles s'appliquent de manière cohérente dans les transferts et les fonctions de transaction natives, évitant aux applications de réinterpréter une logique personnalisée pour chaque contrat de jeton. Stellar étend la connexion entre les actifs du registre et l'environnement des smart contracts via les Stellar Asset Contracts ; XRPL s'appuie sur le MPT, évoluant des fonctionnalités de détention sous permission, de gel et de récupération vers des fonctionnalités liées à la confidentialité. Cependant, plus les règles sont intégrées profondément dans le registre, plus leur évolution dépend des mises à niveau du réseau et du consensus. Les paramètres de contrôle peuvent également contraindre plus directement la liquidité et l'utilisation des actifs.
Sui et Aptos se situent entre le modèle centré sur les contrats de l'EVM et le modèle natif du registre. Sui enregistre l'état de liste de refus des actifs réglementés et les autorisations de suspension globale dans un Currency Registry ; Aptos utilise le TransferRef du cadre Fungible Asset pour geler des comptes, ou contourne ces restrictions via des transferts privilégiés si nécessaire. Les fonctions d'exécution récurrentes comme le blocage d'adresses ou la suspension d'urgence sont fournies par le cadre ; les politiques plus complexes, comme la classification des investisseurs ou les plafonds de détention spécifiques à un pays, sont laissées à des modules Move indépendants. À cet égard, leur architecture se rapproche le plus de la direction modulaire que l'écosystème EVM lui-même prend.
Canton étend le champ de la régulation du jeton à l'exploitation de l'ensemble du marché. Le CIP-56 normalise non seulement le transfert de soldes, mais aussi la divulgation d'informations à des parties spécifiques, l'approbation du destinataire et le règlement-livraison atomique (DvP) ; le Token Standard V2 est en test sur un DevNet indépendant prévu pour 2026. Cette conception offre une plus grande cohérence opérationnelle et une confidentialité renforcée, mais nécessite également un environnement d'identité et de développement dédié. Par conséquent, la liquidité et les applications des blockchains publiques existantes ne peuvent pas y être migrées simplement.
Avalanche L1 est mieux comprise comme une option pour construire le marché réglementé lui-même, et pas seulement pour émettre des jetons réglementés. Les opérateurs peuvent utiliser des listes blanches pour limiter les participants aux transactions et les déployeurs de contrats, tout en exigeant que les validateurs satisfassent à des conditions de KYC, AML ou de licence. Cette pile peut également connecter des fournisseurs d'identité comme Jumio et Keyring au txAllowlist, ce qui est très adapté aux exchanges ou réseaux de paiement réservés aux institutions. Le coût est opérationnel : les validateurs, les mises à niveau, les ponts inter-chaînes et la liquidité doivent être gérés indépendamment, avec des coûts et un degré de fragmentation bien supérieurs à l'émission d'un seul jeton sur un réseau EVM existant.
Séparer les fonctions d'exécution génériques des politiques de régulation
Globalement, ces différentes approches montrent que les deux extrêmes ont des limites évidentes : qu'il s'agisse d'intégrer toute la pile de régulation dans le réseau, ou de laisser toutes les fonctions à un seul ERC. Les fonctions d'exécution génériques qui reviennent systématiquement pour la plupart des actifs réglementés – validation préalable au transfert, gel, transfert forcé, suspension d'urgence, ainsi que les métadonnées décrivant les autorités de gestion et leurs risques associés – sont mieux placées près du cadre des jetons, du registre, ou d'une interface minimale comme l'ERC-7943. Cela réduit les différences d'implémentation et les coûts d'audit entre émetteurs, tout en permettant aux portefeuilles, exchanges et dépositaires d'identifier de manière cohérente la structure de contrôle d'un actif.
En revanche, la décision de savoir à quels fournisseurs d'identité faire confiance, quelles juridictions autoriser, comment calculer les plafonds de détention et les périodes de blocage par niveau d'investisseur, ou qui peut exécuter un ordre légal – ces choix sont mieux laissés à des ERC spécifiques à l'actif ou à des modules indépendants. Ces règles varient selon les produits et les juridictions, et doivent évoluer avec les changements législatifs. Les coder en dur dans les règles de base du réseau ralentirait non seulement les mises à niveau, mais pourrait aussi transformer les choix politiques de marchés financiers spécifiques en paramètres par défaut d'une blockchain générique.
En d'autres termes, le marché des jetons réglementés est plus susceptible d'évoluer sous la forme d'une pile de conformité, plutôt que de converger vers un standard unique. Dans ce modèle, des règles remplaçables concernant l'identité, la juridiction et des aspects spécifiques au produit seraient construites sur des fonctions d'exécution génériques. L'écosystème Ethereum et plus largement EVM conserve des avantages en termes de flexibilité politique et d'accès à la liquidité existante ; les blockchains à registre natif sont plus fortes en cohérence d'exécution et simplicité opérationnelle ; et des réseaux dédiés comme Canton se distinguent le plus en matière de confidentialité et de flux de travail institutionnels.
Par conséquent, le taux d'adoption ne sera probablement pas déterminé par la longueur de la liste de fonctionnalités d'un standard. Ce qui importe davantage, c'est la capacité de la politique de régulation à évoluer sans nécessiter la réémission de l'actif ni forcer les portefeuilles, exchanges et dépositaires à reconstruire leur intégration à partir de zéro. Un autre test clé est : les participants externes peuvent-ils clairement identifier, évaluer et gérer les contrôles puissants intégrés dans l'actif ?
