Charting The Ethereum Account Abstraction Roadmap I: EIP-3074, EIP-5806, and EIP-7702

Account abstraction is one of the most transformative concepts on Ethereum’s evolutionary path. As the network moves toward its next major hardfork, Pectra, developers are intensifying efforts to redefine how users interact with the blockchain. At the heart of this transformation lies the effort to bridge the gap between Externally Owned Accounts (EOAs) and Contract Accounts (CAs)—unlocking new levels of flexibility, security, and user experience.

This article explores the current state of Ethereum account abstraction, focusing specifically on EOA programmability through three key Ethereum Improvement Proposals: EIP-5806, EIP-3074, and EIP-7702. We’ll examine their technical designs, potential use cases, limitations, and how they shape the future of transacting on Ethereum and its Layer 2 ecosystems.

Understanding Ethereum Accounts and Transaction Validity

To appreciate the significance of account abstraction, we must first understand Ethereum’s foundational account model.

Every Ethereum account has four core fields:

• nonce: Prevents replay attacks by tracking transaction count.
• balance: Stores the account’s ETH holdings in wei.
• codeHash: For contract accounts, this points to executable EVM code.
• storageHash: A Merkle root representing persistent storage data.

There are two types of accounts:

1. Externally Owned Accounts (EOAs)

Controlled by private keys, EOAs are user-facing and used for signing transactions. They have no associated code (codeHash is empty) and can only initiate transactions directly. Their simplicity makes them easy to use but limits functionality.

2. Contract Accounts (CAs)

Created by EOAs deploying smart contracts, CAs contain executable logic and respond to incoming calls. While highly programmable, they lack autonomy—they cannot self-initiate actions.

👉 Discover how next-gen wallet architectures are redefining user control on Ethereum.

The Core Parameters of Transaction Validity

Each transaction must satisfy a set of validity rules governed by five logical components:

1. Authentication Logic: Proving identity via digital signatures (ECDSA for EOAs).
2. Authorization Logic: Defining who can trigger actions.
3. Nonce Logic: Ensuring sequential execution.
4. Gas Payment Logic: Determining who pays gas fees.
5. Execution Logic: Dictating what actions an account can perform.

Currently, EOAs follow rigid rules across all parameters—offering autonomy but minimal programmability. CAs, in contrast, are highly flexible in execution but require external triggers.

This tradeoff creates what’s known as Ethereum’s account dilemma: full autonomy or full programmability—but not both.

What Is Account Abstraction?

Account abstraction aims to dissolve this dichotomy by enabling any account to redefine its validity rules. In essence, it allows users to customize how their transactions are validated and executed—paving the way for features like:

• Gasless transactions
• Batched operations
• Conditional logic
• Social recovery
• Multi-signature security

Our framework classifies account abstraction approaches into three categories:

1. EOA Programmability – Enhancing EOAs with limited smart contract capabilities.
2. EOA Migration – Converting EOAs into full contract accounts without asset movement.
3. Smart Accounts – Enshrining native support for fully customizable accounts.

In this article, we focus on EOA programmability, evaluating EIPs that aim to supercharge traditional wallets while maintaining backward compatibility.

EIP-5806: Enabling Delegate Calls for EOAs

EIP-5806 introduces a new transaction type that allows EOAs to make DELEGATECALLs—executing logic from a contract while preserving the EOA’s context (sender and value).

Key Specifications

The proposal adds an EIP-2718-compliant transaction format:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s])

This enables EOAs to:

• Execute external logic securely
• Perform multicall operations (e.g., approve + transfer)
• Enable conditional execution flows

However, to preserve network invariants, certain opcodes are restricted:

• SSTORE: Prohibited to prevent storage manipulation
• CREATE, CREATE2, SELFDESTRUCT: Disabled during delegate calls to avoid nonce confusion

Use Cases

• Trustless interaction with DeFi protocols
• Transaction batching without wallet migration
• Atomic swaps across multiple contracts

Criticisms

While simple and backward-compatible, EIP-5806 offers only execution abstraction—it doesn’t modify authentication, authorization, or gas payment logic. Critics argue its benefits may not justify protocol-level changes.

EIP-3074: Delegating Control via AUTH and AUTHCALL

EIP-3074 proposes two new EVM opcodes—AUTH and AUTHCALL—to allow EOAs to delegate control to trusted contracts called invokers.

How It Works

1. An EOA signs a message authorizing an invoker contract.
2. The AUTH opcode verifies the signature and sets the authorized context.
3. AUTHCALL executes calls on behalf of the EOA using the invoker’s logic.

