Comment l’EIP-7702 affecte-t-il la sécurité des wallets ? Comprendre les risques de délégation et de vol d’actifs

EIP-7702 constitue une amélioration importante du protocole dans le développement de l’abstraction de compte sur Ethereum. Il permet aux wallets EOA traditionnels de déléguer la logique d’exécution de contrats intelligents par autorisation, ce qui permet aux adresses ordinaires de prendre en charge les transactions par lots, le parrainage des frais de gas et une gestion de compte plus flexible. Contrairement à la création d’un tout nouveau wallet de contrat intelligent, EIP-7702 préserve les adresses de wallet et les actifs existants des utilisateurs, tout en modifiant la manière dont le compte exécute les transactions.

Toutefois, l’extension des capacités d’un compte modifie également sa frontière de sécurité. Auparavant, les utilisateurs se concentraient principalement sur l’exposition éventuelle de leurs clés privées, sur le niveau excessif des autorisations Approve de jetons et sur la présence de transferts anormaux dans les signatures de transaction. EIP-7702 introduit un autre type d’opération que les utilisateurs doivent comprendre : au moyen d’une seule autorisation, ils peuvent permettre à leur adresse d’exécuter un code de contrat spécifié dans des transactions ultérieures. Si ce code est malveillant ou si la délégation est contrôlée par un attaquant, les risques pour les actifs peuvent s’étendre au-delà d’une seule transaction.

Par conséquent, comprendre EIP-7702 ne se limite pas à se concentrer sur l’expérience d’abstraction de compte qu’il offre. Il est également nécessaire d’analyser comment l’autorisation de délégation prend effet, quelles opérations un code malveillant peut effectuer et comment les utilisateurs ordinaires peuvent identifier et supprimer les délégations dangereuses. Cet article aborde les principes techniques, les vecteurs d’attaque potentiels et les pratiques de sécurité des wallets liés à EIP-7702.

Points clés

• EIP-7702 est une fonctionnalité de compte introduite avec la mise à niveau Pectra d’Ethereum. Elle permet aux comptes détenus en externe traditionnels (Externally Owned Accounts, ou EOA) d’exécuter la logique de contrats intelligents par délégation, sans nécessiter le transfert des actifs vers une nouvelle adresse.

• L’autorisation EIP-7702 diffère d’un Approve ERC-20 classique. La première peut modifier la logique d’exécution d’un compte, tandis que le second accorde généralement à un dépensier l’autorisation d’utiliser une certaine quantité de jetons.

• Le risque lié à une délégation malveillante ne résulte pas nécessairement de l’exposition d’une clé privée. Même si les utilisateurs conservent leurs clés privées, la signature d’une autorisation de délégation dangereuse peut mettre leurs actifs en danger.

• Une délégation EIP-7702 n’expire pas automatiquement après l’exécution d’une seule transaction. La révocation ou le remplacement d’une délégation exige une nouvelle autorisation valide, et l’effacement d’une délégation ne peut pas récupérer les actifs déjà transférés.

• L’évaluation de la sécurité d’EIP-7702 exige plus que la vérification de l’origine d’une signature. Elle implique également de comprendre les autorisations, le comportement du code et les capacités de mise à niveau du contrat délégué.

Qu’est-ce qu’EIP-7702 ? Pourquoi les wallets EOA traditionnels ont-ils besoin d’une exécution déléguée ?

Les comptes Ethereum sont principalement répartis entre les comptes détenus en externe (Externally Owned Accounts, ou EOA) et les comptes de contrats intelligents. Les EOA sont contrôlés par des clés privées et peuvent initier des transactions. Les comptes de contrats intelligents exécutent des opérations conformément au code déployé et peuvent prendre en charge des contrôles d’autorisations et une logique de transaction plus complexes.

Les EOA traditionnels offrent une structure simple et une vaste compatibilité, mais leurs capacités d’exécution sont limitées. Par exemple, les utilisateurs peuvent devoir signer séparément plusieurs transactions pour effectuer un ensemble d’opérations on-chain, ou détenir eux-mêmes des ETH pour payer les frais de gas du réseau. Les wallets de contrats intelligents peuvent améliorer ces expériences, mais ils impliquent souvent le déploiement d’un nouveau compte, la migration des actifs et des exigences de compatibilité supplémentaires.

