# ERC-4337: Account Abstraction Using Alt Mempool Source: https://www.eipsfordesigners.com/standards/ERC-4337 Agent brief: https://www.eipsfordesigners.com/standards/ERC-4337/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-4337 Last reviewed: 2026-04-05 Last updated: 2026-04-05 | Field | Value | | --- | --- | | Status | Last Call | | Chain | both | | Category | Transaction Friction | | Journey stages | Executing Transactions, Gas & Fees | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/eip-4337 | | Discussion search | https://ethereum-magicians.org/search?q=ERC-4337 | ## UX Impact Users interact with smart accounts instead of EOAs. No seed phrases required, social recovery possible, gas payable in any token. Design implications: design onboarding without 'write down 12 words', show gas payment token selector, build recovery flows (guardian management UI), display bundled operations as single actions. Design decisions: tradeoff between custodial simplicity and self-custody complexity, must handle paymaster failures gracefully, decide whether to abstract UserOperations completely or expose for power users. 54M+ smart accounts, 1B+ UserOps. Smart wallets retain 70% of users vs 60% for seed-phrase wallets . Primary solution to Gas Hurdle (Critical), Key Management Burden (High), and Forced Backup Friction (Medium). Widely deployed (Safe, Biconomy, ZeroDev). ## Summary ERC-4337 is the infrastructure that makes "Account Abstraction" work. It creates a parallel system where smart contract wallets can exist with full programmability: custom validation (passkeys, multisig), gas sponsorship via paymasters, bundled operations, and account recovery. It's the backend that powers the best wallet UX patterns. ## For Designers - Checkouts can let users pay gas in USDC or have it sponsored, so "buy ETH first" disappears from the flow. - Account recovery can look like a password reset: guardians, an M-of-N threshold, and a cancel-able timer. - Multi-step flows (approve, swap, stake) can collapse into a single atomic confirmation instead of stacked modals. ## Applicability ### When to Use - New users need to act before they own ETH for gas. - The product benefits from one confirmation for approve, swap, mint, stake, or claim flows. - The account needs recovery, spending limits, passkeys, guardians, or multisig rules. - The team can support smart account infrastructure and clear fallback states. ### When to Avoid - The product cannot support bundler and paymaster failure paths. - The user must keep using a plain EOA with no smart account layer. - The flow is a single low-risk transaction where sponsorship, batching, or recovery adds no user value. - The team cannot explain who controls recovery or who pays fees. ## Problems It Solves ### Users must hold ETH to do anything on-chain Impact: critical Old way: Buy ETH → transfer → wait → then interact New way: Paymaster sponsors gas, user pays in USDC or nothing at all ### Losing seed phrase = losing everything Impact: critical Old way: 12 words is only backup, lose it and funds are gone forever New way: Social recovery, guardian signatures, account restoration possible ### Only ECDSA signatures work for authentication Impact: high Old way: Must sign with private key derived from seed phrase New way: Custom validation: passkeys, multisig, MPC, anything ### Each operation requires separate transaction Impact: high Old way: Approve, wait, swap, wait, stake, wait... New way: UserOps bundle multiple calls, execute atomically ### Smart wallets couldn't initiate transactions Impact: high Old way: Needed an EOA to trigger contract wallet actions New way: Bundlers submit UserOps, wallets work independently ## Anti-Patterns ### No fallback when paymaster rejects Severity: critical User stuck if sponsor runs out or rejects Instead: Graceful fallback to ETH with clear explanation ### Recovery with no time delay Severity: critical Compromised guardian could instantly steal account Instead: Mandatory time lock (24-72h) to allow legitimate owner to cancel ### Single guardian recovery Severity: critical One compromised contact = lost account Instead: Require M-of-N threshold (e.g., 2 of 3 guardians) ### Exposing "UserOperation" terminology to users Severity: high Technical jargon confuses users, they just want to "send" or "swap" Instead: Use familiar terms: transaction, transfer, swap ### Not simulating UserOps before submission Severity: high Failed UserOps waste user time and sometimes gas Instead: Always simulate and show clear error if it would fail ### Hiding gas costs in sponsored transactions Severity: medium Users shocked when sponsorship ends and they pay Instead: Show "Sponsored ($0.35 value)" so users understand ## Design Decisions ### Who pays gas in this flow? Recommendation: Show one fee model at a time: sponsored, paid in native token, or paid in another token. Rationale: Users need to know whether the app is covering the cost, whether their token balance will change, and what happens when sponsorship ends. ### How does the user recover the account? Recommendation: Design guardian setup, threshold progress, a security delay, and a cancel path as first-class states. Rationale: Recovery is not a settings footnote. It is the replacement for "save these 12 words", so the user must understand it before they need it. ### How much protocol detail appears in the confirmation? Recommendation: Summarize the human action first, then expose technical details behind review or advanced disclosure. Rationale: The protocol has many actors, but the user is approving an outcome. Showing plumbing first creates doubt instead of informed consent. ### What happens if the operation cannot be included? Recommendation: Preflight with simulation, then give a specific recovery action: change fee token, remove a step, retry later, or pay gas yourself. Rationale: ERC-4337 adds new failure points. Generic "transaction failed" copy hides the fix and makes the smart account feel unreliable. ### Does the account need to be deployed now? Recommendation: Treat deployment as setup work unless the cost or timing changes the user decision. Rationale: Counterfactual accounts let users begin before deployment, but first execution may still create the account and affect gas or status timing. ## States to Design ### Account not deployed Trigger: The user is using a counterfactual smart account for the first time. User need: Know whether setup is automatic, costs money, or changes timing. Design response: Keep it in setup or transaction details unless deployment affects cost, time, or risk. ### Paymaster quote unavailable Trigger: The sponsor cannot quote gas or the selected fee token is unsupported. User need: A path forward that does not feel like a broken checkout. Design response: Offer another fee token, user-paid gas, or a retry with plain-language reason copy. ### Simulation failed Trigger: The operation would fail during validation or execution. User need: Understand what to fix before signing. Design response: Block signing, name the failed step, and give a concrete action such as reduce amount or remove step. ### Bundler pending Trigger: The user signed, but the operation is waiting for inclusion. User need: Confidence that the action left their device and is still progressing. Design response: Show sent, processing, included, and confirmed as one status strip with an expandable technical ID. ### Guardian invite pending Trigger: A recovery contact has not accepted or confirmed. User need: Know whether the account is protected yet. Design response: Show inactive recovery until the threshold can be reached, not just a generic pending badge. ### Security delay active Trigger: Recovery has enough guardian approvals and is waiting out the delay. User need: Know when recovery completes and how to stop it if it is suspicious. Design response: Show countdown, approving guardians, destination account, and a prominent cancel action. ## Vocabulary - Use "Transaction" instead of "UserOperation, UserOp": UserOp is internal protocol jargon. From the user's seat, they are sending a transaction. What happens under the hood is not their concern. - Use "Smart wallet, Smart account" instead of "4337 wallet, ERC-4337 account": Spec IDs do not belong in user UI. "Smart wallet" tells the user it can do more than a normal wallet without naming the protocol. - Use "Sponsored, Free for you" instead of "Gasless, Free gas": "Gasless" is ambiguous: does it mean truly free, or paid in another token? "Sponsored" is honest about someone else paying. - Use "Pay gas with USDC" instead of "Use ERC-20 paymaster, Token paymaster": Paymaster is the backend role. The user just sees which token they are paying with. - Use "Guardian" instead of "Trustee, Recovery key, Co-signer": Argent introduced "guardian" and the ecosystem standardized on it. Trustee sounds legal, co-signer sounds like a loan, recovery key sounds like a thing you can lose. - Use "Security delay" instead of "Time lock, Timelock": "Time lock" is engineer language. "Security delay" tells the user what the delay is for and why they should not be annoyed by it. - Use "Add a backup, Set up account recovery" instead of "Configure social recovery, Set up your recovery module": Backup is the mental model people bring from photos and passwords. "Module" is implementation language. - Use "Sent, Submitting" instead of "Submitted to bundler, Included in mempool": Bundler and mempool are plumbing. The user cares that the action left their device and is on its way. - Use "Cancel recovery" instead of "Veto, Abort": "Veto" sounds adversarial. "Abort" sounds like a system error. The owner pressing cancel on their own recovery is a normal, calm action. ## What to Prototype First ### Fee selection This is where ERC-4337 removes the "buy ETH first" dead end, but only if the fee model is clear. Covers: Gas sponsorship, Pay gas with another token, Paymaster unavailable - Sponsored label with value - Fee token options - Fallback to user-paid gas ### Bundled confirmation One signature can contain multiple consequences. The user still needs to understand the full action. Covers: Approve plus action, Atomic execution, Simulation failure - Ordered step preview - All-or-nothing copy - Blocked signing when simulation fails ### Recovery setup Recovery replaces the seed phrase backup moment, so it needs to feel like account safety, not advanced settings. Covers: Guardian invites, M-of-N threshold, Recovery inactive state - Guardian status rows - Threshold copy - Clear "not protected yet" state ### Recovery in progress A recovery flow is both help and risk. The owner must see what is happening and how to stop it. Covers: Guardian approvals, Security delay, Cancel recovery - Countdown - Approving guardians - New owner destination - Prominent cancel action ### Operation status ERC-4337 adds steps between signing and confirmation. Status copy should make progress feel legible. Covers: Signed, Bundler pending, Included, Confirmed - Single status strip - Plain-language states - Expandable user operation hash ## Mental Model ### User intent The product still asks the user to send, swap, mint, or recover. "UserOperation" is only the package the app builds behind the interface. ### Smart account The account is contract code, so validation can be passkeys, guardians, multisig, session keys, or another rule the wallet supports. ### Bundler A bundler collects valid operations and submits them on-chain. Your status UI should track submission, inclusion, and confirmation as one journey. ### EntryPoint The EntryPoint checks account and paymaster rules before execution. Failed simulation belongs in the product UI before the user signs. ### Paymaster A paymaster can sponsor gas or charge another token. Designers need a clear fallback when sponsorship is unavailable. ## Seen in the Wild - Coinbase Smart Wallet: Passkey signup, no seed phrase shown. App-level gas sponsorship for first-time interactions. (https://www.coinbase.com/wallet/smart-wallet) - Safe (Smart Account): Original smart contract wallet. Multisig, modules, and 4337-compatible bundled transactions. (https://safe.global/) - Privy: Embedded wallets that sign in with email or social, then route transactions through a bundler so users never see ETH. (https://privy.io/) - Argent: Pioneered guardian-based social recovery and the cancel-able time lock UX patterns most wallets now copy. (https://www.argent.xyz/) - ZeroDev: SDK for building bundled multi-step actions (approve + swap + stake) behind a single signature. (https://zerodev.app/) ## UI Components ### Gas token picker Choose which token to pay gas with, or use a sponsor Kind: selector States: loading, ready, no sponsors, selected Props: availableTokens[], gasEstimates, selectedToken, onSelect ### Guardian list Add, remove, and see the status of recovery guardians Kind: list States: empty, configuring, active, recovering Props: guardians[], threshold, onAdd, onRemove ### Transaction preview Show what a single bundled transaction will do, step by step Kind: preview States: building, ready, simulating, error Props: calls[], gasEstimate, paymasterInfo ### Recovery progress Track guardian approvals, the time lock, and final completion Kind: progress States: initiating, gathering approvals, time-locked, complete Props: approvals, threshold, timelockRemaining ### Submission status Show submission, inclusion, and confirmation as one strip Kind: status States: submitting, pending, included, confirmed, failed Props: userOpHash, txHash, error ## On Monad ### Bundler Economics Ethereum: Bundlers need to account for MEV, price fluctuations Monad: Fast finality reduces bundler risk, potentially lower fees Design implication: Gas sponsorship more economically viable on Monad ### UserOp Confirmation Ethereum: UserOp → mempool → block (12+ seconds) Monad: Sub-second finality for bundled operations Design implication: Can show confirmation instantly, no long pending states ### Reserve Balance Ethereum: Smart wallet can be drained to zero Monad: 10 MON reserve required; delegated accounts cannot use emptying exception Design implication: Show "spendable" balance that accounts for reserve ### Recovery Time Lock Ethereum: 48h delay feels long but necessary Monad: Could potentially reduce with faster block times Design implication: May offer shorter recovery periods ## Key Takeaways - ERC-4337 is the infrastructure, not the UX. Hide the complexity. - Gas abstraction: let users pay in any token or have sponsor - Social recovery needs threshold (M-of-N) AND time delay - Always simulate UserOps before asking user to sign - Never show "UserOperation" or "bundler" to users ## UX Patterns ### Gas Abstraction User sees final cost in their preferred token or zero Components: Gas token picker, Estimated cost, Order total User flow: - User initiates purchase - App fetches gas quotes from paymaster - User selects payment token - UserOp created with paymaster data - User signs once - Paymaster handles conversion Mockup registry key: `gas-abstraction` (React UI on the live standard page). ### Social Recovery Setup Configure guardians who can help recover account Components: Guardian list, Guardian status row, Threshold control, Time-lock notice User flow: - User opens recovery settings - Adds guardian addresses or emails - Sets threshold (2 of 3) - Guardians confirm participation - Recovery becomes active Mockup registry key: `social-recovery-setup` (React UI on the live standard page). ### Account Recovery Flow Guardian-assisted account restoration Components: Approval progress, Time-lock countdown, Recovery status User flow: - User initiates recovery from new device - Contacts guardians for approval - Guardians sign recovery request - Threshold reached - Time lock countdown begins - Recovery completes after delay Mockup registry key: `account-recovery` (React UI on the live standard page). ### Bundled DeFi Operations Complex multi-step DeFi in one interaction Components: Step list, Savings summary, Execute-all button User flow: - User selects strategy/actions - App builds UserOp with all calls - Shows preview with savings - User signs once - All steps execute atomically Mockup registry key: `bundled-defi` (React UI on the live standard page). ## Technical Notes ERC-4337 uses a singleton EntryPoint contract that verifies and executes UserOperations. Smart wallets implement IAccount interface with validateUserOp(). Paymasters implement IPaymaster to sponsor gas. Bundlers are off-chain relayers that submit UserOps to EntryPoint. The system is permissionless: anyone can run a bundler.