EIP 7702 Rescue vs Flashbots Bundles: Saving Tokens

Q: What is sweep7702?

sweep7702 refers to the EIP-7702 batch-sweeping pattern (used by both whitehat rescue tools and blackhat drainers) where an EOA delegates to a lightweight multicall contract so a third-party sponsor address can trigger and pay gas for sweeping all ERC-20s and NFTs in a single transaction.

By Merunas Grincalaitis, founder of MEV DAO and a developer who builds MEV, sniping and trading bots on Ethereum. Last updated: October 2026.

TL;DR: An EIP 7702 rescue (sweep7702) upgrades a classic multi-transaction Flashbots rescue bundle into a single atomic Type-4 transaction (0x04) where a clean sponsor wallet pays 100% of the gas and builder bribe directly—without ever sending a single wei of ETH into the compromised wallet. While classic Flashbots bundles still work when submitted to private builders, an EIP 7702 rescue eliminates gas-dust leakage, packs complex multi-token + NFT + airdrop sweeps into one call, and overwrites any malicious eip 7702 sweeper delegation the attacker installed.

Since Ethereum activated EIP-7702 in the Pectra hard fork, the cat-and-mouse war between wallet drainers and whitehat rescue engineers has changed completely. Attackers now use eip 7702 sweeper delegations to turn normal externally owned accounts (EOAs) into automated smart-contract traps—while whitehat engineers use EIP 7702 rescue (sweep7702) authorizations to rescue tokens from compromised wallets without ever funding the hacked address with gas ETH.

Here is the technical breakdown of what is eip 7702, how an EIP 7702 rescue compares to a classic Flashbots bundle (eth_sendBundle), and which method you should use to save tokens from a compromised wallet.

What is EIP-7702 (and what is its current EIP-7702 status on Ethereum)?

To understand both the attack and the defense, let's clarify what is EIP 7702 and the current eip-7702 status:

Live on Ethereum Mainnet & EVM chains: EIP-7702 went live on Ethereum mainnet with the Pectra upgrade (and is also active on BNB Chain, Base, Optimism, and Arbitrum).
How it works: EIP-7702 introduces transaction type 0x04, which includes an authorization_list. When an EOA signs a 7702 authorization tuple (chain_id, contract_address, nonce), the EVM sets the EOA's code field to a delegation designator (0xef0100 || contract_address).
What that means in plain English: Your normal wallet address (0xabc...) can temporarily or permanently execute smart-contract logic—such as batching 15 token transfers in one transaction, or having a different wallet sponsor your gas—while keeping its original EOA address and balances.

If an attacker tricked you into signing a malicious 7702 authorization, your address now points to their drainer contract. We show how to inspect and clear that in How to Check and Remove a Malicious EIP-7702 Delegation and provide a CLI tool in our eip-7702-delegation-checker-revoker GitHub repository.

Classic Flashbots Rescue Bundle vs. EIP 7702 Rescue (`sweep7702`)

Before EIP-7702, the only way to rescue ERC-20 tokens from an ETH-empty hacked wallet was a multi-transaction Flashbots bundle:

Tx 1 (Sponsor EOA): Send 0.002 ETH to the Compromised EOA.
Tx 2 (Compromised EOA): Call tokenA.transfer(safeWallet, balanceA).
Tx 3 (Compromised EOA): Call tokenB.transfer(safeWallet, balanceB).

While this works when included atomically by a block builder, it has three painful limitations that an EIP 7702 rescue solves completely:

Rescue Dimension	Classic Flashbots Bundle (`eth_sendBundle`)	EIP 7702 Rescue (`sweep7702` Type-4 Tx)
Does ETH ever enter the hacked wallet?	Yes (Tx 1 must send ETH into the hacked wallet for gas)	No! The clean sponsor wallet pays 100% of the gas directly.
What if the hacked wallet has a malicious `receive()` fallback?	Tx 1 reverts or auto-forwards the ETH to the hacker!	Bypasses `receive()` completely because no ETH is sent to the hacked wallet; the 7702 auth overwrites the hacker's code first.
Gas overhead for 5 tokens + 2 NFTs	8 separate signed transactions (~21,000 base gas × 8)	1 single transaction executing a Multicall loop (~45% less total gas).
Risk of bundle unbundling / partial inclusion	If sent to a buggy relay without strict bundle enforcement, Tx 1 could land alone	Mathematically atomic: the authorization and the token sweep live inside one single transaction hash.
Clears attacker's `eip 7702 sweeper` delegation?	Requires an extra Type-4 tx inside the bundle	Yes, automatically—signing a new 7702 authorization to the whitehat rescue contract overwrites the attacker's delegation in place.

Why a classic Flashbots bundle FAILS when an `eip 7702 sweeper` is installed

This is the most critical detail in 2026 wallet rescues. Suppose an attacker has your private key and they have already set an EIP-7702 delegation on your address pointing to their SweeperForwarder contract.

That malicious contract defines a receive() external payable function:

