EIP-7702 in 2026: The Complete Guide to Smart-Account Wallets

Fifteen months after Ethereum’s Pectra upgrade went live, the quietest line item in that hard fork has become one of its most consequential. EIP-7702 let tens of millions of ordinary Ethereum addresses start behaving like smart contracts without changing address, moving funds, or abandoning the seed phrase already backing them up. As of late August 2026, on-chain trackers count more than 51 million live delegated accounts and over 230 million cumulative authorizations, according to BundleBear.

It arrived during a strong stretch for Ethereum itself. ETH was changing hands near $2,440 on 25 August, up roughly 30% over the prior week, a move traders tied to spot ETF inflows and treasury accumulation, per CoinDesk pricing (the story of those flows is its own saga, covered in our look at why approval was the easy part). But the deeper shift for anyone who holds or moves crypto is structural: the wallet in your pocket is no longer a dumb key. This guide explains what EIP-7702 is, how a set-code transaction actually works, who adopted it, what it means for exchanges and custodians, and where the sharp edges are.

What EIP-7702 Actually Is

The one-sentence version: EIP-7702 lets a regular Ethereum account, the kind you control with a private key or seed phrase, point to smart-contract code and act like a smart account, one transaction at a time, without giving up the address you already have. For years Ethereum had two account types that never met in the middle. Externally owned accounts (EOAs) are controlled by a key and can only do one thing per transaction; they cannot batch, cannot set spending rules, and cannot let anyone else pay their gas. Contract accounts are programmable but have no private key of their own. EIP-7702 is the bridge between them.

Crucially, it is not an app, a token, or a product you download. It is a protocol change that shipped inside the Pectra hard fork on 7 May 2025. The proposal was authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett (who writes as lightclient), and first appeared in May 2024. The formal text lives in the Ethereum improvement proposal repository as EIP-7702, and the Ethereum Foundation publishes plain-language guidance on the Pectra roadmap page. Everything else in this guide follows from that single, deceptively small idea: give an EOA the ability to temporarily wear a contract’s code.

The name is literal. The transaction sets the code of an externally owned account, something the protocol simply did not allow before Pectra. Where a plain account previously had an empty code field, a 7702 account carries a short pointer to a contract, and Ethereum runs that contract whenever the account is called. Nothing about your keys, your balance, or your address changes; only the code the account executes does, and only for as long as you leave the pointer in place. That is what makes the feature feel invisible to most users even as it rewires what their wallet is capable of underneath.

Why Ethereum Needed It: A Short History

The dream of account abstraction, letting accounts define their own rules for validity rather than hard-coding one signature scheme, is nearly as old as Ethereum. Buterin has said the community has been talking about it since early 2016. The first standard to make it real at scale was ERC-4337, finalized in March 2023, which built smart accounts entirely at the application layer using a separate mempool, bundlers, and an EntryPoint contract. It worked, but it had a catch for existing users: to get a 4337 smart account you had to deploy a brand-new contract wallet with a brand-new address, then move your assets over. Your old EOA stayed dumb.

An earlier attempt, EIP-3074, tried to upgrade EOAs directly by adding two new opcodes, but it drew years of debate over its trust model and was ultimately set aside. EIP-7702 replaced it with a leaner design that adds no new opcodes and stays forward-compatible with the eventual native account-abstraction endgame. Marius van der Wijden, an Ethereum core developer, described the shift as adding a transaction type that lets existing wallets emulate the functions of account-abstraction wallets, while cautioning that it was, in his words, a very early proposal so the team needed to evaluate all the rough edges, per DL News. Alex Jupiter, a senior product manager at MetaMask, framed it in the same coverage as the piece that finally pulled the ecosystem toward one unified account-abstraction roadmap.

The two standards ended up reinforcing each other rather than competing. ERC-4337’s tooling, its bundlers, paymasters, and the shared EntryPoint contract, kept maturing, and a 2025 EntryPoint revision added first-class support for 7702 accounts so an upgraded EOA can use the same gas-sponsorship and batching rails that purpose-built smart wallets rely on. In practice that means a user who upgrades with EIP-7702 is not choosing a lesser version of account abstraction; they are getting the same capabilities through a different door, one that does not force them to leave the address, history, and reputation their old account already carries.

Inside a Set-Code Transaction

