EIP-7702: How Set-Code Transactions Turn EOAs Into Smart Wallets

For most of Ethereum’s history, the wallet address in your pocket was a blunt instrument. It could hold funds and sign transactions, and that was the extent of its ambitions. The clever features (multiple signers, spending limits, account recovery, paying gas in a stablecoin, batching ten steps into one click) all lived inside smart contracts, and the plain key-controlled accounts that almost everyone actually used could not touch them. EIP-7702, which shipped in the Pectra hard fork on May 7, 2025, ended that divide with a single signed message.

The idea is deceptively simple: let an ordinary account borrow the code of a smart contract, behave like one for as long as it wants, then hand the powers back. The address never changes, no funds move, and nothing is deployed from scratch. By the middle of 2026, more than 46 million wallets had taken that upgrade at least once, according to smart-account tracker BundleBear. The same mechanism that lets a wallet bundle a token approval and a swap into one transaction, however, also let a phishing crew drain $1.54 million from a single victim in one signature, as security firm Scam Sniffer’s findings were documented. Understanding EIP-7702 means holding both of those facts at once.

This guide walks through what the set-code transaction is, how it works byte by byte, what it unlocks for everyday users, how it fits alongside ERC-4337, who has adopted it, where the real danger lives, and how to switch it on without handing your account to a stranger.

What EIP-7702 Actually Is

EIP-7702, titled Set Code for EOAs, is a core Ethereum standard that introduces a new transaction type, numbered 0x04, called the set-code transaction. It lets an externally owned account (EOA), the technical name for a normal key-controlled wallet, attach a pointer to a smart contract’s code. Once that pointer is set, any call to the wallet executes the contract’s logic, while the account keeps its own address, balance, storage, and nonce. The delegation is reversible, and it is set per chain.

The standard was authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and the developer known as lightclient (Matt Garnett), created in May 2024, and now carries Final status. The mental model that trips people up is the assumption that you are getting a new wallet. You are not. Your address stays exactly the same, your funds never move, and you do not deploy anything. You simply point your existing account at a contract that supplies behavior, the way a phone borrows features from an app without changing its number.

A concrete example makes it click. Imagine you want to swap a token on a decentralized exchange. Normally that is two transactions: one to approve the token and one to perform the swap, each signed separately, each costing gas, with an approval left sitting on-chain in between. With a 7702-delegated account, your wallet can bundle both into a single atomic action that either fully succeeds or fully reverts, and it can even let the app cover the gas. Same address, same funds, dramatically better experience.

The Problem It Solves: EOAs vs Smart Contract Accounts

Ethereum has always had two kinds of account. EOAs are controlled by a private key and make up the vast majority of addresses that people use to hold and send crypto. Contract accounts are controlled by code, and that code can do sophisticated things: require two of three signatures, cap daily spending, rotate a lost key through guardians, or run ten operations atomically. The catch is that until Pectra, an EOA could do none of that, and a contract account could not be summoned into an address you already owned.

The imbalance was not academic. EOAs won by default because they are simple: one key, one signature, no deployment cost, and universal support across every tool and chain. That simplicity is also a straitjacket. A plain key cannot enforce a daily withdrawal limit, cannot let a trusted friend help you recover access, and cannot promise that two actions either happen together or not at all. Every workaround, from hardware wallets to multisig treasuries, tried to bolt those properties onto an account model that was never designed for them.

To get smart-account powers the old way, you created a brand-new contract wallet (a Safe, an Argent account), paid to deploy it, and moved all of your funds and token approvals across. That migration tax, plus the mental cost of managing a second address, is the main reason smart accounts stayed a niche product for years even as the tooling matured. This is a big part of the story of how crypto wallets finally became usable: the friction was never really about features, it was about the cost of switching. The table below shows where EIP-7702 sits between the two older models.

From EIP-3074 to EIP-7702: A Short History

The road to the set-code transaction ran through two earlier attempts. EIP-3074, first floated in 2020, tried to give EOAs superpowers with two new opcodes and a system of trusted “invokers.” It worked on paper, but it required consensus-level changes and concentrated a lot of trust in invoker contracts, so core developers hesitated. ERC-4337, finalized in March 2023, took the opposite route: it delivered full account abstraction without changing the protocol at all, using a separate mempool of “user operations,” specialized bundlers, and a shared on-chain EntryPoint contract. The limitation was that ERC-4337 only helped brand-new smart-contract wallets, not the enormous base of EOAs already in use.

