EIP-7702 and MEV in 2026: Smart Accounts as Target and Shield

Every Ethereum upgrade ships with a headline feature and a set of side effects nobody prints on the poster. EIP-7702, live since the Pectra hard fork on May 7, 2025, delivered the headline everyone wanted: an ordinary wallet address can now run smart-contract code, batch several actions into a single click, and let someone else pay the gas. The side effect is quieter, and it matters most to the people who trade, run a desk, or hold other users’ coins. The moment your wallet can execute a list of calls in one transaction, the machines that reorder transactions for profit start to see you differently. This is the story of how set-code accounts became both a fresh target for maximal extractable value, the profit squeezed out of transaction ordering, and, in the right hands, a partial shield against it.

What EIP-7702 changed, on one screen

The mechanic is small and the consequences are large. A set-code transaction (transaction type 0x04) carries an authorization list: a signed tuple of a chain id, a contract address, and a nonce. Once you sign it, the network writes a short pointer into your account, the bytes 0xef0100 followed by the 20-byte address of the contract your account now borrows its logic from, 23 bytes in total. From that moment your externally owned account, the plain key-pair address most people mean when they say wallet, behaves like a smart contract. It can batch calls, enforce spending rules, run session keys, and accept gas sponsorship. Your address does not change. Your private key does not change. You can repoint the delegation at a new contract, or clear it by delegating to the zero address, whenever you like.

Ethereum shipped this in the Pectra upgrade as a bridge toward full account abstraction rather than a replacement for it; ERC-4337, the older account-abstraction standard, still runs alongside it. For a broader tour of what accounts can do once they hold logic, from social recovery to inheritance, see our guide to smart-account wallets, recovery and inheritance. The point for this article is narrower: the instant your account can run a list of calls atomically, it enters the same arena as the bots that profit from transaction ordering.

Adoption has been brisk, if noisy. The tracker BundleBear counts well over 50 million live delegations and more than 100 million set-code transactions, though its cumulative authorization total runs into the hundreds of millions largely because automated sweeper contracts reuse the same delegation over and over. With ETH changing hands near $2,580 in late September 2026, per CoinDesk, the gas cost of installing a delegation is trivial, and the feature has become a routine part of how wallets onboard users.

MEV in ninety seconds

Maximal extractable value is the profit a party can capture by choosing which transactions go into a block and in what order. Ethereum’s public mempool is a waiting room: when you broadcast a swap, it sits there in the open before it is mined, and anyone can read it. Specialized bots called searchers scan that room for opportunities, then bid for favorable placement. Block builders assemble the most profitable ordering they can find and hand it to a proposer, the validator that signs the block.

The classic play against a retail swap is the sandwich. A searcher sees your large buy, buys the same token just ahead of you to push the price up, lets your trade execute at the worse price, then sells right behind you for a profit that comes straight out of your slippage. Front-running (jumping ahead of a pending transaction) and back-running (landing immediately after it) are the same idea applied to arbitrage, newly listed tokens, and liquidations. On-chain credit is a rich hunting ground, because a single price move can make dozens of loans liquidatable at once; our explainer on how on-chain credit markets work shows why liquidations attract so much searcher attention. None of this requires EIP-7702. What 7702 does is change the shape of the target and hand users a few new tools to fight back.

The invariant that quietly broke

Before Pectra, Ethereum guaranteed something developers quietly leaned on. A normal wallet could make only one call per transaction, so if the address running the code was the same address that signed the transaction (tx.origin equals msg.sender, in Solidity terms), you could be sure a human-controlled account was acting directly, with no contract in the middle. Some protocols used that exact check to block sandwich bots and certain flash-loan tricks, on the logic that a genuine end user, not an intermediary contract, was the caller.

EIP-7702 breaks that assumption on purpose. The specification’s security considerations spell it out: once an account has been delegated, it can invoke multiple calls per transaction, so the tx.origin equals msg.sender test no longer proves what it used to. The authors are blunt that an anti-sandwich guard built on that check “would be broken by this EIP,” while adding that relying on tx.origin this way was “considered bad practice” in the first place. They also searched for reentrancy guards written the same way and found none in production, though such a guard would break too. The takeaway is not panic; it is that a category of naive on-chain MEV defenses stopped being reliable the day 7702 went live, and any protocol that depended on them had to move to real protections.

This is the sort of consequence Ethereum core developer Marius van der Wijden had in mind when he cautioned, via DL News, that “it’s still a very early proposal, so we need to evaluate all the rough edges.” The broken tx.origin invariant is exactly that kind of rough edge: a deliberate, documented trade-off rather than a bug, but one that quietly rewired assumptions across DeFi.

