EIP-7702 in 2026: What Your Wallet Really Does Now

Nearly a year and a half ago, on 7 May 2025, the Pectra upgrade switched on a short piece of Ethereum plumbing called EIP-7702. It arrived without a launch party: no new token, no airdrop, and for most people no visible change at all. Yet in the months since, it has quietly rewired what an ordinary Ethereum address can do, letting a plain wallet borrow the powers of a smart contract for the length of a single transaction and then hand them back. By late September 2026, on-chain dashboards counted tens of millions of live delegations sitting on everyday accounts.

This piece is a checkpoint. With the Glamsterdam upgrade due to reach the Sepolia testnet on 6 October and the price of ETH hovering around $2,700, it is a good moment to ask the questions a wallet holder actually cares about: what does EIP-7702 really do, has it lived up to the promises made for it, which wallets and exchanges support it, and what should you do about the delegation that may already be sitting on your address.

EIP-7702 in one sentence

EIP-7702 lets an externally owned account, the technical name for a normal private-key wallet, point at a smart contract and run that contract’s code as if it were the account’s own, without giving up its address or its key. The formal title is set EOA account code. In plain terms, your wallet keeps the address and seed phrase you already have, but it can temporarily behave like a programmable smart-account wallet: bundling several steps into one confirmation, letting someone else pay the gas, or handing an app a narrow, time-limited key. That is the whole idea, and it is deliberately modest. Its importance is that it finally brought account-abstraction features to the hundreds of millions of ordinary addresses that were never going to move to a brand-new contract wallet.

That modesty is the point. Ethereum already had a mature smart-account standard, but using it meant deploying a fresh contract and moving your assets into it, a step most people were never going to take. EIP-7702 met users where they were. If you have held the same address for years, the one printed in old invoices and tied to your ENS name, you can gain batching and gas sponsorship on that exact account without touching your balance or your backups. That is why adoption climbed so fast, and also why the risks are worth understanding rather than waving away.

The set-code transaction, step by step

The mechanism is a new transaction type, 0x04, nicknamed the set-code transaction. It carries an authorization list, and each authorization is a small tuple the account owner signs: a chain id, the address of the contract to delegate to, and a nonce. The signature is tagged with a magic byte (0x05) so it can never be replayed as an ordinary transaction. When the transaction lands, the network writes a 23-byte marker into the account: the prefix 0xef0100 followed by the delegate contract’s 20-byte address. That marker is the delegation designator, and from then on any code that inspects the account sees it pointing at the delegate.

Two properties of that design drive everything that follows. First, it is revocable: sign a fresh authorization pointing at the zero address and the account reverts to a plain EOA. Second, a delegation is tied to a specific chain unless you set the chain id to 0, which makes the authorization valid everywhere at once. That option is convenient and also a footgun, because the same address can end up pointing at different code on different chains. The full rules live in the EIP-7702 specification, and they are worth knowing, because the good and the bad both flow from those 23 bytes.

A concrete example makes the flow easier to picture. Say you want to swap a token on a decentralized exchange. On a plain EOA that is two transactions: approve the token, then swap, with a window in between where a malicious contract could exploit the open approval. With a delegated account, your wallet can send one set-code transaction that both installs the delegate and runs approve-then-swap atomically, so the two steps succeed or fail together and no approval is left dangling. The delegate contract supplies the batching logic; your key simply authorizes it. Nothing about your address or your recovery phrase changes in the process.

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

To see where EIP-7702 fits, it helps to line it up against the two account models that came before it.

ERC-4337, finalized in March 2023, delivered account abstraction entirely off-protocol through an alternative mempool of user operations, bundlers, and a singleton EntryPoint contract; its version 0.8 added native support for 7702 accounts. The point of the table is that EIP-7702 is not a replacement for 4337 but a bridge to it: a delegated EOA can use the same infrastructure without anyone deploying a new wallet or moving a balance. In practice the two increasingly travel together, which is why the adoption figures for each keep climbing in parallel.

