EIP-7702 in 2026: Session Keys, Games, and AI Agents

The signature that hands over the keys

For most of Ethereum’s history, an ordinary wallet could do exactly one thing. It could sign a transaction that you approved, one at a time, while you watched. That is what an externally owned account, or EOA, was built to do, and it is why using crypto has always felt like clicking approve, again, and again, and again. In 2026 that same account can do something new. It can hand a slice of its own authority to a game so the game stops interrupting you every few seconds, or to an AI agent so the agent can trade, pay, and rebalance a position while you are asleep.

The mechanism behind that shift is EIP-7702, the feature that shipped in Ethereum’s Pectra upgrade on 7 May 2025. It is a small change to how a wallet behaves, and it is quietly one of the most consequential upgrades Ethereum has made for everyday users. It also cuts both ways. The same one-time signature that lets a game bot act for you is the exact signature a wallet drainer wants you to sign. This article is about the accounts that act on their own: how EIP-7702 makes them possible, where they already run today, and what it costs you in risk when your account can move without you in the room.

What EIP-7702 actually is

EIP-7702 introduced a new transaction type that lets an existing EOA point at a smart contract and, when the account is called, behave like that contract. Your address stays the same. Your private key stays the same. Your on-chain history stays the same. What changes is that the account gains code, so it can finally do the things smart-contract wallets have done for years: bundle several actions into one atomic transaction, let a third party cover the gas, and enforce rules about what a secondary key is allowed to touch. 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.”

To see why that matters, it helps to know the road not taken. For years the plan for programmable accounts ran through ERC-4337, which builds a whole parallel system on top of Ethereum (user operations, bundlers, and a shared EntryPoint contract) without changing the base protocol. It works, and it is live, but it asks people to move their funds to a brand new smart-contract account with a new address. EIP-7702, proposed in May 2024 by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett as a lighter successor to the earlier EIP-3074, took a different route. Upgrade the address you already have, in place, and keep it compatible with the 4337 world. Alex Jupiter, a senior product manager at MetaMask, called the result a way of aligning the two older paths into “one unified Account Abstraction roadmap.” That in-place upgrade is the reason adoption moved quickly; there was no new account to talk anyone into opening. By early September 2026, on-chain trackers such as BundleBear counted more than 55 million addresses with a live delegation and over 100 million set-code transactions, with ETH itself trading near $2,500 as the month opened. The cumulative authorization count (north of 240 million) looks larger still, but it is inflated by automated sweepers, more on which below.

How the delegation works under the hood

The plumbing is worth a minute, because every risk in this story lives inside it. A 7702 delegation travels in a transaction of type 0x04, the set-code transaction. Inside it sits an authorization list, where each entry is a signed tuple containing a chain id, the contract address to delegate to, a nonce, and a signature. You create that signature by signing over a short message prefixed with a magic byte, 0x05, which keeps a delegation signature from 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 chose, 23 bytes in total. From then on, any call to your address runs that contract’s logic, using your balance and your storage. The EIP-7702 specification lays this out in full.

It is worth stressing that EIP-7702 does not compete with ERC-4337 so much as plug into it. The 4337 ecosystem added native support for 7702 accounts, so the same bundlers, paymasters, and audited account implementations that already existed can serve an upgraded EOA. In practice that means a wallet can point your address at a well-reviewed account contract and immediately inherit years of tooling, rather than shipping bespoke code. The flip side is that the contract you delegate to inherits full control of your account while the delegation is live, so which implementation your wallet chose is a security decision you are trusting it to have made well.

Two details deserve a flag. First, you can undo a delegation by signing a new authorization that points at the zero address, which wipes the code marker and returns your account to a plain EOA. Second, if you sign an authorization with the chain id set to zero, it becomes valid on every EVM chain at once. That is handy if you want the same setup everywhere, but it is also a cross-chain replay risk if you did not mean to grant it. The table below is a field guide to what you are actually authorizing.

Session keys: the primitive that lets an account act on its own

