EIP-7702 in 2026: Whose Code Runs Your Wallet Now?

Here is the fact that reframes everything else about EIP-7702. The single contract that more Ethereum accounts point to than any other was not written by MetaMask, Uniswap, or Ambire. It is a copy-pasted wallet drainer that the trading firm Wintermute nicknamed CrimeEnjoyor, and by its research team’s count it accounted for over 97% of early EIP-7702 delegations. That number is not a scandal about a broken protocol. It is the cleanest illustration of what EIP-7702 actually does, and it is the part almost every explainer skips.

When you turn on a smart account in 2026, you do not receive new abilities the way a phone gets a firmware update. You publish a small pointer that tells the network to run one specific, already-deployed contract whenever your address transacts. The features people advertise (batching, gas paid in a stablecoin, session keys, spending limits) live inside that contract, not inside your account. So the real question is not whether to use a smart account. It is whose contract you point at. Roughly 61 million live delegations have now answered that question, very often without the account owner realizing a question was asked.

EIP-7702 shipped inside the Pectra upgrade on 7 May 2025 and has been live for about sixteen months, a stretch in which Ether has changed hands near $2,700. In that time it has become the default road into account abstraction for mainstream wallets. With the Glamsterdam upgrade lined up for a Sepolia test fork on 6 October 2026, and native smart-account transaction types still a proposal rather than a shipped feature, the contract behind your delegation is the trust decision that matters right now. This is a guide to who is on the other end of that pointer, how to read it, and how to change it.

What Turning On a Smart Account Actually Does

EIP-7702 adds a new transaction type, type 4 (0x04), that carries an authorization signed by your account. When that authorization lands, the network writes a tiny marker into your account’s code slot: the three bytes 0xef0100 followed by a 20-byte contract address. Everything else about your account stays the same. Same address, same private key, same balance, same nonce. The only thing that changed is that your once-empty code field now holds a 23-byte signpost, formally called a delegation designator, per the EIP-7702 specification.

From then on, whenever your address is called, the EVM reads that signpost, loads the code at the address it names, and runs that code as if it lived at your account. Your account does not contain logic. It borrows logic, on demand, from somewhere else. Send a fresh authorization that names a different contract and the borrow changes. Send one that names the zero address and the borrow ends, leaving a plain externally owned account again. The Pectra guidelines describe this as letting an ordinary account temporarily act like a contract, but the word temporary hides a lot: the pointer persists until you overwrite it, so in practice the delegation is a standing relationship, not a one-time trick.

The Pointer Is a Dependency, Not a Feature

Developers have a plain word for code you run but did not write: a dependency. That is exactly what a delegation designator is. When your address points at a contract, that contract’s bugs are your bugs, its permission model is your permission model, and its upgrade policy becomes your upgrade policy. If it can be paused, your account can be paused. If it exposes a function that lets a signed message move funds, your funds move on a valid signed message. None of that is visible in the marketing screen that offered you gasless swaps.

This is the difference between the two roads to account abstraction. ERC-4337, finalized in 2023, has you deploy your own contract account and route intents through a separate mempool of user operations. EIP-7702 skips the deployment: it lets an existing account borrow a shared, pre-deployed contract. That is why 7702 spread so fast and why the trust question is sharper. With 4337 you tend to know you are using a contract wallet. With 7702 the same address you have always used quietly starts executing someone else’s code, and the someone is usually a contract that thousands or millions of other accounts are borrowing at the same time. The table below sets the three models side by side.

Who Is on the Other End: The Delegate-Contract Leaderboard

A handful of contracts do the honest work behind most legitimate 7702 wallets. They are worth knowing by name, because when your wallet says it enabled smart features, one of these (or something like it) is what your account now borrows. MetaMask points accounts at its own delegator, a verified contract named EIP7702StatelessDeleGator living at 0x63c0c19a…07dae32b and audited by Cyfrin in 2025. The word stateless matters: it stores no signer data of its own and grants control to the account that shares its address, which is the EIP-7702 pattern done cleanly.

Uniswap took a different route with Calibur, a non-upgradeable singleton wallet contract at 0x00000000…11F9b8f00 that supports multiple key types (secp256k1, P-256, WebAuthn), batching, and custom hooks. Ambire, which was first to ship a 7702 wallet, uses AmbireAccount7702 at 0x5A7FC113…a63f96f6d, deliberately kept to around 200 lines of Solidity to shrink the attack surface, per Ambire’s own writeup. And for builders who want a neutral default, the ERC-4337 team folded a minimalist account called Simple7702Account into the core distribution alongside EntryPoint v0.8, an audited contract any account can safely authorize for batching and sponsored gas. Each of these is a distinct answer to the same question, and the table lays out the trade you accept with each.

