How is a Sandwich Attack different from the "frontrunning" most people are familiar with, and why is it especially hard to defend against?
Frontrunning, in everyday usage, usually means "completing the same trade before you do." A sandwich attack is more surgical: the attacker isn't racing to beat your trade — they're bracketing it, inserting one transaction before yours and one after, so your trade executes sandwiched in between. That means the attacker doesn't need to compete with you on who settles first; they only need to guarantee their two transactions land immediately before and after yours.
The reason it's hard to defend against comes down to a single Trigger Condition: your trade intent has to become visible in the public Mempool before it can be attacked. As long as your transaction hasn't been packed into a Block yet and is sitting in pending confirmation, any bot monitoring the mempool can in principle see exactly what you're about to do, how much capital is involved, and how much Slippage you're willing to tolerate — a structural exposure baked into Ethereum's "broadcast first, confirm later" transaction mechanism, not a mistake on the user's part.
If Sandwich Attack profits have already been compressed to an average of just $3 per attack, does that mean the problem is close to being solved?
The headline number invites that misreading, but the reality looks more like a shift in the battlefield than the problem disappearing. Throughout 2025, 515 distinct bots were active on Ethereum at some point, but in a typical month only around 100 were actually executing trades consistently — and just 6 of those bots generated more than $10,000 in cumulative profit. That signals competition in this niche has become intense enough to push most participants' margins toward breakeven (roughly a third of bots hovering between -$10 and $10), or into outright losses (roughly 30% net negative).
But the number of attacks itself hasn't declined — it's held steady at 60,000 to 90,000 per month. That means overall victim exposure hasn't decreased; what's shrunk is the profit sliced off each individual attack. A falling per-attack profit mostly reflects intensifying competition among bots — that's a separate question from whether user-side protection has actually gotten more effective, and the two need to be evaluated independently.
Why does Jared's bot strategy capture roughly 70% of the market — is it purely a technical edge?
Not entirely a technical advantage — the more decisive factor is strategic positioning. Cointelegraph Research's analysis notes that Jared's core strategy is volume over selectivity: capturing as many opportunities as possible, including many tiny attacks worth only a few cents in profit, rather than cherry-picking only high-Margin targets the way most bots do. This approach is particularly effective in an environment where gas costs stay relatively low compared to per-attack revenue, since even thin individual profits add up to a substantial total at scale.
That also means Jared's strategy isn't a guaranteed win — in April 2025, the bot's profit margin briefly turned negative 20%, a loss of about $12,000 for the month, showing that even the dominant player in this market can lose money when competition intensifies, gas costs fluctuate, or Slippage calculations go wrong. A high market share reflects an edge in execution scale and speed, not proof that this business carries no risk.
Beyond setting amountAMin and switching to an anti-frontrunning RPC, is there a more direct way for an ordinary trader to check whether a past trade of theirs was ever sandwiched?
Yes, and it doesn't require any paid tools. Paste your transaction hash into a Block Explorer like Etherscan, find the Block number your transaction landed in, and then look at the other transactions immediately before and after yours in that same block. If there's one transaction right before and one right after, involving the same counterparty address and closely related assets (for example, both interacting with the same pair you traded), that's the classic fingerprint of a Sandwich Attack. Some block explorers and MEV-specific tracking platforms (such as EigenPhi's own EigenTx tool) even flag directly whether a given transaction has been classified as a sandwich attack victim, saving you the manual comparison work.
If you confirm you've been a victim before, beyond learning the lesson and setting Slippage protection going forward, it's also worth checking whether that same pool and that same bot address show up repeatedly. If you frequently trade in a handful of low-liquidity pools, you're effectively re-exposing yourself to the same set of bots' hunting grounds each time — it's worth considering switching to pools with deeper liquidity and inherently lower slippage risk.
On January 20, 2025, a user set out to add liquidity to a low-Liquidity Pool on Uniswap V2, planning to deposit 9.946 WBTC alongside an equivalent amount of waBTC. From start to finish, the entire transaction took less than a single Block — and the user walked away having lost nearly $870,000. This is one of the largest sandwich attacks EigenPhi has ever recorded, and every step of it remains permanently on-chain, reconstructable by anyone after the fact.
Once a bot controlled by the attacker (address beginning with 0xe2cd) spotted the victim's transaction sitting in the public Mempool, it inserted three transactions into the same block. The first, a "front-run," swapped 95.1184 ETH for 2.9336 WBTC and deposited it into the pool ahead of the victim, instantly pushing the waBTC-to-WBTC exchange rate to an extreme. The second was the victim's original transaction — because they hadn't set an amountAMin (minimum acceptable amount) protection parameter, it executed anyway at the manipulated rate, severely diluting the asset composition of what they deposited. The third, a "back-run," immediately swapped a negligible amount of waBTC back for 12.8778 WBTC — including the 2.9336 WBTC the bot originally put in, netting 9.9442 WBTC in profit. The attacker ultimately converted the proceeds into over 360 ETH, paid block builder Titan Builder a 22.6 ETH tip, and kept roughly 337.9 ETH.
What's worth noting is that the price distortion from this attack didn't end once the back-run transaction completed. When EigenPhi later dissected the same block, they found at least two other bots riding the same wave of price volatility. One bot pocketed roughly $27,000 arbitraging the price gap created across pools by the attack; another paid an unusually large 11.3 ETH tip to secure a slot in the block, apparently running a matching Arbitrage on a centralized exchange simultaneously. Combined, the incident generated over $840,000 in profit across multiple bots, with the main sandwich bot alone taking home about $796,000 — a reminder that a single MEV opportunity is rarely an isolated event; it frequently triggers a cascade of follow-on arbitrage.
Zooming out to the entire Ethereum ecosystem, this case isn't an outlier. According to data EigenPhi supplied to Cointelegraph Research, more than 95,000 sandwich attacks were recorded on Ethereum over the twelve months from November 2024 to October 2025, and roughly 70% of them were linked to a single bot operating under the pseudonym "jaredfromsubway.eth." The bot's latest version (v2) has evolved to run compound attacks targeting up to four victims simultaneously, sometimes inserting an additional "center transaction" between the front-run and back-run to push exchange rates even further. While total extraction has shrunk from nearly $10 million in a single month in late 2024 to about $2.5 million by October 2025, the number of attacks has held steady at 60,000 to 90,000 per month throughout — declining profit doesn't mean fewer attacks, just a thinner slice landing in each bot's pocket.
If you've ever completed a DEX trade with worse-than-expected Slippage, that's likely not a coincidence — it may well be the direct result of a Sandwich Attack, especially if you were trading stablecoins or wrapped assets in what's classified as a "low-volatility" pool: data shows nearly 40% of attacks target exactly these pools, because most traders don't bother setting strict slippage protection on them, making them the easiest targets. There are two practical, non-technical safeguards. First, route your trades through an anti-frontrunning RPC service like MEV-Share or MEV Blocker within your wallet or trading interface, so your trade intent never surfaces in the public mempool ahead of time. Second, no matter which platform you trade on, always set a minimum-acceptable-amount slippage protection parameter — never leave it blank or set it too loosely. The $870,000 victim above lost that much precisely because they skipped this one step.