EIP-7702 in 2026: The Upgrade That Skipped the Migration

The Ethereum address in your wallet is probably years old. You have pasted it into exchanges, handed it to friends, and watched it collect tokens across a dozen apps. Since May 2025 that same address can do something it never could before: it can run code. It can bundle a token approval and a swap into a single click, let someone else pay its gas, or hand a game a narrow key that expires on Sunday. Nothing about the address changed. You did not move your funds. In most cases you did not even notice. That quiet swap of powers is EIP-7702, and it is the reason account abstraction finally reached ordinary users without asking them to migrate anything.

By late September 2026, with ETH trading around $2,730 and a market value above $330 billion (CoinDesk), tens of millions of Ethereum addresses carry an active EIP-7702 delegation. Wallets from MetaMask to Bitget lean on it, exchanges have had to teach their systems to read it, and a small drainer economy has learned to abuse it. This guide walks through what EIP-7702 does, why skipping the migration was the entire point, and what it means for the wallets and exchanges where most people actually keep their coins.

What EIP-7702 actually does

For most of Ethereum’s history there were two kinds of accounts. An externally owned account, or EOA, is the ordinary wallet: a private key controls it, it can hold and send assets, and it has no code of its own. A contract account is the opposite: it runs logic but cannot start a transaction on its own. Every wallet you have ever imported from a seed phrase is an EOA, and an EOA could never batch actions, set spending rules, or let a third party cover its fees.

EIP-7702 blurs that line. It lets an EOA point at a smart contract and temporarily run that contract’s code as if the code lived at the account’s own address. The private key still authorizes everything; the account simply gains a set of abilities it did not have a moment earlier. The change went live in the Pectra hard fork on May 7, 2025, and it was written by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett as a lighter alternative to an earlier design (EIP-3074) that would have added new opcodes. Ethereum’s own documentation frames it as a way for existing wallets to behave like smart-contract accounts without giving up their keys.

The practical result is that account abstraction, a goal Ethereum developers have chased since 2016, stopped being something you had to opt into by creating a new kind of wallet. It became a feature your old wallet could switch on.

Why “no migration” was the whole point

Smart accounts existed before EIP-7702. ERC-4337, finalized in March 2023, lets developers build fully featured smart-contract wallets with batching, gas sponsorship, and flexible signing, all without changing Ethereum’s core rules. It works, and it powers a large chunk of today’s account-abstraction stack. But it has a friction problem: an ERC-4337 wallet is a separate contract at a brand-new address. To use one, you deploy that contract and move your assets into it. For anyone with a history, a token portfolio, and an address other people already know, that migration is a real cost.

The authors chose that in-place approach deliberately. An earlier proposal, EIP-3074, would have added powerful new opcodes to give EOAs similar abilities, but it risked becoming a permanent fixture that the eventual native design would have to work around. EIP-7702 was pitched instead as a minimal, forward-compatible step: enough to give wallets real smart-account features today, but small enough to retire cleanly once account abstraction is built into the protocol itself. That framing, a bridge rather than a monument, is why its own designers describe it as temporary even as tens of millions of accounts come to rely on it.

EIP-7702 removes the cost entirely. Instead of asking you to move to a new account, it upgrades the account you already have. Your address stays the same. Your seed phrase stays the same. Your deposit addresses at exchanges stay the same. Nothing has to move, which is exactly why adoption spread so quickly: the upgrade is invisible to almost everyone who benefits from it. If you want the deeper account-abstraction picture, our smart-account field guide lays out how the pieces fit together.

That design choice also carries a warning, which the rest of this guide keeps returning to. When you skip the migration, you also keep everything about the old account, including the fact that a single private key still controls it. EIP-7702 hands your address new powers without handing it new protection.

Under the hood: the set-code transaction

The mechanism is a new transaction type, 0x04, sometimes called the set-code transaction. It carries an authorization list: one or more tuples of the form (chain_id, address, nonce, y_parity, r, s). Each tuple is a signature from an EOA saying, in effect, let my account run the code at this contract address. When the transaction is included, Ethereum writes a short marker into the account’s code slot.