Notice the last row. The single most common delegation target on Ethereum is not any of the legitimate wallets above. It is the sweeper.

CrimeEnjoyor: The Most-Pointed-At Contract Is a Drainer

Within weeks of Pectra, Wintermute’s researchers noticed that the overwhelming majority of 7702 delegations were pointing at multiple contracts that shared the exact same bytecode. It was a short, simple sweeper: the moment any ETH lands in a compromised address, the code forwards it to an attacker. Wintermute tagged the pattern CrimeEnjoyor, verified the bytecode on-chain so wallets and explorers could flag it, and reported that more than 97% of early delegations were this or an identical copy. The share has eased since then as legitimate wallets adopted 7702, but sweepers still make up the large majority of the live count, which is why the raw cumulative-authorization figure (in the hundreds of millions) badly overstates real adoption.

The important nuance, which Wintermute has repeated, is that this is not a flaw in EIP-7702, and the protocol is safe to use. CrimeEnjoyor does not steal keys; it is deployed after a key is already compromised, and it simply makes draining that address cheaper and more automatic than before. In other words, the sweeper epidemic is a story about private-key security, dressed up in a new transaction type. It also happens to be the perfect teaching case for this article: it shows, in the starkest possible way, that a delegation is nothing more than an address pointing at code, and that the code can be anything. The USENIX Security 2026 study by Mingyuan Huang and colleagues reached a similar conclusion from the other direction, finding that a majority of the millions of 7702 authorizations they analyzed across seven chains were tied to malicious contracts, while stressing the losses trace to user-level compromise rather than a bug in the standard.

Two things follow from that. First, the sweeper population keeps regenerating: as wallets and explorers learned to flag the original bytecode, Wintermute kept verifying newer copycats built on the same idea, so the malicious share drifts down slowly rather than collapsing. Second, the sweepers are why headline adoption numbers deserve a pinch of salt; a compromised address can be re-authorized again and again, inflating the cumulative count far above the number of real people using smart accounts. The encouraging counterpoint is that overall wallet-drainer losses fell hard in 2025, down about 83% to roughly $84 million as defenses improved, even as 7702-flavored batch-signature scams became a larger slice of what remained.

Shared Code, Shared Blast Radius

The convenience of 7702 comes from sharing. Instead of every user deploying a bespoke wallet contract, millions of accounts point at the same few implementations. That is efficient, and it concentrates risk in a way that is easy to miss. When a legitimate delegate has an undiscovered bug, it is not one user’s problem; it is a shared blast radius covering every account currently borrowing that code. Concentration hidden behind a friendly interface is a recurring theme in crypto infrastructure, the same blind spot our colleagues wrote about in Bitcoin mining pools and the leaderboard blind spot: the leaderboard looks diverse until you trace where the real power actually sits.

This is the monoculture argument, and it cuts both ways. A single well-audited delegate that everyone uses is easier to scrutinize, easier for explorers to label, and easier for exchanges to allowlist, so shared code also means shared defense. The counterweight is that a defect propagates instantly to everyone. The prudent reading is not that sharing is bad, but that the choice of which shared contract to join is a security decision with systemic weight, not a cosmetic wallet preference. Pointing at Calibur, at the MetaMask delegator, or at Simple7702Account puts you inside a large, watched, reviewed pool. Pointing at whatever a phishing site suggests puts you inside a very different pool, with the same mechanics.

Picture the failure concretely. Suppose a widely used delegate shipped a subtle flaw in how it validates a signature, and suppose it went unnoticed for a month. Every account pointed at that contract would be exposed at once, regardless of how carefully each individual owner guarded their key, because the vulnerable logic is shared, not personal. That is the uncomfortable inverse of the efficiency argument, and it is why serious delegates are audited by more than one firm, kept small, and made non-upgradeable where possible. It is also why an account owner gets real value from simply knowing which pool they are in, since the size and scrutiny of that pool is part of the risk they are carrying whether they think about it or not.

Can the Contract Change Under You?

The most important question to ask about any delegate is whether its code can change without you signing anything. Two answers exist, and they are very different. Some delegates are non-upgradeable singletons: the bytecode at that address is fixed forever, so what you audited today is what runs tomorrow. Uniswap’s Calibur is explicit about this; OpenZeppelin’s review described it as a non-upgradeable, EIP-7702-compliant smart contract wallet. Ambire’s minimal contract and the Simple7702Account reference share the same immutability. With these, the only way the code you run can change is if you send a new authorization.