The mechanism is a new transaction type, 0x04, sometimes called the set-code transaction. It carries a field called the authorization list, and each entry in that list is a tuple: chain id, the contract address to delegate to, a nonce, and the signature values. You sign each authorization off-chain with your regular key. The signed message uses a domain separator, a MAGIC byte of 0x05, so the message is the hash of 0x05 followed by the encoded chain id, address, and nonce. That separation keeps a 7702 authorization from ever being confused with an ordinary transaction signature.

When the transaction lands, the network writes a small marker into your account’s code slot: the bytes 0xef0100 followed by the 20-byte address of the contract you delegated to, 23 bytes in total. This is the delegation designator. From then on, anyone reading your account sees that it delegates its behavior to that contract, and calls to your address run that contract’s logic. Two properties matter enormously for safety. First, delegation is revocable: sign a fresh authorization pointing to the zero address and the designator clears, returning your account to a plain key. Second, an authorization signed with chain id set to 0 is valid on every chain, which is convenient for multi-chain setups but a genuine cross-chain replay risk if you are not careful. The key still controls the account throughout; delegation does not, by itself, move a single wei.

Two further details matter in practice. The account’s nonce increments when it signs an authorization, which stops an old, revoked authorization from being replayed against the same account on the same chain and keeps a delegation from colliding with an ordinary transaction. And because the delegated code runs in the context of your account, calls made through it use your address as the sender, your balance, and your storage; the contract is not a separate account holding your money, it is a behavior your account borrows. That is the mental model to keep: with EIP-7702 you are not moving assets into a smart contract, you are teaching your existing account new tricks while it stays firmly yours.

EOA, ERC-4337, or EIP-7702?

The three models now coexist, and they are complementary rather than mutually exclusive. Many 7702 accounts delegate to contracts that themselves speak the ERC-4337 standard, so an upgraded EOA can plug straight into the existing bundler and paymaster infrastructure. The table below is the cleanest way to see where each one sits.

What Your Wallet Can Suddenly Do

The point of all this plumbing is a better experience for ordinary users. Once an address is delegated to capable contract code, four things become possible that a plain EOA could never do. The first is batching: approving a token and swapping it, or claiming a reward and staking it, in a single atomic transaction that either fully succeeds or fully reverts. The second is gas sponsorship: a paymaster contract can cover the fee, or you can pay it in a stablecoin like USDC instead of holding ETH for gas. The third is session keys, scoped and time-limited permissions that let a game, a subscription, or an AI agent act on your behalf within strict limits without asking you to sign every move.

The fourth is programmable safety: spending limits, allow-lists, transaction guards, and contract-defined social recovery so a lost key does not have to mean lost funds. The important caveat is that none of these capabilities live in EIP-7702 itself. They live in whatever contract you delegate to. MetaMask’s smart-account implementation, Ambire’s, and Safe’s each expose a different feature set, and delegating to a poorly written or malicious contract inherits its behavior, good or bad. The standard hands you a switch; the contract you flip it toward decides what the switch does.

A concrete example makes the difference tangible. On a plain EOA, buying a token on a decentralized exchange means two separate transactions: first an approval that lets the exchange spend your USDC, then the swap itself, each signed, each paying gas, with a dangling allowance left behind that phishing kits love to exploit. On a 7702-upgraded account the wallet bundles the approval and the swap into one atomic action that reverts entirely if any part fails, and it can scope the approval to the exact amount so nothing is left standing afterward. Fewer signatures, no leftover allowance, and no half-finished state: that is the everyday shape of the upgrade.

Gaming, Subscriptions, and AI Agents

Session keys are the capability with the widest reach beyond finance, and they land closest to home for HOGE Wire readers in exactly the places they already spend time: on-chain games, subscriptions, and the new wave of autonomous agents. A blockchain game that asks a player to approve every move with a fresh signature is unplayable. A session key fixes that by granting a temporary, tightly scoped permission, for example spend up to a set amount of one in-game token, only on this game’s contracts, only for the next few hours, after which it expires on its own. The player signs once, then plays freely, and the master key never leaves cold storage.

The same pattern powers gasless onboarding, where a studio sponsors a new player’s first transactions so they never see a gas prompt, and recurring payments, where a subscription pulls a fixed amount on a schedule instead of holding an open-ended approval. It is also the mechanism behind the AI-agent wallets that arrived in force in 2026: an agent can be handed a session key with a hard spending cap and an allow-list of contracts, so a compromised or misbehaving bot can lose only what its key was scoped to touch, not the whole account. The blast radius is bounded by design, which is the property you want when software, not a person, is holding the pen. EIP-7702 is what lets an ordinary address opt into any of this without migrating to a new wallet first, which is why gaming and agent projects treated Pectra as a starting gun.

