Fonctionnement du KYC on-chain pour les tokens autorisés

Comment fonctionne la KYC et la liste blanche sur la chaîne se résume à un seul mouvement : transformer une décision KYC/AML hors chaîne en une éligibilité vérifiable par machine sur la chaîne que les contrats intelligents peuvent appliquer au moment du transfert ou de l'accès.

Le choix de conception n'est pas "KYC ou pas KYC", mais où se situe la porte dans la pile et si les règles résident à l'intérieur du jeton ou dans des modules de conformité évolutifs.

Points clés

• Les vérifications KYC/AML se font généralement hors chaîne avec des fournisseurs réglementés, tandis que la couche sur chaîne stocke un résultat vérifiable "éligible/non éligible + attributs" en tant que revendications liées à une identité sur chaîne.
• L'ERC-3643 fait de la conformité une primitive de transfert : le jeton vérifie un Registre d'Identité et un Module de Conformité, et la transaction est annulée si l'une des vérifications échoue.
• La liste blanche peut être appliquée à plusieurs niveaux au-delà du contrat de jeton, y compris le pont, le RPC et le consensus, avec un compromis clair entre contrôle et ouverture.
• Le plan de contrôle opérationnel est généralement le Registre d'Identité plus le Module de Conformité, ce qui concentre le risque de mise à niveau et de clé d'administrateur dans ces contrats.

Où la KYC sur chaîne s'intègre dans la crypto

Les chaînes sans permission permettent à n'importe quelleadressede recevoir et d'envoyeractifs, ce qui est exactement ce que les émetteurs réglementés ne peuvent pas permettre pour de nombreux titres tokenisés et autres instruments restreints. La contrainte n'est pas philosophique.

Elle est mécanique : si un actif doit être détenu uniquement par des investisseurs éligibles, le système doit avoir un moyen d'arrêter un transfert avant qu'il ne soit réglé sur la chaîne.

C'est là que se manifeste le concept de « conformité par code ». L'expression on chain kyc est mal interprétée comme « mettre des documents d'identité sur Ethereum.” L'architecture commune dans les sources est l'opposée. Les vérifications KYC et AML se font toujours hors chaîne avec des fournisseurs réglementés, tandis que la chaîne conserve le minimum nécessaire pour rendre l'éligibilité vérifiable par machine au moment de la transaction.

La description d'ONINO est explicite : le résultat de la vérification hors chaîne est représenté sur la chaîne sous forme de revendications cryptographiques stockées dans l'ONCHAINID d'un investisseur et ensuite lues lors des transferts.

La liste blanche est la règle d'application qui consomme ces revendications. Une liste blanche de jetons peut être aussi rudimentaire qu'une cartographie d'adresses approuvées, mais les conceptions modernes considèrent « qui est autorisé » comme une question d'identité, et non une question d'adresse.

C'est la différence entre un modèle de portefeuille autorisé (cette adresse est autorisée) et un modèle lié à l'identité (cette adresse est liée à une identité éligible). Dans l'approche liée à l'identité, une adresse peut changer tandis que l'éligibilité reste attachée au dossier d'identité.

L'autre terme qui compte est adresse bloquée. Dans ces systèmes, une adresse bloquée n'est pas une étiquette sociale. C'est une adresse qui échoue aux vérifications d'éligibilité, donc les transferts vers celle-ci sont annulés, ou elle se voit refuser l'accès à une autre porte dans la pile.

Le mécanisme central derrière la liste blanche

Deux leviers entraînent tout le système, et la plupart des explications les mélangent.

Le premier levier est la représentation de l'identité et de l'éligibilité. Les sources décrivent l'ONCHAINID comme la couche d'identité sur chaîne utilisée avec l'ERC-3643, avec des revendications ou des certificats émis par des parties de confiance ou autorisées. AI CERTs met en avant le modèle de confidentialité : les données sensibles restent hors chaîne, tandis que les signatures ou revendications sont conservées sur la chaîne.

Cette séparation est le point. La chaîne n'a pas besoin d'un scan de passeport. Elle a besoin d'une déclaration vérifiable comme « KYC réussi » ou « juridiction = UE », signée par un émetteur en qui le système a confiance.