EIP-7702 fournit une solution différente : il permet à un EOA de déléguer l’exécution du code de compte à la logique d’un contrat intelligent située à une adresse spécifiée, via une autorisation. Les utilisateurs peuvent accéder à certaines fonctionnalités de compte intelligent depuis leur adresse de wallet existante, sans la modifier.

Au niveau du protocole, EIP-7702 introduit un nouveau type de transaction et une liste d’autorisations. Une autorisation admissible peut définir le champ de code d’un EOA sur un indicateur de délégation spécial pointant vers une adresse de contrat spécifiée. Lorsqu’une autre transaction appelle ce compte, Ethereum exécute le code délégué conformément aux règles applicables.

Cette conception confère aux produits de wallet une plus grande flexibilité pour prendre en charge les opérations par lots, la validation flexible des transactions, le parrainage des frais de gas et la gestion des autorisations fondée sur des contrats. Toutefois, EIP-7702 ne fournit pas automatiquement toutes ces capacités. Les fonctionnalités spécifiques dépendent toujours de l’implémentation du contrat délégué.

Comment fonctionne EIP-7702 ? Quel est le lien entre la signature d’autorisation et le contrat délégué ?

L’idée centrale d’EIP-7702 est de séparer la propriété du compte de la logique d’exécution du code. Les utilisateurs continuent de contrôler leurs EOA au moyen de leurs clés privées existantes, mais peuvent utiliser une autorisation conforme au protocole pour préciser quel code de contrat l’adresse doit utiliser.

Les données d’autorisation incluent généralement l’ID de chaîne, l’adresse cible de délégation, le nonce du compte et une signature générée par la clé privée du compte. Lorsque le réseau traite une transaction contenant une liste d’autorisations, il vérifie l’autorisation et met à jour le statut de délégation du compte concerné conformément aux règles du protocole.

Un processus de délégation EIP-7702 typique se compose de quatre étapes :

1. Sélectionner la cible de délégation : le wallet ou l’application détermine l’adresse d’implémentation du contrat intelligent qu’il doit utiliser.

2. Générer la signature d’autorisation : l’utilisateur signe les données d’autorisation pour la cible de délégation spécifiée à l’aide de la clé privée de l’EOA.

3. Traiter l’autorisation on-chain : l’autorisation est incluse dans une transaction compatible avec EIP-7702. Après vérification, le réseau définit l’indicateur de délégation du compte.

4. Exécuter le code délégué : lorsque le compte est appelé ultérieurement, le code du contrat d’implémentation spécifié est exécuté conformément aux règles d’EIP-7702.

Deux concepts faciles à confondre doivent ici être distingués : une signature d’autorisation n’est pas exactement identique à une signature de transaction ordinaire. Une signature de transfert classique sert généralement à approuver une transaction spécifique, tandis qu’une autorisation EIP-7702 définit l’implémentation de code utilisée par un compte. Elle peut affecter le comportement d’exécution de plusieurs transactions ultérieures.

L’adresse cible de délégation ne signifie pas que l’utilisateur a donné sa clé privée à cette adresse, ni que le propriétaire de cette adresse obtient automatiquement l’autorisation de transférer des actifs. Le risque réel dépend de la manière dont le code délégué gère la validation des transactions, les points d’entrée d’exécution et le contrôle d’accès. Si le code permet à un attaquant d’effectuer des opérations sur des actifs sans autorisation supplémentaire du propriétaire du compte, une délégation dangereuse peut devenir un point d’entrée pour le vol d’actifs.

En quoi EIP-7702 diffère-t-il d’ERC-20 Approve ?

Dans les transactions DeFi traditionnelles, les utilisateurs utilisent souvent ERC-20 Approve pour autoriser un échange décentralisé ou un autre contrat intelligent à utiliser un jeton spécifique. Par exemple, un utilisateur peut autoriser un contrat à dépenser jusqu’à 100 USDC. Cette autorisation est généralement enregistrée par le contrat du jeton et contrôle le nombre de jetons qu’un dépensier spécifique peut utiliser.

EIP-7702 opère à un niveau d’autorisation différent. Il ne se contente pas d’approuver un contrat pour dépenser une quantité spécifique de jetons. Il précise plutôt quel code de contrat intelligent le compte exécute. Le code délégué peut inclure la validation des transactions, les transferts d’actifs, les appels par lots et d’autres fonctions de gestion de compte. Son périmètre d’impact potentiel peut donc être plus large.

Une délégation EIP-7702 ne signifie pas que la propriété du wallet est directement transférée à un contrat. Une implémentation de délégation sécurisée peut toujours exiger une signature valide du propriétaire du compte et imposer des limites de transaction, des restrictions temporelles et d’autres mesures de protection.

