L’abstraction de compte sur Ethereum repose sur deux adresses canoniques qu’il vaut la peine de mémoriser. EntryPoint v0.6 se trouve à 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789. EntryPoint v0.7, déployé début 2024, se trouve à 0x0000000071727De22E5E9d8BAf0edAc6f37da032. Sur le réseau principal, Arbitrum, Optimism, Base, Polygon et la plupart des autres chaînes EVM, chaque transaction ERC-4337 passe par l’un de ces deux contrats uniques. Si vous comprenez le rôle de ces contrats et celui des cinq autres acteurs qui les entourent, vous comprenez ERC-4337.

Voici la deuxième partie de notre série sur les comptes intelligents. La première expliquait pourquoi les EOA sont un mauvais choix par défaut. Nous allons maintenant voir ce qui se passe en coulisses : les six rôles, la structure UserOperation, le déroulement concret d’un échange de token depuis un compte intelligent, les changements de v0.6 à v0.7, les paymasters, les alt-mempools publics face aux bundlers privés, ainsi que les frais supplémentaires à prévoir.

Les six rôles en un schéma

ERC-4337 répartit entre six acteurs qui coopèrent ce qu’un EOA fait en une seule étape. Aucun fork d’Ethereum n’a été nécessaire : le système repose entièrement sur des contrats et une infrastructure hors chaîne.

Émetteur (le compte intelligent) : un portefeuille contractuel qui détient vos actifs et implémente validateUserOp. Du point de vue de toute DApp avec laquelle il interagit, il s’agit de msg.sender. Exemples : Safe, Kernel, Biconomy Nexus, Coinbase Smart Wallet et Light Account d’Alchemy.
UserOperation : une structure de pseudo-transaction (ce n’est pas une véritable transaction Ethereum) qui décrit ce que l’émetteur veut faire. Les utilisateurs signent des UserOps, pas des transactions.
Bundler : un nœud hors chaîne qui recueille des UserOps dans un mempool, les simule, les regroupe dans un seul appel handleOps et paie les frais de gaz sur L1. Les bundlers gagnent la différence entre le montant remboursé par l’émetteur (ou le paymaster) et celui qu’ils versent au validateur.
EntryPoint : le contrat unique de confiance qui parcourt le lot, appelle validateUserOp de chaque émetteur, exécute les données d’appel et gère les remboursements et les annulations. Il n’existe qu’un EntryPoint par version et par chaîne.
Paymaster (facultatif) : un contrat qui accepte de payer les frais de gaz au nom d’un émetteur, soit en les prenant en charge (gratuitement pour l’utilisateur), soit en échange d’un token ERC-20 comme USDC.
Agrégateur (facultatif) : un contrat qui valide plusieurs UserOps au moyen d’une seule vérification de signature, notamment pour les schémas BLS ou les preuves à divulgation nulle de connaissance. Il est encore rarement déployé en production.

Gardez ces rôles à l’esprit. Le reste de l’article montre simplement comment ces six acteurs interagissent.

La structure UserOperation

Une UserOperation est un ensemble de champs compatible avec JSON-RPC qui, une fois signé, exprime une intention sans encore l’inscrire sur L1. La disposition de v0.7 comporte 11 champs logiques :

sender — l’adresse du compte intelligent.
nonce — une valeur de 256 bits dont les 192 bits de poids fort constituent une clé (voie de nonce parallèle) et les 64 bits de poids faible, une séquence. C’est ainsi qu’ERC-4337 permet les nonces parallèles, contrairement aux EOA, qui sérialisent toutes les opérations.
factory et factoryData — utilisés lors du premier déploiement via CREATE2 ; nuls après le déploiement.
callData — l’appel que le compte intelligent doit effectuer après validation.
callGasLimit, verificationGasLimit, preVerificationGas — trois budgets de gaz distincts.
maxFeePerGas, maxPriorityFeePerGas — mêmes règles EIP-1559 que pour une transaction ordinaire.
paymasterAndData (v0.6), scindé en paymaster, paymasterVerificationGasLimit, paymasterPostOpGasLimit, paymasterData (v0.7).
signature — des octets opaques que le compte intelligent interprète selon son propre validateUserOp.

Le portefeuille choisit le schéma de signature. ECDSA sur secp256k1 est courant, mais la vérification P-256/passkey, les signatures multisig, les seuils de récupération sociale et les signataires à clé de session utilisent tous la même interface. C’est là tout l’intérêt de cette flexibilité.

De bout en bout : que se passe-t-il lorsqu’un compte intelligent échange des USDC contre des ETH ?

Suivons un échange réel pour voir les différents rôles intervenir dans l’ordre.

