An EOA can become a smart wallet through EIP-7702, which activated in the Pectra hardfork on May 7, 2025. The mechanism: an EOA signs an authorization tuple (chain_id, contract, nonce, signature) that points to a smart-wallet contract. The protocol writes a special delegation marker into the EOA's code field, and any subsequent call into the EOA executes the delegated contract's code. The EOA keeps its address, balance, and nonce. The private key still controls everything. The delegation is revocable.
​

Until 7702 shipped, the EOA-to-smart-wallet upgrade path required moving funds to a new contract account address. That broke ENS records, dapp-side allowlists, and historical on-chain identity. 7702 fixes that. This article walks through how the delegation works on chain, the authorization signing flow, gas semantics, revocation, the security trade-offs, and which infrastructure providers shipped 7702 support through 2025.
​

EIP-7702 introduces transaction type 0x04, the SetCode transaction. A SetCode transaction includes an authorization list. Each authorization is a tuple (chain_id, address, nonce, y_parity, r, s) where the signature recovers to an EOA's public key. When the transaction executes, the protocol writes the delegation marker 0xef0100 || address into each authorizing EOA's code field.
​

The delegation marker is exactly 23 bytes. Any subsequent call to the EOA address triggers the EVM to read the marker, fetch the target contract's code, and execute it in the EOA's context (the EOA's storage, balance, and address are what the code sees). The EOA itself does not store the contract's code; it stores a pointer.
​

The relevant infrastructure-side specification is in the Prague execution-spec. The reference behavior is implemented in Geth, Reth, Erigon, Nethermind, Besu, and the consensus-layer clients.
​

An externally owned account has structural limitations: no batching, no gas sponsorship, no programmable validation, no recovery. Smart wallets fix those, but historically required moving to a new address. The address change broke continuity. ENS records had to be re-registered. NFTs had to be transferred. Dapp-side allowlists had to be re-built. Treasury reporting needed to track the migration.
​

7702 lets a user keep the address. An EOA at 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 can sign a delegation pointing to a smart-wallet contract, gain batching and gas sponsorship for the authorization's lifetime, and revert to a plain EOA whenever the delegation expires or is revoked. ENS, NFTs, dapp allowlists, and reporting all stay intact.
​

A 7702 delegation has four steps. The first three happen off chain. The fourth is what changes state.
​

The wallet shows the user a tuple containing the chain ID, the target contract address, the next nonce, and asks for an ECDSA signature. The signature commits the EOA to one specific contract on one specific chain. EIP-712-style typed data lets wallets render the fields meaningfully so the user is not signing an opaque hex blob.
​

The submitter (any account, possibly the EOA itself) constructs a type-0x04 transaction with the authorization in its authorization list. A single SetCode transaction can carry multiple authorizations, making batched delegations possible across many EOAs.
​

The submitter pays the transaction's gas. This is the basis for sponsored 7702 onboarding: a dapp can pay the gas to delegate a user's EOA to its custom wallet contract, and the user signs only the authorization, not the transaction.
​

On inclusion, the EVM verifies each authorization signature, confirms the EOA's nonce matches, increments the EOA's nonce by one, and writes 0xef0100 || target_address into the EOA's code slot. The state change is final after standard Ethereum finality (roughly 12.8 minutes).
​

From this point forward, every call into the EOA executes against the target contract's bytecode. The EOA can sign user operations, batch calls, accept gas in any token through a paymaster, and use session keys, all without changing address.
​

The delegated EOA inherits the target contract's behavior. If the target is a ERC-4337 wallet implementation like ZeroDev's Kernel or Alchemy's Modular Account, the EOA gains the full ERC-4337 user-operation lifecycle: validateUserOp, paymaster integration, session keys, and modular permissions.
​

The EOA still controls its private key. The private key can still sign transactions directly to the public mempool, bypassing the smart-wallet code. This is by design: 7702 adds a code path; it does not remove the original one. A malicious actor who steals the private key can still drain the account regardless of the delegation.
​

The nonce semantics are subtle. The EOA's transaction-level nonce increments on direct sends. The smart-wallet contract typically maintains its own user-operation nonce in storage. The two coexist, and wallet implementations have to coordinate them carefully.
​

Revocation is a second SetCode transaction with the target address set to 0x0000...0000. The protocol writes the delegation marker pointing to the zero address, which the EVM treats as no delegation. The EOA reverts to plain-EOA behavior immediately on inclusion.
​

Revocation is also implicit: if the EOA's nonce advances past the nonce locked into the original authorization, the authorization stops applying. This means a delegated EOA can sign a one-shot authorization that auto-expires after a set number of transactions.
​

Several wallet and infrastructure providers shipped 7702 implementations after Pectra activated. ZeroDev's Kernel v3 added 7702 delegation support in mid-2025. Alchemy's Modular Account v2 ships native 7702 onboarding. Biconomy's Nexus stack uses 7702 for cross-chain orchestration; see Biconomy MEE for details. Safe announced 7702 support for its 1.5.0 release. MetaMask rolled out 7702 prompt support in its 2025.10 release.
​

Wallet UIs that shipped 7702 support typically present the delegation as "upgrade your wallet to support smart features" with a one-time sponsored transaction. The user does not pay gas for the delegation itself; the wallet provider or app sponsors it.
​

7702 introduces three new failure modes. Each has a mitigation, but the failure modes are real.
​

The original 7702 draft allowed chain_id = 0 authorizations that were valid on every chain. The final spec narrowed this: an authorization with chain_id = 0 is treated as cross-chain-replayable, while a non-zero chain ID locks to one chain. Wallets default to non-zero, but the cross-chain wildcard is still usable. Ethereum Foundation's security review flagged this as the highest-attention area.
​

An authorization signature is a different signature type from a regular transaction signature. Wallet UIs initially under-rendered the authorization fields, making phishing easier. The 2025 retrospectives from Ledger and other hardware-wallet vendors flagged authorization rendering as the most common UX gap.
​

If the delegated contract has a bug, every EOA delegated to it inherits the bug. A single vulnerability in a popular wallet implementation could compromise millions of EOAs simultaneously. Auditing the target contract becomes existential. Safe's 1.5.0 audit, conducted across two firms over 14 weeks, ran specifically because Safe expected to be a 7702 delegation target at scale.
​

The decision is workload-driven. Delegate if the workload benefits from batching, gas sponsorship, or session keys; if address continuity is valuable; if the user already holds an EOA they cannot easily migrate. Stay with a plain EOA if cold-storage simplicity, hardware-wallet UX, or a small attack surface matter more than smart-wallet features. For long-term reserves, the plain EOA on a hardware device is still the most defensible position.
​

For consumer apps optimizing onboarding conversion, 7702 is the lowest-friction upgrade path: existing MetaMask users do not need to migrate, and dapps can sponsor the delegation gas. Chain-abstracted wallet designs increasingly assume 7702 as the default delegation target.
​

Eco is the stablecoin execution network that abstracts cross-chain stablecoin movement for both plain EOAs and 7702-delegated EOAs. A user signs one intent from any wallet. Eco's solver network selects between Circle CCTP, Hyperlane, LayerZero, and Wormhole rails to settle on the destination chain across 15 chains. Eco Accounts is the standardized smart-account layer that pairs cleanly with EOAs and 7702 delegations alike, so the choice to delegate becomes orthogonal to the multi-chain stablecoin flow. Whether the user is plain or delegated, the integration is one signature.
​

The SetCode transaction that writes the delegation costs gas (about 50K gas above a base transfer). The gas is paid by whichever account submits the transaction, which can be the user, a dapp, or an infrastructure provider. Most consumer wallets sponsor the delegation gas during onboarding so users pay nothing.
​

Yes. Sign and submit a second SetCode transaction with the target address set to 0x0000...0000. The protocol overwrites the delegation marker, and the EOA reverts to plain behavior immediately on inclusion. There is no time lock on revocation.
​

Yes, on every L2 that has activated EIP-7702 in its protocol upgrade cycle. Most major L2s (Arbitrum, Base, Optimism, Polygon zkEVM) shipped 7702 within a few months of Ethereum mainnet activation. Each L2 has its own activation timeline; check the chain's official upgrade announcements.
​

Yes. The private key has not gone away. A direct ECDSA-signed transaction from the EOA still goes through the regular mempool and bypasses the smart-wallet code. This is intentional: 7702 adds a code path; it does not lock the original one. Hardware-key custody is still the most important security control.
​

ERC-4337 defines a separate user-operation pipeline (alt-mempool, bundler, EntryPoint) that lets contract accounts behave like first-class senders without protocol changes. EIP-7702 is a protocol-level change that lets an EOA point to contract code. They are complementary: most 7702 delegations target an ERC-4337 wallet implementation, so the EOA gains 4337 capabilities at its existing address. See the account abstraction guide.
​