EIP-7702 in 2026: Smart Accounts Across Wallets and Exchanges

The One-Signature Upgrade That Redefined the EOA

Ethereum spent a decade with two kinds of account that behaved nothing alike. Externally owned accounts (EOAs), the addresses that start with a private key and a seed phrase, could hold funds and sign transactions but could not run code. Smart contracts could run code but could not start a transaction on their own. EIP-7702 collapsed that divide. Since the Pectra hard fork went live on Ethereum mainnet on 7 May 2025, any EOA can borrow the code of a smart contract for the length of a transaction, or keep that code attached indefinitely, by signing a single authorization. The address stays the same, the private key stays the same, and the account gains the abilities that used to require a separate smart-contract wallet.

For readers who live in wallets and on exchanges, that is the whole story in one sentence: your familiar MetaMask or hardware-wallet address can now batch actions, let someone else pay the gas, and delegate narrow permissions, without you moving a cent to a new contract address. More than a year after activation, the feature has gone from experiment to plumbing. BundleBear, which tracks 7702 usage across chains, counts more than 54 million live delegated accounts and hundreds of millions of cumulative authorizations, though a large share of those authorizations come from automated sweeper bots rather than real users (BundleBear). Ether traded near $2,400 as this piece went out.

This is a working guide to what EIP-7702 does, how wallets and exchanges have implemented it, where the money has been lost, and what happens to your delegation as Ethereum moves toward native account abstraction.

From EIP-3074 to EIP-7702: A Short History

Account abstraction, the idea that an Ethereum account should be programmable rather than fixed to a single key, has been on the roadmap for years. The first serious attempt to give EOAs contract-like powers was EIP-3074, which introduced two new opcodes (AUTH and AUTHCALL) and a system of invoker contracts (EIP-3074 spec). Core developers worried that 3074 handed too much standing power to invokers and did not compose cleanly with the longer-term plan for smart-contract accounts, so it never shipped.

EIP-7702 arrived in 2024 as the replacement. It was authored by Vitalik Buterin together with Sam Wilson, Ansgar Dietrichs, and Matt Garnett (who writes as lightclient), and it took a deliberately smaller bite: no new opcodes, no invokers, just a new transaction type that lets an account point at existing contract code. Buterin framed it as a bridge, a way to give EOAs the ergonomics of smart accounts now while keeping the door open to the endgame design where every account is a contract. The proposal moved fast. When Buterin floated it, Geth developer Marius van der Wijden cautioned that “It’s still a very early proposal, so we need to evaluate all the rough edges,” while MetaMask senior product manager Alex Jupiter welcomed it as a step toward “one unified Account Abstraction roadmap” (DL News). Both turned out to be right: the design shipped inside Pectra roughly a year later, and the rough edges became the security story of the year that followed. For a step-by-step walk through the plumbing, our companion piece on how EOAs became smart accounts goes deeper on the mechanics.

How a Set-Code Transaction Works

The mechanism is narrower than the marketing suggests, which is what makes it safe enough to ship. EIP-7702 defines a new transaction type numbered 0x04, sometimes called the set-code transaction (EIP-7702 spec). Its distinguishing field is an authorization list. Each entry is a tuple of a chain id, a contract address, a nonce, and a signature (the y-parity, r, and s values). When the transaction is included, the protocol writes a small marker into the signing account’s code slot: the three-byte prefix 0xef0100 followed by the 20-byte address of the contract, 23 bytes in total. This marker is called a delegation designator. From that point on, when anything calls the account, the EVM loads and runs the designated contract’s code in the context of the account, using the account’s own storage and balance. Because the account holds a pointer to the delegate rather than a copy of its code, every account that points at the same contract shares its behavior, and if that contract is an upgradeable proxy its author can change what all of them do, which is why auditors prefer immutable, well-reviewed delegates.

A few details matter for anyone judging the risk.

