Account Abstraction

Live on-chain usage, the proposal family, native-AA work, and related calls

History and genealogy

How Ethereum accounts became programmable

Every major account abstraction proposal in one place, from EIP-86 in 2017 to EIP-7702 shipping in Pectra, plus the native AA work now in draft. Scoped to account abstraction; unrelated network upgrades are left out. Every proposal links to its full page.

Timeline Family tree

Timeline

Account abstraction proposals, and the infrastructure that made them possible.

2017

EIP-86: Abstraction of transaction origin and signature

StagnantEIP-86

Core · Proposed Feb 2017 · Vitalik Buterin

The first proposal to move signature and nonce checks out of the protocol and into account contracts.

Why it matters: The origin of account abstraction: the account, not the protocol, should decide what makes a transaction valid.

2020

EIP-2938: Account Abstraction

WithdrawnEIP-2938

Core · Proposed Sep 2020 · Buterin, Dietrichs, Garnett, Villanueva, Wilson

The first attempt to make account abstraction a protocol-native transaction type, using new PAYGAS and NONCE opcodes.

Why it matters: Surfaced the hard problems (mempool denial of service, paying gas before validation runs) that shaped every later design.

2020

EIP-3074: AUTH and AUTHCALL opcodes

WithdrawnEIP-3074

Core · Proposed Oct 2020 · Wilson, Dietrichs, Garnett, Zoltu

Two EVM opcodes letting an EOA authorize an invoker contract to batch and sponsor actions on its behalf.

Why it matters: The main pre-Pectra plan for upgrading EOAs. Debated for years, then withdrawn in favor of EIP-7702.

2021

ERC-4337: Account Abstraction Using Alt Mempool

On mainnetFinalERC-4337

ERC · Final · Proposed Sep 2021 · Live on mainnet since 2023

Account abstraction with no consensus change, using UserOperations, an alternative mempool, Bundlers, Paymasters, and a shared EntryPoint contract.

Why it matters: Made smart-account wallets (passkeys, sponsored gas, batching) usable on mainnet without a hard fork.

2022

EIP-5792: Wallet Call API

FinalEIP-5792

Interface · Final · Proposed Oct 2022

Standard wallet RPC methods (wallet_sendCalls, wallet_getCapabilities) for batched calls and capability discovery.

Why it matters: Lets a dApp use account abstraction features without knowing how the wallet implements them.

2024

EIP-7702: Set Code for EOAs

On mainnetFinalEIP-7702

Core · Final · Proposed May 2024 · Live in Pectra (2025)

A type 0x04 transaction that sets a delegation indicator on an EOA, pointing it at contract code. The account keeps its address and key, and the delegation stays until it is replaced or cleared.

Why it matters: The path that shipped: existing accounts gain batching and gas sponsorship with no migration to a new address.

2025

EIP-8130: Keystore Accounts

DraftEIP-8130

Core · Draft · Proposed Oct 2025

A new transaction type plus an on-chain account configuration with explicit authenticators.

Why it matters: Native account abstraction with validation cost a node can predict without running arbitrary wallet code.

2026

EIP-8141: Frame Transaction

DraftEIP-8141

Core · Draft · Proposed Jan 2026

A native transaction type that splits a transaction into frames: separate calls that validate, approve payment, then execute.

Why it matters: The current native AA direction. EIP-7701 was withdrawn in its favor.

2026

EIP-8202: Scheme-Agile Transactions

DraftEIP-8202

Core · Draft · Proposed Mar 2026

A type 0x05 transaction combining an EIP-1559 fee header with swappable signature schemes and typed extensions.

Why it matters: Carries EIP-7702-style set-code authorizations and pluggable auth schemes in one composable format.

Family tree of AA proposals

One origin idea, three approaches to the same goal. Every proposal links to its page.

EIP-86Stagnant

Abstract the account

The 2017 origin idea: let account logic decide transaction validity.

Off-protocol

No consensus change. AA lives in smart contracts and an alternative mempool.

