ERC-7702 is an Ethereum standard that lets a regular externally owned account (EOA) temporarily borrow the code of a smart contract for the duration of a transaction. The standard, authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, introduces a new transaction type (0x04, called SetCode) that carries a signed authorization pointing the EOA to an implementation contract. The full specification is published at eips.ethereum.org/EIPS/eip-7702. ERC-7702 went live on Ethereum mainnet on May 7, 2025 as part of the Pectra hard fork.
​

The practical result: an address that has held ether for years, with thousands of historical transactions and reputation tied to it, can act like a smart wallet for one transaction (batching swaps, paying gas in USDC, granting a session key to a game) and then revert to a plain EOA. No new address. No funds migration. No on-chain identity reset.
​

This article walks through how the delegation pointer works, where ERC-7702 sits relative to ERC-4337, the new transaction format, real use cases shipping in wallets today, the security model and known risks, and the wallets that have integrated the standard since Pectra.
​

ERC-7702 is an Ethereum Improvement Proposal that defines a new transaction type allowing an EOA to authorize a smart contract implementation that the EVM will execute when the EOA is the transaction target. The mechanism is delegation, not deployment. The EOA does not have its own bytecode written to its address. Instead, the EOA's account state stores a 23-byte delegation indicator (the prefix 0xef0100 followed by the 20-byte implementation address) and the EVM treats calls to the EOA as if they were calls to that implementation.
​

The standard was finalized as part of the Pectra hard fork, which activated on Ethereum mainnet at slot 11649024 on May 7, 2025. Pectra also shipped EIP-7251 (max effective balance increase), EIP-7691 (blob throughput increase), and several other consensus-layer changes. ERC-7702 is the execution-layer change that most directly affects wallets and applications.
​

The motivation is plain. Before ERC-7702, the only way to get smart wallet features (batching, gas sponsorship, session keys, social recovery) was to use ERC-4337, which requires the user to fund and operate a fresh smart contract account address. That address has no history, no reputation, no ENS, no Snapshot vote weight, no airdrop eligibility tied to it. ERC-7702 lets the existing EOA borrow smart-contract behavior without abandoning the old address.
​

An ERC-7702 transaction is a new transaction type with the byte tag 0x04, registered as SET_CODE_TX_TYPE in the spec. Its payload contains the standard transaction fields (nonce, gas, to, value, data, access list, signature) plus one new field: an authorization_list. Each entry in that list is a tuple of (chain_id, address, nonce, y_parity, r, s) signed by the EOA being delegated.
​

When the transaction executes, the EVM iterates the authorization list. For each authorization with a matching chain ID and nonce, the EVM writes the delegation indicator 0xef0100 || address into the authorizing EOA's code field. Future calls to that EOA load the code from the delegated implementation. The chain ID can be set to zero, in which case the authorization applies on every chain that supports ERC-7702, which is useful for wallets that want one signature to set the same delegation across mainnet, Arbitrum, Base, Optimism, and other L2s.
​

The implementation address can be changed by sending another 0x04 transaction with a new authorization. Setting the implementation to the zero address (0x0000...0000) revokes the delegation entirely, and the EOA returns to plain EOA behavior. Revocation is one transaction. There is no time lock, no governance, no admin key.
​

Because the delegation is per-account, the implementation contract usually has to be written defensively. Storage slots used by the implementation are read from and written to the EOA's own storage, not the implementation's. This is the same model as a delegatecall proxy. A poorly written implementation can corrupt the EOA's storage layout or expose it to replay attacks across chains if it neglects the chain ID. The spec's security considerations section spells out these failure modes explicitly.
​

ERC-7702 does not replace ERC-4337. The two standards work alongside each other, and most production wallets that adopt ERC-7702 use a 4337-compatible implementation as the delegation target.
​

ERC-4337, finalized in March 2023 and live on every major EVM chain, defines an off-chain mempool for UserOperation objects, a Bundler that packages them into a standard transaction, an EntryPoint contract that verifies and executes them, and an optional Paymaster contract that can pay gas on behalf of the user. ERC-4337 accounts are deployed at a fresh address through a factory. The account's smart contract logic handles signature verification, nonce tracking, and any custom rules the wallet wants (passkeys, multisig, session keys).
​

ERC-7702 changes the address question only. An EOA that delegates to a Safe v1.5 implementation, a Coinbase Smart Wallet implementation, or a MetaMask Smart Account implementation can be called through the ERC-4337 EntryPoint and behave like a 4337 account, while keeping its original address. The Pimlico team's documentation, the Alchemy Account Kit, and Biconomy's modular SDK all support this pattern. The wallet still uses bundlers and paymasters; the user just keeps their EOA.
​

The split looks like this. ERC-4337 answers: how do you process a smart wallet's transaction without consensus-layer changes? ERC-7702 answers: how does an EOA become a smart wallet without changing its address? In practice, wallets ship both: a 4337 stack for users who want a brand-new smart wallet from day one, and a 7702 path for users with an existing EOA who want to upgrade in place.
​

