ERC-4337 Security: Bundlers, Paymasters, Signatures

The Hidden Risks of ERC-4337: Securing Bundlers, Paymasters, and Signatures

ERC-4337 fundamentally shifts “account security” from a single Externally Owned Account (EOA) signature check into a distributed system encompassing smart account code, an onchain EntryPoint, and offchain infrastructure.

While this unlocks massive flexibility (custom authentication, gas sponsorship, transaction batching), it also creates a fragmented security perimeter. A signature that meant "authorize X" can silently become "authorize X on chain A, for account B, under paymaster policy C."

The hard truth: The most expensive bugs in Account Abstraction (AA) are almost never exotic cryptography. They are boring, systemic failures:

1. Hashing or packing mismatches.
2. Incomplete domain separation.
3. Replay windows.
4. "Policy signatures" that don't actually bind to the asset they authorize.

To secure an AA implementation, you must treat the following components as a single security boundary.

• UserOperation: The "pseudo-transaction" object living in a dedicated mempool.
• Smart Account: Implements validateUserOp, verifies authorization, enforces replay protection, and handles prefunding. Must return a “signature failed” code without reverting on mismatch.
• EntryPoint: The onchain coordinator. It runs validation, executes calls, and handles deposits/staking.
• Bundlers: Offchain relayers that accept UserOperations via JSON RPC, simulate/validate them, and submit them onchain via handleOps.
• Paymasters (Optional): Smart contracts that sponsor gas under programmable conditions. Crucially, they pay for execution even if the user operation later reverts.
• Factories: Handle account deployment data. A major attack surface for "denial of wallet" griefing (e.g., initCode front-running).

How the Threat Model Shifts

In the traditional EOA model, the blockchain enforces validity. Under ERC-4337, the "validity function" is EVM code executed during validation, shifting the threat model dramatically:

• Infrastructure is now a security boundary: Paymasters rely on external signers. If compromised, they become a centralized policy choke point.
• Availability = Liveness: If bundlers go down, or a paymaster’s deposit depletes, your "gasless onboarding" breaks. Availability is a first-class failure mode.
• Complex Nonce Semantics: ERC-4337 treats the nonce as a 192-bit key plus a 64-bit sequence. Incorrect usage leads to stuck wallets and replay bugs.
• Multiplying Signature Surfaces: You now have the validateUserOp signature, the Paymaster authorization signature, and often ERC-1271 contract signatures (isValidSignature). Each is a potential replay vector.

Real-World Failure Modes & Case Studies

1. Signature Validation & Replay Bugs

• Hash Mismatches: In early 2023, Alchemy highlighted vulnerabilities where calldata-based "pack and hash" shortcuts led to colliding hashes. If participants compute different hashes for the same operation, signatures bind to the wrong execution.
• ERC-1271 Cross-Account Replay: If the same EOA controls multiple smart accounts, a signature can be replayed across them unless the application’s signed message binds the specific contract address and chain ID (EIP-712 wrapping)

2. Denial of Wallet & Liveness

• Init/Deploy Griefing: Attackers can extract initCode from a UserOp and front-run the deployment. The original UserOp fails, forcing the user to re-sign.
• Reputation Harm via postOp Reverts: Bundlers heavily penalize paymasters if operations fail post-simulation. Token state drift (e.g., allowances changing between simulation and execution) can cause postOp reverts, leading bundlers to throttle your paymaster.

The Engineering Playbook: Component Guidelines

Signatures: Ban Bespoke Verification

Treat signature verification as a library decision, not an app-level flourish.

• Hard-gate validateUserOp: Only your chosen EntryPoint should be able to call it.
• No custom assembly hashing: Compute the userOpHash exactly as the spec demands.
• Ban raw ecrecover: Use widely reviewed libraries (like OpenZeppelin’s SignatureChecker) to prevent signature malleability.

Paymasters: Strict Sponsorship Controls

A paymaster is an onchain credit card with a strict fraud engine. If it fails, the network punishes your availability.

• Bind to the userOpHash: Do not hand-pick fields to sign unless formally proven safe.
• Cap maximum costs: Always verify maxCost assumptions and enforce per-user budgets.
• Limit postOp complexity: Design token flows so that a postOp transfer revert is practically impossible, or results in a strictly bounded, monitored loss.

Bundlers: Design for Resilience

Bundlers cannot forge operations, but they can censor, delay, or leak your calldata to MEV pipelines.

• Implement failovers: Integrate multiple bundlers and failover automatically if eth_sendUserOperation spikes in errors.
• Monitor simulation failures: High simulation failure rates usually indicate broken signature logic or paymaster policy drift.

Testing & Invariants Checklist

Ensure your test suite (e.g., Foundry) explicitly covers these scenarios:

• [ ]  Cross-Chain Replay: A UserOperation signed on Chain A fails on Chain B.
• [ ]  Cross-EntryPoint Replay: A signature for EntryPoint X fails on EntryPoint Y.
• [ ]  ERC-1271 Isolation: An ERC-1271 signature for Smart Account 1 fails on Smart Account 2, even if owned by the same EOA.
• [ ]  Paymaster Replay: Re-submitting the same paymaster signature in a new UserOperation fails (enforce nonce/expiry).
• [ ]  Front-Run Resistance: Direct factory deploy calls revert; only the EntryPoint SenderCreator path succeeds.

Practical checklist with risk to control mapping

The table below is intentionally biased toward what is most likely to break in production first.

The Golden Rule for ERC-4337 Teams:"Any new signature path, including paymaster signatures, session key attestations, and ERC-1271 support, MUST be introduced via an approved library or undergo explicit formal review, and MUST ship with replay and domain separation invariants."

Secure Your Account Abstraction Infrastructure

Account abstraction introduces a massive shift in how smart contracts manage authorization and risk. Whether you are building a custom paymaster, integrating bundler fallback logic, or preparing your smart account for mainnet, you need high-fidelity security intelligence.

Don't ship stealth-shaped risk or broken signature paths. We pair expert human review with advanced testing methodologies to surface critical vulnerabilities before they reach production.

Contact us to explore your security needs and schedule a comprehensive audit