ERC-7562 is an Ethereum Improvement Proposal that formalizes and extends the set of rules governing what operations a smart account's validation logic can perform during the ERC-4337 mempool validation phase. Validation logic runs before a UserOperation is accepted into the mempool, and the bundler nodes that run validation cannot trust arbitrary onchain code. Without constraints, a malicious account could deploy validation logic that causes every bundler to spend gas simulating a transaction that ultimately reverts, creating a denial-of-service attack against bundler infrastructure at no cost to the attacker. ERC-7562 converts the informal rules that bundlers have enforced since ERC-4337 launched into a precise, enforceable specification that smart account developers can test against.
​

The proposal was introduced alongside the broader ERC-4337 ecosystem maturation in 2024. As of Q2 2026, the ERC-4337 EntryPoint contract has processed tens of millions of UserOperations on Ethereum mainnet and L2 chains including Base ($4.3B TVL), Arbitrum ($1.7B TVL), and Optimism, according to DeFiLlama chain TVL data. At that transaction volume, the stability of bundler infrastructure is a systemic concern, not just a developer consideration.
​

The bundler DoS problem is a class of attacks where an adversary submits UserOperations whose validation logic appears valid during simulation but fails when the bundler attempts to include the operation in a block, causing the bundler to waste gas with no compensation. Because bundlers pay for simulation gas out of pocket and only recover it on successful execution, sustained simulation-valid but execution-invalid operations can drain bundler economics and force operators offline.
​

The attack surface exists because validation logic is arbitrary smart contract code. A validation function could call block.timestamp, read from a storage slot that changes between simulation and execution, or call an external contract that returns different results at different times. Any of these dependencies breaks the simulation guarantee: what the bundler simulates at time T is not necessarily what the EntryPoint will execute at time T+1 when the block is built.
​

Bundler operators first documented this attack surface during the ERC-4337 specification process in 2021. The initial response was a set of informal rules baked into the reference bundler implementation at eth-infinitism/bundler: ban certain opcodes, restrict storage access, and prohibit external calls from validation context. Those rules kept bundlers stable but were never formally specified, creating uncertainty for smart account developers building complex validation logic.
​

The informal rules also varied between bundler implementations. A UserOperation that one bundler accepted might be rejected by another, depending on how strictly each operator interpreted the informal guidance. ERC-7562 resolves this inconsistency by publishing a normative specification that all bundlers can implement identically, giving developers a single authoritative target for compliance testing rather than a patchwork of per-bundler behaviors.
​

ERC-7562 converts those informal rules into a normative specification. It defines which opcodes are forbidden, which storage slots are accessible, what external calls are permitted, and how bundlers should handle accounts that violate the rules. A smart account developer can now test their validation function against ERC-7562 rules using static analysis tools, rather than deploying to a testnet bundler and watching for unexplained rejections.
​

ERC-7562 establishes constraints that validation logic must satisfy for a bundler to accept the corresponding UserOperation into its mempool. The constraints fall into four categories: forbidden opcodes, storage access limits, external call restrictions, and return data rules. Together these ensure that bundler simulation produces a stable, repeatable result across the gap between simulation time and block inclusion time.
​

ERC-7562 bans a specific set of EVM opcodes from the validation execution frame. The primary banned opcodes are BLOCKHASH, COINBASE, DIFFICULTY, GASLIMIT, NUMBER, TIMESTAMP, SELFBALANCE, and several others that return values that change block-to-block. A validation function that reads block.timestamp (which maps to the TIMESTAMP opcode in EVM bytecode) could produce a different result at simulation time versus inclusion time if the block window changes. Banning these opcodes eliminates the entire class of time-dependent validation logic at the EVM level, not just at the Solidity source level.
​

The ERC-7562 specification lists all banned opcodes in a normative table alongside the rationale for each ban. Wallet SDK developers using Solidity high-level constructs should note that some constructs that look safe at the source level compile to banned opcodes; the ERC recommends static analysis of the compiled bytecode, not the Solidity source. Solidity's block.number, block.basefee, and block.chainid all map to banned opcodes in the ERC-7562 opcode list.
​

Validation logic can read from storage slots associated with the sender account (the smart account itself) and, if a paymaster is involved, from the paymaster's associated storage. Reading from arbitrary third-party storage slots is prohibited because those slots can change between simulation and execution without the bundler's knowledge. ERC-7562 introduces a formal notion of "associated storage" tied to the sender address and a set of mappings that bundlers track to enforce this rule.
​

