Sweeper Bot Rescue Service: Live Token Rescue Case Study

By Merunas Grincalaitis (X · GitHub · DEV · Hashnode · Telegram), Founder & Lead MEV Engineer at MEV DAO — Ethereum smart contract, Flashbots & MEV builder since 2017. Last updated: October 2026.

TL;DR: When a leaked private key has an active sweeper bot watching it, sending ETH to pay gas will fail 100% of the time because the sweeper drains incoming ETH in the very next block. In this real-world sweeper bot rescue service case study, we walk through how we saved $42,800 in vesting ERC-20 tokens and staked LP positions from a compromised Ethereum wallet using a 3-transaction atomic flashbots rescue bundle ([Sponsor Gas -> Claim & Unstake -> Sweep to Vault]) that beat an aggressive mempool sweeper in block 21,104,8xx.

Part of the Compromised Wallet & Sweeper Bot Rescue Topic Cluster: Start with our Pillar Guide, How to Rescue Tokens From a Compromised Wallet With a Sweeper Bot (Flashbots Guide), for the complete architectural blueprint. This article is a Forensic Mainnet Case Study dissecting a real 3-transaction $42,800 rescue bundle block-by-block (for DIY code templates, see our DIY Flashbots Rescue Pillar Guide; to request managed assistance, see our Sweeper Bot Rescue Service).

Theory guides on eth_sendBundle are helpful, but when your own wallet is compromised—and every 0.005 ETH deposit you send vanishes within 12 seconds—you want to see exactly how a real token rescue bot wins against an automated attacker in production.

As part of our Sweeper Bot Rescue Service, I handle dozens of emergency hacked wallet recovery operations on Ethereum mainnet and EVM L2s every month. Below is an anonymized, block-level walkthrough of a live rescue where the attacker's sweeper was monitoring both the public mempool and ERC-20 transfer events—and how we extracted 100% of the victim's locked tokens on the first attempt without leaking a single wei to the hacker.

Architecture diagram of sweeper bot rescue service workflow on Ethereum showing Compromised Key, Sponsor + Claim Tx, eth_callBundle Sim, and Flashbots Block Rescue — Figure 1: End-to-end Ethereum execution pipeline for **sweeper bot rescue service** (Compromised Key → Sponsor + Claim Tx → eth_callBundle Sim → Flashbots Block Rescue).

The incident: $42,800 trapped behind a sub-second ETH sweeper

A DeFi founder reached out to me on Telegram after accidentally committing a .env file containing his deployer/treasury wallet's private key to a public repository for roughly four minutes (a scenario we cover in Private Key Leaked on Ethereum? Save What's Left).

Within 18 seconds of the GitHub push:

An automated GitHub secret-scanner bot swept all liquid ETH (1.84 ETH) and liquid USDC ($6,200) out of the address.
When the victim panicked and sent 0.02 ETH from his Binance account to try to unstake his remaining tokens, the attacker's sweeper bot automatically front-ran/back-ran the deposit and drained 0.0198 ETH in the very next block.

However, the automated sweeper missed three non-standard positions still sitting inside the compromised wallet:

$28,400 in tokens maturing inside a Sablier linear vesting stream that required calling withdrawMax(streamId, to) from the compromised address.
$11,200 in staked governance tokens locked inside a custom StakingRewards contract with no transferrable receipt token (getReward() + exit()).
$3,200 in an unclaimed protocol airdrop that required a Merkle proof signature (claim(index, account, amount, merkleProof)).

Whenever someone searches wallet stolen what to do or stolen wallet what to do, this is the critical distinction: any ETH or liquid tokens already transferred to the thief's address cannot be reversed, and anyone promising to "hack back" already-stolen funds is running a recovery scam (see Crypto Recovery Scams: How to Spot Fake Wallet Recovery Services). However, any staked, vesting, unstaking, or unclaimed assets still controlled by your compromised address CAN be saved using a private flashbots rescue bundle.

Phase 1: Reconnaissance — Profiling the enemy sweeper bot

Before firing a single transaction from our token rescue bot, we always profile the attacker's sweeper behavior on Etherscan. A failed rescue attempt that leaks into the public mempool alerts the human operator behind the sweeper to write a custom script for your specific staking contract!

Here is what our diagnostic script checks on the compromised address (0xVictim):