• The authorization is signed with a dedicated message format. The signed payload is keccak256 of 0x05 concatenated with the RLP encoding of the chain id, address, and nonce, where 0x05 is a magic byte that keeps these signatures from being replayed as ordinary transactions.
• A user can undo a delegation by signing a new authorization that points at the zero address, which clears the code slot and returns the account to a plain EOA.
• If the chain id in an authorization is set to 0, the authorization is valid on every chain, which is convenient for multi-chain setups and dangerous if signed carelessly, because the same delegation can be replayed across networks.
• The delegation is persistent. Unlike a one-off token approval, a single signature can hand a contract standing control of the account until the user resets it.

That last point is the pivot on which both the promise and the peril turn. One signature, and the account is upgraded; one signature to the wrong contract, and the account is compromised.

EOA, Smart-Contract Wallet, and 7702 Compared

Before 7702, users chose between two models. A plain EOA was simple, cheap, and portable but dumb: one key, one signer, no batching, no recovery. A smart-contract wallet (a Safe multisig, or an ERC-4337 account) was programmable but lived at a new address, cost gas to deploy, and could be awkward to move assets into. EIP-7702 is a third path that keeps the EOA address and adds programmability on top.

The practical upshot: 7702 gives an existing address most of what a smart-contract wallet offers without the migration tax. That is why wallets adopted it as the default upgrade path rather than pushing users to move funds.

What Smart EOAs Unlock

The abilities are not new to Ethereum; ERC-4337 accounts have had them since 2023. What 7702 changed is that they now reach the hundreds of millions of ordinary EOAs already in circulation. The headline capabilities are batching, gas sponsorship, session keys, and recovery.

• Batching. Approve a token and swap it in one atomic transaction instead of two, or top up several positions at once. The companion standard ERC-5792 (the wallet_sendCalls method) gives apps a clean way to ask a wallet to run a batch (EIP-5792 spec). For anyone who has clicked approve and then confirm on a decentralized exchange, this removes a whole failure mode.
• Gas sponsorship. A third party (a paymaster) can pay the network fee, or let the user pay it in a stablecoin. Circle turned on gasless USDC transfers built on 7702, letting a user pay the fee in USDC while a paymaster fronts the ether (Circle). For exchanges and apps, that means a new user can transact before ever holding ETH.
• Session keys. A user can authorize a narrowly scoped key that is allowed to do one thing, such as sign moves in a game or rebalance within limits, without exposing the main key.
• Recovery and guardians. A delegate contract can implement social recovery or spending limits, features that a bare EOA could never enforce.

The Gas-Sponsorship Question: Who Really Pays

Gas sponsorship deserves its own look, because it is the capability most likely to change how ordinary people meet crypto. In the old model, a wallet was useless until it held the network’s native token; a new user who bought USDC on an exchange and withdrew it to a fresh address could not move it without first acquiring ETH for fees. A paymaster breaks that chicken-and-egg problem. In the sponsored model, an app or exchange pays the fee on the user’s behalf, the way a website absorbs its own hosting costs. In the token-fee model, the user pays in a stablecoin and the paymaster fronts the ether behind the scenes, taking a small margin for the service.

For wallets and exchanges, this is an onboarding lever, not just a convenience. A venue that lets a customer transact in USDC from the first minute removes the single most confusing step in self-custody. It also shifts a cost onto the sponsor, which is why paymaster providers price the service and why the economics have to be watched: sponsor too generously and a griefing bot can drain the budget, sponsor too little and the friction returns. Mature setups meter sponsorship per user and per action, cap it, and lean on the same simulation and screening they already run. None of this strictly required 7702, since ERC-4337 accounts could already use paymasters, but 7702 is what brought sponsored gas to the hundreds of millions of plain EOAs that were never going to migrate to a new account.

Session Keys, Games, and AI Agents

The capability that resonates most with a gaming audience is the session key. A blockchain game that asks a player to sign every move dies on friction. With 7702, a player can delegate their EOA to a contract that mints a temporary key scoped to the game: it can move a specific in-game token, up to a spending cap, until an expiry, and nothing else. If the session key leaks, the blast radius is the cap, not the wallet. A card-battler that lets a player fuse items every few seconds, for instance, can run those calls under a session key that is allowed to touch only the item contract and expires at the end of the session, so a compromised game client cannot reach into the player’s tokens or NFTs. Studios building on Ethereum and its layer-2 networks have leaned on this to make on-chain play feel like a normal app rather than a signature gauntlet.

