Module bank et IBC : où placer chaque contrôle de conformité
Votre token contrôle chaque transfert ordinaire qu’il voit. Votre chaîne laisse-t-elle la valeur circuler là où il ne voit rien passer ?
EN 30 SECONDES
Une règle de conformité est ce qui fixe qui peut détenir un actif et comment il peut circuler. Sur une chaîne Cosmos EVM, chaque registre qui détient l’actif exige sa propre règle, sur le chemin qui modifie ses soldes.
À RETENIR · 3
- Chaque registre qui détient l’actif exige sa propre règle, placée sur le chemin qui modifie ses soldes.
- Un contrat de token ne contrôle pas d’office les soldes bank natifs ni les vouchers distants.
- Avant d’activer la conversion, listez chaque paire token-coin, nommez la règle de chaque forme de l’actif, et testez un transfert interdit et une action de récupération sur la chaîne déployée.
Sur cette page
Où placer le contrôle
EN BREF Chaque registre qui détient l’actif exige sa propre règle, placée sur le chemin qui modifie ses soldes.
LES MOTS À CONNAÎTRE
- Module bank
- Le registre intégré d’une chaîne Cosmos, noté x/bank. Il tient les soldes de coins et les déplace lui-même, hors de tout contrat de token.
- Conversion
- L’opération qui place des tokens ERC-3643 sous séquestre contre le même montant en coins du module bank.
- IBC
- Le protocole qu’utilisent les chaînes Cosmos pour s’envoyer des tokens. Quand un token quitte sa chaîne d’origine, un voucher arrive sur l’autre chaîne : un bon qui représente l’original.
- Middleware
- Du code qu’une chaîne ajoute sur un chemin, par exemple le chemin IBC, et qui peut examiner ou refuser ce qui passe.
La chaîne vérifie bien l’exécution des contrats. La faille, c’est un autre chemin, qui n’appelle jamais ce contrat : après une Conversion L’opération qui place des tokens ERC-3643 sous séquestre contre le même montant en coins du module bank. Voir le glossaire, les coins circulent dans le Module bank Le registre intégré d’une chaîne Cosmos, noté x/bank. Il tient les soldes de coins et les déplace lui-même, hors de tout contrat de token. Voir le glossaire et passent par IBC Le protocole qu’utilisent les chaînes Cosmos pour s’envoyer des tokens. Quand un token quitte sa chaîne d’origine, un voucher arrive sur l’autre chaîne : un bon qui représente l’original. Voir le glossaire.
ÉTAPE PAR ÉTAPE
Étape 1. Contrat de token. Les contrôles de transfert et les pouvoirs d’agent ERC-3643 vivent ici, et la chaîne valide leur exécution.
- Contrat de token Les contrôles de transfert et les pouvoirs d’agent ERC-3643 vivent ici, et la chaîne valide leur exécution.
- Module de conversion Il garde la part convertie sous séquestre. Un transfert du token s’exécute à l’entrée et au remboursement.
- Module bank Il tient les soldes des coins bank. Toute restriction bank doit être examinée à part.
- IBC et l’autre chaîne Paquets, middleware et vouchers. Il faut des règles et une récupération aux deux bouts.
EN CLAIR
Un contrôle ne peut arrêter qu’un mouvement qui passe par lui. Ici, l’actif peut prendre plusieurs routes : chacune exige une barrière, même si plusieurs barrières appliquent la même règle.
La même question se pose pour l’autorisation des agents : repérer chaque chemin qui modifie l’état, et placer le contrôle là où ce chemin ne peut pas l’éviter.
Dans la section suivante : Alors, votre propre token passe-t-il par l’une de ces routes ?
Votre token est-il exposé ?
EN BREF Partez des chemins que votre déploiement ouvre réellement, puis suivez chacun jusqu’au registre qu’il modifie.
Chainlink ACE est un produit commercial, distinct d’un standard d’interface de token. Chainlink présente son Automated Compliance Engine et son Cross-Chain Identity comme une infrastructure pour des tokens soumis à des règles. Cela ne dit pas comment un chemin bank Cosmos donné est contrôlé.
Jugez un produit de conformité sur ses contrats déployés, ses réseaux pris en charge, son middleware et sa récupération, pas sur son nom.
En tant que CTO d’Integra en 2025-2026, j’ai mené une Layer-1 RWA du testnet jusqu’à un mainnet prêt au lancement. Ce rôle s’est terminé en juin 2026.
L’article parle de choix d’architecture. Il n’annonce aucune date de mainnet et ne prétend pas que ces contrôles proposés sont déployés.
Un contrat dont les règles sont bien appliquées peut encore exiger des contrôles d’intégration quand un autre registre représente le même actif.
Avant d’activer la conversion, faites trois vérifications. Les arbitrages de déploiement plus généraux sont dans l’épisode 1.
- Listez chaque paire de votre token ERC-3643, et qui peut enregistrer la paire ou convertir le token sur chaque chaîne.
- Pour chaque forme de l’actif (ERC-20, coin bank, voucher IBC), identifiez le code qui modifie ses soldes et la règle qui s’y applique : règles bank, Middleware Du code qu’une chaîne ajoute sur un chemin, par exemple le chemin IBC, et qui peut examiner ou refuser ce qui passe. Voir le glossaire du pont, remboursement.
- Testez un transfert interdit et une action de récupération sur chaque forme, sur la chaîne déployée, pas seulement dans le code du module.
OBJET OBTENU
Testez la chaîne réelle
Sources : le code de conversion cosmos/evm au commit étudié ; présentation de Chainlink ACE par le fournisseur.
FAQ
Cet article décrit un risque d’intégration repéré dans le code, pas un cas documenté où quelqu’un l’aurait exploité. Il ne dit pas si un tel cas a eu lieu ailleurs.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi chaque registre qui détient l’actif exige sa propre règle, sur le chemin qui modifie ses soldes.
- Comment savoir si votre token est exposé, et quoi tester avant d’activer la conversion.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Votre token est déployé sur une seule chaîne EVM, sans module bank, mais un pont l’emmène vers une autre chaîne. Est-il exposé au chemin de conversion ? Que devez-vous encore examiner ?
Pas à ce chemin : les contrôles du contrat d’origine restent sur son registre source. Mais le pont est un autre chemin qui modifie des soldes : examinez-le, ainsi que la forme du token sur l’autre chaîne, les wrappers et les rôles privilégiés.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.