The road here: from EIP-3074 to a one-line upgrade

Account abstraction has been discussed on Ethereum since 2016. An earlier attempt, EIP-3074, introduced new opcodes that let a trusted contract act for an EOA; it was ultimately set aside as too invasive to the protocol. ERC-4337 then shipped the idea without touching consensus at all, at the cost of requiring a brand-new contract account. EIP-7702 is the minimal compromise between those poles: it reuses the 4337 tooling, changes as little as possible, and upgrades the address you already hold.

The lineage matters because it explains 7702’s deliberate limits. EIP-3074 would have handed a sponsor contract broad authority over an EOA, which raised hard questions about trust and about locking the protocol into a single design. The authors of 7702 chose the opposite tack: change as little as possible, borrow the account model that already worked, and leave the door open to a fuller native solution later. The result is less elegant than a clean-sheet design and more useful than waiting for one, a trade-off Ethereum has made before.

Ethereum core developer Marius van der Wijden described 7702 as something that allows existing wallets to emulate the functions of account-abstraction wallets, while cautioning that the community still needed to evaluate all the “rough edges.” MetaMask senior product manager Alex Jupiter, in the same reporting, framed the win differently, arguing that 7702 gave Ethereum “one unified Account Abstraction roadmap” rather than competing standards. Both readings have held up: the upgrade is genuinely useful and genuinely unfinished.

What a delegated account can suddenly do

The capabilities are the reason anyone bothered. The first is batching: a delegated account can approve a token and swap it in one atomic transaction, so there is no dangling approval left behind and no half-finished state if a step fails. That convenience does not change the tax treatment, though; each on-chain action inside a batch is still its own event, a point worth remembering given how little of this the average tax form anticipates, as our look at DeFi taxes in 2026 laid out.

The second is gas sponsorship. A dapp or a paymaster can cover the fee, so a new user can transact before owning any ETH. Circle’s paymaster, for example, lets an account pay gas in USDC, charging roughly a 10% surcharge since the introductory waiver ended on 1 July 2025. The third is session keys: you can hand a game or an application a narrow key that is limited by time and amount and can be revoked, so you are not signing every move. That capability is what makes 7702 interesting for software agents, the same design tension we examined in asking whether you can trust an Eliza agent with a wallet. Jamie Elkaleh, chief marketing officer at Bitget Wallet, argued that features like these bring self-custody closer to the ease of a centralized exchange, letting people transact across chains without juggling gas tokens.

The fourth capability is recovery and automation. Because a delegated account can run arbitrary contract logic, it can support features a bare EOA cannot: spending limits, allow-lists of trusted destinations, guardians who can help recover access, or standing permissions that let an application act within tight bounds. None of this is automatic; it depends on the delegate contract offering those modules and on the wallet exposing them. But it is the ingredient that turns a single-key account into something closer to a configurable vault, which is what the consumer pitch for smart accounts has always been about.

Games are where this stops being abstract. A blockchain game that asked players to sign a wallet popup for every move, every crafted item, and every in-match trade would be unplayable, which is a large part of why Web3 titles were slow to feel like games at all. A session key changes that: the player grants a delegated account permission to make a bounded set of moves for a set period, and the game runs smoothly until the permission expires or is revoked. The risk travels with the convenience, since a too-broad session key is a standing invitation to anyone who steals it, but the design is the closest thing yet to the invisible wallet that on-chain gaming has always needed.

The adoption numbers, and the CrimeEnjoyor asterisk

Raw adoption looks enormous, and the numbers need care. The tracker BundleBear counted more than 258 million cumulative authorizations by late September 2026, across over 108 million set-code transactions. That cumulative figure is heavily inflated by automated sweeper bots re-signing the same addresses, so it overstates real usage. The meaningful number is live delegations: about 61.8 million accounts currently carry an active 7702 designator. For scale, the ERC-4337 side of the same dashboard shows more than 1.3 billion user operations across roughly 68 million accounts.

