EIP-7702 in 2026: How Wallet Delegation Really Works

Sixteen months after it went live, EIP-7702 has quietly become one of the most widely used features Ethereum has ever shipped, and most of the people relying on it never chose it by name. The proposal activated with the Pectra upgrade on 7 May 2025, and it lets an ordinary Ethereum address, the kind that begins life controlled by a single private key, borrow the code of a smart contract and start behaving like a programmable account. There is no new address to fund, no token to migrate, and no fresh seed phrase to back up. The wallet you already have simply learns new tricks.

The scale is easy to miss because the mechanism is invisible by design. BundleBear, the dashboard that tracks account-abstraction activity, counts close to 60 million addresses carrying a live delegation and more than 106 million set-code transactions since launch (BundleBear). Ether trades near $2,711, up more than 11% over the month as markets digested the Federal Reserve’s move to 4% (Fortune), the kind of relief rally HOGE Wire tracked after the Fed hike. And Ethereum’s next hard fork, Glamsterdam, is penciled in for the Sepolia testnet on 6 October, roughly two weeks out, carrying changes that will rework the plumbing 7702 wallets ride on (CryptoPotato).

For something this widely deployed, EIP-7702 is still badly misunderstood. It is not the account-abstraction endgame, and it is not a routine wallet update. It is a bridge, deliberately minimal, that turned hundreds of millions of existing accounts into candidates for smart-contract logic in a single fork. This guide covers what a delegation actually is, how wallets and exchanges absorbed it, where money has been lost, how to check and revoke your own delegation, and what happens to it as Ethereum’s next upgrades land.

What EIP-7702 actually is

Ethereum has always had two kinds of accounts. Externally owned accounts, or EOAs, are controlled by a private key; they can hold funds and start transactions but cannot run code of their own. Contract accounts run code but cannot start a transaction on their own, because something has to call them first. For a decade that split defined what a wallet could do. If you wanted spending limits, batched actions, or social recovery, you needed a smart-contract wallet, which meant a different address and a migration off the account you already used.

EIP-7702, titled “Set Code for EOAs,” erases the hard line between the two. It introduces a transaction that lets an EOA point at a smart contract and adopt that contract’s code as its own, while keeping its address, its balance, and its private key. The account is still yours in every way that matters; it just gains the ability to execute contract logic when it transacts. The official Pectra documentation frames it as giving existing accounts new “superpowers” without asking anyone to move (ethereum.org).

The practical effect is that the wallet in your browser can now bundle several actions into one transaction, let a third party cover its gas, enforce spending rules, or hand a game a temporary key, all without you ever leaving the address your funds already sit on. That is the whole pitch: account abstraction for the accounts that already exist, rather than a fresh set of accounts nobody has funded yet.

The road to 7702: EIP-3074, ERC-4337, and a last-minute swap

The idea did not arrive fully formed. Ethereum developers spent years trying to give EOAs contract-like powers. The first serious attempt, EIP-3074, added two opcodes (AUTH and AUTHCALL) that let a trusted “invoker” contract act on an EOA’s behalf. It was close to ready, but core developers worried it created a permanent, powerful primitive that might not line up with the longer-term account-abstraction plan, and it was pulled.

Running on a parallel track was ERC-4337, finalized in March 2023, which delivered smart accounts entirely at the application layer: a separate mempool of “UserOperations,” bundlers that package them, and a singleton EntryPoint contract, all with no change to Ethereum’s consensus rules. It worked, and it still powers a large share of smart-wallet activity, but it required users to create and fund a brand-new contract account. The old EOA, and everything already sitting in it, stayed behind.

EIP-7702, proposed by Vitalik Buterin with Sam Wilson, Ansgar Dietrichs, and Matt Garnett in 2024, was the compromise that replaced 3074 late in Pectra’s planning. Instead of new opcodes, it reused the smart-account infrastructure that 4337 had already built and simply let existing EOAs plug into it. Marius van der Wijden, an Ethereum core developer, described it as a change that “adds a new transaction type that allows existing wallets to emulate the functions of Account Abstraction wallets,” while cautioning that the ecosystem still had to “evaluate all the rough edges” (DL News). Alex Jupiter, a senior product manager at MetaMask, put the strategic case more plainly: 7702 gave Ethereum “one unified Account Abstraction roadmap” instead of two competing ones (DL News).