What made EIP-7702 click where EIP-3074 stalled was that it asked for less. It introduced no new opcodes, leaned on the ordinary signature machinery EOAs already use, and left the heavy lifting to whatever contract an account chose to delegate to. That minimalism made it easier to reason about, easier to ship inside a scheduled hard fork, and compatible with the ERC-4337 tooling teams had already built rather than competing with it. In a design space littered with ambitious proposals that never merged, doing the smallest useful thing turned out to be the winning move.

In May 2024 Vitalik Buterin proposed EIP-7702 as a pragmatic middle path: no new opcodes, immediate benefits for existing EOAs, and forward-compatibility with the eventual endgame of native account abstraction. It replaced EIP-3074 on the Pectra track and activated with the fork on May 7, 2025. Not everyone was fully at ease with the design. Ethereum core developer Marius van der Wijden told DL News that “It’s still a very early proposal, so we need to evaluate all the rough edges,” and described the mechanism as one that “adds a new transaction type that allows existing wallets to emulate the functions of Account Abstraction wallets.” Alex Jupiter, a senior product manager at MetaMask, framed the upside in the same report, saying the change folded the earlier competing routes into “one unified Account Abstraction roadmap.”

How the Set-Code Transaction Works Under the Hood

The set-code transaction (type 0x04) carries a field the older transaction types do not: an authorization list. Each entry in that list is a small signed tuple in which an account declares, in effect, “run this contract’s code as if it were mine.” The signature covers a magic byte (0x05) followed by the RLP encoding of the chain id, the target contract address, and the account’s nonce, which is what stops the authorization from being replayed against the wrong account state.

When the transaction is included, the protocol writes a compact 23-byte delegation designator into the account’s code field: the three bytes 0xef0100 followed by the 20-byte target address. The 0xef prefix is deliberate; it reuses a byte that EIP-3541 banned as the start of any deployed contract code, so a delegation can never be mistaken for, or collide with, an ordinary contract. From that point on, anything that calls the account runs the target’s logic inside the account’s own context (its storage, its balance, its address). To undo it, the owner signs a fresh authorization pointing at the zero address, which clears the code field and returns the account to a plain EOA.

There is a cost to all this, though a modest one. Each authorization in the list carries a gas charge (on the order of tens of thousands of gas for a fresh delegation, and less to reuse an existing one), which is why wallets often set the delegation once and leave it in place rather than toggling it on every transaction. The authorization can also be included by someone other than the account itself, which is exactly what makes sponsored, gasless upgrades possible: a relayer submits the type 0x04 transaction and pays the fee, while your signature is the only thing that proves consent.

One subtlety carries outsized importance for security: after a delegation, the account is simultaneously a key-controlled EOA and a code-bearing account. The private key can still sign transactions directly, and the delegated code can also act. That dual nature is exactly what makes EIP-7702 so flexible, and it is also the source of the unease some core developers voiced, because an account that is both things at once has a larger surface to reason about.

A Walkthrough: What Happens When You Upgrade

It helps to trace a single upgrade end to end. Say you open a wallet that supports the standard and tap a button to enable smart-account features. Behind the scenes, the wallet asks you to sign an authorization tuple naming its audited implementation contract, your account’s current nonce, and the chain you are on. That signature is the only thing you produce; you are not sending a transaction yet.

The wallet (or a relayer, or the app sponsoring your gas) then submits a type 0x04 transaction that includes your authorization. The network verifies the signature, checks the nonce, and writes the 23-byte delegation designator into your account. From your next action onward, calls to your address run the implementation’s code, so you can batch, sponsor gas, or use a session key. Your balance, address, and transaction history are untouched. If you later change your mind, you sign one more authorization pointing at the zero address, and your account goes back to being an ordinary EOA. The whole model is opt-in at every step, which is precisely why the dangerous moment is the signature itself: everything downstream flows from what you approved in that one prompt.

What Smart Accounts Unlock: Batching, Gas Sponsorship, and Recovery

The reason wallet teams raced to support the set-code transaction is that it turns a long list of painful multi-step flows into single clicks. The Ethereum Foundation’s own documentation describes it as unlocking batched calls, gas abstraction, session keys, and account recovery for accounts that previously could do none of that. In plain terms:

