EIP-7702: How Ethereum's Pectra Upgrade Finally Bridges EOAs and Smart Contracts

On May 7, 2025, the Pectra upgrade activated on Ethereum mainnet, bringing the single largest batch of EIPs in the network's history. Buried among validator improvements and blob throughput increases was EIP-7702 — a proposal co-authored by Vitalik Buterin that quietly rewrites the rules of Ethereum accounts. It allows Externally Owned Accounts (EOAs) to set smart contract code on their address, permanently, without migrating to a new account.

This is not incremental. This is the bridge between the EOA world and the smart contract wallet world that Ethereum has been trying to build for years. If you are a developer building on Ethereum, EIP-7702 will change how your users interact with your application.

The Problem: EOAs Are Stuck in 2015

Ethereum has two types of accounts. Smart contract accounts hold code and can execute arbitrary logic. Externally Owned Accounts (EOAs) are controlled by private keys and can only do one thing per transaction: send ETH, call a function, or deploy a contract. No batching. No sponsorship. No permissions. No recovery.

This limitation has real consequences for every Ethereum user:

Batching: Want to approve USDT spending and then swap it on Uniswap? That is two separate transactions. You pay gas twice. You wait for confirmation twice. And if the first succeeds but the second fails, you are stuck with an approval you did not use.
Sponsorship: A new user with zero ETH cannot do anything on Ethereum. They cannot even receive their first tokens without someone paying gas for them. There is no way for Alice to pay for Bob's transaction natively.
Privilege de-escalation: Your private key controls everything. You cannot create a sub-key that only allows spending USDC up to $100 per day. You cannot give a session key that only interacts with one specific dApp. It is all or nothing.

Smart contract wallets like those built on ERC-4337 solve all of these problems. But they require users to migrate to an entirely new address — losing their transaction history, token holdings, ENS names, and every approval they have ever made. Most users simply refuse.

EIP-7702 eliminates this migration problem entirely.

How EIP-7702 Works

EIP-7702 introduces a new transaction type (type 0x04) that carries an authorization list — a set of signed tuples that tell the protocol: "I, the owner of this EOA, want my account to execute the code at this address."

Each authorization tuple contains:

chain_id: Which chain this delegation applies to (0 for all chains)
address: The address of the contract whose code you want to delegate to
nonce: The current nonce of the authorizing account
y_parity, r, s: A secp256k1 signature proving ownership

When the transaction is processed, the protocol writes a delegation indicator (0xef0100 || address) to the EOA's code slot. From that point forward, every time the EOA is called — whether by a CALL, DELEGATECALL, STATICCALL, or as a transaction destination — the EVM follows the pointer and executes the delegated contract's code in the context of the EOA.

The EOA keeps its address. It keeps its balance. It keeps its nonce. But now it also has code — code that can implement batching, sponsorship, permissions, and any other logic a smart contract wallet provides.

The Delegation Indicator

The delegation indicator uses the 0xef prefix — a previously banned opcode reserved by EIP-3541. This is clever design: regular contracts cannot use 0xef as their first byte, so there is no ambiguity between a normal contract and a delegated account. When the EVM encounters a delegation indicator, it knows to follow the pointer.

Important detail: delegation indicators are persistent. Once set, the code stays on the account until explicitly changed or cleared (by delegating to the zero address). This was a deliberate design choice — persistent delegations create enough friction that users treat them as real wallet upgrades rather than disposable scripts, unifying the smart contract wallet and EOA improvement workstreams.

The Three Killer Features

1. Transaction Batching

With EIP-7702, an EOA can delegate to a contract that accepts an array of operations and executes them atomically. Approve USDT spending and swap it in one transaction. Revoke all old approvals and set new ones in one transaction. Deposit into a vault and stake the receipt tokens in one transaction.

This eliminates the "two-transaction dance" that plagues every DEX interaction today. Users save gas (one transaction instead of two), save time (one confirmation instead of two), and eliminate the risk of partial execution (if any step fails, the entire batch reverts).

2. Gas Sponsorship (Paymasters)

A dApp or protocol can pay gas on behalf of its users. A new user with zero ETH can interact with smart contracts because the protocol covers the gas cost. The sponsor can be paid in ERC-20 tokens, or simply absorb the cost as a user acquisition strategy.

This is the unlock that onboarding has been waiting for. Today, every new Ethereum user needs to acquire ETH for gas before they can do anything. With sponsorship, a wallet can onboard a user with zero ETH and let them start transacting immediately.

3. Privilege De-escalation (Session Keys)

Users can sign sub-keys with limited permissions: spend up to $100 per day in USDC, interact only with Uniswap, or execute only specific function signatures. These session keys cannot drain the entire account — they are scoped to precisely defined operations.