How a delegation works, step by step

Under the hood, EIP-7702 defines a new transaction type, 0x04, sometimes called a set-code transaction. What makes it different from an ordinary transfer is a field called the authorization list, which carries one or more signed tuples. Each tuple contains a chain ID, the address of the contract to delegate to, and a nonce. The account holder signs that tuple over a special prefix byte (the MAGIC value 0x05), producing an authorization that can then be included in a transaction by the owner or by someone acting on their behalf.

When the network processes that transaction, it writes a short marker into the EOA’s code field: the bytes 0xef0100 followed by the 20-byte contract address. That 23-byte string is the delegation designator, and OpenZeppelin’s documentation walks through the exact layout for developers (OpenZeppelin Docs). From that point on, any call to the account runs the delegate contract’s code, but reads and writes storage on the EOA itself. The private key still works as before; the owner can still sign plain transactions, and the delegation does not hand the key to anyone.

A few details matter for safety. Only one delegation can be active at a time, so authorizing a new contract replaces the old one rather than stacking on top of it. The nonce stops a given authorization from being replayed on the same chain. The chain ID field is the sharp edge: set it to a specific chain and the authorization works only there, but set it to 0 and the same signed authorization is valid on every chain at once, which is convenient for multi-chain wallets and dangerous if it is signed carelessly. To undo a delegation, the owner signs a new authorization pointing at the zero address, which clears the code field and returns the account to a plain EOA. The full mechanism is spelled out in the proposal itself (EIP-7702 specification).

None of this is visible to a typical user. In practice the wallet handles the tuple, the signature, and the designator behind a single prompt that says something like “upgrade this account,” and the first smart-account action often rides along in the same transaction. That smoothness is the point, and also the hazard: the same one-tap flow that makes upgrading painless is what a phishing site imitates to make a hostile delegation look routine.

EOA, ERC-4337, and EIP-7702 side by side

The three models overlap in what they can do but differ sharply in how you get there and what you give up. The table below sets out the practical distinctions that matter when a wallet or an exchange decides which path to support.

What a delegated wallet can suddenly do

The reason wallet teams moved fast is that a single, cheap upgrade unlocks a list of features users have wanted for years. The headline one is batching: an EOA can approve a token and swap it in the same atomic transaction, so the old two-step dance (sign an approval, wait, then sign the trade) collapses into one signature that either fully succeeds or fully reverts. That also closes the notorious approval gap, where a granted allowance sits open and exploitable between steps.

Gas abstraction is the second big unlock. A delegated account can let a third party pay its transaction fees, or pay them itself in a stablecoin instead of ether, so a newcomer can make their first on-chain move without owning any ETH at all. On top of that, delegates can enforce spending limits, add multi-factor or social recovery, schedule automated payments, and grant scoped, temporary keys for specific apps. None of this is new to smart accounts; what is new is that the account you already funded can do it without moving a cent to a new address.

Jamie Elkaleh, chief marketing officer at Bitget Wallet, framed the appeal in consumer terms when the wallet added 7702 support, saying it “brings self-custody closer to the ease of centralized exchanges” and lets people “transact across chains without ever managing gas tokens” (The Block). That is the quiet ambition behind the feature: make a self-custodial wallet feel as frictionless as an exchange account, without giving up the keys.

Who actually pays for gasless: paymasters and sponsorship

“Gasless” is marketing shorthand; someone always pays the validator. In the account-abstraction stack, that someone is usually a paymaster, a contract that agrees to cover fees under rules the sponsor sets. An app might absorb gas costs to onboard new users, a game might sponsor in-game actions, or a wallet might let the user pay in USDC and settle the underlying ETH cost behind the scenes.

