--- title: "Account Abstraction in Production" canonical: https://wavect.io/blog/account-abstraction-erc4337-production/ language: en description: "What ERC-4337 account abstraction fixes in production, what it does not, and the new attack surfaces. Gasless UX, batched transactions, social recovery." image: "https://wavect.io/img/blog/headers/header_account-abstraction-erc4337-production.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 26 May 2026 [**Next**](/blog/smart-contract-security-checklist-pre-audit/) # Account Abstraction (ERC-4337) in Production: What It Actually Fixes, What It Doesn't TL;DR ERC-4337 account abstraction is UX progress, not security progress. It fixes gasless onboarding via paymasters, batched transactions, social recovery, and session keys, while introducing new attack surfaces in bundlers, paymasters, and wallet contracts. Wavect has shipped AA wallets in production, and most products do not need a custom wallet contract; audited implementations like Safe or Kernel cover roughly 90% of real-world needs. ERC-4337 has been live long enough to stop being a thought experiment. We have shipped [account abstraction](/glossary/account-abstraction/) [wallets](/glossary/crypto-wallet/) in production for clients (see [our AA case study](/case-studies/account-abstraction/) and [MetaMask Snap work](/case-studies/metamask-snap/)). The honest summary: AA is UX progress, not security progress. It removes a long list of papercuts users complain about, and it introduces a shorter list of new attack surfaces engineers complain about. This post is the teardown: what it fixes, what it does not fix, and the Q&A we hear from clients before they commit. ## What is ERC-4337 in one paragraph? A standard that lets a smart contract act as a user's account, without changing the underlying [EVM](/glossary/evm/) protocol. The user signs a UserOperation, a bundler packages it, a paymaster optionally pays the gas, and an entry-point contract validates and executes it. The end result: the user does not need ETH to transact, can use a passkey or social recovery instead of a seed phrase, and can batch multiple actions into a single approval. ERC-4337 is the standard; specific wallet implementations (Safe, Kernel, Biconomy, Alchemy's Light Account, ZeroDev) layer features on top. ## What does AA actually fix in production? - **Gasless UX via paymaster.** The user does not hold ETH. Someone else (you, a sponsor contract, a token-in-token swap) pays gas. This single change closes the biggest onboarding gap in EVM products. - **Batched transactions.** Approve plus swap in one signature. Approve plus deposit plus stake in one signature. Fewer prompts, fewer abandoned flows. - **Social recovery.** Guardians can rotate the signing key without moving the funds. Users stop losing wallets to lost seed phrases. - **Session keys.** Time-bounded, scope-bounded signing rights. The user signs once; the dapp can act within the limits without further prompts. Huge for games and high-frequency products. - **Role-based spending policies.** "Trade up to $500 per day on this DEX, anything else needs a guardian signature." Real policy engines in the wallet, not in the app. - **Passkeys and WebAuthn.** Sign with a fingerprint or device passkey instead of a seed phrase. Massive UX win for non-crypto-native users. ## What does AA not fix? - **Bundler centralisation.** Most production traffic runs through a handful of bundler operators. Censorship and uptime risk concentrate there. - **Paymaster economics.** Someone pays gas eventually. If that is you, you need a budget, a quota, and a sybil-protection strategy. - **Social-engineering recovery attacks.** If your recovery flow trusts an email or phone number, that is your new weakest link. Recovery sounds safe; it is only as safe as the guardians you choose. - **Multi-chain wallet UX.** Each chain has its own AA deployment, its own bundler, its own paymaster. The user-facing wallet hides this; the engineering team feels it. - **Dapp signing UX confusion.** EIP-712 typed data is still confusing for most users. AA does not change what the user is asked to sign. - **The fundamental "what does this transaction do" problem.** A batched UserOperation is harder to display safely than a single transfer. UX work is still required. ## What new attack surfaces does AA introduce? Not "smaller". Just "different". Worth listing because we see them on engagements that skipped a serious threat model. 1. **Paymaster spoofing.** If your paymaster validation logic is sloppy, an attacker can drain the paymaster budget by triggering sponsored ops that should not have qualified. 2. **Signature aggregator quirks.** Aggregated signature schemes have subtle malleability and replay considerations. They need their own audit. 3. **Init-code phishing.** A wallet's first deployment includes init code. A malicious dapp can suggest init code that backdoors the wallet from day one. 4. **UserOperation simulation drift.** The state seen during bundler simulation may not match execution state. Mishandled, this becomes a griefing vector. 5. **Session key over-scoping.** Easy to grant, easy to forget. We have seen dapps request session keys with broader scope than they actually need. 6. **Guardian collusion.** Social recovery transfers trust from the seed phrase to the guardian set. Choose accordingly. ## Quick comparison: EOA vs AA | Concern | EOA (today) | AA (ERC-4337) | | --- | --- | --- | | Seed phrase required | Yes | No (passkey, social, or hybrid) | | User holds gas token | Yes | Optional (paymaster covers) | | Batch in one signature | No | Yes | | Recovery from key loss | No (game over) | Yes (guardians or hybrid) | | Per-transaction cost | Lower | Higher (entry-point overhead) | | Audit surface | Small | Larger (wallet contract + paymaster) | | Censorship risk | Validator-level | Validator + bundler-level | ![Kevin Riedl](/img/team/kevin.webp) "AA is UX progress, not security progress. Treat it that way and you will scope it correctly." ## Q&A: do we still need EOAs? Yes, for now. EOAs are still simpler, cheaper per transaction, and have a much smaller audit surface. For high-frequency, low-stakes transactions from technical users, EOAs are fine. For consumer onboarding, AA is the right default. We frequently ship hybrid products: AA for the consumer flow, EOA for power-user or operator flows. ## Q&A: is AA cheaper or just nicer? Per-transaction, AA costs more gas than an EOA, because the entry-point and wallet contract do extra validation work. The user experience is cheaper (fewer signature prompts, no need to pre-buy ETH). The fee economics flip only when you batch enough operations into one UserOperation that the per-op cost drops below the EOA equivalent. Batching is where the gas math wins. ## Q&A: can we run our own bundler? Yes. Several open-source bundlers exist (Pimlico's Alto, Stackup, ETH Infinitism reference). Running your own bundler gives you censorship resistance and predictable performance. It also gives you a 24/7 ops burden, a node infrastructure bill, and a target for DDoS. For most products, using a hosted bundler is the pragmatic answer. For products where censorship resistance is a core promise, self-hosting is worth the work. ## Q&A: what about EIP-7702? EIP-7702 (live since Pectra) gives EOAs the ability to temporarily behave like smart accounts. It changes the calculus: for many products that wanted AA mainly for batching and sponsored gas, EIP-7702 delivers most of the UX upside without a new wallet contract. ERC-4337 is still the right answer for full social recovery, session keys, and policy-rich wallets. We help clients decide between the two based on the product, not the trend. ## Q&A: how does AA interact with [smart contracts](/glossary/smart-contract/) on other chains? Each chain needs its own AA deployment. The entry-point address, bundler, and paymaster contracts are per-chain. Users see one wallet; engineering sees N deployments. Tools like cross-chain wallet abstractions are catching up but are still rough. Plan for it. ## Q&A: do we need a custom wallet contract? Usually no. Safe, Kernel, Light Account, and similar implementations are well-audited and cover 90% of real-world product needs. Custom wallet contracts are appropriate when you have a specific policy engine, signature scheme, or recovery model that the existing implementations do not support. Custom is more expensive and carries a heavier audit burden. See our [blockchain engineering service](/services/blockchain/) for how we scope this. When a concrete operation fails between the wallet, bundler, paymaster, and EntryPoint, paste the exact artifact into our free [ERC-4337 UserOperation debugger](/tools/erc-4337-useroperation-debugger/). It separates packed fields and AAxx errors locally without sending another RPC request. ## Final thoughts ERC-4337 in production is a tool, not a religion. It fixes a real, measurable list of UX problems: gas, batching, recovery, session keys, passkeys. It does not fix bundler centralisation, paymaster economics, or the human problem of trusting the right guardians. It introduces a new audit surface that needs treated with the same seriousness as any other smart contract work. The pragmatic position in 2026 is this: default to AA for consumer-facing products where onboarding friction is the moat, default to EOA for technical users and operators, and reach for EIP-7702 when you only need part of the AA toolkit. Whatever you pick, model the threats, audit the wallet contract and paymaster together, and plan for the ops cost of bundlers. UX progress is real progress; just do not confuse it for a free lunch. The teams that ship AA well treat it as a product decision with engineering teeth. The teams that ship it badly treat it as a marketing checkbox. ## You may also like.. [**Ethereum gas prices** Why gas fees matter for product economics and how we design around them.](/blog/ethereum-gas-prices/) [**Wavect vs a generalist dev agency** Generalists sell capacity; we sell product judgment plus the engineering to ship it.](/compare/wavect-vs-dev-agencies/) Blockchain infrastructure ## Continue through this cluster Networks, smart contracts, payments and production architecture for Web3 systems. [Start with the cornerstone**Ethereum to Solana Migration Cost**](/blog/ethereum-to-solana-migration-cost/) - [Native Rollups vs Based Rollups](/blog/native-rollups-vs-based-rollups/) - [Tokenomics Implementation in 2026: From Model to Production](/blog/tokenomics-implementation-infrastructure-2026/) - [Top 10 Web3 and Smart Contract Auditors in Germany (2026)](/blog/top-smart-contract-auditors-germany/) - [x402 Payments in 2026: Coinbase, Stripe & Alternatives](/blog/x402-payments-comparison-2026/) - [Open USD Explained: What a Consortium Stablecoin Changes](/blog/open-usd-stablecoin-explained-2026/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 26 May 2026 [**Next**](/blog/smart-contract-security-checklist-pre-audit/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/account-abstraction-erc4337-production/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/account-abstraction-erc4337-production/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "ERC-4337 account abstraction is UX progress, not security progress. It fixes gasless onboarding via paymasters, batched transactions, social recovery, and session keys, while introducing new attack surfaces in bundlers, paymasters, and wallet contracts. Wavect has shipped AA wallets in production, and most products do not need a custom wallet contract; audited implementations like Safe or Kernel cover roughly 90% of real-world needs.", "articleBody": " Blog overview/Web3 and privacy/Blockchain infrastructure Account Abstraction (ERC-4337) in Production: What It Actually Fixes, What It Doesn't TL;DR ERC-4337 account abstraction is UX progress, not security progress. It fixes gasless onboarding via paymasters, batched transactions, social recovery, and session keys, while introducing new attack surfaces in bundlers, paymasters, and wallet contracts. Wavect has shipped AA wallets in production, and most products do not need a custom wallet contract; audited implementations like Safe or Kernel cover roughly 90% of real-world needs. ERC-4337 has been live long enough to stop being a thought experiment. We have shipped account abstraction wallets in production for clients (see our AA case study and MetaMask Snap work). The honest summary: AA is UX progress, not security progress. It removes a long list of papercuts users complain about, and it introduces a shorter list of new attack surfaces engineers complain about. This post is the teardown: what it fixes, what it does not fix, and the Q&A we hear from clients before they commit. What is ERC-4337 in one paragraph? A standard that lets a smart contract act as a user's account, without changing the underlying EVM protocol. The user signs a UserOperation, a bundler packages it, a paymaster optionally pays the gas, and an entry-point contract validates and executes it. The end result: the user does not need ETH to transact, can use a passkey or social recovery instead of a seed phrase, and can batch multiple actions into a single approval. ERC-4337 is the standard; specific wallet implementations (Safe, Kernel, Biconomy, Alchemy's Light Account, ZeroDev) layer features on top. What does AA actually fix in production? Gasless UX via paymaster. The user does not hold ETH. Someone else (you, a sponsor contract, a token-in-token swap) pays gas. This single change closes the biggest onboarding gap in EVM products. Batched transactions. Approve plus swap in one signature. Approve plus deposit plus stake in one signature. Fewer prompts, fewer abandoned flows. Social recovery. Guardians can rotate the signing key without moving the funds. Users stop losing wallets to lost seed phrases. Session keys. Time-bounded, scope-bounded signing rights. The user signs once; the dapp can act within the limits without further prompts. Huge for games and high-frequency products. Role-based spending policies. \"Trade up to $500 per day on this DEX, anything else needs a guardian signature.\" Real policy engines in the wallet, not in the app. Passkeys and WebAuthn. Sign with a fingerprint or device passkey instead of a seed phrase. Massive UX win for non-crypto-native users. What does AA not fix? Bundler centralisation. Most production traffic runs through a handful of bundler operators. Censorship and uptime risk concentrate there. Paymaster economics. Someone pays gas eventually. If that is you, you need a budget, a quota, and a sybil-protection strategy. Social-engineering recovery attacks. If your recovery flow trusts an email or phone number, that is your new weakest link. Recovery sounds safe; it is only as safe as the guardians you choose. Multi-chain wallet UX. Each chain has its own AA deployment, its own bundler, its own paymaster. The user-facing wallet hides this; the engineering team feels it. Dapp signing UX confusion. EIP-712 typed data is still confusing for most users. AA does not change what the user is asked to sign. The fundamental \"what does this transaction do\" problem. A batched UserOperation is harder to display safely than a single transfer. UX work is still required. What new attack surfaces does AA introduce? Not \"smaller\". Just \"different\". Worth listing because we see them on engagements that skipped a serious threat model. Paymaster spoofing. If your paymaster validation logic is sloppy, an attacker can drain the paymaster budget by triggering sponsored ops that should not have qualified. Signature aggregator quirks. Aggregated signature schemes have subtle malleability and replay considerations. They need their own audit. Init-code phishing. A wallet's first deployment includes init code. A malicious dapp can suggest init code that backdoors the wallet from day one. UserOperation simulation drift. The state seen during bundler simulation may not match execution state. Mishandled, this becomes a griefing vector. Session key over-scoping. Easy to grant, easy to forget. We have seen dapps request session keys with broader scope than they actually need. Guardian collusion. Social recovery transfers trust from the seed phrase to the guardian set. Choose accordingly. Quick comparison: EOA vs AA Concern EOA (today) AA (ERC-4337) Seed phrase requiredYesNo (passkey, social, or hybrid) User holds gas tokenYesOptional (paymaster covers) Batch in one signatureNoYes Recovery from key lossNo (game over)Yes (guardians or hybrid) Per-transaction costLowerHigher (entry-point overhead) Audit surfaceSmallLarger (wallet", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-05-26", "description": "ERC-4337 account abstraction is UX progress, not security progress. It fixes gasless onboarding via paymasters, batched transactions, social recovery, and session keys, while introducing new attack surfaces in bundlers, paymasters, and wallet contracts. Wavect has shipped AA wallets in production, and most products do not need a custom wallet contract; audited implementations like Safe or Kernel cover roughly 90% of real-world needs.", "headline": "Account Abstraction in Production", "image": "https://wavect.io/img/blog/headers/header_account-abstraction-erc4337-production.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/account-abstraction-erc4337-production/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/account-abstraction-erc4337-production/", "wordCount": 1615 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/web3-privacy/", "name": "Web3 and privacy", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/blockchain-infrastructure/", "name": "Blockchain infrastructure", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/account-abstraction-erc4337-production/", "name": "Account Abstraction in Production | ", "position": 5 } ] } ```