That marker is the delegation designator: the three bytes 0xef0100 followed by the 20-byte contract address, 23 bytes in total. Any code that reads the account now sees those bytes and knows to execute the target contract’s logic in the account’s context. The signed authorization uses a dedicated prefix (the magic byte 0x05) so it cannot be confused with an ordinary transaction. The full specification, including these details, sits in the EIP-7702 document.

Two properties matter for everyday use. First, the delegation is revocable: sign a new authorization pointing at the zero address and the designator clears, returning the account to a plain EOA. Second, the delegation is tied to a chain through the chain_id field, with one sharp exception covered later: a chain_id of zero makes the authorization valid on every chain at once. Those two facts, revocability and chain scope, shape almost everything about how wallets and exchanges handle EIP-7702 in practice.

EOA, ERC-4337, and EIP-7702 side by side

It helps to see the three models next to each other. A plain EOA is what you started with. An ERC-4337 account is a purpose-built smart wallet at its own address. An EIP-7702 account is your existing EOA wearing a contract’s abilities. Crucially, the last two are not rivals: the reference EntryPoint contract that powers ERC-4337 added native EIP-7702 support in its v0.8 release, so many delegated accounts point straight at ERC-4337 infrastructure (eth-infinitism releases).

What your wallet can suddenly do

Once an address carries a delegation, the wallet software behind it can offer features that used to require a separate smart account. The most common ones:

• Batching: approve a token and swap it in one atomic transaction, so no open approval is left dangling for a drainer to find later.
• Gas sponsorship: let a dapp or a paymaster cover the network fee, or pay the fee in a stablecoin instead of holding ETH for gas.
• Session keys: grant a game or an automated agent a narrow key that can only do specific things and expires on its own.
• Guards and limits: cap how much can leave in one move, or require an extra check for large transfers.
• Recovery hooks: attach social-recovery or timelock logic to an address that never had any.

Gas abstraction is where users feel the change first. Circle’s paymaster lets an ERC-4337 or EIP-7702 account pay fees in USDC rather than ETH, live on networks including Arbitrum and Base, with a small surcharge on the sponsored gas (Circle). Bitget Wallet built the same idea directly on EIP-7702, letting users pay gas in USDT, USDC, or its own token across eight chains. Jamie Elkaleh, chief marketing officer at Bitget Wallet, told The Block that the integration “brings self-custody closer to the ease of centralized exchanges,” letting people “transact across chains without ever managing gas tokens.” That framing, a self-custody wallet that feels like an exchange account, captures why the feature spread.

Session keys are the other feature builders keep reaching for, and they matter most in games and automation. A traditional wallet forces you to approve every single action, which is fine for an occasional swap and miserable for a game that wants to move an item every few seconds. With a delegation, a game or an automated agent can be handed a narrow key that is allowed to do only a few specific things, up to a set limit, until it expires. The main key stays in your control; the session key is a leash, not a copy of it. That is the same pattern powering the crypto-and-AI agents that now hold scoped keys to spend on their owner’s behalf.

The same key is still the single point of failure

Here is the tradeoff hiding inside the convenience. Because EIP-7702 upgrades your existing account rather than replacing it, the private key that always controlled that account still controls it. The upgrade adds abilities; it does not add a second signer, a hardware barrier, or anything else standing between an attacker and your funds. If your key was the single point of failure before, it still is.

What changes is the blast radius. A thief who compromises a key no longer has to drain assets one clumsy transaction at a time. With a delegation, they can batch a sweep of every token in a single, cheap, atomic action. Taylor Monahan, a security researcher at MetaMask, has argued that this is not really an EIP-7702 problem at all: the root cause is the same one crypto has wrestled with since the beginning, users struggling to keep their private keys safe (Cryptopolitan). The feature makes a stolen key more dangerous, but it does not create the theft. A quieter class of key failure, weakly generated keys that can simply be guessed, gets the same amplification; we covered that in our look at crypto’s weak-key problem.

The lesson for users is blunt. EIP-7702 rewards good key hygiene and punishes blind signing more harshly than the old EOA did. Signing a delegation you cannot read, on a hardware screen that shows only a hash, is now one of the riskier things you can do with a wallet.

