EIP-4337 Account Abstraction Status 2026 vs ERC-4337 Account Abstraction Status 2026

Description: In January 2026, account abstraction on Ethereum spans two tracks: ERC-4337’s production mempool-and-EntryPoint stack (now at EntryPoint v0.9) and protocol-level EOAs via Pectra’s EIP-7702, with emerging specs like ERC-7562, ERC-7677, and ERC-7769 hardening operations and developer ergonomics.

TL;DR for decision‑makers

ERC-4337 is live and maturing: EntryPoint v0.7 became the default in 2024; v0.8 (Mar 2025) added native 7702 and EIP‑712 userOp hashing; v0.9 (Nov 2025) landed parallel paymaster signing, block-number validity windows, and safer multi-op deployment semantics. Providers are signaling deprecation of v0.6 during 2026—start migrations now. (github.com)
EIP-7702 shipped on mainnet with Pectra on May 7, 2025, letting any EOA temporarily execute smart-account logic at the same address; it is already supported by 4337 tooling and bundlers. Treat 7702 as a UX accelerator layered over your existing 4337 rails. (ethereum.org)
Operational hardening: the shared UserOperation mempool, ERC‑7562 mempool rules, and standard RPCs (ERC‑7769) plus paymaster web APIs (ERC‑7677) reduce fragmentation and make 4337 infra more predictable to run at scale. (docs.erc4337.io)

EIP vs ERC: what you need to know in 2026

You’ll see both “EIP‑4337” and “ERC‑4337” online. 4337 is an application‑layer standard (ERC) that implements account abstraction without consensus changes; the document lives in the EIPs repo, but the spec is an ERC. In 2026, “ERC‑4337” refers to the live system: UserOperations, EntryPoint, bundlers, and paymasters. The corresponding EIP page remains iterative as related standards (7562/7677/7769) converge. (eip.info)

What actually shipped (and where we are today)

Pectra activated on mainnet on May 7, 2025 (epoch 364032). Among other items, it delivered EIP‑7702: a typed transaction that lets an EOA set a delegation indicator so calls execute against delegate code at the same address. Wallets can batch, sponsor fees, or use passkeys—without migrating addresses. (ethereum.org)
ERC‑4337 kept shipping independently:
- EntryPoint v0.7 (address below) introduced PackedUserOperation, gas and postOp simplifications, structured errors, and better gas estimation. (outposts.io)
- EntryPoint v0.8 (Mar 26, 2025) added native EIP‑7702 support, EIP‑712 userOp hashing, and ignored unused‑gas penalty below ~40k; it uses a new singleton address per chain. (github.com)
- EntryPoint v0.9 (Nov 2025) added paymasterSignature (parallel signing), block‑number validity windows, “ignore initCode if deployed” to enable two‑dimensional nonces, getCurrentUserOpHash(), and an EIP‑7702 initialization event; new addresses published with the release. (github.com)

Common EntryPoint addresses you’ll encounter:

v0.6:

0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

v0.7:

0x0000000071727De22E5E9d8BAf0edAc6f37da032

v0.8:

0x4337084d9e255ff0702461cf8895ce9e3b5ff108

v0.9:
```
0x433709009B8330FDa32311DF1C2AFA402eD8D009
```
Providers support v0.6 and v0.7 broadly; v0.6 deprecation is planned “sometime in 2026,” and v0.8+ support is available from leading bundlers. Align migrations accordingly. (alchemy.com)

ERC-4337 status in early 2026: from training wheels to industrial rails

