EIP-7702: Account Abstraction That Ships Without the Overhead

Visa mentioned stablecoin settlement hitting ~$20B annualized run-rate this week. That's not DeFi degens—that's real payment volume. And real payment volume has real UX requirements: users can't be copying 42-character hex addresses or paying gas in tokens they don't understand.

Account abstraction has been the promised solution for years. ERC-4337 shipped, but adoption is slower than hoped. EIP-7702 takes a different approach: instead of replacing EOAs with smart accounts, make EOAs temporarily act like smart accounts.

Summary

EIP-7702 allows Externally Owned Accounts (EOAs) to delegate to smart contract code for a single transaction. You sign an authorization; the EOA behaves like a smart wallet for that transaction; then it goes back to being a normal EOA. The core bet: backwards compatibility matters more than architectural purity. EOAs can gain smart wallet features without migration, lowering the adoption barrier dramatically.

What is EIP-7702?

ERC-4337 created a parallel system: smart accounts, bundlers, paymasters. It works, but users need to migrate from EOAs to smart accounts—and migration has friction.

EIP-7702 works differently:

ERC-4337 Approach:
┌─────────────────────────────────────────────────┐
│ User has EOA (0xUser)                           │
│ User deploys Smart Account (0xSmart)            │
│ User migrates funds EOA → Smart Account         │
│ User interacts via Smart Account forever        │
└─────────────────────────────────────────────────┘
Requires: Migration, new address, learning curve

EIP-7702 Approach:
┌─────────────────────────────────────────────────┐
│ User has EOA (0xUser)                           │
│ User signs: "For this tx, use code from 0xImpl" │
│ EOA temporarily becomes smart account           │
│ Transaction executes with smart wallet features │
│ EOA returns to normal (same address, same key)  │
└─────────────────────────────────────────────────┘
Requires: One signature, no migration

The authorization is a signed message that says "delegate my account to this implementation contract." The EVM executes the transaction as if the EOA were a smart contract—with all the capabilities that implies.

The Migration-Free Bet

Here's what makes 7702 compelling: it meets users where they are.

Existing EOAs represent years of accumulated token approvals, ENS names, NFT ownership, and social reputation. Asking users to migrate to new addresses means losing or manually migrating all of that. Most users won't bother.

Migration Pain Points:

Token Approvals:
  - User has 50 DeFi approvals on 0xOldAddress
  - Migrate to 0xNewAddress
  - All 50 approvals invalid, must re-approve each

ENS Names:
  - vitalik.eth points to 0xOldAddress
  - Must update ENS record (gas cost + complexity)

NFTs and Social:
  - Profile picture NFTs at 0xOldAddress
  - Onchain reputation tied to 0xOldAddress
  - Social graphs (Farcaster FID) tied to 0xOldAddress

EIP-7702: Same address, no migration, features just work

For Visa-scale stablecoin settlement, this matters. Enterprise integrations point to specific addresses. Changing addresses breaks integrations.

Impact

Batched transactions become standard. Approve and swap in one transaction. Approve three protocols and execute a strategy atomically. Gas savings are significant, but the UX improvement is transformational.

Sponsored transactions unlock normie UX. Users don't pay gas—applications sponsor it. The application pays gas in ETH, deducts equivalent stablecoins from the user. User never touches ETH.

Session keys enable delegation. Grant a game temporary permission to move your NFTs without exposing your main key. The session key is scoped and time-limited.

But the security model changes. EOAs are simple: one key controls the account. With 7702 delegation, you're trusting the implementation contract code. A malicious implementation contract could drain your wallet.

Failure Modes

Malicious Implementation Delegation: User signs 7702 authorization to a malicious implementation. The implementation drains the wallet. Users might not understand what they're authorizing.

The signature format looks innocuous: "Authorize 0xContract to act on behalf of your account." A phishing site could get users to sign delegations to drain contracts.

Approval Persistence Confusion: ERC-20 approvals granted while delegated to an implementation might persist after delegation ends. Users could be confused about what approvals exist on their account.

Implementation Contract Bugs: Even honest implementations can have bugs. A bug in a widely-used wallet implementation affects everyone who delegates to it.

Recovery Complexity: If a user's key is compromised while delegated to a contract, recovery becomes more complex. The interaction between key recovery and contract delegation isn't always clear.

What I'd Change

Standardize implementation audit requirements. Don't let users delegate to unaudited implementations. Build a registry of audited, verified implementations that wallets can whitelist.

Make authorization scope explicit in UIs. "This authorization lets the contract: transfer tokens, approve spending, call any function." Users should see exactly what powers they're granting.

Time-bounded authorizations by default. Delegations should expire. A user who authorizes a wallet implementation in 2024 shouldn't still be delegated to that (potentially buggy) implementation in 2026.

Implementation upgrade mechanisms. If an implementation has a bug, how do users switch to a patched version? The upgrade path should be as frictionless as the initial delegation.

Lessons

Migration is a UX killer. Any system that requires users to migrate to new addresses faces an uphill adoption battle. Meet users where they are.
Backwards compatibility compounds. 7702 works with existing infrastructure—existing addresses, existing approvals, existing integrations. That backwards compatibility is a massive advantage over clean-slate approaches.
Smart wallet features are the product, not smart wallets. Users don't want "smart accounts." They want batched transactions, sponsored gas, and session keys. 7702 delivers the features without the migration.
Security model changes need explicit communication. The jump from "one key controls account" to "one key can delegate to arbitrary code" is significant. Wallet UIs need to make this clear.
Payment-scale UX requires payment-scale simplicity. $20B in stablecoin settlement can't run through "approve → wait → confirm → pay gas" flows. 7702 enables the batched, sponsored experiences that payment volume requires.

7702 is scheduled for Ethereum's Pectra upgrade. If you're building wallet infrastructure or payment applications, start designing for 7702 capabilities now. The UX improvements are substantial, and early adopters will have an advantage.