erc4337-account-abstraction

# ERC-4337 / Account Abstraction detection ## When this applies - Smart-wallet implementations (SimpleAccount, Safe-AA, Kernel, Biconomy, Light Account, custom) - Paymaster contracts (verifying, deposit, token-paying, sponsorship) - Module systems (ERC-7579, ERC-6900) and session-key managers - Bundler / mempool-side relayer logic (rare in app code, but watch for) - EIP-7702 delegated EOAs ## Detection patterns ### `validateUserOp` storage-rule violation (HIGH) ERC-4337 §6 forbids `SLOAD` on storage slots outside the wallet's own contract during validation. Bundlers reject non-compliant UserOps. Beyond compliance, accessing external state during validate is a *banner attack surface* (e.g. reading from an attacker-controlled contract). ```solidity function validateUserOp(...) external returns (uint256) { uint256 x = IExternal(0xabc).read(); // ← violates storage rules + leaks attack surface ... } ``` ### Missing `msg.sender == entryPoint()` check (CRITICAL) ```solidity function validateUserOp(...) external returns (uint256) { // ← anyone can call directly, bypass bundler entirely } ``` ### Paymaster `postOp` revert risk (HIGH) ```solidity function postOp(PostOpMode mode, bytes calldata ctx, uint256 actualGasCost) external { require(...); // ← if this reverts in postOp, bundler is griefed; reputation system penalizes the paymaster } ``` `postOp` should be revert-free. Use try/catch or never revert. ### Paymaster oracle manipulation for token-paying (H...