EIP-7702 in 2026: The Delegation You Forgot to Revoke

Something odd sits in Ethereum’s on-chain record. Since the Pectra upgrade activated on 7 May 2025, wallets have signed more than 255 million EIP-7702 authorizations. Yet the number of accounts that actually behave like smart accounts right now is closer to 60 million. That gap is not a rounding error. It is the story of a feature that quietly rewired how ordinary Ethereum addresses work, then left tens of millions of users with a pointer attached to their account that most have never looked at, cannot easily see, and have no plan to remove.

EIP-7702 has been explained many times, including here at HOGE Wire. What stays under-covered is the part that matters most once the novelty fades: a delegation is not a session that ends when you close a tab. It is stored state that stays attached to your address until you actively clear it. This piece is about that persistence, why it is a convenience and a liability at once, and the practical mechanics of checking, updating, and revoking the code your account points to.

What EIP-7702 actually changed

Before Pectra, every Ethereum address was one of two things. It was either an externally owned account (EOA) controlled by a private key, with no code of its own, or a smart contract with code but no key. EIP-7702, shipped as part of Pectra, broke that wall. It added a new transaction type (0x04, the set-code transaction) that lets an EOA point at the code of a smart contract while keeping the same address and the same private key. The formal specification lives at eips.ethereum.org.

Mechanically, the account stores a 23-byte marker: the fixed prefix 0xef0100 followed by the 20-byte address of the contract it delegates to. When a transaction reaches that address, the EVM runs the delegate’s code in the context of your account. Your key still authorizes everything; the code simply gives the key new abilities, such as batching several actions into one transaction, letting someone else pay the gas, and granting scoped session keys. Two properties define the rest of this story: the delegation is chain-specific, so a designator set on Ethereum mainnet does not exist on Arbitrum or Base unless you authorize it there too, and it is revocable.

The design took years to reach that shape. An earlier proposal, EIP-3074, tried to give EOAs similar powers through new opcodes, but it leaned on helper contracts called invokers and was set aside as too invasive. ERC-4337 then delivered account abstraction entirely off to the side, without touching the base protocol. EIP-7702 is the compromise that shipped: a minimal, forward-compatible bridge that borrows 4337 infrastructure while letting ordinary keys keep their address. That lineage matters, because 7702 was always meant as a bridge toward native account abstraction rather than the final destination, which is why its rough edges were tolerated in the first place.

That second property, revocability, is where most of the interesting problems live in 2026.

255 million authorizations, 60 million live accounts

Adoption dashboards make EIP-7702 look enormous. As of late September 2026, BundleBear counts more than 255 million cumulative authorizations and over 107 million set-code transactions across supported chains. The metric that describes reality, though, is the third one: roughly 60 million live delegations. The distance between a quarter of a billion authorizations and 60 million active accounts is not a glitch. It is the accumulated residue of a feature in heavy use, and it is the clearest sign that authorizations pile up while live delegations churn.

Three forces drive that gap. The first is sweeper bots. A large share of the earliest authorizations came from automated drainers, not real users, a pattern the trading firm Wintermute flagged within weeks of Pectra and nicknamed CrimeEnjoyor. Those contracts re-authorize the same compromised addresses over and over, inflating the cumulative count without adding a single genuine smart account. Treat the headline authorization figure as a ceiling, not a user count.

The second force is updates. Every time a wallet moves a user to a new implementation, that is a fresh authorization; the old one is superseded, not erased from the historical tally. The third is revocation. Users and wallets do reset delegations back to nothing, which removes them from the live count while leaving the original authorization in the record forever. The practical takeaway is rarely stated plainly: hundreds of millions of authorizations have been signed, the live footprint is a smaller and constantly shifting set, and a meaningful slice of the addresses that ever carried a designator still carry one that nobody is thinking about.

That distinction is not academic. Every live delegation is an address whose behavior now depends on a contract someone else wrote, and every abandoned one is a loose end on an account that still holds a key. Dashboards report the big number because it is the impressive one, but the security-relevant figure is how many real users have an active designator and know what it points to. On that question the honest answer is that nobody has a precise count, because the on-chain data shows the pointer, not whether a human is paying attention to it.