This has massive implications for security. Instead of connecting your full private key to every dApp, you authorize a session key that can only do what you explicitly permitted. If the dApp is compromised, the attacker gets access to a scoped key — not your entire wallet.

Security Considerations

EIP-7702 is powerful, but it demands caution. The code you delegate to has unrestricted access to your account. A malicious delegation can drain everything. This is why the EIP explicitly warns that wallets must not provide a generic interface for signing arbitrary authorizations — users should only delegate to well-known, audited implementations.

Key Security Properties

Delegations are persistent but revocable: You can clear a delegation by authorizing the zero address. This means compromised delegations can be revoked, but you need to act fast.
No initcode: EIP-7702 does not run constructor code. The delegation is a simple pointer. Initialization happens via a regular call after the delegation is set. This eliminates an entire class of deployment attacks.
Template-based delegation: You delegate to an address, not arbitrary bytecode. This means you point to an existing, deployed contract — ideally one that has been audited and battle-tested.
Failed transactions do not roll back delegations: Even if the transaction execution fails, the delegation is already set. This prevents a class of griefing attacks where an attacker causes transaction failure to prevent a user from setting their delegation.

What Developers Must Do

Applications must never ask users to sign an EIP-7702 authorization directly. Instead, the delegation should happen through the wallet interface, with the wallet auditing the target code. If your dApp needs custom wallet functionality, build it on top of the delegated code using standardized module and extension systems — not by asking users to delegate to your custom contract.

Gas Costs

EIP-7702 adds gas costs proportional to the number of authorizations in the list:

Base cost per authorization: 12,500 gas
Additional cost for non-empty accounts: 25,000 gas per authorization
Cold account access during delegation resolution: +2,600 gas (EIP-2929)

For a typical single-delegation transaction to a previously empty account, expect roughly 37,500 gas for the authorization processing on top of normal transaction costs. This is significantly cheaper than deploying a new smart contract wallet (which typically costs 200,000+ gas) and avoids the migration entirely.

EIP-7702 vs ERC-4337: Complementary, Not Competing

A common misconception is that EIP-7702 replaces ERC-4337 (Account Abstraction). It does not. They are complementary:

ERC-4337 defines the UserOperation mempool, bundlers, and paymaster infrastructure — the "how" of account abstraction.
EIP-7702 lets EOAs participate in that infrastructure without migrating to a new address — the "who" of account abstraction.

An EOA with an EIP-7702 delegation can point to ERC-4337-compatible wallet code and immediately benefit from the entire ERC-4337 ecosystem: bundlers, paymasters, signature aggregators. The user keeps their existing address, keeps their existing assets, and gains all the capabilities of a smart contract wallet.

EIP-7702 is also designed to be forward-compatible with RIP-7560 (native account abstraction), ensuring that the delegations set today will continue to work as Ethereum's account abstraction roadmap evolves.

Developer Guide: Building for EIP-7702

If you are building on Ethereum, here is what you should start doing today:

Update your smart contracts: Contracts that check tx.origin or make assumptions about EOAs not having code need to be updated. With EIP-7702, tx.origin can have delegation code. Use msg.sender for authorization checks.
Support EIP-7702 transactions in your SDK: If you build wallet SDKs or transaction builders, add support for the new type 0x04 transactions with authorization lists.
Build delegation-aware UIs: Your dApp should detect when a user's account has an active delegation and adjust the UI accordingly. Delegated accounts may support batching, sponsorship, and session keys — expose these capabilities.
Create audited delegation targets: If you are building a wallet implementation, create and audit the contract that users will delegate to. This is the code that runs with full access to their account — it must be bulletproof.
Test on testnets: Pectra is live on mainnet, but test your EIP-7702 flows thoroughly on testnets first. The interaction between delegation, batching, and your existing contract logic may have edge cases.

The Bigger Picture: Why EIP-7702 Matters

Ethereum's account model has been a bottleneck since 2015. Smart contract wallets have existed for years, but adoption has been blocked by the migration problem — users cannot abandon their existing addresses. EIP-7702 removes this barrier entirely. Every EOA on Ethereum can now opt in to smart contract wallet features without changing a single thing about their account.

This is not just a technical upgrade. It is an adoption unlock:

For users: Batching, sponsorship, and session keys — immediately available on their existing address.
For dApps: Lower friction onboarding (gasless transactions) and better security (scoped permissions).
For the ecosystem: A unified path to account abstraction that bridges the EOA world and the smart contract wallet world without fragmentation.

EIP-7702 is live on Ethereum mainnet right now. The question is not whether it will change Ethereum account interactions — it already has. The question is how quickly developers will build on top of it. If you are building on Ethereum, the time to start is now.