Bundlers and UserOperations: How ERC-4337 Transactions Work

A quick ERC-4337 recap

ERC-4337 is the Ethereum standard for account abstraction — a way to give smart-contract accounts the same first-class ability to initiate and pay for actions that externally owned accounts (EOAs) have always had, without any change to the base protocol. Instead of modifying the consensus layer, ERC-4337 introduces a parallel system of higher-level objects and off-chain infrastructure that ultimately settles through ordinary Ethereum transactions. If you want the ground-up version first, our explainer on what account abstraction is covers the motivation, and what ERC-4337 is maps the full standard. This post zooms into the mechanics: the objects that move through the system and the actors that process them. Note that ERC-4337 is an EVM standard — it applies to Ethereum and EVM-compatible chains, not to non-EVM chains like Solana or TON.

What a UserOperation actually is

The central object in ERC-4337 is the UserOperation. It looks superficially like a transaction, but it is better understood as a signed statement of intent: "here is what my account wants done, and here are the parameters for validating and paying for it." A UserOperation carries fields such as the sender account, a nonce, the calldata to execute, gas limits, fee parameters, an optional paymasterAndData field, and a signature.

The key difference from a normal transaction is who and what signs it. A conventional Ethereum transaction must be signed by an EOA's private key using a fixed ECDSA scheme, and that same account pays the gas. A UserOperation is validated by the sender's own smart-contract account logic — which can implement whatever signature scheme, multi-key rule, or authorization policy the account defines — and it does not have to pay for itself in native gas at all. That flexibility is the whole point: the account, not the protocol, decides what a valid action looks like.

The alternative mempool where they live

UserOperations do not enter the regular Ethereum transaction mempool, because they are not yet transactions. Instead they are broadcast to a separate alternative mempool (often called the alt-mempool) — a peer-to-peer network dedicated to ERC-4337 objects. Wallets and dApps submit UserOperations here, and the infrastructure that consumes them listens on this network rather than on the base-layer mempool. This separation keeps account-abstraction traffic off the consensus-critical path until the moment it is packaged into a real transaction.

The bundler's role

A bundler is the off-chain actor that turns intents into on-chain reality. Its job has four parts. First, it collects UserOperations from the alternative mempool. Second, it simulates and validates each one — running the account's validation logic in a simulated context to confirm the signature is valid, the nonce is correct, and the account (or its paymaster) can cover the cost — while enforcing rules that stop operations from consuming resources they cannot pay for. Third, it packs one or more valid UserOperations into a single ordinary Ethereum transaction. Fourth, it submits that transaction to the network from its own EOA, paying the base-layer gas up front and expecting to be reimbursed on-chain.

Because the bundler fronts gas and earns fees for inclusion, it behaves much like a specialized block builder for account-abstraction traffic. Its simulation-and-validation step is what protects it: it will not bundle an operation that would fail to reimburse it.

The EntryPoint contract

Everything converges on a single, canonical smart contract called the EntryPoint. The bundler's transaction is a call to the EntryPoint with an array of UserOperations. The EntryPoint then runs a strict two-phase loop. In the validation phase, for each operation it calls the sender account's validation function (and the paymaster's, if one is specified) to re-check the signature, nonce, and payment arrangement on-chain. Only after all operations in the batch have been validated does it move to the execution phase, where it dispatches each operation's calldata to its account to actually perform the transfer, swap, or other action.

This split matters: validation and execution are separated so that a batch's payment guarantees are established before any state-changing work runs, and so the EntryPoint can account for gas precisely across many operations at once.

Where the paymaster fits

A paymaster is an optional contract that agrees to pay for a UserOperation on the account's behalf. When a UserOperation includes paymaster data, the EntryPoint asks that paymaster, during the validation phase, whether it will sponsor the operation and under what terms. The paymaster can accept unconditionally (true gasless sponsorship), or it can accept in exchange for value — most usefully, by charging the user in an ERC-20 token instead of native gas. For a deeper look at this component, see what a paymaster is. The paymaster is the hook in the flow that decouples "what the user pays with" from "what the network is paid in."

How gas and failures are handled

Gas in ERC-4337 is layered. The bundler pays real ETH for the outer transaction; the EntryPoint meters each UserOperation's validation and execution gas against the limits it declared; and whoever is on the hook — the account or its paymaster — must have staked or deposited enough to cover the bill, which the EntryPoint settles at the end. Failures are contained by the validation-first design. If an operation fails during on-chain validation, it is simply excluded and cannot land, and the bundler's off-chain simulation is meant to catch this before submission. If an operation passes validation but its execution reverts, the execution effects roll back while the gas already spent is still accounted for and paid — so a bundler is not left uncompensated for honest work. This is why bundlers simulate so carefully: their protection against griefing is refusing to include anything that would not reimburse them.

How WATS uses this

On EVM chains, WATS relies on exactly one piece of this flow: an ERC-4337 paymaster. When you make a transfer, swap, or stake in the WATS Hot Wallet, the paymaster is what lets your fee be charged in ATS rather than in the chain's native gas — you never need to hold ETH, BNB, or any other gas token to transact. Because ATS is a LayerZero OFT, a single ATS balance covers fees across EVM, Solana, and TON (on non-EVM chains an equivalent fee-payer plays the paymaster's role), and collected ATS is burned from 100,000,000 toward a 30,000,000 floor. WATS remains fully non-custodial — you hold your own keys — and it is the first and only wallet to combine ERC-4337 + OFT single-token fees charged instead of native gas with that burn. See how the ATS fee model works for the full picture.