Toutefois, si un utilisateur autorise un contrat malveillant, sa logique interne peut permettre à un attaquant d’effectuer des opérations que l’utilisateur n’avait pas l’intention d’approuver. Par conséquent, par rapport aux autorisations Approve ordinaires, les vérifications de sécurité EIP-7702 doivent se concentrer davantage sur le code du contrat lui-même que seulement sur le montant autorisé.

Comment une autorisation EIP-7702 malveillante peut-elle entraîner le vol des actifs d’un wallet ?

L’un des principaux risques de sécurité d’EIP-7702 est que des attaquants peuvent utiliser le phishing de signature pour inciter les utilisateurs à approuver des délégations malveillantes. Les attaquants peuvent présenter une demande d’autorisation comme une mise à niveau de wallet, une vérification de compte, une demande de récompense ou une optimisation de transaction, en amenant les utilisateurs à croire qu’ils effectuent une signature ordinaire.

Lorsqu’un utilisateur signe une autorisation valide pointant vers un contrat malveillant, l’attaquant peut la soumettre on-chain. Il est important de noter que la signature d’autorisation elle-même ne modifie pas nécessairement l’état du compte immédiatement. La délégation ne prend effet on-chain qu’après l’inclusion de l’autorisation concernée dans une transaction valide et sa vérification.

Si le code délégué inclut une fonction de transfert d’actifs qu’un attaquant peut appeler, celui-ci peut utiliser cette logique d’exécution pour transférer des ETH ou d’autres jetons depuis le compte.

Un parcours de risque typique peut être résumé comme suit :

1. Inciter à signer : l’attaquant obtient l’autorisation de l’utilisateur pour une cible de délégation malveillante via un faux site web ou une fausse interface d’application.

2. Soumettre l’autorisation : l’attaquant ou un autre expéditeur de transaction soumet l’autorisation valide à un réseau compatible avec EIP-7702.

3. Définir la délégation : après vérification de l’autorisation, le réseau amène le compte concerné à exécuter le code de contrat spécifié.

4. Déclencher la logique malveillante : l’attaquant appelle un point d’entrée d’exécution exploitable dans le code malveillant.

5. Transférer les actifs : la logique malveillante effectue des transferts, des opérations sur des jetons ou d’autres actions dangereuses dans le contexte du compte.

Le danger de ce type d’attaque est que les utilisateurs peuvent ne voir qu’une seule demande de signature sans comprendre qu’elle peut modifier la manière dont le compte exécute les transactions ultérieures.

Le 30 octobre 2026, un incident de sécurité majeur impliquant des hot wallets liés à Binance s’est produit. L’analyse de l’incident par TRM Labs a conclu que les attaquants avaient utilisé une délégation EIP-7702 sur le réseau Ethereum pour connecter les hot wallets concernés à un code d’exécution malveillant. Elle a également observé des transferts de fonds anormaux sur d’autres blockchains. Différentes analyses de sécurité comportent encore des détails nécessitant une vérification supplémentaire concernant l’ampleur de l’attaque, la manière dont les signatures ont été obtenues et le vecteur d’intrusion initial.

Cet incident montre qu’EIP-7702 peut servir d’infrastructure à l’automatisation normale des wallets, mais qu’il peut également amplifier les conséquences d’une perte de contrôle des systèmes d’autorisation ou de signature. Il ne démontre toutefois pas que le protocole EIP-7702 lui-même comporte une vulnérabilité permettant à des attaquants arbitraires de contourner la vérification des signatures.

Pourquoi les attaquants peuvent-ils transférer des actifs même lorsque la clé privée de l’utilisateur n’a pas été exposée ?

L’éducation traditionnelle à la sécurité des wallets met généralement l’accent sur la protection des phrases de récupération et des clés privées, car un attaquant qui obtient une clé privée peut forger une signature valide au nom du propriétaire du compte. Toutefois, dans les scénarios d’interaction avec des contrats intelligents, l’absence d’exposition de la clé privée ne garantit pas la sécurité des actifs.

La raison est que les utilisateurs peuvent signer volontairement des autorisations aux conséquences dangereuses. Dans le cas d’EIP-7702, un attaquant n’a pas nécessairement besoin d’obtenir directement la clé privée. S’il parvient à inciter l’utilisateur à signer une autorisation de délégation malveillante valide et à remplir les conditions nécessaires à l’exécution on-chain, il peut être en mesure d’influencer le comportement ultérieur du compte.

