Bundlers et UserOperations : comment fonctionnent les transactions ERC-4337

Une UserOperation est l'objet d'intention signé défini par ERC-4337 : elle indique ce qu'un compte à contrat intelligent veut faire, ainsi que la façon dont cette action doit être validée et payée. Contrairement à une transaction Ethereum ordinaire, ce n'est pas un objet de niveau protocole signé par un compte détenu en externe : sa signature est vérifiée par le contrat de compte lui-même, et elle n'a pas à payer son propre gas natif. Un bundler est l'acteur off-chain qui collecte les UserOperations depuis un mempool alternatif dédié, simule chacune d'elles, regroupe les valides dans une unique transaction Ethereum ordinaire et appelle le contrat canonique EntryPoint — lequel valide toutes les opérations du lot avant d'en exécuter la moindre. Le bundler avance le gas réel depuis son propre EOA et se fait rembourser on-chain par le compte expéditeur ou par le paymaster de ce compte. Un contrat paymaster optionnel peut accepter de prendre en charge une opération pendant cette étape de validation : c'est là que les frais deviennent sponsorisés ou payables dans un token ERC-20 plutôt que dans le token de gas natif de la chaîne.

Un rapide rappel sur ERC-4337

ERC-4337 est le standard Ethereum pour l'abstraction de compte — une manière de donner aux comptes à contrat intelligent la même capacité de première classe à initier et à payer des actions que les comptes détenus en externe (EOA) ont toujours eue, sans aucune modification du protocole de base. Au lieu de modifier la couche de consensus, ERC-4337 introduit un système parallèle d'objets de plus haut niveau et d'infrastructure off-chain qui se règle finalement à travers des transactions Ethereum ordinaires. Si vous voulez d'abord la version de fond, notre explicatif sur ce qu'est l'abstraction de compte couvre la motivation, ce qu'est ERC-4337 cartographie le standard complet, et comptes intelligents contre EOA compare directement les deux types de compte. Cet article zoome sur la mécanique : les objets qui traversent le système et les acteurs qui les traitent. Notez que ERC-4337 est un standard EVM — il s'applique à Ethereum et aux chaînes compatibles EVM, pas aux chaînes non-EVM comme Solana ou TON.

Ce qu'est réellement une UserOperation

L'objet central d'ERC-4337 est la UserOperation. Elle ressemble superficiellement à une transaction, mais on la comprend mieux comme une déclaration d'intention signée : "voici ce que mon compte veut faire, et voici les paramètres pour la valider et la payer." C'est une struct passée en calldata à un contrat, et non un objet natif du protocole — la couche de base n'en a jamais entendu parler.

Une UserOperation porte, en substance :

• sender — le compte à contrat intelligent pour lequel l'opération agit.
• nonce — la protection contre le rejeu, suivie par l'EntryPoint sous forme de valeur en deux parties (une clé plus une séquence), afin qu'un compte puisse gérer plusieurs files de nonce indépendantes plutôt qu'une seule file stricte.
• callData — ce que le compte doit exécuter, souvent un lot de plusieurs appels au sein d'une même opération.
• données de déploiement du compte — optionnel ; déploie le contrat de compte lors de sa toute première opération, ce qui permet à un compte intelligent d'être approvisionné à une adresse connue, dérivée de façon déterministe, avant même d'exister on-chain.
• limites de gas — des budgets distincts pour la validation et l'exécution, plus une valeur preVerificationGas qui dédommage le bundler pour le calldata et la surcharge que l'EntryPoint ne peut pas mesurer lui-même.
• paramètres de frais — des frais maximum et des frais de priorité maximum, à l'image d'EIP-1559.
• données de paymaster — optionnel ; quel contrat sponsorisera l'opération et le contexte dont il a besoin.
• signature — vérifiée par la propre fonction de validation du compte, et non par le protocole.

L'encodage exact a évolué selon les versions de l'EntryPoint — la v0.7 sépare les blobs de déploiement et de paymaster en champs explicites et regroupe plusieurs valeurs de gas, là où la v0.6 utilisait de simples chaînes d'octets initCode et paymasterAndData — mais le contenu conceptuel est le même. Si vous intégrez, vérifiez quelle version d'EntryPoint vise votre bundler.

La différence clé avec une transaction normale porte sur qui et quoi la signe. Une transaction Ethereum classique doit être signée par la clé privée d'un EOA selon un schéma ECDSA fixe, et ce même compte paie le gas. Une UserOperation est validée par la logique de compte à contrat intelligent de l'expéditeur — qui peut implémenter n'importe quel schéma de signature, règle multi-clés, clé de session ou politique d'autorisation que le compte définit — et elle n'a pas du tout à se payer elle-même en gas natif. Cette flexibilité est tout l'intérêt : c'est le compte, et non le protocole, qui décide de ce à quoi ressemble une action valide.

Le mempool alternatif où elles vivent

