EIP-7702 in 2026: The Smart-Account Upgrade, Explained

When Ethereum shipped its Pectra upgrade on 7 May 2025, the change that mattered most was not a new token standard or a fee cut. It was a quiet rewrite of what an ordinary wallet is allowed to be. EIP-7702, titled “Set Code for EOAs,” let a normal externally owned account, the kind behind every MetaMask login and hardware wallet, borrow the code of a smart contract and, for as long as the owner chooses, behave like one. No new address, no migration, no seed phrase to abandon.

Sixteen months on, that quiet rewrite has become some of the busiest plumbing on the network. As of 1 September 2026, on-chain trackers count more than 235 million cumulative authorizations and over 53 million live delegated accounts, according to BundleBear. Ether changed hands near $2,450 the same day, per CoinDesk, in a market still digesting late-summer inflation prints. The token price is almost beside the point here; the adoption curve is the story.

This guide walks through what EIP-7702 is, how a set-code transaction works, what your wallet can suddenly do once you sign one, and where the sharp edges are. It also covers the part the marketing decks skip: the same one-signature power that lets a wallet batch trades and sponsor gas is exactly what a phishing page needs to empty an account in a single click. And it looks at the protocol-level successor that was supposed to make 7702 redundant this very month, then slipped.

What EIP-7702 actually is

Ethereum has always run on two kinds of accounts. Externally owned accounts, or EOAs, are controlled by a private key; they can hold funds and fire off transactions, but they cannot run any logic of their own. Contract accounts run code, but they cannot begin a transaction; something else has to call them first. For roughly a decade, anyone who wanted programmable features, spending limits, batched actions, or recovery that did not depend on a memorized phrase, had to use a smart-contract wallet. That meant a brand-new address and the chore of moving assets across.

EIP-7702 folds those two account types together. Its specification, written by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, gives an EOA a way to point at a smart contract and adopt that contract’s code, while keeping the same address, the same balance, and the same private key. The account stays yours; it simply gains a brain for as long as the pointer is in place. And because the pointer is revocable, you can aim it back at nothing and the account is a plain key-controlled EOA once more.

Marius van der Wijden, an Ethereum core developer, captured the design early on, telling DL News that the proposal “adds a new transaction type that allows existing wallets to emulate the functions of Account Abstraction wallets.” The operative word is emulate. Your key still signs; the borrowed code only decides what that signature is allowed to do.

From EIP-3074 to Pectra: how we got here

The idea of giving EOAs superpowers is older than 7702. An earlier proposal, EIP-3074, tried to do something similar with two new opcodes, AUTH and AUTHCALL, that let a trusted contract act on behalf of an account. It spent years in review and drew objections: the new opcodes were invasive, and handing a contract broad authority over an EOA worried security researchers. By 2024, core developers were unwilling to ship it.

Buterin’s answer, floated in May 2024, was to capture most of 3074’s benefits with none of its new opcodes. Instead of teaching the EVM new instructions, 7702 reuses a mechanism the network already understood, contract code, and lets an EOA borrow it. That framing kept it forward-compatible with the long-term goal Ethereum calls account abstraction, where every account is programmable by default. Alex Jupiter, a senior product manager at MetaMask, told DL News that the shift finally put the ecosystem on “one unified Account Abstraction roadmap.”

The other piece of that roadmap, ERC-4337, had been live since March 2023. It delivered smart accounts without any change to Ethereum’s core rules, using a separate system of bundlers and a shared EntryPoint contract. 7702 does not replace 4337; the two are built to fit together, and the latest EntryPoint release even ships native 7702 support. When Pectra activated on 7 May 2025, 7702 went live with it, and delegations started appearing the same day.

Not everyone was ready to call it finished. Van der Wijden also cautioned, in the same DL News interview, that “it’s still a very early proposal, so we need to evaluate all the rough edges.” Sixteen months of mainnet traffic have found several of those edges, which is a large part of this story.

Anatomy of a set-code transaction

The mechanics are worth understanding, because the security model follows directly from them. 7702 introduces a new transaction type, numbered 0x04 and usually called the set-code transaction. What makes it special is a field called the authorization list. Each entry is a tuple: a chain ID, the address of the contract whose code you want to borrow, a nonce, and a signature (the y-parity, r, and s values).

When that transaction lands, the network writes a small marker into the EOA’s code field. The marker is 23 bytes: a three-byte prefix, 0xef0100, followed by the 20-byte address of the delegate contract. This is the delegation designator. From then on, any call to your address runs the delegate’s code, but in the context of your account, using your balance and your storage. The signature that authorizes all of this is built over a specific message: the keccak256 hash of 0x05 concatenated with the encoded chain ID, delegate address, and nonce. That leading 0x05 is a domain-separator byte that keeps these authorizations from being confused with anything else your key signs.