ERC-4337

On mainnetFinal

Alt-mempool AA

UserOps, Bundlers, Paymasters, EntryPoint.

EIP-5792

Final

Wallet Call API

Standard dApp to wallet batch calls.

On existing EOAs

Give the accounts people already have smart-account behavior.

EIP-3074

Withdrawn

AUTH / AUTHCALL

Invoker-based batching for EOAs. Superseded by EIP-7702.

EIP-7702

On mainnetFinal

Set code for EOAs

Type 0x04: an EOA runs contract code. Live in Pectra.

EIP-8202

Draft

Scheme-Agile tx

Type 0x05 carrying EIP-7702-style auth.

In-protocol (native)

A new transaction type with validation built into the protocol.

EIP-2938

Withdrawn

Account Abstraction

First native attempt, using PAYGAS.

EIP-7701

Withdrawn

Native Account Abstraction

Validation and execution phases. Withdrawn for EIP-8141.

EIP-8141

Draft

Frame Transaction

Frame-based successor to EIP-7701.

EIP-8130

Draft

Keystore Accounts

A separate native design: on-chain config and explicit authenticators.

Transaction types on mainnet

Every typed transaction family. Account abstraction added type 0x04 (EIP-7702); a proposed 0x05 (EIP-8202) would carry the same set-code authorization.

Tx type	EIP	Transaction	Introduced
Legacy	Pre-EIP-2718	Legacy RLP transaction	Frontier
0x01	EIP-2930	Access list	Berlin
0x02	EIP-1559	Dynamic fee	London
0x03	EIP-4844	Blob-carrying	Dencun
0x04	EIP-7702	Set code (EOA delegation)Account abstraction	PectraFinal
0x05	EIP-8202	Scheme-agileAccount abstraction	ProposedDraft

EIP-2718 is not a transaction type. It is the Typed Transaction Envelope (Berlin, 2021) that added a leading type byte so new formats could be introduced without breaking old clients. Legacy transactions predate it; every type above (0x01 to 0x05) is defined as a new EIP-2718 transaction type.

Three ways to get a smart account

Plain EOA

Since 2015

Auth: Fixed ECDSA key pair
Gas: Paid in native ETH
Code: None (empty account)

Limit: One key. Lose it and funds are gone. No batching or sponsorship.

ERC-4337 smart account

Live 2023

Auth: Passkeys, multisig, session keys
Gas: Sponsored or paid in ERC-20
Code: Custom contract deployed on chain

Trade-off: A new contract address. It does not upgrade an existing EOA.

EIP-7702 delegated EOA

Live 2025

Address: Keeps the original EOA
Auth: ECDSA plus delegated contract code
Gets: Batching and gas sponsorship

Result: An existing account becomes a smart account with no migration.

Why it took so long: the validation problem

Ethereum checks that a transaction is valid before it executes it. If verifying a signature required running arbitrary contract code, an attacker could flood the mempool with transactions that burn work and then turn out invalid. Every AA design is an answer to this one constraint.

Cheap validation

Nodes must reject invalid transactions without spending uncompensated compute.

Guaranteed payment

Something must guarantee gas before validation code runs.

Stable mempool rules

Validity cannot depend on state that changes within a block.

How the three approaches compare

Property	ERC-4337	EIP-7702	Native (EIP-8141)
Formal status	Final (ERC)	Final (Core)	Draft
Live on mainnet	Yes, since 2023	Yes, since Pectra (2025)	Not yet
Consensus change	None	Pectra (shipped)	Future fork
Works on your existing account	No, a new contract	Yes, same EOA	Yes
Transaction format	UserOperation (alt mempool)	Type 0x04	Frame-based tx
Needs bundler or EntryPoint	Yes	No, a direct L1 tx	No, native builders
Custom validation (passkeys, multisig)	Yes	Yes, via delegated code	Yes
Gas sponsorship	Paymaster	Sponsor tx	Native
Atomic batching	Yes	Yes	Yes

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.