receive() external payable {
    // Whenever ANY ETH arrives in this wallet, forward it to the hacker immediately!
    payable(hackerAddress).transfer(msg.value);
}

If you try to run an old-school 2024 Flashbots rescue script where Tx 1 sends 0.003 ETH to your compromised wallet to pay for gas, Tx 1 triggers the attacker's receive() hook, which immediately forwards your 0.003 ETH to hackerAddress inside Tx 1! When Tx 2 tries to run token.transfer(), your compromised wallet still has 0 ETH for gas, causing the entire bundle to fail.

How an EIP 7702 rescue (`sweep7702`) defeats the sweeper in one transaction

An EIP 7702 rescue turns the tables on the attacker by using Type-4 transaction mechanics (0x04) combined with a private Flashbots bundle:

Offline authorization signing: Using the compromised private key offline, we sign an EIP-7702 authorization tuple delegating the compromised address to a verified Whitehat Batch Rescue Contract (and optionally a second tuple delegating back to 0x0000000000000000000000000000000000000000 after execution, or checking msg.sender == trustedSponsor).
Sponsor-paid Type-4 transaction: Our clean sponsor wallet is the from sender (and gas payer!) of the Type-4 transaction. It attaches the compromised wallet's signed authorization_list and calls compromisedAddress.executeBatchRescue(tokens[], nfts[], safeDestination).
In-place code replacement + sweep: Before a single opcode of contract execution runs, the Ethereum protocol processes the authorization_list, wiping out the attacker's malicious 7702 sweeper delegation and replacing it with our Whitehat Rescue implementation.
Atomic Multicall sweep: Inside that same call frame, compromisedAddress executes transfer() on every ERC-20 token, safeTransferFrom() on every ERC-721/1155 NFT, claims any pending airdrops, and tips block.coinbase—all paid for by the sponsor wallet's gas without a single wei of ETH ever sitting in the compromised address!

We still submit this Type-4 rescue transaction privately via eth_sendBundle to Flashbots, Titan, and Beaverbuild so the attacker's mempool monitor cannot see our transaction and attempt to front-run the nonce.

Which rescue method should you use right now?

Use an EIP 7702 rescue (submitted via Flashbots) whenever the compromised address has an active 7702 delegation, whenever you are rescuing 2+ tokens/NFTs at once, or whenever you want zero gas-calculation friction.
Combine EIP-7702 + multi-block Flashbots bundles when rescuing two-step staking cooldowns or contested airdrop claims at a specific unlock block, as covered in Unstake From a Compromised Wallet: Rescue Locked Tokens and How to Claim an Airdrop From a Compromised Wallet (Before the Sweeper Does).

Both workflows are supported in our MEV DAO Sweeper Bot Rescue Service and our open-source compromised-wallet-sweeper-rescue GitHub repo.

Frequently asked questions

What is the difference between an EIP-7702 rescue and a Flashbots bundle?

A classic Flashbots bundle requires a clean wallet to send gas ETH into the compromised wallet in Transaction 1 so the compromised wallet can pay gas for token transfers in Transaction 2. An EIP-7702 rescue attaches a signed delegation tuple to a single Type-4 transaction paid for directly by the clean sponsor wallet, sweeping all tokens atomically without ever sending ETH into the hacked wallet.

Why should I still send an EIP-7702 rescue through Flashbots?

If you broadcast an EIP-7702 rescue transaction to the public mempool, an attacker who also holds your compromised private key can spot the pending transaction, see the nonce in your 7702 authorization tuple, and front-run you with a higher-gas transaction that increments the compromised wallet's nonce or changes the delegation first. Submitting the 7702 transaction privately via eth_sendBundle prevents mempool front-running.

Can an EIP-7702 rescue overwrite a hacker's existing EIP-7702 sweeper?

Yes. In EIP-7702, signing a new valid authorization tuple with the current account nonce immediately overwrites whatever delegation code was previously attached to the EOA—even if the attacker's contract had a malicious receive() hook that blocked normal ETH transfers.

What is sweep7702?

sweep7702 refers to the EIP-7702 batch-sweeping pattern (used by both whitehat rescue tools and blackhat drainers) where an EOA delegates to a lightweight multicall contract so a third-party sponsor address can trigger and pay gas for sweeping all ERC-20s and NFTs in a single transaction.

How can I check if my compromised wallet has an EIP-7702 sweeper attached?

Look up your address on Etherscan (which displays a "Delegated to..." badge on 7702 accounts) or run eth_getCode(yourAddress) against an Ethereum RPC. If it returns 0xef0100 followed by a 20-byte contract address instead of 0x, your EOA has an active EIP-7702 delegation.

Related guides

Need to run an atomic EIP-7702 + Flashbots rescue on a compromised Ethereum wallet right now? Access the MEV DAO Token Rescue Bot with a 3-day free trial at mevdao.org/subscribe, or message me directly on Telegram (@merunas) for urgent whitehat assistance.