Two details carry outsized weight. First, revocation is built in: to clear a delegation, you sign a fresh authorization pointing at the zero address, and the 23-byte marker disappears. Second, the chain ID can be set to zero, which tells the network the authorization is valid on any chain. That is convenient for people who want the same setup everywhere, and it is a cross-chain replay risk for anyone who signs one without realizing it, because a captured authorization can then be replayed on another network.

Because a set-code transaction can be submitted by someone other than the account owner, 7702 also quietly enables gas sponsorship: a third party can pay to include your delegation and your follow-up actions. That is the same submit-on-your-behalf pattern that powers relayers and, less benignly, the searchers who reorder transactions for profit, a dynamic we unpacked in our guide to MEV strategies. In 7702’s case the sponsor cannot move your funds; it can only foot the bill.

EOA, ERC-4337, or 7702: three ways to hold Ether

It helps to line up the three account models side by side. A plain EOA is the classic key-only account. An ERC-4337 smart account is a full contract wallet with its own address. A 7702-delegated EOA is the hybrid: your existing key-controlled address wearing a contract’s code.

What a delegated EOA can suddenly do

Once your address is delegated to a capable contract, a set of features that used to demand a separate smart wallet becomes available without leaving your address behind.

• Batching: approve a token and swap it in a single atomic transaction, instead of two separate signatures that can strand you halfway.
• Gas sponsorship: let an app or a paymaster cover the network fee, sometimes in a stablecoin rather than Ether. Circle’s paymaster, for one, lets a delegated account pay gas in USDC.
• Session keys: grant a narrow, time-limited permission to a game or an agent so it can act without prompting you for every move.
• Spending limits and guards: cap how much can leave the account in a given window, or require extra conditions before a large transfer clears.
• Recovery: configure trusted parties or devices that can help you regain control, easing the all-or-nothing dependence on one seed phrase.

None of this is magic. Every one of these features lives in the delegate contract, not in the protocol; 7702 only provides the hook that lets your EOA run that contract’s code. Which contract you delegate to therefore decides everything, a point that turns uncomfortable in the security section. Circle documented the stablecoin-gas path in its own write-up on gasless USDC.

Session keys, games, and AI agents

The feature crypto gaming has wanted for years is the session key, and 7702 makes it practical on accounts people already own. A session key is a scoped permission: you authorize a specific contract to perform a specific class of action, for a set period, up to a set limit, without signing each time. For a game, that means a player can move, craft, or trade in-game items across a long session with one upfront approval, instead of a wallet pop-up every few seconds.

The same primitive is what makes autonomous agents usable. An AI agent that trades, pays for compute, or manages a portfolio needs authority to act on-chain, yet nobody wants to hand a bot the master key. A session key lets the owner delegate a slice of authority, revocable at any time, the pattern MetaMask formalized in its advanced-permissions work. The catch is that a session key is only as safe as the contract enforcing its limits and the trust you place in the agent; a compromised or overly broad permission is a standing invitation. That trust problem is why so much 2026 infrastructure is devoted to proving what an agent actually did, a subject we covered in our piece on verifiable compute for AI agents.

Who turned it on: the 2026 adoption scorecard

Adoption came from wallets first. Ambire was the first consumer wallet to ship 7702 delegation; MetaMask made it the primary upgrade path for its enormous base of existing users, branding the result Smart Accounts. Rabby, Trust Wallet, OKX Wallet, and others followed with opt-in smart-account features. On the infrastructure side, the account-abstraction team’s EntryPoint v0.8 added native 7702 support and a reference Simple7702Account, stitching the two standards together.

The aggregate numbers make the case. BundleBear’s dashboard counts more than 235 million cumulative authorizations, over 98 million set-code transactions, and north of 53 million live delegated accounts as of 1 September 2026. A community-maintained registry of delegate contracts tracks which implementations wallets actually point at. The table below is a snapshot, not a ranking; support keeps expanding.

One caveat about the headline figures: authorizations, set-code transactions, and live delegations measure different things, and a large share of raw authorizations came from automated scripts rather than distinct human users. The live-delegations count, the number of addresses currently carrying a delegation, is the closest proxy for real usage, and even that oscillates as accounts delegate and revoke.

How exchanges and custodians are coping

Centralized exchanges and custodians met 7702 with caution, because a delegated EOA behaves differently from the plain deposit addresses their systems were built around. When a user deposits from a 7702 account, or when a deposit address itself carries a delegation, the funds can be swept by the delegate the instant they arrive, before an exchange’s crediting logic runs. That has pushed operators to screen for the 23-byte 0xef0100 designator on incoming and outgoing addresses and to treat delegated accounts as their own risk category.