The associated storage model is one of the key extensions ERC-7562 adds beyond the pre-existing informal rules. Earlier bundler implementations used a coarser heuristic: any external storage access was banned. ERC-7562 allows reads from storage that is structurally tied to the account's own address, enabling richer validation patterns like reading an account's own configuration from a factory contract without violating the DoS guarantees. The formal definition of "associated storage" in ERC-7562 uses the sender address as a key in any SLOAD that refers to a storage slot computed from the sender's address as an input.
​

Validation logic cannot make arbitrary external calls. External calls introduce two risks: they can read or write state that changes between simulation and execution, and they can trigger reentrant validation paths that complicate bundler accounting. ERC-7562 permits calls to a predefined whitelist of addresses (primarily the EntryPoint itself and explicitly declared helper contracts called "staked entities") while banning calls to arbitrary addresses.
​

A staked entity is a contract that has deposited stake in the EntryPoint and is therefore subject to slashing if it behaves maliciously. The stake requirement creates an economic deterrent against deploying staked entities whose onchain state changes unpredictably. This mechanism extends the set of permissible validation behaviors without giving up the DoS protection. Paymaster contracts and aggregator contracts both register as staked entities to participate in ERC-7562-compliant validation flows.
​

ERC-7562 also specifies limits on gas consumption during validation and rules for how validation return data is interpreted. Validation must not consume more gas than the verificationGasLimit field in the UserOperation. The return data from the validation call is interpreted as a packed struct encoding the signer address, a validity window (valid-after and valid-until timestamps), and an authorized context. ERC-7562 normalizes the interpretation of this return data, eliminating ambiguities that caused different bundlers to accept or reject the same UserOperation.
​

ERC-7562's formal associated-storage model and staked-entity mechanism enable validation patterns that the earlier informal rules did not permit. Three patterns are particularly relevant: multi-key validation using onchain key registries, paymaster-delegated validation with per-account allowances, and aggregated signature validation schemes like BLS.
​

A smart account might store its authorized signers in a separate registry contract rather than in its own storage slots, so that the signing key set can be updated by a separate governance process. Under the pre-ERC-7562 informal rules, reading from the registry contract during validation was often banned as external storage access. Under ERC-7562's associated storage definition, if the registry storage is keyed by the sender's address, the read is explicitly permitted. This enables passkey wallets, multisig accounts, and enterprise account systems that keep authorization logic in shared registry contracts without triggering bundler rejection. The Safe smart account uses a similar pattern for its module registry.
​

ERC-4337 paymasters can sponsor gas for UserOperations, and their validation logic runs in the same phase as account validation. ERC-7562 formalizes the storage access rules for paymaster validation separately from account validation, allowing paymasters to read their own subscription or allowance data during validation. Paymaster protocols like Alchemy's Gas Manager and Pimlico's paymaster service depend on this capability to check account allowances before committing to gas sponsorship. Without ERC-7562's explicit paymaster storage scope, these allowance reads would be indistinguishable from arbitrary external storage reads and would be banned by strict bundler implementations.
​

ERC-4337 supports signature aggregators that combine multiple UserOperation signatures into a single onchain proof, reducing gas costs for batch operations. ERC-7562 defines the validation rules for aggregator contracts as a distinct entity class with its own associated storage permissions. BLS signature aggregation, as prototyped in eth-infinitism's sample contracts, requires the aggregator to run verification logic during bundler simulation; ERC-7562's aggregator rules define exactly what that logic can access. Aggregated signatures can reduce per-UserOperation onchain gas by 30-50% in batch scenarios, according to the ERC-4337 team's benchmarks from 2023.
​

Smart account developers need to audit their validation functions against ERC-7562 rules before deployment to ensure bundler compatibility. A validation function that passes Solidity compilation and unit tests may still fail ERC-7562 compliance if it uses a banned opcode, reads from non-associated storage, or makes an external call to an address not whitelisted as a staked entity. Bundlers that implement ERC-7562 will reject non-compliant UserOperations at the mempool level, silently from the user's perspective.
​

The practical impact for developers can be summarized across five dimensions: which validation logic is now permitted, which was already permitted but is now formally specified, which was previously permitted by some bundlers but is now explicitly banned, how paymaster rules differ from account rules, and what the testing toolchain looks like.
​

