UserOp Mempool

The mempool decouples the signing of a user operation from its execution. A user signs and submits a UserOp, which enters the mempool. A separate actor, the bundler, later picks it up, packages it into a bundle transaction, and pays the gas for on-chain execution. This separation enables gas sponsorship and batched execution.

UserOps can specify a paymaster, a contract that sponsors transaction fees. The mempool must validate that a paymaster is willing and able to pay for the operation. This enables gasless transactions for users, who can pay fees in ERC-20 tokens, or have them sponsored by dApps, abstracting away the need for native chain currency.

A core function is the aggregation of multiple UserOps into a single bundle transaction. Bundlers monitor the mempool, select operations based on fee priority or other rules, and submit them as a batch. This reduces on-chain overhead and gas costs per operation, making micro-transactions and complex session keys feasible.

Before accepting a UserOp, the mempool (or bundlers) perform simulation using eth_call to verify it will execute successfully without reverting. UserOps also have a validity window, defined by validUntil and validAfter timestamps, during which they can be bundled. Expired operations are purged from the pool.

Each smart contract account has its own nonce sequence for UserOps. The mempool must respect this ordering to prevent nonce gaps that would block subsequent operations. Bundlers must execute UserOps from a single sender in strict nonce order, which is a key difference from EOA-based mempools.

Unlike a single centralized service, a robust UserOp mempool is a peer-to-peer network of nodes and bundlers. This decentralized design prevents censorship and single points of failure. Nodes gossip UserOps using a dedicated P2P protocol (e.g., ERC-4337 mempool spec), ensuring redundancy and high availability for the system.

A malicious actor can flood the mempool with invalid UserOperations that fail signature validation or pay insufficient fees. This can clog the bundler's processing queue, wasting its resources and potentially censoring legitimate users. Mitigations include:

• Aggressive filtering of invalid ops before inclusion.
• Reputation systems for senders.
• Staked bundlers with slashing for censorship.

Bundlers can reorder, censor, or insert their own UserOperations to extract Maximal Extractable Value (MEV). This can lead to:

• Time-bandit attacks replacing a user's profitable transaction.
• Sandwich attacks on DEX trades initiated by UserOps.
• Unfair fee extraction. Permissionless bundler networks and fair ordering protocols (e.g., SUAVE, MEV-Share) are proposed solutions.

The bundler is a critical, trusted role. If few bundlers exist, the system becomes vulnerable to:

• Single points of failure for transaction inclusion.
• Censorship of specific applications or users.
• Collusion to increase fees. Reliability depends on a robust, permissionless network of bundlers, which is still an early-stage challenge for ERC-4337 adoption.

When a paymaster sponsors gas fees, users must trust it not to:

• Rug-pull by revoking its sponsorship, causing transactions to fail.
• Censor transactions based on content.
• Frontrun sponsored transactions. Verifiable paymaster policies and reputation systems are essential for decentralized, reliable sponsorship.

Signature aggregation (e.g., BLS) can reduce gas costs but introduces complexity. A bundler must correctly verify aggregated signatures, which is computationally intensive. Faulty verification could lead to:

• Invalid bundles being submitted on-chain, wasting gas.
• The entire bundle reverting, harming reliability. Robust client implementations are critical.

A healthy, interconnected peer-to-peer mempool is vital for censorship resistance and low latency. Challenges include:

• Network partitions isolating bundlers.
• Propagation delays causing stale UserOperations.
• Non-standard data in paymasterAndData or signature fields causing compatibility issues. Standardized P2P protocols (e.g., ERC-4337 Bundler Network spec) aim to address this.

The singleton, audited smart contract that serves as the central verification and execution hub for ERC-4337. All bundled UserOps are sent here. It:

• Validates each operation's signature and paymaster sponsorship.
• Executes the operation's logic on the target contract.
• Handles fee payment and refunds. Its standardization ensures system-wide security and interoperability.

A contract that can sponsor transaction fees for users, enabling gasless transactions or payment in ERC-20 tokens. The paymaster is simulated by the bundler and must deposit stake in the EntryPoint. It defines sponsorship rules, allowing for:

• Sponsored sessions (free for user).
• ERC-20 gas payment (e.g., pay fees in USDC).
• Subscription models.

The decentralized peer-to-peer network where bundlers broadcast and receive UserOperations. Unlike Ethereum's base-layer mempool, this is a separate gossip network specific to ERC-4337 messages. It ensures censorship resistance and liveness by allowing multiple bundlers to see pending operations. Clients use libp2p or similar protocols for discovery and communication.

An optional component that allows smart accounts to use custom signature aggregation schemes. Instead of submitting a single signature per UserOp, an account can delegate signature verification to an aggregator contract. This bundler can then submit a single aggregated signature for a batch of operations, significantly reducing on-chain gas costs for complex multi-signature setups.