The economics are not free money. Circle’s paymaster, for instance, lets users pay gas in USDC on networks such as Arbitrum and Base and charges roughly a 10% surcharge on the gas cost for the service (Circle). Sponsors also have to meter their generosity, because an open-ended offer to pay gas is an invitation for griefing, where someone burns the sponsor’s budget with junk transactions. The plumbing that lets 7702 accounts interoperate with this system got a boost when the eth-infinitism team shipped EntryPoint v0.8 with native EIP-7702 support and a reference Simple7702Account, so a delegated EOA can act as a first-class 4337 account (eth-infinitism releases).

For exchanges and consumer apps, sponsorship is the real prize: it removes the single hardest step in onboarding, which is explaining to a newcomer why they need a second token just to move their first one. That is also why so much early adoption clustered around wallets that already had a paymaster relationship in place, rather than spreading evenly across the ecosystem.

Session keys, games, and AI agents

The feature that gets crypto-gaming and agent developers excited is the session key. A delegated account can grant a temporary, tightly scoped key that is allowed to do only certain things, for a limited time or up to a spending cap, then expires. In a game, that means a player can sign once at the start of a session and then swing a sword, mint an item, or trade a resource dozens of times without a wallet pop-up on every action, while the master key stays cold.

The same pattern is what makes autonomous on-chain agents plausible rather than reckless. An AI agent that trades or pays for services needs authority to act, but handing it a full private key is a recipe for disaster. A 7702 session key lets an owner delegate a narrow budget and a short list of allowed actions, so an agent can operate inside a fence rather than with the run of the whole account. That is exactly the kind of guardrail the agent frameworks now being built for on-chain automation are designed around, including projects like the one HOGE Wire profiled in its look at the Eliza agent framework and its gaming bet. Emerging payment standards for machine-to-machine commerce lean on the same building block: scoped, revocable authority instead of an all-or-nothing key.

The catch is that a session key is still a key, and a scope that is too broad is just a slower way to lose funds. The safety of the pattern lives entirely in how narrowly the delegate contract defines what the temporary key may do, which puts the burden back on wallet and app developers to set sane limits by default.

How the wallets shipped it

Adoption did not spread evenly; it clustered in the wallets that had already invested in smart-account features. MetaMask, with tens of millions of monthly users, made 7702 the primary path for turning an existing account into a MetaMask smart account, upgrading in place rather than asking users to create anything new. Ambire was among the first to support the standard at launch. Trust Wallet added the ability to sign and display 7702 authorizations, with an emphasis on showing users what they are approving. Bitget Wallet built cross-chain gas abstraction on top of it, letting users pay fees in tokens like USDT and USDC across several networks (The Block). On the exchange-wallet side, OKX’s wallet and Coinbase’s Base Account (an ERC-4337 and passkey design) rounded out the field, while Safe’s smart-account stack connected to the standard through the updated EntryPoint.

Two caveats keep the adoption story honest. First, the eye-catching cumulative total (more than 250 million authorizations) is heavily padded by automated sweeper bots that re-sign constantly, so the roughly 60 million live delegations is the more meaningful number (BundleBear). Second, some of the earliest and heaviest use came from exchange-linked wallets rather than retail browser extensions, a sign that the feature’s first killer app was operational plumbing, not consumer dazzle.

What it means for exchanges and custodians

For centralized exchanges, EIP-7702 is less a feature than an operational puzzle to manage, and the puzzle sits at the deposit address. Historically an exchange could assume that an EOA sending it funds was a dumb account with no code; now a depositing EOA might carry a delegation, which means calls to it can run arbitrary logic, auto-forward incoming funds, or behave in ways a naive deposit-crediting system never anticipated. Re-entrancy and unexpected transfers are suddenly possible from an address that looks, at first glance, like a normal user wallet.

The industry’s answer is to screen for the designator. Because every delegation writes the same 23-byte marker (0xef0100 plus an address) into the account’s code, an exchange can check whether a depositing or withdrawing address carries that prefix and route it through stricter handling. That screening also intersects with compliance: an account that can auto-forward or batch on the exchange’s behalf changes the risk picture for know-your-customer and anti-money-laundering controls, the kind of controls whose failures HOGE Wire documented in its account of OKX’s $504 million settlement.

