Native Account Abstraction: State-of-Art and Pending Proposals (Q1/26)

This article has been written manually alongside AI assisted tools. The article has been manually reviewed for correctness.

TL;DR

Native account abstraction aims to bring gas sponsorship, batch transactions, passkey authentication, and post-quantum cryptography directly into the EVM protocol—without requiring bundlers or secondary mempools. Four proposals are actively being discussed:

Vitalik’s Proposal (EIP-7701)

Maximum generality. Arbitrary validation logic, transaction phases, all stretch goals covered. The “final answer” approach that aims to never need replacing.
Jump to section ↓

Tempo Transactions

Ship fast, solve today’s problems. Native passkeys, batching, scheduling, and ETH sponsorship. No custom validation—intentionally constrained to what users need now.
Jump to section ↓

EIP-8130: Account Configurations

Ship robust features fast. Constrained validation with programmable execution. Native multisig, token gas payments, and extensible key types.
Jump to section ↓

EIP-8141: Frame Transactions

Formal EF specification crystallizing EIP-7701 into a concrete spec. Transaction “frames” for validation and execution with full programmability.
Jump to section ↓

Bottom line: Tempo and EIP-8130 optimize for shipping quickly with bounded complexity. Vitalik’s proposal and EIP-8141 optimize for long-term flexibility and post-quantum readiness at the cost of more protocol complexity.


Account Abstraction

The Ethereum/EVM developer community has long sought to tackle the UX and usability challenges inherent to the EVM architecture. The most common desires are to enable:

  1. Paying for gas with ERC-20 tokens or allowing apps to sponsor gas for users
  2. Executing batch transactions
  3. Transaction authentication with Passkeys (or other signing schemes)
  4. Transaction scheduling and repeat transactions (subscriptions, trigger-based automation, etc.)
  5. Native multi-sig setups

While many other use cases fall under the broad term “account abstraction,” these are the most prevalent.

ERC-4337

The initial step toward Account Abstraction was ERC-4337—a standardized approach to gas abstraction, transaction sponsorship, batch execution, and more. Notably, ERC-4337 didn’t require hard forks or protocol changes.

ERC-4337 achieved this by having users adopt Smart Contracts as their accounts. These Smart Contracts followed a strict standard defined within the ERC and executed transactions through Bundlers and Paymasters. The ERC-4337 ecosystem was supported by many vendors—notably Biconomy, ZeroDev, Alchemy, Safe, Rhinestone, Ambire, and others.

The standard gained decent adoption, particularly among consumer-oriented fintech and neobank apps, but fell short of solving account abstraction fully.

Some of the core critiques of ERC-4337 have been:

  • Wallet Non-Portability: Despite standardization, wallets could not be “imported/exported” between apps. If an app deployed a ZeroDev account, that account could not trivially be used by an app built on the Biconomy account standard.
  • Secondary Mempool / Bundler Access: In ERC-4337, transactions depended on a secondary mempool or apps having direct access to an ERC-4337 Bundler. The secondary mempool introduced complexity, while requiring apps to maintain direct relationships with Bundlers introduced centralization risks.
  • Complexity: Because ERC-4337 aimed to allow arbitrarily complex validation logic, several DoS vectors emerged. A malicious actor could force Bundlers to run thousands of simulations and invalidate transactions before execution with a single transaction. This required ERC-4337 bundlers/mempool to implement complex state-access logic.
  • Gas Cost: Although this is becoming less of an issue, executing transactions through ERC-4337 came with significant gas overhead—partly due to complex Paymaster validation logic, partly because transactions were routed through a Smart Contract. While less problematic on L2s and cheaper L1s, this slowed adoption of ERC-4337 on Ethereum Mainnet.
  • Backwards Non-Compatibility: Since using an ERC-4337 account required deploying a smart contract, users could not keep their existing wallet address when migrating to the new account standard. They would have to move all assets to a new address—introducing migration friction and causing users to lose their wallet history.

EIP-7702

These critiques were not left unaddressed—the Ethereum Foundation introduced a new standard: EIP-7702.