Shared mempool maturity. A decentralized shared UserOperation mempool went live across mainnet and major L2s in late 2024–2025, improving inclusion guarantees and reducing single‑bundler risk. Wallets no longer rely on siloed relays; compliant bundlers gossip valid UserOps and enforce consistent validation. (docs.erc4337.io)
Canonical validation rules (ERC‑7562). 7562 specifies mempool‑safe validation behavior to prevent unpaid DoS during validation and defines network‑wide reputation and throttling: e.g., MIN_UNSTAKE_DELAY=1 day; unstaked entities are rate‑limited; throttling/ban slack parameters cap abuse. It also defines how EIP‑7702 authorizations appear in UserOps (e.g., at most one tuple; only sender may be an authorized 7702 account). Adopt these rules in bundlers and paymasters. (eips.ethereum.org)
Standardized RPCs (ERC‑7769) and paymaster web capability (ERC‑7677). 7769 formalizes
```
eth_sendUserOperation
```
,
```
eth_supportedEntryPoints
```
, and debug endpoints for mempool introspection. 7677 standardizes the wallet ↔ paymaster web API and aligns payloads across v0.6/v0.7/v0.9 (e.g., returning
```
paymasterPostOpGasLimit
```
for v0.7). These reduce bespoke glue code and integration risk. (eips.ethereum.org)
Observability. Modern bundlers expose metrics for ingress, simulateValidation outcomes, inclusion latency, and handleOps success rates. Track per‑version behavior (0.6 vs 0.7 vs 0.8/0.9) and shared mempool gossip health to diagnose censorship or fragmentation. (docs.erc4337.io)

What this means: you can plan 4337 deployments with predictable ops runbooks and versioned change management instead of one‑off infra.

EIP‑7702 x ERC‑4337: how they work together in production

7702 authorizations make an EOA “smart” per authorization by delegating execution to contract code at the same address. EntryPoint v0.8+ and many bundlers treat 7702‑authorized EOAs as first‑class senders in the 4337 pipeline; 7562 clarifies mempool behavior with such senders. (github.com)
The result: you can keep your existing 4337 paymasters, batching flows, session keys, and analytics, while onboarding EOAs without fresh addresses or proxies. Coinbase and other infra vendors document 7702 vs 4337 roles and confirm they are complementary. (docs.cdp.coinbase.com)
Security reality: 7702 expands the phishing surface. Attackers trick users into signing an authorization tuple that delegates to malicious code (“batch‑signature” scams). Industry telemetry in 2025 attributes a portion of phishing losses to 7702‑style signatures; treat 7702 authorizations like firmware updates with explicit review and revocation UX. (cointelegraph.com)

Module standards update: ERC‑7579 vs ERC‑6900

ERC‑7579 (Minimal Modular Smart Accounts) specifies the smallest set of interfaces for validation, execution, fallback, and hooks, enabling cross‑account module compatibility without dictating architecture. It is widely adopted by account vendors as a pragmatic interoperability layer. (eips.ethereum.org)
ERC‑6900 (Modular Smart Contract Accounts) defines richer interfaces and permissioned graphs for validation/execution/hooks and is designed to be ERC‑4337‑compatible. Think of 6900 as more prescriptive, with registries/permissions ergonomics for enterprise governance. (eips.ethereum.org)
Developer guidance: if you need maximum vendor portability fast, target 7579 modules; if you need richer permission graphs and introspection, pilot 6900 (or compose both where practical). (docs.erc4337.io)

Adoption and reality checks (numbers you can benchmark)

2024 activity: independent analytics report >103M UserOperations in 2024 (vs. 8.3M in 2023). Paymasters covered ~87% of ops; bundlers executed ~59M bundles, with Coinbase/Alchemy/Pimlico/Biconomy among leaders. Engagement quality varies: only ~4.3M accounts made more than one UserOp in 2024, highlighting retention challenges for some use cases. (etherspot.io)
2025 operations: major bundlers (e.g., Etherspot Skandha) added EntryPoint v0.8/7702 support across main EVM chains; the shared mempool improved inclusion guarantees and reduced vendor lock‑in. (etherspot.io)

Takeaway: 4337 is battle‑tested at scale, but outcomes are product‑dependent. Budget for UX polish and funnel telemetry, not just infra.