Three account models, side by side

It helps to line up the three ways an Ethereum account can behave in 2026, because each one sits differently in the MEV supply chain.

The last row is the one that matters here. A plain EOA is transparent to ordering bots but limited to a single action; an ERC-4337 account routes through a separate alt-mempool of UserOperations and bundlers, so the bundler, not your wallet, is the transaction origin; a 7702 account keeps your familiar address while gaining the power to bundle calls. Alex Jupiter, a senior product manager at MetaMask, framed that convergence to DL News as the moment Ethereum finally gets “one unified Account Abstraction roadmap,” folding the key-pair world and the smart-contract world together. That union is also what drops a formerly simple wallet into the middle of the ordering game.

Your account as a target

Start with the uncomfortable side. A 7702 delegation is installed by a single signature, and that signature does not move any funds, so it can look harmless in a wallet pop-up while handing a contract the right to act for your account. Attackers noticed at once. In the weeks after Pectra, the trading firm Wintermute found that more than 97% of early delegations pointed at copies of the same recycled sweeper bytecode, a template nicknamed CrimeEnjoyor, deployed to drain any account whose key was already compromised, as CoinDesk reported. Wintermute’s own conclusion was that the campaign was barely profitable, because it went after wallets that were already empty or already stolen, and that 7702 itself was not the flaw.

That nuance connects to MEV in a specific way. Once a drainer holds your signature, it can batch the theft: approve, transfer, and sweep several tokens in one atomic transaction that either fully succeeds or fully reverts, leaving no half-drained mess and no window for you to react. The most expensive single case reported in 2025 saw one victim lose $1.54 million in a single 7702-enabled phishing transaction, per Cryptopolitan. The lesson echoes a theme we keep returning to in coverage of why bridge hacks keep repeating: the failure is almost never the cryptography, it is a person approving something they could not fully read. Delegation raises the stakes of a bad signature, because one approval now buys an attacker programmable, batched control instead of a single transfer.

Your account as a shield

Now the other edge. The same atomic batching that helps a drainer also helps an honest user. Before 7702, a token swap on a decentralized exchange usually meant two separate transactions: first an approval, then the trade. Between them sat a window a searcher could exploit. Bundle them into one 7702 transaction and that gap closes; the approval and the swap live or die together, in the same slot, with no exposed in-between state. It is the same one-block, all-or-nothing property that makes flash loans possible, turned to a defensive purpose.

Atomicity also kills a class of griefing. If any leg of your batch would fail, the whole transaction reverts and you pay only for the failed attempt, not for a stranded approval a bot can pounce on later. And because a delegated account can enforce its own rules, it can carry logic that refuses to execute a swap outside a tight price band, rejecting the exact slippage a sandwich depends on.

The shield has clear limits, and honesty about them matters. Bundling your approval and swap does not hide the swap. The moment your transaction reaches the public mempool, a searcher can still read your intended trade and try to sandwich it, because the price impact is visible whether or not an approval is attached. Atomic batching removes the approval-gap attack and the failed-transaction tax; it does not make you invisible. For that, you have to keep the transaction out of the public waiting room altogether, which is where the next set of tools comes in.

When ordering still beats you

It is worth being precise about which MEV problems 7702 touches and which it leaves alone.

Read down the right-hand column and the pattern is clear. EIP-7702 genuinely helps against the mechanical, self-inflicted forms of value leakage, the approval gaps and the reverted transactions, and it genuinely hurts in the hands of a phisher. Against the headline threat, the public-mempool sandwich, it is close to neutral, because the exposure comes from broadcasting your intent in the open, not from how many calls your account can make in a block.

The one-pending-transaction rule

There is a subtler ordering issue that lives below the trading layer, in how transactions propagate. A delegated account can invalidate other pending transactions from the same address, because its code can change what a later transaction will do. Left unchecked, that would let someone flood the network with transactions that get cheaply cancelled, a denial-of-service angle aimed at the mempool itself.

The EIP-7702 authors answered it with a deliberately conservative rule in the specification’s security considerations: clients should not accept more than one pending transaction for any EOA that carries a non-zero delegation, which, in their words, “minimizes the number of transactions that can be invalidated by a single transaction.” For everyday users this is invisible. For anyone building high-throughput flows on a delegated account, a market maker, an exchange hot wallet, an automated strategy, it is a real constraint: you cannot keep a deep queue of pending transactions on a single delegated address the way you might on a plain EOA. It pushes heavy senders toward multiple addresses, or toward the alt-mempool design of ERC-4337, and it is the kind of detail that separates a working desk integration from a stuck one.

The defenses that actually work today