EIP-7702 enabled users to convert their existing EOA into a Smart Account by delegating it to a Smart Account implementation. EIP-7702 directly addressed the issues of wallet non-portability (users can always re-delegate their EOA to a different implementation) and backwards non-compatibility (since users delegate their existing EOA, no history is lost).

However, the issues of secondary mempool, complex validation logic, and gas overhead remained.

EIP-7702 was provided by most ERC-4337 vendors (already listed), with the addition of having first-class support by some wallets (MetaMask, Trust, BitGet, Ambire) and non-4337 providers - notably Ithaca and Porto.

Honorary Mention: Elegant Backwards Compatibility for non-7702 EOA Wallets

Native Account Abstraction

Even before EIP-7702 was formalized, the Ethereum Foundation had plans to introduce Account Abstraction on the level of the protocol itself. This would allow standard Ethereum/EVM nodes to accept batch transactions, validate custom signing schemes (notably Passkeys) and allow users to pay for gas with ERC-20 tokens or for apps to sponsor gas for users.

An additional goal of native account abstraction is to enable protocol-level support for Post-Quantum cryptography and transaction privacy.

Lastly, the “constraint” of native account abstraction is that it must align with the scaling roadmap of Etehreum, notably partial-statelessnes (VOPS) and Inclusion Lists (FOCIL).

Currently, there are four active proposals to introduce a native version of Account Abstraction in EVM chains:

  • Vitalik’s Proposal
  • Tempo Transaction Proposal
  • EIP-8130 (From Coinbase/Base Team)
  • EIP-8141: Frame Transactions (Formal EF Specification)

The Mempool Problem

Before diving into the proposals, it’s worth understanding why native account abstraction is hard. The core challenge isn’t implementing new signature types or batching—it’s the mempool.

In traditional Ethereum, validating a transaction is cheap: check the signature (one elliptic curve operation), verify the nonce matches, confirm the account has enough ETH for gas. All of this can be done with simple state lookups. If a transaction is valid now, it stays valid until the account’s nonce or balance changes.

Account abstraction breaks this model. If validation can run arbitrary code, several problems emerge:

DoS via simulation: Before including a transaction, nodes must simulate it to check if it’s valid and will pay fees. With arbitrary validation logic, an attacker can craft transactions that pass simulation but fail on-chain (because some state changed between simulation and inclusion). The node wasted computation, and the attacker paid nothing.

Mass invalidation: Suppose validation logic reads from a shared contract—say, checking an oracle price or a global registry. A single transaction that updates that contract can instantly invalidate thousands of pending transactions in the mempool. Nodes have to re-simulate everything.

Griefing bundlers: In ERC-4337, bundlers aggregate multiple UserOperations into one transaction. A malicious user can craft a UserOperation that passes simulation but reverts during actual execution, wasting the bundler’s gas. Bundlers need complex reputation systems to protect themselves.

State access during validation: The more state validation can read, the more ways transactions can become invalid. If validation can read any storage slot, the invalidation surface is effectively unbounded.

This is why ERC-4337 introduced strict rules about what validation code can do: no reading external contracts (except your own), no environmental opcodes like TIMESTAMP or BLOCKHASH, limited gas. These rules make validation “local”—your transaction’s validity depends only on your own state.

The three proposals below take different approaches to this problem. Vitalik’s proposal embraces complexity and builds sophisticated mempool rules. Tempo and EIP-8130 sidestep it entirely by restricting validation to signature checks—no EVM execution until the transaction is already paid for.

Vitalik’s Proposal

Read the full proposal

In January 2026, Vitalik published a proposal outlining the path to full, native account abstraction. It defines two sets of goals:

Core Goals:

  • Alternative signature algorithms (including quantum-resistant ones)
  • Native multisig support
  • Key rotation and account upgrades
  • Privacy protocol withdrawals without intermediaries

Stretch Goals:

  • Gas payment with ERC-20 tokens (no off-chain actors needed)
  • Quantum-resistant signature aggregation
  • Keystore wallets (account state on L1, readable from L2s)
  • Private account abstraction (ZK-SNARKs for verification)
  • Post-assertions (revert if conditions aren’t met after execution)
  • Backwards compatibility with ERC-4337 and wallets like Safe

