ERC-3643 vs ERC-1400 vs CMTAT : comparatif

Une banque m'a appele 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 equipe conformité voulait savoir si c'était le bon choix. Ce n'était pas une question de code. C'était une question a cinq ans deguisee en question de code.

Un standard de security token n'est pas une bibliotheque qu'on remplace au sprint suivant. Il décide qui peut detenir 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.

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 biaise et informe, pas neutre. Je serai juste envers les deux autres, car pretendre qu'ils n'ont aucune place, c'est perdre le debat face a un bon ingénieur.

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

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

Le vrai choix : où vit la conformité ?

Oubliez les listes de fonctionnalités un instant. Chacun de ces standards repond a la même question a un endroit différent : quand quelqu'un tente de deplacer ce token, qui décide oui ou non, et sur quelle preuve ?

Ce seul choix de design entraine tout le reste. Il fixe 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. Si vous ne retenez qu'une chose de ce post : 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 ineligible. Pas un wrapper, pas une barriere hors chaine qu'on peut oublier d'appeler. La fonction de transfert demande a un registre d'identité si le destinataire détient les attestations exigées par ce token, et annule sinon. La conformité n'est pas ajoutee ; elle est le chemin du transfert.

Les attestations vivent dans un contrat d'identité on-chain (dans le design T-REX, OnchainID), signees par des émetteurs de confiance. Votre passeport ne touche jamais la chaine. La chaine voit seulement qu'un émetteur que vous approuvez a atteste << cette adresse peut detenir cette classe d'actif >>. C'est la partie elegante, et c'est pourquoi le modèle a gagne son adoption.

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

ERC-1400 : les tranches, et quand elles gagnent

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

Cela colle parfaitement aux instruments a vrai cycle de vie : blocages qui expirent, classes d'actions qui se convertissent, opérations sur titres qui deplacent des soldes entre compartiments. Si votre histoire de conformité est surtout << ces tokens sont restreints jusqu'a la date X puis ne le sont plus >>, les partitions l'expriment nativement la ou 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écide qui est autorise sur le registre. Associez-le a une liste blanche ou a une couche d'identité et vous etes proche d'ERC-3643 avec une mecanique de tranches en plus. Si vous n'avez pas besoin des tranches, cette mecanique est une complexite que vous payez sans l'utiliser.

CMTAT : l'option sobre et pragmatique

CMTAT est l'option que les ingenieurs sous-estiment car elle parait 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 severite ; le standard garantit seulement que le hook est toujours appele.

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 des le premier jour. Mais un module de validation vide est un security token sans conformité, donc le vrai travail se deplace dans du code que vous possedez et devez réussir.

Alors, lequel choisir ?

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

Trois façons de se planter en production

FAQ