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

Description

As we dive into January 2026, account abstraction on Ethereum is moving forward on two main tracks: first up, we have ERC-4337 with its production-ready mempool-and-EntryPoint setup, and it’s currently running on EntryPoint v0.9. On the flip side, we’ve got the protocol-level EOAs from Pectra’s EIP-7702. And let’s not forget about some cool new specs that are on the horizon, like ERC-7562, ERC-7677, and ERC-7769, all aimed at streamlining operations and making things a whole lot easier for developers.

TL;DR for decision‑makers

• ERC-4337 is officially live and continuously improving! By 2024, EntryPoint v0.7 became the favorite version. Then, in March 2025, we got v0.8, which brought some awesome features like native 7702 support and EIP‑712 userOp hashing. Jump ahead to November 2025, and v0.9 rolled out with cool additions like parallel paymaster signing, block-number validity windows, and better multi-operation deployment semantics. Providers are already hinting at retiring v0.6 throughout 2026, so it’s smart to start migrating now. Check it out here: (github.com)
• EIP-7702 made its debut on the mainnet with Pectra on May 7, 2025. This update lets any externally owned account (EOA) temporarily harness smart-account capabilities using the same address. It’s already backed by the 4337 tools and bundlers. Think of 7702 as a way to supercharge your user experience while complementing your existing 4337 setup. For more info, head over here: (ethereum.org)
• On the operations side, the shared UserOperation mempool, ERC‑7562 mempool rules, and standard RPCs (ERC‑7769), along with paymaster web APIs (ERC‑7677), are all coming together to cut down on fragmentation. This is making it way easier to run 4337 infrastructure smoothly at scale. If you want to dive deeper, check it out here: (docs.erc4337.io)

---

EIP vs ERC: what you need to know in 2026

When you're browsing around online, you might stumble upon both “EIP‑4337” and “ERC‑4337.” Just to clear things up, 4337 is an application-layer standard (ERC) that introduces account abstraction without requiring any changes to the consensus layer. While you can find the document in the EIPs repository, the actual specification is categorized as an ERC. By 2026, when folks mention “ERC‑4337,” they’re referring to the live setup, which consists of UserOperations, EntryPoint, bundlers, and paymasters. The related EIP page will keep evolving as it aligns with other standards like 7562, 7677, and 7769. Feel free to check it out here: (eip.info).

---

What actually shipped (and where we are today)

• Pectra officially launched on the mainnet on May 7, 2025 (epoch 364032), and it brought some pretty exciting features along with it. One standout is EIP‑7702, which lets an Externally Owned Account (EOA) set up a delegation indicator. What this means is that calls can run against delegate code right at the same address. Plus, wallets are now able to batch transactions, sponsor fees, and use passkeys--all without the hassle of migrating addresses. If you want to dive deeper into the details, check it out on ethereum.org.
• In the meantime, ERC‑4337 has been making some impressive progress:
  • EntryPoint v0.7 (check out the address below) introduced some cool updates like PackedUserOperation, simplified gas and postOp processes, structured error handling, and better gas estimation. Curious for more details? Swing by outposts.io.
  • EntryPoint v0.8 (released on March 26, 2025) rolled out native EIP‑7702 support, added EIP‑712 userOp hashing, and ensured that any unused gas penalties below around ~40k wouldn’t hit you hard; plus, it now uses a fresh singleton address for each chain. For all the nitty-gritty details, check out github.com.
  • EntryPoint v0.9 (launching in November 2025) is gearing up to roll out some awesome features! We’re talking about paymasterSignature for parallel signing, block-number validity windows, and a handy function to skip initCode if it’s already deployed. This is going to make two-dimensional nonces a reality. Plus, it’ll bring in getCurrentUserOpHash() and an EIP‑7702 initialization event, along with fresh addresses popping up when it drops. For all the latest updates, don’t forget to check out github.com.

Check out some of the common EntryPoint addresses you’ll run into:

• v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789
• v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032
• v0.8: 0x4337084d9e255ff0702461cf8895ce9e3b5ff108
• v0.9: 0x433709009B8330FDa32311DF1C2AFA402eD8D009

Most providers are definitely on board with v0.6 and v0.7, but just a quick heads up--v0.6 is going to be phased out “sometime in 2026.” If you're exploring v0.8 and later, you'll find support from several leading bundlers. Make sure you plan your migrations accordingly! For all the nitty-gritty details, check it out here.

---

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

• Shared mempool maturity. Starting in late 2024-2025, we saw the launch of a really neat decentralized shared UserOperation mempool on the mainnet and major L2s. This development has boosted inclusion guarantees and reduced the risks associated with relying on single bundlers. With this setup, wallets aren’t just hanging out, waiting on isolated relays; now, compliant bundlers are actively sharing valid UserOps, which keeps validation on point. You can dive deeper into it here: (docs.erc4337.io)
• Canonical validation rules (ERC‑7562). So, here’s the scoop on ERC-7562: it’s all about keeping mempool validation safe from those pesky unpaid DoS attacks. The proposal lays out some cool guidelines for how validation should behave to protect the network. For example, there’s a MIN_UNSTAKE_DELAY set at 1 day, which means that when entities unstake, they’ll face some rate-limiting. There are also throttling and ban slack parameters designed to curb any potential abuse. Another important point is how EIP‑7702 authorizations are handled in UserOps--they only allow one tuple and ensure that the sender is the sole authorized account for that 7702. If you’re working with bundlers and paymasters, it makes sense to integrate these rules. Want to dive deeper? Check it out here: (eips.ethereum.org)
• Standardized RPCs (ERC‑7769) and paymaster web capability (ERC‑7677). So, ERC-7769 is all about giving a clear structure to eth_sendUserOperation, eth_supportedEntryPoints, and a few handy debug endpoints for checking out the mempool. On the flip side, ERC-7677 brings some consistency to the API between wallets and paymasters. It aligns payloads across versions v0.6, v0.7, and v0.9, especially with how it handles paymasterPostOpGasLimit for v0.7. This really helps reduce the need for custom glue code and makes integrations a lot less risky. Want to learn more? Check it out here: (eips.ethereum.org)
• Observability. These days, modern bundlers are quite open about their performance. They provide cool metrics for things like ingress, simulation validation results, inclusion latency, and success rates for handleOps. You can easily track how different versions stack up against each other (like 0.6 vs 0.7 vs 0.8/0.9) and check the health of the shared mempool gossip to catch any potential issues, such as censorship or fragmentation. For more details, take a look here: (docs.erc4337.io)

What this means is that you can easily set up 4,337 deployments using dependable ops runbooks. This way, you can manage versioned changes efficiently instead of juggling random, one-off infrastructure setups.

---

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

• So, here's the deal: 7702 authorizations are like giving your EOA a cool “smart” upgrade, allowing it to execute contract code right from the same address. With EntryPoint v0.8+ in the mix and a bunch of bundlers hopping on board, these 7702-authorized EOAs get to enjoy the VIP treatment as top-tier senders in the 4337 process. Plus, 7562 helps clarify how these senders act in the mempool. Check it out here: (github.com)
• So, what’s in it for you? You can keep using your existing 4337 paymasters, batching flows, session keys, and analytics without having to set up new addresses or proxies for EOAs. Coinbase and a few other infrastructure providers are syncing up on this, showing how the roles of 7702 and 4337 mesh nicely together. Check it out here: (docs.cdp.coinbase.com)
• Just a quick heads-up about security: the introduction of 7702 actually increases the phishing risk. Scammers have found ways to trick users into signing off on an authorization tuple that will redirect to malicious code (these are known as "batch-signature" scams). By 2025, we’re expected to see industry data linking some phishing losses to these 7702-style signatures. So, it’s really important to handle 7702 authorizations with the same care you’d give to firmware updates--make sure you review them and have a way to revoke them if needed. (cointelegraph.com)