EOA, ERC-4337, and EIP-7702: three roads to a smart account

It helps to place EIP-7702 next to the two other ways an Ethereum user can end up with smart-account features.

ERC-4337, finalized in March 2023, builds a whole parallel system: a singleton EntryPoint contract, off-chain bundlers, and a separate mempool of UserOperations, all without changing Ethereum consensus. Its cost was migration. You had to move funds to a brand-new contract address to get the benefits. EIP-7702 skipped that step. It let the address you already own, the one you have already handed to exchanges, friends, and tax software, gain the same abilities in place. That convenience is exactly why persistence matters: the smart behavior is bolted onto the identity you keep, not a fresh account you can simply abandon.

What a delegation lets your wallet do

The upside is real, and it is why wallets adopted the feature so fast. A delegation turns a bare key into something closer to a programmable account.

• Atomic batching. Several actions execute as one transaction, so an approve-then-swap collapses into a single step. That closes the window between the two that front-runners exploit and smooths interaction with on-chain venues, from spot DEXs to the perpetual-futures platforms that now dominate on-chain derivatives.
• Gas sponsorship. A paymaster can let you pay fees in a stablecoin, or let a dapp cover them entirely, which removes the need to hold ETH just to move a token.
• Session keys. A narrow, temporary key can be granted to an application, so a game or an autonomous AI agent can act within strict limits without ever touching the master key.
• Programmable guards. Spending limits, allow-lists, and social-recovery hooks can be layered on, turning security policy into code rather than habit.

Each of these is a reason to delegate. None of them is a reason the delegation should ever be forgotten, which is the tension the rest of this article works through.

From opt-in to on-by-default

For most of its first year, EIP-7702 was something you opted into. In September 2026 that changed in a way few users noticed. On 21 September, Alchemy’s Modular Account v2 (release v1.1.0) made 7702 delegation the default for new accounts on its stack, a change its documentation now states as plain current behavior rather than a forward-looking migration note (GitHub). MetaMask, which offers a 7702 upgrade path to a very large user base, has pushed smart-account features into its mainstream product rather than a lab setting. Default-on delegation is what maturity looks like: the abilities arrive whether or not the user asked for them by name.

Ethereum core developer Marius van der Wijden described 7702 early on as a way for existing wallets to emulate the functions of account-abstraction wallets, while cautioning that the ecosystem still had to work through its rough edges (DL News). MetaMask senior product manager Alex Jupiter framed the same shift more optimistically, calling 7702 part of one unified account-abstraction roadmap. Both were right, and both point at the same consequence: as delegation becomes the default, its housekeeping stops being a power-user concern and becomes everyone’s.

The pointer that persists: why a delegation does not expire

Here is the mental model that trips people up. A token approval, a WalletConnect session, a signed login: these are the reference class most users reach for when they think about connecting an account, and all of them are either scoped or forgettable because they lapse. A 7702 delegation is not like that. It is written into your account’s state on-chain. It does not time out. It does not clear when you close your wallet, switch phones, or stop using the dapp that prompted it. It stays exactly where it is, pointing at exactly the same contract, until a new authorization overwrites it or a reset removes it.

That permanence is deliberate and, for the intended use, correct. You want your account to keep behaving like a smart account between sessions. But it inverts the usual hygiene. With approvals, the danger is granting too much; with delegations, the danger is granting once and then never revisiting. And because a delegate contract can itself be an upgradeable proxy, the code your address runs today is not guaranteed to be the code it runs next month. The provider behind the designator can change the logic under you without a new signature. Delegating is a standing trust decision, not a one-time click.

The proxy point deserves weight, because it is the part most users miss entirely. When you delegate to a wallet provider’s account contract, you are often not pointing at fixed code; you are pointing at an implementation the provider can upgrade. That is convenient, since it lets a wallet ship fixes to millions of accounts at once, and it is also a concentration of power, since whoever controls that upgrade path shapes what your account can do. It is the same tradeoff custodians have always faced, moved one layer down, into an account you still think of as entirely your own.

