ERC-7562

Defines validation rules for secure off-chain simulation of Account Abstraction operations.

ERC-7562 sets the standard for how UserOperations must behave during the validation phase of execution. These rules are enforced off-chain by bundlers to protect the mempool and prevent denial-of-service (DoS) attacks in systems using Account Abstraction (AA), such as ERC-4337, RIP-7560 and EIP-7701.

---

⭐️ Why This Matters

Unlike EOA transactions, AA introduces flexible logic during validation — like custom signature schemes or Paymaster rules — which are implemented in EVM code. Without restrictions, malicious users could submit computationally expensive or unstable UserOperations, wasting bundler resources and threatening network health.

ERC-7562 ensures that validation remains:

• Deterministic

• Resource-bounded

• Isolated from shared mutable state

---

🤔 What Does It Apply To?

ERC-7562 governs the validation phase of:

• ERC-4337 UserOperations

• RIP-7560 native AA tx types

• Any protocol with smart contract-based validation

These restrictions do not apply to the execution phase.

---

👮‍♀️ Categories of Validation Rules

1. Disallowed Opcodes

These opcodes are banned during validation for determinism and safety:

Category	Examples	Reason
Non-deterministic	BLOCKHASH, TIMESTAMP, NUMBER	Can change between blocks
State-mutating	SSTORE, SELFDESTRUCT	May cause side effects

---

2. Storage Access Restrictions

• Only bounded and deterministic reads are acceptable.

• Unbounded iteration or state-dependent reads are allowed only if the contract is staked and reputation-tracked.

---

3. External Calls

• Validation should not depend on arbitrary external contracts.

• If external state is required (e.g., for a Paymaster or aggregator), that contract must be staked and trusted.

---

4. Gas and Stack Limits

• Bundlers must cap the gas allowed for validation.

• Deep call stacks or excessive memory usage will cause rejection.

---

5. Shared State Constraints

• Validation must not rely on shared mutable state unless the contract is staked.

• This prevents one UserOperation from invalidating thousands via state manipulation.

---

🤝 Staking for Exceptions

Smart contracts (e.g. Paymasters or Factories) that want to:

• Use external calls

• Access shared state

• Run more complex validation

...may do so only if they are staked and tracked in a local reputation system used by bundlers.

---

📦 Bundler Enforcement

Bundlers are responsible for:

• Simulating UserOperations with handleOps() in view mode

• Rejecting any UserOperation that violates these rules

• Optionally maintaining a reputation system to throttle or ban abusive entities

These rules are enforced off-chain by bundlers. The EntryPoint enforces correctness on-chain, but not simulation rules like opcode bans or gas metering.

Bundlers may use tools like debug_traceCall to classify validation failures and protect themselves against gas griefing.

---

🔄 Compatibility

ERC-7562 is fully compatible with:

• ✅ ERC-4337-based flows

• ✅ RIP-7560 (L2 native AA)

• ✅ EIP-7701 (L1 native AA)

• ✅ Any custom AA mechanism that uses off-chain simulation

---

✅ Summary

ERC-7562 provides the foundational guardrails for safe validation in Account Abstraction. It ensures that flexible wallet logic doesn’t lead to exploitable complexity, enabling scalable and censorship-resistant UX for smart accounts.

By defining strict off-chain validation constraints, ERC-7562 protects bundlers, preserves mempool health, and enables Account Abstraction to scale securely.