EIP-7702 est une amélioration des fonctionnalités de compte introduite dans la mise à niveau Pectra d’Ethereum. Elle permet aux comptes détenus en externe (EOA) d’exécuter du code de smart contract via un mécanisme de délégation, tout en conservant leurs adresses existantes et le contrôle de leurs clés privées. Les wallets traditionnels peuvent ainsi accéder à certaines fonctionnalités des comptes intelligents, comme le regroupement de transactions, le paiement des frais de Gas par un tiers et une gestion plus précise des autorisations par l’intermédiaire de contrats spécifiques.
Toutefois, l’extension des capacités d’exécution d’un compte modifie également la limite de sécurité du wallet. Auparavant, les utilisateurs se préoccupaient principalement des fuites de clés privées, des approbations de tokens malveillantes et des transferts par phishing. Dans un environnement EIP-7702, une seule signature de délégation non sécurisée peut modifier la manière dont le wallet exécute les transactions ultérieures. Même si les utilisateurs n’initient pas eux-mêmes de transferts ordinaires, des attaquants peuvent utiliser des contrats de délégation malveillants pour transférer automatiquement des actifs. Cet article explique le mécanisme technique d’EIP-7702, les vecteurs d’attaque associés aux délégations malveillantes, ainsi que les démarches à suivre pour enquêter et réagir après des transferts non autorisés depuis un wallet.
EIP-7702 permet aux wallets ordinaires de déléguer leur logique d’exécution à des smart contracts. Les utilisateurs peuvent accéder à des fonctionnalités telles que les transactions groupées, la prise en charge des frais de Gas et la gestion des autorisations sans changer l’adresse de leur wallet existant, mais cela introduit également de nouveaux risques de sécurité liés aux smart contracts.
Une délégation malveillante diffère d’une approbation de token ordinaire. Des attaquants peuvent utiliser des signatures de phishing pour faire exécuter à une adresse de wallet une logique de contrat malveillante et transférer des ETH, des tokens ERC-20 ou d’autres actifs.
Les transferts automatiques ne signifient pas nécessairement que la clé privée a été compromise. Une délégation malveillante peut accorder aux attaquants des autorisations d’exécution, mais une fuite de clé privée peut aussi survenir simultanément. Ces possibilités doivent être examinées séparément.
La révocation d’une délégation malveillante et celle d’une approbation ERC-20 sont deux opérations distinctes. Une délégation EIP-7702 peut être effacée au moyen d’une nouvelle autorisation valide, mais les outils ordinaires de gestion des approbations de tokens peuvent ne pas prendre en charge cette opération.
La clé de la récupération d’un wallet consiste à identifier la source du contrôle. Si seule une délégation malveillante existe et que la clé privée reste sécurisée, l’effacement de la délégation peut empêcher toute exploitation ultérieure. Si la clé privée ou la phrase de récupération a été compromise, les actifs doivent être transférés en priorité vers un wallet entièrement nouveau.
Les comptes Ethereum comprennent principalement les comptes détenus en externe (EOA) et les comptes de smart contracts. Les EOA traditionnels sont contrôlés par des clés privées et initient généralement des transactions au moyen de signatures, tandis que les comptes de smart contracts peuvent exécuter une logique plus complexe fondée sur des programmes préécrits. Chaque type de compte possède ses propres caractéristiques : les EOA sont simples à utiliser, mais ne prennent pas nativement en charge une gestion complexe des autorisations, tandis que les comptes de smart contracts sont flexibles, mais nécessitent généralement un déploiement et une gestion supplémentaires.
EIP-7702 introduit un nouveau type de transaction et un mécanisme d’autorisation permettant à un EOA de pointer vers du code de smart contract déjà déployé. Une fois la délégation activée, les opérations pertinentes exécutées pour ce compte peuvent utiliser la logique du contrat cible, tandis que le compte conserve son adresse et sa clé privée d’origine. Les utilisateurs peuvent ainsi accéder aux fonctionnalités des comptes intelligents sans déplacer l’ensemble de leurs actifs vers une nouvelle adresse.
Les utilisations normales de cette conception comprennent l’exécution de plusieurs opérations simultanément, la réduction de la complexité liée à la gestion des frais de Gas et la fourniture d’une expérience de transaction plus flexible grâce à des sous-autorisations limitées. Toutefois, le contrat de délégation participe au processus d’exécution du compte. Si son code comporte des vulnérabilités, si la conception de ses autorisations est inappropriée ou si l’utilisateur délègue directement à un contrat malveillant, le wallet peut être exposé à des risques qui dépassent le cadre des approbations de tokens ordinaires.
Le principal risque d’EIP-7702 est qu’un utilisateur puisse signer une autorisation permettant à un compte d’utiliser la logique d’exécution d’un smart contract, plutôt que de signer uniquement une transaction précise. Des attaquants peuvent utiliser de fausses pages de mise à niveau de wallet, des portails de réclamation d’airdrops ou des invites de vérification de sécurité pour inciter les utilisateurs à signer des autorisations de délégation. Une fois l’autorisation soumise et activée on-chain, l’adresse du wallet peut fonctionner selon les règles définies par le contrat malveillant.
Par exemple, un utilisateur peut penser réclamer uniquement une récompense, mais déléguer son wallet à un contrat contrôlé par un attaquant pendant le processus de signature. Le contrat malveillant peut contenir une logique de transfert d’actifs, de contournement d’autorisations ou de vidage automatique. Lorsque l’attaquant déclenche ultérieurement l’appel concerné, le contrat peut utiliser les autorisations d’exécution du compte pour transférer des actifs. Dans certaines conceptions, l’attaquant peut même attendre que le wallet reçoive de nouveaux ETH, puis les transférer via une transaction ultérieure, donnant à la victime l’impression que le wallet comporte un mécanisme de prélèvement automatique impossible à supprimer.
Il est important de noter qu’EIP-7702 n’écrit pas directement de code arbitraire dans un wallet et que toute délégation ne transfère pas automatiquement des actifs. Le protocole enregistre un indicateur de délégation qui pointe vers un contrat cible. La possibilité de transférer des fonds dépend du code du contrat cible, de son état d’initialisation, de ses autorisations d’exécution et de ses conditions de déclenchement. Les délégations malveillantes sont dangereuses, car elles peuvent donner à un programme non fiable le contrôle des capacités d’exécution réelles du compte, alors que les utilisateurs peuvent ne pas être en mesure de comprendre ce changement à partir d’une interface de signature ordinaire.