There is a deeper irony that security researchers keep pointing out. The exact capability that makes EIP-7702 useful to a defender, the ability to script an account so it can do several things in one signed action, is the same capability that makes it useful to an attacker. A recovery module that sweeps your funds to safety if your key is threatened and a drainer that sweeps them to a thief are, at the level of the code, nearly the same construct pointed in opposite directions. That is why the protocol cannot simply block the bad version: the mechanism is neutral, and the intent lives entirely in who holds the key and which contract they trusted.

CrimeEnjoyor and the drainer economy

Attackers noticed the amplification within days of Pectra. The trading firm Wintermute found that more than 97 percent of early EIP-7702 delegations pointed at the same reused sweeper bytecode, a copy-pasted contract researchers nicknamed CrimeEnjoyor. Roughly 2.88 ETH worth of authorizations covered about 79,000 addresses, and a single contract handled more than 52,000 of them (CoinDesk). The important nuance: these delegations were mostly attached to wallets whose keys had already leaked, and they were not very profitable, because the target wallets were already empty. It was automation layered on top of old thefts, not a new hole in EIP-7702.

The losses that did land came through phishing, not the protocol. One victim lost $1.54 million in a single delegation transaction disguised as a routine approval, and two 2025 cases together accounted for about $2.54 million. Even so, the broader trend ran the other way: wallet-drainer losses across all of crypto fell about 83 percent in 2025 to roughly $83.85 million, from nearly $494 million the year before, with victim counts down sharply too (Cointelegraph, citing Scam Sniffer). A peer-reviewed study accepted to the 35th USENIX Security Symposium put numbers on the malicious share: across roughly 3.66 million authorizations on seven chains through mid-2025, more than 63 percent were tied to malicious contracts, with 924 distinct malicious contracts confirmed and about $2.36 million in realized losses (USENIX Security 26). That headline share sounds alarming, but it counts transactions, and attacker contracts get reused far more often than legitimate ones. The same batching that helps a drainer can also be turned against ordinary traders in the mempool, a dynamic we unpacked in EIP-7702 and MEV.

The mechanics of these thefts are worth understanding, because they explain why the delegation is the accelerant rather than the cause. Established drainer kits such as Inferno Drainer and Pink Drainer learned to fold a 7702 authorization into the same malicious signing flow they already used for token approvals; one early sweep using the technique took about $146,551 (ChainPlay). A victim who signs a doctored prompt is not just approving one token; they are handing over a delegation that lets a contract sweep everything in one atomic transaction and pay for it out of the stolen funds. The wallet did nothing wrong, and neither did the protocol. The failure is the same forged signature that has drained wallets for years, now able to do more damage per click.

What exchanges had to change

Exchanges felt EIP-7702 in an odd place: their deposit addresses. A centralized venue usually assigns each customer a unique deposit address and later sweeps funds from it into cold storage. Those addresses are EOAs, and before Pectra they could only ever be EOAs. After Pectra, any address, including a deposit address, can suddenly carry a 0xef0100 designator and run code. An exchange that assumed its deposit addresses were inert now has to check.

The screening job is concrete: watch for the 23-byte delegation marker, decide whether a delegated contract is trusted before interacting with it, and make sure an automated sweep cannot be hijacked by code sitting at an address the exchange treated as passive. Custody providers responded with formal guidance. Arik Galansky, vice president of technology at Fireblocks, has stressed that a single malicious delegation is all it takes to compromise an account, so institutions should delegate only to fully audited contracts and keep EIP-7702 mostly to hot, limited-value wallets (Fireblocks). The blind-signing danger that made the Bybit theft possible, where signers approved something they could not read, applies directly to delegations too; our analysis of the Liquid Network hack is a reminder of how expensive an unreadable signature can get.

For institutions, the answer has been to pair EIP-7702 with multi-party computation rather than a single signing key. In an MPC setup no one machine ever holds the full private key, so the single-point-of-failure problem that worries Galansky is split across parties, while the delegation still layers on batching, gas sponsorship, and session limits. Fireblocks has described the combination as a form of mutual reinforcement, with MPC covering EIP-7702’s key-security gap and EIP-7702 giving MPC accounts the smart-account features they otherwise lacked (Fireblocks). At the custody layer the interesting question is rarely EIP-7702 on its own, but which key-management model sits underneath it.

The SEC, self-custody, and who counts as a broker