Other designs are frameworks with modules or proxy patterns, where the account’s behavior is composed from parts that can be added or swapped. That flexibility is genuinely useful, but it means trust extends past the contract you first pointed at, out to whoever governs the parts. This is the same reason on-chain power tends to hide one layer down from where people look, a dynamic we traced in the governance you cannot flash-loan. There is also a second, blunter path for change that applies to every delegated account, immutable or not: you can always re-sign to a different contract. That is the real upgrade mechanism of 7702, and it is also the real risk. A single malicious authorization, signed once in a moment of inattention, repoints your account at a sweeper and does not expire on its own. The contract does not change under you; the pointer does.

If you want to check immutability yourself rather than take a wallet’s word for it, the signals are on-chain. A non-upgradeable singleton has no admin function that swaps its logic and no proxy pointing somewhere else; the code at the address is the code, full stop. A proxy or an upgrade-controlled contract will have an owner or an admin slot that can change what executes, which means you are trusting whoever holds that role in addition to the code you read. Neither design is disqualifying, but they are different promises, and a wallet that cannot tell you plainly which one it made is asking for more trust than it has earned.

What an Audit Does and Does Not Buy You

Every reputable delegate has been audited, and it is worth being precise about what that means. OpenZeppelin’s review of Calibur, run over several weeks in 2025, found no critical and no high-severity issues, alongside a set of medium and low findings that were resolved: a signature-replay scenario tied to incorrect call assumptions, hooks that lacked access to validation and execution results, WebAuthn authenticators that do not display structured transaction data before signing, and admin keys that could extend their own permissions. The public audit concluded the codebase was well written and interoperable, while noting that meaningful trust assumptions remain around how administrators manage keys and hooks. MetaMask’s delegator carries a comparable clean bill from Cyfrin.

An audit is a snapshot of specific code at a specific commit under specific assumptions. It is strong evidence that the contract does what it claims, and it is silent about how you will use it. The recurring 7702 losses are not audit failures; they are people signing authorizations they did not understand. That is why the WebAuthn blind-signing finding above matters more than its low severity suggests, and it is the same theme flagged in a separate 2026 arXiv study of 7702 phishing that documented takeover through a single signed tuple across tens of thousands of addresses. Read an audit as a floor under the contract, not a ceiling over your own habits. A perfectly audited delegate still drains you if you sign the wrong thing into it.

There is a subtler limit worth naming. An audit covers the code that existed at the moment it was run. Non-upgradeable delegates like Calibur make that guarantee durable, because nothing can be added later. Framework-style delegates that accept modules do not: a module written after the audit, or one you enable yourself, sits outside the reviewed set, and its powers still flow through your account. This is not a reason to avoid modular designs, which are often the most capable, but it is a reason to check whether a given capability came from the audited core or from a bolt-on that no red team has looked at. The name on the delegate is a starting point, not the full inventory of what runs when you sign.

What the Delegate Actually Exposes

Once you point at a good contract, the powers people came for are functions that contract chooses to expose. Batching lets several actions settle in one atomic transaction, so an approve-then-swap becomes a single click with no dangling allowance in between. Gas sponsorship lets a paymaster cover the fee, or lets you pay it in a token rather than ETH. Session keys let you grant a narrow, time-boxed permission (spend up to a set amount on a set app for a set window) without handing over the account. MetaMask’s delegator exposes these through the ERC-7710 delegation interface and the EIP-7821 execution interface, and modular designs following ERC-7579 let capabilities plug in as separate, individually scoped modules.

Session keys are also where the frontier is moving, because they are what let software act for you between signatures. An AI trading agent or an in-game account can operate under a key scoped to a tight budget and a short life, so a compromise is bounded by design rather than by hope. That model, and its limits, is the connective tissue between smart accounts and the machine economy we covered in opML’s speed limit and the agent economy. The caution is symmetrical with everything else here: a session key is only as safe as the delegate that honors it and the scope you actually granted, and delegated execution in contracts like Calibur means anyone holding a valid signature from an authorized key can act, which is powerful and unforgiving in equal measure.

The same machinery is what finally makes recurring, permissioned actions safe to automate. MetaMask’s delegation framework lets an account grant a scoped permission (a monthly spend cap on a specific app, say, or approval limited to one token) so a subscription or an automated strategy can run without a blanket allowance and without a fresh signature every time. That is a real improvement over the old model, where a single unlimited token approval was the standard price of using a DeFi app and the standard cause of drained wallets months later. The catch is unchanged: a granted permission is only as narrow as you made it, so the useful discipline is to grant the least a task needs and to treat any request for broad, open-ended power as the warning sign it has always been.

