Backrun vs Sandwich: When to Use Each Strategy

Answer first — A backrun trades immediately after a target transaction, capturing arbitrage value the target left behind by moving a pool out of equilibrium. A sandwich trades both before and after the target — the front-run buys, the target's swap pushes the price, then the back-run sells at the worse price the target created. Mechanically the difference is one extra transaction; ethically and operationally it's a chasm. Backruns are positive-sum (they restore prices toward equilibrium and don't worsen outcomes for the target user); sandwiches are explicitly extractive (the target user gets a worse fill because of the sandwich). In 2026 most serious MEV operations run backruns and explicitly disable sandwich logic — both because the regulatory direction is unfavourable and because protocol-side defences (private RPCs, MEV-Share, sandwich-resistant routers, MEV-Blocker rebates) increasingly route ordinary user flow away from sandwich-able mempool exposure. FRB Agent ships with sandwich strategies disabled by default; the working policy in 2026 is to keep them off unless your jurisdiction and counterparty pool both genuinely permit them.

Mastery path

• What is MEV?
• Private vs public mempool
• Backrun vs sandwich (current)
• Inclusion probability 101
• Fixing failed bundles guide
• Mempool scanning 101

Mechanics, side by side

The single biggest difference: a backrun makes nobody worse off than they were before. The target user's transaction would have moved the pool whether you backran them or not — the arbitrage value was created by their trade and would otherwise be captured by someone else (or remain as transient pool imbalance until the next arbitrageur). A sandwich, by contrast, makes the target's fill worse than it would have been in the absence of your bot.

When backrun is the right tool

• Liquid AMM swaps moving price meaningfully. A trader executes $200k against ETH/USDC; the pool moves; you trade against the post-swap state to capture the imbalance. Pure arbitrage.
• Liquidations on lending protocols. A position becomes liquidatable; the liquidation transaction moves collateral; you backrun to capture associated arbitrage between liquidator-received collateral and current market.
• Cross-DEX rebalancing. A swap on Uniswap moves price; the price differential against Sushi/Curve creates a cross-DEX arb opportunity; you take the arbitrage.

In all three cases your transaction lands the price closer to fair value. The protocol benefits, the arbitrage market benefits, and no individual is materially worse off.

When sandwich is theoretically applicable but operationally unwise

There are pool conditions and target-user conditions where a sandwich's economics work — wide-tolerance swaps, illiquid pools where slippage is high to begin with. Most operators in 2026 still avoid them because:

• Regulatory direction. Several jurisdictions are explicitly studying sandwich attacks as market-manipulation analogues. The legal posture is moving toward "this is harmful and at minimum requires disclosure."
• Reputation cost. Public association with sandwich extraction limits institutional partnerships and counterparty access. The economics of one trade are dwarfed by the long-tail business cost.
• Protocol-side defences are working. Flashbots Protect, MEV-Blocker, MEV-Share, and increasing adoption of sandwich-resistant routing (CoW Swap, MEV-protected RPCs in major wallets) mean the addressable surface for sandwiches shrinks every quarter.
• Counterparty pools shift. When wallets default-route users through sandwich-protective endpoints, the population still hitting the public mempool is increasingly not an unsuspecting retail user — it's protocol smart contracts, other bots, or users who've explicitly chosen direct submission. The economics of sandwiching that population are different.

For these reasons FRB Agent disables sandwich strategies by default. They can be enabled but it requires explicit configuration plus a policy acknowledgement.

A working decision tree

For any opportunity:

1. Is the target a normal user submitting through a public-mempool RPC? If yes, default to backrun-only — this is the population for whom sandwich is most ethically and regulatorily problematic.
2. Is the pool deep and liquid? If yes, backrun economics work; sandwich economics are usually thin anyway because slippage tolerance is low.
3. Is the trigger transaction itself a contract-to-contract action (DEX router, aggregator, automated strategy)? Then backrun is still the right tool — there's no individual user being harmed, but the dynamics are pure arbitrage.
4. Is your jurisdiction's regulatory position on sandwich extraction unclear or hostile? If yes, treat sandwich as off-limits.

The default for FRB Agent and for serious operators in 2026 is: backrun only. If the question is whether to enable sandwich, the answer is almost always no.

Operational discipline either way

Whether backrun or (rarely) sandwich:

• Always simulate against a fork at current head before signing. The biggest losses come from sim-vs-reality drift, not from "the strategy was wrong."
• Always reference the trigger tx explicitly in the bundle. Without an explicit targetTxHash-equivalent, your backrun can land in a different block than the trigger and have no effect.
• Always cap slippage tightly per pool class. Slippage caps don't get widened to make trades land — they get tightened.
• Always track realised vs simulated PnL. A persistent gap (>10% over 100+ trades) is a model bug, not statistical noise.

Backrunning on Solana vs Ethereum

The mechanics of backrunning differ significantly between Solana and Ethereum, and strategies designed for one chain don't transfer directly to the other.

Ethereum backrunning: The standard pattern is submitting a bundle via eth_sendBundle where your backrun transaction is explicitly referenced to the trigger transaction. The bundle guarantees atomicity — your backrun lands in the same block as the trigger or not at all. This is essential for GMX backrunning on Arbitrum, Uniswap V3 tick arb on Ethereum, and AAVE liquidation pairs.

Solana backrunning via Jito: Jito bundles provide the same atomicity guarantee on Solana — your backrun and the trigger transaction are in the same bundle and execute atomically. The key difference is that Solana has no traditional mempool; the trigger transaction must either be in your bundle or already confirmed before you submit. For Jito-based backrunning, the pattern is typically to backrun a confirmed (already-landed) transaction in the next block rather than co-bundling.

Speed considerations: On Ethereum's 12-second blocks, you have substantial time to detect a trigger, simulate your response, and submit a bundle for the same block. On Solana's ~400ms blocks, the window from detecting a trigger to submission is measured in milliseconds. Yellowstone gRPC subscription (versus standard WSS) is effectively mandatory for competitive Solana backrunning — standard WebSocket endpoints add 100-200ms of detection lag that eliminates most of the window.

References

• Flashbots: bundle structure
• MEV-Share and OFA
• Inclusion probability 101
• Arbitrum MEV: Latency Pitfalls & Routing Tips
• Zero Latency Trading on Solana