Délégation EIP-7702 : quoi vérifier avant de signer ?
Une seule signature peut faire exécuter à votre compte le code d’un autre. Que doit vérifier votre wallet avant de signer ?
EN 30 SECONDES
Une délégation EIP-7702 est une permission signée qui fait exécuter à un compte ordinaire le code d’un contrat. Un délégué mal écrit peut livrer à un attaquant le contrôle quasi complet du compte, et des attaquants s’en servent déjà. Un wallet devrait vérifier la chaîne, le nonce et le code audité du délégué avant de signer.
À RETENIR · 3
- Une délégation 7702 persiste jusqu’à son remplacement, et la spec 7702 prévient qu’un délégué mal écrit peut livrer à un attaquant le contrôle quasi complet du compte.
- Un article de USENIX Security ’26 associe plus de 63 % des autorisations 7702 étudiées, sur sept chaînes avant le 15 juillet 2025, à des attaques malveillantes visant des EOA.
- Avant de signer, un wallet devrait vérifier la chaîne et le nonce, et s’assurer que le délégué figure sur une liste auditée avec un code conforme.
Sur cette page
Ce qui peut mal tourner avec une délégation EIP-7702
EN BREF Une délégation 7702 confie votre compte au code du délégué : un délégué mal écrit peut vous coûter le compte.
LES MOTS À CONNAÎTRE
- EOA
- Un « externally owned account » : un compte Ethereum classique, contrôlé par une seule clé privée.
- Délégué
- Avec EIP-7702, le contrat vers lequel pointe un compte ordinaire, et dont il exécute le code comme si c’était le sien.
- Autorisation
- Le message signé qui fait pointer un EOA vers un délégué. Il indique la chaîne, l’adresse du délégué et un nonce.
- Nonce
- Un compteur des transactions envoyées par un compte et des autorisations traitées pour lui, pour qu’une ancienne signature ne puisse pas être rejouée.
La suite vient de la spec et d’un article de USENIX Security ’26.
EN CLAIR
EIP-7702, créé en mai 2024, est Final et en production depuis Pectra, le 7 mai 2025. Il permet à un EOA Un « externally owned account » : un compte Ethereum classique, contrôlé par une seule clé privée. Voir le glossaire de signer une Autorisation Le message signé qui fait pointer un EOA vers un délégué. Il indique la chaîne, l’adresse du délégué et un nonce. Voir le glossaire qui le fait pointer vers un Délégué Avec EIP-7702, le contrat vers lequel pointe un compte ordinaire, et dont il exécute le code comme si c’était le sien. Voir le glossaire. L’ancienne clé marche toujours. La spec est sans détour sur le risque :
« A poorly implemented delegate can allow a malicious actor to take near complete control over a signer’s EOA. »
Un délégué mal écrit peut donc livrer l’EOA à un attaquant. Une délégation persiste jusqu’à son remplacement, et n’est pas annulée si la transaction échoue. Une autorisation avec chain_id 0 est valable sur toutes les chaînes.
ATTENTION
Aucun code d’initialisation ne s’exécute pendant la délégation : un observateur peut envoyer l’appel d’initialisation avant vous, sauf si l’initialisation vérifie la signature de la clé de l’EOA sur ses données d’initialisation. Le stockage survit aussi à un changement de délégué, d’où la recommandation d’utiliser des espaces de noms ERC-7201.
Si le délégué est aussi un compte 4337, ERC-4337 ajoute une exigence impérative (un MUST) : sa fonction d’initialisation n’accepte que les appels de entryPoint.senderCreator(). La raison : l’EntryPoint ne peut pas savoir si un compte 7702 a déjà été initialisé.
Coming up next: Quelqu’un exploite-t-il déjà ce risque ?
Ce que les attaquants font déjà des délégations 7702
EN BREF Un article de USENIX Security ’26 associe plus de 63 % des autorisations 7702 étudiées à des attaques malveillantes visant des EOA.
Les chiffres viennent d’un article de USENIX Security ’26. Certains attaquants ont redélégué leurs propres comptes vers des contrats bénins après une attaque, pour échapper à la détection. Juger un compte demande donc tout son historique d’autorisations, pas seulement son code actuel.
ATTENTION
Vos contrats utilisent msg.sender == tx.origin comme garantie d’un « appel direct » ? Depuis 7702, précise la spec, ce test identifie toujours un EOA, mais ne garantit plus l’appel de premier niveau. Les protections qui en dépendent tombent, comme l’anti-sandwich et l’anti-réentrance.
L’article compte 124 contrats malveillants dans sa catégorie d’attaques visant des contrats, où un compte mis à niveau garde son identité d’EOA pour passer ce genre de contrôle.
Cinq contrôles avant que le wallet signe
EN BREF Chaque contrôle s’appuie sur la spec, mais refuser chain_id 0 et tenir une liste d’autorisation relèvent de la politique du wallet, pas du protocole.
Cette liste ne doit pas reposer sur l’utilisateur : l’article note que, dans les interfaces de wallet courantes, celui-ci ne voit parfois qu’un résumé du type « upgrade account », sans l’adresse ni le code du délégué.
AVANT QUE LE WALLET SIGNE
Étape 1. Demande. Une dapp demande au wallet de signer une autorisation 7702.
- Demande Une dapp demande au wallet de signer une autorisation 7702.
- Chaîne : refusée chain_id 0 est valable sur toutes les chaînes : le wallet refuse l’autorisation, comme pour toute autre chaîne que celle-ci.
- Nonce Si l’EOA envoie aussi la transaction, prenez son nonce plus un : celui de l’émetteur augmente d’abord. Une adresse de délégué à zéro est une remise à zéro : rien d’autre à vérifier.
- Liste Le délégué doit figurer sur votre liste de contrats audités.
- Code, puis signature Le code déployé doit correspondre à la version auditée. Alors seulement, le wallet signe.
OBJET OBTENU
Vérifier avant de signer
FAQ
Signez une nouvelle autorisation vers l’adresse zéro, qu’EIP-7702 traite comme une remise à zéro : le code revient au hash de code vide. Le stockage de l’ancien délégué reste. Choisissez un délégué sans risque de collision, ou videz d’abord ce stockage avec un contrat prévu pour cela.
Lisez son code. Un EOA délégué porte un marqueur, 0xef0100 suivi de l’adresse du délégué. Lisez aussi ses autorisations passées, car le code actuel seul peut être trompeur.
Sources : EIP-7702, ERC-4337, Huang et al., USENIX Security ’26.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi une délégation 7702 revient à confier le compte, et quelles règles de la spec rendent cela risqué.
- Ce que montrent les données de terrain et les cinq contrôles qu’un wallet devrait faire avant de signer, dont deux relèvent de sa politique.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Une dapp n’admet un appelant que s’il est le compte qui a signé la transaction, pour écarter les comptes programmables. Est-ce encore efficace ?
Non. Ce test identifie toujours un EOA, mais depuis 7702 cet EOA peut exécuter le code d’un délégué : il ne prouve plus que l’appel est direct.
Vous avez fini tous les niveaux publiés de cette série. Retour à la carte de la série
Ingénieur web3 x IA, 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.
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.