EIP-7702 Explained: How EOAs Became Smart Accounts
EIP-7702 lets any Ethereum wallet borrow smart-contract powers without changing its address. Here is how it works, who is shipping it, and why early delegations turned malicious.
For most of Ethereum’s history, choosing an account meant choosing a tradeoff. On one side sat externally owned accounts (EOAs), the ordinary wallets that a single private key controls: cheap, universal, and not very clever. On the other sat smart contract wallets, which can batch actions, sponsor gas, and enforce spending limits, but which live at a fresh address and cost money to deploy. EIP-7702 erases that choice. It lets a plain EOA borrow the code of a smart contract, keep its existing address, and behave like a programmable account for as long as its owner wants.
The feature reached Ethereum mainnet on May 7, 2025 inside the Pectra hard fork, and it has since become one of the most used and most abused upgrades the network has shipped. By the middle of 2026, on-chain trackers had logged hundreds of millions of authorizations and tens of millions of live smart EOAs. In the same window, security researchers found that the overwhelming majority of the earliest delegations pointed straight at automated wallet drainers. What follows is the full picture: what EIP-7702 does, why it exists, who is building on it, and where it has already gone badly wrong.
What EIP-7702 Actually Does
The formal title of the proposal is blunt: Set EOA account code. Under the old rules, an externally owned account could never have code of its own; only contracts could. EIP-7702 adds a narrow exception. An account holder signs a short authorization that names a contract address, and the protocol writes a special pointer into the account, a delegation that tells the network to run that contract’s logic whenever someone calls the account. The wallet keeps its address, its balance, its transaction history, and its private key. It simply gains a brain on loan.
Three properties make this workable rather than reckless. First, the delegation is a pointer, not a copy: the account references the target contract’s code, so an upgrade to that contract flows through automatically. Second, the private key never loses ultimate authority; the owner can sign a new authorization at any time and repoint or remove the delegation. Third, delegation is reversible. As the Ethereum Foundation’s own guidance puts it, a delegation can be reset by delegating to the null address, which strips the code back out and returns the account to a plain EOA. The upgrade was authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and the developer known as lightclient, and it is written into the reference clients as transaction type four.
It helps to be precise about what does not change. A delegated account is still the same account: same balance, same address, same nonce, same history. It can still send ordinary transactions signed by its key. The delegation only adds behavior, and only for as long as the pointer is set. That is why the feature is often described as giving an EOA a brain on loan rather than a transplant, and it is why so many wallets could switch it on for their users without asking anyone to move funds.
From EIP-3074 to EIP-7702: A Short History
Account abstraction, the broad idea that a wallet’s rules should be programmable rather than hardwired, has sat on Ethereum’s roadmap for years. The immediate predecessor to EIP-7702 was EIP-3074, a proposal that would have added two new opcodes (AUTH and AUTHCALL) to let a trusted contract act on behalf of an EOA. EIP-3074 was mature and, for a time, slated for inclusion in Pectra. Then, in May 2024, Buterin published EIP-7702 as an alternative, and the core developers switched course.
The reasoning, as Buterin laid it out and as outlets including The Block and DL News reported at the time, was about not painting the protocol into a corner. EIP-3074’s opcodes would have been dedicated machinery that risked becoming dead weight once Ethereum reached what Buterin calls endgame account abstraction, the state in which every account is a smart contract. EIP-7702 reaches a similar result without minting permanent new opcodes. The specification describes itself as very forward-compatible with endgame account abstraction, without over-enshrining any fine-grained details of the existing ERC-4337 standard. In plain terms, it is meant to be a bridge that can be dismantled later without regret.
Inside the Type 4 Transaction
The mechanics are simpler than they look. EIP-7702 introduces a new transaction type, 0x04, sometimes called the set-code transaction. Alongside the usual fields, it carries an authorization list: a set of tuples, each of which is a signed instruction to set one account’s delegation. A single transaction can therefore upgrade several accounts at once, and the account paying gas need not be the account being upgraded, which is what makes sponsored onboarding possible.
Each entry in the list has six fields, and the signature inside it is what actually authorizes the change. To stop that signature from being reused where it was not intended, it is computed over a dedicated message: the magic byte 0x05, followed by the encoded chain ID, the target address, and the account nonce. The table below breaks the structure down.
| Element | What it holds | Why it matters |
|---|---|---|
| chain_id | The chain the authorization is valid on, or 0 for any chain | A value of 0 lets the same delegation replay on every EVM chain, handy for deployers but risky for users |
| address | The contract whose code the account delegates to | Delegating to the zero address removes the delegation entirely |
| nonce | The account’s expected nonce at signing time | Stops an old authorization from being replayed after the account has moved on |
| y_parity, r, s | The ECDSA signature over the authorization message | Proves the account owner actually approved this specific delegation |
| designator (on chain) | The account stores 0xef0100 followed by the 20-byte contract address | This 23-byte marker is how clients recognize a delegated EOA |
| magic (signing) | The signed message is the hash of 0x05 followed by the encoded chain_id, address and nonce | The 0x05 prefix keeps 7702 signatures from being confused with ordinary transaction signatures |
Those details come straight from the EIP-7702 specification. The single most important line for ordinary users is the one about the null address: because a delegation can always be wiped by pointing the account at 0x0, no 7702 upgrade is permanent, and a compromised or unwanted delegation can be undone by the key holder in one transaction.
EIP-7702 vs ERC-4337: Complements, Not Rivals
Newcomers often assume EIP-7702 replaces ERC-4337, the account abstraction standard that has powered smart wallets since 2023. It does not. The two are designed to work together. ERC-4337 built an entire parallel system (a mempool of user operations, bundlers that package them, an EntryPoint contract, and paymasters that can cover fees) without touching Ethereum’s core protocol. Its weakness was that using it meant deploying a new smart contract account at a new address and moving your assets there. EIP-7702 removes that migration step by upgrading the account you already have. A smart EOA can then plug into the same 4337 bundlers and paymasters for gas sponsorship. As the account abstraction team at MetaMask frames it in its developer documentation, 7702 upgrades the account while 4337 standardizes how that account talks to the wider infrastructure.
| Dimension | ERC-4337 | EIP-7702 |
|---|---|---|
| Account address | New smart contract account at a new address | Keeps your existing EOA address |
| Protocol change | None; built entirely at the application layer | Adds native transaction type 0x04 in the Pectra fork |
| Asset migration | Required; you move funds to the new account | Not required; the same account is upgraded in place |
| Ultimate control | The contract’s configured signer or signers | The original private key, which can always repoint or revoke |
| Live since | 2023, via the EntryPoint contract | May 7, 2025, via Pectra |
| Best at | Fully featured smart accounts from day one | Giving hundreds of millions of existing wallets smart features overnight |
The practical upshot is that the two standards divide the labor. If you are building a wallet from scratch, a 4337 account gives you the richest feature set. If you are trying to reach the enormous installed base of people who already hold assets in an EOA, 7702 is the on-ramp, because it asks them to sign a message rather than uproot their funds. Most projects now treat the pair as a stack rather than a choice.
What Smart EOAs Unlock
Once an EOA is delegated, it can do the things that used to require a dedicated smart wallet. The headline features, drawn from the Ethereum Foundation’s guidance and from the wallets that have shipped 7702, fall into four buckets.
- Transaction batching. The classic example is a token swap, which normally needs an approve transaction followed by a separate swap. A smart EOA can bundle both into one atomic action, cutting clicks, reducing gas, and closing the window in which a dangling approval can be abused.
- Gas sponsorship. A dapp or exchange can pay a user’s gas through a paymaster, or let the user pay fees in a stablecoin instead of ETH. This is the feature that makes sign up and start using the app with no ETH in your wallet actually possible.
- Session keys and spending policies. A delegation contract can grant a temporary key that is allowed to do only certain things, for example trade up to a set amount on one game or exchange for one day, without ever exposing the master key.
- Recovery and guardians. Because the account now runs contract logic, it can support social recovery or guardian rules, softening the lose the seed phrase, lose everything failure mode that has defined EOAs since the beginning.
Ambire, which shipped one of the first production integrations, markets the combination plainly: gasless transactions, batched actions, and on-chain simulation from the wallet a user already owns, as the company describes on its product blog. None of these features is new to Ethereum; smart contract wallets have offered versions of them for years. What is new is the audience. These conveniences now reach the single-key browser wallet that a first-time user installs in five minutes, and they reach it without a migration, which is the difference between a feature power users enjoy and a feature the whole market can adopt.
Adoption by the Numbers
Adoption started fast and never really slowed. In the first week after Pectra went live, trackers were already logging thousands of EIP-7702 authorizations on mainnet. By the middle of 2026, the dashboard maintained by BundleBear counted more than 210 million cumulative authorizations, close to 89 million set-code transactions, and roughly 44 million live smart accounts, though that last figure blends genuine wallet upgrades with large numbers of accounts that automated scripts delegated in bulk. The counts move constantly, and the ratio matters more than any single day’s total: authorizations far outnumber unique accounts because a wallet can repoint its delegation many times.
The early leaderboard, compiled from Dune Analytics dashboards in the weeks after launch, is a useful snapshot of who moved first. It is not a current ranking, and the figures below have long since been overtaken, but it captures the shape of the initial land grab, with an exchange delegate contract out in front and wallet providers close behind.
| Provider | Type | Early authorizations | Note |
|---|---|---|---|
| WhiteBIT | Exchange delegate | around 5,300 | Nearly half of all early authorizations |
| OKX Wallet | Wallet | around 3,100 | Highest among wallet providers at the time |
| MetaMask | Wallet | around 1,300 | Fewer authorizations, but more ETH held in its delegate contracts |
Those raw counts come with a heavy asterisk, and it is the same asterisk that has hung over EIP-7702 since day one: a large share of the earliest delegations were not users upgrading their wallets at all. They were criminals.
The Wallets and Exchanges Racing to Ship It
The legitimate adoption is real and broad. Ambire was first to market. MetaMask, the most widely installed Ethereum wallet, folded 7702 into its Smart Accounts Kit (previously the Delegation Toolkit), letting dapps offer batching and gas sponsorship to ordinary MetaMask users. Rabby, Trust Wallet, and TokenPocket added support. Safe, the dominant smart-account platform for treasuries and DAOs, published its own path for combining 7702 with existing Safe accounts. On the exchange side, OKX and WhiteBIT were among the earliest movers, using delegate contracts to smooth onboarding and to sponsor gas for new users.
For exchanges and wallet vendors, the appeal is straightforward. Every extra click and every you need ETH to pay gas error is a place where a new user gives up. Batching and sponsorship remove those frictions without asking the user to learn a new address or trust a new custodian. That is why the wallets-and-exchanges layer, rather than DeFi power users, has driven most of the honest volume. It is also why the security stakes are so high: the same features that make onboarding smooth make a single careless signature catastrophic. For teams weighing the tradeoffs, the discipline that has long governed multisig wallet setups is a useful reference point, because 7702 brings smart-account power to keys that were never held to that standard.
CrimeEnjoyor and the Sweeper Epidemic
Within weeks of launch, the market maker and research firm Wintermute dropped an uncomfortable statistic. Analyzing every delegation on chain, its team found that more than 97% of all EIP-7702 delegations pointed to multiple contracts sharing the exact same bytecode. These were not wallets. They were sweepers, automated contracts designed to drain any ETH that lands in a compromised address the instant it arrives. Wintermute nicknamed the most common one CrimeEnjoyor and, as it wrote in the research that CoinDesk reported, the CrimeEnjoyor contract is short, simple, and widely reused, and this copy-pasted bytecode now represents the majority of all EIP-7702 delegations.
The mechanics are grim but instructive. Attackers who already hold a victim’s private key, usually harvested through an earlier leak or phishing round, spend a tiny amount of gas to delegate that account to a sweeper. From then on, any ETH deposited to the address is siphoned automatically before the victim can rescue it. Wintermute calculated that the operators behind the campaign spent roughly 2.88 ETH to authorize about 79,000 addresses, with a single sweeper handling more than 52,000 of them, as Cointelegraph also documented.
There is an important nuance that the scary headline number obscures. EIP-7702 did not create these thefts, and Wintermute was careful to say the standard is not flawed and is safe to use. The sweepers only work against keys that were already stolen; 7702 simply industrialized the cleanup. And by CoinDesk’s account, the campaign was not even profitable: the drainers had spent gas to blanket tens of thousands of empty addresses that never received fresh deposits. The lesson is that a dominant share of delegations being malicious tells you about the criminal appetite for automation, not about a hole in the protocol.
Anatomy of a $1.54 Million Drain
The sweeper campaign was noisy but low value. A different class of attack proved that 7702 could also enable single, enormous losses. In August 2025, the security firm Scam Sniffer documented a victim who lost $1.54 million in a single phishing transaction tied to EIP-7702, as Cryptopolitan reported. Two days earlier, another user had lost roughly $1 million in tokens and NFTs to the same pattern, and an earlier victim had lost about $66,000.
Here the delegation itself is the weapon. Instead of stealing a key first, the attacker lures the victim to a counterfeit interface, often a clone of a well-known exchange or swap page, and presents what looks like a routine batched approval. Hidden inside that batch is a 7702 authorization that delegates the victim’s account to a contract the attacker controls. One signature, and the attacker can move everything. Known drainer crews, including groups tracked as Inferno Drainer and Pink Drainer, folded the technique into their kits within months. The batching feature that makes honest swaps cleaner is exactly what lets a malicious batch hide a wallet-ending instruction in plain sight.
This is the same lesson the industry keeps relearning from other corners of the 2026 threat map, from oracle manipulation attacks that target the data feeds themselves to social engineering that targets signers: the weakest link is rarely the cryptography. It is the human being clicking approve.
The Auditor’s Checklist
For the developers writing delegation contracts, EIP-7702 opens a set of failure modes that do not exist for ordinary smart wallets. The security firm SlowMist, which has published widely read best-practice guidance, and the custody provider Fireblocks both flag several recurring hazards.
- Storage collisions. Delegating code does not wipe the account’s existing storage. If a user migrates from one delegate contract to another and the new one reuses the same storage slots with different meanings, leftover data can trigger dangerous behavior. SlowMist recommends the namespaced storage layout of ERC-7201 to keep slots from clashing.
- Initialization front-running. A 7702 delegation does not run constructor or init code, so any setup must be gated by an explicit signature from the account owner. A contract that lets just anyone initialize it can be hijacked before the real owner acts.
- Cross-chain replay. An authorization signed with chain_id set to 0 is valid on every EVM chain. That is convenient for deployers and a trap for users, because one signed message can be replayed to delegate the same address elsewhere.
- Blind signing. Wallets should decode and display the exact contract an account is about to delegate to. If the interface hides the target, the user cannot tell a legitimate upgrade from a drain.
The guidance converges on a few rules: delegate only to immutable, audited contracts rather than upgradeable proxies, never sign a chain_id of 0 unless you understand the replay risk, and always confirm the target address. It is worth stressing that an audit is a floor, not a guarantee. As HOGE Wire has documented in cases where firms audited a protocol that was later hacked anyway, reviewed code can still fail in production, and a delegation contract that holds the keys to millions of wallets is an unusually attractive target.
How to Delegate Without Getting Drained
For ordinary users, the defensive playbook is short and worth memorizing. EIP-7702 does not require anyone to change their habits overnight, but the moments when a wallet asks you to sign a delegation are the moments that matter.
- Read the signature request. If your wallet shows that you are setting account code or delegating to a contract, make sure you initiated it and recognize the target address.
- Treat upgrade your wallet prompts on unfamiliar sites as a red flag. A legitimate 7702 upgrade comes from your own wallet or a trusted app, not from a swap page you reached through an ad or a direct message.
- Prefer wallets that decode batched calls into plain language, so a hidden delegation cannot ride along inside a swap.
- Know the escape hatch. Because delegating to the null address removes the code, you can check your account on a block explorer for the 0xef0100 marker and, if something is wrong and you still control the key, revoke it.
The uncomfortable truth is that 7702 raises the cost of a single mistake. With a plain EOA, a bad signature usually approves one token. With a delegated EOA, a bad signature can hand over the whole account. That is a reason for caution, not for avoidance, and it is why the wallet builders shipping this feature have leaned so heavily on clear signing screens and human-readable transaction previews.
What It Means for Exchanges and Custody
The wallets-and-exchanges layer is where EIP-7702 will either prove itself or stall. Exchanges such as OKX and WhiteBIT moved early precisely because sponsored gas and batching solve real onboarding pain, and a smoother first transaction is worth money to any platform competing for retail deposits. Yet the same features raise questions that custody and compliance teams are still working through. If an exchange sponsors gas through a paymaster, who bears the counterparty risk when a batch fails? If a self-custody wallet can be delegated with one signature, how should a regulated venue treat withdrawals to addresses that already carry a delegation marker?
The paymaster question is not academic. Sponsored transactions mean someone is fronting ETH for strangers, and a poorly designed sponsorship contract can be griefed or drained, which is why relayers are advised to require bonds or reputation checks. Compliance desks, meanwhile, have to decide whether a delegated EOA counts as a smart contract for screening purposes, and how to monitor an address whose behavior can change the moment its owner signs a new pointer.
In the United States, the Securities and Exchange Commission has spent 2026 refining how it treats custody and the broader wave of crypto products, a backdrop that also shaped this year’s crypto ETF approvals. Account abstraction is not itself a securities question, but the plumbing it touches, custody, key management, and who is authorized to move client funds, sits squarely inside the SEC’s remit. Firms integrating 7702 are doing so against a set of moving compliance deadlines, and readers tracking those dates can follow our running regulatory countdown. The short version: the technology is ahead of the rulebook, and the venues shipping smart EOAs are making bets on where the rules land.
The Road to Endgame Account Abstraction
Zoom out, and EIP-7702 is a waypoint rather than a destination. The stated goal of Ethereum’s account abstraction effort is a world where the distinction between EOAs and contract accounts disappears entirely, and every account is programmable by default. Buterin has argued that this endgame becomes urgent, not merely convenient, if and when quantum computers threaten the elliptic-curve cryptography that secures today’s private keys, since programmable accounts can swap in quantum-resistant signature schemes while plain EOAs cannot.
7702 is the bridge to that world. It gives hundreds of millions of existing wallets a taste of smart-account life without a migration, and it was deliberately written to be replaceable by deeper native account abstraction later, work that continues in proposals such as EIP-7701. In the meantime, the standard is doing something rare in crypto infrastructure: it is being used at genuine scale, by mainstream wallets and exchanges, for features that ordinary people actually notice. It is also, in the same breath, being used to rob them. Both things are true, and both are the story of EIP-7702 in 2026.
Frequently Asked Questions
Is EIP-7702 safe to use?
The standard itself is considered sound. Even Wintermute, the firm that exposed the sweeper campaign, said EIP-7702 is not flawed and is safe to use. The risk lies in what you delegate to: an audited, immutable contract from a reputable wallet is low risk, while signing a delegation on an unfamiliar site can hand your whole account to an attacker. The feature is safe; blind signing is not.
Does EIP-7702 replace ERC-4337?
No. They are complementary. EIP-7702 upgrades your existing EOA in place so it can behave like a smart account, while ERC-4337 provides the bundlers, paymasters, and EntryPoint infrastructure that smart accounts use for features like gas sponsorship. A smart EOA created with 7702 can plug directly into 4337 infrastructure.
Can I undo an EIP-7702 delegation?
Yes, as long as you still control the private key. A delegation is reset by signing a new authorization that points the account at the null address, which removes the delegated code and returns the account to a normal EOA. You can check whether an address is delegated by looking for the 0xef0100 marker on a block explorer.
Which wallets and exchanges support EIP-7702?
Ambire was among the first, and support now spans MetaMask through its Smart Accounts Kit, Trust Wallet, Rabby, TokenPocket, and the Safe smart-account platform, along with exchanges including OKX and WhiteBIT. The list keeps growing because the feature lets providers offer gasless, batched transactions to users who keep their existing address.
When did EIP-7702 go live on Ethereum?
EIP-7702 activated on Ethereum mainnet on May 7, 2025 as part of the Pectra hard fork. It was proposed by Vitalik Buterin and co-authors in May 2024 as an alternative to the earlier EIP-3074, and it was one of the headline features of the Pectra upgrade.
By the HOGE Wire editorial desk, covering wallets, exchanges, and the infrastructure that moves crypto.