There is a catch that studios learned quickly: a session key is only as safe as its scope. Grant one that is too broad, or let it live too long, and it becomes a standing invitation to drain the account it was meant to protect. The better implementations default to narrow limits, short expiries, and per-contract allow-lists, and they surface exactly what a key can do before the user signs it. Done well, session keys are the clearest example of why programmable accounts are worth the added complexity; done carelessly, they are one more footgun wearing a convenience label.

The Adoption Scorecard

Adoption went from a trickle to a flood. The first week after Pectra saw just over 11,000 authorizations on mainnet. By late August 2026 BundleBear counts roughly 230.8 million cumulative authorizations, about 51.4 million live delegated accounts, and more than 96 million set-code transactions across the chains that support the standard. Ambire was first out of the gate, upgrading its EOA users at Pectra activation, and the major consumer wallets followed. A community-maintained registry of who delegates to what lives in the open-source awesome-eip-7702-delegations list.

The shape of that growth tracks where the standard is cheapest to use. A set-code transaction and the batched operations it unlocks cost gas like anything else, so the heaviest genuine usage clusters on low-fee networks, while wallets have leaned on 7702 as the on-ramp that upgrades a user in place rather than asking them to bridge to a brand-new account. That in-place upgrade is the single biggest reason adoption outran every earlier account-abstraction standard in raw account count, even if a large share of the authorizations are automated rather than human.

One number in that dashboard deserves an asterisk. A large slice of the cumulative authorization count is not real users at all; it is attacker infrastructure reusing the same bytecode millions of times. That is the segue into the part of the story wallets would rather you skimmed.

What It Means for Exchanges and Custody

For centralized exchanges, EIP-7702 quietly complicated a routine operation: crediting deposits. When funds arrive from an EOA, that EOA might now be delegated to a contract that behaves in unexpected ways, for example a sweeper that immediately pulls anything sent back out, or code that reverts under conditions an exchange did not anticipate. Compliance and risk teams have responded by screening the 23-byte delegation designator on incoming and outgoing addresses, treating a delegated EOA as a smart contract for the purposes of transaction monitoring rather than as a simple wallet. Withdrawals to delegated addresses get the same scrutiny.

There is an operational wrinkle beyond screening. A delegated EOA can run logic the moment it receives funds, so an exchange sweeping user deposits into an omnibus wallet has to assume an incoming address might behave like a contract rather than a passive key, which changes gas estimation and failure handling. Some venues now route deposits from delegated addresses to manual review, and a few briefly weighed rejecting them outright before settling on designator screening as the proportionate answer. On the withdrawal side the reverse question applies: paying out to a delegated address is usually fine, but the receiving contract’s behavior sits outside the exchange’s control, so support desks have had to learn a new category of failed-withdrawal ticket.

Custodians face the mirror-image question: whether to let institutional clients delegate at all, and to which vetted implementations. On the regulatory side, the picture in the United States is comparatively settled for self-custody. In April 2026, Securities and Exchange Commission staff indicated that software allowing users to transact from self-hosted wallets is not itself acting as a broker, per CoinDesk. Delegating an address does not change that, and it does not change your tax position either; the reporting shift that actually matters for US holders is the one covered in our guide to the crypto tax bill no broker files for you. The broader lesson is that programmability moves complexity from the app into the account, which is exactly the theme we traced across account abstraction in 2026.

The Dark Side: Sweepers, CrimeEnjoyor, and the USENIX Numbers

Within weeks of Pectra, the trading firm Wintermute noticed something strange in the delegation data. More than 97% of early EIP-7702 delegations pointed to the exact same copied bytecode, a sweeper program researchers nicknamed CrimeEnjoyor. The design was blunt: attackers who had already stolen a private key delegated the compromised account to a bot that instantly siphons any incoming funds. Roughly 2.88 ETH had authorized around 79,000 addresses, and a single sweeper contract handled more than 52,000 of them. Wintermute’s analysts were careful to note the campaign was barely profitable, because it targeted wallets that were already empty or compromised, and that this was not a flaw in the standard, per CoinDesk.