If atomic batching is a partial shield, the real armor against sandwiching is keeping your transaction out of the public mempool until it is mined. That is what a private RPC endpoint does. Instead of broadcasting to the open waiting room, your wallet sends the transaction down a private channel to block builders directly.

The best-known option is Flashbots Protect, a permissionless RPC that has run since 2022 and plugs into ordinary wallets like MetaMask with a single network setting. Transactions routed through it stay hidden from front-running and sandwich bots, are included only if they do not revert (so you never pay for a failed swap), and can even earn an MEV refund, with builders returning most of any back-run value to the user rather than pocketing it.

MetaMask went further and built protection into the wallet by default. Its Smart Transactions feature, launched in May 2024, routes swaps through a private virtual mempool where the same builders and searchers who power the public mempool compete to fill your order, but face financial penalties if they fail to execute at the quoted price. MetaMask reported that in July 2024, when roughly $11 million in value was siphoned from user transactions on mainnet, the equivalent figure across its own users was about $5, and that Smart Transactions pushed swap success rates to 99.995%.

These tools matter more, not less, in a 7702 world. A delegated account can batch beautifully, but if it broadcasts that batch into the open, a sandwich bot still reads the swap inside it. Combining atomic batching with a private route is the version that actually protects a retail trader in 2026.

What the data says about sandwiches

Step back from the mechanics and the trend is encouraging, if strange. Data from the analytics firm EigenPhi, shared with Cointelegraph Research, shows sandwich attacks on Ethereum shrinking even as trading grows. Value extracted from sandwiches fell from nearly $10 million a month in late 2024 to roughly $2.5 million by October 2025, while decentralized-exchange volume climbed from about $65 billion in the first quarter to more than $100 billion in the third. The raw count of attacks stayed high, between 60,000 and 90,000 a month, but the average profit per attack collapsed to just above $3.

The distribution is its own lesson. Across the period EigenPhi studied, roughly 70% of all sandwich attacks traced back to a single entity, and only six attackers cleared more than $10,000 in total profit for the whole of 2025. Most of the extracted value does not even reach the searchers: block builders capture the bulk of it through gas fees, leaving attackers with margins around 5%. The sandwich business, in other words, is being competed and defended into the ground, precisely because private RPCs and features like Smart Transactions have made the easy targets harder to reach. EIP-7702 is one more nudge in that direction for the users who pair it with a private route.

Where exchanges and custodians sit

For the wallets-and-exchanges audience this cluster serves, the operational question is what to do when an address, a customer’s or one of your own, carries a delegation. Every exchange that credits deposits by watching an address now has to reckon with the fact that a watched address can run code. A deposit address delegated to a sweeper contract can have incoming funds pulled the instant they land, before the exchange finishes crediting them, and a withdrawal target that runs code can behave in ways a naive integration does not expect.

The screening handle is the 23-byte designator itself. Any address whose code begins with 0xef0100 is a delegated EOA, and the 20 bytes that follow name the contract it trusts. Desks increasingly read that field the way they already read a contract’s bytecode, keeping allow-lists of known-good delegates such as a wallet vendor’s audited implementation and flagging unknown ones for review. Institutional custodians face the same choice from the other side: whether to permit a delegation on a customer account at all, and if so, to which contracts. This is the unglamorous plumbing that decides whether smart accounts settle cleanly on a trading desk, and it explains why the exchange tier has moved more cautiously than retail wallets.

Glamsterdam, the protocol-level answer

Everything above is a user-level or desk-level patch. The deeper fix for MEV is being built into the protocol itself, and in 2026 its name is Glamsterdam. Ethereum’s previous upgrade, Fusaka, went live on December 3, 2025 and focused on cheaper data for layer-2s; Glamsterdam turns to block production and ordering.

Its headline change is enshrined proposer-builder separation, or ePBS, specified as EIP-7732. Today the handoff between the validator that proposes a block and the specialized builder that assembles its profitable ordering runs through off-protocol middleware, chiefly MEV-Boost and a handful of trusted relays. ePBS moves that handoff into the protocol, removing the trusted relay and, as the Ethereum Foundation’s roadmap page puts it, stretching the block-propagation window from about two seconds to roughly nine. The second pillar, block-level access lists (EIP-7928), publishes an upfront map of which accounts and storage each block will touch, so nodes can validate transactions in parallel instead of one after another. A related consensus change, FOCIL (EIP-7805), lets a committee of validators force transactions into blocks, so a censoring builder cannot quietly drop the transactions it dislikes.

