If Mempool transactions are inherently public, why can't exchanges or protocols just design pending transactions to be invisible, cutting off sandwich attacks at the root?
The answer touches on the foundational design philosophy of public chains like Ethereum: a public mempool is a direct byproduct of being decentralized and permissionless — any validator needs to be able to see incoming transactions to fairly compete for the opportunity to pack them into a Block. Fully hiding the mempool at the protocol level would concentrate the power to see and order transactions into the hands of a small number of specially-privileged participants, directly conflicting with the core spirit of decentralization.
The solution the industry has adopted instead isn't eliminating the public mempool at the protocol level — it's offering optional alternative channels like private RPCs and order-flow auctions. Users can choose to route their transactions directly to a specific block builder, bypassing the exposure risk of the public mempool — but that's an opt-in additional service a user actively chooses, not a base-layer rule the entire network is forced to adopt. This incremental, market-driven approach reflects, to some degree, the compromise the industry has currently settled on between the ideal of decentralization and users' practical need for protection.
How is JaredfromSubway's loss here fundamentally different from the "Private Key stolen" or "contract exploited" incidents users commonly hear about?
The core difference lies in the attack surface itself. A stolen private key typically means a user's signing credential leaked out — through a phishing site or malware — and once an attacker has it, they can sign any transaction directly as the victim. A contract exploit means an attacker found an actual logic flaw in the Smart Contract's code, and through a carefully crafted call sequence, gets the contract to execute behavior its developers never intended, draining funds that way.
JaredfromSubway's loss here was neither. The attacker never obtained the bot's private key, and never broke any smart contract's code logic — they simply exploited the bot's own behavioral logic of "automatically trust and interact with anything that looks like a profitable Arbitrage opportunity." That means what this attack genuinely exposed wasn't a cryptographic or code-level weakness — it was that the automated trading system's design lacked a sufficiently rigorous pre-screening mechanism for deciding what kind of counterparty deserves trust. This category of weakness is typically harder for traditional security audit tools to catch than a code exploit, precisely because the code is executing exactly what it was designed to do — the flaw sits in the judgment logic behind what it was designed to do in the first place.
If sandwich-attack volume has already dropped 75% overall, does that mean everyday users doing Token swaps don't really need to worry much about getting sandwiched anymore?
The overall decline is a genuine trend, but that number reflects a drop in industry-wide average risk, not an equal reduction in risk for every individual transaction. Users who've adopted MEV-protection tools (private RPCs, order-flow auctions) have genuinely and substantially reduced their own probability of being targeted, and that's the main driver behind the overall decline. But if an everyday user is still routing transactions through a default public RPC Node and hasn't proactively adjusted their Slippage settings, their exposure hasn't automatically shrunk just because the overall market's scale has. It's a bit like an overall crime rate dropping — that doesn't mean risk fell proportionally for every single person who left their door unlocked; whether protective measures are actually in use is what determines individual risk.
The more precise way to think about it: the overall "cost-effectiveness" of sandwich attacks is declining because more and more easy targets have switched to protection tools — which could actually make the remaining unprotected users look relatively more attractive as one of the few remaining soft targets in an attacker's eyes. An attacker's resources don't disappear; they just get increasingly concentrated on the small group of people who still haven't taken precautions.
If I start using MEV-protection tools like private RPCs or order-flow auctions, what should I actually pay attention to — does setting them up mean I don't need to worry anymore?
The first thing to keep in mind is that a private RPC or order-flow auction is itself a service provided by a specific provider or builder. Using one of these tools means shrinking the question of "who can see my pending transaction" from "every Mempool participant" down to "this one specific provider" — which genuinely reduces sandwich-attack risk substantially, but it also means taking on an additional trust assumption toward that specific provider, and it's worth paying attention to that provider's own reputation and track record.
The second thing to keep in mind is that these tools generally can't eliminate every form of MEV entirely. Some order-flow auction designs, for instance, redirect what would otherwise be captured by a sandwich bot into a rebate paid to the user by the auction winner — that improves your actual execution price, but it's a redistribution of the spread, not the spread disappearing altogether. Third, even with protection tools in place, setting Slippage remains a necessary last line of defense — protection tools mainly reduce the probability of being specifically targeted, not the underlying risk that the market itself is genuinely moving sharply at that moment. Both need to work together to provide reasonably complete protection.
JaredfromSubway.eth is Ethereum's most infamous sandwich-attack bot, having accumulated an estimated $295 million in profit over time by sandwiching other users' trades. In June 2026, an unidentified attacker deployed 66 fake contracts disguised as well-known tokens — WETH, USDC, USDT — letting the bot's automated trading logic scan for Arbitrage opportunities as it normally does, unknowingly granting Token-spending approvals to these fake contracts along the way. Once enough approvals had accumulated, the attacker swept the bot's actual ETH and Stablecoin holdings in a single coordinated sequence, draining at least $7.5 million. What makes this incident genuinely notable isn't the dollar amount — it's that it precisely demonstrates how the information advantage that sandwich attacks themselves depend on can be turned right back against the predator using it.
A sandwich attack exploits the fact that a blockchain transaction briefly sits visible in a public waiting area — the Mempool — before it gets packed into a Block. Anyone can see what's about to happen before it's confirmed. When a large token swap appears in the mempool, an MEV Bot calculates the price impact that transaction would cause once executed, then front-runs it by submitting a buy order first (paying a higher fee than the original transaction to guarantee priority inclusion), pushing the price up. Once the original transaction executes at that inflated price — leaving the user with fewer tokens than expected — the bot submits a sell order, cashing in at the inflated price it created. Throughout this process, the victim's original transaction sits sandwiched between the attacker's two transactions, which is exactly where the name comes from.
What made this attack succeed was the attacker precisely exploiting the JaredfromSubway bot's own automated logic: the bot's core function is continuously scanning the mempool for arbitrage opportunities and automatically reacting to token trades that look profitable. The 66 fake contracts the attacker deployed were designed and named to deliberately mimic well-known tokens, tricking the bot's automated system into misjudging them as genuinely profitable arbitrage opportunities — and in the course of interacting with them, the bot granted token-spending approvals through its normal process, exactly the same standard procedure it executes on thousands of real transactions every single day. The attacker never exploited any Smart Contract vulnerability; they simply used the bot's own behavioral pattern of "automatically interacting with anything that looks like an arbitrage opportunity" as the attack surface itself. Once enough approvals had built up, the attacker struck, emptying the bot's actual wallet holdings in one clean sweep.
Based on a dataset covering over 95,000 attacks, monthly sandwich-attack extraction fell from roughly $10 million in late 2024 to about $2.5 million in October 2025 — a 75% decline. That decline is largely credited to users increasingly adopting MEV-protection tools — private RPCs or order-flow auctions that keep pending transactions out of the public mempool that sandwich bots scan — attackers simply can't see the transaction content, so there's nothing to act on. Currently, more than 88% of Ethereum's MEV-Boost blocks are handled by three relay operators, with a single builder alone constructing more than half of all blocks. This increasingly concentrated block-building market structure has, to some extent, also made it harder for large-scale, systematic sandwich attacks to operate at the same scale they once did.
The most practical takeaway isn't the specific bot's downfall — it's that the same MEV-protection tools that shrunk the sandwich-attack economy in the first place are directly available to you: routing swaps through a private RPC or an order-flow auction keeps your pending transaction invisible to bots scanning the public mempool, which is a far more direct defense than simply lowering your Slippage Tolerance. And if you're setting Slippage anyway, remember it's a trade-off, not a fix — too tight and legitimate trades start failing and reverting (still costing you gas), too loose and you leave more room for exactly the price impact a sandwich attack is designed to exploit; there's no single number that's safe for every trade, only one that fits the specific token's liquidity and the moment's volatility.