Static analysis tools targeting ERC-7562 compliance are being developed as part of the ERC-4337 tooling ecosystem. The eth-infinitism bundler reference implementation includes a simulation tracer that checks for ERC-7562 violations at runtime. Developers should run their validation bytecode through this tracer in a local hardhat or foundry environment before deploying to mainnet or submitting to a production bundler.
​

The most common compliance failure in early smart account implementations has been reading block.number or block.timestamp to implement time-based access controls (e.g., "this key is valid until block 19,000,000"). ERC-7562 resolves this pattern cleanly: use the validAfter and validUntil fields in the validation return data instead. Those fields are enforced by the EntryPoint at execution time, achieving the same semantic result without touching banned opcodes during the simulation phase.
​

ERC-7562 is a bundler-level specification, not an EntryPoint contract change. The EntryPoint contract does not enforce ERC-7562 rules onchain. ERC-7562 rules are enforced by bundler software during simulation, before any transaction reaches the chain. This means a UserOperation submitted directly to the EntryPoint via a standard Ethereum transaction, bypassing the mempool, is not subject to ERC-7562 enforcement, though it is still subject to the EntryPoint's own validation logic.
​

The EntryPoint contract (deployed at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 on Ethereum mainnet, verified in the official eth-infinitism account-abstraction repository) handles execution-time validation: it calls the account's validateUserOp function, checks the signature, and verifies the nonce. ERC-7562 addresses simulation-time validation: it constrains what the bundler is willing to simulate before the transaction ever reaches the EntryPoint. Both layers are necessary; ERC-7562 adds the simulation-time safety guarantee that the EntryPoint cannot provide on its own.
​

This distinction matters for developers testing smart accounts. An account that passes direct EntryPoint calls in tests may still be rejected by a production bundler that enforces ERC-7562. The correct testing approach is to use a local bundler instance with ERC-7562 enforcement enabled, not to test against the EntryPoint directly. Several open-source bundler implementations support this, including eth-infinitism/bundler, aa-bundler, and Stackup's bundler.
​

For cross-chain products using smart accounts, including Eco Routes' settlement flows that execute through account-abstracted contracts on Base and other networks, ERC-7562 compliance is a deployment prerequisite. Bundlers on Base (chain ID 8453) and Arbitrum (chain ID 42161) have adopted ERC-7562-aligned validation rules in line with the broader ecosystem, meaning non-compliant validation logic will fail silently at the bundler layer without reaching the chain.
​

The bundler drops the UserOperation from its simulation queue and does not add it to the mempool. No gas is consumed by the account, and no onchain event is emitted. The bundler may return an error code to the submitting application indicating the specific rule that was violated, but this behavior is implementation-dependent. The user sees a transaction that never submitted, not a revert.
​

ERC-7562 is an Ethereum standard that applies wherever ERC-4337 bundlers operate. On chains like Base, Arbitrum, and Optimism that have active ERC-4337 deployments and bundler ecosystems, ERC-7562-aligned validation rules are typically enforced by production bundlers. Chains with custom account abstraction implementations (like zkSync's native AA) have their own validation rule sets that may differ from ERC-7562.
​

No. The TIMESTAMP opcode is on ERC-7562's banned list because the block timestamp changes between simulation and execution. ERC-4337 provides a purpose-built mechanism for time-bounded validity: the validation return data includes validAfter and validUntil fields (unix timestamps) that the EntryPoint enforces at execution time. Use those fields instead of reading block.timestamp in validation logic.
​

A staked entity is a contract that has deposited ETH stake in the ERC-4337 EntryPoint and is therefore subject to slashing for misbehavior. ERC-7562 permits validation logic to make calls to staked entities because the economic stake creates a deterrent against deploying staked contracts whose state changes unpredictably. Paymasters and aggregators that want to be callable from validation context must register as staked entities.
​

Run your validation bytecode through the simulation tracer in the eth-infinitism reference bundler against a local hardhat or foundry fork. The tracer logs each ERC-7562 rule violation with the specific opcode or storage slot that triggered it. This is more reliable than testing against the EntryPoint directly, which does not enforce bundler-level rules.
​

Sources and methodology. Chain TVL data from DeFiLlama, April 29, 2026. ERC-7562 specification details verified against eips.ethereum.org/EIPS/eip-7562. EntryPoint contract address verified against eth-infinitism/account-abstraction repository. Figures refresh as specifications are updated.
​

By Eco research. Updated Apr 2026.
​