Account Abstraction Security: How ERC-4337 Smart Wallets Fail

Legacy Ethereum wallets force you to act like a cryptography clerk. You juggle 12 secret words, keep ETH on hand just to move stablecoins, and blindly sign raw cryptographic hashes. ERC-4337 throws that out. Under this standard, your wallet isn't an account tied to a private key. It's a programmable smart contract that runs logic on your behalf.

That makes onboarding smoother. You can cover gas in USDC, schedule trades, recover accounts without seed phrases, and batch five clicks into one. But programmable execution rewrites how transactions get validated, routed, and settled. By shifting protocol rules into smart contract code, ERC-4337 introduces attack vectors normal wallets never had to worry about.

The ERC-4337 Architecture: Moving Beyond EOAs

To spot the security risks, you have to look at how traditional accounts work. A standard wallet is an Externally Owned Account (EOA). It's just a public address tied to a private key. Ethereum validates an EOA transaction directly at the protocol level: checks the signature, checks for enough ETH gas, increments the nonce, runs the payload. One atomic step.

ERC-4337 sidesteps those hardcoded rules without touching Ethereum's core consensus layer. It adds an off-chain mempool and relies on four primary components to move transactions along.

In this setup, your wallet is the Smart Account contract. You don't broadcast standard transactions directly to the network anymore. Instead, you sign a UserOperation structure and toss it into an alternative mempool.

Step-by-Step: How an ERC-4337 Transaction Executes

ERC-4337 breaks execution into two strict steps: the Validation Phase and the Execution Phase. That split dictates how gas gets paid and where code fails.

1. Construction: You build a UserOperation containing your target contract call, gas limits, signature, and optional Paymaster data.
2. Broadcast: You send the UserOperation to the off-chain ERC-4337 alt-mempool.
3. Bundler Simulation: A Bundler node pulls your operation and runs a local simulation calling the EntryPoint to check signatures, state, and Paymaster funds.
4. Submission: The Bundler bundles valid UserOperations into one standard Ethereum transaction and broadcasts it to the network.
5. Validation Phase: The EntryPoint contract processes each operation. It calls validateUserOp on your Smart Account and validatePaymasterUserOp on the Paymaster. If validation passes, gas gets pre-allocated or locked inside the EntryPoint.
6. Execution Phase: The EntryPoint executes the call data against your Smart Account. If the target contract reverts, the spent gas still goes to the Bundler.
7. Post-Execution (PostOp): If a Paymaster was used, the EntryPoint calls postOp to handle token transfers, refunds, or gas adjustments.

A Worked Example: Paymaster Gas Sponsorship

Let's look at how gas mechanics work in practice. A trader wants to swap 1,000 USDC for ETH on a decentralized exchange. The wallet holds 1,000 USDC and 0 ETH.

An EOA rejects this immediately. No native ETH means no transaction. Under ERC-4337, a Paymaster contract covers the ETH gas fee upfront and collects USDC from the trader instead.

The Concrete Numbers

Here's the exact breakdown of gas and token math for the transaction:

• Base Gas Parameters: Verification Gas Limit = 50,000; Call Gas Limit = 100,000; PreVerification Gas = 21,000. Total Gas Limit = 171,000 gas.
• Gas Price: Max Fee Per Gas = 30 Gwei (0.00000003 ETH per unit of gas).
• ETH Price: $3,000 per ETH.
• Token Exchange Rate: USDC pegged at $1.00. The Paymaster adds a 10% premium to absorb token volatility.

Once submitted, the gas math runs like this:

• Maximum ETH Gas Cost: 171,000 gas * 30 Gwei = 0.00513 ETH.
• Dollar Value of Gas: 0.00513 ETH * $3,000 = $15.39.
• Required USDC Charge (With 10% Premium): $15.39 * 1.10 = 16.929 USDC.

During the Validation Phase, the EntryPoint calls validatePaymasterUserOp. The Paymaster checks if the Smart Account approved it to pull at least 16.929 USDC. It freezes that balance requirement and signals approval to the EntryPoint with a deposit lock.

During the Execution Phase, the swap runs, using 120,000 actual gas instead of the 171,000 limit. Real gas cost: 0.0036 ETH ($10.80). The EntryPoint refunds the unused gas to the Paymaster's deposit. In the postOp step, the Paymaster pulls 11.88 USDC ($10.80 + 10%) from the user's wallet. The trade goes through. Zero ETH required in the wallet.