L’utilisateur appuie sur « Swap » dans l’interface de son portefeuille. Le portefeuille construit une UserOperation : sender = 0xUserSafe, callData = swapUSDCforETH(amount) ciblant Uniswap.
Estimation du gaz. Le portefeuille appelle eth_estimateUserOperationGas sur un RPC de bundler. Celui-ci simule l’opération auprès d’EntryPoint et renvoie les trois limites de gaz.
Signature de l’utilisateur. Le portefeuille calcule le hachage de la UserOp avec l’adresse d’EntryPoint et l’identifiant de chaîne, demande à l’utilisateur de signer (avec une passkey, une clé matérielle ou autre), puis ajoute la signature.
Soumission. La UserOp signée est envoyée via eth_sendUserOperation à un ou plusieurs bundlers. Elle entre dans l’alt-mempool, un réseau pair-à-pair distinct du mempool des transactions ordinaires d’Ethereum.
Simulation par le bundler. Le bundler simule à nouveau l’opération avec eth_call auprès de simulateValidation. Il vérifie les règles d’accès au stockage d’ERC-7562 : pendant la validation, une UserOp ne peut accéder qu’à son propre stockage, faute de quoi le bundler risque d’être la cible d’une attaque par harcèlement.
Regroupement. Le bundler regroupe cette UserOp avec une dizaine d’autres au maximum dans un seul appel handleOps([...userOps], beneficiary) à EntryPoint.
Exécution sur la chaîne. EntryPoint parcourt le lot : pour chaque opération, il appelle validateUserOp sur l’émetteur, déduit le préfinancement, puis exécute callData. L’échange sur Uniswap est effectué depuis le compte intelligent.
Remboursement. EntryPoint rembourse à l’émetteur (ou au paymaster) les frais de gaz inutilisés et verse le paiement à l’adresse bénéficiaire du bundler.

Si l’étape 5 échoue, le bundler abandonne l’opération et l’utilisateur voit un code d’erreur AAxx. Les plus courants sont AA21 (préfinancement insuffisant), AA23 (erreur de signature), AA25 (nonce invalide), AA33 (annulation par le paymaster) et AA40 (limite de gaz de vérification dépassée). Mémorisez ces codes : vous les rencontrerez.

EntryPoint v0.6 et v0.7

v0.6 a été lancé en mars 2023 à l’adresse 0x5FF1…2789. Il fonctionnait, mais présentait trois problèmes récurrents : un seul bloc paymasterAndData confondant trois dimensions de gaz, un empaquetage initCode peu pratique et un calcul des frais de gaz qui faisait payer trop cher les émetteurs. v0.7 a corrigé ces trois problèmes.

Voici les principaux changements de v0.7 :

Adresse : 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (remarquez les zéros initiaux : cette adresse personnalisée a été obtenue par minage afin de réduire le coût en gaz des données d’appel, puisque chaque octet nul coûte 4 unités de gaz contre 16 pour un octet non nul).
Champs du paymaster séparés : paymaster, paymasterVerificationGasLimit, paymasterPostOpGasLimit et paymasterData sont désormais distincts. L’estimation est plus simple et il est plus difficile d’oublier un budget.
Séparation de la factory : même principe : factory et factoryData sont des champs distincts plutôt que d’être regroupés dans initCode.
Pénalité pour le gaz inutilisé : les émetteurs paient 10 % du gaz inutilisé de callGasLimit/paymasterPostOpGasLimit, ce qui les incite à ne pas surestimer largement les opérations.
Compatibilité avec EIP-7702 : v0.7 a ajouté les mécanismes permettant à un EOA ordinaire de déléguer temporairement à l’implémentation d’un compte intelligent. Ils ont servi de fondement à la voie de mise à niveau EIP-7702, déployée dans Pectra.

v0.6 est toujours actif et utilisé : de nombreux portefeuilles n’ont pris en charge les modules compatibles avec v0.7 qu’à partir de la seconde moitié de 2024. Sur la plupart des chaînes, les deux versions d’EntryPoint coexistent pendant des années.

Paymasters : qui paie les frais de gaz ?

Un paymaster est un contrat qui immobilise une mise en ETH auprès d’EntryPoint et accepte de couvrir les frais de gaz des UserOps conformes à sa politique. Trois types dominent :

Paymaster avec vérification (sponsorisé). Le serveur signe une autorisation hors chaîne ; le paymaster en vérifie la signature sur la chaîne et paie. Cette solution est utilisée par les applications qui veulent permettre une prise en main sans frais de gaz : Coinbase Smart Wallet, Farcaster Frames et la plupart des créations de NFT.
Paymaster ERC-20. L’utilisateur paie en USDC, USDT ou DAI ; le paymaster convertit le paiement en ETH en arrière-plan (ou détient des réserves d’ETH). Pimlico, Biconomy et Stackup en proposent tous des versions publiques.
Paymaster de token avec permit. Il utilise le permit EIP-2612 pour que l’utilisateur signe la UserOp et l’autorisation de dépense du token en une seule fois.