For institutional custodians, the more interesting development is the pairing of 7702 with multi-party computation. A delegated account can offer programmable features such as batching and policy limits while the key that authorizes the delegation is itself split across a threshold of signers, so no single machine ever holds the whole secret. That combination lets a custodian offer smart-account convenience without loosening the key-management discipline its clients are paying for.

The dark side: sweepers, phishing, and blind signing

The same power that lets a friendly contract batch your swaps lets a hostile one drain your wallet, and the defensive and offensive uses are technically identical. In the first weeks after Pectra, analysts at Wintermute found that the overwhelming majority of early delegations pointed at near-identical “CrimeEnjoyor” sweeper contracts, automated tools that instantly move funds out of an already-compromised account. Wintermute’s read was that these were not a flaw in 7702 itself; they only affected keys that were already leaked, and for everyone else the feature was safe to use (CoinDesk).

The scarier vector is phishing that abuses the signing screen. Because a delegation is authorized by a signature over data most users cannot read, an attacker can dress up a request as something harmless and trick a victim into delegating their account to a malicious contract, which then sweeps everything. A peer-reviewed study presented at USENIX Security 2026 by Mingyuan Huang and co-authors analyzed millions of 7702 authorizations and found that more than 63% of them, counted by transaction, were tied to malicious contracts, though the researchers stressed that attacker contracts are reused far more often than legitimate ones, so the figure overstates the share of affected users (USENIX Security 2026). A separate paper documenting the phishing pattern in detail concluded the technique was “already being exploited at scale” (arXiv), and that research drew fresh scrutiny to wallet-signing UX (NewsBTC). One victim reportedly lost about $1.54 million after signing a single malicious batch (Cryptopolitan).

Taylor Monahan, a security researcher at MetaMask, argued the root cause predates the standard: “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 practical defense is clear signing, wallets that decode an authorization into human-readable terms (this contract, these permissions) rather than an opaque hash, an effort being standardized under ERC-7730. The ability to revoke a delegation instantly, covered next, is the industry’s off-switch for a mistaken signature, a close cousin of the pause-and-recover reflex HOGE Wire examined in its piece on crypto’s off-switch reckoning.

It is worth keeping the losses in proportion. Even as 7702 handed attackers a fresh batch-signing trick, total wallet-drainer losses actually fell in 2025, dropping about 83% to roughly $83.85 million from close to half a billion dollars the year before, as wallets and detection tools caught up (Cointelegraph). The pattern to watch is not the headline total but the mix: signature-based scams, the category a hostile delegation falls into, are taking a larger share of a shrinking pie.

How to read and revoke your delegation

Checking and, if needed, clearing a delegation is something any self-custodial user can do without special tooling. The steps below work whether you are auditing your own wallet or responding to a request you should never have signed.

1. Look up your address on a block explorer such as Etherscan, or a dedicated viewer, and check the code field. A plain EOA shows no code; a delegated account shows the 0xef0100 prefix followed by the contract it points to.
2. Identify the delegate contract. If it is your wallet’s official smart-account implementation, that is expected; if you do not recognize it, treat it as hostile.
3. Remember that delegation is per chain. A delegation set on Ethereum mainnet does not exist on Arbitrum or Base unless you authorized it there too, so check each chain where you hold funds.
4. To remove a delegation, use your wallet’s revoke or downgrade option, which signs a new authorization to the zero address and clears the code. If the wallet has no such button, a fresh authorization to the zero address achieves the same result.
5. If you suspect your key is compromised, revoking a malicious delegation is not enough; the attacker still has the key, so move your funds to a new wallet first, then worry about the delegation.

Where the SEC stands on self-custody

Because a 7702 delegation lives entirely inside a user’s own account, it sits on the self-custody side of the regulatory line, which in the United States keeps most of it outside the activities the Securities and Exchange Commission polices directly. SEC staff signaled in April 2026 that software enabling self-hosted wallet transactions is not, by itself, acting as a broker (CoinDesk), a stance that matters for wallet developers shipping delegation features. The regulatory weight still falls on the intermediaries: the exchanges, custodians, and paymaster services that touch customer funds.