Once an account can carry code, it can hand out a session key. A session key is a secondary signing key with strict limits written into the contract that the account delegates to, and the limits are the whole point. A session key can be scoped to a single contract address, capped at a spending amount, and set to expire after a fixed window. You sign once to grant it, and after that the holder of the session key can act inside those bounds without prompting you again. Just as importantly, you keep the master key and you can revoke the grant whenever you want.

Under the hood, this is a delegation, and a second standard, ERC-7710, describes how one account can pass a capability to another. The account that grants the power is the delegator; the session key or agent that receives it is the delegate; and the rules attached to the grant (which contract, how much, until when) are enforced as conditions the delegate has to satisfy when it redeems the delegation on-chain. The important consequence is that the funds never leave your account. The delegate is a signer with a permission slip, not a custodian holding your money, which is why revoking or expiring the permission ends its power cleanly.

Standards are forming around this so that any app can ask for a session in a predictable way. ERC-7715 defines a method, wallet_grantPermissions, that lets a website request a scoped, time-bounded permission from your wallet, and EIP-7702 supplies the on-chain machinery that makes your EOA enforce it. MetaMask ships this as its Delegation Framework and Advanced Permissions, where a dapp can ask once to, say, spend up to a set amount against one contract until a chosen date, rather than making you sign every step. The mental model is a spending allowance with a timer and a leash, not a blank check. The difference between the three ways an account can act is worth making explicit.

Games that stop asking you to sign

The most immediate payoff is in gaming, where the old one-signature-per-action model was simply unplayable. Every sword swing, every crafted item, every in-game trade was a wallet pop-up that broke the flow. Session keys fix that. As one developer walkthrough describes it, a game can request a session key valid for two hours that can call only its own game contract and spend at most a tiny amount of ETH; the player signs once, and for the next two hours the game submits moves signed by the session key with no further prompts. When the window closes, the authority evaporates on its own.

This is the frictionless experience that gaming-focused wallets have chased for years, and it is why the pattern shows up across ecosystems built for players, from Ronin to Immutable to the newer Aptos and Sui gaming stacks. EIP-7702’s contribution is to bring that same session model to an ordinary Ethereum EOA, without asking the player to migrate to a special account first. The trade is exactly the one every convenience makes. A session key that can act for two hours is also two hours during which something other than you is signing, so the scope you grant and the expiry you set are not fine print; they are the safety rails.

The stakes here are not only comfort. Web3 games have spent years losing players at the wallet step, where a signature pop-up in the middle of a fight is enough to make someone quit. Session keys turn the wallet into something closer to a console login: approve once at the start of a play session, then play. Guilds and in-game marketplaces get the same benefit, because a scholar or a trading bot can be handed a tightly scoped key that can move a single asset class but never touch the treasury behind it.

AI agents that trade while you sleep

The same primitive is what makes an autonomous on-chain agent thinkable. Give an AI agent a session key and it can execute a strategy inside limits you set: rebalance a portfolio, dollar-cost-average into an asset, chase a yield, or place orders on a perpetuals venue, all without waking you for a signature each time. A KuCoin explainer lays out the shape of it plainly: you grant an agent a session key that might allow trading only for the next 24 hours, forbid moving more than a set amount of ETH, and permit only certain functions, for example a swap on an approved DEX while barring transfers to outside addresses. You keep the private key and can revoke at any time.

Builders are already packaging this. MetaMask’s Delegation Toolkit lets a developer request exactly these scoped permissions, so an agent can, for instance, be told to spend up to 10 USDC a day for 30 days against a single strategy contract from one signature, rather than pinging you for approval every morning. Subscriptions, recurring buys, automated treasury management, and in-game economies all fit the same template. The account becomes a set of standing instructions with a budget attached, and the human moves from approving each action to setting the policy that governs all of them.

