WATS Wallet logoWATS Wallet
Technique6 min de lecture

EIP-7702 : abstraction de compte native pour les EOA (2026)

L'EIP-7702 permet à un EOA Ethereum ordinaire d'agir temporairement comme un smart account. Voici comment fonctionne le mécanisme de délégation de l'ère Pectra, comment il s'associe à ERC-4337 et ce qu'il débloque.

Le fossé : pourquoi votre EOA ne peut pas faire de choses de smart account

La plupart des gens sur Ethereum détiennent un compte détenu en externe (EOA) — une adresse contrôlée par une seule clé privée. Les EOA sont simples et éprouvés, mais ils sont aussi rigides. Ils ne peuvent pas regrouper plusieurs actions en une seule transaction atomique, ne peuvent pas laisser quelqu'un d'autre payer leur gas, et ne peuvent pas déléguer un pouvoir de signature limité à une clé temporaire. Ces commodités relèvent de l'abstraction de compte, et elles imposaient historiquement de déplacer vos fonds vers un compte à contrat intelligent — une adresse différente, avec des frictions de migration et ses propres hypothèses de confiance.

C'est le fossé que l'EIP-7702 a été conçue pour combler : donner aux EOA existants un accès au comportement de smart account sans demander aux utilisateurs d'abandonner l'adresse qu'ils possèdent déjà.

Ce qu'est l'EIP-7702

L'EIP-7702 est un mécanisme qui permet à un EOA de déléguer temporairement à du code de contrat afin qu'il puisse se comporter comme un smart account. Elle a été livrée dans le cadre de la mise à niveau Pectra d'Ethereum en 2025, et en 2026 elle est en service sur le mainnet et largement prise en charge par l'infrastructure des wallets. Elle introduit un nouveau type de transaction qui attache un morceau de code — une délégation — à un compte ordinaire. Point crucial, vos clés, votre solde et votre adresse restent exactement les mêmes ; le compte gagne simplement la capacité d'exécuter une logique programmable lorsqu'il le souhaite.

Il s'agit d'un changement significatif. Avant l'EIP-7702, "passer à un smart account" signifiait "créer et approvisionner un nouveau compte." Après elle, le compte que vous avez peut opter pour des fonctionnalités de smart account et, tout aussi facilement, y renoncer.

Comment ça fonctionne : le designator de délégation

À un haut niveau, l'EIP-7702 fonctionne grâce à un designator de délégation — un petit pointeur stocké dans le compte qui dit, en substance, "exécute le code de ce contrat comme s'il était le mien." L'utilisateur signe une autorisation nommant un contrat d'implémentation spécifique, et l'emplacement de code du compte est réglé sur un marqueur référençant ce contrat. À partir de là, les appels à l'EOA exécutent la logique déléguée tandis que les transactions sont toujours autorisées par la propre clé du compte.

Parce que la délégation est établie par une autorisation signée, elle peut aussi être effacée ou repointée. En 2026, le modèle pratique est le suivant : l'EOA reste un EOA, mais il peut revêtir une "tenue" de smart account définie par ce vers quoi il délègue. Cette implémentation est là où vivent réellement des fonctionnalités comme le batching ou les politiques de dépense.

EIP-7702 face à ERC-4337 : complémentaires, non concurrents

ERC-4337 est le standard d'abstraction de compte qui a introduit les UserOperations, les bundlers, un contrat EntryPoint singleton et les paymasters — un pipeline compatible avec l'off-chain pour les smart accounts qui n'a jamais touché au protocole central d'Ethereum. L'EIP-7702, en revanche, est un changement au niveau du protocole qui met à niveau les EOA directement.

Il est facile de les présenter comme des rivaux, mais en 2026 on les comprend mieux comme complémentaires. L'EIP-7702 répond à "comment un simple EOA acquiert-il une identité définie par du code ?" ERC-4337 répond à "comment les smart accounts obtiennent-ils une exécution regroupée, des frais sponsorisés et un pipeline de vérification partagé ?" Un compte délégué via EIP-7702 peut adopter une logique compatible ERC-4337 et se brancher sur la même infrastructure d'EntryPoint et de paymaster. Les deux standards s'empilent plutôt que de se remplacer.

Ce que cela débloque pour les wallets existants