Une approbation ERC-20 traditionnelle permet généralement à une adresse ou à un contrat spécifié d’utiliser un token donné dans la limite d’un montant déterminé. Par exemple, lors d’une opération sur un échange décentralisé, un utilisateur peut autoriser un contrat de routeur à dépenser une certaine quantité d’USDT. Si le montant approuvé est trop élevé et que le contrat autorisé est compromis, les tokens correspondants de l’utilisateur peuvent être transférés. Toutefois, ce type d’approbation concerne généralement un contrat de token spécifique et un montant d’approbation donné.
Une délégation EIP-7702 s’applique à la logique d’exécution d’un compte. Elle ne permet pas simplement à un contrat de dépenser un type de token. Elle peut modifier la manière dont le compte traite les appels, vérifie les autorisations et exécute plusieurs opérations. Si un contrat malveillant ne dispose pas de contrôles d’autorisation appropriés, il peut affecter les ETH, les tokens et d’autres actifs on-chain. Par conséquent, une délégation malveillante EIP-7702 ne doit pas être considérée simplement comme un autre type d’approbation illimitée.
| Critère de comparaison | Approbation de token ERC-20 | Délégation EIP-7702 |
|---|---|---|
| Fonction principale | Permet à une adresse spécifiée d’utiliser des tokens | Permet à un EOA d’utiliser la logique d’exécution d’un contrat spécifié |
| Principal périmètre d’impact | Tokens spécifiques et montant de l’approbation | Dépend du contrat de délégation et peut concerner l’ensemble du compte |
| Risque courant | Un contrat malveillant appelle des transferts de tokens | Du code malveillant obtient des capacités d’exécution du compte |
| Comment la gérer | Ajuster ou révoquer l’approbation de token | Effacer ou remplacer la délégation du compte |
| La clé privée contrôle-t-elle toujours le compte ? | Oui | Oui, mais le code délégué peut également exécuter des opérations |
Les deux peuvent également exister simultanément. Un wallet peut conserver des approbations ERC-20 dangereuses tout en étant affecté par une délégation malveillante EIP-7702. Par conséquent, après un transfert non autorisé, les utilisateurs ne doivent pas vérifier uniquement les enregistrements d’approbation de tokens. Ils doivent également confirmer si l’adresse du wallet possède actuellement du code délégué.
Un transfert rapide après la réception d’ETH par un wallet ne signifie pas nécessairement qu’un attaquant utilise manuellement le wallet en temps réel. Un contrat de délégation malveillant peut fonctionner avec un programme de surveillance automatisé, permettant à l’attaquant de soumettre une transaction ultérieure dès que des fonds sont détectés à l’adresse cible. Pour un wallet disposant déjà d’autorisations d’exécution malveillantes, l’attaquant peut automatiser la surveillance, le déclenchement et les transferts, créant ainsi un processus continu de vidage d’actifs.
Cette attaque ressemble à un Sweeper traditionnel reposant sur une fuite de clé privée, mais le chemin de contrôle n’est pas exactement le même. Un Sweeper traditionnel s’appuie généralement sur une clé privée divulguée pour signer des transactions, tandis qu’une délégation malveillante EIP-7702 peut transférer des actifs grâce à des autorisations d’exécution de contrat déjà actives. Les deux situations peuvent se présenter sous la forme de fonds transférés peu après leur arrivée. Par conséquent, la seule vitesse de transaction ne permet pas de déterminer si l’attaquant possède la clé privée.
Certaines délégations malveillantes peuvent également concerner plusieurs chaînes compatibles avec l’EVM. Les autorisations EIP-7702 incluent un identifiant de chaîne, généralement utilisé pour limiter le périmètre d’une autorisation. Toutefois, une autorisation ayant un identifiant de chaîne égal à 0 peut s’appliquer sur plusieurs chaînes. Cela signifie qu’une autorisation non sécurisée signée sur un réseau peut créer des risques sur d’autres réseaux éligibles. Après avoir détecté un transfert non autorisé, les utilisateurs doivent vérifier l’état de délégation de l’adresse concernée sur d’autres réseaux EVM, et pas uniquement sur la chaîne où la perte initiale s’est produite.
Pour déterminer si un wallet est affecté par une délégation malveillante, il faut d’abord distinguer les transferts ordinaires, les approbations de tokens et les délégations de compte. EIP-7702 introduit les transactions de type 4, qui peuvent contenir une liste d’autorisations. Les utilisateurs peuvent utiliser un explorateur de blocs ou un outil de sécurité de wallet prenant en charge EIP-7702 afin de consulter les informations d’autorisation dans les transactions concernées et de vérifier si le compte pointe actuellement vers un contrat de délégation.
Si une délégation EIP-7702 a été configurée pour une adresse de wallet, le code de son compte contient généralement un indicateur de délégation spécifique pointant vers l’adresse du contrat cible. Cela ne signifie toutefois pas que la délégation est nécessairement malveillante, car des fonctionnalités légitimes de smart wallet peuvent également utiliser EIP-7702. Pour approfondir l’évaluation, les utilisateurs doivent vérifier si le contrat cible correspond à une implémentation reconnue par le fournisseur du wallet, si son code a été vérifié, s’il contient une logique inhabituelle de transfert d’actifs et si la délégation est survenue à peu près au même moment qu’une signature suspecte ou qu’une perte d’actifs.
Les utilisateurs peuvent également examiner la manière dont les transactions non autorisées ont été déclenchées. Des actifs ont-ils quitté le wallet sans action de l’utilisateur ? Une adresse inconnue a-t-elle appelé le wallet à plusieurs reprises ? Les fonds ont-ils continué d’être envoyés vers la même adresse de réception ? Si l’une de ces conditions s’applique, conservez les hachages de transaction, les enregistrements d’autorisation, les adresses des contrats cibles et les informations relatives aux flux de fonds. Toutefois, une seule transaction non autorisée ne suffit pas à établir de manière concluante que l’attaque provient d’EIP-7702. Les fuites de clés privées, les approbations de tokens malveillantes et les autres risques liés aux smart contracts doivent également être examinés.
Après avoir découvert une délégation suspecte, cessez d’abord d’utiliser le wallet pour de nouvelles opérations à haut risque. Ne transférez pas d’actifs supplémentaires vers celui-ci et ne continuez pas à signer des transactions provenant de sites inconnus. Utilisez ensuite un client de wallet ou un outil de sécurité fiable pour vérifier l’état actuel de la délégation et confirmer l’existence éventuelle d’un contrat cible inconnu. Si le wallet que vous utilisez ne propose pas encore de méthode permettant d’effacer une délégation EIP-7702, ne consultez pas sans précaution des sites inconnus proposant une prétendue « solution en un clic ». Ces services peuvent eux-mêmes vous inciter à signer une nouvelle autorisation malveillante.
Selon le mécanisme du protocole, EIP-7702 permet à un compte de définir l’adresse zéro comme cible de délégation au moyen d’une nouvelle autorisation valide, ce qui efface l’indicateur de délégation actuel. Les utilisateurs peuvent également remplacer la délégation par une autre implémentation au moyen d’une autorisation valide. Toutefois, pour un wallet ordinaire ayant déjà subi une attaque, le rétablissement d’un état d’exécution de compte clair et fiable facilite généralement l’évaluation des risques. Notez que la révocation d’une approbation ERC-20 ne révoque pas une délégation EIP-7702. Ces opérations doivent être gérées séparément.
La réussite de l’opération dépend également du fait que l’utilisateur conserve ou non le contrôle sécurisé de la clé privée et que la transaction effaçant la délégation puisse être incluse avec succès on-chain. Si l’attaquant dispose également de la clé privée, il peut signer une autre délégation malveillante ou transférer directement les actifs. Pour les wallets affectés par un Sweeper automatisé, une transaction de révocation ordinaire peut également faire face à une concurrence entre transactions et au risque que ses fonds destinés aux frais de Gas soient transférés. Dans cette situation, ne réalimentez pas à plusieurs reprises l’adresse compromise et ne tentez pas d’effectuer d’autres transactions. Envisagez plutôt de demander l’aide de professionnels de la sécurité fiables et prenez les mesures de protection appropriées après avoir pleinement évalué les risques.
L’effacement d’une délégation malveillante peut supprimer le chemin d’exécution délégué actuel du compte, mais cela ne signifie pas que tous les risques de sécurité du wallet ont disparu. Si l’attaquant a obtenu uniquement une autorisation de délégation par phishing, tandis que la clé privée et la phrase de récupération de l’utilisateur restent sécurisées, l’effacement de la délégation peut empêcher le contrat malveillant de continuer à exécuter des opérations via le chemin initial. Toutefois, les utilisateurs doivent toujours vérifier les autres approbations de tokens, les signatures malveillantes, les paramètres d’autorisation non résolus ou les informations de compte compromises.
Si l’attaquant a obtenu la clé privée ou la phrase de récupération, le wallet d’origine ne doit pas être considéré comme sécurisé, même si l’utilisateur efface avec succès la délégation. L’attaquant peut toujours utiliser la clé privée pour initier des transferts ordinaires ou signer une nouvelle autorisation EIP-7702. Dans cette situation, l’approche la plus fiable consiste à créer un wallet contrôlé par une phrase de récupération entièrement nouvelle et à transférer les actifs restants lorsque cela peut être fait en toute sécurité. Le simple fait de changer d’application de wallet, de supprimer des extensions de navigateur ou d’importer à nouveau la phrase de récupération d’origine ne résoudra pas une compromission existante de la clé privée.
En outre, l’effacement d’une délégation ne peut généralement pas annuler des transactions on-chain déjà finalisées ni récupérer automatiquement les actifs volés. La récupération des actifs peut toujours nécessiter une analyse on-chain, la coopération des échanges, une preuve de propriété et des procédures juridiques. Les utilisateurs doivent considérer la prévention de nouvelles pertes et la récupération des pertes historiques comme deux objectifs distincts. Ils ne doivent pas supposer que les fonds déjà transférés reviendront automatiquement après que le wallet semble à nouveau fonctionner normalement.
Les risques de sécurité liés à EIP-7702 ne signifient pas que les utilisateurs doivent éviter complètement les fonctionnalités de compte intelligent. Un mécanisme de délégation correctement conçu peut améliorer l’expérience de wallet en réduisant les signatures répétées, en prenant en charge les transactions groupées et en activant des autorisations de transaction limitées. Les principaux critères sont la capacité des utilisateurs à identifier la cible de l’autorisation, à comprendre la portée de ses autorisations et à confirmer que le contrat de délégation est fiable.
Pour un usage quotidien, privilégiez l’activation des fonctionnalités de compte intelligent depuis le client de wallet lui-même. Ne signez pas sans précaution une autorisation de délégation inconnue en raison d’un airdrop, d’une réclamation de points ou d’une prétendue mise à niveau de compte. Lorsqu’une invite concerne EIP-7702, Set Code, Delegate ou des modifications d’autorisation similaires, vérifiez l’adresse du contrat cible, le réseau applicable et le contenu de l’autorisation. Si vous ne pouvez pas vérifier l’origine d’un contrat, ne le considérez pas comme sans risque, même si la page indique que la transaction ne nécessite pas de frais de Gas.
Les utilisateurs détenant des actifs importants peuvent également adopter une approche de gestion des fonds par niveaux en séparant les avoirs à long terme des wallets de trading fréquemment utilisés. Un wallet d’usage quotidien peut être utilisé pour la DeFi, les tests d’applications et l’essai de nouveaux protocoles, tandis que les actifs à long terme devraient de préférence être stockés dans un environnement doté d’autorisations plus simples et utilisé moins fréquemment. La vérification régulière des délégations de compte, des approbations de tokens et des enregistrements de transactions non autorisées peut également aider à identifier plus rapidement la source d’un problème de sécurité.
EIP-7702 modifie l’hypothèse traditionnelle selon laquelle « les signatures de clés privées contrôlent les transactions » dans les wallets. Les utilisateurs détiennent toujours la clé privée, mais le compte peut exécuter du code de contrat externe via une délégation. Par conséquent, la sécurité du wallet ne se limite plus à la protection de la clé privée : elle s’étend à la protection de la cible de délégation, de la logique d’exécution et de la configuration des autorisations. Pour les utilisateurs ordinaires, les conséquences de la signature d’une autorisation ne peuvent plus être évaluées uniquement selon qu’elle transfère des fonds ou approuve un token particulier.
Des recherches en sécurité menées en 2026 ont identifié plusieurs schémas de délégation malveillante liés à EIP-7702, notamment l’obtention d’autorisations par phishing, le transfert continu d’actifs par le biais de contrats Sweeper malveillants et l’extension du périmètre d’attaque au moyen d’autorisations inter-chaînes. Des recherches associées ont également révélé que certains comptes affectés n’avaient pas effacé rapidement leurs délégations malveillantes, ce qui indique que le risque qui en résulte peut persister après la perte initiale d’actifs. Toutefois, le nombre de délégations malveillantes identifiées dans les recherches, le nombre de comptes affectés et les pertes financières réelles ne doivent pas être considérés comme équivalents. Ces chiffres doivent être compris séparément.
À l’avenir, les fournisseurs de wallets devront afficher plus clairement les contrats de délégation et la portée de leurs autorisations, et empêcher les sites non fiables d’inciter directement les utilisateurs à effectuer des délégations à haut risque. Les explorateurs de blocs, les outils de détection de sécurité et l’infrastructure des comptes intelligents devront également améliorer leur capacité à identifier l’activité EIP-7702. Pour les utilisateurs, le changement le plus important consiste à considérer une signature de délégation comme une opération à haut risque susceptible d’affecter les autorisations d’exécution de l’ensemble du wallet, plutôt que comme une simple demande de connexion à un site web.
EIP-7702 confère aux wallets Ethereum traditionnels des capacités d’exécution de smart contracts plus flexibles, rendant possibles les transactions groupées, la prise en charge des frais de Gas et la gestion fine des autorisations. Toutefois, ce même mécanisme peut également être exploité par des attaquants pour modifier la logique d’exécution d’un wallet au moyen d’une délégation malveillante, entraînant des transferts automatiques, un vidage continu des actifs et des risques de sécurité inter-chaînes.
Lorsqu’un wallet subit des transferts non autorisés, les utilisateurs doivent vérifier ses délégations EIP-7702, ses approbations ERC-20 et l’état de sécurité de sa clé privée. Si une délégation malveillante est confirmée, utilisez un outil fiable pour l’effacer ou la remplacer, puis évaluez si les actifs doivent être transférés vers un wallet entièrement nouveau. La révocation d’une délégation peut aider à empêcher l’exploitation ultérieure d’un chemin d’exécution spécifique, mais elle ne peut pas garantir que la clé privée est sécurisée ni récupérer automatiquement les actifs déjà transférés.
Pas nécessairement. Des attaquants peuvent utiliser le phishing pour inciter les utilisateurs à signer une autorisation de délégation, puis utiliser un contrat malveillant pour exécuter des transactions sans obtenir directement la clé privée. Toutefois, si la clé privée a été compromise, les attaquants peuvent également utiliser EIP-7702 pour étendre leurs capacités d’attaque. Ces possibilités doivent être examinées séparément.
Une délégation malveillante peut conduire le compte à exécuter des opérations conformément à une logique de contrat contrôlée par l’attaquant. L’attaquant peut déclencher des transferts au moyen d’appels ultérieurs ; des actifs peuvent donc être perdus même lorsque l’utilisateur n’a pas initié de transfert ordinaire.
EIP-7702 permet de définir l’adresse zéro comme cible de délégation via une nouvelle autorisation valide, ce qui efface la délégation. L’opération doit être effectuée au moyen d’un wallet ou d’un outil de sécurité fiable prenant en charge cette fonctionnalité. Ne communiquez pas votre clé privée ou votre phrase de récupération à un site web inconnu.
Pas nécessairement. Les outils Revoke ordinaires sont généralement utilisés pour gérer les approbations ERC-20 et d’autres approbations de tokens, tandis qu’une délégation EIP-7702 concerne les autorisations d’exécution du compte. À moins que l’outil ne prenne explicitement en charge la gestion des délégations EIP-7702, la révocation des approbations de tokens ne peut pas remplacer l’effacement de la délégation malveillante.
Cela dépend de la source du risque. Si la clé privée reste sécurisée et que la délégation malveillante a été effectivement effacée, le wallet d’origine peut revenir à un état d’exécution normal. Toutefois, si la clé privée ou la phrase de récupération a été compromise, utilisez un wallet nouvellement généré et transférez les actifs restants lorsque cela peut être fait en toute sécurité.
Oui. L’identifiant de chaîne dans une autorisation peut limiter les réseaux applicables, mais une autorisation ayant un identifiant de chaîne égal à 0 peut être utilisée sur plusieurs réseaux compatibles. Après avoir découvert une délégation malveillante, vérifiez l’état de l’adresse concernée sur d’autres réseaux EVM.
* Les informations ne sont pas destinées à être et ne constituent pas des conseils financiers ou toute autre recommandation de toute sorte offerte ou approuvée par Gate.
* Cet article ne peut être reproduit, transmis ou copié sans faire référence à Gate. Toute contravention constitue une violation de la loi sur le droit d'auteur et peut faire l'objet d'une action en justice.





