User Operation (UserOp)

The sender is the smart contract wallet address initiating the operation. The nonce is a unique number that prevents replay attacks and ensures the UserOp is executed only once. The EntryPoint contract manages this nonce, which can be sequential or keyed by a specific signer for more complex account logic.

InitCode is the factory contract address and calldata needed to deploy the sender's smart contract wallet if it doesn't yet exist (enabling gasless onboarding). CallData is the encoded function call that the wallet will execute, such as transferring tokens or interacting with a dApp.

The signature is a cryptographic proof (e.g., ECDSA) that the owner of the wallet authorizes the UserOp. Paymaster data contains information for a Paymaster contract, which can sponsor the transaction's gas fees or pay in ERC-20 tokens, abstracting gas complexity from the user.

A UserOp specifies its own gas parameters, separate from the underlying Ethereum transaction:

• Verification gas: For the wallet's validateUserOp function.
• Call gas: For executing the callData.
• Pre-verification gas: Covers Bundler overhead.
• Max fee per gas & Max priority fee: Set the gas price for the Ethereum block.

The EntryPoint is a singleton, audited smart contract that acts as the central orchestrator. It validates each UserOp (signature, nonce, paymaster), executes the wallet's logic, handles gas payment, and aggregates results. All Bundlers submit UserOps to this single contract address.

A Bundler is a network participant (often a node) that listens for UserOps in a peer-to-peer mempool, packages them into a standard Ethereum transaction, and submits the batch to the EntryPoint. This separates transaction construction from block building.

A UserOp is a standardized packet containing all the information needed to execute a transaction from a smart account. Its 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 encoded actions to execute.
• paymasterAndData: For sponsoring gas fees.
• signature: User verification, which can be any logic (e.g., multisig, passkey).

Bundlers are network actors (often nodes) that collect UserOps from a mempool, simulate them for validity, bundle them into a single transaction, and submit them to the blockchain. They act as the relay layer, paying the base layer gas fees and earning tips. This abstracts gas handling from the end user.

A paymaster is a smart contract that can sponsor transaction fees for users, enabling gasless transactions or payment in ERC-20 tokens. In a UserOp, the paymasterAndData field specifies which paymaster to use and provides verification data, allowing for:

• Sponsored sessions (app pays).
• ERC-20 gas payment (user pays in USDC).
• Subscription models.

The EntryPoint is a singleton, audited smart contract that acts as the central verification and execution hub. Bundlers call handleOps() on it. It is responsible for:

• Validation: Calling the smart account's validateUserOp function.
• Execution: Executing the UserOp's callData.
• Payment: Compensating the bundler and paymaster. All ERC-4337 flows must pass through this contract, ensuring security and consistency.

UserOps enable features impossible with EOAs (Externally Owned Accounts):

• Social Recovery: Use guardians to recover a lost key.
• Batch Transactions: Multiple actions in one UserOp (e.g., approve & swap).
• Session Keys: Grant limited permissions to dApps.
• Quantum Resistance: Signatures can be based on new algorithms. This shifts security and logic from the key pair to the smart contract account.

UserOps are broadcast to a dedicated alt mempool, separate from the standard transaction mempool. Before accepting a UserOp, a bundler must run a simulation via eth_call to the EntryPoint to verify it will pay fees and is valid. This prevents spam and ensures bundlers are not penalized. Failed simulations result in the UserOp being rejected.

The Bundler must verify the cryptographic signature on the UserOp before including it in a bundle. This involves:

• Ensuring the signature corresponds to the sender address.
• Validating the signature against the UserOp hash, which includes all fields to prevent tampering.
• Supporting the account's specific signature scheme (e.g., EOA-signed, multi-sig, passkey).

The Paymaster must rigorously validate payment logic to prevent subsidy abuse.

• Pre-funding checks: Verifying the account or paymaster has sufficient deposit in the EntryPoint.
• Gas limit enforcement: Ensuring callGasLimit, verificationGasLimit, and preVerificationGas are within sane bounds to prevent resource exhaustion attacks.
• Sponsorship rules: Applying strict business logic for sponsored transactions to prevent draining.

Each UserOp must be unique to prevent replay attacks.

• The EntryPoint contract uses a nonce for each sender account.
• Nonces can be sequential (for EOAs) or parallel (for smart accounts enabling concurrent sessions).
• Bundlers must check the nonce is valid and has not been used before submitting the operation.

UserOps are broadcast to a public mempool, exposing them to frontrunning and sandwich attacks.

• Searchers can copy, modify (e.g., raising maxPriorityFee), and republish a UserOp.
• Sensitive fields like callData are visible, potentially leaking intent.
• Mitigations include using private RPCs, Flashbots Protect, or future encrypted mempools.

Using a Paymaster introduces centralization and trust risks.

• A malicious or compromised paymaster can censor, frontrun, or drain its own deposit to fail user transactions.
• Users must trust the paymaster's liveness and integrity.
• Verifying Paymasters that only perform signature aggregation reduce this risk surface.

The security of a UserOp depends on the smart account's code.

• Vulnerabilities in the account's validateUserOp function or execution logic can lead to total fund loss.
• Common risks include signature malleability, reentrancy in validation, and improper access controls.
• Audits and formal verification of account factory and wallet contracts are critical.

A network actor (often a node) that packages multiple UserOps into a single on-chain transaction. It's critical for efficiency and gas economics.

• Function: Collects UserOps, simulates them via the EntryPoint, and submits a bundle.
• Incentive: Earns fees via priority gas auctions and bundler-specific MEV.

A smart contract that sponsors transaction fees for users, enabling gas abstraction. It can pay in ERC-20 tokens or entirely on a user's behalf, removing the need for native ETH in the wallet.

• Use Cases: Sponsored transactions (dApp pays), subscription models, and fee payment in stablecoins.
• Validation: Must stake ETH and is subject to anti-abuse rules.

The singleton, audited smart contract that acts as the orchestrator and security gatekeeper for the ERC-4337 system. All UserOp bundles must pass through it.

• Core Duties: Validates each UserOp's signature and paymaster, executes the operation, and compensates the Bundler.
• Security: A single, widely-reviewed contract to minimize attack surface.

An ERC-4337-compliant smart contract wallet that is a user's primary account (vs. a key pair). It validates and executes UserOps.

• Capabilities: Social recovery, multi-signature rules, batch transactions, and session keys.
• Examples: Safe{Wallet}, ZeroDev, Biconomy, and Argent.

A service that sits between users and the network, optimizing UserOp submission. It finds the best Bundler and Paymaster for cost and reliability.

• Function: Provides a simplified RPC endpoint (like eth_sendUserOperation), handles gas estimation, and fee management.
• Examples: Stackup, Pimlico, Alchemy's Account Kit.