ERC 3643 et ERC 1400 : deux architectures pour tokens…

L'explication de l'ERC 3643 par rapport à l'erc 1400 se résume à l'endroit où se trouve la décision de conformité « oui/non » : dans le chemin de transfert du jeton onchain (ERC-3643) ou dans un flux de travail d'autorisation offchain (ERC-1400). Ce choix de conception unique façonne l'interopérabilité, le risque opérationnel et la proximité d'un émetteur avec la conformité par code avec un véritable règlement T+0.

Points clés

• ERC-20 déplace la valeur de manière fluide mais ne peut pas nativement imposer l'éligibilité des investisseurs et les restrictions de transfert requises pour les actifs, ce qui explique l'émergence des normes de jetons de sécurité.
• L'erc 3643 utilise un modèle de validateur automatique onchain lié aux identités et aux règles d'offre, maintenant le contrôle de l'émetteur ou de l'agent même lorsque les investisseurs se gardent eux-mêmes.
• L'erc 1400 valide les transferts avec une clé générée offchain spécifique et ajoute des fonctionnalités de marchés de capitaux comme des partitions et la gestion de documents.
• Les normes diffèrent moins par leurs « fonctionnalités » que par la microstructure du marché : le gating onchain (ERC-3643) tend à s'intégrer comme l'ERC-20, tandis que l'autorisation offchain (ERC-1400) ajoute une dépendance critique que chaque lieu doit opérationnaliser.

Pourquoi les jetons de sécurité ont besoin de normes spéciales

ERC-20 a résolu un problème de distribution pour les tokens de type porteur : les soldes se déplacent de pair à pair avec un seul appel de transfert on-chain. Cela se brise au moment où l'actif est réglementé. Un token de sécurité représente un actif réel réglementé comme des actions, des dettes, un intérêt de fonds ou de l'immobilier tokenisé, et les transferts ne se limitent pas à « le vendeur a-t-il un solde ?

» Ils sont « le destinataire est-il éligible, dans cette juridiction, selon les règles de cette offre, maintenant ? » Tokeny cadre directement le problème : ERC-20 permet des transferts de base mais n'impose pas les règles de transfert et les réglementations de conformité qui existent sur les marchés de capitaux.

Cet écart est là où la conformité par code commence à ressembler moins à une fonctionnalité et plus à de la plomberie de marché. Si l'éligibilité n'est pas appliquée au niveau du token, elle est poussée dans des processus manuels, des contrôles de courtiers-négociants ou des règles spécifiques aux lieux.

Le résultat est un règlement fragmenté et des étapes opérationnelles supplémentaires qui ressemblent à du post-négociation traditionnel, juste avec un emballage de token.

DeuxEthereum normes sont couramment positionnées comme les principales réponses à cela : erc 3643 (anciennement la norme t rex, également écrite comme T-REX) et erc 1400. Tokeny décrit les deux comme des normes de token de sécurité qui imposent des règles de conformité et contrôlent les transferts aux investisseurs éligibles, mais avec des mécanismes différents. Ce « mécanisme différent » est tout le jeu.

Il détermine si un lieu peut traiter le token comme un ERC-20 avec des vérifications supplémentaires, ou si chaque transfert nécessite un flux de travail d'autorisation externe qui devient une dépendance pour le règlement.

Comment ERC-3643 impose des transferts conformes

Un transfert sous erc 3643 est conçu pour échouer rapidement si les parties ne sont pas éligibles. Le flux principal est un système de validation automatique qui vérifie les règles de transfert liées aux utilisateurs (identités) et à l'offre. Tokeny et NYALA décrivent tous deux le même schéma : avant qu'un transfert ne s'exécute, la logique du token vérifie si l'expéditeur et le destinataire satisfont aux règles définies par l'émetteur.

C'est ici que l'analogie du « moteur de correspondance » s'applique. Le token lui-même se comporte comme un lieu autorisé qui refuse de régler une transaction inéligible. Le token devient un token autorisé par construction, et le modèle mental le plus courant auquel les utilisateurs font appel est un token sur liste blanche. La différence est que la liste blanche n'est pas juste une liste statique.

La logique de validation peut refléter des attributs d'identité et des contraintes d'offre, et elle peut être mise à jour au fur et à mesure que les règles changent.

L'identité est le levier. L'aperçu de Rejolut lie explicitement les vérifications d'éligibilité ERC-3643 à ONCHAIN ID, décrivant onchainid comme une identité numérique avec des attestations signées par des émetteurs de revendications de confiance.

Que l'équipe utilise cette pile d'identité exacte ou un registre équivalent, l'implication opérationnelle est la même : le registre d'identité et la configuration du validateur deviennent le chemin critique pour chaque transfert.

Le contrôle de l'émetteur et de l'agent est l'autre levier. Tokeny et NYALA soulignent tous deux que l'émetteur des titres, ou son agent, garde le contrôle des tokens et des transferts même lorsque les investisseurs se gardent eux-mêmes. NYALA décrit des contrôles comme la destruction ou le transfert forcé de tokens.

