Quand un transfert groupé contourne les règles du token
Dans le code de référence d’ERC-7943, un transfert de 80 était refusé, mais 40 + 40 en un seul batch passaient. Comment des tokens gelés ont-ils bougé ?
EN 30 SECONDES
Un contournement par transfert groupé est un bug dans lequel plusieurs petits montants envoyés en un seul appel totalisent un transfert que le contrôle du token refuse. Dans le code de référence d’ERC-7943, il permettait de déplacer des tokens gelés (correctif proposé, non fusionné au 7 octobre 2026). Ce niveau montre comment.
À RETENIR · 3
- Dans le code de référence d’ERC-7943, le contrat uRWA1155 comparait chaque élément d’un batch à un solde qu’il ne débitait qu’après la boucle.
- En répétant un token id (40 + 40), un détenteur pouvait déplacer des tokens gelés, alors que canTransfer refusait un transfert unique de 80.
- Le bug se trouve dans l’implémentation de référence, pas dans le texte du standard. La PR n° 2045 propose un correctif, non fusionné au 7 octobre 2026.
Sur cette page
Le problème : deux envois de 40 là où 80 était refusé
EN BREF Dans le code de référence d’ERC-7943, un transfert refusé passait dès qu’on le coupait en deux éléments sur le même token id.
Un transfert de 80
- Le contrôle dit non : 80 dépasse les 40 non gelés.
- Le transfert échoue.
Un batch de 40 + 40, même id
- Chaque élément est comparé aux mêmes 40 : les deux passent.
- 80 partent. Solde 20, toujours 60 gelés.
C’est ce que faisait le contrat de référence ERC-7943 pour les tokens ERC-1155 quand je l’ai vérifié, le 7 octobre 2026. Un correctif attend dans une pull request, pas fusionnée lors de ma vérification (voyez la PR pour son état actuel).
Le bug se trouve dans ce code de référence, pas dans le texte du standard. Je suis l’un des cinq auteurs nommés d’ERC-3643, pas d’ERC-7943, et ce n’est pas moi qui ai trouvé ce bug.
EN CLAIR
Un ERC est un standard pour les applications Ethereum. Une pull request est une proposition de modification du code. Un token permissionné soumet ses transferts à des contrôles d’autorisation.
Ce type de bug est générique. Je le testerais sur tout token permissionné qui a un chemin batch.
Coming up next: Mais que veut dire « gelé » pour un token qui reste à vous ?
Les mots à connaître avant le bug
EN BREF Un token gelé ressemble à de l’argent bloqué sur votre compte : il vous appartient, mais vous ne pouvez pas l’envoyer.
ADAM explique : Prenez un guichetier qui compare chaque bordereau à votre solde libre, mais ne met votre compte à jour qu’à la fermeture. Un humain pourrait remarquer deux bordereaux du même compte ; ce code ne les comparait jamais.
LES MOTS À CONNAÎTRE
- Token id
- Un contrat ERC-1155 gère plusieurs sortes de tokens. Le token id indique laquelle, comme une référence produit.
- Tokens gelés
- Des tokens qu’un rôle autorisé a bloqués sur le compte d’un détenteur. Il en reste propriétaire, mais ne peut pas les envoyer.
- Transfert groupé (batch)
- Un seul appel qui déplace d’un coup plusieurs lots de tokens, sous forme d’une liste de token ids et d’une liste de montants.
- canTransfer
- Une fonction en lecture seule, une « vue », qui répond oui ou non : ce transfert serait-il autorisé ? Les applications peuvent la consulter avant d’envoyer.
- Implémentation de référence
- Du code d’exemple publié avec un standard pour montrer une façon de l’implémenter. Ce ne sont pas les règles du standard elles-mêmes.
Comment un transfert groupé contourne le gel des soldes
EN BREF Le code de référence compare chaque élément à un solde pas encore débité : un id répété est donc comparé deux fois aux mêmes 40.
ÉTAPE PAR ÉTAPE
Étape 1. Demander d’abord. Le détenteur veut envoyer 80 tokens de l’id 1 vers un autre compte, et consulte d’abord le pré-contrôle.
- Demander d’abord Le détenteur veut envoyer 80 tokens de l’id 1 vers un autre compte, et consulte d’abord le pré-contrôle.
- Refusé Le pré-contrôle répond non : 80 dépasse les 40 non gelés.
- Envoyer un batch Le détenteur envoie à la place un seul batch : l’id 1 deux fois, 40 à chaque fois.
- Premier contrôle Le premier élément demande 40. Le solde non gelé vaut 40 : il passe.
- Second contrôle Le second demande aussi 40. Rien n’a encore été débité, le solde non gelé vaut toujours 40. Il passe aussi.
- Débits C’est seulement maintenant, après les deux contrôles, que le contrat débite les deux éléments : 80 au total.
- Résultat Solde 20, gelé toujours 60. Une partie de la position gelée a quitté le compte.
ERC-7943 (uRWA, l’interface universelle des actifs réels) est un ERC Final signé par Dario Lo Buglio, Tino Martinez Molina et Mihai Colceriu. Final, c’est le stade où le texte est arrêté. Sa version multi-token permet à un rôle autorisé de geler une partie du solde d’un compte pour un Token id Un contrat ERC-1155 gère plusieurs sortes de tokens. Le token id indique laquelle, comme une référence produit. Voir le glossaire.
Frozen tokens cannot be transferred by the account.
Autrement dit, le détenteur ne doit pas pouvoir déplacer ses Tokens gelés Des tokens qu’un rôle autorisé a bloqués sur le compte d’un détenteur. Il en reste propriétaire, mais ne peut pas les envoyer. Voir le glossaire. Et canTransfer Une fonction en lecture seule, une « vue », qui répond oui ou non : ce transfert serait-il autorisé ? Les applications peuvent la consulter avant d’envoyer. Voir le glossaire « MUST validate that the amount being transferred doesn’t exceed the unfrozen amount » : il doit vérifier que le montant ne dépasse pas la part non gelée.
L’Implémentation de référence Du code d’exemple publié avec un standard pour montrer une façon de l’implémenter. Ce ne sont pas les règles du standard elles-mêmes. Voir le glossaire, le contrat uRWA1155, est censée appliquer cette règle dans _update, la fonction interne des transferts ordinaires. Pour un Transfert groupé (batch) Un seul appel qui déplace d’un coup plusieurs lots de tokens, sous forme d’une liste de token ids et d’une liste de montants. Voir le glossaire, elle compare chaque élément au solde non gelé. Le problème : le débit n’a lieu qu’après la boucle.
OBJET OBTENU
Contrôlés un par un, débités à la fin
Les dégâts sont bornés. Vers un autre compte, le batch ne peut pas déplacer plus que le solde brut. Et chaque élément pris seul doit tenir dans le montant non gelé.
ATTENTION
Dans ces limites, un détenteur sans rôle particulier peut déplacer la part gelée de sa position. Il lui suffit d’être sur la liste blanche du token.
Pourtant, le pré-contrôle que les applis peuvent consulter refuse ce même total.
Sources : issue n° 1814 des ERC, PR n° 2045 des ERC (ouverte au 7 oct. 2026), ERC-7943 (Final), contrat de référence uRWA1155.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi un contrôle qui regarde un élément à la fois peut rater ce que fait le batch entier.
- Pourquoi un débit placé après la boucle laissait passer 40 + 40 là où 80 était refusé.
- Où se trouve le bug : dans le code de référence, pas dans le texte du standard.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Un batch envoie 30 de l’id 1 et 30 de l’id 2, avec 40 non gelés sur chaque id. Entame-t-il le montant gelé ?
Non. Chaque id n’apparaît qu’une fois : chaque élément est déjà le total de son id. L’astuce exige le même id deux fois.
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.