The same pattern powers the current wave of on-chain AI agents. An agent that trades, rebalances, or pays for compute needs authority to act without a human clicking confirm each time, and it needs that authority bounded. A scoped 7702 delegation lets an owner hand an agent a leash: spend from this balance, call these contracts, within these limits. Networks that sell GPU time and inference to those agents sit on the same demand curve. The risk is symmetrical: a delegation broad enough to be useful to an agent is broad enough to be dangerous if the agent, or its operator, is compromised. Scoping is everything, and the difference between a convenience and a catastrophe is how tightly the permission is written.

The Wallet Rollout and the Numbers

Wallets moved first, because 7702 slots into their existing model. Ambire shipped support early. MetaMask built its smart-account features on 7702 as the primary upgrade path for its enormous EOA base, so a user upgrades in place rather than creating a new account. Rabby, Trust Wallet, TokenPocket, and Safe added support across 2025. The pattern is consistent: the wallet offers to upgrade your address, which under the hood signs a 7702 authorization to the vendor’s audited delegate contract. Because the address does not change, the upgrade is nearly invisible to the user; balances, transaction history, and the public address all stay exactly as they were, which is precisely why the migration friction that held back ERC-4337 adoption did not repeat here.

The aggregate numbers are large but need reading with care. BundleBear’s cross-chain tracker shows more than 237 million cumulative authorizations, over 54 million currently live delegated accounts, and close to 100 million set-code transactions as of early September 2026 (BundleBear). Those authorization totals are inflated by automated activity: sweeper bots that authorize tens of thousands of already-compromised addresses in bulk account for a large slice, so the count of authorizations overstates the count of real human upgrades. The live-delegation figure, the accounts that currently have a delegate attached, is the more honest measure of adoption, and even discounted it represents one of the fastest uptakes of a new account model Ethereum has seen.

Exchanges and Custody: Screening the 23-Byte Designator

Exchanges sit on the other side of the wallet from users, and 7702 gave their engineering teams a new edge case. When a customer withdraws to a self-custodied address, or when a deposit arrives, that address may now carry a delegation designator: the 0xef0100 prefix plus a contract address, sitting where an EOA’s empty code used to be. An address that runs code on receipt behaves differently from a passive EOA. A naive deposit-crediting system that assumes an address with code must be a contract can misfire, and a system that assumes an EOA never runs code is simply wrong after Pectra.

So custody and exchange teams added screening. On withdrawal, some venues check whether the destination is a delegated account and to which contract, because sending to an address controlled by a malicious sweeper contract means the funds can be swept the instant they land. On deposit, address-monitoring has to account for code appearing and disappearing at an address as users delegate and reset. Some desks go further and keep allow-lists of known-good delegate contracts, treating a withdrawal to an address that points at an unrecognized contract the way they would treat a withdrawal to a flagged address: pause, review, and confirm with the customer before releasing funds. None of this is exotic, but it is new operational surface, and it sits next to the compliance stack that already screens for sanctioned addresses and suspicious flows. The know-your-customer and anti-money-laundering machinery that exchanges run does not change because of 7702, but the address hygiene around it does, and it is worth asking how well that machinery actually works in practice.

There is a custody-policy question underneath. A delegated EOA is still a self-custodied account: the user holds the key, and the delegate contract only runs when the account is called. Regulators treat self-hosted wallets differently from custodial accounts, and 7702 does not move an address across that line. What it changes is that the same self-custodied address is now programmable, which is a capability, not a change of custodian.

The Dark Side: Drainers, Sweepers, and CrimeEnjoyor

The feature that lets a wallet upgrade in one signature also lets a thief take over in one signature, and attackers noticed immediately. Within weeks of Pectra, security researchers found that the overwhelming majority of early delegations were not upgrades at all. Wintermute reported that more than 97% of early 7702 delegations pointed at the same reused piece of bytecode, a copy-pasted sweeper contract the firm nicknamed CrimeEnjoyor (CoinDesk). The pattern: an attacker who already has a victim’s private key, from a leaked seed phrase, a phishing signature, or malware, delegates the victim’s account to a sweeper that automatically forwards any incoming funds to the attacker. Roughly 2.88 ETH of authorizations covered around 79,000 addresses, with a single contract handling more than 52,000. Wintermute’s read was that this was not profitable and not a flaw in 7702; the accounts were already compromised, and the sweepers were emptying wallets that were mostly empty.