Les UserOperations n'entrent pas dans le mempool de transactions Ethereum habituel, car ce ne sont pas encore des transactions. Elles sont plutôt diffusées vers un mempool alternatif distinct (souvent appelé alt-mempool) — un réseau pair-à-pair dédié aux objets ERC-4337. En pratique, un wallet ou une dApp en soumet une en appelant eth_sendUserOperation sur le point d'accès RPC d'un bundler ; ce bundler peut la propager vers l'alt-mempool partagé ou la conserver dans son propre pool privé. Dans les deux cas, l'infrastructure qui consomme ces objets écoute ici plutôt que sur le mempool de la couche de base. Cette séparation maintient le trafic d'abstraction de compte hors du chemin critique du consensus jusqu'au moment où il est empaqueté dans une véritable transaction.

Le rôle du bundler

Un bundler est l'acteur off-chain qui transforme les intentions en réalité on-chain. Sa mission comporte quatre volets. Premièrement, il collecte les UserOperations depuis le mempool alternatif. Deuxièmement, il simule et valide chacune d'elles — en exécutant la logique de validation du compte dans un contexte simulé pour confirmer que la signature est valide, que le nonce est correct et que le compte ou son paymaster peut couvrir le coût. Troisièmement, il regroupe une ou plusieurs UserOperations valides dans une unique transaction Ethereum ordinaire. Quatrièmement, il soumet cette transaction au réseau depuis son propre EOA, en avançant le gas de la couche de base et en s'attendant à être remboursé on-chain.

La simulation seule ne suffit pas à le protéger, car l'état peut changer entre la simulation et l'inclusion. ERC-4337 encadre donc aussi ce que le code de validation a le droit de faire : pendant la phase de validation, un compte ou un paymaster ne peut pas lire les horodatages de bloc ni d'autres valeurs d'environnement qui lui permettraient de se comporter différemment on-chain et en simulation, et son accès au stockage est largement limité aux slots associés à son propre compte. Les contrats qui agissent pour le compte de nombreux utilisateurs — les factories et les paymasters en particulier — sont censés déposer un stake, afin qu'un seul contrat malveillant ne puisse pas invalider à bas coût une large part du mempool d'un seul coup. Ces règles existent pour une seule raison : faire de la simulation d'un bundler une prédiction fiable de ce qui se produira on-chain.

Parce que le bundler avance le gas et gagne des frais pour l'inclusion, il se comporte à peu près comme un constructeur de blocs spécialisé pour le trafic d'abstraction de compte. Son étape de simulation-et-validation est ce qui le protège : il ne regroupera pas une opération qui échouerait à le rembourser.

Le contrat EntryPoint

Tout converge vers un unique contrat intelligent canonique appelé EntryPoint. C'est un singleton, déployé par version à la même adresse sur toutes les chaînes EVM, et il détient les dépôts qui paient les opérations. La transaction du bundler est un appel à l'EntryPoint avec un tableau de UserOperations, et l'EntryPoint exécute alors une boucle stricte en deux phases.

