EIP-7702 in 2026: Your Wallet Got Smart, Exchanges Didn’t

On 7 May 2025, Ethereum’s Pectra upgrade shipped a change that sounded small and turned out to be the largest shift in how ordinary wallets work since the network launched. A single new transaction type, defined by EIP-7702, let an externally owned account (EOA) point itself at a smart contract and, for as long as that pointer is set, behave like one. No migration. No new address. No seed phrase to rewrite. The same key you already held could suddenly batch several actions into one transaction, pay gas in a stablecoin, hand a game a limited session key, or be recovered by people you trust.

Seventeen months later, the gap EIP-7702 opened is hard to miss. On 6 October 2026, the day this piece ran, Ethereum’s next upgrade, Glamsterdam, forked the Sepolia testnet at 13:53:36 UTC, a reminder that the base layer keeps moving while the wallet layer sprints ahead of almost everything built to watch it. Wallets adopted 7702 within weeks. Exchanges, hardware devices, and compliance tooling are still catching up. This is the explainer for where the standard actually stands: what it does, what it lets your wallet do, why the venue on the other end of your deposit may not see your account the way you do, and what the fight over native account abstraction means next. With ETH changing hands around $2,700, the stakes are less about price and more about who controls the logic that moves your balance.

EIP-7702 in one sentence

EIP-7702, titled “Set EOA account code,” adds a transaction type that lets an externally owned account install a pointer to a smart contract, so the account can run that contract’s logic while keeping its original address and private key. That is the whole idea. Everything else, the batching, the gasless swaps, the session keys, is a feature of whatever contract your account points at, not of the standard itself.

The proposal was written by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett (who works under the handle lightclient), and it shipped as part of Pectra, Ethereum’s spring 2025 hard fork. The crucial word is delegation. Your account is not converted into a contract and it is not abandoned for a new one. It temporarily delegates its behavior to code at another address, and that delegation can be changed or removed at any time by sending another transaction. Think of it less as moving house and more as handing your existing house a new set of rules that you can tear up whenever you like.

What “set code” actually does

Under the hood, EIP-7702 introduces transaction type 0x04, sometimes called the set-code transaction. It carries a field the earlier types never had: an authorization list. Each entry in that list is a tuple of a chain ID, the address of the contract to delegate to, the account’s nonce, and a signature. The account owner signs a short message (a magic byte followed by the chain ID, delegate address, and nonce) to prove consent, and anyone can then include that authorization in a transaction and even pay the gas for it.

When the transaction lands, the account’s code is set to a 23-byte marker: the bytes 0xef0100 followed by the 20-byte address of the delegate contract. That marker is the delegation designator. From then on, any call to your account runs the delegate’s code in the context of your account, with your balance and your storage. Ask the chain for the code size of a delegated account and it returns 23, the length of that pointer. Set the chain ID to zero and the authorization is valid on every chain at once, which is convenient and, as we will see, a genuine footgun. To undo the whole thing, you sign a new authorization pointing at the zero address, which clears the pointer.

A subtlety worth knowing is how 7702 coexists with an old safety rule. Ethereum has long enforced that an account carrying code cannot be the sender of a transaction, a protection (EIP-3607) that stops contracts from impersonating EOAs. EIP-7702 carves out a careful exception so that a delegated account, despite now holding those 23 bytes of code, can still initiate its own transactions the way an EOA always could. That exception is what makes the whole thing usable, and it is also the precise detail that older tooling, written before the exception existed, tends to get wrong.

A concrete example makes it click. Before 7702, swapping a token on a decentralized exchange usually meant two separate transactions: one to approve the spender, one to execute the swap, with a dangerous gap in between where the live approval sits exposed. With a 7702 delegate that supports batching, the approve and the swap travel together in a single atomic transaction that either fully succeeds or fully reverts. The gap disappears. So does the ritual of keeping a little ETH on hand purely to pay for gas, if your delegate routes fees through a paymaster.

EOA, ERC-4337, EIP-7702: three roads to a smart account

Account abstraction is the umbrella idea that your account should be programmable rather than hard-wired to a single key. There are now three ways an Ethereum account relates to that idea, and confusing them is the most common mistake readers make. A plain EOA is controlled by one private key and can only do what the protocol hard-codes. A full ERC-4337 smart account is a contract from birth, with its own deployment, that never had a private key of the familiar kind. An EIP-7702 account is the hybrid: a normal EOA that borrows a contract’s code without giving up its key.

The difference matters because it decides who can send transactions, how recovery works, and what an exchange or an auditor sees when they look at the address. The table below lays out the three side by side.