None of this abolishes MEV; value from ordering will always exist. What it does is shrink the trust you must place in relays and builders and make censorship harder, which is the part of MEV that most threatens ordinary users. The timeline is close enough to matter: Glamsterdam is running on developer testnets now, with a Sepolia fork scheduled for October 6, 2026 and mainnet activation targeted for the fourth quarter, though the exact date is not locked. We tracked the testnet milestones in the L2 fee countdown; for MEV, the same upgrade is quietly rewriting who gets to reorder your transactions.

The US picture: the SEC, self-custody, and MEV

For readers in the United States, the regulatory questions around 7702 and MEV are less settled than the engineering. Start with custody. A delegated EOA is still self-custody: you hold the key, you install and revoke the delegation, and no third party takes possession of your assets. That distinction has support from the regulator. In April 2026, staff at the Securities and Exchange Commission (SEC) took the view that software letting users transact from self-hosted wallets is not, on its own, acting as a broker, as CoinDesk reported. A wallet that helps you sign a 7702 transaction sits on the same side of that line as any other self-custody tool.

MEV itself occupies grayer ground. Front-running a customer order is a familiar offense in traditional markets, but on a permissionless network the searcher has no fiduciary relationship with the trader whose transaction it reorders, and the SEC has not brought a signature MEV case that would settle how existing law applies. Builders, relays, and order-flow arrangements could eventually draw scrutiny as market-structure questions, especially once ePBS formalizes those roles inside the protocol. For now the practical guidance for a US user is unchanged: MEV is a cost you manage with private routing and sensible slippage, not a protection any agency currently guarantees.

A ten-minute defense checklist

None of this needs a computer-science degree to act on. If you use a wallet that supports EIP-7702, a short routine keeps you on the safe side of the ledger.

1. Check what your account delegates to. Read your address on a block explorer or a checker like eip7702.app; if the code begins with 0xef0100, note the 20-byte contract that follows and confirm it is your wallet vendor’s audited implementation, not something you do not recognize.
2. Turn on a private route. Add Flashbots Protect as a custom RPC, or use a wallet with built-in protection such as MetaMask Smart Transactions, so your swaps skip the public mempool.
3. Batch approval and swap together when your wallet offers it, closing the approval-gap window instead of leaving a standing allowance a bot can use later.
4. Set slippage deliberately. A tight slippage tolerance is still the cheapest anti-sandwich defense, and atomic batching does not replace it.
5. Read the signing screen. A 7702 authorization installs code rather than moving funds, so it can look harmless; if a pop-up asks you to delegate and you did not start the action, reject it.
6. Reset when in doubt. To strip a suspect delegation, point your account back at the zero address, then move funds to a fresh key if the old one may have leaked.

That last point carries a caveat worth stating plainly: clearing a delegation removes the borrowed code, but if your private key itself has leaked, resetting the delegation does not make the key safe again. When the key is the problem, the only real fix is a new wallet.

Frequently Asked Questions

Does EIP-7702 protect me from MEV and sandwich attacks?

Only partly. Bundling your approval and swap into one atomic 7702 transaction removes the approval-gap attack and the tax of paying for a failed transaction, but it does not hide your trade from the public mempool, so a sandwich bot can still read and bracket a visible swap. Real protection comes from pairing 7702 with a private route such as Flashbots Protect or MetaMask Smart Transactions, plus a tight slippage setting.

Why did EIP-7702 break the tx.origin == msg.sender check?

Because a delegated account can make several calls in one transaction, so the check no longer proves that a plain human wallet is acting directly. The EIP-7702 specification says naive anti-sandwich guards built on that check are broken by the upgrade, and notes that relying on tx.origin that way was already poor practice.

Can a sandwich bot still attack my EIP-7702 transaction?

Yes, if you broadcast it to the public mempool. Batching your approval and swap into one 7702 transaction closes some gaps, but the swap’s price impact is still visible once the transaction is public. Keeping it private until it is mined, through a private RPC, is what actually stops the sandwich.

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

Look up your address on a block explorer or a checker like eip7702.app. If the account code starts with 0xef0100, the 20 bytes that follow name the contract your account trusts. To remove the delegation, sign a set-code transaction pointing at the zero address, which strips the borrowed code. If the key itself may be compromised, move your funds to a new wallet as well.

Will Glamsterdam fix MEV?

It will not abolish MEV, but it targets the worst parts. Glamsterdam’s enshrined proposer-builder separation (EIP-7732) removes trusted relays, block-level access lists (EIP-7928) enable parallel execution, and FOCIL (EIP-7805) makes censorship harder. The upgrade is on developer testnets now, with a Sepolia fork set for October 6, 2026 and mainnet targeted for the fourth quarter.

Marcus Okafor covers wallets, exchanges, and Ethereum market structure for HOGE Wire.