How to Read Which Contract You Point At

You can check any account’s delegate in under a minute, and everyone with a smart account should know how. On a block explorer, open your address and look at its code. A plain account shows none. A delegated account shows a short entry beginning 0xef0100 followed by 20 bytes: those 20 bytes are the delegate address, and clicking through tells you whether you are pointed at a labeled MetaMask, Uniswap, or Ambire contract, or at something unlabeled that deserves suspicion. Wallet interfaces expose the same fact in friendlier form; MetaMask surfaces it in account details, and inspection tools like Revoke.cash list your active delegations, though many such tools can show a delegation without being able to clear it for you.

Changing it is its own step, and this is where a delegate becomes a matter of hygiene rather than curiosity. To repoint, sign a new authorization naming a different contract. To exit smart-account behavior entirely, sign one naming the zero address, which strips the pointer and returns you to a plain account. One caveat travels with every clear: resetting the pointer removes the borrowed code but does not wipe any storage the delegate may have written, and it must be done on each chain separately. The practical routine, including why an abandoned pointer is worth clearing even when nothing looks wrong, is the subject of our companion piece on the delegation you forgot to revoke. The table condenses the moves.

Exchanges Read the Delegate, Too

The delegate designator is not just a user concern; it reshaped how centralized exchanges handle deposits. An exchange has to decide whether a deposit from an address is safe to credit, and a delegated account is no longer a passive key. It can run code on the way in or out, which means an incoming transfer can behave in ways a plain transfer never could. In response, exchanges and custodians began screening the 23-byte designator on deposit and withdrawal addresses, effectively maintaining an allowlist of known-good delegate contracts and flagging accounts pointed at anything resembling the CrimeEnjoyor family. A deposit address that suddenly starts pointing at an unrecognized contract is a signal worth pausing on.

This is one more reason the identity of your delegate matters beyond your own security: it determines how the rest of the system treats your account. It is also part of why 7702 is quietly narrowing the gap between self-custody and the exchange experience, since a delegated account can batch, sponsor gas, and enforce limits the way a hosted account does. Regulators have started to draw the lines around exactly that boundary, which the next sections take up.

For an exchange, this is a genuine change in operating assumptions. A deposit address used to be inert: value arrived and that was that. A delegated address can execute logic as part of the same transaction that moves funds, so the deposit and withdrawal machinery now has to account for code that might, for example, try to claw a credited balance back. The practical response has been conservative: screen the designator, credit known-good delegates promptly, and hold or review anything pointed at an unfamiliar or flagged contract. It is the same instinct behind allowlisting a token contract before listing it, applied to the account itself, and it means your choice of delegate quietly affects how fast your own deposits clear.

Same Address, Different Chain, Different Code

A delegation lives at an address on a specific chain, not in your key, and this trips up more people than any other detail. If you enable a smart account on Ethereum mainnet, that pointer does not exist on Arbitrum, Base, or Optimism unless you authorize it there too. Your address is the same everywhere; your delegate is not. So the account that batches and sponsors gas beautifully on one network can behave like a plain key on the next, and a wallet that hides this can leave you assuming protections you do not have where you are actually transacting.

The specification does allow a shortcut: sign with a chain ID of zero and the authorization is valid on every chain at once. That is convenient and it is a footgun, because the same 20-byte address can hold entirely different code on different chains, so a cross-chain authorization can point you at safe code in one place and unknown code in another. Portability of a plain address is not portability of its behavior, a distinction that sits right next to the harder problem of moving assets and messages between networks that we examined in the interoperability wars over cross-chain protocols. The safe habit is to treat each chain as a separate delegation to inspect, enable, and revoke on its own terms.

The Regulator’s View: Software, Not a Broker

A reasonable worry is whether the wallet steering all this delegation counts as a regulated intermediary. In the United States the answer, for now, leans toward no. In April 2026 the SEC’s Division of Trading and Markets issued a staff statement finding that software interfaces which merely help users transact through their own self-custodial wallets generally do not trigger broker-dealer registration. The statement defines a covered user interface as a website, extension, mobile app, or embedded wallet software that helps a user initiate transactions with their own keys, provided it stays a neutral tool: no solicitation, no investment advice, no custody, with fees and conflicts disclosed.

Two caveats keep this from being a clean all-clear. It is staff guidance, not a rule, so it carries no force of law on its own, and it is written to be considered withdrawn five years from its issuance unless the Commission replaces it with permanent rulemaking. It also draws its safe harbor precisely around the self-custody line: the moment an interface starts holding assets or steering choices, the analysis changes. For a delegated account that is the whole point. You still hold your key, your address is still yours, and the delegate contract runs at your instruction, which is the technical fact that keeps a 7702 wallet on the software side of the line rather than the broker side. Tax treatment, of course, follows the transactions rather than the wallet software, a distinction worth keeping straight as batching makes it easier to fire off many actions at once.