That nuance matters, and it is the consensus among the researchers who have studied it. Taylor Monahan, a security researcher at MetaMask, put it bluntly after a large theft: “It’s not actually a 7702 issue, its the same issue crypto has had since day one: end users struggle to secure their private keys” (Cryptopolitan). The largest single loss reported in a 7702-assisted phishing attack was $1.54 million, drained in one transaction after the victim signed a malicious batch that looked like a routine action. What 7702 added was efficiency: an attacker can now batch the approval and the theft, and set up automatic sweeping, in fewer steps.

The academic record has caught up with the anecdotes. A large empirical study presented at the 35th USENIX Security Symposium analyzed more than 3.6 million 7702 authorizations across seven chains and found that over 63% were tied to malicious contracts, with 924 distinct malicious contracts confirmed by hand, around $2.36 million in realized losses, and roughly $10.14 million in exposure from legacy contracts (USENIX Security). A separate 2025 paper documented a dedicated 7702 phishing technique across roughly 26,000 addresses and more than 150,000 events, describing a single signed tuple that can hand an attacker persistent, unconditional control of an account (arXiv). Read carefully, both papers make the same point as Monahan: the malicious share is high because a handful of attacker contracts get reused across tens of thousands of already-compromised addresses, so the percentage counts transactions, not victims, and not a break in the protocol.

There is a broader and more hopeful trend around this. Wallet-drainer losses across all techniques fell sharply in 2025; Scam Sniffer data reported by Cointelegraph showed phishing losses down about 83% year over year, to roughly $83.85 million (Cointelegraph). Better wallet warnings, transaction simulation, and drainer takedowns did more to protect users than any protocol change. When a delegation does end in a theft, the after-the-fact options are limited and mostly involve white-hat negotiation and recovery bounties rather than clawbacks through the chain.

Reading and Revoking a Delegation

Because a delegation is persistent, every 7702 user should know how to check and clear one. The steps are simple.

1. Look up your address on a block explorer such as Etherscan. A delegated account shows code beginning with 0xef0100 followed by the delegate contract’s address. If that field is empty, you are a plain EOA.
2. Confirm the delegate is one you recognize (your wallet vendor’s contract) and not an unknown address.
3. To change delegates, sign a new authorization pointing at the new contract.
4. To fully reset, sign an authorization to the zero address, which clears the code slot and returns the account to a bare EOA.

A caution that trips people up: some allowance-revocation tools can show a 7702 delegation but cannot remove it, because clearing a delegation requires a signed 7702 authorization, which today comes from the wallet itself rather than a third-party dapp. If a wallet is compromised at the key level, resetting the delegation does not help, because the attacker can simply re-delegate; the only fix is to abandon the address and move funds to a fresh key. This is the same lesson multisig users learned the hard way: the signature is the security boundary, so verify what you sign before you sign it.

Builder Footguns: Storage, Init, and Replay

For teams shipping delegate contracts, 7702 introduces failure modes that do not exist for ordinary contracts. Auditors flag four in particular.

• Storage collisions. A 7702 account can change which contract it delegates to. If two delegate contracts use the same storage slots for different purposes, switching from one to the other can corrupt state or hand an attacker a foothold. The standard defense is namespaced storage under ERC-7201, which spreads a contract’s variables into a pseudo-random slot derived from a namespace so two delegates do not overlap (ERC-7201 spec).
• Initialization. A delegate cannot rely on constructor-style setup, because the code runs in the account’s context without a deploy step. Naive init functions can be front-run, so delegates need initialization bound to the authorizing signature.
• Replay. An authorization with a chain id of 0 is valid everywhere. That is a feature for multi-chain wallets and a trap for anything that assumes a signature is single-use or single-chain.
• Blind signing. The user-facing risk is that a delegation looks like any other signature request. Wallets that decode a 7702 authorization and show the target contract in plain language protect users; wallets that show an opaque hash do not.