Cela compte pour les opérations du jour 2 : les actions d'entreprise, les mises à jour de sanctions, les clés perdues et les ordonnances judiciaires ne sont pas des cas marginaux sur les marchés réglementés. Ce sont le travail.

Comment ERC-1400 structure les tokens régulés

ERC-1400 emprunte une voie différente vers la même destination : des transferts conformes. Au lieu de s'appuyer sur une porte de validation on-chain, Tokeny et NYALA décrivent ERC-1400 comme validant chaque transaction à l'aide d'une clé spécifique générée off-chain. Conceptuellement, cela est plus proche d'un ticket pré-négociation. Le transfert est autorisé parce qu'un système externe a produit la bonne attestation pour ce mouvement spécifique.

Ce flux de travail de clé off-chain est associé à des fonctionnalités qui ressemblent à la conception de produits de marchés de capitaux plutôt qu'à une simple restriction de transfert. NYALA décrit un système de gestion documentaire qui lient les tokens à des documents juridiques et des informations pertinents. Les mêmes sources décrivent des partitions, qui divisent les tokens en sous-ensembles avec des règles et des restrictions différentes.

Rejolut cadre également ERC-1400 comme combinant des normes ERC existantes et nouvelles pour couvrir les besoins des tokens de sécurité, y compris les restrictions de transfert, les métadonnées de transfert, la gestion documentaire, les transferts forcés et la fongibilité partielle via des soldes partitionnés.

Les partitions sont la partie qui change la façon dont l'actif se comporte sur un écran. Un seul "token" peut représenter plusieurs compartiments qui ne sont pas interchangeables car ils portent des droits, des périodes de blocage ou des restrictions différents. Cela est utile lorsque le "même ticker" ne peut pas être traité comme un seul pool uniforme.

Cela signifie également que les intégrations doivent comprendre quelle partition est en mouvement, pas seulement le solde total.

Le compromis opérationnel est intégré dans le modèle d'autorisation. Si chaque transfert nécessite une clé générée off-chain, alors le pipeline d'émission et de validation de clés devient une infrastructure de marché. S'il est en panne, les transferts échouent. S'il est mal géré, les transferts peuvent être abusés.

NYALA signale explicitement la dépendance à une clé off-chain comme un risque de sécurité et opérationnel car la clé pourrait être compromise ou perdue.

Différences clés qui affectent l'adoption

La manière la plus claire de comparer ces normes de tokens de sécurité est d'aligner les axes qui déterminent qui peut s'intégrer et ce qui se casse lors du règlement.

1. Où vit l'autorisation. ERC-3643 impose l'éligibilité on-chain via un validateur automatique lié aux identités et aux règles d'offre. ERC-1400 autorise les transferts via une clé off-chain spécifique par transaction. C'est la bifurcation architecturale qui cascade dans tout le reste. 2. Interopérabilité et distribution.

NYALA affirme qu'ERC-3643 est compatible avec tout portefeuille ou échange ERC-20, tandis qu'ERC-1400 n'est pas entièrement compatible avec les portefeuilles et échanges ERC-20 en raison de la complexité ajoutée. La description de Rejolut implique qu'ERC-1400 s'appuie sur ERC-20 avec des extensions, ce qui peut être interprété comme une compatibilité partielle, mais cela ne fait pas la même large affirmation de "tout portefeuille/échange". 3.

Dépendance opérationnelle. La dépendance d'ERC-1400 est le flux de travail de clé d'autorisation off-chain. La dépendance d'ERC-3643 est le registre d'identité et de validateur plus les contrôles de l'émetteur ou de l'agent. Les deux sont des chemins critiques, mais ils échouent différemment à 2 heures du matin. 4. Structuration des produits.

Les partitions et la gestion documentaire d'ERC-1400 sont conçues pour des actifs où des tranches, des périodes de blocage ou des droits doivent être représentés comme des compartiments séparés. ERC-3643 est positionné davantage comme une porte de transfert uniforme qui peut appliquer plusieurs règles et juridictions sans partitionnement.

Tokeny positionne également l'ERC-3643 comme un encodage de conformité, préservant le contrôle de l'émetteur ou de l'agent, réduisant les coûts grâce à un règlement automatisé onchain T+0, et augmentant la transférabilité et la liquidité. L'affirmation T+0 n'est pas magique. Elle dépend de l'automatisation de la décision de conformité dans le chemin de transfert.

Si la conformité est déplacée vers des étapes de coordination offchain, le système peut revenir vers une latence opérationnelle.

L'adoption est un jeu de coordination, donc l'empreinte rapportée compte même lorsqu'elle est fournie par l'émetteur ou le vendeur. Tokeny répertorie les métriques d'utilisation d'ERC-3643 pour plus de 120 fonctions, plus de 180 juridictions appliquées, 28 milliards d'euros de valeur tokenisée pour les clients, et plus de 120 émetteurs et institutions financières.

Aucun ensemble de données d'adoption de tiers comparable n'est fourni pour ERC-1400 dans les sources fournies, donc la comparaison ne peut pas être faite de manière symétrique.

Quand chaque norme a du sens

