Phantom

🚨 New paper alert 🚨 No Place to Hide: An Analysis on Protected Order Flow Sandwich Attacks w/ Ozan Solmaz @boez95 @ChristofTorres Bots watch every pending trade in Ethereum's public mempool and sandwich the ones worth attacking. Hence the nickname: the dark forest. In response, Ethereum and other chains built protections, from private RPCs to mechanisms native to the chain, that shield trades from these bots. We call this protected order flow. How well are these users actually protected? We measured it in a three-year study of sandwich attacks by persistent bots against protected order flow on Ethereum, Solana, Tron, Base, Arbitrum, and Monad. The protections on these chains range from private RPCs on Ethereum and private submission to a centralized sequencer on Base and Arbitrum, to first-come-first-served ordering in Tron's public mempool and local mempools on Solana and Monad. Local mempools were never meant as a full front-running prevention, but they do limit who sees a trade before it lands. On four of the six chains, we observe protected order flow sandwich attacks: 28.0M attacks on Solana, 38,567 on Tron, 30,607 on Ethereum plus 2,576 more through reorged blocks, and 1,889 on Base. We trace each chain's exposure and find that it sits in various places along a transaction’s path. 🟠 Ethereum: OFAs can expose enough information to make private trades sandwichable, especially when the same transaction reaches multiple OFAs or when searchers receive full transaction details. Reorged blocks also expose private transactions. We find transactions that were private and untouched in a block that got reorged, and then sandwiched on the canonical chain. 🟠 Solana: transactions are sent to the upcoming leaders, and early on we find that a few leaders carry far more attacks in their blocks than their share of blocks, i.e., they are likely the exposure source for these transactions. From 2025 that fades, but we see that victims concentrate around a few apps. 🟠 Tron: we presume that bots win latency races in the public mempool, so the first-come-first-served ordering in block building does not fully prevent sandwiches. 🟠 Base: we see two different kind of exposure. One lines up with a documented RPC bug that exposed pending transactions. The other has attackers preying on victims who trade on a predictable schedule, if the vicim does the same trade every couple of blocks, the attacker can front-run them without observing the pending trade. Protected order flow sandwiches look very different from public mempool sandwiches. The attacker's transactions often land in a different block than the victim's, and unlike in the public mempool, their success is not guaranteed. These attackers simply don't act with the same certainty. The dark forest may have shrunk, but we show there's an even darker corner of it, where users who think they're protected still get front-run. Protection has to hold at every layer, from the app to the RPC to the block producer. Encrypted mempools and TEE-based designs can help, by keeping transaction contents out of attackers' reach until inclusion. But even they might not be enough on their own without privacy, for example if the victim is too predictable. Link: arxiv.org/abs/2609.28115