{"id":"ERC-4337","slug":"account-abstraction","name":"Account Abstraction Using Alt Mempool","status":"Final","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"ERC-4337 supports smart-account flows that can offer sponsored fees, batched actions, or account recovery when the chosen implementation supports them. Show which options are available, who pays, and what happens if an operation fails. These features are not guaranteed by ERC-4337 alone.","lastUpdated":"2026-09-18","officialUrl":"https://ercs.ethereum.org/ERCS/erc-4337","discussionUrl":"https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160","lastReviewed":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-4337","summary":"ERC-4337 supports smart-account flows that can offer sponsored fees, batched actions, or account recovery when the chosen implementation supports them. Show which options are available, who pays, and what happens if an operation fails. These features are not guaranteed by ERC-4337 alone.","designerTakeaways":["ERC-4337 supports compatible EIP-7702-delegated senders as well as deployed contract accounts. Check the network and infrastructure path rather than presenting the two standards as alternatives.","Show a non-native fee token or sponsorship option only when the selected account, paymaster, bundler, and network support it.","Treat passkeys, guardians, thresholds, recovery delays, and cancellation as account and product behavior that must be explained explicitly.","Collapse steps into one confirmation only when the selected account implementation supports batching; show its subcall failure semantics and result."],"applicability":{"whenToUse":["The selected account and paymaster can support the fee or sponsorship model the product wants to offer.","The product benefits from one confirmation for approve, swap, mint, stake, or claim flows and the account supports the required batching.","The selected account implementation provides the recovery, spending-limit, authenticator, or multisig rules the product will expose.","The team can support smart-account infrastructure and clear bundler, paymaster, and account fallback states."],"whenToAvoid":["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."]},"specConstraints":[{"id":"unused-gas-penalty","constraint":"Unused execution and paymaster post-operation gas can incur a 10% penalty at the specified 40,000-gas threshold.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A penalty of 10% (UNUSED_GAS_PENALTY_PERCENT) is applied on the amounts of callGasLimit and paymasterPostOpGasLimit gas that remains unused. This penalty is only applied if the amount of the remaining unused gas is greater than or equal 40000 (PENALTY_GAS_THRESHOLD).","specSection":"Specification / Required EntryPoint contract functionality / Execution loop","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#required-entrypoint-contract-functionality","designImplication":"Use estimates for the deployed EntryPoint version and actual operation. Do not promise that all unused gas is refunded: the current specification applies this penalty to the stated limits, not every gas field or the entire transaction fee. Explain the charge to the actual fee payer, including any paymaster pricing passed on to the user."},{"id":"bundler-validation-rejection","constraint":"Bundlers must reject UserOperations that fail validation before admitting or propagating them.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A node/bundler MUST reject a UserOperation that fails the validation, meaning not adding it to the local mempool and not propagating it to other peers.","specSection":"Specification / Required EntryPoint contract functionality","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#required-entrypoint-contract-functionality","designImplication":"Do not label a signed operation as accepted or pending until the bundler accepts it. Keep validation rejection separate from an included execution failure and display the reported recovery action."},{"id":"paymaster-acceptance","constraint":"Sponsorship depends on both the paymaster's deposit and its acceptance of this operation.","appliesTo":"infrastructure","normativity":"normative","specQuote":"During the verification loop, in addition to calling validateUserOp, the handleOps execution also must check that the paymaster has enough ETH deposited with the EntryPoint to pay for the UserOperation, and then call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation.","specSection":"Specification / Extension: paymasters","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#extension-paymasters","designImplication":"Confirm sponsorship for the actual operation before labeling its fee covered. A funded deposit does not prove the sponsor accepts the action, and locked stake is not the deposit used to pay gas. Keep funding, policy rejection, and bundler reputation errors distinct."},{"id":"validation-not-execution","constraint":"Bundler validation simulation does not guarantee successful execution.","appliesTo":"application","normativity":"normative","specQuote":"Simulation should run only on the validation section of the sender and paymaster, and is not required for the UserOperation's execution.","specSection":"Specification / UserOperation Simulation / Simulation Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#simulation-specification","designImplication":"Label validation acceptance separately from execution simulation and the final receipt. Explain the scope of a preview; never turn a successful bundler check into a guaranteed-success badge."},{"id":"operation-validity-window","constraint":"Bundlers must drop operations that expire too soon to remain valid for inclusion.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A bundler MUST drop a UserOperation if it expires too soon and is likely to become invalid before the next block.","specSection":"Specification / UserOperation Simulation / Simulation Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#simulation-specification","designImplication":"Show a relevant operation or sponsorship expiry, refresh stale quotes, and explain when renewed approval is needed. A queued or signed operation is not guaranteed to remain eligible. Respect a reported not-yet-valid time instead of repeatedly resubmitting unchanged data."},{"id":"delegated-account-initialization","constraint":"Wallet applications should not repeatedly send initialization code for an EIP-7702 account.","appliesTo":"wallet","normativity":"normative","specQuote":"There is no way for the EntryPoint contract to know whether an EIP-7702 account has been initialized or not, and therefore the EIP-7702 account initialization code, can be called multiple times through EntryPoint. The Account code SHOULD only allow calling it once and the Wallet Application SHOULD NOT pass the initCode repeatedly.","specSection":"Specification / EIP-7702 delegated Smart Contract Accounts","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#eip-7702-delegated-smart-contract-accounts","designImplication":"Separate setup from ordinary operations and check the selected account implementation's initialization state before retrying setup. An EntryPoint acceptance alone does not establish that initialization is needed or safe to repeat."},{"id":"legacy-account-compatibility","constraint":"An existing smart contract account is not automatically ERC-4337-compatible.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"Unfortunately it is not easily compatible with pre-ERC-4337 Smart Contract Accounts, because those Accounts do not have a validateUserOp function.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#backwards-compatibility","designImplication":"Detect the selected account and supported EntryPoint path before offering this flow. Explain a supported wrapper or migration when needed; do not infer compatibility merely because an address contains contract code."},{"id":"authorization-gas-estimate","constraint":"The EIP-7702 authorization cost must be included in preVerificationGas when that path is used.","appliesTo":"infrastructure","normativity":"normative","specQuote":"Additionally, EIP-7702 defines the gas cost of executing an authorization equal to PER_EMPTY_ACCOUNT_COST = 25000. This gas consumption is not observable on-chain by the EntryPoint contract and MUST be included in the preVerificationGas value.","specSection":"Specification / Support for EIP-7702 authorizations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#support-for-eip-7702-authorizations","designImplication":"Use an estimate that includes authorization overhead for the chosen network and EntryPoint version. Do not reuse an ordinary operation's estimate for a setup operation or describe this path as cost-free."},{"id":"entrypoint-trust-boundary","constraint":"EntryPoint is a central trust point whose audit and formal verification matter to the integration.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"The `EntryPoint` contract will need to be audited and formally verified, because it will serve as a central trust point for _all_ [ERC-4337].","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#security-considerations","designImplication":"Verify the chosen network's deployed EntryPoint address and version and the review evidence for that deployment. A supported-account or sponsorship badge is not proof of security; keep infrastructure provenance available for integration review."},{"id":"optional-account-deposit","constraint":"An account may deposit more than the current operation needs and withdraw the excess later.","appliesTo":"account-implementation","normativity":"normative","specQuote":"* The `sender` MAY pay more than this minimum to cover future transactions. It can also call `withdrawTo` to retrieve it later at any time.","specSection":"Specification / Smart Contract Account Interface","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#smart-contract-account-interface","designImplication":"If the wallet exposes prefunding, distinguish the EntryPoint deposit from the account's ordinary balance and the current operation's fee. Show a supported withdrawal path without implying every account must prefund future operations."},{"id":"delegated-operation-code-binding","constraint":"Without the specified initCode, a delegated UserOperation may execute against a changed account delegate.","appliesTo":"wallet","normativity":"normative","specQuote":"Note that a `UserOperation` may still be executed without such `initCode`.\nIn this case the `EntryPoint` doesn't hash the current [EIP-7702 delegate](./eip-7702.md), and can be potentially executed against a modified account.","specSection":"Specification / Support for EIP-7702 authorizations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#support-for-eip-7702-authorizations","designImplication":"Confirm whether the operation hash binds the reviewed delegate. If the delegate changes before inclusion, refresh the execution review or reject the stale operation through the supported wallet path. A new authorization tuple and delegate binding are separate checks."},{"id":"sender-queue-policy","constraint":"The specified sender queue and bundle limits have a staked-sender exemption.","appliesTo":"infrastructure","normativity":"normative","specQuote":"* The `sender` doesn't have another `UserOperation` already present in the mempool (or it replaces an existing entry with the same sender and nonce, with a higher `maxPriorityFeePerGas` and an equally increased `maxFeePerGas`).\n  Only one `UserOperation` per sender may be included in a single bundle.\n  A sender is exempt from this rule and may have multiple `UserOperations` in the mempool and in a bundle if it is staked.","specSection":"Specification / Bundler behavior upon receiving a UserOperation","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#bundler-behavior-upon-receiving-a-useroperation","designImplication":"Handle a pending-operation conflict and any supported same-nonce fee replacement. Check the selected bundler's rules and the sender's staking state; do not impose a universal one-operation queue on every smart account."},{"id":"paymaster-precharge-refund","constraint":"A token paymaster may pre-charge a maximum amount and refund excess afterward.","appliesTo":"application","normativity":"rationale","specQuote":"Paymaster architecture allows them to follow the model of \"pre-charge, and later refund\".\nE.g. a token-paymaster may pre-charge the user with the max possible price of the transaction, and refund the user with the excess afterwards.","specSection":"Rationale / Paymasters","specUrl":"https://ercs.ethereum.org/ERCS/erc-4337#paymasters","designImplication":"When the selected paymaster uses this model, show the temporary charge separately from the final fee and track the actual refund. Do not promise precharging or refunds for every sponsorship implementation."}],"prototypeFirst":[{"screen":"Fee selection","why":"A supported paymaster can remove the need to acquire ETH first, but the fee model must include the actual operation's costs. The current spec charges 10% on unused callGasLimit and paymasterPostOpGasLimit gas when the remaining unused amount is at least 40,000 gas; inflated limits are not always refunded in full.","covers":["Gas sponsorship","Pay gas with another token","Paymaster unavailable","Paymaster rejected by bundler"],"include":["Sponsored label with value","Fee token options","Fallback to user-paid gas","Version-aware estimate including any unused-gas penalty and paymaster charges"]},{"screen":"Bundled confirmation","why":"One signature can contain multiple consequences. The user still needs to understand the full action.","covers":["Approve plus action","Account-specific batch semantics","Validation rejection","Execution simulation failure when available"],"include":["Ordered step preview","Selected account's success and failure behavior","Blocked signing when an available execution preflight fails","Separate validation acceptance from execution outcome"]},{"screen":"Recovery setup","why":"Recovery replaces the seed phrase backup moment, so it needs to feel like account safety, not advanced settings.","covers":["Configured recovery contacts","Account-specific threshold or rule","Recovery inactive state"],"include":["Configured recovery status rows","Account-specific rule copy","Clear \"not protected yet\" state"]},{"screen":"Recovery in progress","why":"A recovery flow is both help and risk. The owner must see what is happening and how to stop it.","covers":["Configured approvals","Configured security delay","Cancel recovery"],"include":["Countdown","Approving guardians","New owner destination","Prominent cancel action"]},{"screen":"Operation status","why":"ERC-4337 adds steps between signing and confirmation. Status copy should make progress feel legible.","covers":["Signed","Bundler pending","Included","Confirmed"],"include":["Single status strip","Plain-language states","Expandable user operation hash"]}],"mentalModel":[{"label":"User intent","description":"The product still asks the user to send, swap, mint, or recover. \"UserOperation\" is only the package the app builds behind the interface."},{"label":"Smart account","description":"The account is contract code, so validation can follow rules supplied by the selected account implementation, such as passkeys, guardians, multisig, or session keys."},{"label":"EIP-7702-delegated sender","description":"On a network with EIP-7702 enabled, a compatible delegated EOA can be the UserOperation sender. The 0x7702 factory flag identifies that path. When a signed eip7702Auth tuple is supplied, the bundler includes the required authorizations in a type-0x04 bundle transaction. Existing contract accounts remain a separate supported path; not every operation needs a new delegation authorization."},{"label":"Bundler","description":"A bundler collects valid operations and submits them on-chain. Your status UI should track submission, inclusion, and confirmation as one journey."},{"label":"EntryPoint","description":"The EntryPoint checks account and paymaster rules before execution. Bundler validation simulation does not guarantee execution success; distinguish a wallet's optional pre-signing execution preview from bundler acceptance and the final receipt."},{"label":"Paymaster","description":"A paymaster can sponsor gas or charge another token. Designers need a clear fallback when sponsorship is unavailable."}],"statesToDesign":[{"state":"Account not deployed","trigger":"The user is using a counterfactual smart account for the first time.","userNeed":"Know whether setup is automatic, costs money, or changes timing.","designResponse":"Keep it in setup or transaction details unless deployment affects cost, time, or risk."},{"state":"Paymaster quote unavailable","trigger":"The sponsor cannot quote gas or the selected fee token is unsupported.","userNeed":"A path forward that does not feel like a broken checkout.","designResponse":"Offer a supported fee token, user-paid gas, or retry with the service's reported reason. Do not infer a bundler reputation failure or exhausted sponsor funds from a missing quote."},{"state":"Paymaster rejected by bundler","trigger":"Bundler validation rejects the paymaster, including a reported reputation throttle or temporary ban after invalidating many pending operations.","userNeed":"Understand why a quoted fee option cannot currently be submitted.","designResponse":"Use the reported reason and distinguish reputation policy from deposit funding, stake or storage checks, and quote-service failure. Offer another supported paymaster, user-paid path, or retry when appropriate."},{"state":"Validation rejected","trigger":"The bundler rejects the operation during account or paymaster validation.","userNeed":"Understand why a signed operation was not accepted.","designResponse":"Show the reported validation reason and a recovery action. Do not label it an included execution failure or repeatedly submit the same invalid operation."},{"state":"Execution preview failed","trigger":"An optional wallet or application execution simulation predicts a failed call.","userNeed":"Understand what to fix before signing when this preview is available.","designResponse":"Explain the preview's scope, name the failed step, and let the user revise the action before signing. Do not imply that every bundler performs this execution check."},{"state":"Included execution failed","trigger":"The operation passed validation and was included, but its execution failed.","userNeed":"Know the actual outcome and any fee charged.","designResponse":"Use the operation receipt and account-specific batch results. Separate the failed action from other operations in the bundle, and explain the fee and safe retry path."},{"state":"Bundler pending","trigger":"The user signed, but the operation is waiting for inclusion.","userNeed":"Confidence that the action left their device and is still progressing.","designResponse":"Show sent, processing, included, and confirmed as one status strip with an expandable technical ID."},{"state":"Guardian invite pending","trigger":"A recovery contact has not accepted or confirmed.","userNeed":"Know whether the account is protected yet.","designResponse":"Show inactive recovery until the threshold can be reached, not just a generic pending badge."},{"state":"Security delay active","trigger":"Recovery has enough guardian approvals and is waiting out the delay.","userNeed":"Know when recovery completes and how to stop it if it is suspicious.","designResponse":"Show countdown, approving guardians, destination account, and a prominent cancel action."}],"designDecisions":[{"question":"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":"Show the actual fee payer and token debit, including any paymaster pricing. In the current specification, unused callGasLimit and paymasterPostOpGasLimit gas incurs a 10% penalty when the remaining unused amount reaches at least 40,000 gas. Estimate for the deployed EntryPoint version instead of promising a full refund for inflated limits."},{"question":"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."},{"question":"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."},{"question":"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."},{"question":"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."}],"problemsSolved":[{"problem":"A user may lack the native token required by a smart-account flow","oldWay":"Acquire the network token before submitting the action","newWay":"A compatible paymaster may sponsor the operation or accept another fee token; the product must show fallback and eligibility","impact":"critical"},{"problem":"A smart-account recovery path may be easier to understand than a seed phrase","oldWay":"The selected account offers only its configured key or recovery method","newWay":"An account implementation may provide guardians, thresholds, delays, or another recovery rule; ERC-4337 does not mandate one","impact":"critical"},{"problem":"The account may need validation rules beyond a single ECDSA key","oldWay":"The account accepts only the signing method its implementation defines","newWay":"A compatible account can implement custom validation such as a passkey or multisig rule","impact":"high"},{"problem":"Each operation requires separate transaction","oldWay":"Approve, wait, swap, wait, stake, wait...","newWay":"A compatible account can bundle multiple calls, but UserOperation bundling does not guarantee atomicity across subcalls or unrelated operations","impact":"high"},{"problem":"Smart wallets couldn't initiate transactions","oldWay":"Needed an EOA to trigger contract wallet actions","newWay":"Bundlers can submit UserOperations through the EntryPoint when the account and infrastructure are configured","impact":"high"}],"uxPatterns":[{"name":"Gas Abstraction","description":"User sees the fee model returned by the selected account and paymaster, if supported","components":["Gas token picker","Estimated cost","Order total"],"userFlow":["User initiates purchase","App fetches gas quotes from paymaster","User selects payment token","UserOp created with paymaster data","User signs once","Paymaster handles conversion"]},{"name":"Social Recovery Setup","description":"Configure the recovery rules exposed by the selected account implementation","components":["Guardian list","Guardian status row","Threshold control","Time-lock notice"],"userFlow":["User opens recovery settings","Adds guardian addresses or emails","Sets threshold (2 of 3)","Guardians confirm participation","Recovery becomes active"]},{"name":"Account Recovery Flow","description":"Account restoration using the configured recovery rules","components":["Approval progress","Time-lock countdown","Recovery status"],"userFlow":["User initiates recovery from new device","Contacts guardians for approval","Guardians sign recovery request","Threshold reached","Time lock countdown begins","Recovery completes after delay"]},{"name":"Bundled DeFi Operations","description":"Complex multi-step DeFi in one account-specific operation","components":["Step list","Savings summary","Execute-all button"],"userFlow":["User selects strategy/actions","App builds UserOp with all calls","Shows preview with savings","User signs once","Account executes the selected calls according to its implementation; show each outcome and any partial result"]}],"uiComponents":[{"name":"Gas token picker","description":"Choose which token to pay gas with, or use a sponsor","kind":"selector","states":["loading","ready","no sponsors","selected"],"props":["availableTokens[]","gasEstimates","selectedToken","onSelect"]},{"name":"Guardian list","description":"Add, remove, and see the status of recovery guardians","kind":"list","states":["empty","configuring","active","recovering"],"props":["guardians[]","threshold","onAdd","onRemove"]},{"name":"Transaction preview","description":"Show what a single bundled transaction will do, step by step","kind":"preview","states":["building","ready","simulating","error"],"props":["calls[]","gasEstimate","paymasterInfo"]},{"name":"Recovery progress","description":"Track guardian approvals, the time lock, and final completion","kind":"progress","states":["initiating","gathering approvals","time-locked","complete"],"props":["approvals","threshold","timelockRemaining"]},{"name":"Submission status","description":"Show submission, inclusion, and confirmation as one strip","kind":"status","states":["submitting","pending","included","confirmed","failed"],"props":["userOpHash","txHash","error"]}],"antiPatterns":[{"pattern":"Exposing \"UserOperation\" terminology to users","why":"Technical jargon confuses users, they just want to \"send\" or \"swap\"","instead":"Use familiar terms: transaction, transfer, swap","severity":"high"},{"pattern":"No fallback when paymaster rejects","why":"User stuck if sponsor runs out or rejects","instead":"Graceful fallback to ETH with clear explanation","severity":"critical"},{"pattern":"Assuming ERC-4337 mandates a recovery delay","why":"Recovery rules and delay semantics belong to the selected account implementation","instead":"If the account configures a security delay, show its duration, destination, and cancel path; otherwise explain the actual recovery rule","severity":"critical"},{"pattern":"Presenting one recovery policy as universal","why":"ERC-4337 does not mandate guardians, thresholds, or any particular recovery mechanism","instead":"Show the selected account's configured recovery rule, threshold, and fallback before setup","severity":"critical"},{"pattern":"Hiding gas costs in sponsored transactions","why":"Users shocked when sponsorship ends and they pay","instead":"Show \"Sponsored ($0.35 value)\" so users understand","severity":"medium"},{"pattern":"Not simulating UserOps before submission","why":"Failed UserOps waste user time and sometimes gas","instead":"Simulate when the selected infrastructure supports it and explain any known failure before signing","severity":"high"}],"vocabulary":[{"use":"Transaction","avoid":"UserOperation, UserOp","why":"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","avoid":"4337 wallet, ERC-4337 account","why":"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","avoid":"Gasless, Free gas","why":"\"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","avoid":"Use ERC-20 paymaster, Token paymaster","why":"Paymaster is the backend role. The user just sees which token they are paying with."},{"use":"Guardian","avoid":"Trustee, Recovery key, Co-signer","why":"Use the term that matches the selected account's role; avoid presenting an implementation-specific label as an ERC-4337 requirement."},{"use":"Security delay","avoid":"Time lock, Timelock","why":"\"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","avoid":"Configure social recovery, Set up your recovery module","why":"Backup is the mental model people bring from photos and passwords. \"Module\" is implementation language."},{"use":"Sent, Submitting","avoid":"Submitted to bundler, Included in mempool","why":"Bundler and mempool are plumbing. The user cares that the action left their device and is on its way."},{"use":"Cancel recovery","avoid":"Veto, Abort","why":"\"Veto\" sounds adversarial. \"Abort\" sounds like a system error. The owner pressing cancel on their own recovery is a normal, calm action."}],"onMonad":[{"aspect":"Account and fee payer","ethereum":"EntryPoint, account, bundler, and paymaster support determine which operations and fee options work.","monad":"Verify those integrations on Monad. An ERC-4337 contract account is not automatically a delegated EOA, and Monad's EOA reserve rules do not impose a universal 10 MON balance on every smart account.","designImplication":"Identify the actual account type and transaction fee payer. Show sponsorship only when the selected integration accepts the operation; provide a clear failure or user-paid path."},{"aspect":"Delegated EOA operations","ethereum":"A compatible EIP-7702 account can use ERC-4337 infrastructure without changing its address.","monad":"When an operation spends native MON from a delegated EOA, the reserve rules still apply. Sponsorship pays the transaction fee; it does not grant unrestricted native-balance spending.","designImplication":"Simulate the complete operation. Keep sponsorship eligibility separate from the account's ability to make the requested transfer."}],"keyTakeaways":["ERC-4337 is the infrastructure, not the UX. Hide the complexity.","Batching and failure behavior come from the selected account implementation, not ERC-4337 bundling alone.","Recovery thresholds and delays come from the selected account implementation.","Use an execution preview when the wallet or app supports it. Keep pre-signing warnings, bundler validation rejection, and included execution failure separate; validation success does not guarantee execution success.","Never show \"UserOperation\" or \"bundler\" to users"],"technicalNotes":"ERC-4337 defines UserOperations, EntryPoint, bundlers, and account/paymaster interfaces. It does not make an account's internal batch atomic, and bundling UserOperations does not make unrelated operations all-or-nothing. Read the selected account's execution behavior, simulate the requested calls, and show the actual outcome. The current ERC-4337 specification lists EIP-712 and EIP-7702 as dependencies and supports compatible delegated EOAs alongside contract accounts. On networks with EIP-7702 enabled, factory = 0x7702 identifies the delegated-sender path; when eip7702Auth is provided, the bundler adds required authorizations and executes the bundle as a type-0x04 transaction. This does not require every smart account or every bundle to use EIP-7702. Executing an authorization adds 25,000 gas that must be included in preVerificationGas. The current spec also applies a 10% penalty to unused callGasLimit and paymasterPostOpGasLimit gas at the 40,000-gas threshold; verify the deployed EntryPoint version. Reputation rules can throttle or temporarily ban paymasters that invalidate many pending operations. Stake and storage checks, deposit funding, and reputation are distinct checks; ERC-4337 leaves the full reputation-system specification out of scope.","sources":[{"label":"Monad reserve-balance rules","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"reference"},{"label":"EIP-7702 on Monad","url":"https://docs.monad.xyz/developer-essentials/eip-7702","type":"reference"},{"label":"Official ERC-4337 specification","url":"https://ercs.ethereum.org/ERCS/erc-4337","type":"official-spec"}],"lastUpdated":"2026-09-18","lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-4337","type":"official-spec"},{"label":"Discussion thread","url":"https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160","type":"discussion"},{"label":"Monad reserve-balance rules","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"reference"},{"label":"EIP-7702 on Monad","url":"https://docs.monad.xyz/developer-essentials/eip-7702","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-4337","markdown":"https://www.eipsfordesigners.com/standards/ERC-4337/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-4337/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-4337","official":"https://ercs.ethereum.org/ERCS/erc-4337","discussion":"https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}