The short version: ERC-4337 built the smart-account machinery (bundlers, paymasters, a singleton EntryPoint contract) off to the side, without touching Ethereum’s consensus rules. EIP-7702 reached back and let the hundreds of millions of existing EOAs opt into that machinery without redeploying. The two are complements, not rivals, and the EntryPoint v0.8 release added native 7702 support so a delegated EOA can plug straight into the 4337 world.

The road from EIP-3074

EIP-7702 did not arrive from nowhere. For years the leading plan to make EOAs programmable was EIP-3074, which proposed two new opcodes (AUTH and AUTHCALL) and a pattern of trusted “invoker” contracts. It was powerful, but it introduced new primitives that would have been awkward to unwind once native account abstraction arrived, and core developers worried about locking the ecosystem into a design that did not point cleanly at the endgame. Buterin floated 7702 as a smaller, forward-compatible alternative in 2024, and it replaced 3074 in the Pectra lineup within weeks.

Marius van der Wijden, an Ethereum core developer, described the design plainly to DL News: the proposal “adds a new transaction type 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.” Alex Jupiter, a senior product manager at MetaMask, framed the upside to the same outlet, calling 7702 a step toward “one unified Account Abstraction roadmap” rather than a fork in it. That framing has held up: 7702 is the bridge, not the destination.

What your wallet can suddenly do

The practical payoff shows up in four places. The first is batching, already described: approve and swap, or claim and stake, or mint and list, all collapse into one atomic transaction. The second is gas abstraction. A paymaster can cover your fees so you never hold the native token, or let you pay in a stablecoin instead; Circle’s paymaster, for example, lets users settle gas in USDC. For anyone who has ever tried to explain to a newcomer why they need a few dollars of ETH before they can spend their dollars of USDC, this is the single most humane change 7702 enables.

The third is session keys. A delegate can grant a narrowly scoped key that is allowed to do only certain things, for a limited time, up to a spending cap. That is the feature that makes blockchain games and on-chain AI agents tolerable, because you can let an app act on your behalf for an afternoon without handing it the keys to everything you own. The fourth is recovery. Lose a traditional seed phrase and the funds are gone forever; a 7702 delegate can wire in social recovery or a backup signer, which is why so much of the renewed interest in wallet UX without a seed phrase runs through this standard.

Jamie Elkaleh, chief marketing officer at Bitget Wallet, which integrated 7702 to let users pay gas across several chains in stablecoins, told The Block the appeal in one line: the standard “brings self-custody closer to the ease of centralized exchanges.” That sentence is the whole wallet-versus-exchange story in miniature, and it is where the trouble starts.

Adoption by the numbers, and the CrimeEnjoyor asterisk

By 6 October 2026, the on-chain counters looked enormous. The analytics dashboard BundleBear recorded more than 262 million cumulative authorizations, over 110 million set-code transactions, and roughly 63.8 million live delegations across chains. Those numbers dwarf almost every other adoption metric in Ethereum’s history, which is exactly why they need an asterisk.

The cumulative figure counts every authorization ever signed, including an industrial volume of automated noise. Shortly after Pectra, the analytics desk at Wintermute found that more than 97 percent of early delegations pointed at near-identical copies of one sweeper contract, nicknamed CrimeEnjoyor, that instantly drains an already-compromised account. As Wintermute explained to CoinDesk, that is not a flaw in 7702: the sweepers are deployed after a key is already stolen, as a way to vacuum funds the moment they arrive, and the contract itself is harmless to a healthy account. The number to watch is live delegations, the count of accounts that currently have a pointer set. Even deflated, tens of millions of real, functioning smart-ish EOAs is a staggering amount of behavior change for seventeen months.

Does your wallet support it?

Support arrived unevenly, and the delegate contract your wallet points you at is a real trust decision, because its code runs with your balance. Ambire shipped the first production 7702 wallet. MetaMask, which serves tens of millions of users, routes its smart-account features through a delegate it calls the EIP7702StatelessDeleGator, part of a delegation framework audited by Cyfrin. Uniswap built its own delegate, Calibur, as a deliberately non-upgradeable singleton that was audited by OpenZeppelin. Bitget Wallet leaned into multichain gas abstraction. The table sorts out who does what.

One row deserves emphasis because it trips people up constantly. Coinbase’s Base Account is a smart account, but it is an ERC-4337 contract account, not a 7702-delegated EOA. “Smart account” is an umbrella, and two wallets under it can take completely different roads. When you read that a wallet is “smart,” the useful next question is always which road: a contract from birth, or your old key wearing a contract’s code.

The exchange blind spot