• Atomic batching: approve a token and swap it in one transaction, so you are never left with a dangling approval or a half-finished action.
• Gas sponsorship: let an app, an exchange, or a paymaster pay your gas, or pay fees in a stablecoin instead of keeping ETH on hand purely for gas.
• Session keys: hand a game or trading app a temporary, tightly scoped key so you do not have to sign every single action.
• Social recovery and multi-factor rules: add guardians or a second signer to an account that was born as a plain key, without a seed-phrase migration.
• Guardrails: enforce spending limits, allowlists, and transaction simulation at the account level.

These are not hypothetical features. Wallet standards such as ERC-5792, which defines how an app asks a wallet to send a batch of calls, give front-ends a clean way to request bundled actions, and wallets translate that request into a 7702-powered transaction under the hood. The user sees one confirmation for what used to be three or four, and the app never has to know whether the account is a native smart wallet or an upgraded EOA.

Gas abstraction is the feature users feel first. With ETH trading around $1,870 in early August 2026, per CoinGecko, the old requirement to keep a little ETH in every wallet just to move a stablecoin was a genuine onboarding wall. Paying fees in the asset you already hold, or having an app sponsor them entirely, removes that wall without asking the user to understand any of the plumbing underneath. Session keys do something similar for on-chain games: instead of confirming every move, a player grants a scoped key that can only perform certain actions for a limited time, which is the difference between a clunky demo and a game people actually play.

EIP-7702 vs ERC-4337: Complements, Not Competitors

A common misreading treats EIP-7702 and ERC-4337 as rivals. They are better understood as two layers of the same stack. ERC-4337 is a complete framework for smart-contract wallets that lives entirely above the protocol, with its user operations, bundlers, paymasters, and a shared EntryPoint. EIP-7702 is a protocol-level primitive that gives existing EOAs code. Rather than compete, they were designed to compose: the EntryPoint v0.8 release in 2025 added native support for EIP-7702 along with a canonical Simple7702Account implementation, so a delegated EOA can plug straight into the 4337 world of paymasters and bundlers.

In practice, most users will never choose between the two; their wallet will. A modern wallet can upgrade your EOA with a 7702 delegation and then route your actions through ERC-4337 infrastructure for sponsorship and batching, so the standards stack rather than compete. The distinction mostly matters to builders deciding whether to support existing addresses (7702) or issue new smart-contract accounts (4337), and increasingly the answer is both, because EntryPoint v0.8 lets a single codebase serve delegated EOAs and native smart accounts side by side.

Adoption by the Numbers

Adoption started fast and stayed fast. In the first week after Pectra, The Block reported more than 11,000 EIP-7702 authorizations on mainnet. By the middle of 2026, BundleBear counted roughly 217.6 million cumulative authorizations, about 46.2 million live delegated smart accounts, and more than 90.4 million set-code transactions. Those figures move daily, so treat them as a snapshot rather than a fixed score.

The wallets and exchanges that shipped support quickly are a good map of who is betting on the standard. Ambire was first out of the gate, followed by MetaMask’s Smart Accounts, Rabby, Trust Wallet, TokenPocket, and Safe, while exchange-side wallets from OKX and WhiteBIT were among the early volume leaders. For exchanges, the appeal overlaps with the incentives that already shape how tokens get listed and promoted: smoother onboarding and gasless first transactions lower the drop-off between signup and first trade.

Layer 2 networks leaned in quickly, since cheaper gas makes batched and sponsored transactions even more attractive. Arbitrum, for instance, pitched the upgrade directly to existing users under the banner that the smartest wallet you already own is the one already in your hands once it is delegated, and other rollups including Linea folded EIP-7702 support into their stacks so that any Ethereum wallet could reach smart-account features without deploying a new address.

One caveat belongs next to those headline numbers: a large share of the earliest authorizations were not real users at all, but automated malicious contracts, which is where the story turns darker.

The Dark Side: CrimeEnjoyor Sweepers and 7702 Phishing

When Wintermute’s research team looked at the first wave of delegations, it found something startling: more than 97% of them pointed at the exact same bytecode, a copy-pasted sweeper the researchers nicknamed “CrimeEnjoyor.” As CoinDesk reported, attackers spent roughly 2.88 ETH to authorize around 79,000 addresses, with a single address responsible for more than 52,000 of them. The purpose was mechanical: automatically drain any ETH that lands in a wallet whose private key has already leaked. Crucially, the campaign was barely profitable, because it targeted accounts that were already emptied. It was opportunistic reuse of stolen keys, not a break in the standard itself.