Tax treatment is the more mundane concern for ordinary users. Delegating an account is not a taxable event on its own, but the actions a smart account makes easier, such as swaps, bridging, and automated trades, each carry their own reporting consequences. The upgrade changes how you transact, not whether the tax authorities are interested in what you did.

What comes after 7702: Glamsterdam and native accounts

EIP-7702 was always framed as a bridge, and the traffic on the far side is now in view. Ethereum’s next hard fork, Glamsterdam, is scheduled to activate on the Sepolia testnet on 6 October 2026 at 13:53 UTC, with client teams asked to ship compatible software by late September and a further test on the Hoodi network expected around 27 October; a mainnet date remains an unconfirmed Q4 target (CryptoPotato). Its headline change, enshrined proposer-builder separation (ePBS, defined in EIP-7732), pulls block-building coordination into the protocol and reduces the reliance on off-protocol MEV relays that sit between validators and builders today (Crypto Briefing). Developers have flagged risks in the new builder-auction design, including scenarios where a bad actor wins a block auction and then withholds transaction data, so the schedule is explicitly tentative.

Glamsterdam does not touch 7702 directly, but it reshapes the base layer that delegated wallets and their batched, sponsored transactions run on. The longer-term question is what replaces the bridge. Vitalik Buterin has proposed EIP-8141, an “omnibus” that aims to fold account abstraction natively into the protocol, targeted at a later fork he calls Hegota. On the layer-2 side, Base’s Cobalt upgrade and its EIP-8130 design point at native accounts too, though that work remains on a devnet with no mainnet date.

Until one of those lands, 7702 is the account-abstraction path that actually exists at scale, a point HOGE Wire made in its earlier look at the upgrade that skipped the migration. Bridges built as temporary fixes have a habit of staying in service, and this one already carries close to 60 million accounts across it (BundleBear).

The bottom line

EIP-7702’s achievement is that it made account abstraction boring. There was no migration weekend, no address swap, no mass re-education; a fork shipped, wallets flipped a switch, and tens of millions of ordinary accounts became programmable. The cost of that smoothness is a new attack surface that lives on the signing screen, and a delegation model that demands users understand, at least dimly, that a single signature can hand their account over to code. The winners will be the wallets that make the powerful version easy and the dangerous version obvious. For now, the feature does exactly what it was designed to do: it upgrades the account you already have, and it asks you to keep guarding the same key you always did.

Frequently Asked Questions

Is EIP-7702 safe to use?

The standard itself is considered safe, and it is used by tens of millions of accounts. The risk is not in the code but in what you sign: a malicious authorization can delegate your account to a wallet-draining contract. Use a wallet that clearly shows what a delegation does, only delegate to your wallet’s official implementation, and never approve a signing request you do not understand.

Does EIP-7702 change my wallet address or private key?

No, and that is the point of the design. Your address stays the same, your existing private key still controls the account, and your balance does not move. The delegation only adds a pointer to smart-contract code that runs when the account transacts, and you can remove it at any time.

How do I know if my wallet has an EIP-7702 delegation?

Look up your address on a block explorer such as Etherscan and check the code field. A plain account has no code, while a delegated account shows a marker beginning with 0xef0100 followed by the contract address it delegates to. Delegations are per chain, so check each network where you hold funds.

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

ERC-4337 delivers smart accounts at the application layer and requires creating a new contract account. EIP-7702 upgrades an existing EOA in place, keeping its address and key, by adding a new transaction type at the protocol level. In practice they now work together: an upgraded EOA can plug into the same 4337 infrastructure.

Can EIP-7702 delegations be used across multiple chains?

A delegation is normally specific to one chain, so authorizing a contract on Ethereum does not delegate your account on Arbitrum or Base. An authorization signed with a chain ID of 0 is valid on every chain at once, which is convenient for multi-chain wallets but riskier if it is signed without care.

By Yuki Tanaka, senior wallets and exchanges correspondent at HOGE Wire.