How to see what your address points to

Most users have no idea whether their address is delegated, because wallets surface the feature inconsistently. The ground truth is on-chain, and anyone can read it.

The manual method uses a block explorer. Open your address on Etherscan and look at the code field. If it is empty, you are a plain EOA. If it starts with ef0100, you are delegated, and the 20 bytes after that marker are the contract you delegated to. Copy that address and confirm it is one you recognize, such as your wallet provider’s account implementation. If you do not recognize it, stop sending funds and treat the account as suspect.

Friendlier tooling exists. Revoke.cash, long the standard for auditing token approvals, added a delegations tab that lists any 7702 delegation on your account. The limitation is instructive: you can inspect a delegation there, but you cannot revoke it from Revoke.cash. Most wallets refuse to let an external dapp change a 7702 designator, so the removal has to happen inside your wallet app. That restriction is a safety feature, not an oversight.

How to revoke a delegation, and what revoking does not do

Revocation has a canonical form: sign a new authorization that points your account at the zero address, 0x0000000000000000000000000000000000000000. That clears the delegation and returns the account to plain-EOA behavior. The mechanics, set out in the specification and in OpenZeppelin’s EOA delegation docs, are worth understanding before you rely on them.

1. In practice, do it inside your wallet. In MetaMask, open Account Details, find the smart-account section, and disable or revoke the delegation for each chain where you set one.
2. If you prefer to act directly, submit a set-code transaction whose authorization tuple targets the zero address, using a nonce higher than the current one.
3. Confirm the result the way you checked it: the code field on Etherscan should be empty again.
4. For a compromised account, do not improvise. The Flashbots whitehat channel exists for exactly this kind of rescue, and open-source tooling such as the eip7702-clean-delegation CLI can revoke delegations, including a sponsored mode for accounts that hold no ETH for gas.

Now the caveat that catches people. Resetting to the zero address clears the code and resets the code hash to the empty value, but it does not wipe the storage a delegate may have written into your account. Leftover storage slots can linger and, depending on the next contract you delegate to, be misread. That is why serial re-delegation across unrelated implementations is a real footgun, and why pointing an account back at zero is necessary but not always sufficient.

There is also a multiplication problem. Because delegations are set per chain, an active user can accumulate designators on Ethereum, Base, Arbitrum, and more, each one a separate authorization that has to be checked and cleared on its own. Revoking on mainnet does nothing for the copy on Base. This is the part of the cleanup that scales badly: the more chains you use, the more places a stale or malicious pointer can hide, and no single action clears them all at once.

The abandoned-delegation problem

Persistence produces a whole population of delegations that nobody is minding. Start with the malicious ones. Wintermute’s CrimeEnjoyor finding was that the overwhelming majority of early 7702 delegations were sweeper bots installed on addresses whose keys had already leaked. Those designators are, in a narrow sense, harmless: they cannot newly compromise a key that was already lost. But they never go away. Millions of dead addresses now carry a permanent pointer to a drainer, a monument to a compromise that happened once.

Then there are the merely stale. A user tries a wallet, gets migrated to its 7702 implementation, moves to a different wallet, and never revokes the old designator. A dapp sunsets its account contract, but the delegations pointing at it remain. A provider ships a proxy upgrade, and the code behind millions of designators changes without any user signing anything new. None of this is catastrophic on its own. Collectively it is a large, quiet attack surface and an accountability mess, the kind of ambiguity that turns into finger-pointing after something goes wrong, as HOGE Wire has documented in the blame wars that follow major hacks. The uncomfortable part is that nobody owns the cleanup: not the wallet that set the delegation, not the dapp that prompted it, and often not the user, who does not know it is there.

Wallet teams are starting to treat this as a product problem rather than a user error. Some now show a persistent badge when an account is delegated, prompt a review of unknown designators, and make the revoke path easier to find than it was a year ago. That is progress, but it is uneven: coverage varies by wallet, and the tens of millions of designators already sitting on addresses were set before any of these prompts existed. Cleaning up the installed base is a harder problem than improving the next signature.

When a delegation turns against you