The most rigorous accounting arrived in 2026. A peer-reviewed study presented at the 35th USENIX Security Symposium, Revealing the Dark Side of Smart Accounts by Mingyuan Huang and colleagues, reviewed more than 22.8 billion transactions across seven EIP-7702 chains through 15 July 2025. It isolated 3,664,166 authorizations and tied 2,322,548 of them, over 63%, to malicious contracts; it confirmed 924 distinct malicious contracts (793 aimed at EOAs, 124 at contract accounts, and 7 composite attacks), and tallied about $2.36 million in realized losses plus roughly $10.14 million in exposure. The crucial nuance, flagged by CryptoSlate, is that the 63% counts transactions, not users or dollars: attacker contracts are reused disproportionately, so their transaction share balloons. This is a blind-signing and wallet-UX problem, not a broken protocol.

The genuinely dangerous variant is not the sweeper but the phishing kit. Fake dapps prompt a user to sign a 7702 authorization that hands account control to an attacker, sometimes disguised as a routine swap approval. In one August 2025 case a single victim lost $1.54 million in one such transaction, as Cryptopolitan reported. The playbook rhymes with other copy-and-paste scams like address poisoning, where the exploit is human attention, not cryptography. Even so, the aggregate trend improved: overall crypto phishing losses fell 83% to about $83.85 million in 2025, according to Scam Sniffer data cited by Cointelegraph. We mapped the full anatomy of these campaigns in the smart-account switch and its dark side.

The defensive takeaway from all of it is consistent. Almost none of the losses trace to a weakness in EIP-7702 itself; they trace to leaked keys, blind signing, and users approving things they could not read. That is encouraging, because those are fixable with better wallet interfaces and better habits rather than another hard fork, and it is why the security conversation in 2026 shifted from whether the standard is safe to whether your wallet shows you what you are actually signing.

The Risk Map

It helps to separate the failure modes, because they call for different defenses. Some are attacks on already-compromised keys, some are social-engineering traps, and some are developer mistakes in the delegate contracts themselves.

How to Read and Revoke a Delegation

Because delegation is public and reversible, every user has the tools to audit and undo it. Any block explorer will show whether an address carries the 0xef0100 designator and, if so, which contract it points to; dedicated dashboards that decode 7702 delegations have also sprung up. If you ever find a delegation you do not recognize, or you simply want to return to a plain key, the fix is a single signed transaction.

1. Open a wallet that supports EIP-7702 and load the address you want to check.
2. Inspect the current delegation designator on a block explorer to see which contract, if any, your account runs.
3. Choose the switch-back or revoke option, which signs a new authorization pointing to the zero address.
4. Confirm the transaction and verify on the explorer that the designator has cleared and the account is a plain EOA again.

The single most protective habit is simple: never sign a 7702 authorization you did not personally initiate. A legitimate upgrade comes from your wallet’s own settings, not from a website that pops up an urgent request to upgrade your account. Treat any unsolicited upgrade prompt the way you would treat an email asking for your seed phrase, and when a transaction preview and the plain-English description of it do not match, stop and check on a block explorer before you sign.

Footguns for Builders

Developers writing delegate contracts inherit a set of hazards that do not exist for ordinary contracts. The first is storage collision. Because a 7702 account can be delegated, undelegated, and redelegated to different implementations over its life, a naive layout can have new code interpret old storage slots as its own, corrupting balances or permissions. The accepted fix is namespaced storage under ERC-7201, which computes deterministic, collision-resistant slot locations. The second is initialization: unlike a freshly deployed contract, a 7702 delegate has no constructor run at a known moment, so any initialize function must be guarded against front-running, or an attacker can seize the account between delegation and setup.

The third is the chain-id-zero replay window described earlier, which invites signing chain-specific authorizations by default. The fourth, and the one that keeps hurting real users, is blind signing. A hardware wallet that displays only a transaction hash gives the signer no way to see that a batch is draining their account rather than swapping a token, which is precisely how the largest heists of the era succeeded. Clear-signing standards like ERC-7730 aim to make what you sign match what you see, and auditors now treat human-readable signing as a baseline requirement rather than a nicety.

Auditors flag one more risk that is organizational rather than technical. Because a delegate contract can be swapped, a wallet vendor effectively holds an upgrade lever over every account pointing at its implementation, so a compromise of that vendor’s deployment keys, or a malicious update, could in principle reach many accounts at once. Reputable teams pin their delegate to immutable, audited code and make redelegation an explicit user action rather than a silent push, but the concentration is real and worth asking about before you upgrade. Treat the choice of which contract you delegate to as seriously as the choice of wallet itself.

What Comes Next: The Race to Native Account Abstraction