Practical, concrete examples for 2026 roadmaps

1) v0.6/0.7 → v0.8/v0.9 migration playbook

Inventory by ABI: scan accounts for
```
validateUserOp
```
signature. If first parameter is
```
UserOperation
```
you’re on v0.6; if
```
PackedUserOperation
```
, you’re on v0.7. Plan a two‑track rollout and start moving to v0.7+ now; add v0.8/0.9 where you need 7702/EIP‑712/paymasterSignature features. (alchemy.com)

Update EntryPoint addresses and code‑hash allowlists:

v0.7:

0x0000000071727De22E5E9d8BAf0edAc6f37da032

v0.8:

0x4337084d9e255ff0702461cf8895ce9e3b5ff108

v0.9:

0x433709009B8330FDa32311DF1C2AFA402eD8D009

(alchemy.com)

Gas/accounting differences to test:
- v0.8 ignores unused‑gas penalty below ~40k; reduces incentive to over‑pad gas limits.
- v0.9 enables parallel paymaster signing (
```
paymasterSignature
```
  ) so accounts and paymasters can sign concurrently—shrinking confirmation latency.
- v0.9 ignores
```
initCode
```
  when the account already exists (emits
```
IgnoredInitCode
```
  ), enabling two‑dimensional nonces with parallel deployment flows. (github.com)
Mempool conformance: ensure your bundler enforces ERC‑7562 rules (throttling/ban slack, staked-entity behavior) and participates in the shared mempool. Non‑conforming peers are increasingly deprioritized. (eips.ethereum.org)
Timeline risk: vendors intend to deprecate v0.6 during 2026; maintain dual‑stack client routing until your fleet and partners are fully upgraded. (alchemy.com)

2) 7702‑front, 4337‑spine onboarding pattern

Goal: onboard EOAs with zero address churn while retaining 4337 rails.

Step 1: 7702 authorization UX
- Present a single, high‑friction “upgrade authorization” screen that identifies the delegate contract by name, code hash, and audit checksum; warn on any non‑whitelisted delegate.
- Require explicit per‑chain confirmation if you use multi‑chain authorizations. (eips.ethereum.org)
Step 2: Route intent via 4337
- Submit as a UserOp through a shared‑mempool bundler; use your existing paymaster for sponsorship and batching.
- For v0.9 stacks, get paymaster stubs the moment you have a “nearly complete” UserOp, then request the paymaster signature in parallel to the user’s signature to minimize time‑to‑confirmation. (eips.ethereum.org)
Step 3: Safety rails
- Enforce 7562 AUTH rules: one 7702 tuple per UserOp; only the sender may be an authorized 7702 account; do not allow 7702 accounts as paymasters/factories.
- Monitor for “role drift”: if a sender flips delegation between validation and inclusion, drop and reputationally throttle per 7562. (eips.ethereum.org)

3) Security defaults you should not skip

7702 phishing is real. Phishing crews are actively using 7702 batch signatures to drain wallets; industry tallies in 2025 recorded multi‑million‑dollar incidents. Mitigate with:
- Visual code‑hash attestations;
- Session‑scoped authorizations with short expiry and automatic post‑op revocation;
- Policy engines that disallow ERC‑20 unlimited approvals or NFT approvals in the same batch as value transfers unless a trusted domain is detected. (cointelegraph.com)
ERC‑6492 for pre‑deploy signatures. If your flow collects signatures before first deployment, support ERC‑6492 so dapps can verify undeployed accounts—dropping failed first‑use UX and preventing signature replay weirdness. (alchemy.com)
Use audited module registries when adopting modular accounts (7579/6900). Incorporate ERC‑7484‑style registry checks so wallets can refuse unknown/unattested modules at install time. (erc7579.com)
Budget for observability. Track simulateValidation failure classes, inclusion latency, bundle size distributions, and who actually included each UserOp (origin vs includer) to spot censorship patterns. (docs.erc4337.io)

