Account abstraction ERC-4337: gasless transactions guide

ERC-4337 achieves account abstraction on Ethereum without protocol changes by introducing the UserOperation mempool and EntryPoint contract at the application layer. StarkNet and zkSync have native account abstraction at the protocol level — every account is a smart contract from the protocol's perspective, without needing a separate mempool or EntryPoint overhead. Native account abstraction is more gas-efficient and architecturally cleaner, but only available on chains designed for it from the start. ERC-4337 brings equivalent capabilities to all EVM-compatible chains including Ethereum mainnet, making it the practical choice for Ethereum ecosystem applications regardless of the architectural tradeoff versus native approaches.

On Ethereum mainnet, a typical ERC-20 transfer via smart account costs approximately 100,000–150,000 gas (versus 65,000 for an EOA transfer), costing $0.50–$3.00 at typical gas prices. On Base or Optimism, the same operation costs $0.001–$0.01. For consumer applications with typical usage volumes, gasless sponsorship on L2s costs $100–$500 per month per 10,000 monthly active users — often less than the customer acquisition cost savings from removing the ETH onboarding requirement. Budget Paymaster deposits based on projected transaction volumes and set per-user daily limits to prevent Paymaster drain from exploitative behaviour.

Yes — Safe 1.4.1 introduced native ERC-4337 compatibility through the Safe4337Module, allowing existing Safe multisig wallets to submit UserOperations to the ERC-4337 EntryPoint. This enables gasless transactions and Paymaster sponsorship for existing Safe deployments, and allows Safe's battle-tested multisig security model to be combined with ERC-4337's UX features. For enterprise treasury management applications on Safe, the ERC-4337 module enables automation use cases (recurring payments, conditional executions) without requiring separate signer transactions for each operation.

ERC-4337 smart accounts still require at least one signer key by default — the account's validation logic checks that UserOperations are signed by an authorised key. The difference is that the signing relationship is defined in contract code rather than hardcoded by the protocol, enabling additional signing methods (passkeys, biometrics, multi-factor) and recovery mechanisms (social recovery, guardian recovery). The seed phrase problem can be eliminated entirely by using passkey-based smart accounts (ERC-7579 compatible) where the signing key is stored in a device's secure enclave rather than as a seed phrase — providing Web2-level key management UX with Web3 self-custody properties.

ERC-6900 defines a standard interface for modular smart accounts — smart accounts that can have plugins (validation modules, execution modules) installed and removed dynamically. This enables smart accounts to add functionality — new signing schemes, spending limits, automation rules, social recovery — as plugins without deploying a new account contract. ERC-6900 is analogous to the ERC-20 standard for fungible tokens: it enables an ecosystem of interoperable plugins that work across any ERC-6900-compliant smart account rather than being tied to a specific account implementation. Alchemy's Modular Account is the reference ERC-6900 implementation.

Bundlers monitor the UserOperation mempool, simulate UserOperations for validity and gas estimation, package them into Ethereum transactions, and submit to the EntryPoint. They earn fees via the gas overpayment in each UserOperation (the difference between the UserOperation's gas price and the Bundler's actual submission cost). Running your own Bundler provides censorship resistance and eliminates dependency on third-party bundler availability, but requires Ethereum node infrastructure, ongoing maintenance, and handling the economic model of bundler operation. For most applications, using a third-party Bundler-as-a-service (Pimlico, Alchemy, Stackup) is the right choice — self-hosting bundlers is reserved for infrastructure providers and applications with extreme censorship resistance requirements.

Hardware wallet compatibility with ERC-4337 has improved significantly in 2025–2026. Ledger and Trezor support signing ERC-4337 UserOperations in their firmware, allowing hardware wallets to authorise smart account transactions. The user experience is not yet as smooth as EOA hardware wallet signing — UserOperations require custom signing flows rather than standard Ethereum transaction signing — but the signing flow works correctly. For high-security smart accounts (Safe with hardware signing), the hardware wallet serves as the authorised signer while the smart account provides the programmable logic layer — combining hardware key security with smart account flexibility.

ERC-4337 UserOperations have higher gas costs than equivalent EOA transactions due to: EntryPoint contract overhead (~20,000 gas), smart account validation logic (~10,000–30,000 gas depending on implementation), and Paymaster validation if used (~10,000 gas). For a simple ETH transfer, smart account gas usage is approximately 2–3× an EOA transfer. This overhead is significant on Ethereum mainnet but negligible on L2s where base gas costs are already in the thousands rather than tens of thousands of gas. The gas overhead is generally considered worthwhile for the UX improvements enabled — the overhead cost is typically less than $0.01 on L2s and the conversion improvement from removing ETH onboarding requirements far exceeds the per-transaction gas premium.