The compliance overlay matters too. Exchanges remain the regulated choke points, and their duty to identify counterparties does not vanish because an address is programmable; the same Travel Rule plumbing that governs a normal withdrawal still applies, as we detailed in our explainer on the crypto Travel Rule. For custodians holding institutional funds the calculus is stricter still: a delegate contract is code that can move client assets, so it has to be reviewed like any other dependency, and many simply block delegated deposit addresses outright.

The dark side: sweepers, drainers, and the single-signature takeover

The uncomfortable truth about 7702 is that its best feature and its worst attack are the same mechanism. If signing one authorization can upgrade your account, then tricking you into signing one authorization can give it away. Researchers have spent the past year measuring exactly how that plays out.

The earliest scare was mostly noise. Within weeks of Pectra, the trading firm Wintermute found that the overwhelming majority of early delegations, more than 97 percent, pointed at identical copy-pasted “CrimeEnjoyor” sweeper bytecode, as it told CoinDesk. These contracts automatically forward any Ether that lands in an already-compromised account to the attacker. Alarming as the share sounded, the money involved was tiny, because the targets were wallets whose keys had already leaked; the sweepers were mopping up dead accounts, not breaking into live ones. This was not a flaw in 7702.

The genuine threat is phishing, and it has grown more sophisticated. A study presented at the 2026 USENIX Security Symposium analyzed more than 3.6 million 7702 authorizations across seven chains and tied over 63 percent of them to malicious contracts, with about $2.36 million in realized losses. A separate December 2025 paper, EIP-7702 Phishing Attack by Minfeng Qi and co-authors, examined more than 150,000 authorization and execution events across roughly 26,000 addresses and concluded the attack surface is already being exploited at scale. Its central finding is unsettling in its simplicity: an attacker can induce a victim to sign a single authorization tuple that grants persistent, unconditional control over the account.

The damage from individual cases is real. In 2025, one victim lost about $1.54 million to a single 7702 phishing transaction dressed up as a routine interaction, as Cryptopolitan reported. The wider picture is more encouraging: overall crypto phishing losses actually fell 83 percent in 2025 to about $83.85 million, according to Scam Sniffer data cited by Cointelegraph, even as 7702-based batch-signature scams became a bigger slice of what remained. Once a drainer succeeds, clawing the money back is close to hopeless, a reality we examined in after the rug pull.

How to read, and revoke, your delegation

Because a delegation is public and revocable, you can always check what your account points at and undo it. The steps are simple.

1. Look up your address on a block explorer such as Etherscan. A delegated account shows a code field that begins with the 0xef0100 designator followed by a 20-byte address.
2. Decode that address, either from the explorer or with a dedicated checker, and confirm it is a contract you recognize and chose to use.
3. If the delegate is unfamiliar, treat the account as compromised: move any remaining funds to a fresh wallet from a clean device before doing anything else.
4. To revoke a delegation you no longer want, sign a new set-code authorization pointing at the zero address. This clears the 23-byte marker and returns the account to a plain EOA.
5. Refresh the explorer and confirm the code field is empty again.

One rule survives all of this: never sign an authorization you do not understand. A wallet that shows you the delegate address in plain language is doing its job; a signing prompt that shows only an opaque hash is asking you to trust blindly, which is where most losses begin.

Footguns that bite builders

The risks are not only on the user side. Because a 7702 account reuses the same storage as the EOA and can be re-delegated over time, contract developers face a specific set of traps.

• Storage collisions: if one delegate writes to storage slots a later delegate interprets differently, funds can be lost or locked. The standard defense is namespaced storage under ERC-7201, which spaces each contract’s state apart.
• No init code: unlike a freshly deployed contract, a delegated account has no constructor, so any setup logic runs as an ordinary call that an attacker may be able to front-run. Initializers must be idempotent and guarded.
• Replay exposure: authorizations signed with chain ID zero are valid everywhere, so a signature meant for one network can be reused on another. Chain-specific authorizations avoid this.
• Blind signing: if the wallet cannot decode the delegation for the user, even a careful person is signing on faith. Clear-signing standards and hardware wallets that parse the payload are the answer.

These are the reasons auditors now treat delegate contracts as high-stakes code. A delegation is not a suggestion to the account; it is executable authority over it, which is precisely why the wallet you trust to display and vet that authority matters as much as the contract behind it.

Where the SEC and the rulebook stand

For readers in the United States, the regulatory question about 7702 is really a question about self-custody, and the answer sharpened in 2026. In an April 2026 staff statement, the SEC signaled that software which merely lets a user transact from a self-hosted wallet is not, on its own, acting as a broker, provided it stays neutral and does not solicit, route, or take custody, as CoinDesk reported. A 7702 wallet, by that logic, is the user’s own tool, not a regulated intermediary.