The asterisk is the reason the cumulative number is so noisy. In the first weeks after Pectra, the trading firm Wintermute found that more than 97% of early delegations pointed at a single family of identical sweeper contracts nicknamed CrimeEnjoyor. That code automatically forwards any ETH sent to an already-compromised address to the thief. It sounds alarming, but it is not a flaw in 7702 and the contract itself is harmless to touch; it is deployed only after a private key has already leaked, as a way to squeeze value out of a dead account. The lesson for reading adoption data is simple: look at live delegations, not the cumulative headline.

Strip out the sweeper noise and the honest reading is still striking. Tens of millions of ordinary accounts have quietly become programmable in under eighteen months, with no migration event and no token to chase. Few protocol changes reach that many users that quietly, and fewer still do it without asking anyone to move a single coin.

Does your wallet actually support it?

Being on Ethereum does not mean your wallet lets you use 7702, and support is uneven. The table below summarizes where the major consumer wallets stood in late September 2026.

A few caveats sit behind the tidy grid. Ambire shipped the first 7702 wallet and keeps its delegate contract deliberately small; MetaMask exposes a per-chain switch so you can move an account back and forth; Uniswap’s Calibur is notable for being non-upgradeable, which means the code cannot change under you. Support for revoking a delegation you did not set yourself is still inconsistent across wallets. And the pool of delegated users keeps growing partly by default: Alchemy’s wallet infrastructure began delegating by default on 21 September 2026, so more people now carry a delegation without having deliberately chosen one.

Promise versus reality, one cycle in

EIP-7702 was sold on a handful of concrete promises. Here is where each one stands after the better part of a year and a half in production.

The honest summary is that the user-experience promises have largely come true, while the security promises are conditional. Batching, sponsorship, and session keys are in daily use. Recovery and safety, by contrast, depend entirely on which contract you delegate to and on whether you understand what you are signing. That split, real convenience paired with unchanged key risk, is the story of 7702 so far, and it is the reason a checkpoint like this one is worth doing rather than simply celebrating the adoption curve.

The row worth dwelling on is the cross-chain one, because it is the most misunderstood. People assume that upgrading their account on Ethereum upgrades it everywhere, and it does not. A delegation is written per address and per chain, so the same wallet can be a smart account on mainnet and a plain EOA on Arbitrum at the same moment. The chain-agnostic shortcut, setting the chain id to zero so a single authorization applies universally, saves a step but invites a subtle danger: if the delegate address holds different code on another chain, you have quietly pointed your account at something you never checked. The safe habit is to treat each chain as its own decision, and to check each one before assuming your upgrade followed you there.

The security ledger: blind signing, phishing and the dark side

The most cited warning comes from a peer-reviewed study presented at the 35th USENIX Security Symposium. Researchers led by Mingyuan Huang analyzed 3,664,166 EIP-7702 authorizations across seven chains through the middle of July 2025 and found that more than 63% were tied to malicious contracts, with 924 distinct malicious contract accounts confirmed by hand, roughly $2.36 million in realized losses, and about $10.14 million in further exposure. The figure needs context: the 63% counts transactions rather than users or dollars, because attacker contracts are reused far more often than legitimate ones, and the underlying problem is wallet UX and blind signing, not a defect in the protocol.

Blind signing is the crux. Because a 7702 authorization is just a signature over a compact tuple, a user who approves a request without a wallet that decodes it clearly may not realize they are pointing their account at hostile code. The industry answer is clear signing: standards and wallet features that render, in plain language, exactly what a signature will authorize before you approve it. Where clear signing is present and users read it, the batch-approval scams the studies catalog become far harder to pull off; where it is absent, a single tap can hand over everything. This is part of why hardware-wallet support for 7702 has lagged, since showing a human-readable delegation on a small screen is genuinely hard, and vendors would rather ship nothing than ship a confusing approve button.

