UserOperation

A UserOperation is a standardized JSON-like object defined by ERC-4337 that packages all data required to execute a user's intent. Key fields include:

• sender: The smart contract account address.
• nonce: Prevents replay attacks.
• initCode: For deploying the account if it doesn't exist.
• callData: The calldata to execute on the sender.
• signature: Cryptographic signature for validation.
• paymasterAndData: Optional field for gas sponsorship. This structure allows Bundlers to uniformly process operations from any compliant wallet.

A core innovation is the separation of signature verification from transaction execution. The UserOperation's signature field can implement any custom logic (e.g., multisig, social recovery, session keys) defined by the smart account. The EntryPoint contract validates this signature before executing the callData. This enables features impossible with EOAs, such as:

• Batched transactions with a single signature.
• Gasless (sponsored) transactions via a paymaster.
• Transaction scheduling and expiry.

The paymasterAndData field enables gas abstraction, allowing a third-party Paymaster contract to sponsor transaction fees. This permits:

• Gasless UX: Users submit UserOperations without holding native tokens.
• Payment in ERC-20s: Fees can be paid in stablecoins or other tokens.
• Sponsored Sessions: Apps can pay for user interactions during a session. The Paymaster validates the UserOperation and deposits funds to the EntryPoint, which refunds it after execution. This is a key driver for improved user onboarding.

The initCode field handles counterfactual address generation and just-in-time account deployment. A user can generate a deterministic smart account address (using CREATE2) and receive funds before the contract is deployed on-chain. The initCode contains the factory address and calldata to create the account. When a Bundler processes a UserOperation for an undeployed account, it:

1. Uses the initCode to deploy the contract.
2. Proceeds with the UserOperation execution. This enables seamless first transactions without separate deployment steps.

UserOperations are broadcast to a peer-to-peer mempool distinct from the traditional transaction mempool. Specialized nodes called Bundlers listen to this mempool, validate UserOperations, bundle them into a single transaction, and submit them to an EntryPoint contract on-chain. Bundlers:

• Perform simulation (via eth_call) to ensure operations are valid and pay fees.
• Compete to include UserOperations based on gas fees.
• Act as the relay layer between users and the blockchain, similar to block builders in PBS.

The EntryPoint is a singleton, audited smart contract that acts as the central orchestrator and security checkpoint. Its primary functions are:

• Validation: Calls the smart account's validateUserOp function to check signatures and pay prefunds.
• Execution: If validation passes, it executes the UserOperation's callData against the sender account.
• Post-Op: Handles gas accounting and refunds to the Bundler and Paymaster. All UserOperation logic must pass through the EntryPoint, which enforces consistency and security for the entire system.

A UserOperation is a standardized JSON-like object containing the user's intent. Key fields include:

• sender: The smart contract account address.
• nonce: Prevents replay attacks.
• initCode: For deploying a new account if it doesn't exist.
• callData: The encoded function call(s) to execute.
• paymasterAndData: Optional field for gas sponsorship.
• signature: Cryptographic signature for validation.
• preVerificationGas, verificationGasLimit, callGasLimit, maxFeePerGas, maxPriorityFeePerGas: Parameters for gas management.

A Bundler is a network participant (often a node operator) that collects UserOperations from a mempool, validates them, packages them into a single blockchain transaction, and submits it on-chain. They are analogous to block builders in traditional Ethereum. Bundlers earn fees for this service and are critical for the system's decentralization and censorship resistance.

The EntryPoint is a singleton, audited smart contract that acts as the on-chain verification and execution hub. The Bundler's transaction calls handleOps() on the EntryPoint, which:

1. Validates each UserOperation's signature and pays the gas.
2. Deploys the sender account if needed (via initCode).
3. Executes the user's intended calls (via callData).
4. Compensates the Bundler. All ERC-4337 compliant accounts must interact with this single contract, ensuring security and standardization.

A Paymaster is a smart contract that can sponsor transaction fees for users, enabling key use cases:

• Gasless Transactions: The Paymaster pays all fees, improving UX.
• Pay in ERC-20 Tokens: Users pay for gas in USDC or another token; the Paymaster converts it to ETH.
• Sponsored Sessions: Apps can subsidize costs for their users. The Paymaster logic is executed and verified by the EntryPoint, and its address is specified in the paymasterAndData field of the UserOperation.

Smart contract accounts (wallets) in ERC-4337 must implement two core functions:

• validateUserOp: Verifies the UserOperation's signature and pays the upfront gas to the EntryPoint. This is where custom security logic (multi-sig, social recovery) resides.
• execute: Performs the actual calls specified in the callData. This separation allows for complex validation without burdening the execution step. The EntryPoint orchestrates this two-phase process.

UserOperations are broadcast to a dedicated alt mempool, separate from the standard Ethereum transaction mempool. This specialized P2P network is used by Bundlers to receive, validate, and propagate UserOperations. It uses different gossip rules and validation logic tailored for account abstraction, ensuring only properly formed UserOperations are considered for bundling.

Before including a UserOperation in a bundle, a Bundler must simulate its execution using eth_call to a special validation function. This simulation ensures the operation will pay its required fees and is not malicious. The bundler's reputation depends on not submitting failing operations, creating a strong economic incentive for correct validation. Failed simulations are discarded, protecting the network from spam and invalid state changes.

A Paymaster is a contract that can sponsor transaction fees for a UserOperation. This introduces specific trust vectors:

• Deposit Security: Users must trust the paymaster's solvency and honesty, as it holds deposited funds.
• Selective Censorship: A paymaster can refuse to sponsor certain operations.
• Validation Logic: Malicious validation code in a paymaster could cause a UserOperation to fail after being accepted by a bundler, wasting gas. Users should audit or use reputable paymaster services.

UserOperations use signature abstraction, allowing smart contract accounts to define their own verification logic. This flexibility requires careful implementation:

• Account-Specific Logic: The validateUserOp function must be secure against replay attacks and correctly validate the user's signature or authority.
• Signature Aggregators: For gas efficiency, multiple signatures can be aggregated off-chain. This requires trust in the aggregator to correctly construct the aggregated signature and for the on-chain verifier to validate it cryptographically.

The EntryPoint is a singleton, audited contract that orchestrates UserOperation execution. It is a critical trust assumption for the entire ERC-4337 system:

• Centralized Failure Point: A bug in the EntryPoint could affect all account abstraction transactions.
• Upgradability: Some EntryPoint implementations may be upgradeable, introducing governance trust.
• Inviolable Rules: It enforces core security rules, such as ensuring the validateUserOp function is called before execution and that paymaster deposits are managed correctly. All participants must trust its code.

UserOperations exist in a public mempool before being bundled, similar to traditional transactions. This exposes them to known risks:

• Frontrunning: A malicious actor can see a profitable UserOperation (e.g., an arbitrage opportunity) and submit their own with a higher fee to get it processed first.
• Sandwich Attacks: Particularly relevant for operations involving DEX swaps.
• Solution Patterns: To mitigate this, accounts can use private RPCs, commit-reveal schemes, or pre-confirmation services from bundlers to gain execution certainty.

The security of a UserOperation ultimately depends on the smart account (e.g., a Safe, Argent, or custom contract) that executes it. Key risks reside here:

• Upgrade Mechanisms: Malicious or compromised account upgrades can drain funds.
• Social Recovery: While enhancing usability, recovery guardians become high-value attack targets.
• Module Security: Plug-in modules that extend account functionality (e.g., session keys) must be rigorously audited. A vulnerability in any module can compromise the entire account.