Account Abstraction and Smart Wallets¶
ERC-4337 reviews span contracts, clients, bundlers, paymasters, simulation, mempool policy, wallet UX, and monitoring. Treat the system as a distributed security boundary, not just a contract scope.
Review questions¶
- Can a
UserOperationbe replayed, invalidated, censored, or executed outside the assumed lifecycle? - Can a paymaster be griefed, drained, throttled, or forced into unsafe
postOpbehavior? - Does wallet UX represent delegated authority, gas sponsorship, and failure modes clearly?
Review workflow¶
- Map client, account, paymaster, bundler, EntryPoint, mempool, and execution.
- Review off-chain simulation requirements alongside contract validation.
- Test replay, nonce, chain binding, session key scope, revocation, and failure handling.
- Monitor bundler health, paymaster balances, rejection patterns, and sponsorship limits.
Common risks¶
| Risk | What to verify |
|---|---|
| Implicit off-chain assumptions | Simulation, reputation, mempool policy, bundler fallback, and metrics. |
| Broad session keys | Scope, expiry, spending limits, chain binding, and revocation. |
| Paymaster griefing | Stake, deposit, sponsorship policy, postOp, throttling, and abuse monitoring. |
| Weak user intent display | Clear transaction preview and delegated authority language. |
Linked checklists¶
FAQ¶
Is account abstraction only a contract audit problem? No. ERC-4337 security spans contracts, bundlers, paymasters, client UX, mempool policy, simulation, and monitoring.
What should teams review first?
Start with the UserOperation lifecycle, replay protection, paymaster economics,
session-key scope, and what the wallet shows before signing.