Dans la phase de validation, pour chaque opération, il appelle la fonction de validation du compte expéditeur (et celle du paymaster, si l'un est spécifié) afin de revérifier la signature, le nonce et l'arrangement de paiement on-chain, et il réserve le coût maximal possible auprès de celui qui paie. Ce n'est qu'après que toutes les opérations du lot ont été validées qu'il passe à la phase d'exécution, où il transmet le calldata de chaque opération à son compte pour effectuer réellement le transfert, le swap ou toute autre action, puis règle le coût réel et rembourse la réserve inutilisée.

Cette séparation compte : la validation et l'exécution sont dissociées pour que les garanties de paiement d'un lot soient établies avant qu'un travail modifiant l'état ne s'exécute, et pour que l'EntryPoint puisse comptabiliser le gas avec précision sur de nombreuses opérations à la fois. Cela signifie aussi que l'échec d'une opération pendant l'exécution ne peut pas contaminer les autres du lot.

La place du paymaster

Un paymaster est un contrat optionnel qui accepte de payer une UserOperation au nom du compte. Lorsqu'une UserOperation inclut des données de paymaster, l'EntryPoint demande à ce paymaster, pendant la phase de validation, s'il sponsorisera l'opération et selon quelles conditions ; le paymaster renvoie une décision accompagnée d'un blob de contexte. Après l'exécution, l'EntryPoint rappelle le paymaster lors d'une étape post-opération avec le gas réellement consommé : c'est là qu'un paymaster qui facture en token règle le montant exact. Le paymaster peut accepter sans condition (véritable sponsoring gasless, où une application absorbe le coût), ou il peut accepter en échange d'une valeur — le plus utilement, en facturant l'utilisateur dans un token ERC-20 au lieu du gas natif. Pour un examen plus approfondi de ce composant, voir ce qu'est un paymaster. Le paymaster est le point d'accroche du flux qui découple "ce avec quoi l'utilisateur paie" de "ce dans quoi le réseau est payé."

Comment le gas et les échecs sont gérés

Le gas dans ERC-4337 est stratifié. Le bundler paie de vrais ETH pour la transaction externe ; l'EntryPoint mesure le gas de validation et d'exécution de chaque UserOperation par rapport aux limites qu'elle a déclarées ; et celui qui est engagé — le compte ou son paymaster — doit avoir déposé auprès de l'EntryPoint de quoi couvrir la facture, réglée à la fin du lot. Une conséquence à connaître : une opération ERC-4337 coûte un peu plus de gas que la transaction simple équivalente, car vous payez la validation au niveau du contrat et la comptabilité de l'EntryPoint en plus de l'action elle-même.

Les échecs sont contenus par la conception validation-d'abord. Si une opération échoue lors de la validation on-chain, tout le lot serait annulé ; le bundler l'écarte donc et reconstruit son lot plutôt que de laisser cela se produire — c'est exactement à cela que sert sa simulation off-chain. Si une opération passe la validation mais que son exécution échoue (revert), les effets de l'exécution sont annulés tandis que le gas déjà dépensé est tout de même comptabilisé et payé, de sorte qu'un bundler n'est pas laissé sans compensation pour un travail honnête. C'est cette asymétrie qui explique pourquoi les bundlers simulent avec autant de soin : leur protection contre le griefing consiste à refuser d'inclure quoi que ce soit qui ne les rembourserait pas.

Le cycle de vie, dans l'ordre

1. Votre wallet construit une UserOperation : sender, nonce, calldata, limites de gas, paramètres de frais, données de paymaster optionnelles.
2. Un paymaster, s'il y en a un, valide les conditions de sponsoring avant que l'opération ne soit diffusée.
3. La logique de signature de votre compte la signe — ce qui n'a pas besoin d'être une unique clé ECDSA.
4. Le wallet la soumet au RPC d'un bundler, et elle entre dans le mempool alternatif.
5. Le bundler la simule et la valide selon les règles d'opcodes restreints et de stockage du standard.
6. Le bundler la regroupe avec d'autres opérations dans une transaction Ethereum appelant handleOps sur l'EntryPoint, et paie le gas de la couche de base.
7. L'EntryPoint valide toutes les opérations, exécute le calldata de chacune, règle les coûts sur les dépôts, rembourse l'excédent et dédommage le bundler.

Ce que cela apporte à l'utilisateur d'un wallet

La machinerie est élaborée, mais son objectif est terre à terre et utile : regrouper plusieurs actions en une seule confirmation (approve et swap ensemble, par exemple), des frais sponsorisés ou payés en token, des schémas de signature autres qu'une unique clé secp256k1, des politiques de dépense et des clés de session, et une récupération sociale ou basée sur l'appareil. Il vaut la peine de noter qu'EIP-7702 permet à un EOA ordinaire d'exécuter temporairement du code de compte intelligent, ce qui réduit l'écart pour certaines de ces fonctionnalités sans remplacer l'infrastructure ERC-4337 décrite ci-dessus.

Comment WATS utilise cela

Sur les chaînes EVM, WATS s'appuie sur exactement un élément de ce flux : l'emplacement du paymaster. Lorsque vous effectuez un transfert, un swap ou un staking dans le Hot Wallet WATS, la UserOperation que construit votre wallet désigne un paymaster, et c'est ce paymaster qui permet de facturer les frais en ATS plutôt que dans le token de gas natif de la chaîne — vous n'avez donc jamais besoin de conserver un fond de poussière d'ETH, de BNB ou de POL sur chaque réseau simplement pour pouvoir bouger. On ne vous demande pas de faire tourner un bundler, de choisir une version d'EntryPoint ou de détenir une clé RPC de bundler : cela relève de l'infrastructure, et le travail du wallet est de construire une UserOperation valide et de la soumettre.

Deux précisions gardent tout cela honnête. Premièrement, payer en ATS n'est pas une remise — le réseau facture toujours ses frais normaux et le paymaster les règle ; ce qui change, c'est donc quel token quitte votre solde, pas le coût sous-jacent. Deuxièmement, ERC-4337 est exclusivement EVM : sur Solana et TON, un dispositif de payeur de frais équivalent joue le rôle du paymaster à la place du flux EntryPoint décrit ici. ATS est un OFT LayerZero, ce qui permet à un solde ATS unique de couvrir les frais sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana et TON, et l'ATS collecté est brûlé, faisant passer l'offre de 100 000 000 à un plancher de 30 000 000. WATS reste entièrement non-custodial d'un bout à l'autre : vous détenez vos clés, et WATS n'en détient jamais aucune.

Si vous voulez voir ce flux comme un système qui fonctionne plutôt que comme une spécification, l'étape concrète est d'essayer un transfert dans le Hot Wallet WATS sur une chaîne où vous ne détenez pas du tout le token de gas natif : la UserOperation, le bundler et l'EntryPoint font leur travail hors de votre vue, et les frais sortent de votre solde ATS. Comment fonctionne le modèle de frais ATS détaille la mécanique de bout en bout.