“EIP‑4337 vs ERC‑4337” in 2026: which one should you build on?

Short answer: build on ERC‑4337 today; layer 7702 where it improves UX; watch native AA proposals.

ERC‑4337 is the shipping, widely supported account‑abstraction rail. It gives you paymasters, batching, session keys, and modular accounts across mainnet and major L2s—without protocol risk. The ecosystem now includes shared mempools, conformance rules, and standard RPCs. (docs.erc4337.io)
EIP‑7702 is already live and complementary; treat it as an EOA upgrade path that works great with 4337 infra. (ethereum.org)
Native AA (RIP‑7560 and EIP‑7701) remains in active design and L2‑first experimentation. They aim to lower gas and move AA into the canonical mempool, but they’re not mainnet standards today. Keep tabs; don’t block your product roadmap on them. (docs.erc4337.io)

2026‑ready best practices (checklist)

Versioning and addresses
- Inventory and tag accounts/bundlers by EntryPoint version; maintain per‑chain address registries and code‑hash checks.
- Plan v0.6 sunset; shift new deployments to v0.8+; evaluate v0.9 for parallel paymasterSignature and block‑number validity windows. (alchemy.com)
Mempool hygiene
- Conform to ERC‑7562; participate in the shared mempool; monitor peer reputation and drop non‑conformant ops early. (eips.ethereum.org)
Paymaster ergonomics
- Implement ERC‑7677 web methods; pre‑fill stub gas values; parallel‑sign on v0.9. Use policy‑based whitelists to control spend. (eips.ethereum.org)
Wallet UX
- Require explicit review for 7702 authorizations (delegate name, code hash, audit link). Offer one‑tap revoke. Make default sessions short‑lived. (eips.ethereum.org)
Modular accounts
- Prefer ERC‑7579 modules for baseline interoperability; add ERC‑6900 where richer permission graphs are needed. Gate with a module registry. (eips.ethereum.org)
Observability
- Track simulate vs. actual gas deltas, inclusion latency, bundle composition, and who included your UserOps. Alert on spikes in rejected ops and gossip drop‑offs. (docs.erc4337.io)

Brief in‑depth: what v0.9 changes for product teams

Faster confirmations with parallel paymaster signing. UserOps can be signed by the account and paymaster concurrently since
```
paymasterSignature
```
is excluded from the userOpHash (like the account signature). Expect a noticeable reduction in “click‑to‑confirmation” time in sponsored flows. (docs.erc4337.io)
Fewer race conditions with “ignored initCode.” Previously, parallel “first‑use” UserOps could cause cross‑invalidations; now, if the account already exists, initCode is ignored instead of reverting, enabling safer multi‑lane nonces. Audit any logic that assumed “initCode implies first‑ever op.” (github.com)
Better timeboxing with block‑number validity. You can bound UserOps by block numbers (set the high bit) to align with protocols that rely on block cadence, not timestamps—useful for sequenced actions or MEV‑sensitive flows. (github.com)

Looking ahead

Expect more 7702‑aware wallet UX patterns (firmware‑like upgrades, on‑device attestations). Also expect continued phishing attempts targeting 7702 signatures; your mitigations will be a competitive advantage. (cointelegraph.com)
Native AA proposals (RIP‑7560/EIP‑7701) could land first on L2s, then inform future mainnet design. If/when native AA arrives, your 4337 investments will carry forward: paymasters, session keys, and modular accounts remain the abstractions—just with a different transport. (docs.erc4337.io)

Appendix: useful addresses and specs to bookmark

EntryPoint v0.6:

0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

EntryPoint v0.7:

0x0000000071727De22E5E9d8BAf0edAc6f37da032

EntryPoint v0.8:

0x4337084d9e255ff0702461cf8895ce9e3b5ff108

EntryPoint v0.9:

0x433709009B8330FDa32311DF1C2AFA402eD8D009