Summary: ERC-7562 is best understood as mempool-governance infrastructure for account abstraction rather than as a wallet feature or a minor implementation note. Its core move is to define what smart-account validation code is allowed to do before inclusion, so bundlers can safely simulate UserOperation-style flows without opening themselves to unpaid denial-of-service attacks. The useful mechanism lens is that ERC-7562 governs who may consume bundler resources, what kinds of validation logic are admissible, and when staked entities are allowed to exceed the default sandbox.
What it does:
Defines validation-scope rules for account-abstraction systems such as ERC-4337 and RIP-7560
Separates network-wide rules from bundler-local rules so peers can distinguish malicious spam from local-state disagreement
Restricts validation-time opcode usage, external calls, environment access, gas behavior, and storage access patterns
Limits how unstaked entities can rely on shared state, while allowing broader access for staked entities that accept reputation and capital requirements
Defines reputation states such as OK, THROTTLED, and BANNED, with formulas tied to observed versus included operations
Requires repeated validation and tracing before mempool admission and again before bundle submission, making simulation discipline part of the standard itself
Key claims:
The abstract says ERC-7562 defines rules AA protocols should follow during the validation phase and says they are enforced off-chain by block builders or bundlers, which is the clearest signal that this belongs in the corpus as admission-control infrastructure
The motivation explains that AA replaces hard-coded transaction validation with EVM code and therefore needs explicit guardrails so a submitted operation remains economically guaranteed to pay, preserving the anti-DoS properties that EOAs get implicitly
The specification distinguishes network-wide rules from local rules, which is analytically important because it separates universal mempool norms from bundler-specific policy and local-state conflict
The constants and mempool rules set explicit limits for same-sender and same-entity mempool counts, verification gas ceilings, bundle sizes, and context sizes, showing that ERC-7562 is not just a philosophical safety note but a concrete congestion-control scheme
The opcode rules ban environment-sensitive opcodes such as TIMESTAMP, NUMBER, BLOCKHASH, BASEFEE, and SELFDESTRUCT during validation, which makes determinism and bounded simulation a first-class requirement
The storage rules allow much broader access for staked entities and explicitly define associated-storage exceptions, which means staking is not just Sybil resistance here but the gateway to richer validation behavior
The reputation rules define THROTTLED and BANNED states from opsSeen versus opsIncluded, revealing that ERC-7562 effectively builds a reputation-weighted mempool constitution for paymasters, factories, aggregators, and other validation-time actors
The official ERC-4337 docs say bundlers may apply local policies or reputation scoring via ERC-7562 and describe it as the standard that keeps off-chain simulation deterministic, resource-bounded, and protected from shared-state abuse
Those docs also emphasize that the restrictions apply to validation, not execution, which matters because ERC-7562 is not limiting smart-account expressiveness in general; it is deciding what logic may run before the network trusts an operation enough to include it
Whitepaper: No standalone ERC-7562 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC itself and the official ERC-4337 documentation site; see ../../whitepapers/erc-7562-primary-sources-2026-05-07.md.