The proposal presents three approaches, each more powerful than the last:

Idea 1: Minimal AA

The simplest approach. Today, every Ethereum transaction is verified by checking an ECDSA signature—a fixed, unchangeable process baked into the protocol. Idea 1 replaces this with a smart contract call. Instead of the protocol verifying your signature directly, it calls your account’s code and lets that code decide if the transaction is valid.

Your account gets a small set of storage slots (0–15) where it can store public keys. This means you can rotate keys, add backup keys, or set up a basic multisig—all without changing addresses. The protocol adds these slots to the “VOPS” (the minimal state that all nodes must store), so validation stays fast and cheap.

The limitation: this approach is intentionally restricted. Validation can only read those 16 storage slots and nothing else. This keeps things simple and mempool-safe, but it means no privacy protocols, no gas sponsorship, and no backwards compatibility with existing smart wallets (which would need to rewrite their code to fit into 16 slots).

Idea 2: Privacy Extension

Builds on Idea 1 by adding a new type of storage called “2D nonces.” This storage is only accessible during the validation phase—the execution phase can’t touch it.

Why does this matter? Privacy protocols (like Tornado Cash or Railgun) need to track which notes have been spent. They do this with “nullifiers”—unique markers that prevent double-spending. With 2D nonces, a privacy protocol can act as a “multi-tenant account” where many users share one contract, each storing their nullifiers in this special validation-only storage.

The downside: if multiple users try to withdraw from the same privacy protocol simultaneously, the mempool might only let one through at a time. And like Idea 1, it’s not backwards-compatible with existing wallets.

Idea 3: No In-Protocol Restrictions

This approach removes the restrictions on what validation can access. Your account’s validation code can read any state it needs—other contracts, token balances, oracles, anything.

To make this work with FOCIL (the censorship-resistance mechanism) and statelessness (where most nodes don’t store the full state), transactions must include “witnesses”—cryptographic proofs of any state values they access outside the core VOPS. This adds ~4KB per external storage slot, but it’s manageable.

The tradeoff is the mempool. With unrestricted state access, a single transaction could invalidate thousands of other pending transactions by changing shared state. To handle this, Idea 3 relies on two mempool strategies:

  1. ERC-4337-style rules: Validation can only access “your own state”—your account’s storage, your token balances, etc. This guarantees your transaction stays valid until your state changes.

  2. Custom mempools: For advanced use cases (like gas sponsorship), apps can run their own mempools with custom rules. Proposers and FOCIL nodes can join whichever mempools they want.

Idea 3 covers all core goals and most stretch goals. The main limitation is developer experience—each advanced use case might need its own custom mempool.

EIP-7701: Full Generality

EIP-7701 is the most powerful option. It introduces the concept of transaction phases—distinct stages that execute in sequence, each with its own rules for what happens on success or failure.

A typical transaction might have five phases:

  1. Deployment: Deploy the account contract if it doesn’t exist yet
  2. Sender validation: Check the user’s signature
  3. Paymaster validation: A “paymaster” contract agrees to pay gas on the user’s behalf
  4. Execution: Do whatever the user actually wants to do
  5. Post-op: The paymaster calculates the final gas cost and takes payment (e.g., in USDC)

Each phase can specify: “if I fail, revert just me” or “if I fail, revert everything” or “if I fail, the transaction can’t be included at all.” This flexibility enables complex flows that were previously impossible without off-chain intermediaries.

For example: you have 100 USDC and no ETH. You want to send 10 USDC to a friend. With EIP-7701, you can do this in one transaction—a paymaster contract (essentially an on-chain AMM) fronts the ETH for gas, executes your transfer, then takes USDC as payment. No bundlers, no relayers, no trusted third parties.

EIP-7701 also enables “post-assertions”—checks that run after execution to verify the transaction did what you expected. If your token balance doesn’t match what you anticipated, the execution reverts (but you still pay gas, so it’s mempool-safe).

