EIP-7702 permet à un compte Ethereum contrôlé par une clé privée de déléguer l’exécution à un contrat. Ce mécanisme peut faciliter les opérations groupées, la prise en charge du gas par un tiers et des permissions applicatives plus souples. La conséquence de sécurité est essentielle : vous ne choisissez pas seulement un destinataire autorisé à dépenser un token, mais du code exécuté dans le contexte de votre compte.
La délégation ne disparaît pas automatiquement à la fin d’une transaction. Elle peut rester active jusqu’à son remplacement ou son retrait correct. Une signature ne doit donc pas être acceptée simplement parce qu’elle promet du gas gratuit, un airdrop ou une activation pratique. Voici comment distinguer les autorisations et comprendre les vérifications, sans improviser une procédure de récupération universelle.
EIP-7702 : compte, clé privée et code délégué
Un compte externe, ou EOA, est traditionnellement contrôlé par une clé privée. Le nouveau mécanisme permet d’indiquer un contrat dont le code s’exécute dans le contexte de ce compte. L’adresse reste identique et la clé d’origine conserve un rôle fondamental. Vous n’obtenez pas automatiquement un nouveau portefeuille plus sûr.
Ce qui change est le comportement du compte. Une bonne implémentation peut ajouter des fonctions utiles, mais leur fiabilité dépend du code choisi et de ses contrôles. La délégation constitue le mécanisme de base. Les plafonds de dépense, les clés de session ou la récupération relèvent de l’implémentation, pas d’une garantie générale du protocole.
Pour distinguer contrôle des clés et service de conservation, consultez le guide des wallets crypto. Une interface plus simple ne dispense pas de comprendre qui peut signer et ce qu’autorise réellement chaque demande.
Les améliorations possibles au quotidien
Le batching regroupe plusieurs opérations dans une même exécution. Une application pourrait organiser une approbation de token puis un échange dans un parcours moins fragmenté. Il faut néanmoins vérifier que le code réalise exactement le comportement prévu. Regrouper des actions ne les rend pas toutes sûres ou économiquement intéressantes.
La prise en charge du gas par un tiers peut éviter d’acheter de l’ETH immédiatement avant une opération. Elle ne supprime pas le coût : quelqu’un le paie. Le service peut le récupérer au moyen de commissions, de conditions commerciales ou d’un autre actif. Regardez le prix complet plutôt que de considérer l’étiquette « gasless » comme une preuve de gratuité.
Le portefeuille peut aussi construire des permissions limitées au-dessus du code délégué. Une clé de session pourrait être réservée à une application ou soumise à un plafond. Ces restrictions doivent être réellement appliquées. La description d’un site ne suffit pas : quel code les impose et qui peut modifier ce code ou sa configuration ?
Ce n’est pas une simple approbation de token
Une approbation ERC-20 permet à un spender de dépenser une quantité définie d’un token donné. Permit et Permit2 suivent d’autres chemins d’autorisation, avec des pouvoirs définis par leurs contrats. La délégation change plutôt le code exécuté dans le contexte du compte. Ces niveaux de sécurité sont différents, même si toutes les interfaces demandent une signature.
| Action | Élément à examiner | Question principale |
|---|---|---|
| Approbation de token | Spender et montant | Qui peut dépenser ce token ? |
| Permit ou Permit2 | Signature et permissions du système | Quels actifs et quelles limites ? |
| Délégation | Code associé au compte | Quelle implémentation gouverne l’exécution ? |
Le guide des signatures Permit2 et de leur révocation aide à séparer ces notions. Révoquer une approbation ne retire pas automatiquement une délégation. Retirer une délégation ne supprime pas non plus toutes les approbations existantes. Il faut identifier la permission concernée au lieu de traiter toutes les signatures comme équivalentes.
La persistance est le point à retenir
Dans sa forme définitive, la délégation est persistante. La considérer comme une permission limitée au clic actuel minimise ses conséquences. Une signature peut autoriser une modification présentée dans une transaction, et l’implémentation déléguée peut rester associée au compte après cette exécution.
Le traitement de l’autorisation et la réussite de l’opération suivante sont deux étapes distinctes. Une exécution qui échoue n’annule pas nécessairement la délégation déjà traitée. Ne déduisez pas l’état complet du compte d’une simple mention « failed ». Vérifiez ce que le portefeuille et la chaîne indiquent sur le compte lui-même.
Imaginez un échange sponsorisé qui échoue, puis un utilisateur qui ferme la page. Il n’est pas prudent de supposer que tout est revenu à l’état précédent. La vérification doit porter aussi sur une éventuelle délégation installée, pas seulement sur le solde ou le reçu de l’échange. Le message d’erreur peut décrire une opération sans décrire toutes ses conséquences.
Adresse du contrat, réseau et nonce
L’autorisation contient des informations sur l’implémentation choisie, son périmètre réseau et le nonce du compte. Ce sont des éléments importants. Un contrat peut être examiné sur une chaîne mais absent, différent ou non vérifié sur une autre. Une adresse ressemblant à une adresse officielle ne constitue pas une preuve.
Le protocole accepte aussi un chain ID égal à zéro, qui ne limite pas l’autorisation à une seule chaîne. Cela ne signifie pas que chaque signature fonctionne partout : les conditions de nonce et le support réseau restent nécessaires. Cela signifie que le portefeuille doit expliquer ce périmètre au lieu de le cacher dans une demande générique.
Il n’est pas raisonnable d’exiger que chaque utilisateur reconstruise l’encodage d’une signature. Utilisez des implémentations documentées et prises en charge par le portefeuille, vérifiez le réseau et refusez les adresses de délégation arbitraires proposées par une application. La documentation officielle vaut davantage qu’une fenêtre promotionnelle.
Le risque principal : un code non fiable
Du code exécuté dans le contexte du compte peut avoir des conséquences bien plus larges qu’une lecture du solde. Une implémentation malveillante ou défectueuse peut compromettre les actifs et les permissions. Un code source vérifié sur un explorateur aide à identifier le déploiement, mais cette vérification n’est pas un audit de sécurité.
Demandez quelles analyses indépendantes existent, quelles parties peuvent être mises à jour et qui contrôle ces changements. Un audit couvre une version et un périmètre précis, pas toutes les configurations futures. Même un portefeuille connu doit expliquer l’implémentation proposée et la réponse prévue en cas de problème.
Ne signez pas une délégation arbitraire pour « vérifier le wallet », recevoir une récompense ou résoudre une prétendue panne. Les fraudeurs peuvent présenter un changement profond comme une formalité. Si l’interface ne distingue pas connexion au site et contrôle du compte, il vaut mieux s’arrêter que valider pour essayer.
Comprendre le retrait sans croire à une remise à zéro
Une nouvelle autorisation visant l’adresse zéro peut retirer le code de délégation. Utilisez des outils fiables et compatibles, puis vérifiez le résultat sur la bonne chaîne. Ne suivez pas les instructions d’inconnus et n’importez jamais votre phrase de récupération dans un prétendu service de nettoyage.
Ce retrait n’est pas une remise à zéro universelle. Il ne supprime pas automatiquement le stockage du compte, les approbations de tokens ou toutes les permissions accordées à d’autres applications. Ces éléments peuvent nécessiter des contrôles séparés. Si la clé privée a été compromise, retirer la délégation ne la rend pas secrète à nouveau.
Les autorisations signées mais pas encore utilisées demandent aussi de l’attention. Déconnecter un site ne détruit pas les signatures déjà transmises. La réponse dépend des outils du portefeuille et de l’état du compte. Pour des fonds importants ou un incident actif, cherchez une assistance technique qualifiée plutôt que d’enchaîner des manipulations mal comprises.
Hardware wallet : vérifier la compatibilité réelle
Un appareil matériel protège la conservation de la clé, mais ne rend pas inoffensive une signature validée par l’utilisateur. Si son écran n’explique pas l’autorisation ou affiche des données incompréhensibles, la sécurité pratique diminue. Vérifiez le support du fabricant et du logiciel qui communique avec l’appareil.
Notre guide des hardware wallets rappelle cette limite : isoler la clé de l’ordinateur est utile, mais il faut toujours comprendre la validation. Ne contournez pas une incompatibilité en supprimant des avertissements ou en suivant une configuration fournie par un site inconnu.
Les questions avant d’activer la délégation
- Le portefeuille documente-t-il le support du réseau concerné ?
- L’implémentation est-elle examinée par le portefeuille plutôt qu’arbitraire ?
- Qui paie le gas et quels autres frais restent dus ?
- Les limites annoncées sont-elles appliquées et modifiables par qui ?
- Connaissez-vous les outils prévus pour vérifier et retirer la délégation ?
- Avez-vous séparé délégation, approbations et signatures déjà transmises ?
Pour un premier essai, limitez le périmètre et ne prenez pas une opération réussie pour une preuve de sécurité complète. Un échange peut fonctionner alors que le compte conserve des pouvoirs plus étendus que prévu. Notez le réseau et l’implémentation, lisez la description du nouvel état du compte et vérifiez les futurs parcours de signature. L’expérimentation ne remplace pas la compréhension.
EIP-7702 peut rendre un compte existant plus flexible. La bonne décision n’est pas d’activer chaque nouveauté, mais de comprendre le code autorisé et les contrôles qui le limitent. Une meilleure expérience n’est utile que si elle ne cache pas une décision de sécurité plus large que celle que vous pensiez prendre.
Sources primaires vérifiées le 30 septembre 2026 : spécification EIP-7702 ; explication Ethereum sur Pectra et la délégation ; documentation Ethereum. Ce texte explique les risques ; il ne constitue ni une procédure universelle de récupération ni un conseil financier.