---

Module standards update: ERC‑7579 vs ERC‑6900

• ERC‑7579 (Minimal Modular Smart Accounts) sets up the essential interfaces you need for validation, execution, fallback, and hooks. The idea is to let different accounts play nicely together without tying you down to any specific setup. A lot of account vendors have jumped on this because it provides a simple route to interoperability. Want to dive deeper? Check it out here.
• ERC‑6900 (Modular Smart Contract Accounts) levels up the game by introducing some pretty sophisticated interfaces and permission graphs for validation, execution, and hooks. While ERC‑7579 aims for simplicity, you can see 6900 as the intricate roadmap that still plays nice with ERC‑4337. This is a real win for businesses needing clear registries and permission management. Curious about the nitty-gritty? Check it out here.
• Developer guidance: For a fast track to compatibility with various vendors, the 7579 modules are your best bet. But if you’re after something more robust, complete with detailed permission setups and insights, you might want to check out the 6900 modules (or even combine both for a balanced approach). For a deeper dive, take a look at the docs here.

---

Adoption and reality checks (numbers you can benchmark)

• 2024 activity: A new analytics report reveals that we’re gearing up for over 103 million UserOperations in 2024--a massive leap from the 8.3 million we saw in 2023! Paymasters have been handling about 87% of those operations, while bundlers managed to create around 59 million bundles. Some big names in the game include Coinbase, Alchemy, Pimlico, and Biconomy. That said, engagement quality is a bit of a mixed bag--only about 4.3 million accounts executed more than one UserOp this year, highlighting some challenges with retention for certain use cases. For more info, you can check it out here.
• 2025 operations: As we look toward 2025, some big players in the bundling game, like Etherspot Skandha, are ramping up their efforts. They're rolling out support for EntryPoint v0.8/7702 across all the major EVM chains. This new shared mempool feature is really changing the game--it’s enhancing inclusion guarantees and easing those pesky vendor lock-in issues. If you want to dive deeper into the details, check it out here.

Takeaway

So, 4337 has really shown its strength in tackling larger scale challenges. Just remember, the results you see can vary a lot based on the product. It's super important to set aside some budget for fine-tuning the user experience and keeping an eye on your funnel performance--not just on infrastructure.

---

Practical, concrete examples for 2026 roadmaps

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

• Inventory by ABI: Take a look at the accounts for the validateUserOp signature. If the first parameter shows UserOperation, then you’re rolling with v0.6; on the other hand, if it’s PackedUserOperation, congrats, you’re using v0.7! It’s a good idea to set up a two-track rollout and start making the shift to v0.7+ right away. And if you're eyeing those 7702/EIP‑712/paymasterSignature features, don’t forget to sprinkle in v0.8/0.9 where needed. (alchemy.com)
• Update EntryPoint addresses and code-hash allowlists:
  • v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032
  • v0.8: 0x4337084d9e255ff0702461cf8895ce9e3b5ff108
  • v0.9: 0x433709009B8330FDa32311DF1C2AFA402eD8D009 (alchemy.com)
• Gas and accounting differences to check out:
  • In v0.8, if you’re under about 40k, the unused-gas penalty doesn’t really kick in. This makes it easier to play it safe with gas limits.
  • v0.9 steps it up with parallel paymaster signing (paymasterSignature). This means both accounts and paymasters can sign at the same time, which is pretty cool because it speeds up confirmation times!
  • Another neat thing in v0.9 is that if an account already exists, it just skips the initCode (and throws out an IgnoredInitCode), allowing for two-dimensional nonces with parallel deployments. Check it out on (github.com)!
• Mempool conformance: Ensure that your bundler complies with the ERC‑7562 guidelines, like throttling/ban slack and the behavior of staked entities, while actively participating in the shared mempool. If your peers aren’t playing by the rules, they might find themselves getting deprioritized. (eips.ethereum.org)
• Timeline risk: Hey, just a heads up! Vendors are looking to phase out v0.6 by 2026. It’s a good idea to maintain a dual-stack client routing until your fleet and partners are completely upgraded. You can find more details here.

