EIP-7702 in 2026: The Smart-Account Switch and Its Dark Side

Almost exactly a year ago, in late August 2025, one Ethereum user signed a single transaction and watched roughly $1.54 million in staked ETH, wrapped Bitcoin, and NFTs drain out of their wallet in one motion, according to on-chain sleuths whose findings were reported by Cryptopolitan. The mechanism behind that one-click theft was not a bug. It was EIP-7702, the marquee feature of Ethereum’s Pectra upgrade, doing precisely what it was designed to do: let a plain wallet act like a smart contract for the length of a transaction.

That tension sits at the center of the most consequential wallet change Ethereum has shipped in years. EIP-7702 turned every ordinary account into a programmable one, unlocking batching, gasless transactions, and session keys that wallet designers had wanted for a decade. It also handed the same powers to drainers. In August 2026, with ETH trading near $2,480 after a roughly 30% weekly rally, according to CoinGecko, and more than 51 million accounts now carrying a live delegation, a peer-reviewed academic study finally put a hard number on the dark side. This is what EIP-7702 does, how the set-code transaction works, who ships it across wallets and exchanges, and the security math that decides whether it serves you or empties you.

What EIP-7702 Actually Does

Ethereum has always had two kinds of accounts. Externally owned accounts (EOAs) are controlled by a private key; they are what sit behind almost every MetaMask, Ledger, or exchange withdrawal address. Contract accounts are controlled by code. For a decade, that split was rigid: an EOA could sign and send but could not run logic, and a smart contract could run logic but could not start a transaction on its own.

EIP-7702 breaks that wall. It lets an EOA point at a smart contract’s code and, for as long as that pointer is set, behave like that contract while keeping its original address, balance, and transaction history. Your wallet address does not change. The key that controls it does not change. What changes is that the account can now do things only smart contracts used to do: bundle several actions into one atomic transaction, let someone else pay the gas, enforce spending limits, or hand a game a temporary key that can only make in-game moves.

The official EIP-7702 specification calls the feature “set EOA account code.” In plain terms, it is an upgrade switch. Flip it, and your regular account gains a smart-account brain. Flip it back, and it is an ordinary EOA again. That reversibility, plus the fact that it needs no new address and no asset migration, is why wallet teams treated 7702 as the single most important account-abstraction milestone since the standard that came before it.

From EIP-3074 to Pectra: The Road to Set-Code

The idea of giving EOAs smart-contract powers is older than 7702. Its direct ancestor, EIP-3074, proposed two new opcodes (AUTH and AUTHCALL) that would let a trusted contract act on an EOA’s behalf. Core developers spent years on it, then grew uneasy: 3074 introduced powerful new opcodes and a trust model that did not line up cleanly with Ethereum’s longer-term account-abstraction endgame.

In May 2024, Vitalik Buterin, together with Sam Wilson, Ansgar Dietrichs, and the core developer known as lightclient (Matt Garnett), published EIP-7702 as a leaner alternative. It added no new opcodes. Instead of a bespoke trust framework, it reused the same smart-contract account model that ERC-4337 already relied on, which meant tooling, audits, and mental models could carry over. When Ethereum core developer Marius van der Wijden first reviewed the proposal, he told DL News it was “still a very early proposal, so we need to evaluate all the rough edges.”

Those rough edges got evaluated fast. EIP-7702 shipped to Ethereum mainnet inside the Pectra hard fork on May 7, 2025. Within the first week, thousands of accounts had authorized a delegation. Alex Jupiter, a senior product manager at MetaMask, framed the significance to DL News as folding competing designs into “one unified Account Abstraction roadmap.” Fifteen months on, that roadmap is no longer theoretical; it is running under tens of millions of wallets.

Anatomy of a Set-Code Transaction

EIP-7702 introduces a new transaction type, numbered 0x04 and named SET_CODE_TX_TYPE. What makes it different from a normal transfer is a field called the authorization_list, a list of tuples that each say, in effect, “this account agrees to delegate to that contract.”

Every authorization tuple contains six values: a chain_id, the address of the contract to delegate to, the account’s nonce, and a signature split into its y_parity, r, and s components. To sign it, the wallet takes the domain-separator byte named MAGIC (0x05) and computes a keccak256 hash over that byte followed by the RLP encoding of the chain_id, address, and nonce. Because the authorization is signed separately from the transaction that carries it, one account can authorize its own delegation while a different account pays the gas, which is exactly how gasless onboarding works.

When the network processes the transaction, it writes a small marker into the delegating account’s code slot.