La fonction validatePaymasterUserOp du paymaster s’exécute pendant la phase de validation d’EntryPoint. Si elle est annulée, vous obtenez AA33. Si la mise est épuisée, EntryPoint la confisque et le bundler absorbe la perte — c’est pourquoi les bundlers tiennent des listes de réputation des paymasters. ERC-7562 formalise ces règles de réputation afin que le mempool des bundlers reste résistant au spam. Ces mêmes mécanismes expliquent pourquoi les bonnes pratiques de gestion des autorisations DeFi et du multisig s’appliquent aussi facilement à l’écosystème 4337 : mêmes menaces, nouvelle enveloppe.

Mempool alternatif public ou bundler privé

Il existe deux façons d’inclure une UserOp dans la blockchain.

Mempool alternatif public : les bundlers compatibles avec ERC-7562 diffusent les UserOps sur un réseau libp2p. Toute personne qui exécute un nœud Pimlico, Stackup, Alchemy, Etherspot ou Voltaire peut récupérer la vôtre. Cette approche est sans permission et résistante à la censure, mais vous êtes exposé aux mêmes risques de MEV que pour les transactions Ethereum classiques : les searchers peuvent voir votre opération avant son inclusion.

Bundler privé : vous envoyez directement eth_sendUserOperation au point de terminaison RPC d’un fournisseur. Celui-ci simule, regroupe et soumet les opérations en privé, souvent via Flashbots. C’est plus rapide et protège contre le MEV, mais vous devez faire confiance au bundler pour qu’il ne censure pas votre opération et ne la devance pas. En 2026, la plupart des portefeuilles grand public utilisent des bundlers privés par défaut.

Ce compromis rappelle celui entre un mempool public et Flashbots Protect pour les transactions classiques. Si vous n’avez pas consulté le guide du cycle de vie d’une transaction depuis l’époque de la L1, il explique ce qui change lorsque le bundler intervient.

Agrégateurs, adoption et coût total

Les agrégateurs sont des contrats qui valident des lots avec une seule vérification de signature. Leur principal cas d’usage est BLS : vous réunissez 50 UserOps signées avec BLS, agrégez leurs signatures en une seule vérification par appariement et économisez environ 95 % sur le coût en gaz des signatures. Leur adoption est lente, car créer des portefeuilles qui signent avec BLS est difficile et les économies de gaz ne deviennent intéressantes qu’à grande échelle. À la mi-2026, moins de 1 % des UserOps du réseau principal utilisent des agrégateurs.

Chiffres d’adoption (T1 2026, d’après bundlebear.com) : environ 380 millions de UserOps cumulées sur toutes les chaînes. Base, Polygon et Arbitrum représentent la majorité. La part du réseau principal est d’environ 6 à 8 % : c’est la plus faible en volume, mais la plus élevée en valeur transférée. Coinbase Smart Wallet, Farcaster et Argent dominent les usages grand public.

Surcoût : une UserOp v0.7 coûte environ 30 000 à 40 000 unités de gaz de plus que la transaction EOA équivalente. Ce surcoût vient de la boucle d’EntryPoint, de la validation et de la gestion du lot. Sur le réseau principal, à 20 gwei, cela représente une fraction de dollar par opération. Le déploiement d’un compte pour la première fois via factoryData ajoute environ 250 000 unités de gaz. Sur les L2, où les données d’appel constituent le principal coût, le surcoût en pourcentage reste à un chiffre. Les UserOps sponsorisées transfèrent ce coût à la dApp : c’est pourquoi les applications grand public proposent des transactions gratuites, contrairement aux applications DeFi sérieuses. Le guide général sur les frais de transaction explique comment ce surcoût se répercute sur différents marchés de frais.

En bref : ERC-4337 repose sur six rôles (expéditeur, UserOp, bundler, EntryPoint, paymaster et agrégateur), une structure, deux adresses EntryPoint à retenir et un surcoût d’environ 30 à 40 k unités de gaz. En contrepartie, il permet d’utiliser des schémas de signature arbitraires, de parrainer les frais de gaz, de regrouper des opérations et d’employer des nonces parallèles. La troisième partie de cette série porte sur EIP-7702, la voie parallèle de Pectra qui permet à votre EOA existant d’utiliser ces mêmes mécanismes sans changer d’adresse.