La sélection commence généralement par une question directe : l'objectif est-il une distribution large semblable à celle des ERC-20, ou l'objectif est-il une structuration juridique fine à l'intérieur du token ?

ERC-3643 a tendance à convenir aux équipes qui souhaitent que la conformité soit appliquée au niveau du transfert de jetons et qui veulent que les intégrations ressemblent le plus possible à ERC-20. La revendication de compatibilité de NYALA est la principale raison pour laquelle elle apparaît dansRWAconversations de distribution.

Si un token peut être détenu et déplacé en utilisant les infrastructures de portefeuille et d'échange existantes, l'émetteur ne demande pas à chaque plateforme de mettre en œuvre un flux d'autorisation sur mesure. Le coût est que la configuration de l'identité et des validateurs devient le centre de gravité opérationnel, et les contrôles de l'émetteur ou de l'agent doivent être régis de manière stricte.

ERC-1400 convient aux actifs où les partitions et le lien documentaire ne sont pas optionnels. Si le produit nécessite une fongibilité partielle, plusieurs tranches ou différents ensembles de restrictions qui doivent être représentés explicitement, le système de partition d'ERC-1400 est un moyen natif de le faire. Le coût est de souscrire au flux de travail de clé offchain en tant qu'infrastructure critique, car chaque transfert en dépend.

Une séquence d'évaluation pratique est simple.

1. Cartographier le modèle de restriction de l'actif. Si l'actif est un seul pool avec des règles d'éligibilité, le gating onchain s'aligne naturellement. Si l'actif est composé de plusieurs compartiments avec différents droits ou verrouillages, des partitions peuvent être le produit. 2. Valider les cibles d'intégration tôt.

Si la distribution dépend du support existant des portefeuilles et des échanges ERC-20, tester la revendication de compatibilité ERC-3643 de NYALA avec les lieux réels qui comptent. 3. Souscrire au mode de défaillance. L'ERC-1400 concentre le risque dans le pipeline de clés offchain. L'ERC-3643 concentre le risque dans les registres d'identité, la configuration des validateurs et les contrôles des agents.

Les deux normes sont des tentatives de transformer le règlement réglementé en logiciel. La différence réside dans le fait que la décision de conformité est appliquée comme une règle de moteur d'appariement onchain, ou comme un ticket de pré-négociation émis offchain. Ce choix détermine à quel point le système se rapproche du règlement automatisé sans réintroduire de coordination manuelle.

Idées reçues courantes qui font perdre du temps

« Les deux ne sont que des ERC-20 avec une liste blanche. » Cette formulation manque la distinction fondamentale. L'ERC-3643 est décrit comme imposant l'éligibilité par le biais d'un validateur onchain et de vérifications d'identité, tandis que l'ERC-1400 est décrit comme validant les transferts avec une clé générée offchain spécifique.

Un modèle mental de jeton de liste blanche peut être utile comme point de départ, mais il cache où la décision d'autorisation réelle est prise.

« Les partitions ne sont qu'une fonctionnalité agréable à avoir. » Pour de nombreux produits réglementés, les partitions sont le produit. NYALA et Rejolut décrivent les partitions comme divisant les jetons en sous-ensembles ou sous-soldes avec des règles et restrictions différentes, ce qui modifie le comportement des soldes, des transferts et des rapports. Considérer les partitions comme cosmétiques conduit à une comptabilité défaillante et à des intégrations confuses.

« T+0 est automatique une fois que vous tokenisez. » Le positionnement T+0 de Tokeny est lié au règlement automatisé onchain avec la conformité intégrée dans le chemin de transfert. Si un design repose sur des étapes offchain comme l'émission de clés par transaction, le système peut réintroduire une latence opérationnelle même si le transfert final est onchain.

« L'autorisation offchain n'est qu'un détail d'implémentation. » NYALA signale explicitement la clé offchain comme une dépendance de sécurité et opérationnelle car elle peut être compromise ou perdue. Ce n'est pas une note de bas de page. C'est un élément central de l'infrastructure du marché qui doit être géré comme tout autre système critique.

La prise

J'ai vu des équipes traiter le « choix de la norme de jeton » comme une préférence de développeur, puis découvrir qu'il s'agit en réalité d'une décision de conception de lieu. Si l'éligibilité est appliquée onchain comme l'ERC-3643, le jeton lui-même devient la porte d'entrée, et les intégrations peuvent ressembler de plus près au chemin ERC-20 que NYALA revendique.

Si l'éligibilité est appliquée par une clé offchain comme l'ERC-1400, le pipeline de clés devient ce qui peut arrêter le règlement lorsqu'il rencontre des problèmes.

L'erreur coûteuse consiste à optimiser pour la démo au lieu des opérations du jour 2. Les actions d'entreprise, les transferts forcés et les mises à jour de règles sont là où la conformité par code soit tient bon, soit se transforme en un tas d'exceptions manuelles.

Choisissez le mode de défaillance que l'organisation peut réellement gérer à 2 heures du matin, car c'est là que ces normes cessent d'être « des normes de jetons de sécurité comparées » et commencent à être une microstructure de marché.

Sources

• Tokeny
• NYALA
• Rejolut