Here is the thesis of this whole piece. For most of Ethereum’s life a simple rule held: an address either had code (a contract) or it did not (an EOA), and a great deal of exchange and custody tooling quietly assumed that an account with code is a contract and therefore not a user-controlled sender. EIP-7702 breaks that assumption cleanly. A delegated EOA has code (those 23 bytes) and is still a user-controlled account that can initiate its own transactions. Software that treated “has code” as a synonym for “not a user wallet” now has a blind spot.

The sharpest edge is the deposit address. When you withdraw to a delegated EOA, or deposit from one, the venue’s systems see an account whose code begins with 0xef0100. A careful exchange reads those bytes, identifies the delegate contract behind them, and decides whether it trusts that contract before crediting or forwarding anything. A careless one either rejects the deposit, mis-credits it, or, in the worst case, interacts with an auto-forwarding delegate that redirects funds away from where the exchange expected them to settle. Screening the delegate, maintaining an allowlist of known-good delegate contracts, and handling the 23-byte marker correctly are now basic operational hygiene, and the industry is unevenly good at them.

Institutional custody has its own version of the puzzle. Custodians that secure keys with multi-party computation can layer 7702 delegation on top, keeping the MPC key management they already trust while gaining programmable execution; the trade-offs there are the same ones covered in our look at the cryptography under your wallet. The uncomfortable summary is that your self-custodial wallet became programmable faster than the venues you move money through learned to read the new accounts. Elkaleh’s line about self-custody matching the ease of an exchange cuts both ways: the wallet caught up to the exchange on convenience, and the exchange now has to catch up to the wallet on comprehension.

Hardware wallets and the four approaches

Hardware wallets sit in a similar bind, and the Ethereum Foundation has spelled out their options directly. Its Pectra documentation lays out four approaches a hardware wallet’s companion app can take to 7702. The lazy approach does nothing, since the EOA still works as before. The aware approach checks the account’s code, tells the user a delegation is in place, and optionally offers to remove it. Common delegation means the provider whitelists known delegate contracts and supports them in its software. Custom delegation means the provider ships its own delegate contract with full ERC-4337 support.

The reason hardware vendors move slowly is blind signing. A delegation authorization and the batched calls that follow are complex payloads, and a device that can only show a user a hash is asking them to approve something they cannot read. That is precisely the surface drainers exploit, so the serious work in hardware is clear signing: rendering, in human terms on the device screen, exactly what a 7702 authorization will do before the user approves it. Standards such as ERC-7730 for structured signing data exist for this, but coverage across the delegate ecosystem is still partial, which is why “varies, cautious” is the honest row in the table above.

The security ledger

Every power 7702 grants is also a power an attacker would like to borrow. The headline worry is the one-signature drain. Because a single authorization can install arbitrary logic, a phishing page that convinces you to sign one innocuous-looking message can delegate your account to attacker code that then moves funds without asking again. Worse, the delegation persists, which creates a temporal gap: the thief can install the pointer today and wait until your balance is worth draining.

Research presented at the USENIX Security Symposium and summarized by NewsBTC found that, in its sample, 63 percent of 7702 authorization transactions were linked to malicious contracts, tied to more than $2.3 million in confirmed thefts, with established drainer kits such as Inferno, Pink, and Angel shipping 7702-flavored modules. Set against that, the broader trend is encouraging: Scam Sniffer reported that wallet-drainer losses across the ecosystem fell about 83 percent in 2025, even as individual 7702 phishing victims lost sums as large as $1.54 million in single incidents.

The security researcher Taylor Monahan has made the point that matters most: in these cases the failure is almost always a compromised key or a blind-signed approval, not a weakness in 7702 itself. The standard is doing exactly what the owner authorized; the problem is that owners authorize things they cannot see. That is the same lesson our guide to multisig best practices reaches from another direction: the permission is the attack surface. The table sorts the main vectors.

How to see and revoke a delegation

Because a delegation is persistent state rather than a one-time action, delegation hygiene is now part of basic wallet maintenance. Checking is straightforward. On a block explorer, open your address and look at its code: if it begins with 0xef0100, you are delegated, and the 20 bytes after that prefix are the delegate contract. Revoke.cash added a delegations tab that lets you inspect what an account points at, though at the time of writing it is inspection-only for 7702. MetaMask exposes a per-chain smart-account toggle in its account details.

Revoking means signing a fresh authorization that points your account at the zero address, which clears the code pointer. Two caveats matter. First, per OpenZeppelin’s documentation on EOA delegation, resetting the pointer clears the code and code hash but does not wipe any storage the previous delegate may have written, so switching between delegate implementations should be treated with the same care as upgrading a contract. Second, delegation is per chain: a pointer you set on Ethereum mainnet does not exist on Arbitrum or Base unless you authorized it there too, and if you used chain ID zero to deploy everywhere at once, you have more cleanup to do, not less. The practical rule is to review your delegations the way you already review token approvals.