That same explainer is refreshingly blunt about the failure modes, and they are worth internalizing before you delegate a dollar to a bot. A bug or hidden backdoor in the delegation contract can expose funds for as long as the delegation is live. A convincing phishing site can dress up a hostile agent as a helpful trading assistant. And the agent’s own judgment is a risk in itself: a model that misreads a stablecoin depeg as a buying opportunity can burn through its budget in minutes. The guardrails are not optional extras. They are the difference between a useful agent and an expensive one, and they are enforced by the contract, not by the app’s good intentions.

x402 and the machine economy

If agents are going to act, they also need to pay, and a payment rail built for machines has taken shape around x402, a protocol Coinbase introduced that revives an old, mostly unused HTTP status code, 402 Payment Required, and turns it into a way for software to settle stablecoin micropayments inside ordinary web requests. An agent that hits a paywalled API can pay for the call in USDC and continue, no card, no human, no checkout screen. Pair that with a 7702 session key and you have an account that can both decide and pay on its own.

The adoption numbers are loud, and they need a skeptic’s ear. Chainalysis counted well over 100 million cumulative x402 transactions through the first quarter of 2026, and more recent Coinbase figures put the running total north of 200 million with cumulative value around $53 million, most of it in USDC and most of it on Base. But CoinDesk reported that real daily volume was closer to $28,000, with roughly half of the activity looking like testing or gamed transactions rather than genuine commerce. In other words, the rails are being laid faster than the demand is arriving, a familiar pattern for anyone who has watched the market for decentralized AI compute try to answer the same question: who actually buys this yet? The plumbing is real. The economy on top of it is still early.

The harder problem behind agent payments is not moving the money; it is trust. If an agent can pay, it can also be tricked into paying, so the same permissioning that scopes a session key is what keeps an agent’s spending bounded. Efforts to give agents verifiable identities and to link x402 to broader agent-payment frameworks, including Google’s Agent Payments Protocol, are trying to answer who an agent is acting for and what it is allowed to buy. Until those answers are solid, the safest agent is a narrow one: a small budget, a short leash, and a contract that refuses by default.

The same power, turned against you

Here is the uncomfortable symmetry at the center of EIP-7702. The feature that lets a game or an agent act for you, a single signature that installs code and grants authority, is technically identical to the feature a thief uses to empty your wallet. There is no separate malicious version of 7702. There is only delegation, pointed either at a contract you trust or at a contract you should never have touched.

Security firm Wintermute documented the darker use within weeks of Pectra. It found that more than 97% of early delegations pointed at reused, copy-pasted sweeper bytecode that the industry nicknamed CrimeEnjoyor: identical code deployed to drain any account whose key was already compromised. Roughly 2.88 ETH of authorizations covered some 79,000 addresses, and one contract alone handled more than 52,000 of them. Wintermute’s own read was almost anticlimactic. The sweepers were mostly unprofitable, because they were chasing already-empty or already-stolen wallets, and the pattern reflected old private-key leaks rather than any flaw in 7702 itself. The mechanism was new. The victims were people whose keys were gone before Pectra ever shipped. This is the same drainer-as-a-service economy that powers the broader wave of lure-free, supply-chain phishing now hitting crypto users.

What makes the mechanism dangerous at scale is that it is productized. Drainer kits are sold as a service, with the operators taking a cut of whatever their affiliates steal, so the technical skill needed to run a 7702 phishing campaign is close to zero. The attacker does not need to break Ethereum or find a bug; they need one victim to sign one authorization. That is why the defense is behavioral as much as technical, and why every credible wallet team now spends more effort on the signing screen than on the cryptography behind it.

Anatomy of a drain

The frightening cases are not the sweepers cleaning up dead wallets; they are the live victims. The pattern is always the same. A phishing interface presents a single signature that looks routine, but the message is actually a 7702 authorization plus a batch of token approvals and transfers, all set to execute atomically. You sign once. The batch fires as one transaction. By the time you notice, the account is empty.