Pour un développeur de wallet, l'EIP-7702 transforme des fonctionnalités auparavant "réservées aux smart accounts" en choses que l'adresse d'un utilisateur ordinaire peut utiliser :

Batching. Approuver et swapper en une seule transaction atomique, de sorte qu'une étape ne puisse pas s'exécuter à moitié et vous laisser coincé entre une approbation et un trade.

Sponsoring du gas. Un paymaster (ou un fee-payer équivalent sur les chaînes non-EVM) peut couvrir le gas, ou laisser l'utilisateur payer les frais dans un token autre que l'actif natif de la chaîne — sans réserve d'ETH-pour-le-gas séparée requise.

Session keys. Accorder une clé temporaire et à portée limitée qui peut signer un ensemble restreint d'actions dans des bornes définies, puis expire — utile pour les jeux, les interfaces de trading et les flux récurrents sans re-signer chaque étape.

Risques et considérations

La délégation est puissante, ce qui est précisément la raison pour laquelle elle mérite de la prudence. Le contrat d'implémentation vers lequel vous déléguez définit de fait ce que votre compte peut faire, de sorte qu'une implémentation malveillante ou boguée constitue un risque sérieux — les utilisateurs ne devraient déléguer qu'à du code audité et réputé. Les autorisations signées doivent être manipulées avec soin par les wallets pour éviter le phishing qui piégerait un utilisateur en pointant son compte vers une logique contrôlée par un attaquant. Et parce que l'EIP-7702 est relativement nouvelle, l'outillage, les indexeurs et les hypothèses de sécurité mûrissent encore en 2026. Rien de tout cela n'est une raison de l'éviter ; c'est une raison d'attendre des wallets qu'ils rendent la cible de délégation explicite et révocable, et de traiter "vers quoi est-ce que je délègue ?" comme une question de sécurité de première importance.

Comment WATS utilise cela

Le bénéfice quotidien de l'abstraction de compte — pas de jonglage avec le gas natif, un seul frais prévisible — est déjà ce que le WATS Hot Wallet offre, de manière non-custodiale. Chaque transfert, swap ou staking est facturé dans un seul token, ATS — sur l'EVM via un paymaster ERC-4337, et via un fee-payer équivalent sur Solana et TON — et parce que ATS est un OFT LayerZero, un seul solde fonctionne à travers les trois. WATS est le premier et le seul wallet à combiner des frais en token unique ERC-4337 + OFT, facturés à la place du gas natif, avec un burn qui tire l'ATS collecté de 100M vers un plancher de 30M — tout en vous laissant conserver vos clés, puisque WATS n'en détient jamais aucune.

Foire aux questions

L'EIP-7702 transforme-t-elle mon EOA en compte à contrat intelligent de façon permanente ?

Non. L'EIP-7702 attache un designator de délégation qui pointe votre compte vers du code d'implémentation, mais votre adresse, vos clés et votre solde restent les mêmes. La délégation peut être repointée ou effacée, de sorte que le compte peut opter pour un comportement de smart account et y renoncer. C'est une mise à niveau temporaire et réversible plutôt qu'une migration permanente vers un nouveau compte.

L'EIP-7702 est-elle un remplacement d'ERC-4337 ?

Non, elles sont complémentaires en 2026. L'EIP-7702 est un changement au niveau du protocole qui permet à un EOA de déléguer à du code de contrat, tandis qu'ERC-4337 fournit le pipeline de UserOperation, le contrat EntryPoint, les bundlers et les paymasters pour les smart accounts. Un compte délégué via 7702 peut adopter une logique compatible ERC-4337 et utiliser la même infrastructure de paymaster, de sorte que les standards s'empilent ensemble.

Que peut faire un EOA avec l'EIP-7702 qu'il ne pouvait pas faire auparavant ?

Avec une implémentation déléguée appropriée, un EOA ordinaire peut regrouper plusieurs actions en une seule transaction atomique, faire sponsoriser son gas par un paymaster ou le payer dans un token non natif, et accorder des session keys à portée limitée et expirantes. Ces fonctionnalités étaient auparavant réservées aux smart accounts. La principale réserve est que le compte n'est aussi sûr que le contrat vers lequel il délègue, de sorte que les utilisateurs ne devraient déléguer qu'à du code audité.