TL;DR
Front-running is when a bot or trader detects your pending transaction and submits their own trade before yours to profit from the price movement your trade will cause.
A front-runner monitors incoming transactions — either through Jito’s block builder relay or through validator-level access. When they spot a large buy order heading for a DEX, they submit their own buy first (with higher priority fees) to move the price up. Your trade then executes at a worse price. The front-runner sells immediately after, capturing the spread. On Solana, this entire sequence can happen within the same block in under 400 milliseconds.
The most common form of front-running on Solana is a sandwich attack: the attacker places a buy before your trade (front-run) and a sell after (back-run), squeezing profit from the slippage your trade creates. The victim ends up paying more for the token, while the attacker captures the price difference risk-free. Sandwich bots are sophisticated — they simulate your transaction to calculate exact profitability before committing.
Large market orders on DEXs are the primary targets. The bigger your trade relative to pool liquidity, the more profit a front-runner can extract. Tokens with thin liquidity are especially vulnerable. Trades submitted without MEV protection through standard RPC endpoints are visible to searchers. Even moderate-sized trades (a few hundred dollars) can be profitable to sandwich if the pool is shallow enough.
Send transactions through MEV-protected RPC endpoints or Jito bundles, which prevent searchers from seeing your trade before it lands. Jupiter offers a built-in MEV-protection toggle. Most Solana trading bots on MadeOnSol route through Jito by default. Keep slippage tolerance as low as practical — lower slippage means less room for a sandwich. For very large trades, split into smaller chunks or use limit orders to avoid creating a single large target.