On 24 May 2025, Scam Sniffer flagged a MetaMask user who lost about $146,551 to exactly this, in an Inferno Drainer batch. Three months later, on 24 August 2025, the same technique produced a single-victim loss of $1.54 million in wstETH, cbBTC, and NFTs, the funds moved out and then bridged across chains before recovery was possible; readers moving assets between chains should read our field guide to bridging safely. Scam Sniffer counted two large 7702 phishing cases in 2025 that together took $2.54 million. The one piece of good news in the data is that overall wallet-drainer losses actually fell 83% in 2025, to roughly $83.85 million, even as the 7702-flavored attacks appeared. The risk vectors, and the defenses that actually work, look like this.

What the data says about the risk

Two studies in 2026 put numbers to the fear, and both point the same direction: the danger is real, but it is a human-and-wallet problem, not a broken protocol. A large empirical study accepted to the 35th USENIX Security Symposium analyzed more than 3.6 million EIP-7702 authorizations across seven chains and found that over 63% were tied to malicious contracts, with 924 distinct malicious contracts confirmed by hand, around $2.36 million in realized losses, and roughly $10 million more in exposure from legacy contracts. Read that carefully, though. The 63% counts transactions, not people or dollars, and attacker contracts get reused far more often than honest ones, which inflates their share of the count. A separate arXiv paper catalogued more than 150,000 authorization and execution events across roughly 26,000 addresses and mapped three exploitation paths, warning that a single signed tuple can hand an attacker persistent control of an account.

The people closest to wallet security keep returning to the same point. Taylor Monahan, a security researcher at MetaMask, has argued consistently that this is not really a 7702 issue at all; it is the oldest issue in crypto, that end users struggle to keep their private keys safe, and 7702 mostly makes sweeping a compromised address cheaper and less tedious, a position she set out in MetaMask’s June 2025 security report. That is why the real defense is not fear of the feature but discipline at the signing screen. If you want the deeper version of that argument, we covered it in can you read what you sign?

How to read, grant, and revoke a delegation

You do not need to be a developer to stay in control of your own account. Four habits cover most of the ground.

1. Check your address on a block explorer such as Etherscan. A delegated account shows a code field beginning with 0xef0100 followed by the contract it points to; a plain EOA shows no code at all.
2. Use a dedicated checker like eip7702.app to see the target of an active delegation in plain language. Note that revoke.cash can display a 7702 delegation but, as it explains in its own guide, it cannot remove one; that has to happen in the wallet.
3. Grant sessions narrowly. When an app asks for a permission, give it the smallest scope, the lowest spending cap, and the shortest expiry that still lets it work, then revoke it when you are done.
4. Reset when in doubt. Signing a new authorization to the zero address clears the delegation and returns the account to a normal EOA; most wallets expose this in their settings.

The revocation point is the one people get wrong. If your key is actually compromised, resetting the delegation is false comfort, because the attacker can simply re-delegate. In that case the only safe move is to abandon the address and move whatever is left to a fresh wallet created on a clean device.

Exchanges and custody at the edge

EIP-7702 quietly became an exchange and custody problem, too. When a delegated account sends a deposit, the receiving venue has to reason about code it did not put there. A compromised deposit address can be configured so that a sweeper snatches funds the instant they land, before the exchange credits them, which is why serious desks now screen incoming addresses for the 0xef0100 designator and treat a delegated depositor as a flag to investigate rather than a routine credit.

The distinction custodians draw matters for anyone comparing options. A multi-signature setup spreads approval across several keys, while multi-party computation splits a single signature into shares so that no one machine ever holds a whole key. Both remove the single point of failure that a 7702 drainer preys on, but they do it differently, and the right choice depends on who is signing, how often, and from where. What EIP-7702 adds on top is convenience without a migration: a desk can give a client batching and sponsored gas on the address they already use, provided the delegation target is a contract the desk has vetted.