Ce risque est similaire au phishing de signature traditionnel, mais la cible s’étend d’une transaction unique ou d’une autorisation spécifique de jetons à la logique d’exécution du compte.

Les attaquants peuvent également cibler les systèmes de signature, les processus d’approbation des autorisations ou les terminaux opérationnels des wallets d’entreprise. Si un système de signature est trompé et génère une autorisation valide ne correspondant pas à l’objectif commercial prévu, de graves conséquences peuvent survenir même si la clé privée sous-jacente n’a pas été directement exposée.

La sécurité des wallets ne peut donc pas reposer uniquement sur la protection des clés privées. Le processus de signature lui-même doit également être protégé. Les utilisateurs doivent savoir s’ils signent un transfert ordinaire, une autorisation de jetons ou une délégation de code susceptible d’affecter le comportement du compte sur une période prolongée.

Pour les wallets institutionnels, les politiques de signature, les listes blanches de contrats, les approbations multipartites et les simulations de transaction doivent également couvrir les autorisations EIP-7702, plutôt que de s’appuyer uniquement sur les vérifications traditionnelles des montants de transfert.

Une délégation EIP-7702 expire-t-elle automatiquement ? Comment vérifier et révoquer les autorisations risquées ?

Une caractéristique importante d’EIP-7702 est que l’état de délégation n’est pas automatiquement effacé lorsque la transaction qui l’a défini est terminée.

Une fois qu’un compte a défini avec succès une délégation, l’indicateur de code concerné reste généralement en place jusqu’à ce qu’une nouvelle autorisation valide le remplace ou l’efface. Cela signifie que la délégation peut rester active même après que l’utilisateur a fermé le site web, déconnecté le wallet ou terminé la transaction initiale.

Au niveau du protocole, les utilisateurs peuvent utiliser une nouvelle autorisation valide pour définir la cible de délégation sur l’adresse zéro, effaçant ainsi l’indicateur de délégation EIP-7702. Les utilisateurs peuvent également autoriser à nouveau un contrat d’implémentation de confiance lorsque cela est approprié.

Les étapes suivantes peuvent être utilisées pour vérifier et gérer une délégation :

1. Interroger l’état du code du compte : utilisez un explorateur de blockchain de confiance ou un outil de sécurité pour confirmer si l’adresse possède une délégation EIP-7702.

2. Vérifier le contrat cible : vérifiez si la délégation pointe vers le même contrat d’implémentation que celui publié par le produit de wallet utilisé.

3. Évaluer le risque du contrat : vérifiez si le code a été audité, s’il possède des privilèges administrateur, s’il peut être mis à niveau et s’il permet à des tiers d’effectuer des opérations sur des actifs.

4. Effacer une délégation anormale : après avoir confirmé le processus et les conditions du réseau, utilisez un outil de confiance pour soumettre une nouvelle autorisation valide afin d’effacer ou de remplacer la délégation dangereuse.

5. Vérifier les risques associés : vérifiez également les autorisations ERC-20, les enregistrements de transactions anormales et l’état du compte sur d’autres chaînes.

Lors de l’interrogation du code d’un compte disposant d’une délégation EIP-7702, les utilisateurs peuvent voir un indicateur spécial commençant par 0xef0100, suivi de l’adresse cible de délégation. Il s’agit d’une méthode d’identification au niveau du protocole. Toutefois, les utilisateurs ordinaires n’ont pas besoin d’analyser eux-mêmes les données hexadécimales brutes. Ils peuvent utiliser un outil de confiance qui affiche correctement le statut EIP-7702.

Il est important de noter que la révocation d’une délégation ne restaure pas les actifs et ne garantit pas que le compte est entièrement sécurisé. Si la clé privée, le dispositif de signature ou l’environnement opérationnel a déjà été compromis, le simple effacement de la délégation peut ne pas suffire. En cas de suspicion de compromission d’un compte, envisagez de cesser d’utiliser l’environnement de signature concerné et, après vous être assuré qu’il est possible de le faire en toute sécurité, de déplacer les actifs restants.

En quoi le modèle de sécurité EIP-7702 diffère-t-il des comptes intelligents ERC-4337 ?

EIP-7702 et ERC-4337 sont tous deux liés à l’abstraction de compte Ethereum, mais ils abordent le problème de manière différente.