Note from the author: Post-assertions can technically be achieved without EIP-7701 by encoding an atomic batch with the assertion as the final call. If the assertion fails, the entire batch reverts. However, EIP-7701 formalizes this pattern at the protocol level with cleaner semantics and better tooling support.

The cost is complexity. EIP-7701 is a more involved protocol change, and the mempool rules become more sophisticated. But it covers every goal—core and stretch—and provides a foundation flexible enough for use cases we haven’t imagined yet.

Vitalik’s Recommendation

Anything less than Idea 3 isn’t worth the effort. Between Idea 3 and EIP-7701, it’s a tradeoff of complexity vs. generality.

His approach: ship the protocol changes soon, but roll out mempool features gradually. Start restrictive (like ERC-4337 rules), then expand as developers gain confidence.

The key insight: most complexity lives in the mempool, not the protocol. Getting protocol changes in early gives the ecosystem time to mature.

Arguments for Full Generality (Nicolas Consigny)

ZkEVM Compatibility

Ethereum’s roadmap includes transitioning to a ZkEVM architecture where provers generate cryptographic proofs of block execution instead of validators re-executing every transaction. This is the “lean” project—progress tracked at ethproofs.org.

For this to work, the proving system must handle every operation in Ethereum, including validation. If validation is constrained to fixed operations (like Tempo’s specific signature types), the prover only handles those cases—but Ethereum loses the ability to add new signature schemes or validation patterns without hard forks. EIP-7701’s arbitrary validation aligns with ZkEVM’s need for a general-purpose prover. The alternative is repeated protocol changes every time cryptographic standards evolve.

Post-Quantum Flexibility

Current Ethereum cryptography (ECDSA on secp256k1, P-256) is vulnerable to quantum computers running Shor’s algorithm. Industry consensus suggests P-256 hardware may be obsolete by 2027-2028, replaced by post-quantum schemes like ML-DSA (lattice-based) or SPHINCS (hash-based).

Efficient post-quantum signature aggregation requires recursive STARK proofs—proofs that verify batches of other proofs. This only works if the proving system can handle arbitrary validation logic. With EIP-7701, new post-quantum schemes can be deployed as smart contract validation without protocol changes. With fixed validation (Tempo, EIP-8130), each new signature algorithm requires a hard fork. Given the uncertainty around which post-quantum schemes will win, flexibility is valuable.

Tempo Transactions

Read the full proposal

Tempo is a different philosophy. Instead of building a general-purpose framework that can handle any future use case, it asks: what are the specific UX problems users face today, and what’s the minimal protocol change to fix them?

The proposal introduces a new transaction type that bundles a constrained set of features:

  • Atomic batching: Multiple calls in one transaction—if any fails, all revert
  • Validity windows: Transactions can have “valid after” and “valid before” timestamps for scheduling and expiration
  • Gas sponsorship: An optional “fee payer” can cover gas costs
  • 2D nonces: Parallel nonce streams so transactions don’t have to wait in line
  • Multiple signature schemes: Native support for secp256k1, P-256, and WebAuthn (passkeys)
  • Access keys: Protocol-enforced sub-keys with expiry and spending limits

What Tempo Explicitly Doesn’t Do

The proposal is clear about its boundaries:

  • It does not replace ERC-4337 or its mempool model
  • It does not provide arbitrary validation logic (no custom code deciding if a transaction is valid)
  • It does not introduce native ERC-20 fee payment—sponsors wanting token reimbursement must include explicit calls in the transaction to pay themselves back
  • It does not define a universal permissions system

The goal is a narrow, reviewable set of primitives. Complex use cases still need smart contract wallets or EIP-7702 delegation.

Native Passkey Support

This is Tempo’s headline feature. Today, using passkeys (WebAuthn) with Ethereum requires ERC-4337: you create a UserOperation, a bundler packages it into a real transaction, and that transaction calls the EntryPoint contract. You can’t just sign a transaction with your passkey and submit it directly.

Tempo changes this. A Tempo transaction can be signed directly with a P-256 key (the cryptography passkeys use) or with full WebAuthn authentication data. No bundler, no EntryPoint, no intermediaries. The protocol itself understands these signatures.