Le levier deux est l'application des règles. Une fois que l'éligibilité est représentée sur la chaîne, quelque chose doit encore l'appliquer. L'application peut se trouver à l'intérieur d'un contrat de jeton, à l'intérieur d'une application, ou plus haut dans la pile. Au niveau du jeton, l'application signifie que le jeton refuse de se déplacer à moins que les deux parties ne soient éligibles et que le transfert respecte la logique des règles. C'est là que l'idée du jeton sur liste blanche devient concrète : le jeton lui-même devient le portail.

Un flux générique ressemble à ceci :

1. Un fournisseur hors chaîne vérifie un utilisateur et décide quels attributs il possède (KYC validé, accréditation, juridiction). 2. Un émetteur de confiance écrit ces attributs sur la chaîne en tant que revendications liées à une identité sur la chaîne. 3. Un registre lie une ou plusieurs adresses de portefeuille à cette identité et répond à la question « cette adresse est-elle éligible en ce moment ? » 4.

Un jeton ou une application vérifie le registre et tout moteur de règles pendant une transaction. 5. Si une vérification échoue, la transaction revient en arrière, de sorte que l'état ne change pas et que le transfert ne se règle pas.

La sortie n'est pas « KYC sur la chaîne ». La sortie est un oui/non déterministe au moment du transfert, plus une trace d'audit de ce que les contrats ont appliqué.

Comment l'ERC-3643 applique le KYC sur les transferts

L'ERC-3643 est positionné dans sa documentation comme une suite open-source de contrats intelligents pour émettre, gérer et transférer des tokens autorisés, avec un cadre d'identité décentralisé intégré afin que seuls les utilisateurs éligibles puissent devenir détenteurs de tokens sur des blockchains sans permission.

Cela établit également une distinction claire par rapport à ERC-20: ERC-3643 vérifie l'identité et l'éligibilité avant de permettre les transferts, soutenant les exigences de conformité telles que KYC et AML.

L'architecture ERC-3643/T-REX d'ONINO divise le système en quatre composants connectés : identités on-chain, registre d'identité, modules de conformité plug-in, et contrat de token. Cette décomposition est importante car elle montre où les équipes opèrent réellement le système au quotidien.

L'arbre de décision de transfert décrit par ONINO est simple et brutal, c'est pourquoi il fonctionne :

1. Un transfert est initié sur le contrat de token. 2. Le token vérifie le Registre d'Identité pour la vérification de l'expéditeur et du destinataire. 3. Le token vérifie un Module de Conformité pour des violations de règles. 4. Si l'une ou l'autre vérification échoue, la transaction est annulée. Si les deux réussissent, le transfert s'exécute.

C'est l'avantage pratique clé par rapport aux listes blanches ad hoc. Un token autorisé construit sur ERC 3643 ne « fait pas de son mieux » et ne se réconcilie pas plus tard. La chaîne accepte soit le transfert selon les règles, soit elle ne l'accepte pas.

Le Module de Conformité est l'endroit où l'application des règles devient modulaire. ONINO liste des exemples qui peuvent y être codés : plafonds d'investisseurs, restrictions juridictionnelles, périodes de blocage et limites de détenteurs. ONINO déclare également que les règles peuvent être mises à jour sans redéployer le token car la logique de conformité est séparée du contrat de token.

Cette séparation est le déverrouillage opérationnel, et c'est aussi là que se concentre le risque de gouvernance et de mise à niveau.

Dans les marchés traditionnels, un agent de transfert est la partie qui maintient le registre officiel de propriété et traite certains événements de cycle de vie. Les piles de style ERC-3643 sont une tentative de coder des parties de cette fonction dans des contrats et des rôles d'agents, afin que le token lui-même puisse faire respecter qui est autorisé à détenir et à transférer.

D'autres endroits où le KYC peut être appliqué

Le guide DeFi autorisé de Conduit cadre « où vous gatez » comme un choix de pile, et non un choix de norme de jeton. Il décrit quatre couches d'infrastructure où l'autorisation peut être mise en œuvre, classées de la moins à la plus impactante sur l'ouverture et la décentralisation: protocole, pont, RPC et consensus.