Diagnostic Check	What We Found in This Case Study	Why It Matters for the Rescue Bundle
EIP-7702 Delegation Check (`eth_getCode`)	`0x` (Empty bytecode — no `0xef0100` delegation attached)	Confirmed a classic off-chain private-key sweeper rather than an on-chain EIP-7702 smart-account drainer
Sweeper Trigger Threshold	Swept any ETH balance `>= 0.0008 ETH` within 1 block	Funding gas had to match exact execution gas down to the wei so zero dust remained
Sweeper Gas Strategy	Legacy/EIP-1559 public broadcast with `45 Gwei` priority fee	Vulnerable to private MEV-Boost bundles (`eth_sendBundle`) that bypass the public mempool
Contract Call Monitoring	Sweeper only watched `ETH` balance and top-500 ERC-20 `Transfer` logs	The attacker had not yet discovered the Sablier stream ID or custom staking pool
Target Contract `recipient` Support	Sablier `withdrawMax` allowed specifying `to = 0xSafeVault` directly; Staking `exit()` forced withdrawal to `msg.sender`	Required an immediate `ERC20.transfer(0xSafeVault, balance)` as Transaction #4 inside the same bundle

(Note: Had eth_getCode(0xVictim) returned 0xef0100..., indicating a malicious EIP-7702 delegation, we would have prepended a Type-0x04 delegation-wipe authorization to Transaction #1. We compare both methods in EIP 7702 Rescue vs Flashbots Bundles: Saving Tokens.)

Phase 2: Designing the 4-transaction atomic Flashbots rescue bundle

Because the custom staking contract's exit() function hardcoded token.transfer(msg.sender, stakedBalance)—meaning the tokens had to pass through 0xVictim before moving to the clean hardware wallet (0xSafeVault)—every step had to execute atomically inside a single block with zero public mempool visibility.

We constructed the following 4-transaction flashbots rescue bundle:

Tx 1 (Signed by 0xSponsor):   Transfer exact gas budget (0.01482 ETH) -> 0xVictim
Tx 2 (Signed by 0xVictim):    Sablier.withdrawMax(streamId, 0xSafeVault)  [$28,400 sent directly to safe wallet]
Tx 3 (Signed by 0xVictim):    StakingPool.exit() + MerkleDistributor.claim(...)  [$14,400 lands in 0xVictim]
Tx 4 (Signed by 0xVictim):    Multicall / ERC20.transfer(0xSafeVault, fullBalance) + Bribe Builder

Why exact gas accounting prevents the sweeper from interrupting the bundle

Even inside a private bundle, what if the block builder also receives a random mempool transaction targeting 0xVictim?

Inside an eth_sendBundle array [Tx1, Tx2, Tx3, Tx4], block builders guarantee contiguous, ordered execution: no external transaction can be inserted between Tx1 and Tx2 or between Tx3 and Tx4.
Furthermore, we calculated the exact gas limit and fixed maxFeePerGas == maxPriorityFeePerGas + targetBaseFee for Tx2, Tx3, and Tx4 so that after Tx4 completed, 0xVictim's ETH balance dropped back below 0.0001 ETH.

Phase 3: Anvil fork simulation and `eth_callBundle` verification

Never submit a live sweeper bot rescue service bundle without simulating it first. If a staking contract has a hidden 24-hour cooldown or a non-standard transfer fee that causes Tx4 to revert, a poorly configured script might accidentally land Tx1 (the ETH gas deposit) without Tx4!

To prevent partial execution:

We forked Ethereum mainnet at the current head block using Foundry Anvil (anvil --fork-url $ETH_RPC_URL) and ran our rescue script locally (see How to Test an MEV Bot on a Mainnet Fork with Anvil).
Next, we called eth_callBundle against the live Flashbots relay (https://relay.flashbots.net) and verified:
- Zero reverts across all four transactions (Tx1 through Tx4).
- Exact post-state balanceOf(0xSafeVault) increases matching $42,800 in rescued tokens.
Notice that in eth_sendBundle, if any single transaction in the txs array reverts (unless explicitly listed in revertingTxHashes), the entire bundle is discarded by the builder. That means Tx1 (your gas sponsorship) can never land unless Tx4 (the token transfer to your safe wallet) also succeeds!

You can review the open-source template for this exact pattern in our compromised-wallet-sweeper-rescue GitHub repository and our DIY technical walkthrough How to Rescue Tokens from a Compromised Wallet with a Sweeper Bot (Flashbots Guide).

Phase 4: Multi-builder broadcast and block inclusion

Why do many DIY flashbots rescue attempts fail for 15+ blocks in a row, allowing the attacker time to notice? Because the victim only submits their bundle to relay.flashbots.net, which builds roughly 15%–25% of Ethereum blocks, while Titan Builder and Beaverbuild construct over 70% of blocks!

Our token rescue bot fanned the signed 4-transaction bundle out simultaneously across:

Titan Builder (https://rpc.titanbuilder.xyz)
Beaverbuild (https://rpc.beaverbuild.org)
Rsync Builder (https://rsync-builder.xyz)
Flashbots Relay (https://relay.flashbots.net)

We targeted blocks N+1, N+2, and N+3 with a 0.035 ETH builder tip (~$90).

Result: Titan Builder included the bundle at the top of the very next block (N+1).
Execution time from first simulation to tokens sitting safely in 0xSafeVault: 14 seconds.
Total rescued: $42,800 across all three positions; $0 lost to the sweeper.

Whether you need to Unstake From a Compromised Wallet, Claim an Airdrop From a Compromised Wallet, or Recover an NFT From a Hacked Wallet, the same multi-builder atomic bundle principle applies.

Frequently asked questions

How does a sweeper bot rescue service save tokens without the hacker stealing the gas ETH?

A sweeper bot rescue service never sends ETH through the public mempool. Instead, it uses an atomic private bundle (eth_sendBundle) sent directly to Ethereum block builders (Flashbots, Titan, Beaverbuild) where Transaction #1 funds the exact gas needed and Transactions #2–#4 unstake and transfer the tokens to your clean wallet in the exact same block position.

Can a token rescue bot recover crypto that was already transferred out of my wallet?

No. Blockchain transactions are immutable. Once ETH or ERC-20 tokens have already left your wallet address and sit in the attacker's wallet, no legitimate service can reverse them. A token rescue bot only saves assets that are still inside your compromised wallet (such as staked tokens, vesting claims, LP positions, airdrops, or NFTs) that the sweeper bot has not figured out how to claim yet.

What if the attacker attached an EIP-7702 delegation to my compromised wallet?

If your address has a malicious EIP-7702 smart-account delegation (0xef0100...) that automatically forwards incoming ETH, a standard Flashbots bundle will revert unless Transaction #1 includes a signed Type-0x04 authorization tuple revoking the delegation back to 0x000...000 (or re-delegating to a whitehat rescue contract) in the same atomic transaction.

How much does a professional Flashbots rescue cost?

Legitimate whitehat rescue teams—including MEV DAO's Sweeper Bot Rescue Service—never charge an upfront fee. We cover the simulation and builder bribe costs during the rescue and only retain a transparent percentage (typically 10%–15%) of the tokens successfully delivered into your new safe wallet.

Should I try to run a DIY rescue script first before contacting a rescue service?

If your locked tokens are worth under $500 and have no upcoming unlock cliff, experimenting with our open-source GitHub repo on an Anvil fork is a great way to learn. However, if you have thousands of dollars in a timed unstake cooldown or airdrop claim window, one misconfigured transaction that leaks to the public mempool can alert the hacker to write a counter-sweeper for that exact contract.

Need an urgent rescue for staked tokens, vesting streams, airdrops, or NFTs stuck in a compromised wallet? Read our Sweeper Bot Rescue Service page or message me directly on Telegram at @merunas with your wallet address and target contract—zero upfront fee, pay only on successful recovery.

About the Author — Merunas Grincalaitis: Merunas is the Founder and Lead MEV Engineer at MEV DAO, an Ethereum smart contract architect and Flashbots searcher who has built production Solidity contracts, Block-0 sniping engines, and whitehat token rescue bundles since 2017 (author of Mastering Ethereum technical tutorials and open-source MEV frameworks). Verify our open-source benchmarks, Foundry Anvil simulation harnesses, and live bundle tooling on GitHub (@merlox), GitHub Org (@mevdao-org), X (@merunasgrincalaitis), DEV Community, and Hashnode, alongside primary protocol specifications at Flashbots Bundle Docs and EIP-7702 Specification. Need immediate help beating an active sweeper? Contact our 24/7 engineering desk on Telegram (@merunas) or inspect our open-source rescue scripts on GitHub (mevdao-org/eth-sweeper-rescue).