The transaction includes the signature type in its encoding:

  • secp256k1 (65 bytes): Standard Ethereum signature
  • P-256 (130 bytes): Raw P-256 signature with public key
  • WebAuthn (variable, up to 2KB): Full passkey authentication including authenticator data and client data JSON

For P-256 and WebAuthn, the sender address is derived from the public key: keccak256(pubkey_x || pubkey_y) truncated to 20 bytes.

Gas Sponsorship

Tempo includes an optional fee_payer_signature field. If present, gas fees are charged to the fee payer instead of the sender.

The fee payer signs a slightly different message than the sender (with a different magic byte for domain separation), which includes the sender’s address. This prevents replay attacks where a fee payer signature gets attached to a different transaction.

Important: fee payer signatures must be secp256k1. This keeps validation simple and bounded.

The protocol doesn’t handle token reimbursement. If a sponsor wants to be paid back in USDC, they should only co-sign transactions that include an explicit transfer paying them. This is verified off-chain before signing—the protocol just executes the calls.

2D Nonces

Traditional Ethereum accounts have a single nonce that increments with each transaction. This means transactions must be processed in order—if transaction #5 is stuck, transactions #6, #7, #8 all wait.

Tempo introduces “nonce keys.” Each key has its own independent nonce stream:

  • nonce_key = 0: Uses the standard account nonce (backwards compatible)
  • nonce_key > 0: Uses a separate counter for that key

This lets you send multiple transactions in parallel without them blocking each other. An app could use one nonce key for swaps, another for transfers, another for governance votes—each operating independently.

Validity Windows

Transactions can specify:

  • valid_after: Don’t include this transaction until after this timestamp
  • valid_before: Don’t include this transaction after this timestamp

This enables scheduled transactions (execute tomorrow at noon) and expiring transactions (this swap is only valid for 5 minutes). The mempool holds transactions until they become valid and drops them when they expire.

Access Keys

The proposal references a companion EIP for “access keys”—sub-keys with restricted permissions. A user could create an access key that:

  • Can only spend up to 0.1 ETH per day
  • Expires after 30 days
  • Can only interact with a specific contract

The main account creates these keys, and transactions signed by an access key use a “keychain wrapper” signature format that identifies which access key is being used. The protocol validates the key’s permissions before execution.

The Tradeoff

Tempo deliberately avoids generality. It won’t handle every possible use case—privacy protocols, fully custom validation, programmable post-conditions all remain outside its scope.

But for the specific problems it targets—passkeys, batching, scheduling, sponsorship—it offers a clean solution with minimal protocol complexity. Transactions are statically analyzable. Gas costs are predictable. The mempool doesn’t need new rules beyond basic validity checks.

Vitalik’s take: Tempo solves a different problem. It’s great for standardizing common UX patterns, but it doesn’t address the long-term goals of full account abstraction (quantum resistance, privacy, key rotation). Ethereum could adopt both—Tempo for everyday transactions, EIP-7701 for advanced use cases—but they serve different purposes.

EIP-8130: Account Configurations

Read the full proposal

EIP-8130 takes a middle path between Tempo’s constrained primitives and EIP-7701’s full generality. The core insight: most complexity in account abstraction comes from validation. Restrict validation to fixed key types, let execution remain fully programmable, and you get most benefits without mempool complexity.

Validation vs. Execution

This distinction is key to understanding EIP-8130.

Validation answers: “Is this transaction authorized?” It happens before gas is spent. In EIP-8130, this means checking signatures against the account’s registered keys—a simple state lookup, no EVM execution. If validation fails, the transaction is rejected immediately, never entering the mempool.

Execution is everything else: your smart wallet logic. It happens after gas payment is secured. The calldata arrives as a self-call to your address (to = msg.sender = tx.origin = your address).

For EOAs without code, this does nothing—the call succeeds and that’s it. For smart accounts, your contract interprets the calldata however you want:

  • Decode it as a batch of calls and execute sequentially
  • Check spending limits before allowing transfers
  • Implement timelocks, session keys, or any other logic

The protocol handles “who can submit.” Your code handles “what can be done.”