ERC-4337 utilise des composants tels que UserOperation, Bundler et EntryPoint pour fournir un cadre d’exécution des transactions pour les comptes de contrats intelligents, sans dépendre des EOA traditionnels pour initier directement chaque opération. Les règles de validation et d’exécution du compte sont implémentées par des contrats intelligents.

EIP-7702 vise principalement à permettre aux EOA traditionnels d’acquérir des capacités d’exécution de contrats intelligents. Il permet aux adresses existantes de déléguer l’exécution de code de contrat, réduisant ainsi les obstacles pour les utilisateurs souhaitant adopter les fonctionnalités de comptes intelligents.

Les deux ne sont pas des substituts complets l’un à l’autre. Certaines architectures de wallet peuvent utiliser EIP-7702 pour fournir des capacités d’exécution de code aux EOA existants, puis les combiner à l’infrastructure ERC-4337 afin d’offrir une expérience de compte intelligent plus complète.

Du point de vue de la sécurité, EIP-7702 nécessite de se concentrer sur les délégations malveillantes et la tromperie par signature. ERC-4337 exige une attention particulière à la logique de validation des contrats de compte, aux modules d’exécution, aux autorisations de mise à niveau et aux risques liés à l’infrastructure associée. La sécurité réelle dépend de l’implémentation spécifique plutôt que simplement de la norme adoptée.

Comment les utilisateurs ordinaires peuvent-ils se protéger contre le phishing de signature EIP-7702 ?

Pour les utilisateurs ordinaires, la clé de la gestion des risques EIP-7702 ne consiste pas à éviter entièrement les fonctionnalités de compte intelligent, mais à reconnaître les changements d’autorisations représentés par les différentes signatures.

1. Les utilisateurs doivent distinguer les signatures de transaction, les signatures de message, les autorisations de jetons et les délégations de compte. Si l’interface du wallet affiche EIP-7702, Delegation, Set Code ou une invite similaire, vérifiez que l’opération doit réellement modifier la logique d’exécution du compte.

2. Portez une attention particulière à l’adresse cible de délégation. Une mise à niveau normale d’une fonctionnalité de wallet peut nécessiter la définition d’un contrat d’implémentation de compte intelligent vérifié, mais les utilisateurs doivent rester prudents lorsqu’un site web inconnu leur demande de déléguer à une adresse inconnue. Même si le code source d’un contrat est accessible publiquement, cela ne signifie pas nécessairement que la conception de ses autorisations est sécurisée.

3. Ne jugez pas la fiabilité d’une demande d’autorisation uniquement sur la base du nom du site web, de la conception de l’interface ou d’un lien de réseau social. Les attaquants peuvent utiliser de fausses pages de mise à jour de wallet, des publicités dans les moteurs de recherche ou des pages frontend compromises pour inciter les utilisateurs à signer.

4. Utilisez, lorsque cela est possible, des outils de wallet qui affichent clairement le contenu des autorisations et fournissent une simulation de transaction ainsi que des alertes de risque. Si un dispositif de signature ne peut afficher que des données brutes que l’utilisateur ne comprend pas, évitez de signer aveuglément avant d’avoir vérifié le contenu.

5. Envisagez de séparer les comptes selon le montant des actifs et les scénarios d’utilisation. Conserver les avoirs à long terme séparément des wallets utilisés pour des interactions DeFi fréquentes, des airdrops ou de nouvelles applications peut réduire dans une certaine mesure l’impact potentiel d’une seule autorisation malveillante.

Il est important de noter que les hardware wallets peuvent améliorer la protection des clés privées, mais ils ne peuvent pas déterminer automatiquement si une délégation approuvée activement par l’utilisateur est sûre. Une signature sécurisée exige toujours un affichage fiable des informations et une évaluation éclairée de l’utilisateur.

Que signifie EIP-7702 pour l’avenir de la sécurité des wallets et de l’abstraction de compte ?

EIP-7702 fait évoluer les comptes Ethereum du modèle d’exécution relativement fixe des EOA vers des comptes programmables plus flexibles. Pour les développeurs de wallets, cela signifie qu’ils peuvent proposer des transactions par lots, le parrainage des frais de gas, la gestion des autorisations et l’exécution automatisée tout en conservant les adresses existantes.

Toutefois, plus la programmabilité du compte est étendue, plus les vérifications de sécurité doivent être précises. Auparavant, les alertes de risque des wallets se concentraient principalement sur les destinations de transfert, les montants des transactions et les montants des autorisations de jetons. À l’avenir, elles devront également afficher avec précision les cibles de délégation, les règles de validation des contrats, les autorisations d’exécution et les effets potentiels à long terme.