EIP-7702 is a bridge, not the destination. The next chapter moves account abstraction into the base protocol so that smart accounts need no bolt-on infrastructure at all. Three camps are competing to define how. The Ethereum Foundation camp, led by Buterin, has coalesced around EIP-8141, an omnibus he describes as the proposal that wraps up and solves every remaining problem that account abstraction was intended to address, targeted, in his words, at happening within a year at the Hegota fork, per Cointelegraph. A second camp, driven by Coinbase and Base, has proposed EIP-8130, an account-configuration model with fixed key types that Base has said it will ship in an upcoming network upgrade, detailed on the Base engineering blog. A third, from the Paradigm orbit, is a minimalist design known as Tempo.

The reason the ecosystem is not content to stop at 7702 is dependence. Smart accounts today lean on off-chain helpers, bundlers and relays, to get their operations included on-chain, and Buterin has argued that this reliance is a source of fragility because a user has no guaranteed alternative path to inclusion if those intermediaries fail or censor, per news.bitcoin.com. Native account abstraction folds that machinery into the protocol so ordinary nodes handle it directly, and companion work on fork-choice inclusion lists aims to make sure a validator cannot quietly drop a user’s transaction. For everyday holders the change will be invisible; the point is that the plumbing gets harder to break.

None of these has a locked mainnet date, and the Foundation’s own 2026 protocol priorities note that native account abstraction is not yet scheduled. What has already shipped is the groundwork around it: the Fusaka upgrade went live on 3 December 2025, bringing data-availability sampling, as CoinDesk reported. For now, EIP-7702 remains the practical way that a normal address becomes a smart account, and it will likely coexist with whatever native model wins for years.

The Bottom Line for Wallet Users

EIP-7702 did something rare in crypto: it delivered a real upgrade to hundreds of millions of existing users without asking them to migrate, mint, or move funds. The same address you have used for years can now batch actions, accept sponsored gas, hand out scoped session keys, and enforce spending limits, all while staying under the control of your key and reversible in a single transaction. That is a genuine leap in usability, and it is why every serious wallet now supports it.

The catch is that the same feature that gives you superpowers gives attackers a larger surface. Programmability is power, and power delegated to the wrong contract is a drain. The practical takeaways are short: upgrade only through your wallet’s official flow, check your delegation on an explorer if anything feels off, never blind-sign a batch you cannot read, and revoke to the zero address the moment you are unsure. Do those four things, and EIP-7702 is one of the best things to happen to self-custody in years. Ignore them, and it is one more way to lose everything with a single signature.

Zoom out and the trajectory is clear. Account abstraction spent years as a promise that required abandoning your wallet to reach; EIP-7702 delivered most of it to the account you already have, and the native proposals now in the pipeline aim to make the whole thing a default rather than an opt-in. The technology is not finished, and the security lessons of its first fifteen months are worth taking seriously. But the direction is set: the Ethereum account of 2027 will look far more like a programmable vault than the bare keypair it started as, and most users will get there without ever having to move.

Frequently Asked Questions

What does EIP-7702 do?

EIP-7702 lets a normal Ethereum account, the kind controlled by a private key or seed phrase, temporarily point to smart-contract code and act like a smart account. It shipped in the Pectra upgrade on 7 May 2025 and enables features like batching several actions into one transaction, letting an app or a paymaster cover gas, and setting scoped session keys, all without creating a new wallet or moving your funds.

Is EIP-7702 safe to use?

The standard itself has held up; the risks come from what you sign. Security researchers found that most early delegations were attacker-controlled sweeper bots targeting already-compromised keys, and phishing kits now use 7702 to drain a wallet with a single batched signature. Using a reputable wallet’s official upgrade is low risk; signing an unexpected upgrade prompt from a random dapp is not.

How do I revoke an EIP-7702 delegation?

You revoke by signing a new authorization that points your account to the zero address, which clears the delegation designator and returns the account to a plain key. Most wallets that support 7702 expose this as a switch-back option, and block explorers let you confirm the designator is gone.

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

ERC-4337 builds smart accounts entirely at the application layer, so you deploy a new contract wallet with a new address. EIP-7702 upgrades the address you already have by delegating it to contract code, and it required a change to Ethereum’s core protocol. The two are complementary: many 7702 accounts delegate to contracts that speak the 4337 standard.

Does EIP-7702 replace my seed phrase or move my funds?

No. Your private key still controls the account, delegation is reversible, and signing an authorization does not by itself move any assets. It only sets which contract code your account runs, which is why the danger is signing a malicious delegation rather than the mechanism itself.

Marcus Okafor covers wallets, custody, and market structure for HOGE Wire.