Account Abstraction Deep Dive: ERC-4337 Bundlers, EntryPoint & Paymasters

The ERC-4337 Protocol Architecture: The 4 Core Primitives

Introduced in 2021 by Vitalik Buterin and leading Ethereum researchers, ERC-4337 achieves account abstraction entirely at the application layer through four core architectural components:

1. UserOperation (UserOp):

An off-chain pseudo-transaction object that expresses the user's intent. Instead of standard transaction fields, a UserOp includes:

• sender: The smart account address.
• nonce: Anti-replay sequence counter supporting 2D parallel nonces for asynchronous execution.
• initCode: Factory contract bytecode to deploy the smart account deterministically via CREATE2 if it does not yet exist.
• callData: Function execution payload (e.g., executing a swap on Uniswap).
• callGasLimit, verificationGasLimit, preVerificationGas: Precise gas allocations for validation and execution phases.
• maxFeePerGas, maxPriorityFeePerGas: Standard EIP-1559 fee parameters.
• paymasterAndData: Optional paymaster address and sponsorship verification signature.
• signature: Arbitrary signature payload validated by the smart account (ECDSA, Passkey, or multi-sig).

1. Bundler:

A specialized node operator that monitors an alternative peer-to-peer UserOperation mempool. The bundler packages multiple valid UserOps into a single standard Ethereum transaction calling the canonical EntryPoint contract. Bundlers run specialized simulations (using eth_estimateUserOperationGas) to ensure all operations in the bundle will execute cleanly without reverting.

1. EntryPoint Contract:

The canonical, singleton smart contract (deployed deterministically across all EVM networks at 0x0000000071727De22E5E9d8BAf0edAc6f37da032). It coordinates the validation and execution phases for every UserOp on Ethereum.

1. Smart Account (Sender):

The user's on-chain programmable wallet contract implementing the standard IAccount interface.

The EntryPoint Validation & Execution Loop (Phase Separation)

