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

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:

Paying for gas with ERC-20 tokens or allowing apps to sponsor gas for users
Executing batch transactions
Transaction authentication with Passkeys (or other signing schemes)
Transaction scheduling and repeat transactions (subscriptions, trigger-based automation, etc.)
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 three 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)

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:

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.
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:

Deployment: Deploy the account contract if it doesn’t exist yet
Sender validation: Check the user’s signature
Paymaster validation: A “paymaster” contract agrees to pay gas on the user’s behalf
Execution: Do whatever the user actually wants to do
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:

Register existing signing keys in the precompile
Update contract to read keys from the precompile
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. During execution, contracts call getCurrentSigner() to identify which key authorized the transaction, then verify additional co-signer signatures from the calldata before executing operations. This keeps validation simple (single signature check) while still enabling any multisig scheme (m-of-n, weighted, time-delayed) at the smart contract layer.

No Native 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.

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.