This decouples tx.origin (signer) from msg.sender (executor), enabling advanced features like:

• Sponsored transactions (gas paid by relayers)
• Nonce parallelism (multiple concurrent transactions)
• Custom validation rules

Potential Applications

• Gas sponsorship for dApp onboarding
• Enterprise wallet management
• Cross-application automation

Drawbacks

Despite its power, EIP-3074 faces criticism:

• Invoker centralization risk: Users may rely on a few audited invokers, creating trust bottlenecks.
• Forward compatibility issues: Ties Ethereum to ECDSA, potentially complicating future quantum-resistant upgrades.
• Security fragility: Loss of private keys revokes all delegated permissions irreversibly.

👉 See how decentralized identity models could integrate with upgraded EOAs.

EIP-7702: Smart Behavior Without Permanent Conversion

EIP-7702 builds on EIP-3074’s vision but improves safety and compatibility. It introduces a new transaction type—SET_CODE_TX_TYPE—that temporarily equips an EOA with contract-like behavior by setting its code to point to another account’s logic.

Technical Overview

The transaction format includes an authorization list:

rlp([chain_id, nonce, ..., data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Each entry in the authorization_list specifies:

[chain_id, address, nonce, y_parity, r, s]

Upon validation:

1. Signature is verified using ecrecover.
2. Chain ID prevents cross-chain replay.
3. Nonce is checked for consistency.
4. The EOA’s codeHash is updated to reference the target contract.
5. The nonce increments only after successful setup.

This mechanism allows EOAs to temporarily become smart accounts, executing complex logic without permanent migration.

Advantages Over EIP-3074

• Fully compatible with ERC-4337 and future native account abstraction (RIP-7560)
• Avoids persistent delegation risks
• Enables richer execution environments

Use Cases

• Conditional access policies (e.g., spending limits per dApp)
• Cross-chain deployments using CREATE2
• Self-custodial relayer integration

Criticisms

Despite its promise, EIP-7702 raises concerns:

• Breaks backward compatibility: Allows EOAs with non-zero codeHash to initiate transactions—violating EIP-3607 safeguards against address collision attacks.
• Cross-chain inconsistency risk: Same address may point to different logic on different chains, increasing spoofing potential.

Frequently Asked Questions (FAQ)

Q: What is account abstraction in simple terms?
A: Account abstraction lets users customize how their transactions are validated—enabling features like gasless transactions, batch operations, and social recovery—without losing control of their funds.

Q: Why not just switch everyone to smart contract wallets?
A: While possible via ERC-4337, mass migration faces UX and developer adoption hurdles. EOA upgrades offer a smoother transition path while preserving existing infrastructure.

Q: Which EIP is most likely to be included in Pectra?
A: EIP-7702 is currently favored as a replacement for EIP-3074 due to better compatibility and lower risk profile. It has strong community and core developer support.

Q: Does account abstraction compromise security?
A: Not inherently—but introducing flexibility increases attack surface. Solutions like EIP-7702 aim to balance innovation with safeguards like temporary code pointers and strict signature validation.

Q: Can EOAs become quantum-resistant under these proposals?
A: Not directly. All three EIPs rely on ECDSA signatures. Long-term quantum resistance will require deeper protocol changes beyond current programmability enhancements.

Q: How does this affect Layer 2 networks?
A: These upgrades apply across Ethereum’s ecosystem—including L2s—ensuring consistent user experience and developer tooling regardless of scaling solution.

Conclusion: A Stepping Stone Toward Smart Accounts

EOA programmability represents a pragmatic evolution toward full account abstraction. While EIP-5806 offers minimal execution upgrades, EIP-3074 unlocks powerful delegation mechanics at the cost of complexity and centralization risks. EIP-7702, emerging as the leading candidate for Pectra, strikes a compelling balance—enabling rich functionality while aligning with long-term goals like RIP-7560.

However, these are not endpoints but stepping stones. True smart accounts—natively supported, quantum-safe, and fully autonomous—remain the ultimate destination.

For now, enhancing EOAs ensures that innovation benefits all users immediately—even those not ready to adopt contract wallets. As Ethereum continues its rollup-centric journey, seamless interoperability between account types will be critical.

In the next part of this series, we’ll explore EOA migration strategies, examining how users can transition from traditional wallets to full smart accounts without friction or risk.

👉 Stay ahead of Ethereum's evolution—explore tools that prepare you for the future of self-custody.