2) 7702‑front, 4337‑spine onboarding pattern

Goal: Onboard EOAs with Zero Address Churn While Keeping 4337 Rails Intact

• Step 1: 7702 Authorization UX
  • Kick things off with a simple but firm “upgrade authorization” screen. It's super important to clearly display the delegate contract name, code hash, and audit checksum. And just a friendly reminder--if it’s not on the approved delegate list, make sure to give a warning!
  • If you’re working with multi-chain authorizations, you’ll need to confirm each chain one at a time. (eips.ethereum.org)
• Step 2: Route Intent via 4337
  • Go ahead and submit your request as a UserOp through a shared-mempool bundler. It's totally fine to use your current paymaster for sponsorship and batching - it really helps to keep everything organized!
  • If you're working with v0.9 stacks, make sure to snag those paymaster stubs when your UserOp is "almost done." Then, ask for the paymaster's signature at the same time you get the user's signature. This little trick can really speed up the confirmation process. (eips.ethereum.org)
• Step 3: Safety Rails
  • Stick to the rules laid out in 7562 AUTH: there should only be one 7702 tuple per UserOp, and only the sender can be a 7702 authorized account. Also, remember that 7702 accounts shouldn’t take on roles as paymasters or factories.
  • Watch out for “role drift” -- if a sender changes their delegation between validation and inclusion, it’s best to drop and reputationally throttle according to 7562. (eips.ethereum.org)

3) Security defaults you should not skip

• 7702 phishing is a serious concern. Phishing teams are actively targeting folks, using 7702 batch signatures to drain wallets. It's pretty alarming--by 2025, we were looking at losses in the millions! To keep yourself safe, check out these tips:
  • Use visual code-hash attestations;
  • Set up session-scoped authorizations with short expiry times, and make sure they auto-revoke after operations;
  • Create policy engines to block ERC-20 unlimited approvals or NFT approvals in the same batch as value transfers, unless you're sure it’s from a trusted source. (cointelegraph.com)
• ERC-6492 is a total game changer for pre-deploy signatures. If you’re gathering signatures before your app goes live, it’s crucial to back ERC-6492. This means dapps can verify accounts that haven't been deployed yet, which helps sidestep those frustrating first-use failures and keeps signature replay issues at bay. (alchemy.com)
• Always use audited module registries when exploring modular accounts (7579/6900). This involves implementing ERC-7484-style registry checks, allowing wallets to turn away any unknown or unverified modules during the installation process. Check it out here: (erc7579.com)
• Keep observability in mind. It’s super important to keep an eye on simulateValidation failure classes, inclusion latency, bundle size distributions, and track down who’s really including each UserOp (origin vs. includer) to spot any potential censorship issues. (docs.erc4337.io)

---

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

Short answer: dive into ERC‑4337 right away; layer 7702 where it enhances the user experience; and don’t forget to watch for native AA proposals.

• Right now, ERC‑4337 is the top choice for account abstraction. It offers some really useful features, like paymasters, batching, session keys, and modular accounts--all available on the mainnet and big L2s, so you don't have to stress about protocol risk. The whole ecosystem is growing rapidly, with shared mempools, conformance rules, and standard RPCs getting into the mix. If you want to dive deeper, you can check it out here.
• EIP‑7702 is already live and operates smoothly alongside ERC‑4337; you can think of it as a solid upgrade path for EOAs that meshes well with the 4337 setup. If you're curious to learn more, check out ethereum.org.
• Regarding Native AA (RIP‑7560 and EIP‑7701), it’s still a work in progress, with a focus on L2-first experiments. The aim is to cut down on gas fees and bring AA into the main mempool. Just a heads-up, though: they’re not standards on the mainnet yet. Keep yourself in the loop, but don’t let this hold up your product plans. You can find more details here.

---

2026‑ready best practices (checklist)