Paymaster Exploit Vectors: The Validation-Execution Gap

Paymasters are vulnerable because validation and execution are decoupled. The EntryPoint guarantees the Bundler gets paid once validation passes. If execution fails, the Paymaster eats the bill anyway.

1. Validation Griefing Attacks

An attacker can forge a UserOperation designed to pass validatePaymasterUserOp but fail on purpose in the execution phase after consuming maximum gas. If the Paymaster doesn't check execution conditions strictly during validation, an attacker can flood the network with these payloads. The Paymaster's ETH deposit inside the EntryPoint gets burned to zero on junk executions.

2. Dynamic State Poisoning

To defend against griefing, ERC-4337 limits what Paymasters can inspect during validation. A Paymaster can't read fast-changing storage outside its scope. If a developer builds validation logic that depends on dynamic external state—like a DEX spot price—an attacker can alter that state right before the bundle hits a block. Simulation passes in the mempool, but execution reverts on-chain. The Paymaster or Bundler loses the gas fee.

Bundler Centralization and MEV Risks

Bundlers aren't protocol consensus nodes. They're private relays run by specialized operators or MEV searchers. That setup creates centralizing bottlenecks.

Alternative Mempool Censorship

UserOperations don't sit in Ethereum's public mempool. You rely on Bundlers to push them through. If only a handful of operators run active Bundler nodes, they control the door. They can censor operations, jack up priority fee requirements, or order transactions to favor their own off-chain margins.

Private MEV Extraction

Bundlers inspect transaction calls, allowances, and targets before operations hit a block. An aggressive operator can look at a user's batch, insert their own trades ahead of or behind it, and harvest Maximal Extractable Value (MEV). If a Smart Account submits a large token trade sponsored by a Paymaster, the Bundler can front-run it inside the exact bundle sent to block builders.

Smart Account Permission Sprawl: Modules and Session Keys

Smart Accounts rely on modular setups like ERC-6900 or ERC-7579 to add features like session keys, spending limits, and automated trading. Every added module opens another entry point for attack.

Unrestricted Session Key Scopes

Session keys let dApps execute transactions on your behalf without asking for a signature every time. You might give an exchange a session key to auto-sign orders. But if the Smart Account doesn't restrict that key to specific targets, function signatures, and spending caps, an attacker who extracts that session key can drain the wallet.

Malicious Module Upgrades

Smart Accounts often use delegatecall proxies to swap logic or attach plugins. If a wallet provider ships a buggy upgrade, or if the access control on installModule is weak, an attacker can attach a malicious delegatecall module. That gives the module direct write access to the wallet's funds and state storage.

Common Mistakes Users and Developers Make

• Blind-Signing Complex UserOp Payloads: Signing raw UserOperation hashes without decoding the underlying call data, Paymaster address, and fee caps.
• Setting Infinite Lifetime Session Keys: Leaving session keys active indefinitely without timestamps or transaction-level spend limits.
• Relying on Unverified Paymaster Logic: Deploying sponsor contracts that lack reentrancy protection or fail to check token allowances before validating.
• Ignoring Fallback Implementations: Using Smart Account upgrade mechanisms that can be hijacked by an unauthorized multisig or single admin key.

Frequently Asked Questions

Can a compromised Bundler steal the funds stored inside my smart wallet?

No. A Bundler can't pull funds directly. The EntryPoint contract enforces protocol rules requiring valid signatures from your Smart Account key. But a malicious Bundler can front-run your transactions, sandwich your swaps, charge maximum gas limits, or ignore your operations entirely.

What happens if a Paymaster runs out of ETH mid-transaction?

If the Paymaster's deposit in the EntryPoint contract falls below the estimated gas cost for a UserOperation, validation fails instantly with a revert. The transaction drops before execution logic runs. Your wallet funds stay safe, but the operation won't execute until the Paymaster refills its balance or you pay for gas yourself.

How do session keys differ from traditional ERC-20 token approvals?

Traditional ERC-20 approvals let a contract pull a fixed token amount from your address. Session keys give a secondary keypair execution rights to trigger transactions directly from your wallet. Session keys can run multi-step transactions across multiple protocols, which makes scoping them correctly far more critical than setting a simple token cap.