None of this changes who is holding your coins. An EIP-7702 delegation does not hand custody to a wallet developer or a paymaster; your key still signs, and the funds still sit at your address. That distinction matters for how United States regulators treat the software involved. Staff at the Securities and Exchange Commission have taken the view that software enabling transactions from a self-hosted wallet is not, by itself, acting as a broker (CoinDesk). A wallet that adds batching or gas sponsorship through a delegation is still self-custody software, not a custodian.

The regulated perimeter, in other words, sits where it always did: at the exchanges and custodians that hold customer assets, not at the protocol feature. Anti-money-laundering and travel-rule obligations attach to those intermediaries, not to your delegation. For self-custody users, the more immediate policy question in 2026 is tax reporting rather than broker status, an area moving quickly enough that we tracked it separately in our coverage of the year’s digital-asset tax fights. The upshot is that EIP-7702 leaves the legal shape of self-custody untouched while quietly expanding what a self-custodied account can do.

The multichain catch: one key, many chains, no free portability

Skipping the migration solved one problem and created a subtler one. Because a delegation is written into an account on a specific chain, upgrading your address on Ethereum mainnet does not upgrade it anywhere else. Set a delegation on mainnet and your Arbitrum copy of the same address is still a plain EOA until you authorize it there too. Same key, same address, different capabilities depending on where you are standing. Wallets have to track this per chain, and users who assume an upgrade follows them everywhere can be surprised.

The specification does offer a shortcut, and it is a double-edged one. Signing an authorization with a chain_id of zero makes it valid on every chain at once, which is convenient for deploying the same setup across many networks. It is also a replay risk: a single signature now applies everywhere, including chains you never meant to touch, so a careless zero-chain authorization can be reused against you. Careful wallets pin a concrete chain_id when they sign for exactly this reason.

This is where gas abstraction and the multichain reality meet. Bitget’s pitch that users can transact across chains without managing gas tokens works precisely because the wallet handles the per-chain plumbing for them: a delegation and a stablecoin paymaster on each network, presented as one smooth experience. The portability users feel is real, but it is manufactured by the wallet, not granted automatically by EIP-7702. The protocol gives you one key across many chains; it does not give you one upgrade across many chains.

How to read and reset your delegation

Because a delegation is visible on-chain and reversible, checking and clearing one is straightforward once you know where to look. If you have ever signed a suspicious prompt, or you just want to audit what your address is pointing at, work through these steps:

1. Look up your address on a block explorer such as Etherscan, or a dedicated tool like eip7702.app; a delegated account shows the 0xef0100 code prefix followed by a contract address.
2. Confirm that contract is one you trust, ideally your wallet’s official delegate, rather than an address that arrived through a random dapp prompt.
3. To clear a delegation, sign a fresh authorization pointing your account at the zero address; that removes the code and returns you to a plain EOA.
4. Remember that tools such as revoke.cash can display an active delegation but cannot remove it for you; only a new authorization from your key can.
5. If the delegation is malicious, treat the private key itself as compromised and move every asset to a brand-new wallet, because a reset does not undo a leaked key.

That last point is the one people get wrong. Revoking a bad delegation feels like fixing the problem, but if an attacker set it, they had your key, and they can simply set it again. Resetting is hygiene; migrating to a fresh key is the cure.

Adoption by the numbers

Raw counts make EIP-7702 look enormous, and they need a caveat. Trackers like BundleBear record more than 250 million cumulative authorizations, but the majority of those are automated sweeper delegations tied to already-compromised keys rather than distinct users, so the headline number overstates real adoption. The steadier figures are roughly 59 million addresses carrying a live delegation and more than 106 million set-code transactions to date.

Filter out the sweepers and the picture is healthier than it looks. Millions of addresses delegate to legitimate wallet implementations, with Bitget Wallet, MetaMask, and Ambire among the most-used delegate targets, and exchanges such as OKX and WhiteBIT were early to authorize their own contracts. Industry estimates put the total number of smart wallets across the ecosystem above 200 million when ERC-4337 accounts are counted alongside EIP-7702 delegations. The signal underneath the noise is that the feature moved from novelty to default plumbing in barely more than a year.