The security research on 7702 reads differently once you hold the persistence idea in mind. A study presented at the 35th USENIX Security Symposium analyzed millions of 7702 authorizations across seven chains and tied roughly 63 percent of them, measured by transaction count, to malicious contracts, alongside 924 manually confirmed malicious contract accounts and several million dollars in realized losses and exposure. That 63 percent number is often misread as a protocol flaw. It is not. It counts transactions, which attacker contracts reuse heavily, and the root problem is that a user signed something they did not understand.

The persistence lens sharpens the stakes. When the thing you sign is a delegation, one bad signature is not a one-time loss, it is a standing grant. A drained approval empties one token; a malicious delegation hands over the account itself, and because a delegation persists until it is actively reset, that control lasts until someone notices and clears it. This is why blind signing, approving a transaction whose payload you cannot read on your device, is the central risk, and why clear-signing standards matter more here than almost anywhere else.

Researchers who have mapped 7702 phishing describe several routes to a malicious delegation. A victim can be tricked into signing the authorization directly; an attacker who already holds the key can install a delegate to automate future theft; and a weakly built delegate contract can expose functions that a third party triggers later. The common thread is that the damaging step is a signature, not a break in the protocol, and that the resulting control does not end when the transaction confirms. It sits on the account, waiting, which is exactly why checking and revoking are not optional housekeeping.

Two caveats keep the picture in proportion. Phishing losses are actually falling: Scam Sniffer reported that 2025 drainer losses dropped about 83 percent to $83.85 million, even though a single 7702 phishing victim lost $1.54 million. And as MetaMask security researcher Taylor Monahan put it, “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 feature did not create the danger. It raised the stakes of a signature.

Exchanges and custody: deposit addresses that run code

For exchanges, delegated EOAs are an operational headache with a specific shape. A user can deposit from an address that runs code, and code can behave in ways a plain-EOA deposit flow never anticipated: rejecting transfers, re-entering, or forwarding funds automatically. The industry response has been to screen the designator directly. Because a delegated account’s code is always exactly 23 bytes (0xef0100 plus 20 address bytes), a compliance system can detect delegation cheaply and check the target against an allow-list of known-good implementations, then flag or freeze anything pointing at an unrecognized or blacklisted contract.

This is also where 7702 quietly reshapes the deposit-address model exchanges have leaned on for years. Sweep automation, gas management on omnibus wallets, and the assumption that a deposit address is inert all get more complicated when any address might be delegated. Bitget Wallet’s chief marketing officer, Jamie Elkaleh, has argued that features like paying gas in stablecoins across chains bring self-custody closer to the convenience of a centralized exchange (The Block). That same convenience is the programmability a custodian now has to reason about at the perimeter, because the wallet and the exchange are converging on the same account model from opposite directions.

For a withdrawal, the same logic runs in reverse. If a user asks to send funds to a delegated address, the receiving contract could reject, redirect, or wrap the transfer, so an exchange that once treated any address as a passive destination now has to consider that the other side might run code on arrival. None of this is a reason to fear delegated accounts, but it is a reason the deposit and withdrawal plumbing built for plain EOAs is quietly being rewritten behind the scenes.

The regulator’s line: self-custody and who counts as a broker

None of this changes the basic US posture on self-custody, which became more explicit in 2026. On 13 April 2026, the SEC’s Division of Trading and Markets issued a staff statement clarifying that software interfaces letting users transact through their own self-custodial wallets do not, on their own, make the provider a broker (CoinDesk). A wallet that upgrades your EOA with a 7702 delegation sits squarely inside that covered-user-interface idea, provided it does not solicit trades, route orders, or take custody of assets.

Two qualifiers matter. The relief is interim staff guidance, not a rule, and it is set to be treated as withdrawn five years out unless the Commission replaces it with formal rulemaking. It is also narrow: the moment an interface starts recommending, routing, or holding assets, the carveout falls away. For now, running a smart-account wallet on your own key sits on the self-custody side of the line, the same side as holding your own coins, an area regulators keep redrawing across products, from the spot ETFs reshaping access to stablecoins.