That does not put smart accounts entirely outside the rules. The moment a service takes custody, sponsors gas as a business, or offers hosted recovery, it starts to resemble a regulated activity, and those lines are still being drawn. Exchanges and custodians touching 7702 accounts keep their existing obligations, including the counterparty-identification duties noted above. For most individual users the tax treatment is unchanged: a delegated EOA is still your account, and gains or losses are reported the same way whether you hold through a bare key or a smart account.

The native-abstraction question, and why it just slipped

7702 was always described as a bridge, not a destination. The destination is native account abstraction, where programmability is built into the protocol itself instead of bolted on through delegation or a separate contract system. Several proposals are competing to be that destination, and one of them was meant to reach mainnet this month.

The frontrunner is EIP-8130, an account-abstraction-by-configuration design championed by Coinbase’s Base team. Base had planned to ship it in a network upgrade called Cobalt in September 2026, promising more than a twofold cut in per-transaction cost, with a native USDC transfer dropping roughly 63 percent in gas, according to the Base engineering blog. Momentum had been building: Pedro Gomes, the founder of WalletConnect, wrote that after months on a rival design he had become “convinced EIP-8130 is the better path for native account abstraction,” calling it “simpler, more portable, and focused on what wallets actually need,” in a post on X.

Then the date moved. As of early September, Base’s own upgrade documentation lists Cobalt’s mainnet activation as to be determined, with EIP-8130 still running only on an experimental devnet, as Bitcoinist noted. The September mainnet expectation has quietly become a maybe. We tracked the full state of that transition in account abstraction goes native.

The other leading contender, EIP-8141, takes a more ambitious “frame transaction” approach and is being weighed for a later upgrade Buterin calls Hegota. He has described it as an omnibus that, in his words, “wraps up and solves every remaining problem that AA was intended to address,” and suggested the whole thing could arrive “within a year,” per Cointelegraph. Client teams have flagged the complexity, and no fork has locked it in. The practical upshot for users is simple: native abstraction is coming, but not this month, which leaves 7702 as the bridge everyone is actually standing on.

The bottom line

Sixteen months in, EIP-7702 has settled into the role its designers hoped for and its critics feared. For ordinary users it delivered the thing account abstraction always promised, smart-wallet features without a new address or a discarded seed phrase, and tens of millions of accounts have taken it up. For attackers it turned one careless signature into a full account takeover, and the research now shows that abuse is neither theoretical nor rare.

The right posture is neither hype nor panic. Delegate only to contracts you or your wallet vendor can vouch for; insist on a wallet that shows the delegation target in plain language; check your own account’s code field now and then; and revoke anything you do not recognize. Do that, and 7702 is the most useful upgrade an Ethereum wallet has had in years. Ignore it, and it is the sharpest new tool in a phisher’s kit. The technology is the same either way; the difference is entirely in what you sign.

Frequently Asked Questions

What is EIP-7702 in plain English?

It is an Ethereum upgrade, live since the Pectra hard fork in May 2025, that lets an ordinary wallet address borrow the code of a smart contract and act like a smart account, while keeping the same address, balance, and private key. You sign a special set-code transaction to turn it on, and you can turn it off again by pointing the account back at nothing.

Is EIP-7702 safe to use?

The mechanism itself is not the problem; the risk is what you delegate to. Delegating to a reputable, audited wallet contract is broadly considered safe and is how millions of accounts use it. Signing an authorization for an unknown contract, usually because a phishing site asked you to, can hand your entire account to an attacker in one signature, which is the main documented way people lose funds.

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

Look up your address on a block explorer like Etherscan; a delegated account shows a code field starting with the bytes 0xef0100 followed by the delegate’s address. To revoke, sign a new set-code authorization that points at the zero address, which clears the delegation and returns the account to a normal EOA. If you do not recognize the delegate, move your funds to a fresh wallet first.

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

ERC-4337 creates a full smart-contract wallet with its own new address, using a separate system of bundlers and an EntryPoint contract. EIP-7702 upgrades an existing key-controlled address in place, with no migration. They are complementary rather than competing, and the latest ERC-4337 EntryPoint release supports 7702 accounts directly.

Does EIP-7702 change my address or replace my seed phrase?

No. Your address and your private key stay exactly the same; the delegation is layered on top and can be removed at any time. It can enable recovery features that reduce your reliance on a single seed phrase, but only if you choose a delegate contract that offers them, and the underlying key still controls the account.

By Marcus Okafor, senior markets writer at HOGE Wire, covering Ethereum infrastructure, wallets, and exchanges.