Where the Delegate Disappears: Native Accounts

The whole delegate-contract question exists because Ethereum accounts were not born smart. The proposed cure is to make them smart at the protocol level, so an account can validate its own transactions, pay fees in any token, and rotate keys without borrowing a separate contract at all. Two designs aimed at that in 2026, and in September they stopped trying to agree. Ethereum’s EIP-8141 divides a transaction into frames that validate, pay for, and execute an operation; Base’s EIP-8130, written by a Coinbase engineer, pairs a new transaction type with an on-chain keystore that names the authenticator for each transaction. After weeks of trying to reconcile them, the teams split, as Derek Chiang of Ethlabs, who founded ZeroDev, told The Defiant.

“While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals,” Chiang said, describing an Ethereum that weights censorship resistance and privacy against a Base built for scale and compliance. Until one of those proposals reaches mainnet, the delegate contract is not a stopgap you can route around; it is the mechanism. The next scheduled upgrade does not change that either. Glamsterdam, testing on Sepolia on 6 October, is about block production and throughput (its headline is enshrined proposer-builder separation, EIP-7732), not native accounts, and developers have flagged a builder-auction withholding risk to resolve before a mainnet date that is still only a tentative Q4. The honest way to see EIP-7702 in late 2026 is as a durable bridge rather than a temporary trick, which is precisely why the contract on the far side of the pointer deserves your attention.

Choose a Contract Like You Choose a Validator

Pull the threads together and a simple posture falls out. A delegation is infrastructure you join, not a setting you flip. You would not run a validator on anonymous client software, or stake through a node operator you could not name, and pointing your account at a contract is the same class of decision made faster and with less ceremony. Three questions cover most of the risk before you sign: which contract am I pointing at, can its code change without me signing again, and who has actually reviewed it. If the answers are a labeled, audited, non-upgradeable delegate from a wallet you trust, you are in the watched, defended pool. If any answer is unknown, so is your money.

The people who built this are candid that it is not finished. Ethereum core developer Marius van der Wijden, describing 7702 as a way for existing wallets to emulate account-abstraction features, cautioned that “It’s still a very early proposal, so we need to evaluate all the rough edges,” and has been wary of an account behaving as a plain key and a smart contract at the same time. The security view is blunter still. As MetaMask’s Taylor Monahan put it after a user lost seven figures to a delegation scam, “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.” The pointer is 23 bytes. What it points at is your account. Read it, know its name, and be as deliberate about repointing it as you were about generating the key in the first place.

Frequently Asked Questions

What contract does my wallet delegate to under EIP-7702?

It depends on your wallet. MetaMask points accounts at its EIP7702StatelessDeleGator, Uniswap uses its non-upgradeable Calibur contract, Ambire uses AmbireAccount7702, and many tools rely on the shared Simple7702Account. You can confirm yours by viewing your address on a block explorer, where a delegated account shows a code entry starting with 0xef0100 followed by the 20-byte delegate address.

Is EIP-7702 safe to use?

The mechanism itself is considered safe, and researchers including Wintermute have stressed that the widespread sweeper problem comes from compromised private keys, not a flaw in the standard. The real risk is signing an authorization you do not understand, which can point your account at malicious code. Use a wallet whose delegate contract is audited and labeled, and check what you sign.

What is the CrimeEnjoyor contract?

CrimeEnjoyor is the nickname Wintermute gave to a widely copied sweeper contract that automatically drains ETH from already-compromised addresses. It became the single most common EIP-7702 delegation target, accounting for more than 97% of early delegations, because attackers reuse the same simple bytecode. It does not steal keys; it is deployed only after a key is already exposed.

How do I remove or change my EIP-7702 delegation?

To change it, sign a new type-4 authorization naming a different contract, which fully replaces the old pointer. To turn off smart-account behavior, authorize the zero address, which strips the delegation and returns you to a plain account. Clearing the pointer does not erase any storage the delegate wrote, and you must do it separately on each chain.

Does an EIP-7702 delegation work across every chain?

No. A delegation is set at your address on one specific chain, so enabling it on Ethereum does not enable it on Arbitrum, Base, or other networks unless you authorize it there too. Signing with a chain ID of zero makes an authorization valid everywhere at once, but that is risky because the same address can hold different code on different chains.

By Yuki Tanaka, who covers wallets, custody, and account abstraction for HOGE Wire.