What Glamsterdam changes, and what it does not

The next major date on Ethereum’s calendar is the Glamsterdam upgrade, and its first real test is close. Client teams are targeting a Sepolia testnet fork on 6 October 2026 at 13:53 UTC, with mainnet penciled in for around December 2026 but not confirmed (CryptoPotato). The headline feature is enshrined proposer-builder separation (ePBS, specified as EIP-7732), which pulls today’s off-protocol block-building relays into the protocol itself; developers have flagged a builder-auction withholding risk as one thing to watch on testnet. The date is conditional, because the fork had not yet run cleanly on a stable private devnet as of late September, so it can still slip.

For 7702 users, the important point is what Glamsterdam is not. It is a throughput and block-production upgrade, not an account-abstraction one, and it does nothing to solve delegation persistence or cross-chain portability. Native account abstraction, the endgame that would make smart-account behavior a first-class protocol feature rather than a bolted-on designator, is being fought out separately: Ethereum’s EIP-8141 Frame Transaction line, aimed at a later fork, against Base’s keystore-based EIP-8130. Until one of those ships, EIP-7702 remains the bridge, and the same roadmap that keeps home validators busy leaves the bridge’s housekeeping to the user.

Two proposals frame the endgame. Ethereum’s Frame Transaction line would make account abstraction a native transaction type, so the smart behavior would no longer need a designator bolted onto an EOA at all. Base’s keystore approach would store account configuration in one place and read it across chains, which attacks the per-chain fragmentation that makes 7702 cleanup so tedious. Whichever prevails, the transition will take years, and in the meantime the pointer model is what hundreds of millions of accounts actually run. Understanding it is not a temporary skill.

The bottom line: manage a delegation like an approval

EIP-7702 succeeded on its own terms. It gave hundreds of millions of existing addresses smart-account powers without asking anyone to migrate, and in September 2026 it crossed from opt-in to on-by-default on major stacks. The cost of that success is a maintenance burden the ecosystem has not fully absorbed: a delegation is durable state, it can be malicious, stale, or silently upgraded, and clearing it is a deliberate act most users have never performed.

The habit to build is the one power users learned for token approvals, applied to a bigger object. Periodically check what your address points to. Revoke delegations you no longer use. Recognize the contract before you sign, because a delegation is not a click, it is a standing grant of control. With ETH trading near $2,690 in late September 2026 (CoinDesk) and delegation now the default on major wallet stacks, the protocol has handed ordinary keys extraordinary abilities. Managing them, for the moment, is on you.

Frequently Asked Questions

How do I check if my Ethereum address has an EIP-7702 delegation?

Open your address on a block explorer such as Etherscan and read the code field. An empty field means you are a plain EOA; a value starting with ef0100 means you are delegated, and the 20 bytes after that marker are the contract your account points to. Revoke.cash also lists delegations under a dedicated tab, though you cannot revoke them from there.

How do I revoke an EIP-7702 delegation?

Sign a new authorization that points your account at the zero address (0x0000…0000), which clears the delegation and restores plain-EOA behavior. In practice you do this inside your wallet, in MetaMask through Account Details and the smart-account section, for each chain where you set one, then confirm the code field is empty again.

Does an EIP-7702 delegation expire on its own?

No. A delegation is stored on-chain as part of your account and persists until you overwrite it with a new authorization or reset it to the zero address. It does not lapse when you close your wallet, change devices, or stop using the dapp that prompted it.

Is EIP-7702 safe to use?

The mechanism itself is not a protocol vulnerability, but it raises the stakes of a signature, because a single malicious authorization can hand over lasting control of your account. Use wallets that support clear signing, verify the contract you are delegating to, and revoke delegations you no longer need.

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

ERC-4337 creates a separate smart-contract account with its own address and requires moving your funds to it, using a parallel system of bundlers and an EntryPoint contract. EIP-7702 upgrades your existing EOA in place, keeping the same address and private key while letting it run a delegate contract’s code, and the delegation is revocable and set per chain.

By Yuki Tanaka, HOGE Wire senior editor covering wallets, custody, and account abstraction.