• The account’s code is set to a 23-byte delegation designator.
• That designator is the three-byte prefix 0xef0100 followed by the 20-byte address of the contract being delegated to.
• Any later call to the account transparently runs the delegate’s code, but reads and writes storage on the original account.
• To undo it, the owner signs a new authorization pointing at the zero address, which clears the designator and restores a plain EOA.

Two design choices carry outsized security weight. First, setting chain_id to 0 in an authorization makes it valid on every EVM chain, a convenience that becomes a cross-chain replay risk if a wallet signs it carelessly. Second, the delegate’s code executes in the caller’s storage context, so a sloppy or malicious implementation can quietly collide with or overwrite the account’s storage. Both are handled correctly by audited wallets and abused by drainers, a theme this piece returns to.

EOA vs ERC-4337 vs EIP-7702

It helps to place 7702 next to the two models it sits between. A classic EOA is simple and self-sovereign but dumb. ERC-4337 gives you a full smart-contract wallet with its own address and a separate mempool of user operations, live since 2023, but it usually means moving assets to a new account. EIP-7702 is the bridge: your existing EOA, temporarily wearing smart-contract clothes.

The practical read: 4337 and 7702 are complements, not rivals. Many production wallets delegate a 7702 EOA to a contract that itself speaks the 4337 interface, so a user gets the familiar address of an EOA and the paymaster and bundler infrastructure of 4337 at the same time. For a broader map of how these smart-account designs expand what an attacker can reach, see our companion feature on account abstraction as the new attack surface.

The Superpowers a Delegated Wallet Unlocks

Strip away the cryptography and 7702 is about user experience. The capabilities it enables are the same ones that made people willing to tolerate its risks.

• Batching: approve a token and swap it in a single atomic transaction, so a trade either fully succeeds or fully reverts, leaving no dangling approvals behind.
• Gas abstraction: let a dapp or a paymaster cover the fee, or pay it in a stablecoin instead of ETH, which removes the “you need ETH to move your USDC” trap that stalls newcomers.
• Session keys: grant a temporary, tightly scoped key that can, say, make moves in a game or sign trades up to a limit, without exposing the master key.
• Spending guards: enforce daily caps, allowlists, or co-signer rules directly in the account’s logic.
• Social recovery and passkeys: attach recovery paths or passkey signing to an address you already own and fund.

Those first two, batching and gas abstraction, are why exchanges and consumer apps care. A newcomer who buys a first token no longer has to understand gas, hold ETH separately, and sign three sequential prompts. For wallet builders chasing mainstream users, that is the whole game. The same batching primitive, though, is what lets a single malicious signature approve and sweep everything at once, which is where the story turns.

The Adoption Map: Wallets, Exchanges, and 51 Million Delegations

By late August 2026, dashboards tracking 7702 show a feature that has moved well past the experimental phase. According to BundleBear, EOAs have signed more than 229 million cumulative authorizations, over 95 million set-code transactions have landed on-chain, and roughly 51 million accounts currently carry a live delegation. Counting both 4337 and 7702, industry estimates for the number of smart wallets across the ecosystem now run into the hundreds of millions.

Support is broad but uneven, and it changes month to month. A community-maintained registry of 7702 delegation contracts lists more than a dozen distinct implementations from major teams.

On the exchange side, adoption is more cautious, which is rational: a venue that custodies user funds has to reason carefully about how a delegated deposit address behaves. OKX and WhiteBIT were among the earliest to engage. How the largest exchanges handle self-custody, deposits, and the smart-account transition is a recurring theme in our Coinbase, Binance, Kraken, and OKX comparison.

The Dark Side, Quantified: Inside the USENIX Security ’26 Study

The most rigorous look yet at how 7702 got used in the wild is not flattering. In August 2026, researchers led by Mingyuan Huang presented a peer-reviewed paper at the 35th USENIX Security Symposium titled “Revealing the Dark Side of Smart Accounts: An Empirical Study of EIP-7702 Incurred Risks in Blockchain Ecosystem.” The team analyzed 3,664,166 EIP-7702 authorization transactions across seven chains (Ethereum, BNB Smart Chain, Polygon, Optimism, Arbitrum, Base, and Gnosis) through mid-July 2025.

Their headline finding: 2,322,548 of those authorizations, more than 63%, were tied to malicious contracts. The researchers manually reviewed and confirmed 924 distinct malicious contract accounts, including several previously unreported zero-day cases, and tallied roughly $2.36 million in realized losses plus about $10.14 million in additional exposure from legacy contracts built on outdated security assumptions.