These are solvable, and the mature wallet delegates in production handle them. But they explain why the security researchers who like 7702 still describe it as a design with sharp edges: the protocol is small and clean, and most of the risk lives in how contracts and wallets use it.

Where the SEC and Compliance Teams Stand

EIP-7702 is a protocol feature, not a financial product, so it does not have a direct regulatory owner. The relevant question for United States readers is narrower: does upgrading an EOA change its regulatory status? The answer, so far, is no. A delegated EOA remains a self-hosted wallet under the key of its owner. The Securities and Exchange Commission’s attention in 2026 has centered on tokens, exchanges, and custody arrangements, not on the internal mechanics of how a self-custodied Ethereum account signs. Nothing in 7702 makes an address a broker, an exchange, or a custodian.

Where it touches compliance is at the edges that exchanges already police: screening destination and source addresses, handling accounts that run code, and applying the same anti-money-laundering rules to flows regardless of whether the counterparty is a plain EOA or a delegated one. For a sense of how the year’s regulatory deadlines are shifting more broadly, our regulatory countdown tracks the dates that actually matter. The short version: 7702 is not on the SEC’s docket, but the wallets and exchanges that implement it are, for reasons that have nothing to do with account abstraction.

What Comes Next: Fusaka, Native AA, and the Slip

EIP-7702 was always meant to be a bridge to native account abstraction, the endgame in which every Ethereum account is a smart account by default and the EOA-versus-contract distinction disappears. That endgame has slipped. The Fusaka upgrade that activated in December 2025 focused on data scaling (PeerDAS) and a gas-limit increase, not account abstraction. The most concrete native-AA effort, Base’s Cobalt upgrade built on EIP-8130, was expected to reach mainnet in 2026 but now lists its mainnet and testnet activation as to be determined, with the standard still running on a devnet (Bitcoinist). A separate proposal, EIP-8141, has been penciled in for the later Hegota fork rather than shipping as a headline feature (EthDaily).

The practical consequence for anyone holding a delegated EOA is reassuring: 7702 is not a temporary hack that is about to be swapped out. It is becoming durable infrastructure that will coexist with native accounts whenever they arrive. When native AA does land, a 7702 delegation is expected to migrate cleanly or reset to a plain EOA at the owner’s choice, with the key and address unchanged. Until then, the smart account you already have is the one the ecosystem is building on, and the practical work for users and operators is not waiting for the next upgrade but learning to read, scope, and reset the delegations they already carry.

Frequently Asked Questions

What does EIP-7702 actually do?

It adds a transaction type that lets a normal Ethereum account (an EOA) point at a smart contract and gain that contract’s abilities, such as batching transactions, gas sponsorship, and session keys, without changing the account’s address or private key. It went live in the Pectra upgrade on 7 May 2025.

Is EIP-7702 safe to use?

The protocol itself is considered sound; the risk is in what you delegate to. Delegating to a reputable wallet vendor’s audited contract is safe. The thefts reported in 2025 came from users signing malicious authorizations or from attackers who already held the victim’s private key, not from a flaw in the design. Verify the contract you delegate to, and never blind-sign.

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

Look up your address on a block explorer such as Etherscan; a delegated account shows code beginning with 0xef0100 plus the delegate contract address. To remove it, use your wallet to sign a new authorization pointing at the zero address, which resets the account to a plain EOA. Some third-party revocation tools can display a delegation but cannot clear it.

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

ERC-4337 is a smart-contract account standard that lives at a new address and routes actions through bundlers and an EntryPoint contract. EIP-7702 upgrades your existing EOA in place, keeping the same address, and can use the same kinds of delegate logic. They are complementary; many wallets use 4337-style contracts as the delegate a 7702 account points to.

Do exchanges support EIP-7702 deposits and withdrawals?

Yes. A delegated address is still an Ethereum address, but exchanges have added screening to detect the 23-byte delegation designator, because a delegated address can run code when it receives funds. A delegated EOA remains a self-custodied wallet and does not change the custody status of the account.

Marcus Okafor is a senior editor at HOGE Wire covering Ethereum infrastructure, wallets, and the security of self-custody.