EIP-7702 Explained: How EOAs Became Smart Accounts in 2026
EIP-7702 lets an ordinary Ethereum wallet borrow smart-contract code without changing its address. The same feature that powers one-click batching became a favorite tool of wallet drainers.
For most of Ethereum’s history, every wallet forced a compromise. You could hold funds in an externally owned account (EOA), the kind a seed phrase creates in MetaMask, which is simple, cheap, and understood by every application, but also rigid: one signature buys one action, there is no batching, no gas sponsorship, and no recovery if the key leaks. Or you could move to a smart contract wallet with all of those powers and pay for it with a fresh address, a contract deployment, and years of patchy support from exchanges and apps. Almost everyone stayed on the EOA and lived with the limits.
EIP-7702 ended that compromise. Shipped in Ethereum’s Pectra upgrade on May 7, 2025, it lets an ordinary EOA borrow the code of a smart contract and behave like a programmable account, while keeping its original address, its balance, and its private key. No migration, no new address, no deployment. With Ether trading around $2,400 and gas a recurring cost for active users, the ability to batch actions and let someone else pay the gas is not a novelty; it is a structural change in how wallets work.
It is also one of the most double-edged changes Ethereum has shipped. The same mechanism that folds an approval and a swap into a single click lets an attacker empty a compromised address in one transaction, and it has already cost individual users seven figures. This explainer covers what EIP-7702 does, how the set-code transaction works under the hood, why exchanges and wallet makers adopted it within days, and why wallet drainers adopted it just as fast.
What EIP-7702 Actually Does
EIP-7702 introduces a new Ethereum transaction type, type 4, usually called the set-code transaction. It lets an EOA install a pointer to already deployed smart contract code. Once that pointer is set, the account’s code field holds a short delegation designator, and any call to the account runs the target contract’s logic in the account’s own context, using its balance, its storage, and its nonce. Crucially, the private key still works. The owner can keep signing ordinary transactions and can remove the delegation whenever they want.
The important mental model is that the EOA does not turn into a contract permanently. It gains a code pointer that it can set, change, or clear. It keeps the address that holds its history, its ENS name, and its airdrop eligibility. Ethereum’s own Pectra documentation describes it as setting a pointer to existing code through a new transaction type, and that framing matters: you are not deploying anything, you are borrowing logic that someone else already deployed and, ideally, already audited.
EIP-7702 was co-authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, and proposed in May 2024 as a leaner alternative to an earlier idea, EIP-3074. Buterin has framed it as a way to bring smart-account features to the accounts people already use, rather than asking a billion existing wallets to migrate, and as a design that stays compatible with the protocol’s longer-term account-abstraction plans, a position he set out when he first floated the proposal on Ethereum’s core developer channels.
EOAs vs Smart Contract Wallets: The Problem 7702 Solves
Ethereum has always had two kinds of accounts. An externally owned account is controlled directly by a private key. It is simple and universally supported, but it is also inflexible: a single signature authorizes a single call, so there is no native way to batch steps, no way for a third party to pay your gas, and no built-in recovery. If the key leaks, the funds are gone.
A smart contract wallet, such as Safe or the wallets pioneered by Argent, is the opposite. Because it is code, it can enforce arbitrary rules: multiple signers, daily spending limits, session keys, social recovery, and gas paid by a sponsor. The catch was always onboarding. A contract wallet needs to be deployed, which costs gas; it lives at a brand-new address; and for years many centralized exchanges and some applications handled contract addresses poorly, refusing withdrawals or mishandling signatures.
The migration friction was the real barrier. Long-term users had reputations, token approvals, ENS records, and airdrop history bound to a specific EOA. Asking them to abandon that address for a new contract was, for most, a non-starter. EIP-7702 removes the migration entirely. Your EOA remains your EOA and gains programmability on demand, which is why the change landed so quickly across the wallet stack.
The scale is what made this matter. The overwhelming majority of Ethereum accounts are EOAs, and they hold the bulk of ordinary users’ funds, so any account-abstraction plan that required everyone to move addresses was always going to stall. By meeting those accounts where they are, 7702 turned a migration problem into a one-signature opt-in, which is why wallet teams treated it as a default-experience upgrade rather than a niche power-user feature.
| Property | Plain EOA | Smart contract wallet | Delegated EOA (7702) |
|---|---|---|---|
| Controlled by | Private key | Contract code | Private key plus borrowed code |
| Address | Original | New contract address | Original, unchanged |
| Setup cost | Free | Contract deployment | One authorization signature |
| Batching and sponsorship | No | Yes | Yes |
| Recovery and limits | No | Yes | Yes, via delegate |
| Reversible | Not applicable | Move funds out | Revoke to the null address |
How the Set-Code Transaction Works
Under the hood, a type 4 transaction carries an authorization list. Each entry is a tuple of six fields: chain_id, address, nonce, and the three components of a signature (y_parity, r, s). The account owner signs a hash of the first three fields, and that signature is what proves consent to delegate.
According to the Pectra specification, the signed message is keccak(0x05 || rlp([chain_id, address, nonce])). The leading 0x05 is a magic byte that isolates this signature so it cannot be replayed as an ordinary transaction. The address field names the delegate contract, which must already be deployed; you delegate to existing bytecode, you do not upload new code. The nonce ties the authorization to a specific account state, and chain_id ties it to a network. A chain_id of zero is a special value meaning the authorization is valid on every EVM chain at once, which is convenient for wallet vendors but a cross-chain replay risk if used carelessly.
Once the transaction executes, the account’s code is set to a 23-byte value: the prefix 0xef0100 followed by the 20-byte delegate address. That is the delegation designator. Read the account’s code and you get those 23 bytes; call the account and the EVM loads the target’s bytecode and runs it against the EOA’s own storage and balance. To undo it, the owner signs a fresh authorization pointing to the zero address, which clears the code and returns the account to a plain EOA.
One subtlety trips up naive implementations. Because the delegate runs against the EOA’s storage, two different delegates can collide on the same storage slots, so switching from one implementation to another can leave corrupting leftovers. Serious wallet teams avoid this by using namespaced storage layouts (ERC-7201), which scatter each implementation’s variables to unique, collision-resistant slots. Each authorization also carries a base gas cost, and touching a fresh, never-before-seen account costs more, so vendors design their flows to reuse delegations rather than reset them on every action.
From EIP-3074 to EIP-7702
EIP-7702 did not appear in a vacuum. For years, Ethereum’s account-abstraction roadmap ran on two tracks: enshrine the feature at the protocol level, which is slow and invasive, or build it above the protocol, which is what ERC-4337 has done since 2023 using a separate system of user operations and bundlers. Between those poles sat EIP-3074, an earlier attempt to give EOAs superpowers through two new opcodes, AUTH and AUTHCALL, and a set of invoker contracts that could act on an account’s behalf.
EIP-3074 was far along, at one point pencilled in for the hardfork before Pectra, but it drew criticism. The invoker model could grant very broad and potentially long-lived authority, and it did not line up neatly with the direction ERC-4337 was already taking. In May 2024, Buterin proposed 7702 as a more forward-compatible replacement, and core developers agreed, dropping 3074 and adopting 7702 for Pectra, as The Block reported at the time. Swapping one proposal for another so late in the planning cycle was unusual, and it signalled how much the community wanted an EOA-friendly path that pointed toward the same endgame as 4337 rather than away from it.
What a Delegated Account Can Do
The upside is concrete and immediate. A delegated EOA can do things that used to require a separate contract wallet:
- Batching and atomic transactions: approve and swap, or claim and stake, in a single signature and a single transaction. If any step reverts, the whole bundle reverts, which removes the classic approved-but-the-swap-failed trap.
- Gas sponsorship: a dapp, exchange, or paymaster can cover your gas, or let you pay it in a stablecoin, so a brand-new user can transact without first buying ETH.
- Session keys: grant a temporary, tightly scoped key to a game or trading interface so you are not signing every single action, then revoke it when you are done.
- Spending limits and permissions: transaction-level rules such as daily caps, allowlisted destinations, or per-app limits.
- Social recovery: designate guardians so the seed phrase is not the only thing standing between you and a permanent lockout.
For consumer apps, the payoff is even more visible. A game can hand a delegated account a session key that signs routine in-game moves for an hour, so the player is not interrupted by a wallet pop-up on every turn, and the key expires on its own. A payments app can sponsor gas so that receiving a stablecoin and swapping it costs the recipient nothing up front. This is the direction wallet designers describe as the invisible wallet, where the machinery recedes and the user simply clicks once.
These are not abstract benefits. Batching, in particular, kills one of DeFi’s oldest footguns: the infinite token approval that sits open forever and gets drained months later. With 7702, a wallet can grant an exact approval and spend it in the same atomic transaction, then leave nothing dangling. The same batching makes position management cleaner; a borrower can add collateral and repay debt in one bundle to sidestep a forced sale, which matters when health factors and bad debt turn on seconds rather than minutes.
| Capability | Before EIP-7702 | With a delegated account |
|---|---|---|
| Approve and swap | Two transactions, two signatures | One atomic transaction |
| Paying gas | User needs ETH | Sponsor or stablecoin gas |
| Onboarding a new user | Buy ETH first | Transact with zero ETH |
| Recurring app actions | Sign every action | Scoped session key |
| Losing the seed phrase | Funds lost | Guardian recovery possible |
EIP-7702 vs ERC-4337: Not a Competition
A common confusion is that EIP-7702 competes with ERC-4337. It does not; they compose. ERC-4337 is the existing above-protocol account-abstraction standard, built around user operations, a dedicated mempool, bundlers, a shared EntryPoint contract, and paymasters that sponsor gas. It was designed for purpose-built smart accounts. EIP-7702 lets a plain EOA delegate to a 4337-compatible implementation, so the same ordinary wallet can plug into the same EntryPoint (version 0.8) and bundler infrastructure without ever leaving its address.
Put simply, 7702 is the on-ramp for the hundreds of millions of EOAs that already exist, and 4337 is the execution framework they ride once they are on it. The longer-term goal, native account abstraction (sketched in proposals such as EIP-7701), would erase the distinction between EOAs and contracts at the protocol level, at which point 7702 will have served as the bridge. Ethereum’s Pectra guidance explicitly recommends that delegate contracts be 4337-compatible, precisely so the two standards reinforce each other rather than fragment the wallet market.
| Dimension | EIP-7702 | ERC-4337 |
|---|---|---|
| What it is | Protocol transaction type | Above-protocol standard |
| Who it targets | Existing EOAs | Purpose-built smart accounts |
| Address | Keeps the original | New account address |
| Core infrastructure | Set-code tx, delegate contract | EntryPoint, bundlers, paymasters |
| Relationship | Delegates into 4337 | Executes delegated EOAs |
What a 7702 Upgrade Looks Like in Practice
For a normal user, the whole thing usually hides behind a single prompt. You open a wallet that supports smart accounts, the software notices that your address is still a plain EOA, and it offers to upgrade it. Behind that button is a set-code authorization pointing at the vendor’s own implementation contract. You sign once, the wallet submits the type 4 transaction, and from that point your address carries the delegation designator. Nothing about your address, balance, or transaction history changes; the account simply gains new abilities.
After that, the benefits show up as fewer clicks. A swap that once needed a separate approval and then the trade becomes one confirmation. A first-time user who holds only a stablecoin can pay network fees in that stablecoin, or have a dapp cover them, instead of being told to go buy ETH first. A game can ask once for a session key and then stop interrupting play. The wallet, not the user, decides when to reuse the existing delegation and when to route a call through a bundler.
Checking the status is straightforward. A block explorer will show a delegated account’s code as the 23-byte designator, and most explorers now label the target contract so you can see exactly what your address points to. If you ever want to walk it back, the wallet exposes a reset that signs an authorization to the zero address, and your account returns to being an ordinary EOA. That reversibility is part of what made the feature palatable: enabling it is not a one-way door, which is a meaningful contrast with migrating to a brand-new contract wallet.
How Exchanges and Wallets Rolled It Out
Adoption started immediately and, tellingly, exchanges moved first. Within a week of Pectra going live, more than 11,000 set-code authorizations had hit the chain, and the single largest source was not a consumer wallet but the exchange WhiteBIT, whose delegate contract accounted for roughly 48% of those early authorizations. OKX’s wallet contributed more than 3,100, while MetaMask sat around 1,300, according to Dune data compiled by The Block. The logic is straightforward: exchanges process enormous volumes of small transfers, and batching withdrawals, sponsoring gas, and consolidating deposits through a delegate contract cuts real costs.
The economics explain the ordering. An exchange that processes a large book of withdrawals can bundle many of them, sponsor gas so users are not blocked by empty balances, and route everything through a single delegated contract, which trims both failed transactions and per-transfer overhead. Those savings scale with volume, so the platforms moving the most funds had the most to gain and the least reason to wait. Retail wallets, by contrast, had to build user-facing flows, warnings, and recovery options before flipping the switch, which is why the consumer rollout trailed the exchange rollout by weeks.
The consumer wallets followed with full frameworks rather than one-off contracts. MetaMask shipped Smart Accounts built on a delegation framework, prompting existing users to sign a set-code authorization that points to a MetaMask-audited implementation. Ambire, an early mover, wired delegation directly into its flow so that any transaction triggers delegation automatically for EOA-mode users. Safe published a 7702-compatible implementation that lets an existing EOA borrow Safe’s multisig and module logic while keeping its canonical address, a design it calls the smart EOA. Coinbase’s smart wallet and several others followed the same pattern.
By 2026, cross-chain trackers such as BundleBear count 7702 activity in the hundreds of millions of cumulative authorizations across networks. That headline number flatters the picture, though, because a large share of the raw count comes from high-frequency automated senders, including the sweeper contracts discussed below; the population of unique human wallets that have genuinely upgraded is a much smaller slice. Still, the direction is clear, and the exchange lead has practical consequences for compliance teams, since sponsored and batched withdrawals interact with the identity and reporting rules that already govern how funds move between platforms, the same Travel Rule plumbing that shapes cross-exchange transfers.
On the regulatory side, EIP-7702 is protocol-level and self-custodial, so it does not itself trigger securities law, and the SEC does not regulate wallet bytecode. What it does is sharpen an old debate: as exchanges sponsor gas and batch actions on a user’s behalf, the line between self-custody and hosted convenience blurs, which is one of the threads running through crypto’s broader regulatory calendar into 2026. For now the feature sits squarely in the self-custody camp, and the responsibility for what an account signs stays with its owner.
The Security Paradox
Every property that makes 7702 useful cuts both ways. If your account can delegate to a contract that batches actions, then anyone who controls your key, or tricks you into signing on its behalf, can do the same. Security auditor CertiK described the change as one that redefines the trust assumptions of externally owned accounts, because a single signature can now hand over execution logic, not merely move one asset.
Two distinct threat models emerged almost at once. In the first, the attacker already has your private key, from malware or a leaked seed, and uses 7702 to bolt a draining contract onto the account. In the second, the attacker has no key at all and instead tricks you into signing a set-code authorization bundled with a batch of transfers, draining the wallet in one confirmation. The two are very different problems, and conflating them has muddied a lot of the coverage.
What makes the paradox sharp is that the defensive and offensive uses are technically identical. When your wallet upgrades your account, it asks you to sign a set-code authorization; when an attacker phishes you, they ask for exactly the same thing. The only difference is the delegate address and who controls it. That is why the entire safety model rests on one question at signing time: is this the contract my wallet vendor actually publishes, or a stranger’s. Everything else, from audits to bug bounties, is secondary to whether the user can answer that question correctly under pressure.
Sweeper Bots and the CrimeEnjoyor Contracts
The first model showed up in the on-chain data within days. Research from trading firm Wintermute found that in the weeks after Pectra, the overwhelming majority of 7702 delegations, more than 97% of them, pointed to identical copies of a simple sweeper contract that observers jokingly tagged CrimeEnjoyor. These are attached to addresses whose keys are already compromised, so that any ETH sent in is instantly forwarded to the attacker. Wintermute noted that the operations were largely unprofitable, sweeping little more than dust, as CoinDesk reported, and it later warned that the automation still left careless users exposed.
The reason 7702 appealed to sweeper operators is efficiency, not novelty. Before the upgrade, draining a compromised address on every incoming deposit meant running a frontrunning bot that watched the mempool and raced to move funds the instant they landed, a fragile and gas-hungry setup. With a delegation in place, the malicious logic lives on the account itself, so a single batched transaction can pull ETH, tokens, and approvals together the moment conditions are met. The upgrade did not create the theft; it lowered the operating cost of a theft that already depended on a stolen key.
The nuance is important, because 7702 exploit headlines misplace the blame. Taylor Monahan, a security researcher known for her work at MetaMask, put it bluntly: “It’s not actually a 7702 issue, its the same issue crypto has had since day one: end users struggle to secure their private keys.” She added that the upgrade “just unlocks a bunch of cool abilities that make sweeping addresses more cost efficient and less tedious,” her words quoted in reporting on the sweeper wave. In other words, the sweeper story is a key-hygiene failure that 7702 made cheaper to exploit, not a flaw in the transaction type. That distinction is the same reason serious holders keep meaningful balances under hardware or multisig custody, where a single leaked key is not enough to move funds.
The $1.54 Million Signature: How 7702 Phishing Works
The second threat model is the frightening one, because it does not need your key at all. On-chain scam tracker Scam Sniffer documented a case in which a single victim lost roughly $1.54 million after signing what looked like an ordinary interaction; the signature actually authorized a 7702 delegation to an attacker-controlled contract, bundled with a batch of token approvals and transfers that executed together. The lure was disguised as a routine Uniswap transaction, and Scam Sniffer flagged that a handful of similar 7702 batch attacks accounted for a large share of that month’s phishing losses.
It was not an isolated event. In the weeks right after Pectra, trackers documented a run of 7702 batch and sweeper thefts, with early sweeper attacks alone accounting for around $150,000 in losses, as AMBCrypto reported. The mechanics are always the same: users are conditioned to skim signature prompts, and a set-code authorization can look like a harmless message while the accompanying batch hides several transfers behind one approval. The danger is the combination, delegation plus batching under a single confirmation, which turns one careless click into total loss.
This is where the audit conversation gets uncomfortable. A delegate contract can be perfectly audited and still be useless as protection if the user is the one who signs the malicious delegation, a variant of the audited-yet-exploited pattern that recurs across the industry, as HOGE Wire noted in its look at CertiK’s August ledger. Code review hardens the contract; it does not harden the human at the confirmation screen.
How to Protect Yourself When You Sign
The defenses are practical, and most of them come down to reading what you sign:
- Treat any request to upgrade, delegate, or set code on your account as high-risk, and only ever delegate to your own wallet’s vetted implementation.
- Use a wallet that decodes 7702 authorizations in plain language and shows you the exact delegate address before you approve.
- Check that delegate address against the one your wallet vendor publishes; a mismatch is a red flag.
- Never approve a batch you cannot read. If a simple swap asks for a set-code authorization, stop.
- Keep large balances in hardware or multisig custody, and treat hot wallets as spending money.
- If your key is already compromised, delegation cannot save you; move remaining assets to a fresh wallet generated on a clean device.
Wallet software is catching up on the vendor side too, with clear-signing standards that render a human-readable summary of what a signature will do, transaction simulation that previews the outcome, and allowlists that refuse delegations to unknown contracts. None of these replace attention at the moment of signing, but they raise the floor for users who do not read raw hex.
Hardware wallets add another layer, because the delegate address has to be confirmed on a separate screen that malware on your computer cannot quietly rewrite. The blunt rule that survives every version of these attacks is simple: when a prompt asks to change what your account is, rather than just move a known amount, treat rejection as the safe default and only proceed once you have independently confirmed where the delegation points.
What Auditors and Wallet Teams Check
On the engineering side, delegate implementations get scrutinized for a set of failure modes that are specific to the 7702 model:
- Storage safety: namespaced layouts (ERC-7201) so a later delegate does not read or overwrite a previous one’s slots.
- Replay protection: careful handling of
chain_id, with high-value operations avoiding the all-chains value of zero, and disciplined nonce management. - Initialization guards: preventing an attacker from re-initializing a freshly delegated account into a state they control.
- Access control: ensuring sensitive functions on the delegate cannot be called by arbitrary third parties once an EOA points to it.
- EntryPoint interaction: confirming the implementation behaves correctly when driven through the 4337 EntryPoint.
The recurring lesson from firms like CertiK is that auditing the delegate is necessary but not sufficient. A flawless implementation still leaves the user exposed at the point where they choose what to sign, which is why the strongest wallet designs pair audited contracts with aggressive signing-time warnings and default-deny allowlists.
What Comes Next: Toward Native Account Abstraction
EIP-7702 is best understood as a bridge rather than a destination. Pectra shipped it; the upgrades that follow continue the account-abstraction roadmap toward native support, where the very distinction between EOAs and contracts fades and every account is programmable by default. Proposals such as EIP-7701 sketch that endgame, and 7702 is the retrofit that lets today’s wallets enjoy the benefits before the protocol gets there.
The upgrades that came after Pectra kept the roadmap moving on adjacent fronts, from data-availability scaling to further refinements in how accounts and transactions are handled, and each one narrows the remaining gap between an EOA and a contract. The practical effect for users is that the smart-account features introduced by 7702 keep getting cheaper and better supported rather than being replaced. By the time native account abstraction lands, most wallets and exchanges will already have years of production experience with delegated accounts, which is the kind of gradual migration Ethereum’s core developers said they wanted when they chose 7702 over the more abrupt alternatives.
What makes 7702 unusual among Ethereum upgrades is that it changed the default wallet experience without asking anyone to move. It brought batching, gas sponsorship, session keys, and recovery to the addresses people already hold, and it drove some of the fastest adoption of any recent change, led by exchanges rather than enthusiasts. In the same stroke, it handed drainers a cheaper way to empty compromised or deceived accounts. The technology itself is neutral; the risk sits where it has always sat, in how well keys are guarded and how carefully users read the thing they are about to sign. For a feature that quietly upgraded hundreds of millions of accounts, that is both its achievement and its warning.
Frequently Asked Questions
What is EIP-7702 in simple terms?
EIP-7702 is an Ethereum feature, live since the Pectra upgrade on May 7, 2025, that lets an ordinary key-controlled wallet (an EOA) temporarily borrow the code of a smart contract. The wallet keeps its original address and private key but gains smart-account powers such as batching several actions into one transaction, letting someone else pay the gas, and setting spending rules or recovery options.
Is EIP-7702 safe to use?
Delegating to your own wallet vendor’s audited implementation is safe, and it is how features like batching are delivered. The danger is signing a malicious delegation: attackers have used fake upgrade or swap prompts to trick users into delegating to a draining contract, and one victim lost about $1.54 million this way. Only ever delegate to your wallet’s official contract, and never approve a set-code authorization you did not start yourself.
Does EIP-7702 replace ERC-4337?
No, they work together. ERC-4337 is the account-abstraction framework, with its bundlers, EntryPoint contract, and paymasters, built for smart accounts. EIP-7702 lets an existing EOA delegate to a 4337-compatible contract, so an ordinary wallet can use that same infrastructure without moving to a new address. Think of 7702 as the on-ramp and 4337 as the road.
How do I revoke an EIP-7702 delegation?
You revoke by signing a new set-code authorization that points your account to the zero address, which clears the delegation and returns the account to a plain EOA. Most wallets that support 7702 expose this as a remove or reset option in their settings, so you do not have to build the transaction by hand.
Which wallets support EIP-7702?
MetaMask (through its Smart Accounts and delegation framework), Ambire, and Safe all support EIP-7702, and Coinbase’s smart wallet plus several exchanges, including WhiteBIT and OKX, integrated delegate contracts early. Support has spread quickly across the wallet stack since Pectra, so most actively maintained Ethereum wallets now offer some form of it.
By Marcus Okafor, senior markets and infrastructure editor at HOGE Wire.