How Solana Trading Bots Avoid Sandwich Attacks on DEX Swaps

Sandwich attacks on Solana are not a theoretical concern — they are an everyday cost that poorly configured bots pay silently on every swap. The mechanics are identical to Ethereum: a searcher spots your pending transaction, frontruns it to move the price, lets your swap execute at the worse price, then immediately backruns to pocket the difference. What is different on Solana is that the attack surface, the defenses, and the economics all behave differently enough that solutions ported naively from EVM chains fail in subtle ways.

Why Solana's Architecture Changes the Threat Model

Solana has no public mempool in the traditional sense. Transactions are forwarded directly to the current leader and discarded if they miss their slot. In practice, though, there is a window of exposure: Gulf Stream forwards transactions to the anticipated next few leaders before the current block is sealed. That short window is enough for well-connected searchers — particularly those running nodes co-located near validators — to observe, construct, and submit competing transactions that land in the same block.

Jito's block engine made this even more explicit. It introduced a real, ordered mempool for bundles, which dramatically lowered the barrier for sandwich attacks while simultaneously offering the most reliable defense mechanism available.

Jito Bundles: The Primary Defense

The most effective tool for bot operators on Solana right now is submitting swaps as Jito bundles rather than individual transactions. A bundle is an atomic group of up to five transactions that the Jito block engine guarantees will land consecutively, in order, with no transactions interleaved. A sandwicher cannot insert a frontrun between bundle transactions because the bundle is atomic at the block-construction level.

The trade-off is cost. Bundles require a tip — typically denominated in lamports — paid to the Jito tip accounts. In low-competition windows, tips of 10,000–50,000 lamports are sufficient. During high-throughput periods or when trading in the same slot window as a popular token launch, competitive tips can spike an order of magnitude higher. Our bots on /services/bots dynamically size tips based on observed bundle landing rates from the Jito block engine's feedback endpoint, rather than using a fixed constant.

One sharp edge: if your bundle fails to land — because tip competition was too high or the slot was already committed — Jito does not retry it. Your logic must handle the no-land case explicitly, re-evaluate the opportunity, and decide whether to re-submit. Bots that loop on a fixed bundle without checking whether market conditions still justify the trade will hemorrhage tips.

Compute Unit Pricing and Priority Fees

Before Jito bundles became the dominant approach, the standard advice was to set high priority fees to out-prioritize potential sandwichers. This still matters as a second layer of defense, particularly for non-bundle transactions where you want your transaction processed before competing ones in the same leader queue.

The mechanics on Solana: you attach a SetComputeUnitPrice instruction with a microlamports-per-compute-unit value. Getting this number right requires observing recent block data. We use the getRecentPrioritizationFees RPC method over a rolling 50-slot window and take the 75th percentile as a baseline, then multiply by 1.5 for time-sensitive swaps. Static values — especially the hardcoded 1,000 or 10,000 microlamports per CU that appear in tutorials — are useless during congestion and wasteful during quiet periods.

Also set an explicit compute unit limit with SetComputeUnitLimit. Letting the runtime use the default 200,000 CUs for a simple swap costs you in priority fee calculation. A single-hop Jupiter swap typically needs 80,000–120,000 CUs depending on the pool type. Profile your transactions, set a tight limit, and your effective per-lamport priority improves.

Slippage Tolerance: The Leaky Bucket

Slippage tolerance is not a sandwich defense by itself, but it is the mechanism that determines how much a sandwich can extract from you. A 1% slippage tolerance on a $10,000 swap means an attacker can reliably extract up to $100 per transaction — enough to make the attack profitable even accounting for their own fees and compute costs.

Practical settings we use in production:

• Liquid pools (SOL/USDC on Raydium CLMM, large Orca whirlpools): 0.1%–0.3%
• Mid-cap tokens with reasonable depth: 0.3%–0.5%
• Low-liquidity or volatile tokens: accept higher slippage only if the opportunity edge justifies it, and prefer smaller position sizes

The important discipline is computing your expected price impact before constructing the transaction, then setting slippage relative to that computed impact rather than using a blanket percentage. If your expected impact is 0.15%, setting 1% slippage is giving away eight times your impact as extractable value. Set 0.25% instead and you limit the extraction window to your actual uncertainty.

Route Splitting and Pool Selection

Splitting a large swap across multiple pools or routing through intermediate tokens does more than improve price — it reduces the depth of impact on any single pool, which reduces the sandwich profitability. An attacker needs to move the price in a specific pool ahead of your transaction. If your $50,000 BONK buy is split 60/40 across two pools, the attacker must sandwich both legs simultaneously, which requires two bundles or two frontrun transactions landing consecutively — a much harder coordination problem.

Jupiter's API exposes the split-route option. Use it. The additional latency of computing multi-route quotes is usually worth the sandwich reduction, except in sub-second arbitrage scenarios where you are already operating in bundle-only mode.

Monitoring for Exposure

None of these defenses matter if you cannot tell when they are failing. We instrument every swap with a post-transaction check: fetch the transaction result, compute the actual execution price, and compare it to the pre-swap simulated price. A consistent gap larger than your slippage setting signals that something is wrong — either your simulation is stale, your tip sizing is off, or a new attack vector has opened up. Alert on it. Do not let silent leakage accumulate for days before you notice.

Helius's enhanced transaction API and the Solana FM transaction parser both make it straightforward to pull this data programmatically. Build the feedback loop first, before you optimize anything else.

---

If you are running a bot on Solana and unsure whether your current setup leaks value to sandwichers, talk to us — we audit existing bot configurations and have shipped production-grade MEV protection across Solana, Hyperliquid, and Polymarket.