The wider picture is less grim than the headline suggests. Scam Sniffer reported that total wallet-drainer losses actually fell about 83% in 2025 to roughly $84 million, even as two EIP-7702 batch-signature phishing cases in August 2025 cost their victims about $2.54 million between them. The through-line is that 7702 does not invent a new way to steal a key; it raises the cost of one careless signature, because a single approval can now authorize a contract to act for your entire account. It also matters which contract you point at, and an audit only proves so much: a review is a snapshot at one commit, and modules added later sit outside it, the same limits we traced in our piece on bug-bounty payouts across ecosystems.

How to see and revoke a delegation yourself

Because a delegation is state that persists until you change it, hygiene matters. Checking and clearing one is straightforward once you know where to look.

• To check, look up your address on a block explorer. A delegated account shows code beginning with 0xef0100 followed by the delegate’s 20-byte address; a plain EOA shows none.
• Revoke.cash added a delegations view that shows what your account points at, but it is inspect-only and cannot revoke on your behalf.
• To revoke, sign a fresh authorization pointing at the zero address with a higher nonce. That clears the code and the code-hash.
• Be aware it does not clear the delegate’s stored state, so treat a delegation like an upgradeable contract, not a light switch.
• In MetaMask you can revert an account from the Account Details screen, but you must do it once per chain.

One practical wrinkle: a compromised account with no ETH left cannot pay to revoke itself. Community tools have appeared that perform the revocation in sponsored mode, where a third party covers the gas, so even a drained account can be cleaned. The broader habit worth adopting is to review your delegations the way you already review token approvals, on every chain you have touched, rather than assuming a single revocation on Ethereum mainnet covers all of them.

How exchanges and custodians treat a delegated address

EIP-7702 quietly broke an assumption a lot of exchange software relied on: that an address either is a contract or is not. A delegated EOA now carries code, so a naive is-this-a-contract check can misread it, and deposits from smart-account wallets can be flagged or held. The fix that has spread across deposit systems is to read the 23-byte designator directly and credit delegated wallets while still screening genuine contracts, rather than blocking anything with code attached.

The detail is more than cosmetic for anyone who moves funds between self-custody and an exchange. An exchange that treats every address with code as a contract might reject a perfectly normal deposit from a smart-account wallet, or credit it to the wrong internal ledger. One that reads the designator correctly can tell a delegated EOA apart from a genuine contract and route the deposit properly. As delegation-by-default spreads, the share of ordinary users arriving with code on their address only grows, which is why deposit-screening logic has had to catch up quickly across the industry.

On the institutional side, custody providers are pairing 7702 with their existing key management rather than replacing it. Fireblocks, for instance, published a security-first approach that combines MPC-based signing with the delegation model, so that turning an account into a smart account does not weaken the controls around the key. The pattern to notice is that 7702 does not remove the operational questions exchanges and custodians already face; it adds a new field they have to parse before crediting your money.

Where the SEC stands on smart-account wallets

For US readers, the most relevant regulatory signal arrived in April 2026, when the SEC’s Division of Trading and Markets issued a staff statement that software and user interfaces enabling self-custodial crypto-wallet transactions are not, on their own, acting as brokers. Read plainly, that means upgrading your EOA into a smart account does not drag a self-custody wallet into broker-dealer regulation. The line the staff drew is about who controls the funds, not about the code your address happens to point at.

The caveat is that this is staff guidance about self-custody, and it does nothing to soften the rules for custodial businesses. An exchange holding customer assets, or a service that can move funds on a user’s behalf, remains squarely within the regulatory perimeter. In other words, the smart-account upgrade itself is not what draws scrutiny; control over other people’s money is, and that distinction is likely to outlast any particular piece of guidance.

None of this settles the larger questions circling the industry heading into the fourth quarter, from stablecoin rules to the status of staking and of tokens more broadly. What the staff statement does is narrow one of them: it takes the fear that merely making a wallet programmable could be treated as running a brokerage and sets it aside. For wallet builders, that clarity is worth more than it sounds, because it lets them ship smart-account features to US users without first testing an untested legal theory. The perimeter still exists; it just sits where it always did, around custody and control rather than around code.