• Versioning and Addresses
  • Let’s keep our accounts and bundlers organized by tagging them based on the EntryPoint version. It’s super important to have those address registries up to date for each chain, and don’t forget about running those code-hash checks!
  • We’re getting ready to retire v0.6 and will be shifting all new deployments to v0.8 and above. We should also take a closer look at v0.9, especially for features like the parallel paymasterSignature and the validity windows for block numbers. You can read more about it here.
• Mempool Hygiene
  • It’s important that we stick to ERC‑7562 guidelines. We should engage with the shared mempool and watch out for peer reputation. If we spot any operations that aren’t up to par, let’s go ahead and drop them early. (eips.ethereum.org)
• Paymaster Ergonomics
  • Let’s get those ERC‑7677 web methods up and running! We should really go ahead and pre-fill those stub gas values, plus dive into parallel sign on v0.9. Implementing policy-based whitelists will definitely help us keep our spending in check too. Check out the details here: (eips.ethereum.org)
• Wallet UX
  • It's essential that we implement a clear review process for 7702 authorizations. This should include details such as the delegate name, code hash, and links to audits. To make it a breeze for users, we should add a simple one-tap revoke feature and keep default sessions short-lived. Check out more about this on (eips.ethereum.org).
• Modular Accounts
  • Let's focus on using ERC‑7579 modules for basic interoperability. If we want more complex permission structures, we can bring in ERC‑6900. We'll need to set this up with a module registry. (eips.ethereum.org)
• Observability
  • Keeping an eye on the differences between simulated and real gas costs, inclusion latency, the make-up of bundles, and who’s including your UserOps is key. Let’s not forget to set up alerts for any sudden spikes in rejected operations and keep tabs on any gossip drop-offs. You can check out more details here.

---

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

• Get ready for faster confirmations with parallel paymaster signing! Now, UserOps can be signed simultaneously by both the account and the paymaster since the paymasterSignature isn’t included in the userOpHash (just like the account signature). This change is going to significantly cut down on the “click-to-confirmation” time for sponsored flows. You can read more about it here: (docs.erc4337.io).
• Wave goodbye to those pesky race conditions thanks to the “ignored initCode” feature! In the past, if you had parallel “first-use” UserOps going on, it could cause cross-invalidations, which was a real headache. But now, if the account already exists, the initCode is simply ignored instead of causing a revert. This change really boosts the safety of multi-lane nonces. Just remember to take a look at any logic that assumed “initCode means it’s the first op ever.” For more details, check this out: (github.com).
• Improve your timeboxing with block-number validity! You can now establish boundaries for UserOps by using block numbers (just set the high bit). This is a game changer for protocols that rely on block timing rather than timestamps. It’s especially useful for actions that need to be sequenced or for dealing with MEV-sensitive flows. Check out more details here: (github.com).

---

Looking ahead

• Get excited about some sleek new wallet UX patterns that are 7702-aware--think of them like firmware upgrades and on-device attestations. Just a quick note: phishing attempts targeting 7702 signatures are still out there, so having strong defenses in place will really set you ahead. (cointelegraph.com)
• The native AA proposals (RIP‑7560/EIP‑7701) are likely to kick things off on Layer 2s before they influence the design of future mainnets. So, when native AA finally rolls around, your investments in 4337 will still have a place. Paymasters, session keys, and modular accounts are here to stay--they’ll just have a new approach to getting there. (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 (alchemy.com)

Standards to Keep an Eye On:

• ERC‑4337 core docs
• ERC‑7562 validation rules
• ERC‑7677 paymaster web service
• ERC‑7769 bundler JSON‑RPC
• EIP‑7702
• Pectra status.

For more info, check it out here.

---

Ready to make your bets for 2026? Here’s the scoop: jump in with ERC‑4337 (v0.8/0.9), bring in 7702 for a seamless EOA onboarding ride, stick with those 7579 modules for consistency, and don’t forget to enforce 7562/7677/7769. You’ll enjoy an awesome user experience today while setting the stage for the native AA of tomorrow.