Two caveats keep that 63% honest, and the study is careful about both. First, it counts transactions, not people or dollars. Attacker contracts were reused disproportionately, so, as the researchers note, transaction counts can rise far faster than the number of distinct contracts or affected users. A small pool of drainer contracts, hammered over and over, inflates the share. Second, and this is the point security engineers keep repeating, the finding is not evidence of a protocol bug. As coverage in CryptoSlate stressed, the danger lives in how users are tricked into signing, and in wallet prompts that do not clearly show which code is being approved. A companion USENIX ’26 study underscored the supply side of the problem, flagging tens of thousands of high-risk addresses whose private keys had leaked through public code repositories, worth a standardized $574.8 million, per reporting by crypto.news.

CrimeEnjoyor and the Economics of the Sweeper

The academic data lines up with what security firms saw in the first weeks after Pectra. In June 2025, the trading firm Wintermute told CoinDesk that more than 97% of all early 7702 delegations pointed at the same reused, copy-pasted bytecode, a sweeper contract that on-chain analysts nicknamed CrimeEnjoyor. Roughly 2.88 ETH worth of gas had authorized delegations for around 79,000 addresses, and a single sweeper contract handled more than 52,000 of them.

Here is the twist that keeps 7702 from being a catastrophe: Wintermute’s analysis found the campaign was barely profitable. The sweepers were pointed mostly at wallets whose private keys were already compromised, empty shells with nothing left to take. The bytecode was designed to instantly forward any incoming ETH to the attacker, so if a victim accidentally funded a drained address the money vanished; but there was rarely anything there. In other words, the “63% malicious” picture describes automated bots spamming already-dead wallets far more than it describes fresh victims losing fortunes.

That does not make the losses imaginary. The mechanics of who profits when a wallet is emptied, and the layered economy of drainer kits, launderers, and affiliates behind it, mirror the structure we mapped in the rug-pull economy. EIP-7702 did not create that economy. It gave it a faster tool.

How a 7702 Drain Actually Happens

When a real person does lose money to 7702, the pattern is consistent. The attacker breaks no cryptography. They convince the victim to sign an authorization, usually disguised inside what looks like a routine action: a token approval, a swap, an airdrop claim. Because the wallet often shows a blind hex blob rather than a human-readable “you are about to make your account controlled by this contract” warning, the victim clicks approve. Once the delegation is set, the attacker’s batched transaction can approve and move every asset in a single atomic sweep.

The batched-signature drainers, Inferno Drainer and Pink Drainer among them, adapted to 7702 within weeks of Pectra. Scam Sniffer documented a MetaMask user suffering a six-figure loss to an Inferno-linked 7702 batch in May 2025, and the roughly $1.54 million single-victim loss in late August 2025 that opened this article. Even so, the broader trend ran the other way: total wallet-drainer losses fell about 83% year over year to roughly $83.85 million in 2025, according to Scam Sniffer data reported by Cointelegraph, as wallets shipped better warnings.

What Exchanges and Custodians Have to Screen

For the wallets-and-exchanges world, 7702 is not just a consumer feature; it is an operational headache. The 23-byte delegation designator sitting in an account’s code changes how a venue should reason about the addresses it touches.

Consider a deposit address. If a user’s EOA is delegated to a contract with a “forward everything on receipt” sweeper built in, funds sent to that address can be re-routed the instant they land. A custodian or exchange that credits deposits naively could find the underlying balance gone. That is why sophisticated venues now screen incoming and outgoing addresses for the 0xef0100 prefix and inspect the delegate contract before treating an address as a plain EOA. A delegated withdrawal target deserves the same scrutiny.

• Deposit screening: flag deposit addresses carrying a delegation designator and check what the delegate does before crediting.
• Withdrawal checks: verify that a delegated destination is not a sweeper that will re-route customer funds.
• Address reuse: recognize that an address can gain or lose smart-account behavior between two transactions, so a one-time check is not enough.
• Travel Rule and AML: a delegated account can batch and obscure flows, which complicates the counterparty and beneficiary data that regulated venues must collect.

That last point connects 7702 to the compliance debate playing out globally. As programmable accounts blur the line between a simple transfer and a contract interaction, the counterparty-identification duties at the heart of the FATF crypto guidance get harder to satisfy cleanly, especially where a delegate contract routes funds through intermediaries before they reach the named beneficiary.

How to Read, Audit, and Revoke Your Delegation

The single most useful habit for any 7702 user is knowing how to check whether an account is delegated and how to undo it. Because the designator lives on-chain in plain view, this is straightforward.