What comes next: the native-AA split and Glamsterdam

Two threads will shape the next year. The first is native account abstraction, the plan to bake these features into the protocol so a delegation becomes invisible plumbing. On 15 September 2026 the effort to align Ethereum’s and Base’s native-AA proposals broke down in public. Ethereum is pushing EIP-8141, a frame-transaction design co-authored by Vitalik Buterin and tagged as a must-ship item for the Hegota fork; Base has a rival keystore-based proposal, EIP-8130, part of its Cobalt upgrade and still experimental. Derek Chiang, founder of the account-abstraction firm ZeroDev, explained the divergence bluntly, saying that while the teams identified a number of technical solutions, each one required one side or the other to compromise at least a little on its core goals. Until one of these lands on mainnet, EIP-7702 remains the bridge everyone actually uses.

The second thread is the Glamsterdam upgrade, due on the Sepolia testnet on 6 October 2026 at 13:53 UTC, with a mainnet target somewhere in the fourth quarter that has not been dated. It is easy to conflate the calendars, so it is worth being clear: Glamsterdam is about throughput, not account abstraction. Its headline features are enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928), and developers have already flagged a builder-auction withholding risk to watch on the testnet. If you were hoping the fork would make your wallet smarter, it will not; that work is happening on a separate track.

Behind both threads sits a quieter shift. As account abstraction wins, trust migrates from your seed phrase to a stack of operators, the bundlers, paymasters, and authors of the contract you delegate to, and that stack concentrates, a dynamic we mapped in our piece on the smart wallet’s new middlemen. It rhymes with what has happened elsewhere on Ethereum, where the pull toward a handful of large operators has made solo staking feel like an act of resistance rather than a default. Convenience has a way of centralizing the thing it makes easy.

The bottom line

A year and a half in, EIP-7702 has done what its designers hoped and little more, which is close to the best outcome an infrastructure change can claim. It gave existing wallets real superpowers, batching, sponsorship, and session keys, without asking anyone to migrate or surrender their key. It did not make self-custody safe by itself, and it will not; the private key is still the thing that matters, and a smart account simply raises the stakes of every signature. The practical takeaways are modest and worth acting on: know whether your wallet is delegated, know which contract it points at, revoke what you no longer use, and read what you sign. The plumbing is quietly excellent. The responsibility, as ever, stays with you.

Frequently Asked Questions

Is EIP-7702 safe to use?

The upgrade itself is safe; the real risk is a compromised key or a careless signature. A delegation only does what the contract it points at is programmed to do, so the questions that matter are which contract your wallet delegates to and whether you blind-sign. Overall wallet-drainer losses fell sharply in 2025, but 7702 raises the stakes of a single bad approval because one signature can authorize a contract to act for your whole account.

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

Sign a new authorization that points at the zero address, which most wallets expose as a switch-back or revert-to-EOA option. Do it once per chain, and remember that it clears the code but not the delegate’s stored state. Revoke.cash can show you what your account points at, but it cannot revoke the delegation for you.

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

ERC-4337 is a full smart-account standard that requires deploying a brand-new contract wallet at a new address. EIP-7702 upgrades the address you already have, keeping your key and history intact. They are complementary rather than competing, because a 7702 account can reuse the same 4337 infrastructure of bundlers and paymasters.

Does turning my wallet into a smart account change my keys or address?

No. Your address and private key stay the same. A delegation only points your existing account at contract logic for as long as you leave it in place; it is revocable at any time and does not move or migrate your funds.

Which wallets support EIP-7702 in 2026?

MetaMask, Ambire, Bitget Wallet and Uniswap’s wallet all support it, while Coinbase’s Base Account uses the different ERC-4337 contract-account model and hardware-wallet support depends on clear-signing. Before relying on it, check whether your wallet lets you toggle a delegation on and revoke it per chain.

By Yuki Tanaka, wallets and infrastructure correspondent at HOGE Wire.