Du point de vue de la conception des produits, les pratiques de sécurité EIP-7702 peuvent évoluer dans trois directions.

• Transparence des autorisations. Les wallets doivent aider les utilisateurs à comprendre ce qu’une délégation modifiera, plutôt que de simplement afficher une adresse de contrat.

• Principe du moindre privilège. Les contrats délégués peuvent réduire les pertes potentielles grâce à des contrôles d’accès stricts, des limites, des périodes d’expiration et des mécanismes de vérification multiples. Toutefois, ces restrictions doivent être appliquées de manière fiable par le code réel, plutôt que de reposer uniquement sur des affichages frontend.

• Surveillance continue des risques. Comme les délégations peuvent rester en place sur une période prolongée, les outils de sécurité des wallets doivent permettre de détecter les délégations anormales, les modifications du code de contrat et les opérations de compte suspectes, plutôt que de vérifier uniquement au moment de la signature initiale.

L’importance d’EIP-7702 ne réside pas seulement dans l’amélioration de l’expérience des wallets, mais aussi dans l’extension de la sécurité des comptes au-delà de la protection traditionnelle des clés privées, vers une gestion intégrée de l’intention de signature, de l’exécution du code et des autorisations continues.

Résumé

EIP-7702 introduit des capacités de délégation de contrats intelligents pour les EOA Ethereum traditionnels, permettant aux utilisateurs d’accéder à des fonctions d’exécution de compte plus flexibles tout en conservant leurs adresses de wallet existantes. Ce mécanisme fournit une nouvelle base technique pour l’abstraction de compte, mais il modifie également la frontière de sécurité des wallets traditionnels.

Contrairement à ERC-20 Approve, qui contrôle principalement les autorisations de dépense de jetons, l’autorisation EIP-7702 peut modifier le code de contrat exécuté par un compte. Si un utilisateur signe une délégation malveillante, un attaquant peut utiliser une logique d’exécution non sécurisée pour transférer des actifs sans nécessairement obtenir directement la clé privée de l’utilisateur.

Par conséquent, évaluer si EIP-7702 est sûr exige plus que de vérifier si l’autorisation a été signée par l’utilisateur. Il faut également vérifier la cible de délégation, les autorisations du contrat, la source de la signature et le comportement d’exécution ultérieur. À mesure que les fonctionnalités de comptes intelligents seront davantage adoptées, la compréhension de la délégation de code et de la gestion des autorisations deviendra une partie importante de l’éducation à la sécurité des wallets.

FAQ

Qu’est-ce qu’EIP-7702 ?

EIP-7702 est une amélioration du protocole Ethereum qui permet aux EOA traditionnels de déléguer l’exécution du code de contrats intelligents par autorisation, offrant ainsi certaines fonctionnalités de compte intelligent.

EIP-7702 peut-il vider automatiquement un wallet ?

Non. EIP-7702 n’est pas une fonctionnalité qui vole automatiquement des actifs. Les principaux risques proviennent d’autorisations malveillantes, d’un code délégué non sécurisé ou de systèmes de signature compromis.

L’autorisation EIP-7702 est-elle identique à ERC-20 Approve ?

Non. ERC-20 Approve accorde généralement à une adresse spécifique une autorisation d’utiliser des jetons, tandis que l’autorisation EIP-7702 définit le code de contrat exécuté par un compte. Les niveaux d’autorisation sont différents.

Une délégation EIP-7702 peut-elle être révoquée ?

Oui. Le propriétaire du compte peut utiliser une nouvelle autorisation valide pour effacer ou remplacer la délégation. Toutefois, si la clé privée ou l’environnement de signature a été compromis, la seule révocation de la délégation ne peut pas garantir la sécurité.

Un hardware wallet peut-il empêcher le phishing EIP-7702 ?

Pas complètement. Un hardware wallet contribue à protéger la clé privée, mais les utilisateurs peuvent toujours être exposés à des risques pour leurs actifs s’ils confirment une autorisation malveillante sur l’appareil.

Comment savoir si un wallet possède une délégation EIP-7702 ?

Vous pouvez utiliser un explorateur de blockchain ou un outil de sécurité compatible avec EIP-7702 afin d’interroger le code du compte et la cible de délégation. Si vous trouvez une adresse de délégation inconnue, vérifiez son origine et ses autorisations.