ERC-3643 vs ERC-1400 vs CMTAT : standards de security token

Une banque m'a appelé l'an dernier avec une question qui paraissait simple. Elle avait choisi un prestataire de tokenisation, le prestataire avait choisi un standard de token, et son équipe conformité voulait savoir si c'était le bon choix. Ce n'était pas une question de code. C'était une question à cinq ans déguisée en question de code.

Voici donc la comparaison honnête des trois standards qui reviennent vraiment : ERC-3643, ERC-1400 et CMTAT. Je suis l'un des auteurs nommés d'ERC-3643, alors lisez-moi comme biaisé et informé, pas neutre. Je serai juste envers les deux autres, car prétendre qu'ils n'ont aucune place, c'est perdre le débat face à un bon ingénieur.

Y arriver fut un combat de plusieurs années ; j'ai détaillé comment faire accepter un standard Ethereum dans le premier épisode.

La décision dont personne ne vous parle

Un standard de security token n'est pas une bibliothèque qu'on remplace au sprint suivant. Il décide qui peut détenir l'actif, comment un régulateur impose un gel, et ce que vos auditeurs doivent comprendre pendant toute la vie de l'instrument. Trompez-vous et vous migrez une table de capitalisation en production, ce qui est aussi amusant que ça en a l'air.

ERC-3643, ERC-1400 et CMTAT : de quoi parle-t-on ?

Les trois permettent d'émettre un security token sur une chaîne EVM. Ils divergent sur la seule chose qui compte pour un actif régulé : comment le token décide si un transfert est autorisé.

Le vrai choix : où vit la conformité ?

Oubliez les listes de fonctionnalités un instant. Les trois standards posent la même question à chaque transfert. Ils y répondent simplement à des endroits différents.

Ce seul choix entraîne tout le reste : quelles données doivent exister on-chain, ce qu'un régulateur doit croire, la difficulté d'un gel, et tout ce que votre contrat de token doit savoir du monde extérieur. Les standards diffèrent sur l'emplacement de la réponse, pas sur la difficulté de la question.

ERC-3643 : l'identité est toute la thèse

ERC-3643 fait un pari : le token lui-même doit refuser un transfert inéligible. Pas un wrapper, pas une barrière hors chaîne qu'on peut oublier d'appeler. La fonction de transfert demande à un registre d'identité si le destinataire détient les attestations exigées par ce token, et annule sinon. La conformité n'est pas ajoutée ; elle est le chemin du transfert.

Les attestations vivent dans un contrat d'identité on-chain (dans le design T-REX, OnchainID), signées par des émetteurs de confiance. Votre passeport ne touche jamais la chaîne. La chaîne voit seulement qu'un émetteur que vous approuvez a attesté « cette adresse peut détenir cette classe d'actif ». C'est la partie élégante, et c'est pourquoi le modèle a gagné son adoption.

Le coût est honnête et mérite d'être dit clairement. Vous faites désormais tourner un système d'identité. Quelqu'un doit émettre les attestations, les renouveler, les révoquer et être disponible quand un investisseur s'inscrit. Pour un instrument permissionné surveillé par un régulateur, cette mécanique est le sujet. Pour un token que vous vouliez simple, c'est une charge que vous regretterez.

Si vous voulez l'interface réelle et son statut Final, la référence ERC-3643 (T-REX) la présente.

ERC-1400 : les tranches, et quand elles gagnent

ERC-1400 n'est pas un ERC-3643 en moins bien. C'est une autre idée. Il dit qu'un titre est rarement un solde plat unique. Ce sont des tranches : bloquées et libres, Reg D et Reg S, acquises et non acquises. Il découpe donc un solde en partitions nommées, chacune avec ses règles de transfert, et ajoute un rôle de contrôleur pouvant forcer un transfert ou un rachat quand la loi l'exige.

Cela colle parfaitement aux instruments à vrai cycle de vie : blocages qui expirent, classes d'actions qui se convertissent, opérations sur titres qui déplacent des soldes entre compartiments. Si votre histoire de conformité est surtout « ces tokens sont restreints jusqu'à la date X puis ne le sont plus », les partitions l'expriment nativement là où ERC-3643 doit la contourner.

