Account Abstraction (ERC-4337) in Production: What It Enables and What It Does Not

ERC-4337 is infrastructure for programmable accounts, not a ready-made promise of gasless transactions, recovery, passkeys, session keys, lower fees, or security. It defines a UserOperation flow involving a smart account, bundler, EntryPoint, and optional paymaster. Product properties come from the chosen account implementation and services.

Wavect has worked on account abstraction products, including the published AA case study and MetaMask Snap work. Those projects inform this checklist but do not prove that one stack fits every wallet.

What is ERC-4337?

ERC-4337 introduces UserOperations through higher-layer infrastructure without requiring Ethereum consensus changes. A user sends a UserOperation to a bundler. The bundler validates and packages operations into a transaction to the EntryPoint. The smart account validates authorization and executes calls. An optional paymaster can agree to cover fees under its policy. The specification defines replay binding, validation, deposits, stakes, simulation, and execution behavior (ERC-4337 specification).

The signature field is interpreted by the smart-account implementation. That flexibility can support different authorization schemes, but ERC-4337 alone does not create passkeys, guardians, recovery, spending limits, or session keys.

What can a concrete smart-account stack enable?

• Sponsored fees. A paymaster can pay network fees when its validation accepts the operation. The sponsor still needs policy, deposits, budgets, abuse controls, and reconciliation.
• Alternative fee collection. A product can combine sponsorship with offchain charging or token settlement, subject to implementation, price, liquidity, and regulatory constraints.
• Multiple calls. An account can execute several calls according to its code. Whether this is one user approval and whether it saves gas depends on the implementation and workload.
• Custom authorization. The account can validate supported signature schemes, passkeys, multisig, guardians, roles, or scoped delegates.
• Recovery and rotation. A wallet implementation can define key rotation or recovery. Its security follows the recovery factors, delays, cancellation path, and governance.
• Deployment on first use. A factory can create a counterfactual account when the UserOperation is processed.

What does ERC-4337 not guarantee?

• Gasless operation. Someone pays network fees, and failed or reverted operations can still create cost.
• Lower gas. Validation, EntryPoint, paymaster, factory, and account execution add workload. Batching can amortize some work, but measure the exact calls.
• Recovery safety. Recovery can reduce key-loss risk while adding guardian, identity, delay, coercion, and social-engineering risks.
• Bundler decentralization or availability. The product must evaluate compatible operators, policies, EntryPoint support, failover, censorship, and service levels.
• Cross-chain identity. Account addresses, deployments, deposits, providers, state, and supported features can differ by chain.
• Understandable consent. Multiple calls and delegated permissions still require accurate simulation and clear user-facing authorization.

Which attack surfaces need explicit tests?

How should a paymaster be designed?

Define who is eligible, what calls are allowed, maximum cost, time and replay binding, budgets, rate limits, pricing, authorization, and accounting. Assume hostile inputs. A paymaster maintains a deposit for fees and, where required by its validation behavior, a stake. It can pay even when execution reverts.

The ERC-4337 documentation describes deposit-drain, high-cost, reverted-call, timeout, and race risks, together with deterministic validation and bundler simulation requirements (paymaster security guidance). Treat offchain signers and APIs as part of the security boundary.

How do EOAs compare with ERC-4337 smart accounts?

An externally owned account has fixed protocol authorization through its key. A smart-account implementation can add richer validation and execution while adding code, configuration, service, and governance risk. Neither is categorically right for consumers, operators, or high-frequency users.

Compare the concrete options on onboarding, supported wallets, recovery, authorization, transaction simulation, gas, latency, availability, upgrades, audits, integrations, support, and exit. Do not assume an EOA has no recovery path or that a smart account always has one; surrounding custody and product controls matter.

"Account abstraction creates a programmable security boundary. Its safety depends on the program, authorities, services, and recovery path you actually ship."

What is EIP-7702?

EIP-7702 is a protocol feature that lets an EOA set a delegation indicator pointing to code. The delegation is persistent until changed or cleared, not temporary for one transaction. It can support batching, sponsorship, and restricted subkeys through the delegated implementation. It also introduces initialization, storage, delegation, relayer, and compatibility risks.

The EIP specifies the authorization tuple and persistent code delegation and documents security considerations such as initialization front-running, storage management, sponsored-relayer griefing, and interactions with tx.origin (EIP-7702). ERC-4337 also defines how EIP-7702 delegated accounts can submit UserOperations. The approaches can complement each other.

Can you run your own bundler?

Yes, if the implementation supports the relevant EntryPoint and mempool rules. Self-operation adds node dependencies, simulation, fee estimation, mempool policy, reputation rules, monitoring, updates, denial-of-service protection, key operations, and on-call ownership. A hosted provider adds counterparty, compatibility, availability, policy, privacy, and exit risk.

Choose from measured requirements. Test at least one fallback where the product promises continuity, and verify that failover preserves operation status, idempotency, fee handling, and user communication.

Do you need a custom account contract?

Not by default. Evaluate maintained implementations against the required signature scheme, modules, recovery, upgrades, standards, chains, EntryPoint version, audit history, incident response, integration support, and governance. There is no supportable claim that named implementations cover 90 percent of real-world needs.

Build custom code only when a documented requirement is not met and the benefit justifies design, testing, independent audit, monitoring, upgrade, and migration ownership. Reuse does not remove the need to assess configuration and modules.

What should authorize production launch?

1. Freeze supported account, EntryPoint, factory, module, paymaster, bundler, chain, and client versions.
2. Document authorization, recovery, upgrade, pause, deposit, sponsorship, and emergency owners.
3. Test replay, initialization, signature, nonce, module, delegate, paymaster, simulation, failure, and upgrade paths.
4. Measure gas and latency for representative successful, reverted, sponsored, batched, and recovery operations.
5. Run independent review at the risk boundary, including configuration and integrations.
6. Rehearse bundler and provider failure, deposit exhaustion, key compromise, rollback, and user support.
7. Monitor accepted outcomes, rejection reasons, sponsorship cost, bundler health, account versions, and privileged changes.

When an operation fails between the wallet, bundler, paymaster, and EntryPoint, paste the exact artifact into our free ERC-4337 UserOperation debugger. It separates packed fields and AA error codes locally without sending another RPC request. Our blockchain engineering service can help turn the threat model into implementation and evidence.