Account Configuration Precompile

Each account registers authorized keys in the Account Configuration Precompile. Only the account itself can modify its own configuration. The protocol reads these keys directly during validation—no EVM needed.

Key types supported:

  • K1 (secp256k1): Standard Ethereum ECDSA
  • R1 (secp256r1/P-256): The curve passkeys use
  • WebAuthn: Full passkey authentication
  • BLS: BLS12-381 signatures (enables aggregation for rollups)
  • DELEGATE: Points to another account’s configuration (one hop only)

An empty configuration means only the EOA key works. The EOA key always retains authorization regardless of other keys—this ensures you can always recover the account.

Native Multisig

EIP-8130 includes protocol-level multisig. Set a required_signatures threshold, and the protocol validates that enough distinct keys signed before any code runs.

A 2-of-3 multisig signature is just two signatures concatenated. The protocol parses them, verifies each against the account’s configuration, checks for duplicates, and confirms the threshold is met. No smart contract overhead, no EntryPoint calls.

2D Nonces

Like Tempo, EIP-8130 supports parallel nonce streams via a nonce_key field. Each key has its own independent counter. The first use of a new nonce key costs 20,000 gas to initialize; after that, transactions on different nonce keys don’t block each other.

Token Payments for Gas

This is where EIP-8130 gets more ambitious than Tempo. Instead of just ETH sponsorship, it includes a full token payment system with three modes:

  • Permissioned payer: Sponsor signs each transaction, agreeing to the specific exchange rate
  • Permissionless payer: Registered payers configure per-token oracles; users set max_amount for price protection
  • Native payer: Chain-operated AMM with chain-defined pricing

Tokens must be registered in a Token Payment Registry (balance slot location, decimals, blocklist method). Token transfers happen before execution, outside the EVM—the protocol reads balances directly from storage, verifies blocklist status, and updates balances atomically. Your wallet code receives calldata knowing gas is already paid.

Why per-payer oracles instead of a global oracle? No governance debates about which oracle is canonical, bad oracles only affect that payer’s users, payers can offer promotional rates, and discovery happens at the wallet layer. The max_amount field provides hard protection—if the cost exceeds your limit, the transaction fails.

Migration & Context

Existing ERC-4337 accounts migrate without redeploying:

  1. Register existing signing keys in the precompile
  2. Update contract to read keys from the precompile
  3. Use getCurrentSigner() during execution to know which key authorized the transaction

During execution, contracts can query the precompile for context: which key signed, who paid for gas, how much token was transferred. This enables authorization decisions based on which key was used, without duplicating signature verification.

The Tradeoff

What you get:

  • Simple, optimizable mempool (just state lookups)
  • Native multisig without smart contract overhead
  • Full token payment system with competitive payer market
  • Extensible key types (quantum-safe algorithms can be added later)

What you don’t get:

  • Arbitrary validation logic (no custom code deciding if a transaction is valid)
  • Privacy protocols that need validation-phase state access
  • Post-assertions or conditional execution

EIP-8130 sits between Tempo and EIP-7701—more flexible than Tempo (native multisig, token payments, extensible keys), simpler than EIP-7701 (bounded, predictable validation).

Reduced Scope Variant

A reduced scope version of EIP-8130 has also been proposed, stripping the proposal down to its essentials for faster shipping. The core philosophy remains—constrained validation, programmable execution—but two major features are moved out of protocol scope:

No Native Multisig: Instead of protocol-level threshold validation, multisig lives entirely in wallet code. Smart Account contracts can validate other signers within the contract code itself, but the implementation of this is not part of the spec. During execution, the mulit-sig contract can call getCurrentSigner() to get the protocol-level key and then have its own logic for retrieving and validating the rest of the keys.

No ERC-20 Token Payments: Gas sponsorship is ETH-only. A sponsor signs each transaction they’re willing to pay for—explicit authorization per transaction rather than oracle-based token conversion. The specification reserves an extensions field for future EIPs to add token payments, but the initial version ships without it.

The reduced scope variant is faster to ship and simpler to implement, but wallets wanting multisig or token gas payments must handle them in their own code rather than relying on protocol support. For chains prioritizing rapid deployment of core AA features, it’s a pragmatic starting point that can be extended later.