On the institutional side, custodians have leaned on multi-party computation to remove the single signing key that a malicious delegation preys on, while still using 7702 to give clients batching and gasless flows. Gas sponsorship is part of the same story. Circle’s paymaster lets users pay network fees in USDC on 7702 accounts, so a newcomer never has to buy ETH just to move a stablecoin. The consumer version of that convenience is what wallet teams are selling. Jamie Elkaleh, chief marketing officer at Bitget Wallet, argued that turning on features like stablecoin gas “brings self-custody closer to the ease of centralized exchanges.” That is the promise and the pressure in a single sentence: the closer self-custody feels to an exchange account, the more the signing discipline has to carry the weight the custodian used to carry for you.

Where the SEC lands, and what comes next

For US readers, the regulatory line is clarifying. A 7702 smart account you control yourself is still self-custody, and SEC staff have signaled that software that merely lets you transact from your own wallet is not acting as a broker. The flip side of self-custody is that it comes with no undo button. There are no chargebacks on Ethereum, so a session key that misbehaves, or a delegation you should never have signed, is your loss to absorb. Tax treatment does not soften because your account got smarter, either; a disposal is a disposal whether it is signed by you or by an agent you authorized.

What comes next is the question of whether 7702 is a bridge or a destination. The long-term plan is native account abstraction, where account programmability is built into the protocol itself rather than bolted onto an EOA. Competing proposals are in flight, including EIP-8130 from the Coinbase and Base camp and the EIP-8141 omnibus favored by Ethereum’s core researchers, and the network has kept shipping the groundwork, with the Fusaka upgrade going live in December 2025. But as of September 2026 native account abstraction is still in testing, its timelines have slipped more than once, and none of it has landed on mainnet. Until it does, EIP-7702 is not a placeholder; it is the account-abstraction layer that hundreds of millions of transactions already run through, and the one your game and your agent are using right now.

The honest summary is the one van der Wijden reached for early on. It remains worth the effort to “evaluate all the rough edges.” An account that can act without you is a real upgrade to how crypto feels, and it is a real expansion of what a single careless signature can cost. Both things are true at once, and the users who do best in 2026 are the ones who treat every delegation as exactly what it is: a small, revocable grant of their own power, given deliberately, and taken back the moment it is no longer needed.

Frequently Asked Questions

What is EIP-7702 in simple terms?

EIP-7702 is an Ethereum feature that shipped in the Pectra upgrade on 7 May 2025. It lets an ordinary wallet address (an EOA) point at a smart contract and behave like one, so it can batch transactions, let someone else pay the gas, and hand limited signing power to a session key. Your address and private key do not change.

Can an AI agent control my crypto with EIP-7702?

Yes, within limits you set. Using session keys defined by standards like ERC-7715, you can grant an agent permission to call only certain contracts, spend up to a fixed amount, and act only until an expiry you choose. You keep the master key and can revoke the permission at any time. The catch is that if you delegate to a malicious or buggy contract, the agent’s authority becomes the attacker’s authority.

Is EIP-7702 safe to use?

The protocol itself is not broken. Most losses trace back to the same problem crypto has always had: a leaked or phished private key. Because 7702 lets an attacker install code and drain a wallet in a single signature, blind-signing a malicious authorization is the main danger. Delegate only to audited contracts, read what you sign, and treat any surprise signature request as hostile.

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

Look up your address on a block explorer such as Etherscan; a delegated account shows a code field starting with 0xef0100 followed by the contract it points to. Tools like eip7702.app and revoke.cash can display an active delegation, though revoke.cash can show but not remove it. To clear a delegation, sign a new authorization pointing at the zero address, which resets the account, usually from your wallet’s settings.

Does EIP-7702 replace ERC-4337 or native account abstraction?

No. EIP-7702 complements ERC-4337 and is widely seen as a bridge toward native account abstraction. Proposals like EIP-8130 and EIP-8141 aim to build account programmability into the protocol itself, but those are still in testing as of September 2026, so 7702 is the account-abstraction layer most users actually touch today.

By Marcus Okafor, senior wallets and infrastructure correspondent at HOGE Wire.