ERC4337 Account Abstraction Security

ERC4337 is the account abstraction standard for Ethereum — it enables "smart accounts" where users interact with DeFi without needing native ETH for gas, using flexible signature schemes, and with programmable recovery mechanisms. As adoption grows across Base, Polygon, and Arbitrum, the unique security model of account abstraction requires careful attention.

ERC4337 architecture overview

ERC4337 introduces several new actors with distinct trust assumptions:

• EntryPoint: The singleton contract that processes UserOperations. Audited by OpenZeppelin and trusted by the ecosystem.
• Account contract: The user's smart wallet. Holds funds and implements validateUserOp.
• Paymaster: Optional contract that sponsors gas for users. Must be funded and carefully access-controlled.
• Bundler: Off-chain service that aggregates UserOperations and submits them to the EntryPoint. Partially trusted.

Vulnerability 1: Paymaster drain attacks

Paymasters hold ETH deposits in the EntryPoint to sponsor transactions. A malicious or misconfigured paymaster can be drained by:

• Open paymaster: A paymaster that sponsors any UserOperation without validation can be exploited by an attacker submitting millions of dummy operations
• Signature bypass: If paymaster validation logic doesn't check the UserOperation's sender, calldata, or gas limits, any address can claim sponsorship
• Gas parameter manipulation: Over-estimating verificationGasLimit or callGasLimit in a UserOperation wastes more of the paymaster's deposit per transaction

Always implement strict allowlist-based or signature-based paymaster validation:

function _validatePaymasterUserOp(UserOperation calldata op, bytes32, uint256)
    internal override returns (bytes memory, uint256) {
    address sender = op.sender;
    require(allowedSenders[sender], "Paymaster: sender not allowed");
    return ("", 0);
}

Vulnerability 2: validateUserOp signature vulnerabilities

The account contract's validateUserOp function must correctly verify the UserOperation signature. Common bugs:

• Not including the chainId in the signed hash — enables cross-chain replay of UserOperations
• Not including the EntryPoint address — a UserOperation signed for one EntryPoint version can be replayed on another
• Allowing signature malleability — use ECDSA.recover from OpenZeppelin, which rejects malleable signatures

See signature replay for the underlying vulnerability.

Vulnerability 3: Reentrancy through account execution

The execute function in a smart account runs arbitrary calldata — which means it can call back into the account contract or EntryPoint during execution. The ERC4337 spec includes reentrancy protection in the EntryPoint, but custom account implementations may bypass this. Apply ReentrancyGuard to account-level execution functions. See reentrancy.

Vulnerability 4: Guardian / recovery key misconfiguration

Social recovery and guardian schemes in smart accounts often allow guardian addresses to change the signing key after a delay. If the guardian list is misconfigured (wrong addresses, no delay, no threshold), an attacker who compromises a guardian key gains full account control. Always use a multisig threshold for guardian operations and implement a timelock delay.

Vulnerability 5: Bundler censorship and griefing

Bundlers can theoretically censor specific accounts' UserOperations by refusing to include them. For high-value or time-sensitive operations, plan for bundler censorship by using multiple bundler providers or fallback to direct L1 submission where possible.

Audit ERC4337 contracts

SmartContract.us analyzes account contracts, paymaster implementations, and factory contracts for the ERC4337 ecosystem. Analyze an account contract →