EIP-7702 (co-authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett) is an Ethereum Improvement Proposal — included in the Pectra hard fork (2025) — that allows Externally-Owned Accounts (EOAs) to temporarily “become” a smart contract for the duration of a single transaction. A user signs an authorization specifying a smart contract’s code to execute on their behalf; during that transaction, their EOA has full smart contract capabilities (batching, custom validation, gas payment by a third party). When the transaction ends, the EOA returns to its normal state. This bridges the gap between the simple but limited EOA model and the powerful but complex smart account (ERC-4337) model — without requiring users to migrate their assets to a new address.
How It Works
The following sections cover this in detail.
The Problem: EOA Limitations
Standard Ethereum wallets (MetaMask, Ledger, hardware wallets) are EOAs — accounts controlled by a private key. Their limitations:
- Can only initiate one transaction at a time
- Must pay gas in ETH (can’t use USDC or other tokens)
- No session keys (must sign every single transaction)
- No sponsored transactions (third parties can’t pay gas on your behalf easily)
- No batch — doing 5 DeFi operations requires 5 transactions, 5 signatures
Smart accounts (ERC-4337, like Safe, Argent) solve these, but require a new account address — meaning users must migrate all assets, update all approvals, and lose their existing ENS/reputation.
EIP-7702’s Solution
EIP-7702 introduces a new transaction type that includes an authorization list. Each authorization is:
“`
{ chain_id, address, nonce } signed by the EOA’s private key
“`
address: the smart contract code to “delegate” to- Once processed, the EOA’s code is temporarily set to a delegation pointer to that address
- During the transaction, calls to the EOA execute the delegated contract’s code in the EOA’s storage context
- After transaction settlement, the state persists — the delegation remains until explicitly cleared
In practice:
- User signs an EIP-7702 authorization for, e.g., a “BatchExecutor” contract
- A bundler/sponsor includes this in a transaction
- For the duration of the transaction, the user’s EOA can execute batch calls, accept gas payment from a paymaster, etc.
- The user’s address doesn’t change; their private key still controls the EOA
What It Enables
| Feature | Pre-7702 (EOA) | Post-7702 |
|---|---|---|
| Batch transactions | No | Yes (via delegated contract) |
| Gas sponsorship | No | Yes (paymaster via delegation) |
| Session keys | No | Yes (delegated policy) |
| Token gas payment | No | Yes (paymaster integration) |
| Smart contract migration | Required for smart accounts | Not required |
| Private key ownership | EOA | EOA (unchanged) |
Relationship to Account Abstraction
ERC-4337 (Account Abstraction) created a separate mempool (UserOperations) and required entirely new smart account contracts. EIP-7702 is not a replacement for ERC-4337 — it’s a complement that extends account abstraction features to existing EOAs without requiring protocol-level validation changes. The two coexist:
- ERC-4337 smart accounts: Full-featured, permanent smart contract wallets, ideal for new users onboarding directly to smart accounts
- EIP-7702 EOAs: Existing EOAs that gain temporary smart contract powers per transaction — backward compatible, no migration needed
EIP-7702 is often called “the pragmatic path to account abstraction” — improving the current situation without waiting for full smart account adoption.
History
- 2023, May — EIP-7702 drafted by Vitalik Buterin et al. as a simplified alternative to the then-proposed EIP-3074 (which had broader and more dangerous delegation mechanics).
- 2024 — EIP-7702 gains consensus as the preferred EOA code execution mechanism for inclusion in a near-term hard fork.
- 2024 — EIP-3074 withdrawn in favor of EIP-7702, which provides similar benefits with a safer security model (signed authorizations with nonces, limiting scope).
- 2024–2025 — Pectra upgrade (Prague on execution layer, Electra on consensus layer) includes EIP-7702 as one of its key EIPs.
- 2025 — Pectra activates on mainnet, making EIP-7702 live; wallet providers begin integrating the new transaction type.
Security Considerations
Delegation scope:
EIP-7702 authorization includes a nonce — if the nonce in the signed authorization doesn’t match the EOA’s current nonce when the transaction is processed, the authorization is invalid. This prevents replay attacks.
Risks of bad delegation targets:
If a user signs an authorization for a malicious contract address, that contract can execute arbitrary code in their account’s context during the transaction — including draining funds. Users must only authorize trusted, audited delegation contracts.
Persistent delegation state:
After an EIP-7702 transaction, the delegation pointer persists in state until cleared by another 7702 authorization (pointing to null). This means users who forget they’ve set a delegation may behave unexpectedly in future transactions that invoke their address.
Common Misconceptions
“EIP-7702 makes EOAs into permanent smart accounts.”
The delegation persists between transactions but can be cleared at any time. EOAs are not permanently converted — they’re “augmented” until the delegation is explicitly removed.
“EIP-7702 replaces ERC-4337.”
EIP-7702 extends account abstraction to existing EOAs; ERC-4337 creates fully-featured permanent smart accounts. They serve different user segments and are complementary. The EIP-7702 approach is designed to work with ERC-4337 infrastructure (bundlers, paymasters).
“All wallets automatically support EIP-7702 after Pectra.”
Wallets must actively add UI support for signing EIP-7702 authorizations and integrating with compatible delegation contracts. The EIP activates at the protocol level, but wallet user experience requires deliberate development work from each wallet team.
Criticisms
- Persistent delegation risk — Because delegations persist, users who authorize a contract and forget may be vulnerable to unexpected contract execution if that contract is later exploited or abused.
- Phishing vector — Bad actors can create prompts that look like standard transaction signatures but are actually EIP-7702 authorizations for malicious contracts. User education and wallet warnings are critical.
- State complexity — The persistent code pointer in EOA state adds complexity to account introspection, contract interactions with EOAs, and edge cases in EVM logic.
- Not a full account abstraction solution — EIP-7702 gives EOAs temporary smart contract powers but doesn’t change Ethereum’s validation model at the protocol level — full account abstraction (eliminating the EOA/smart-account distinction entirely) remains a long-term goal.
Social Media Sentiment
EIP-7702 received broadly positive coverage on Ethereum Twitter/X as a pragmatic improvement — Vitalik’s active co-authorship lent it immediate credibility. The withdrawal of EIP-3074 (which some community members were attached to) generated debate, but EIP-7702 was generally accepted as the safer alternative. Wallet developers expressed enthusiasm mixed with implementation realism. r/ethereum threads leading up to Pectra positioned EIP-7702 alongside blob transactions as the two most user-impacting improvements in the fork. Critics note it’s incremental rather than transformative — the “real” account abstraction end state remains further away.
Last updated: 2026-04
Related Terms
Sources
- Buterin, V. et al. (2023). EIP-7702: Set EOA Account Code. Ethereum Improvement Proposals, GitHub.
- Ethereum Foundation (2024). EIP-7702 vs. EIP-3074: Comparison and Rationale. Ethereum Magicians Forum.
- Alchemy (2024). EIP-7702: A Developer’s Guide to Account Abstraction for EOAs. alchemy.com/blog.
- ERC-4337 Account Abstraction Group (2023). Interoperability Between ERC-4337 and EIP-7702. erc4337.io.