EIP-8141: Frame Transactions (January 29th Update)

Read the full proposal

Just days after the initial proposals were being debated, the Ethereum Foundation formally published EIP-8141—a crystallization of Vitalik’s EIP-7701 vision into a concrete specification. Frame Transactions represent the “full generality” path, providing a native off-ramp from ECDSA cryptography to arbitrary signature schemes, including post-quantum systems.

Philosophy

EIP-8141 asks a different question than Tempo or EIP-8130. Instead of “what specific features do users need today?”, it asks “what primitives would let developers build any feature users might need?”

The answer is a transaction model where validation and execution are fully programmable. A transaction becomes a sequence of “frames”—some that validate (who authorized this?), some that execute (what should happen?). The protocol enforces ordering (validation before execution) but doesn’t constrain what the validation or execution logic can do.

This is the “walk-away” design: once shipped, Ethereum shouldn’t need hard forks to add new signature schemes, new gas payment methods, or new transaction patterns. The EVM itself becomes the extension mechanism.

What It Enables

Any Signature Scheme: Accounts can validate transactions using any cryptographic system—ECDSA today, ML-DSA (post-quantum) tomorrow, ZK proofs for privacy, or schemes that don’t exist yet. No protocol upgrade required.

Native Gas Sponsorship: A sponsor can agree to pay for a transaction by adding their own validation frame. The protocol ensures the sponsor only pays if their conditions are met (e.g., the user transfers them tokens). No bundlers, no relayers, no trusted intermediaries.

Trustless ERC-20 Gas Payment: Building on sponsorship, a user can pay for gas in USDC without any off-chain coordination. The transaction structure guarantees the sponsor gets paid before the user’s call executes—enforced by the protocol, not by trust.

Account Deployment in One Transaction: A user can deploy their smart account and execute their first transaction atomically. The deployment frame runs first, then the validation frame (now that the account exists), then the execution.

Privacy Protocol Support: Privacy systems like Tornado Cash or Railgun need to verify ZK proofs during validation. Frame Transactions allow arbitrary validation logic, so these proofs can be verified natively without bundler infrastructure.

Future-Proof Extensibility: Signature aggregation, keystore wallets, post-assertions—features that haven’t been fully designed yet can be built on this foundation without protocol changes.

DoS Vectors and Mitigations

Frame Transactions reintroduce the core mempool challenge: if validation runs arbitrary code, attackers can craft transactions that pass validation initially but become invalid later, wasting node resources.

The Attack: An attacker submits thousands of transactions whose validation depends on some shared state (e.g., checking block.timestamp < deadline). When the deadline passes—or when the attacker modifies the shared state—all transactions become invalid simultaneously. Nodes wasted computation validating and storing them.

Mitigation 1: Validation Restrictions. The specification recommends treating validation frames like ERC-7562 treats ERC-4337 validation: restrict which opcodes can run, limit which storage slots can be read, cap gas consumption. This makes validation “local”—your transaction’s validity depends only on your own state, not shared state that others can modify.

Mitigation 2: Bounded Validation. Validation frames must explicitly succeed (via the APPROVE opcode) before a transaction enters the mempool. Nodes can reject transactions whose validation fails or exceeds limits before propagating them to peers.

Mitigation 3: One Pending Transaction Per Account. Like EIP-7702, nodes can limit each account to one pending frame transaction. This bounds the damage from invalidation—at most one transaction per attacker account gets evicted.

Mitigation 4: Known Deployer Factories. For transactions that deploy the account in-flight, mempools only accept deployments from whitelisted factory contracts. This ensures deployment is deterministic and doesn’t depend on manipulable chain state.

The key insight: the protocol provides full generality, but mempools can impose stricter rules. Advanced use cases (custom validation, exotic signatures) might require direct submission to block builders rather than public mempool propagation.

The Tradeoff

What you get:

  • Full generality—any signature scheme, any validation logic, any gas payment method
  • Native post-quantum support without future hard forks
  • No external infrastructure (bundlers, relayers) required for basic use cases
  • Foundation flexible enough for use cases that don’t exist yet