Ce qu'ERC-1400 ne vous donne pas, c'est l'identité. Il suppose qu'en amont quelqu'un a déjà décidé qui est autorisé sur le registre. Associez-le à une liste blanche ou à une couche d'identité et vous êtes proche d'ERC-3643 avec une mécanique de tranches en plus. Si vous n'avez pas besoin des tranches, cette mécanique est une complexité que vous payez sans l'utiliser.

CMTAT : l'option sobre et pragmatique

CMTAT est l'option que les ingénieurs sous-estiment car elle paraît ennuyeuse, et l'ennuyeux est souvent le bon choix. C'est un cadre suisse (de la Capital Markets and Technology Association) construit sur un cœur ERC-20 sobre avec des modules : mettre en pause tout le token, geler une adresse, prendre un snapshot des soldes pour un dividende ou un vote, et un hook de validation que chaque transfert doit passer.

La philosophie est l'inverse d'ERC-3643. Au lieu d'intégrer l'identité dans le token, CMTAT vous donne une couture propre et dit « mettez votre logique de conformité ici ». Ce module de validation peut être une simple liste d'autorisation, ou appeler quelque chose d'aussi strict qu'un registre d'identité. Vous choisissez la sévérité ; le standard garantit seulement que le hook est toujours appelé.

C'est sa force et son avertissement. CMTAT est honnête : c'est un cadre, pas un système de conformité complet. Le cœur ERC-20 fait que votre token fonctionne avec les wallets et outils existants dès le premier jour. Mais un module de validation vide est un security token sans conformité, donc le vrai travail se déplace dans du code que vous possédez et devez réussir.

ERC-7943 (uRWA) : une interface, pas une quatrième réponse

Il y a désormais un quatrième nom dans la conversation, et ce n'est pas une quatrième réponse. ERC-7943, l'interface universelle pour les actifs du monde réel (uRWA), est passé Final le 5 mai 2026. Avant de l'ajouter au comparatif, lisez son champ catégorie. Il dit Interface.

Il ne vous dit pas où vit la conformité. Il étend ERC-20, ERC-721 et ERC-1155 avec un vocabulaire commun pour ce que tout token régulé finit par faire de toute façon : geler un solde, forcer un transfert quand la loi l'exige, demander si une adresse a le droit d'envoyer ou de recevoir.

Sa motivation est directe sur le pourquoi. Les tentatives passées de standard universel RWA ont, dit-elle, imposé une complexité et un coût en gas inutiles pour des cas simples qui n'ont besoin ni d'une liste blanche on-chain obligatoire ni d'une solution d'identité on-chain spécifique. Elle ne cite personne. Vu que l'identité on-chain obligatoire est précisément la thèse d'ERC-3643, je prends la remarque pour moi.

Le nommage est délibéré lui aussi. La spec dit avoir préféré canTransfer à isTransferAllowed par cohérence avec les standards RWA établis, dont ERC-3643. C'est là qu'est l'intérêt : un intégrateur apprend un vocabulaire au lieu de trois.

Cela ne change donc pas le choix dont parle cet article. Cela change ce que vous exposez une fois le choix fait.

interface IERC7943Fungible {
    function forcedTransfer(address from, address to, uint256 amount) external returns (bool result);
    function setFrozenTokens(address account, uint256 amount) external returns (bool result);
    function canSend(address account) external view returns (bool allowed);
    function canReceive(address account) external view returns (bool allowed);
    function getFrozenTokens(address account) external view returns (uint256 amount);
    function canTransfer(address from, address to, uint256 amount) external view returns (bool allowed);
}

Alors, lequel choisir ?

Ôtez le tribalisme et la décision n'est pas si dure. Accordez le standard à la forme de votre problème de conformité, pas à celui que votre prestataire livre déjà.

La même question, « où vit la règle ? », revient dans les paiements d'agents et qui est responsable quand l'un dérape, plus loin dans la série.

Trois façons de se planter en production

FAQ