ERC-7562 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-7562 whitepaper or litepaper surfaced.
• The clearest current source of truth was the draft ERC itself, supplemented by the official ERC-4337 documentation site.
• The sources consistently frame ERC-7562 as the validation-rule layer that keeps account-abstraction mempools and bundlers from being DoS’d by arbitrary smart-account logic.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7562
• Key excerpt/signals:
  • The abstract says ERC-7562 defines rules AA protocols should follow during validation of ERC-4337 UserOperations or RIP-7560-style native AA transactions.
  • It says these rules are enforced off-chain by a block builder or standalone bundler.
• Why it mattered:
  • This is the clearest evidence that ERC-7562 belongs in the corpus as admission-control and bundler-protection infrastructure rather than wallet UX.

2) Canonical ERC page / motivation

• URL: https://eips.ethereum.org/EIPS/eip-7562
• Key excerpt/signals:
  • The motivation says account abstraction moves transaction validation, gas payment, and execution logic into EVM code.
  • It emphasizes the network-sustainability rule that once a transaction enters the mempool it must be guaranteed to pay.
  • It frames the proposal as restoring that anti-DoS incentive structure for smart-account systems.
• Why it mattered:
  • These passages show the mechanism-level purpose: ERC-7562 is about preserving mempool economics when validation becomes programmable.

3) Canonical ERC page / rule taxonomy

• URL: https://eips.ethereum.org/EIPS/eip-7562
• Key excerpt/signals:
  • The specification distinguishes network-wide rules from local rules.
  • It says violations of network-wide rules should damage the reputation of the peer bundler that propagated the UserOperation.
  • It says local-rule violations should not trigger peer reputation damage because bundlers may reasonably disagree.
• Why it mattered:
  • This is analytically useful because ERC-7562 does not just define safety rules; it defines what kind of disagreement is considered malicious versus merely local.

4) Canonical ERC page / opcode, storage, and stake model

• URL: https://eips.ethereum.org/EIPS/eip-7562
• Key excerpt/signals:
  • The opcode rules ban environment-sensitive instructions like TIMESTAMP, NUMBER, BLOCKHASH, BASEFEE, and SELFDESTRUCT during validation.
  • The storage rules allow much broader access when an entity is staked.
  • The constants specify minimum unstake delay and minimum stake value as the threshold for a “staked entity”.
• Why it mattered:
  • These sections show that ERC-7562 is effectively a validation sandbox with an explicit capital-backed escape hatch for more complex behavior.

5) Canonical ERC page / reputation and throttling

• URL: https://eips.ethereum.org/EIPS/eip-7562
• Key excerpt/signals:
  • The spec defines opsSeen and opsIncluded counters and derives OK, THROTTLED, and BANNED states from them.
  • It also defines mempool-count caps and throttling limits for problematic entities.
• Why it mattered:
  • This reveals that ERC-7562 is not merely about static code rules; it also specifies how bundlers should socially and economically discipline recurring bad actors.

6) Official ERC-4337 docs / interpretive summary

• URL: https://docs.erc4337.io/core-standards/erc-7562.html
• Key excerpt/signals:
  • The docs say ERC-7562 makes validation deterministic, resource-bounded, and isolated from shared mutable state.
  • They say complex behavior such as external calls or shared-state access is allowed only for staked contracts tracked by reputation.
  • They say bundlers enforce these rules off-chain via simulation and may use tools like debug_traceCall.
• Why it mattered:
  • This source makes the role of ERC-7562 very legible: it is the practical ruleset that decides what validation logic is acceptable in the public AA mempool.

Working conclusion

ERC-7562 is best cataloged as the mempool constitution for account abstraction: it defines the validation sandbox, the stake-and-reputation exceptions, and the throttling logic that let bundlers safely admit programmable smart-account transactions without giving away unpaid computation.