The more expensive risk is phishing, and here EIP-7702’s best feature becomes a weapon. Because a set-code transaction can batch many operations behind one signature, a fake trading interface can present what looks like a routine approval while actually bundling a delegation plus a fleet of token transfers. Scam Sniffer documented a victim who lost $1.54 million this way in a single signature, with the batch quietly moving wstETH, cbBTC, and other assets; a second victim lost about $1 million days apart, and a smaller $66,000 loss preceded both, all tied to the same crews, with known operations such as Inferno Drainer and Pink Drainer weaponizing the pattern. This is the same social-engineering engine that powers the DeFi exit-scam machine, dressed in new clothes. The common thread is not a protocol flaw; it is blind-signing a batch and delegating to a contract you did not vet.

Spotting the malicious version is harder than it should be, which is the whole problem. A legitimate upgrade prompt names a recognizable implementation and, ideally, shows its verified label; a malicious one hides a delegation and a pile of transfers inside a single innocuous-looking signature on a spoofed site. The practical defense is to slow down at exactly the moment the interface wants you to move fast, and to distrust any signature request that arrives with urgency, a countdown, or a too-good airdrop attached.

The New Attack Surface Auditors Watch

For the teams building 7702 wallet contracts, the audit checklist grew several new items. Security firms including SlowMist and Fireblocks have flagged a recurring set of pitfalls that are specific to running code inside an EOA’s own storage:

• Storage collisions: because delegated code reads and writes the account’s own storage, re-delegating from one implementation to another can leave stale or conflicting values behind. The mitigation is namespaced storage under ERC-7201.
• Initialization front-running: a set-code delegation has no constructor or initcode, so any “initialize” function can be called by anyone the moment the delegation lands unless it is bound to the authorizing account.
• Cross-chain replay: an authorization signed with chain_id set to 0 is valid on every EVM chain, so a delegation you approved in one place can be replayed against you somewhere else. It is the same class of cross-chain trust problem that makes bridge security so hard.
• Blind signing: ordinary users cannot read bytecode, so they cannot tell a benign delegation from a hostile one. Standards like ERC-7730 for clear signing aim to surface human-readable intent before a signature is given.

How to Use EIP-7702 Safely

For everyday users, the safety story reduces to a handful of durable habits. The Ethereum Foundation’s guidance is blunt: delegate only to audited, immutable implementations from trusted sources, and treat any prompt to delegate to an unfamiliar address as a red flag.

• Delegate only to your wallet’s official contract or a well-known implementation (Safe, MetaMask, Ambire and the like), never to an address a random dApp asks you to sign.
• Prefer wallets that display the delegation target’s verified name and warn you loudly when the target is unverified.
• Be suspicious of any authorization that uses chain_id 0; prefer chain-specific delegations.
• Read batched signature requests as if they were blank checks, because that is effectively what they are.
• Remember that you can revoke at any time by delegating to the zero address, which resets the account to a plain EOA.
• If a private key was ever exposed, no upgrade can save it; move to a fresh account instead of delegating on top of a compromised one.

None of these habits require technical knowledge, which is the point. The security of EIP-7702 for a normal user comes down to a single discipline: never approve a delegation or a batch you do not understand, and lean on wallets that make the delegation target legible before you sign. Everything the standard adds, from batching to sponsorship to recovery, is only as safe as the contract you point at, so the contract is the thing to scrutinize.

What It Means for Exchanges and Custodians

For exchanges, EIP-7702 is mostly an onboarding and retention tool. Sponsoring gas or letting customers pay fees in stablecoins removes a step that used to cost conversions at the top of the funnel, which is why OKX and WhiteBIT moved early. For custodians, the picture is more nuanced. A delegated EOA is still fundamentally key-controlled, so the institutional playbook of MPC signing and multisig approval still applies; the delegation simply adds a new piece of account state that has to be tracked, secured, and reasoned about in a firm’s risk model.

There are sharper operational edges too. A withdrawal address that happens to be a delegated EOA can behave differently from a plain one when it receives funds, so exchanges have to account for delegation status in their deposit and withdrawal logic. Paymaster services that touch customer assets to sponsor gas can blur into regulated money movement depending on how they are structured. None of this is a reason to avoid the standard, but it does mean the compliance and treasury teams need to be in the room, not just the wallet engineers.