A regular EOA can only sign one transaction at a time, and each is processed independently. An ERC-7702 delegation to a batch-call implementation lets the EOA submit a single transaction that approves USDC to Uniswap, swaps USDC for ETH, deposits ETH into Aave, and pulls aETH into a yield strategy, all in one atomic operation. If any step reverts, the whole transaction reverts. This is the same atomic batching that Safe and Argent have offered to smart wallet users since 2020, now available to any address that signs a 7702 authorization.
​

The implementation an EOA delegates to can validate ERC-4337 UserOperation calls routed through a paymaster. The user signs a userop with their EOA key; a paymaster contract (operated by the app, by Pimlico, by Biconomy, or by Alchemy's Gas Manager) covers the gas in ETH on the EOA's behalf. The user pays in USDC, in app credits, or in nothing at all if the app is sponsoring. Coinbase Smart Wallet, Privy, and Dynamic ship this pattern for their embedded-wallet customers.
​

A session key is a secondary key with limited authority. The EOA delegates to an implementation that recognizes a session key, scoped to a single contract address, a spending limit, and an expiration. A game can request a session key valid for two hours that can call only its game contract and spend at most 0.05 ETH. The user signs once. For the next two hours, the game submits transactions signed by the session key without re-prompting the user. ERC-7715, currently in Draft status, formalizes how dapps request these permissions from wallets; ERC-7702 supplies the on-chain mechanism that makes the EOA enforce them.
​

An EOA's private key cannot be changed. If the seed phrase leaks, the address is permanently compromised. With ERC-7702, the EOA can delegate to an implementation that adds guardians (other addresses or passkeys) who can collectively rotate the signing key by replacing the delegation. The original ECDSA key never changes, but the implementation can ignore it after rotation. Argent's recovery flow and Safe's social recovery module both work this way under a 7702 delegation.
​

The same delegation pattern enforces transfer ceilings (no single transfer above $10,000), destination allowlists (only Aave, Uniswap, and a personal cold wallet), and rate limits (no more than five outbound transactions per day). The rules live in the implementation contract, the EOA's signature still authorizes the transaction, and the implementation reverts if the request violates the rules.
​

The implementation an EOA delegates to has full control over the EOA's storage and balance. A phishing site that tricks a user into signing a SetCode authorization for an attacker's implementation can drain the EOA on the next transaction. The phishing payload is one signed authorization, indistinguishable from a benign ERC-7702 setup unless the wallet inspects the implementation address. Wallets are responsible for showing the delegation target clearly and warning on unknown contracts. The Ledger and Trezor teams have published guidance on how their firmware displays 7702 authorizations.
​

An authorization signed with chain_id = 0 is valid on every chain that supports ERC-7702. If a user signs such an authorization for a delegation they want only on mainnet, an attacker can replay the same signature on Arbitrum, Base, Optimism, and any other supporting chain. The spec recommends wallets default to per-chain authorizations and warn loudly before letting a user sign a chain-zero authorization. Implementations should still include a nonce check to prevent replay within a single chain.
​

Because the implementation's storage reads and writes hit the EOA's account, two different implementations using the same storage slots will overwrite each other's state if the EOA switches between them. The Solady and OpenZeppelin libraries provide ERC-7201-namespaced storage helpers that mitigate this. Wallets that let users switch implementations mid-life need to either clear storage on each switch or pick implementations that follow the namespacing convention.
​

Revoking a delegation (by signing a new authorization to the zero address) only stops future transactions from using the implementation. Approvals the implementation already granted to other contracts, session keys it already issued, and any pending operations it was scheduled to perform are not automatically rescinded. Users have to revoke ERC-20 approvals and session keys separately, the same as with any smart wallet.
​

An ERC-7702 transaction with a non-empty authorization list costs slightly more gas than an equivalent EOA transaction (the spec defines a per-authorization cost of 12,500 gas for an existing account, 25,000 additional for an empty one). For most users this is a one-time cost paid when delegation is first set. For wallets that change delegation often, the overhead adds up. Argent's docs note that their 7702 flow sets delegation once and rotates implementations through internal upgrade calls rather than re-authorizing every time.
​

Adoption since Pectra has clustered in the wallet stack that already shipped ERC-4337 features. Concrete integrations as of early 2026:
​

MetaMask Smart Account. MetaMask shipped its Smart Account feature in 2025 with ERC-7702 as the primary upgrade path for existing MetaMask users. The flow lets a user upgrade their existing EOA to a smart account that supports batching and gas sponsorship without changing the address. Documentation is on the MetaMask developer portal.
​

Ambire Wallet. Ambire was an early adopter of ERC-7702 and integrated the standard for its EOA-mode users at Pectra activation. Ambire's docs walk through how the wallet sets delegation to its v2 implementation contract and how users can revoke.
​

Safe. Safe published a 7702-compatible implementation contract that lets an existing EOA borrow Safe's smart account logic for a single transaction or as a persistent delegation. Safe's "smart EOA" framing emphasizes that the EOA remains the canonical address while gaining multisig and module support.
​

Coinbase Smart Wallet. Coinbase Smart Wallet, which launched in June 2024 as a passkey-based smart wallet, exposed an ERC-7702 path for users who want to upgrade an existing EOA rather than create a fresh smart wallet address. The integration uses Coinbase's existing implementation contract.
​

Rabby. Rabby published its ERC-7702 implementation roadmap shortly after Pectra and shipped support for delegated EOA mode in late 2025. Rabby's framing positions 7702 as the default upgrade path for power users with existing addresses.
​

Trust Wallet. Trust Wallet added support for signing and displaying ERC-7702 authorizations after Pectra. Their implementation focuses on transaction display: users see the delegation target's verified name when available, and an explicit warning when the target is unverified.
​

Wallet adoption is uneven and changes month to month. The most reliable source is each wallet's own changelog or developer documentation. Do not treat any aggregated tracker as authoritative without checking the upstream wallet.
​

ERC-7702 had a long road. The EIP was first published in May 2024 by Vitalik Buterin and co-authors as a replacement for the older ERC-3074 proposal, which had a similar goal but a different mechanism (an AUTH opcode). After several months of debate on the Ethereum Magicians forum and the All Core Devs calls, ERC-7702 was included in the Prague execution-layer scope, paired with the Electra consensus-layer scope, to form the Pectra upgrade.
​

Pectra activated on Ethereum mainnet on May 7, 2025. The Ethereum Foundation's announcement and the client team release notes (Geth, Nethermind, Besu, Erigon, Reth) document the activation slot and the exact set of EIPs included. ERC-7702 became live and usable on Ethereum L1 at that moment. L2s that follow mainnet's EVM (Arbitrum, Base, Optimism, Polygon zkEVM, Scroll, Linea) rolled in 7702 support during their post-Pectra upgrades through mid-2025.
​

The next Ethereum upgrade in the pipeline is Fusaka, which is expected to ship blob throughput increases and additional execution-layer EIPs. None of the currently scoped Fusaka EIPs modify ERC-7702 semantics. The standard, as activated in Pectra, is the version every wallet and implementation is building against.
​

Eco Routes works on top of whatever wallet a user holds, whether that wallet is a plain EOA, an ERC-4337 smart account, or an EOA upgraded through ERC-7702. The routing layer is wallet-agnostic. What ERC-7702 changes for Eco's stablecoin payment customers is the user experience around gas: an EOA delegated to a paymaster-compatible implementation can pay for cross-chain USDC or USDT0 transfers in the stablecoin itself, with no separate gas token required. The address on the receipt is the user's original EOA, which keeps reputation, history, and onchain identity intact while removing the friction of holding native gas on every chain.
​

No. ERC-7702 changes how an EOA can borrow smart contract behavior. ERC-4337 defines the userop mempool, bundler, and paymaster infrastructure that smart wallets use. Most production 7702 deployments delegate to an implementation that is itself 4337-compatible, so the two standards work together rather than competing.
​

Yes. Send a new 0x04 transaction with an authorization pointing to the zero address. The delegation indicator clears and the EOA returns to plain EOA behavior. Future approvals or session keys that the delegated implementation already granted to other contracts have to be revoked separately.
​

No. The address is unchanged. ERC-7702 stores a delegation pointer in the EOA's account state but does not change the address. ENS records, NFTs, balances, and history stay tied to the same address.
​

Ethereum mainnet has supported ERC-7702 since the Pectra hard fork on May 7, 2025. Major L2s including Arbitrum, Base, Optimism, Polygon zkEVM, Scroll, and Linea rolled in 7702 support during their post-Pectra upgrades through mid-2025. Check the specific chain's release notes for the activation block.
​

ERC-3074 was the earlier proposal to give EOAs smart contract behavior. It introduced an AUTH opcode that an "invoker" contract would call to execute logic on behalf of the EOA. ERC-7702 replaced ERC-3074 with a simpler model: a delegation pointer in the EOA's code field, no new opcode, and no invoker contract. The Ethereum Foundation and core developers chose 7702 over 3074 because the delegation model composes better with ERC-4337 and avoids new EVM execution paths.
​

They can be. The authorization signature includes a chain ID field. A non-zero chain ID makes the authorization valid only on that chain. A zero chain ID makes the authorization valid on every chain that supports ERC-7702, which is convenient for setting the same delegation across many chains with one signature but creates a replay risk if the user signs without understanding the scope. Wallets default to per-chain authorizations.
​

Standards and specifications: EIP-7702 (Set EOA account code), EIP-4337 (Account Abstraction Using Alt Mempool), EIP-7715 (Grant Permissions from Wallets, Draft), EIP-3074 (predecessor, withdrawn), Ethereum.org Pectra upgrade overview.
​

Wallet documentation: MetaMask developer portal (Smart Account), Ambire docs, Safe (safe.global), Coinbase Smart Wallet docs, Rabby release notes, Trust Wallet release notes.
​

Infrastructure documentation: Alchemy Account Kit, Pimlico docs, Biconomy SDK, ZeroDev docs.
​

Eco Routes makes stablecoin payments work across every chain a user touches, on plain EOAs, ERC-4337 smart accounts, or EOAs upgraded through ERC-7702. Learn more about Eco.
​