Ethereum Smart Accounts Explained: UserOperations, Bundlers, and Gas Sponsorship

An ordinary externally owned account (EOA) proves control with a private-key signature. Its account nonce orders transactions. This is a simple model, but the same signing key typically authorizes every action.

One EOA transaction has one top-level action; a contract it calls can make further internal calls.

The distinction matters alongside the Ethereum pending-transaction guide, which describes the EOA transaction pool rather than the ERC-4337 flow.

A smart account is a contract that can hold assets and execute calls. Its validation code can apply account-specific rules such as one signature, a threshold of several signatures, or permissions that expire after a set time.

ERC-4337 does not prescribe one wallet product or recovery policy; it provides an interface for a contract account to authorize and execute requested operations.

Ethereum.org's account abstraction overview describes possibilities such as backup keys, limited permissions, and sponsored gas, but individual wallets may not implement every feature.

The label “smart wallet” alone does not tell you how secure an account is or who controls it. Check which contract holds the assets, which code and EntryPoint the account trusts, and which signers can authorize calls.

If the account logic can be upgraded, administrator access and change procedures also affect asset control.

A UserOperation is an object describing what a smart account wants to do. It typically includes the sender account, an account-specific nonce, call data, a signature, gas limits, and fee conditions.

It may also include factory information to create a new account or paymaster information to request sponsorship. Exact fields depend on the EntryPoint version.

Instead of sending this object directly to the chain with the ordinary eth_sendTransaction method, a wallet submits it to a bundler or relay exposing ERC-4337 RPC methods such as eth_sendUserOperation.

The request passes through a UserOperation pool that is separate from the pool for ordinary Ethereum transactions. The UserOperation hash identifies the request; the on-chain transaction created by a bundler has a separate transaction hash and receipt.

ERC-7769 defines RPC methods for submission, hash lookup, and UserOperation receipts. A response from a bundler can mean that the request passed that service's checks and entered its pool.

It does not prove that a block included it or that the app action succeeded.

How one bundler shares a request with others depends on its infrastructure and policies. Keep a provider's acknowledgement separate from the result recorded on-chain.

A bundler receives a UserOperation, checks compatibility with its EntryPoint version, then simulates the account and paymaster validation logic.

It checks whether the signature is valid, whether the account trusts that EntryPoint, and whether nonce, gas, and sponsorship conditions pass. It can reject an operation that violates its rules or fails a validation simulation.

The ERC-4337 bundler guide describes this role in simulation and bundle submission.

The bundler selects one or more operations that pass and creates one ordinary Ethereum transaction calling the EntryPoint's handleOps function.

Whether that transaction is included in a block still depends on block production and network conditions. A returned UserOperation hash is not proof that execution happened on the canonical chain.

The UserOperation pool is distinct from the EOA transaction pool, and users should not assume that every provider shares the same requests.

A bundler may reject an operation or leave it waiting; supported chains, EntryPoint versions, and policies can vary among wallets and providers. To check status, distinguish the wallet's UserOperation view, the operation receipt, and the chain receipt for the bundle transaction.

The EntryPoint receives the bundler's handleOps call and invokes each smart account's validation function. The account checks that the call came through a trusted EntryPoint and validates the signature or its own authorization rules.

The nonce packs a 192-bit key and a 64-bit sequence. EntryPoint validates and increments the sequence per account and key; the account may assign custom logic to the key or add checks. An optional paymaster also checks whether it will sponsor the operation.

After validation succeeds, the EntryPoint calls the account's execution function to carry out the action encoded in callData and settles the cost. EntryPoint is the central contract that allows smart-account flows without a protocol change for each wallet design.

The ERC-4337 EntryPoint guide explains this validation and settlement role. Check the actual deployed address, version, and chain supported by the wallet.

Simulation is a useful preview, not a promise of inclusion.

Chain state, fees, validity windows, or external contract state can change while an operation waits, changing the result of on-chain validation. Even after validation, an app call can fail or revert.

Inclusion in a block alone does not prove that the intended token transfer or contract action succeeded.

If a UserOperation includes paymaster information, the EntryPoint asks that contract whether it is willing to sponsor the operation. This can let an app cover transaction fees or let a user start an action without holding ETH in the account.

Some designs also allow token-based payment or other eligibility rules, but these depend on the wallet and paymaster implementation. Sponsorship does not make gas disappear or remove all conditions.

A paymaster can limit eligible apps, users, operation counts, or amounts, inspect the request, and reject it. Its deposit at the EntryPoint is used to pay operation costs.

If a separate stake is required, that stake serves as collateral under validation rules; it is not the same as the spendable gas deposit.

The ERC-4337 paymaster guide and EIP-4337 describe the validation and settlement flow. A fee of zero in an app interface does not mean that no cost exists.

The sponsor may pay first and later recover value through a subscription, token charge, or service terms. Check who ultimately bears the cost, whether sponsorship has a cap or one-time limit, and whether a failed operation can still incur a fee.

If a wallet supports it, a user might put an app approval and a swap into one UserOperation. Both actions are submitted as one operation through the EntryPoint.

This differs from one ordinary EOA transaction and also from a bundler putting several separate UserOperations into one chain transaction. Check the wallet's preview to see which structure it is using.

For a hypothetical fee example, suppose an approved sponsored operation has an actual gas cost of 0.0012 ETH. That cost might be settled from the paymaster's EntryPoint deposit rather than the user's account balance. The 0.0012 ETH is illustrative, not a current quote or market rate.

The actual amount depends on gas used, fee conditions, and network. Batching is not automatically cheaper or safer. Whether multiple calls are atomic depends on how the smart account handles failures.

Check whether one failed call reverts the entire batch, whether some actions could remain completed, and who pays any gas. A poor gas estimate or unavailable app may cause rejection or execution failure.

The Ethereum gas-fee guide explains the general fee fields.

A smart account can be designed with backup signers or a recovery process in which trusted guardians meet a threshold to replace a key. Some designs add a waiting period during which an existing key can object.

If one signature is always required, however, losing that key may leave no recovery path. ERC-4337 lets accounts validate UserOperations under their own rules; it does not give every account backup keys or social recovery by default.

Too few guardians or weak key-replacement rules can create an attack path. Too many guardians or demanding requirements can delay the legitimate owner's recovery. Check the threshold, waiting period, cancellation rights, and how recovery keys are held.

These rules affect who can block as well as who can authorize an operation. A contract wallet is not automatically custodial or non-custodial.

Control depends on who holds the signing keys, whether the account has administrator or upgrade authority, and what a hosted signer or recovery service is allowed to authorize. Examine the asset-holding contract separately from the keys and services that control it.

General seed-phrase backup is a separate subject covered in the wallet recovery guide.

In the wallet preview, inspect the network, account address, target contracts, call data, token-approval scope, and number of calls. A signature may authorize more than the single action highlighted in an interface.

If you cannot understand the data being signed, consult the app's and wallet's official documentation before proceeding.

To understand sponsorship, read the eligibility conditions, usage limits, alternative payment terms, and failure-cost rules rather than relying on a paymaster's name.

An active sponsorship label does not mean the app is unconditionally free, and the paymaster may still decline the operation. Network congestion or block-inclusion delays remain separate issues.

If a UserOperation is taking a long time, do not apply an EOA “speed up” or “cancel” flow without checking how that wallet handles UserOperations. Look up the operation hash and its receipt first.

If the bundler transaction hash is available, check its block receipt and execution outcome too. RPC receipts can distinguish one operation's actual cost and success from the receipt for the whole bundle transaction.

This differs from replacing or cancelling an ordinary EOA transaction with the same nonce.