1. Look up your address on a block explorer such as Etherscan and open the Contract or Code tab; a delegated EOA shows code beginning with 0xef0100 followed by the delegate’s address.
2. Use a dedicated viewer such as eip7702.app to see, in plain language, which contract your account currently points at.
3. If you do not recognize the delegate, or you never intended to delegate at all, treat the account as potentially compromised and move any remaining assets from a clean device first.
4. To revoke, sign a new set-code authorization that points at the zero address; this clears the designator and returns the account to a plain EOA.
5. After revoking, re-check the explorer to confirm the code slot is empty before reusing the address.

A caution that trips up even careful users: if your private key itself was phished, revoking the delegation is not enough, because the attacker can simply re-delegate. In that case the only safe move is to abandon the address entirely and migrate to a fresh key. Delegation hygiene protects you against a malicious contract; it cannot protect a key that is already in someone else’s hands.

One more practical note, since it comes up every filing season: delegating your EOA does not change what you owe. A 7702 account is still your self-custodied wallet, and the batched swaps and transfers it enables are taxable events like any other, a point worth remembering when you read our guide to the crypto-tax bill no broker files for you. In the United States, the SEC’s securities-registration regime does not reach a self-custodial wallet upgrade like this; for most users, the reporting obligations that actually bite are tax ones.

Fusaka, Glamsterdam, and the Road to Native Account Abstraction

EIP-7702 is a bridge, not a destination. Ethereum’s account-abstraction endgame is native, protocol-level support, where smart-account logic is a first-class citizen rather than a designator bolted onto an EOA. The proposal usually cited for that endgame is EIP-7701, which builds account abstraction into the protocol through a new execution format.

That future is not imminent. The Fusaka upgrade, which activated on December 3, 2025, was focused elsewhere, on PeerDAS data-sampling and cheaper layer-2 settlement, and it did not include EIP-7701. The Ethereum Foundation’s 2026 protocol-priorities update did not schedule native account abstraction for a specific near-term fork either. The next upgrade in the pipeline, Glamsterdam, is expected later in 2026, but the scope of what it will carry is still being debated.

For the foreseeable future, then, 7702 is the account-abstraction layer that hundreds of millions of users will actually touch. That makes getting its safety story right more urgent than shipping the next standard. The wallets that win will be the ones that make the delegation prompt as clear as a bank-transfer confirmation, not a hex riddle. The protocol handed users a smart account; whether that turns out to be a gift or a trap now rests almost entirely on interface design.

Frequently Asked Questions

Is EIP-7702 safe to use?

The protocol itself is not considered flawed; security researchers consistently frame 7702 risk as a wallet-interface and user-behavior problem, not a bug in the standard. The danger comes from signing a delegation to a malicious contract, usually because a wallet showed a blind hex prompt instead of a clear warning. Using a reputable wallet that displays human-readable delegation prompts and only allows audited implementations makes everyday use reasonably safe. Never sign an authorization you do not understand.

How do I check if my wallet is delegated under EIP-7702?

Look up your address on a block explorer like Etherscan and open the code tab. A delegated account shows code that begins with the prefix 0xef0100 followed by a 20-byte contract address, for 23 bytes in total. Tools such as eip7702.app translate that into plain language, telling you which contract your account currently delegates to. If you see a delegate you do not recognize, treat the account as at risk and move funds from a clean device.

How do I revoke an EIP-7702 delegation?

Sign a new set-code (type 0x04) authorization that points your account at the zero address. That clears the delegation designator and returns your EOA to normal. Most wallets that support 7702 expose this as a remove-delegation or revoke action. One important caveat: if your private key was compromised, revoking is not enough, because the attacker can re-delegate; in that case, move everything to a new address entirely.

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

ERC-4337 is a full smart-contract wallet with its own new address and a separate transaction mempool, live since 2023. EIP-7702 lets your existing EOA temporarily borrow a smart contract’s code while keeping its original address and requiring no asset migration. They are complementary: many wallets delegate a 7702 EOA to a contract that speaks the 4337 interface, giving users a familiar address plus paymaster and batching features.

Did EIP-7702 make wallet drainers worse?

It gave existing drainers a more efficient tool, letting them approve and sweep many assets in one signed batch, and early on-chain data showed most delegations pointed at sweeper contracts. But total wallet-drainer losses actually fell around 83% in 2025 as wallets shipped better warnings, and the most-copied sweeper campaigns were barely profitable because they targeted already-empty wallets. The feature raised the stakes of a single bad signature without producing a net increase in theft.

By Marcus Okafor, HOGE Wire