Bundlers and UserOperations: How ERC-4337 Transactions Work

A UserOperation is the signed intent object defined by ERC-4337: it states what a smart-contract account wants done and how that action should be validated and paid for. Unlike an ordinary Ethereum transaction it is not a protocol-level object signed by an externally owned account: its signature is checked by the account contract itself, and it does not have to pay its own native gas. A bundler is the off-chain actor that collects UserOperations from a dedicated alternative mempool, simulates each one, packs the valid ones into a single ordinary Ethereum transaction, and calls the canonical EntryPoint contract — which validates every operation in the batch before executing any of them. The bundler fronts the real gas from its own EOA and is reimbursed on-chain by the sending account or by that account's paymaster. An optional paymaster contract can agree to cover an operation during that validation step, which is where fees become sponsored or payable in an ERC-20 token instead of the chain's native gas token.

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, the explainer on what account abstraction is covers the motivation, what ERC-4337 is maps the full standard, and smart accounts vs EOAs compares the two account types directly. 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." It is a struct passed as calldata to a contract, not a native protocol object — the base layer has never heard of it.

A UserOperation carries, in substance:

• sender — the smart-contract account the operation acts for.
• nonce — replay protection, tracked by the EntryPoint as a two-part value (a key plus a sequence), so an account can run several independent nonce lanes rather than one strict queue.
• callData — what the account should execute, frequently a batch of several calls in one operation.
• account-deployment data — optional; deploys the account contract on its very first operation, which is how a smart account can be funded at a known, deterministically derived address before it exists on-chain.
• gas limits — separate budgets for validation and execution, plus a preVerificationGas figure that compensates the bundler for calldata and overhead the EntryPoint cannot meter itself.
• fee parameters — a max fee and a max priority fee, mirroring EIP-1559.
• paymaster data — optional; which contract will sponsor the operation and any context it needs.
• signature — checked by the account's own validation function, not by the protocol.

The exact encoding has changed across EntryPoint versions — v0.7 splits the deployment and paymaster blobs into explicit fields and packs several gas values together, where v0.6 used single initCode and paymasterAndData byte strings — but the conceptual contents are the same. If you are integrating, check which EntryPoint version your bundler targets.

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, session key, 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. In practice a wallet or dApp submits one by calling eth_sendUserOperation on a bundler's RPC endpoint; that bundler may gossip it to the shared alt-mempool or keep it in a private pool of its own. Either way, the infrastructure that consumes these objects listens here 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. 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.

Simulation alone is not enough protection, because state can change between simulation and inclusion. So ERC-4337 also constrains what validation code is allowed to do: during the validation phase an account or paymaster may not read block timestamps or other environment values that let it behave differently on-chain than in simulation, and its storage access is largely limited to slots associated with its own account. Contracts that act on behalf of many users — factories and paymasters especially — are expected to post a stake so that a single misbehaving contract cannot cheaply invalidate a large share of the mempool at once. These rules exist for one reason: to make a bundler's simulation a reliable prediction of what will happen 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. It is a singleton, deployed per version at the same address across EVM chains, and it holds the deposits that pay for operations. The bundler's transaction is a call to the EntryPoint with an array of UserOperations, and 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, and it reserves the maximum possible cost from whoever is paying. Only after every operation in the batch has 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, then settles the real cost and refunds the unused reservation.

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 meter gas precisely across many operations at once. It also means one operation's failure during execution cannot poison the others in the batch.

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 returns a decision plus a context blob. After execution, the EntryPoint calls the paymaster back in a post-operation step with the actual gas used, which is where a token-charging paymaster settles the exact amount. The paymaster can accept unconditionally (true gasless sponsorship, where an app absorbs the cost), 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 deposited enough with the EntryPoint to cover the bill, which is settled at the end of the batch. A consequence worth knowing: an ERC-4337 operation costs somewhat more gas than the equivalent plain transaction, because you are paying for contract-level validation and EntryPoint bookkeeping on top of the action itself.

Failures are contained by the validation-first design. If an operation fails during on-chain validation, the whole batch would revert, so the bundler drops it and rebuilds rather than letting that happen — which is exactly what its off-chain simulation is for. 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 the bundler is not left uncompensated for honest work. This asymmetry is why bundlers simulate so carefully: their protection against griefing is refusing to include anything that would not reimburse them.

The lifecycle, in order

1. Your wallet builds a UserOperation: sender, nonce, calldata, gas limits, fee parameters, optional paymaster data.
2. A paymaster, if used, signs off on sponsorship terms before the operation is broadcast.
3. Your account's signing logic signs it — which need not be a single ECDSA key.
4. The wallet submits it to a bundler's RPC, and it enters the alternative mempool.
5. The bundler simulates and validates it under the standard's restricted-opcode and storage rules.
6. The bundler packs it with other operations into one Ethereum transaction calling handleOps on the EntryPoint, and pays the base-layer gas.
7. The EntryPoint validates every operation, executes each one's calldata, settles costs against deposits, refunds the excess, and reimburses the bundler.

What this buys a wallet user

The machinery is elaborate, but the point of it is mundane and useful: batching several actions into one confirmation (approve and swap together, for example), sponsored or token-paid fees, signature schemes other than a single secp256k1 key, spending policies and session keys, and social or device-based recovery. It is worth noting that EIP-7702 lets an ordinary EOA temporarily execute with smart-account code, which narrows the gap for some of these features without replacing the ERC-4337 infrastructure described above.

How WATS uses this

On EVM chains, WATS depends on exactly one part of this flow: the paymaster slot. When you make a transfer, swap or stake in the WATS Hot Wallet, the UserOperation your wallet builds names a paymaster, and that paymaster is what lets the fee be charged in ATS rather than in the chain's native gas token — so you never need to keep a dust balance of ETH, BNB or POL on every network just to be able to move. You are not asked to run a bundler, choose an EntryPoint version, or hold a bundler RPC key; that is infrastructure, and the wallet's job is to build a valid UserOperation and submit it.

Two clarifications keep this honest. First, paying in ATS is not a discount — the network still charges its normal fee and the paymaster settles it, so what changes is which token leaves your balance, not the underlying cost. Second, ERC-4337 is EVM-only, so on Solana and TON an equivalent fee-payer arrangement plays the paymaster's role rather than the EntryPoint flow described here. ATS is a LayerZero OFT, which is what lets one ATS balance cover fees across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, and collected ATS is burned, taking supply from 100,000,000 down to a 30,000,000 floor. WATS is fully non-custodial throughout: you hold your keys, and WATS never holds one.

If you want to see this flow as a working system rather than a specification, the concrete step is to try a transfer in the WATS Hot Wallet on a chain where you hold none of the native gas token: the UserOperation, the bundler and the EntryPoint do their work out of sight, and the fee comes out of your ATS balance. How the ATS fee model works covers the mechanics end to end.