For users, the practical upshot is that the line between an exchange account and a self-custody wallet keeps blurring. An exchange can offer a delegated wallet that feels as smooth as a custodial balance (gasless, batched, recoverable) while the keys still sit with the user. That is a genuinely better default for newcomers, but it also means the delegation target becomes a trust decision the exchange is effectively making on the customer’s behalf, which raises the stakes on picking audited, well-scrutinized implementations.

Where the SEC and Regulators Fit In

Signing a set-code transaction from your own wallet is, on its face, self-custodial software use, and that sits outside the direct reach of securities regulators. The U.S. Securities and Exchange Commission polices securities offerings, exchanges, brokers, and other intermediaries, not the act of a user signing a transaction; the mechanics of how SEC crypto enforcement works center on who is intermediating value, not on which transaction type a wallet emits. EIP-7702 still brushes against regulated surfaces indirectly, though. Exchanges and custodians that offer smart-account features are intermediaries; gas-sponsorship services that handle customer funds can raise money-transmission questions; and the wave of 7702 phishing losses is exactly the kind of consumer harm that draws enforcement and investor-protection attention.

Outside the United States, the framing is broadly similar: the European Union’s MiCA regime regulates crypto-asset service providers and issuers rather than the base protocol or the individual signing a transaction. In every jurisdiction, the standard itself is neutral infrastructure; the regulatory questions attach to the businesses built on top of it. None of this is legal advice, and anyone building a product on the set-code transaction should get specialist counsel before shipping.

What Comes Next: The Endgame for Account Abstraction

EIP-7702 was never meant to be the final word. It was explicitly designed as a bridge to fully native account abstraction, sometimes discussed under proposals like EIP-7701, in which every account can be a smart account at the protocol level without borrowing code at all. Because 7702 is forward-compatible with that endgame, the ecosystem gets to migrate now, teaching wallets, apps, and users the new patterns, rather than waiting years for a larger change. The convergence is already visible in tooling: EntryPoint v0.8 treats delegated EOAs and 4337 accounts as citizens of the same system.

The migration is deliberately gradual. Nobody is forcing existing EOAs to upgrade, and the standard is designed so that an account can stay a plain key forever if its owner prefers. What changes is the default trajectory: new wallets ship with smart-account features on day one, dApps increasingly assume batching and sponsorship are available, and the long tail of key-only accounts slowly becomes the exception rather than the rule. That is how a protocol-level change actually lands, not with a hard cutover but with a long stretch of accounts quietly gaining powers they never had.

That is the deeper significance behind Alex Jupiter’s line about “one unified Account Abstraction roadmap.” For most of Ethereum’s life, the split between key-controlled accounts and programmable ones forced a choice between the wallet everyone had and the features everyone wanted. The set-code transaction dissolves that choice. The open work now is less about whether EOAs can be smart, and more about making the delegation decision legible enough that users can tell a helpful upgrade from a hostile one, and that, as van der Wijden warned, means grinding down the rough edges one release at a time.

Frequently Asked Questions

What does EIP-7702 do in simple terms?

EIP-7702 lets an existing Ethereum wallet, technically an externally owned account, temporarily borrow a smart contract’s code. That lets the wallet batch actions, use gas sponsorship and add recovery without creating a new address or moving any funds, and the upgrade is reversible whenever you want.

Is EIP-7702 safe to use?

The standard itself is considered sound; the danger lives in what you choose to delegate to. Delegating to a malicious contract or blind-signing a batched transaction on a spoofed site can drain a wallet, so only delegate to audited, well-known implementations and read every batch prompt carefully.

What is the difference between EIP-7702 and ERC-4337?

ERC-4337 is an off-protocol framework for new smart-contract wallets built on user operations, bundlers and a shared EntryPoint. EIP-7702 is a protocol-level transaction type that upgrades existing EOAs. They complement rather than compete, and EntryPoint v0.8 added native EIP-7702 support so the two work together.

When did EIP-7702 go live on Ethereum?

EIP-7702 activated on Ethereum mainnet in the Pectra hard fork on May 7, 2025, introducing transaction type 0x04, the set-code transaction.

How do I revoke or remove an EIP-7702 delegation?

Sign a new set-code authorization that points your account at the zero address. That clears the delegation and returns your account to a plain EOA, and many wallets surface it as a remove-delegation or reset option in their settings.

By the HOGE Wire Wallets and Exchanges Desk.