To protect Bundlers from Denial-of-Service (DoS) attacks where an invalid UserOp causes a bundled transaction to revert on-chain (wasting the Bundler's ETH gas), the EntryPoint strictly enforces a Two-Phase Execution Lifecycle:

Phase 1: Verification Loop (validateUserOp)

1. Account Creation: If the account is not yet deployed, the EntryPoint calls the factory specified in initCode to deploy the smart account using CREATE2.
2. Account Validation: The EntryPoint calls sender.validateUserOp(userOp, userOpHash, missingAccountFunds).
3. The smart account verifies the signature (e.g., ECDSA, passkey, or multi-sig).
4. The account checks nonces and time-range validities (validUntil, validAfter).
5. If valid, the account transfers the required prefund gas payment to the EntryPoint contract.
6. Paymaster Validation (if present): The EntryPoint calls paymaster.validatePaymasterUserOp(). The paymaster validates its sponsorship signature and guarantees fee payment.

Phase 2: Execution Loop Once all UserOps in the bundle pass verification, the EntryPoint executes each UserOp sequentially:

• Calls sender.execute(target, value, data).
• Measures actual gas consumed during execution.
• Calculates the final refund: any unused prefunded gas is refunded back to the smart account or Paymaster immediately.

This strict separation guarantees that bundlers are always compensated for execution gas regardless of whether the user's internal callData succeeds or reverts.

Paymasters: Gasless Transactions & ERC-20 Fee Payments

Paymasters are smart contracts that sponsor transaction gas fees on behalf of users or allow users to pay gas in arbitrary ERC-20 tokens (such as USDC, DAI, or USDT).

How Paymasters Function in Production:

1. Gas Sponsorship (B2C dApps & Web3 Gaming):
2. A Web3 game or decentralized exchange deposits ETH into the EntryPoint contract.
3. When a user signs a UserOp, the dApp's backend signs a paymaster token approving gas sponsorship.
4. The user enjoys a completely seamless, zero-gas onboarding experience without needing cryptocurrency.

1. ERC-20 Token Gas Payment:
2. The user holds USDC but zero native ETH.
3. The UserOp callData approves and transfers USDC to the Paymaster contract.
4. The Paymaster uses an on-chain Chainlink or Uniswap oracle to calculate the real-time exchange rate between USDC and ETH, validates the user's token allowance, and pays the EntryPoint in native ETH on the user's behalf.
5. Post-Execution Reconciliation: After the transaction executes, the Paymaster calculates the exact ETH gas spent and transfers the precise equivalent amount of USDC from the user's balance, refunding any excess allowance.

Paymasters eliminate the #1 user onboarding hurdle in crypto, enabling mainstream consumer applications with frictionless onboarding flows.

Modular Smart Accounts (ERC-7579) & Plugin Architecture

As smart accounts evolved across the ecosystem, protocols faced a growing risk of ecosystem fragmentation and vendor lock-in where smart wallets built on Biconomy, ZeroDev, or Kernel could not share feature modules or security plugins.

To solve this fragmentation, ERC-7579 established the Modular Smart Account Standard:

• Minimal Core Architecture: The core smart account contract contains only essential storage variables, fallback handlers, and module execution routing, minimizing attack surface and deployment gas costs.
• Standardized Module Interfaces: Developers can write plug-and-play modules that work seamlessly across any ERC-7579 compliant smart wallet:
• Validation Modules: Add new signature schemes (e.g., WebAuthn Passkeys, Multi-Sig, BLS aggregation, weighted multisig, and dead-man switches).
• Execution Modules (Executors): Allow authorized automated agents to execute trades on behalf of the user within predefined constraints (e.g., automated DCA bots, limit order executors, automated yield rebalancers).
• Fallback Handlers: Extend account functionality with custom token receivers, flash loan receivers, and utility hooks.
• Hooks: Pre-execution and post-execution security guards enforcing daily spending limits, velocity firewalls, and address whitelisting.

Modular smart accounts turn the user wallet into an extensible, upgradable decentralized operating system where users can dynamically install, configure, and uninstall security plugins without migrating their balances.

Institutional Use Cases: Session Keys, Batching & Social Recovery

Account Abstraction transforms the operational capabilities of institutional and enterprise Web3 platforms across three primary capabilities:

1. Atomic Transaction Batching (Multicall):

In traditional EOAs, trading on Uniswap requires two sequential transactions: approve() and swap(), requiring two wallet popups and two separate gas fees. In ERC-4337, approve and swap are batched atomically into a single UserOp, preventing frontrunning between approval and execution.

1. Session Keys for Automated High-Frequency Infrastructure:

Institutions can generate a temporary Session Key delegated to a server bot with strictly scoped permissions:

• Allowed to trade only on the ETH/USDC pair on Uniswap v3.
• Capped at a maximum volume of $50,000 per 24-hour window.
• Valid for exactly 7 days.

If the server is compromised, the attacker cannot steal assets outside the strict session key constraints.

1. Guardian-Based Social Recovery:

Eliminates seed phrases by designating trusted Guardians (e.g., 3-of-5 institutional legal partners, cold wallets, or identity providers). If credentials are lost, Guardians initiate a timelocked recovery process to assign a new signing key.

1. Subscription and Automated Recurring Payments:

Enables recurring monthly subscription charges (e.g., SaaS Web3 tooling, streaming subscriptions) authorized via recurring allowance execution modules without requiring manual user signatures every billing cycle.

Frequently asked questions

What is the main difference between ERC-4337 and EIP-3074 / EIP-7702?

ERC-4337 works entirely at the application layer without protocol hard forks using an EntryPoint contract. EIP-7702 introduces consensus-level transaction types allowing existing EOAs to temporarily act as smart contracts.

Why do bundlers need an alternative mempool in ERC-4337?

Standard Ethereum mempools only propagate transactions that pay gas from EOAs. ERC-4337 UserOperations are not native transactions, so bundlers use a dedicated P2P mempool to share and validate UserOps before bundling.

Can an ERC-4337 smart account pay gas in USDC instead of ETH?

Yes. By utilizing a Paymaster contract, the paymaster accepts USDC from the user and pays the EntryPoint in native ETH, enabling gas payments in any liquid ERC-20 token.

What is a Session Key in Account Abstraction?

A session key is a temporary key with restricted permissions (e.g., limited spending caps, approved contract addresses, and expiration times) that allows automated bots to execute transactions without user prompts.

Related reading

• combining off-chain MPC signers with ERC-4337 smart accounts — Compare client-side cryptographic keys with on-chain programmable smart accounts.
• integrating WebAuthn passkeys directly into ERC-4337 account validation — Discover how smart accounts use WebAuthn P-256 curves for seedless onboarding.

## Sources

• ERC-4337: Account Abstraction Using Alt Mempool — Ethereum Improvement Proposals
• Proxy Upgrade Pattern documentation — OpenZeppelin

No contributor to this article holds a professional cryptography or security credential. Every technical claim above is sourced to primary protocol documentation rather than to personal authority — follow the sources and verify anything you intend to act on.

Not financial advice. Crypto assets are volatile and can lose value. This article describes how protocols work, not what you should buy.