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.