What you give up:

  • Protocol complexity—new opcodes, new transaction type, frame semantics
  • Mempool complexity—nodes need sophisticated validation rules to prevent DoS
  • Higher base costs than simpler alternatives (15,000 gas intrinsic vs. ~21,000 for legacy, but with more overhead per frame)
  • Steeper learning curve for wallet developers compared to fixed-feature approaches

EIP-8141 is the “final answer” approach. It doesn’t solve specific UX problems directly—it provides primitives powerful enough to solve any UX problem. The cost is complexity that must be managed through tooling, standards, and careful mempool implementation. For Ethereum’s long-term evolution, especially post-quantum readiness and ZkEVM compatibility, this generality may be necessary regardless of short-term costs.

Philosophy

Vitalik’s Proposal (EIP-7701) optimizes for maximum generality and robustness. The goal is to pass the “walk-away test”—building a framework so complete that Ethereum won’t need constant hard forks to add new transaction features as new use cases emerge. It aims to be the “final answer” to account abstraction, flexible enough to handle use cases we haven’t imagined yet. The cost is complexity: sophisticated mempool rules, multiple transaction phases, and more protocol surface area.

Tempo optimizes for speed of shipping. The industry needs better UX now—users are struggling with gas, signatures, and transaction complexity today. Tempo picks specific problems (passkeys, batching, scheduling, sponsorship) and solves them with minimal protocol changes that can ship quickly. No custom validation, no token payments at the protocol level, no multisig—just the primitives needed to unblock the most common pain points.

EIP-8130 optimizes for shipping robust features fast. Like Tempo, it recognizes that users need better UX now and the industry can’t wait years for the perfect solution. But it’s more ambitious: native token payments, multisig, and extensible key types—features that matter for real-world wallet adoption. By constraining validation to fixed key types, it keeps mempools simple enough to ship quickly while still delivering meaningful capabilities. A reduced scope variant trades some features (protocol-level multisig and token payments) for even faster shipping.

EIP-8141 (Frame Transactions) is the formalization of EIP-7701 vision into a concrete, implementable specification. It represents the Ethereum Foundation’s commitment to the full generality path—arbitrary validation logic, post-quantum readiness, and no artificial constraints on what accounts can do. The frame model provides structure (validation before execution, explicit approval semantics) without sacrificing power. Where Tempo and EIP-8130 ask “what do users need today?”, EIP-8141 asks “what will users need for the next decade?” The tradeoff is clear: more protocol complexity and stricter mempool requirements, but a foundation that won’t need replacing as cryptography evolves and new use cases emerge.

Complementary: EIP-7851 (Deactivating EOA Keys)

Read the full proposal

While the proposals above focus on enabling new transaction capabilities, EIP-7851 addresses a different concern: permanently disabling an EOA’s ECDSA private key after migrating to a smart account via EIP-7702.

The motivation is post-quantum security. Once quantum computers become viable, ECDSA keys will be vulnerable to Shor’s algorithm. Users who have migrated to smart accounts with quantum-resistant validation (enabled by EIP-7701/8141 or constrained schemes in Tempo/EIP-8130) would still have their old ECDSA key as a backdoor. EIP-7851 lets them close that door permanently.

The mechanism is a precompile that appends a marker byte to the delegated code, signaling to the protocol that the EOA key is deactivated. A 7-day delay period allows cancellation via an ECDSA-signed transaction—providing a safety window against unauthorized deactivation.

Current Limitations: EIP-7851 only prevents on-chain ecrecover from working for deactivated keys. It does not invalidate off-chain signatures. Contracts using ERC-2612 permit, ERC-712 typed signatures, or other off-chain signing patterns will still accept signatures from deactivated keys unless they explicitly check the account’s deactivation status. This is a known gap—the proposal requires a companion EIP to modify ecrecover behavior for full protection.

EIP-7851 is complementary to the native AA proposals rather than competing with them. It solves the “legacy key” problem that remains after users migrate to smart accounts, regardless of which AA approach is adopted.