The gap between the headline count and real usage is itself the most useful thing to understand about EIP-7702 adoption. Because every leaked-key sweeper shows up as an authorization, the cumulative figure is inflated by exactly the activity you would least want to celebrate. The healthier signals are the counts that are hard to fake: distinct wallets delegating to audited, reputable implementations, and the steady climb of set-code transactions that carry genuine batched actions rather than a one-time drain. By that measure EIP-7702 is not the loudest upgrade of the cycle, but it may be the most quietly load-bearing, sitting under a large share of everyday wallet transactions without most users ever seeing its name.

The roadmap: Fusaka, Glamsterdam, and the migration still coming

EIP-7702 was always described by its own authors as a bridge, not a destination. The longer plan is native account abstraction, where smart-account behavior is built into the protocol rather than bolted onto an EOA. Getting there runs through Ethereum’s upgrade schedule.

Fusaka activated on December 3, 2025, bringing PeerDAS and cheaper data availability that lowers the cost of the layer-2 activity where many smart accounts live (CoinDesk). Next comes Glamsterdam, whose headliners are enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928); it is scheduled to fork the Sepolia testnet on October 6, 2026, with mainnet targeted for the fourth quarter but not yet dated (ethereum.org). The block-space economics driving that work overlap with the fee dynamics we tracked as Glamsterdam hit testnet. Native account abstraction itself, packaged as EIP-8141, is being lined up for a later fork nicknamed Hegota, likely in 2027 (EthDaily).

The people building this are candid that it is unfinished. Marius van der Wijden, an Ethereum core developer, cautioned early on that EIP-7702 remained “a very early proposal, so we need to evaluate all the rough edges” (DL News). In the same reporting, MetaMask product lead Alex Jupiter framed the sequence, from ERC-4337 to EIP-7702 to native abstraction, as one unified account-abstraction roadmap rather than a series of competing standards. EIP-7702 is the part of that roadmap users already have.

The bottom line

EIP-7702 is the rare upgrade that succeeded by asking for nothing. It gave hundreds of millions of Ethereum addresses the ability to batch actions, sponsor gas, run session keys, and enforce limits, all without a new address, a fund transfer, or a moment of user friction. That is why wallets adopted it in months and exchanges had to scramble to keep up. Same address, same key, new powers.

The catch is the mirror image of the benefit. Because nothing migrated, the private key that always guarded your account still guards it alone, and a delegation makes a stolen key faster to exploit, not harder. The abilities are new; the responsibility is old. Read what you sign, delegate only to contracts you trust, keep the key that controls all of it as safe as the account is now capable, and EIP-7702 is what it was designed to be: the smart-account upgrade you never had to move for.

Frequently Asked Questions

What is EIP-7702 in simple terms?

EIP-7702 is an Ethereum upgrade, live since the Pectra hard fork in May 2025, that lets an ordinary wallet address (an externally owned account) temporarily borrow the code of a smart contract. In practice it gives your existing address smart-account features like transaction batching, gas sponsorship, and spending limits, without you creating a new account or moving any funds.

Does EIP-7702 change my wallet address?

No, and that is the whole point. Your address, your seed phrase, and your private key stay exactly the same. EIP-7702 attaches a delegation to the account you already have, which is why exchanges keep using your old deposit addresses and why the upgrade needed no migration.

Is EIP-7702 safe to use?

The upgrade itself has not been shown to contain a protocol bug, and delegating to your wallet’s audited default contract is considered reasonable. The real risk is not new: if someone steals your private key, EIP-7702 lets them drain the account faster and more cheaply. It rewards good key hygiene and punishes blind signing, but it does not create a weakness that careful users did not already face.

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

You reset it by signing a new authorization that points your account at the zero address, which clears the delegated code. Tools such as revoke.cash can display an active delegation but cannot remove it for you. If the delegation was set by an attacker, revoking is not enough, because the underlying key is compromised, so the safe move is to transfer everything to a new wallet.

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

ERC-4337 builds smart accounts as separate contracts with their own addresses, so using it means deploying a new account and moving into it. EIP-7702 upgrades the address you already control, in place, with a single signed transaction. The two are designed to work together: many EIP-7702 accounts delegate to contracts built on the ERC-4337 stack, and Ethereum’s longer-term plan folds both into native account abstraction.

Marcus Okafor covers wallets, account abstraction, and exchange infrastructure for HOGE Wire.