Le gating au niveau du protocole est le plus ciblé. L'exemple de Conduit est la mise sur liste blanche par actif, pointant vers des normes de jeton comme l'ERC-3643 qui peuvent imposer qui peut détenir et transférer un jeton. C'est ici qu'un jeton autorisé peut empêcher les transferts secondaires vers des détenteurs inéligibles parce que le jeton lui-même refuse de se déplacer.

Le gating au niveau du pont est un contrôle de périmètre. Conduit décrit le gating KYC au niveau du pont comme un moyen de décider qui peut entrer dans un écosystème. Cela peut empêcher les portefeuilles non vérifiés d'apporter des actifs sur une chaîne, mais cela n'arrête pas automatiquement les transferts intra-écosystème à moins que les actifs eux-mêmes ne soient également autorisés.

Le gating au niveau RPC façonne le chemin par défaut de l'utilisateur. Conduit donne des exemples comme des restrictions géographiques ou des flux de travail d'approbation de transaction aux points de terminaison RPC officiels. Ces contrôles peuvent être mis à jour en tant que politique, et ils peuvent être contournés par des utilisateurs qui exécutent leurs propres nœuds sur de nombreux réseaux. Cela rend le gating RPC utile pour la posture de conformité, mais plus faible en tant que garantie solide.

Le gating au niveau du consensus est le plus fort et le plus invasif. Conduit décrit cela comme la définition des politiques d'inclusion des transactions au niveau du séquenceur ou du jeu de validateurs. Il fournit la plus profonde application parce que chaque transaction est soumise à la règle, et il a également le plus grand impact sur l'ouverture.

L'implication de conception est simple : l'application au niveau du jeton concerne le contrôle de la détention et du transfert d'un actif spécifique, tandis que les contrôles de pont et de RPC concernent le contrôle des chemins d'entrée et d'accès.

Compromis pratiques et modes de défaillance

Le premier compromis est le contrôle opérationnel contre le risque de mise à niveau. Le cadre de conformité modulaire d'ONINO est attrayant car les règles peuvent changer sans redéployer le token. Le coût est que le Module de Conformité et le Registre d'Identité deviennent le plan de contrôle. Les clés d'administration, les autorisations de mise à niveau et le champ d'audit s'y regroupent, et non dans la surface de type ERC-20 du token.

Le deuxième compromis est l'expérience utilisateur. L'application se manifeste pour les utilisateurs sous forme de transactions annulées, et non comme un avertissement poli. Si un destinataire n'est pas éligible, le transfert échoue etgazest toujours dépensé. Les systèmes qui ne fournissent pas de pré-vérifications claires et de raisons d'échec lisibles transforment la conformité en tickets de support.

Le troisième compromis est ce que signifie réellement "whitelist". Une liste d'adresses statique est fragile car les adresses changent, les configurations de garde évoluent et les institutions utilisent plusieurs portefeuilles. Les modèles liés à l'identité réduisent cette fragilité, mais ils introduisent des dépendances vis-à-vis des registres et des émetteurs de confiance.

Le quatrième compromis est la posture de décentralisation. Le classement des couches de Conduit est un modèle mental utile : le contrôle par protocole est étroit et composable, tandis que le contrôle par consensus est large et coercitif. Les équipes qui affirment une « conformité décentralisée » sans préciser où se situe l'application cachent généralement le véritable point de contrôle.

Les modes de défaillance suivent l'architecture. Si le Registre d'Identité est incorrect, les utilisateurs éligibles sont traités comme une adresse bloquée. Si le Module de Conformité est mal configuré, les transferts qui devraient se régler sont annulés. Si la gouvernance autour des mises à jour est négligente, les règles peuvent changer plus rapidement que les contreparties ne s'y attendent.

C'est pourquoi la conformité par le code n'est pas seulement une question juridique. C'est une histoire de conception de systèmes avec des points de blocage très spécifiques.

Sources

• Documentation ERC-3643
• ONINO）
• CERTs IA
• Conduit