{"id":"EIP-8141","name":"Native Account Abstraction (Frame Txs)","status":"Draft","chain":"ethereum","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"}],"uxImpact":"EIP-8141 is a Draft frame-transaction proposal for native account abstraction. Its current design can let compatible accounts use default code for batching or alternative fee payment, but it does not configure universal recovery or key rotation for every existing account.","officialUrl":"https://eips.ethereum.org/EIPS/eip-8141","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-8141","specConstraints":[{"id":"eip-8141-atomic-frame-batch","constraint":"An atomic-batch flag means every frame in the batch succeeds or the whole batch reverts.","appliesTo":"application","normativity":"normative","specQuote":"All frames in a batch must succeed, or all of them revert.","specSection":"Specification — Frame Transaction — Field Definitions — Frame object — Flags","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#flags","designImplication":"Label atomic batching as a protocol-backed guarantee only when the frame flag and target implementation support it. Show the all-or-nothing failure behavior in the review and recovery states."},{"id":"eip-8141-signature-validation","constraint":"Every protocol-validated signature must validate before any frame executes; one malformed or invalid signature invalidates the transaction.","appliesTo":"account-implementation","normativity":"normative","specQuote":"Every protocol-validated signature in this list must validate successfully before any frame is executed. If any signature is malformed, or any protocol-validated signature is invalid, the whole transaction is invalid.","specSection":"Specification — Frame Transaction — Transaction Signatures","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#transaction-signatures","designImplication":"Keep signature validation failure distinct from a later frame execution failure. A wallet should not present downstream effects as partially submitted when protocol validation rejected the whole transaction."},{"id":"eip-8141-signer-address","constraint":"SECP256K1 and P256 signatures identify a 20-byte Ethereum address, while ARBITRARY signatures have no protocol-resolved signer address.","appliesTo":"wallet","normativity":"normative","specQuote":"For `SECP256K1` and `P256`, the `signer` is a 20-byte Ethereum address. If absent, `tx.sender` is used (for introspections as well).","specSection":"Specification — Frame Transaction — Transaction Signatures","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#transaction-signatures","designImplication":"Show which signer and sender authority a compatible wallet is using, and do not imply that an ARBITRARY witness has a standard address identity."},{"id":"eip-8141-sender-approval-gate","constraint":"A frame transaction is invalid unless sender_approved is true after validation.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- `sender_approved` must be `true`. If not, the transaction is invalid.","specSection":"Specification — Frame Transaction — Behavior","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#behavior","designImplication":"Keep account approval as an explicit capability and failure state. Do not report a frame transaction as authorized merely because a signature or fee payer was present."},{"id":"eip-8141-atomic-rollback","constraint":"When an atomic batch frame fails, state rolls back to before the batch and remaining frames are skipped.","appliesTo":"application","normativity":"normative","specQuote":"When a frame in the batch fails, the state must be rolled back to the condition it was immediately before the atomic batch began. All remaining frames in the atomic batch are skipped.","specSection":"Specification — Frame Transaction — Behavior","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#behavior","designImplication":"Show atomic failure as a rolled-back batch with no later-frame progress. Keep this state distinct from a non-atomic sequence where earlier frames may have committed."},{"id":"eip-8141-mempool-validation-boundary","constraint":"Public mempools must validate frame transactions without allowing shared-state changes to mass-invalidate previously accepted transactions.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The fundamental goal of the public mempool rules is to avoid allowing an arbitrary number of transactions to be invalidated by a single environmental change or state modification.","specSection":"Specification — Mempool","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mempool","designImplication":"Treat a public-mempool acceptance as provisional until inclusion and show a validation or revalidation failure as a recoverable pending-transaction state."},{"id":"eip-8141-public-mempool-propagation","constraint":"Transactions outside the recognized public-mempool rules must not be propagated through the public mempool.","appliesTo":"infrastructure","normativity":"normative","specQuote":"Transactions outside these rules may be accepted into a local or private mempool, but must not be propagated through the public mempool.","specSection":"Specification — Mempool","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mempool","designImplication":"Distinguish local/private acceptance from public propagation in advanced transaction tooling. Do not tell users that a locally accepted draft has entered the network-wide relay path."},{"id":"eip-8141-expiry-mempool-drop","constraint":"A node must drop an expiry-verified frame transaction when its deadline is below the node's current block timestamp.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A node MUST drop a frame transaction from the public mempool if it contains an `expiry_verify` frame whose deadline is less than the node's view of the current block timestamp at any point.","specSection":"Specification — Mempool — Expiry Verifier Frame","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#expiry-verifier-frame","designImplication":"Show expiry as a live boundary for pending transactions. Give users a clear expired/retry state instead of leaving a stale transaction looking queued indefinitely."},{"id":"eip-8141-paymaster-fund-safety","constraint":"A standardized paymaster sponsoring many accounts must keep incoming ether restricted to transaction payment or delayed withdrawal.","appliesTo":"account-implementation","normativity":"normative","specQuote":"If a paymaster sponsors gas for a large number of accounts simultaneously, it must be a safe, standardized paymaster contract. It is designed such that ether which enters it cannot leave except:","specSection":"Specification — Mempool — Paymasters","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#paymasters","designImplication":"Treat sponsored gas as a custody and recovery promise. Show the sponsor identity and any delayed withdrawal condition rather than presenting fee sponsorship as risk-free balance transfer."},{"id":"eip-8141-canonical-paymaster-balance","constraint":"A canonical paymaster transaction is rejected when its available balance is below the transaction's maximum cost.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A node must reject a paymaster transaction if `available_paymaster_balance` is less than the transaction's maximum cost (`TXPARAM(0x06)`).","specSection":"Specification — Mempool — Paymasters — Canonical paymaster","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#canonical-paymaster","designImplication":"Preflight sponsor capacity and show sponsorship as conditional. Do not promise a gasless action when the sponsor cannot cover the maximum cost."},{"id":"eip-8141-noncanonical-paymaster-balance","constraint":"A non-canonical paymaster must have available balance at least equal to the transaction cost before acceptance.","appliesTo":"infrastructure","normativity":"normative","specQuote":"For balance, `available_paymaster_balance` must not be less than the transaction cost, where:","specSection":"Specification — Mempool — Paymasters — Non-canonical paymaster","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#non-canonical-paymaster","designImplication":"Disclose when a sponsor uses a non-canonical path and treat its capacity as a live acceptance condition, not as a permanent account capability."},{"id":"eip-8141-replacement-fee-policy","constraint":"A replacement must satisfy all frame-transaction rules and increase both gas-fee fields by the node's configured minimum increment.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A replacement must be valid under all rules in this section and should only be accepted and propagated if it increases both `max_fee_per_gas` and `max_priority_fee_per_gas` by at least a node-configured minimum increment (10% is the conventional default).","specSection":"Specification — Mempool — Replacement and Eviction","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#replacement-and-eviction","designImplication":"When offering speed-up or replacement, show both fee dimensions and the selected network's configured increment. Do not label a replacement guaranteed until the node accepts it."},{"id":"eip-8141-approve-authority","constraint":"Only the sender can toggle sender_approved to true, and APPROVE is generally callable only by the frame's resolved target.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"It is still required that only the sender can toggle the `sender_approved` to `true`.","specSection":"Rationale — APPROVE calling convention","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#approve-calling-convention","designImplication":"Keep approval authority tied to the intended sender and account implementation. Do not frame a third-party paymaster or arbitrary target as able to grant sender authorization."},{"id":"eip-8141-origin-compatibility","constraint":"Frame transactions change ORIGIN to return the frame caller, so contracts relying on ORIGIN = CALLER security checks may behave differently.","appliesTo":"account-implementation","normativity":"backwards-compatibility","specQuote":"The `ORIGIN` opcode behavior changes for frame transactions, returning the frame's caller rather than the traditional transaction origin.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#backwards-compatibility","designImplication":"Label frame-transaction compatibility as implementation-specific. Do not imply that existing ORIGIN-based authorization contracts retain their old security behavior."},{"id":"eip-8141-per-frame-gas-estimates","constraint":"Wallets and gas estimators must show separate execution and state budgets for each frame; budgets cannot borrow across frames.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"Wallets and gas estimators must produce two-dimensional, per-frame gas estimates: each frame's `limits.execution` covers its execution gas and its `limits.state` covers its state gas, and neither budget can borrow from the other or from other frames.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#backwards-compatibility","designImplication":"Show execution and state gas separately per frame, including the failure state for under-provisioned state gas and the up-front max-cost effect of over-provisioning."},{"id":"eip-8141-expiry-staleness","constraint":"A transaction that depends on a timestamp deadline can become invalid after submission without any on-chain action.","appliesTo":"application","normativity":"security-considerations","specQuote":"Such transactions are valid when submitted but become invalid once the deadline passes, without any on-chain action required from the attacker.","specSection":"Security Considerations — Transaction Propagation — Example Attack","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#example-attack","designImplication":"Show the expiry window and revalidation status for pending frame transactions. Give users a recoverable expired state instead of implying that mempool acceptance guarantees eventual execution."},{"id":"eip-8141-deploy-front-running","constraint":"Deploy-frame calldata and initcode must be safe for anyone to submit because deployment occurs before sender authentication, and wallets should expect resubmission without the deploy frame after a front-run.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Accordingly, the deploy frame's calldata (and any initcode it carries) must be safe to submit by any party, and wallets should expect resubmission without the `deploy` frame once deployment has already occurred.","specSection":"Security Considerations — Transaction Propagation — Deploy Frame Front-Running","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#deploy-frame-front-running","designImplication":"Make deployment front-running and retry behavior explicit. Do not ask users to sign a deploy frame whose calldata would be harmful if copied or submitted by another party."},{"id":"eip-8141-validation-data-visibility","constraint":"Validation logic can inspect later frame parameters, so non-VERIFY frame data should be treated as visible to paymasters and verifiers.","appliesTo":"application","normativity":"security-considerations","specQuote":"Users should therefore treat non-`VERIFY` frame parameters and data as visible to validation logic and should not rely on untrusted paymasters or verifiers to keep such information private.","specSection":"Security Considerations — Transaction Propagation — Cross-frame Data Visibility During Validation","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#cross-frame-data-visibility-during-validation","designImplication":"Warn users before putting sensitive intent or values in frames visible during validation. Treat a paymaster or verifier as an observer of the full frame data it can inspect."},{"id":"eip-8141-arbitrary-signature-malleability","constraint":"ARBITRARY signatures are not cryptographically validated by the protocol, so custom verifiers must enforce canonical encodings and reject unused bytes.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"The protocol performs no cryptographic validation for `ARBITRARY` signatures. When an `ARBITRARY` signature has empty `msg`, its raw bytes are elided from the canonical signature hash and can therefore be changed without changing `TXPARAM(0x08)`. If the custom verifier accepts multiple encodings for the same witness the transaction hash may be malleable even though the canonical signature hash is not. Custom verifiers should enforce canonical encodings and reject unused bytes. When an `ARBITRARY` signature uses an explicit 32-byte `msg`, its raw bytes are committed to by the canonical signature hash and this particular source of transaction-hash malleability does not apply.","specSection":"Security Considerations — Transaction Propagation — Arbitrary Signature Malleability","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#arbitrary-signature-malleability","designImplication":"Do not present an arbitrary signature as protocol-authenticated. Require the account implementation or verifier to explain its canonicalization and replay/malleability protections."},{"id":"eip-8141-validation-prefix-bounds","constraint":"Validation prefixes need enforced structure and bounded validation gas before payer approval permits mempool propagation.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"It's recommended that to *validate* the transaction, a specific frame structure is enforced and the amount of gas that is expended executing the validation phase must be limited.","specSection":"Security Considerations — Transaction Propagation — Arbitrary Signature Malleability — Mitigations","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mitigations","designImplication":"Treat public-mempool acceptance as bounded validation, not as proof that arbitrary account code will remain valid. Keep validation limits and failure states observable to operators and advanced users."},{"id":"eip-8141-deployment-determinism","constraint":"Sender deployment must not depend on mutable chain state outside tx.sender or per-deploy factory storage.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"Any contract may be used as `frame.target`, provided the frame's execution satisfies those rules — notably, it must not read mutable state outside `tx.sender` or maintain per-deploy factory storage (counters, reentrancy flags, etc.), so that the deployment result is independent of chain state.","specSection":"Security Considerations — Transaction Propagation — Arbitrary Signature Malleability — Mitigations","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mitigations","designImplication":"Treat deterministic account deployment as a compatibility and retry requirement. A deployment preview should not depend on mutable factory state that can change before inclusion."},{"id":"eip-8141-single-pending-frame","constraint":"Frame-transaction mempool relay may allow only one pending transaction for an account using frame transactions.","appliesTo":"application","normativity":"security-considerations","specQuote":"In general, it can be assumed that handling of frame transactions imposes similar restrictions as EIP-7702 on mempool relay, i.e. only a single transaction can be pending for an account that uses frame transactions.","specSection":"Security Considerations — Transaction Propagation — Arbitrary Signature Malleability — Mitigations","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mitigations","designImplication":"Show the account's pending-transaction constraint and make replacement or cancellation behavior explicit instead of offering parallel frame submissions that the mempool may reject."},{"id":"eip-8141-state-gas-isolation","constraint":"Frame state-gas budgets are not shared, so validation must verify each dependent frame declares the state budget it needs.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"Frame state-gas budgets are deliberately not shared. A shared, transaction-scoped state budget would allow one frame to exhaust the state gas a later frame depends on: for example, a user operation could drain the budget a paymaster's `post_op` frame needs to write its accounting slot, causing it to halt. Because each frame's `limits.state` is declared in the transaction and unavailable to other frames, validation code and paymasters can verify via `FRAMEPARAM`, before approving, that every frame they depend on carries the state budget it needs. The cross-frame refill rules preserve this isolation: clearing state paid for by an earlier frame reduces that earlier frame's `gas_used.state` and credits the payer at settlement, but never increases the executing frame's spendable budget.","specSection":"Security Considerations — State Gas Isolation Between Frames","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#state-gas-isolation-between-frames","designImplication":"Show per-frame state-gas limits and identify the frame that failed when a later write cannot proceed. Do not describe one transaction-level state budget as shared capacity."},{"id":"eip-8141-approval-scope","constraint":"Execution approval authorizes every subsequent sender frame, so validation must bind approval to the complete frame set or constrain every later target.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"`sender_approved` is a single transaction-scoped flag. Once a frame grants `APPROVE_EXECUTION` (or `APPROVE_EXECUTION_AND_PAYMENT`), every subsequent `SENDER` frame executes with `caller` set to `tx.sender`, not only the frame the approving code inspected. The approval is not scoped to a particular frame or call target.\n\nValidation code must therefore bind its approval to the entire set of frames it is willing to authorize. A signature with an empty `msg` commits to this, because it is verified over `compute_sig_hash(tx)`, which covers the full frame list; the default validation code relies on exactly such a signature. A validator that instead approves on the basis of an explicit 32-byte `msg` signature, or any check that does not commit to the frames, authorizes an open-ended list. Because a frame transaction carries no outer signature over the whole envelope, an observer can then reuse that approval with a different set of `SENDER` frames, since those frames were never part of what the validator verified. This is the \"unchecked fields\" class of issue familiar from account-abstraction relaying, now expressed in-protocol.\n\nCustom validation contracts that grant `APPROVE_EXECUTION` should verify against the canonical signature hash, or otherwise constrain every subsequent `SENDER` frame, before approving.","specSection":"Security Considerations — Execution Approval Authorizes All Subsequent Sender Frames","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#execution-approval-authorizes-all-subsequent-sender-frames","designImplication":"Make the full set of later sender frames visible in approval review and require the validator to commit to them. Never summarize an approval as permission for only the frame that triggered it."},{"id":"eip-8141-canonical-signature-hash","constraint":"The canonical signature hash is strongly recommended for avoiding frame transaction malleability.","appliesTo":"wallet","normativity":"rationale","specQuote":"Computing the signature hash in EVM is complicated and expensive. While using the canonical signature hash is not mandatory, it is strongly recommended. Creating a bespoke signature requires precise commitment to the underlying transaction data. Without this, it's possible that some elements can be manipulated in-the-air while the transaction is pending and have unexpected effects. This is known as transaction malleability. Using the canonical signature hash avoids malleability of the frames.","specSection":"Rationale — Canonical signature hash","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#canonical-signature-hash","designImplication":"For bespoke signatures, confirm precise commitment to the transaction data rather than assuming the same malleability protection."},{"id":"eip-8141-delegatecall-approve-trust","constraint":"Contracts relying on APPROVE should treat delegatecalled libraries as fully trusted because they may execute APPROVE successfully.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"Because `DELEGATECALL` preserves `ADDRESS`, code executed via `DELEGATECALL` from the resolved target may also execute `APPROVE` successfully. Contracts that rely on `APPROVE` should therefore treat delegatecalled libraries as fully trusted.","specSection":"Rationale — APPROVE calling convention","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#approve-calling-convention","designImplication":"Keep delegatecalled approval code inside the account's trusted implementation boundary and avoid implying that a library is an independent approval authority."},{"id":"eip-8141-validation-access-boundaries","constraint":"Node implementations should consider restricting the opcodes and storage slots validation frames can access to limit mass invalidation vectors.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"Node implementations should consider restricting which opcodes and storage slots validation frames can access, similar to ERC-7562. This isolates transactions from each other and limits mass invalidation vectors.","specSection":"Security Considerations — Transaction Propagation — Arbitrary Signature Malleability — Mitigations","specUrl":"https://eips.ethereum.org/EIPS/eip-8141#mitigations","designImplication":"Treat validation-access restrictions as infrastructure trust assumptions and expose them in advanced compatibility or operator tooling rather than promising unrestricted frame execution."}],"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-8141","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"EIP-8141 is a Draft frame-transaction proposal for native account abstraction. Its current design can let compatible accounts use default code for batching or alternative fee payment, but it does not configure universal recovery or key rotation for every existing account.","partialDeployment":{"body":"EIP-8141 is Draft. Treat frame transactions, default code, validation, and alternate-fee behavior as experimental until the target network and wallet implement the finalized proposal."},"designerTakeaways":["Explore frame-transaction UX as a draft and label the assumptions that depend on future protocol adoption.","Keep default-code benefits separate from recovery, guardians, and key rotation supplied by a compatible account implementation.","Show account and wallet capability checks before presenting native-AA actions."],"applicability":{"whenToUse":["You are prototyping native account-abstraction semantics against the target implementation.","The product can gate recovery, validation, and fee flows on the deployed protocol support.","Users need a clearly labeled experimental or implementation-specific flow."],"whenToAvoid":["Shipping before native AA is finalized on mainnet.","Current stack only supports EOAs and ERC-4337 today.","Users need production-ready flows now without draft-spec risk."]},"prototypeFirst":[{"screen":"Draft frame-transaction preview","why":"Prototype the proposal only against a compatible implementation and label assumptions that may change.","covers":["Frame request","Clear draft-stage copy"],"include":["Account capability","Fee path","Fallback"]},{"screen":"Unsupported frame implementation","why":"A Draft proposal cannot be assumed to work on a production wallet or network.","covers":["No frame support","Network or account mismatch"],"include":["Plain-language reason","Fallback action"]},{"screen":"Draft-path fallback","why":"Users need a current account path when frame validation or fee behavior is unavailable.","covers":["Frame validation failure","Legacy or ERC-4337 fallback"],"include":["Retry path","Support context"]},{"screen":"Proposal assumptions","why":"Users and reviewers need to distinguish protocol draft behavior from account-specific recovery or key rules.","covers":["Frame type and account","Validation and fee path","Draft/network support"],"include":["Expandable section","Copy buttons","Explorer link"]}],"statesToDesign":[{"state":"Compatible draft path","trigger":"The target implementation reports support for the selected frame features.","userNeed":"Understand the account and fee behavior before signing.","designResponse":"Show frame action, account capability, fee path, and draft-stage label."},{"state":"Unsupported draft path","trigger":"The wallet, network, or account does not support the selected frame feature.","userNeed":"Know which current path remains available.","designResponse":"Explain support limits and offer a legacy or ERC-4337 fallback."},{"state":"Frame validation failed","trigger":"The account or implementation rejects the frame request.","userNeed":"Understand whether to retry or use another path.","designResponse":"Name the failed validation or capability and preserve fallback."},{"state":"Frame included","trigger":"The compatible network confirms the frame transaction.","userNeed":"See the action result and any account-state change.","designResponse":"Show the confirmed outcome separately from draft/proposal metadata."},{"state":"Fee or recovery limitation","trigger":"Alternate fee behavior, recovery, or key rotation is not supplied by the account implementation.","userNeed":"Avoid assuming the draft provides a missing feature.","designResponse":"Explain the account-specific limitation and offer a supported fallback."}],"designDecisions":[{"question":"How much protocol detail do users see?","recommendation":"Lead with outcomes; tuck identifiers behind review.","rationale":"Users decide on consequences, not function selectors."},{"question":"What happens when support is missing?","recommendation":"Block with explanation and fallback path.","rationale":"Silent failure feels like a broken product."},{"question":"How do you label Draft-stage behavior?","recommendation":"Show implementation, network, account, fee, and fallback assumptions before the user commits.","rationale":"The proposal may change and does not define universal recovery, key rotation, or production wallet support."}],"problemsSolved":[{"problem":"Native account-abstraction proposals are difficult to prototype consistently","oldWay":"Each implementation invents frame and fallback copy","newWay":"A compatible implementation can expose a labeled frame request and account capability state","impact":"high"},{"problem":"Draft support and account rules can be confused","oldWay":"A product presents recovery, key rotation, or alternate fees as protocol guarantees","newWay":"The UI separates proposal behavior from account implementation and current fallback","impact":"high"},{"problem":"Unsupported draft paths are hard to recover from","oldWay":"A frame request fails without naming network, account, or proposal support","newWay":"Mapped capability, validation, fee, and fallback states explain what to do next","impact":"medium"}],"uxPatterns":[{"name":"Frame Transaction Preview","description":"Preview a frame transaction while keeping the draft and account capability boundary visible.","components":["UnifiedFlow","CapabilityBadge"],"userFlow":["User connects a compatible account","App checks supported frame features","User reviews batched or alternative-fee action","App shows unsupported and fallback paths"]},{"name":"Migration Preview","description":"Help existing EOA users understand upcoming native AA.","components":["MigrationBanner","TimelineCard"],"userFlow":["User on legacy path","See a draft proposal and the account capabilities it would require","Compare the compatible frame path with today's account implementation","Choose an available fallback or leave the flow"]}],"antiPatterns":[{"pattern":"Presenting Draft behavior as production support","why":"EIP-8141 is a proposal and wallet/network implementations may not match its current design","instead":"Show implementation, network, account, and proposal assumptions before the primary CTA","severity":"critical"},{"pattern":"Promising recovery or key rotation from frame transactions alone","why":"Those behaviors require account logic and user setup beyond the frame envelope","instead":"Use outcome language with account-specific recovery and key disclosures","severity":"high"},{"pattern":"No current fallback when frame support is missing","why":"A Draft flow may be unavailable on the user's wallet or network","instead":"Explain the limitation and offer a supported legacy or ERC-4337 path","severity":"high"}],"vocabulary":[{"use":"Draft frame transaction","avoid":"Supported everywhere","why":"Label proposal and implementation scope without implying universal availability."},{"use":"Frame path unavailable","avoid":"Native AA failed","why":"Name the missing network, account, or implementation support."},{"use":"Use supported account path","avoid":"Upgrade automatically","why":"Frame transactions do not by themselves configure account recovery or key rotation."}],"technicalNotes":"EIP-8141 is a Draft frame-transaction proposal. Default code and frame validation do not establish a recovery policy for every account; recovery, guardians, and key rotation require compatible account logic and user setup. Keep production UI gated on finalized protocol and wallet support.","relatedStandards":[{"id":"EIP-7702","relationship":"Near-term bridge to smart account UX"},{"id":"ERC-4337","relationship":"Account-abstraction implementation option with a different integration model"}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-8141","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-8141","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-8141","markdown":"https://www.eipsfordesigners.com/standards/EIP-8141/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-8141/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-8141","official":"https://eips.ethereum.org/EIPS/eip-8141","discussion":"https://ethereum-magicians.org/search?q=EIP-8141"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}