Where the SEC sits

For readers in the United States, the regulatory question is narrower than it sounds. EIP-7702 is a protocol feature of self-custodial accounts, and in April 2026 the SEC’s Division of Trading and Markets issued a staff statement indicating that software that merely enables users to transact from their own wallets is not acting as a broker. In other words, the delegate contract your wallet uses, and the wallet software itself, are not obviously the regulated party. That reading is consistent with the broader direction of US policy described in our review of SEC crypto enforcement in 2026.

Where obligations do bite is on the custodial side. An exchange or custodian that holds customer assets is a regulated business regardless of what transaction type a customer’s wallet uses, and the operational duties around screening deposits, detecting delegated accounts, and safeguarding funds sit squarely with that venue. The protocol made accounts programmable; it did not relocate anyone’s compliance perimeter. That is the regulatory mirror of the technical blind spot: the responsibility stayed with the exchange even as the capability moved to the wallet.

Glamsterdam forks Sepolia, and the native-AA split

It is tempting, on the day of a major test fork, to assume the upgrade changes your account. It does not. Glamsterdam, which activated on the Sepolia testnet on 6 October 2026 at epoch 353,024, is a throughput upgrade: its headline features are enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928), which target faster block propagation and parallel execution, as the Ethereum roadmap lays out. It does not touch EIP-7702 or account abstraction at all, and a mainnet date remains unconfirmed, expected in the fourth quarter with client teams still finishing their work. For ETH sitting in your wallet or on an exchange, the Sepolia fork means precisely nothing today.

The account-abstraction endgame is being decided elsewhere, and it recently got messier. In September 2026, the long-running effort to align Ethereum and Base on a single native account-abstraction design broke down. Ethereum is pursuing EIP-8141, a “frame transaction” approach that Buterin has said gets close to optimal; Base is backing a rival, keystore-based design in EIP-8130. Derek Chiang, the ZeroDev founder now working on native account abstraction, described the split to The Defiant with unusual candor: “While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals.” Until one of those designs lands on mainnet, EIP-7702 remains the bridge everyone actually uses, and the throughput that Glamsterdam buys is what will make all these smarter accounts cheap enough to use every day, which is the quiet reason the base-layer upgrade and the wallet revolution belong in the same story.

The bottom line

EIP-7702 is the rare upgrade that changed everyday experience without asking anyone to migrate. The key you already own can now batch actions, abstract away gas, delegate narrow powers to apps and agents, and buy itself a recovery plan, all by pointing at a contract you can un-point from whenever you like. That is a large gift, and it comes with a bill: a delegation is a dependency, the delegate’s code runs with your money, and the pointer persists until you clear it.

The honest state of play in late 2026 is lopsided. Wallets won first, which is why self-custody finally feels close to the convenience Elkaleh described. Exchanges, hardware devices, and compliance systems are still learning to read an account that has both code and a key at the same time. If you take one habit away from this piece, make it this: before you sign anything that mentions delegation, know which contract you are pointing at, and once in a while, check what your account points at now and clear anything you no longer use. The smart account was always going to arrive; it just arrived through the key you already had.

Frequently Asked Questions

Is EIP-7702 safe to use?

EIP-7702 is safe when you delegate to an audited, reputable contract and you can read what you are signing. The standard itself does not steal funds; the documented losses come from phishing that tricks a user into authorizing attacker code, or from a key that was already compromised. Stick to delegates built into mainstream wallets, avoid blind signing, and review your delegations periodically.

What is the 0xef0100 prefix on my account?

Those three bytes are the EIP-7702 delegation designator. When your account shows code that starts with 0xef0100, it means your EOA has delegated its behavior to a smart contract, and the 20 bytes after the prefix are that contract’s address. An account code size of 23 bytes is the signature of a delegated EOA.

Does EIP-7702 replace ERC-4337?

No. ERC-4337 is the off-protocol smart-account system of bundlers, paymasters, and the EntryPoint contract, and EIP-7702 is a way for an existing EOA to plug into that system without redeploying. They are designed to work together; EntryPoint v0.8 added native support for 7702 accounts.

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

Sign a new authorization that points your account at the zero address, which clears the delegation pointer. You can do this from a wallet that exposes the control, such as MetaMask’s account details. Note that resetting the pointer clears the code but not any storage the previous delegate wrote, and that delegations are per chain, so you may need to repeat it on each network.

Do I need to move my funds to a new address for EIP-7702?

No. That is the whole point of the design. EIP-7702 keeps your existing address and private key and simply lets them borrow a contract’s logic, so there is no migration, no new deposit address, and nothing to move. You can turn the delegation off at any time and return to a plain EOA.

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