EIP-4337 validation storage rules: banned opcodes, slots, and safety limits

EIP-4337 validation rules: opcode limits, storage access, bundler simulation. Safer paymaster and smart account implementations. Practical notes for IBEx.

3 min read

Who this is for

  • Smart contract developers
  • Security auditors
  • Bundler engineers

Pros / cons

ProsCons
  • Reduces DoS risk against bundlers
  • Makes simulation more predictive
  • Clarifies security expectations in audits
  • Constrains some legitimate patterns
  • Edge cases differ slightly by client implementation
  • Requires discipline in module design

Key takeaways

  • Keep validation minimal and deterministic
  • Avoid unbounded external calls in validation
  • Test validation with tracing on target nodes

Why validation is sandboxed

Bundlers simulate large volumes of UserOperations before spending native gas to submit bundles. If validation could execute unbounded work or depend on arbitrary state mutations visible only at inclusion time, simulation would become unreliable and attackers could grief bundlers with operations that appear valid off-chain but fail under minor state shifts. EIP-4337 therefore constrains what validation routines may do, including limits on certain opcodes and rules about which storage slots a validating contract may read or write relative to known entities in the UserOperation. These constraints trade expressiveness for predictability, similar in spirit to how Ethereum limits some patterns to keep the mempool tractable. Account developers sometimes chafe at restrictions when they want to read dynamic configuration from remote contracts during validation, but the workaround is to move heavy logic to execution or to prefetch values into allowed storage with explicit governance. IBEx Network documentation emphasizes threat modeling from the bundler perspective, not only the user perspective, because bundlers are economically rational actors that will drop traffic that risks their stake. Understanding banned opcode lists and client interpretations prevents surprises after hard forks rename or repurpose instructions.

Storage access rules in practice

Validation may interact with storage associated with the sender account, paymaster, aggregator, and related entities as defined by the specification, while writes to arbitrary third-party storage are limited to prevent validation from being a covert channel for state bloat or manipulation. Implementations track which slots were accessed during validation to detect violations when contracts attempt to depend on forbidden state. Mappings and delegatecall indirection complicate static analysis, so developers should prefer explicit storage layouts documented for auditors. Proxy patterns deserve special attention: validation logic executing through delegatecall shares storage with the proxy, which can accidentally broaden access beyond what authors intended. IBEx teams recommend cheat-sheet tables mapping common wallet patterns to allowed reads and writes, updated per EntryPoint revision. Tests should assert that validateUserOp reverts on disallowed paths rather than silently succeeding in development environments with lax tooling. When modules plug into accounts, ensure module validation hooks inherit the same constraints and cannot be used to bypass rules via indirect calls.

Opcode restrictions and client version drift

Opcode bans target instructions that break atomic reasoning about validation, including certain control flow and environment opcodes that make outcomes depend on block context in ways bundlers cannot reproduce reliably. Client releases occasionally refine how simulations enforce these bans, so a contract that passed tests months ago might fail under a stricter interpreter. Pinning nodes and bundlers to paired versions mitigates drift, as does CI jobs that run validation traces on release candidates before production promotion. IBEx operational checklists include upgrading bundlers and archival nodes in lockstep during network hard forks. Developers should avoid assembly blocks that obscure opcode usage from reviewers; readability directly impacts security. When uncertain whether a pattern is legal, prototype with official reference tests or ask for an audit opinion before shipping to users. Document any intentional deviations behind feature flags so support can quickly identify experimental code paths during incidents.

Design patterns that stay within rules

Prefer validating signatures and nonces in validation while deferring token movements, complex DeFi interactions, and oracle lookups to execution unless a carefully audited pattern demonstrates compliance. Use immutable or governance-time configuration storage for parameters that validation must read, rather than reading volatile AMM reserves during validation. Paymasters should structure token checks to avoid disallowed storage patterns while still ensuring solvency. Session key scopes can be encoded in compact storage that validation reads cheaply. IBEx reference architectures include module templates that separate validation hooks from execution routers, reducing cognitive load for internal teams. When performance tuning, remember that optimization must not trade away determinism; caching results in forbidden storage locations is not a workaround. Long term, ecosystems may introduce new precompiles or relax specific constraints as implementations mature; subscribe to standards mailing lists and run regression suites when specifications change.

Frequently asked questions

Can validation call external contracts at all?

Limited interactions exist under the rules, but unbounded or disallowed external calls are restricted. Consult the current EIP-4337 specification and your EntryPoint version for exact semantics.

Why does my paymaster work in tests but fail on bundlers?

Tests may not enforce the same validation restrictions as production bundlers. Use bundler simulation RPCs and match node versions to reproduce failures accurately.

Are storage rules identical on L2s?

The abstract rules carry over, but gas costs, precompiles, and client implementations differ. Always validate on the specific chain and client you run in production.