If you trade or build on Solana and your transactions are visible in the public mempool before they're included, you're being priced. The amount lost to MEV — Maximal Extractable Value — across DeFi has been measured in billions. On Solana specifically, the dominant attack vector is the sandwich: a bot front-runs your trade, lets you execute, then back-runs it for the price impact.
This guide covers what MEV looks like on Solana, the protection patterns that actually work, and how MEV-blocker / batch-auction / native-RPC approaches differ in practice. The goal is to give you enough mental model to pick the right protection for what you're building.
What MEV Is, Specifically on Solana
MEV is the value extractable by an actor with transaction ordering power beyond standard fees. On chains with public mempools (Ethereum, BSC), this happens at the mempool level — bots see pending transactions and reorder.
Solana is different. Solana doesn't have a traditional public mempool — transactions go directly to the validator scheduled to produce the next block. But that doesn't make Solana MEV-free. The exposure points just shift:
- Validator-side ordering: a validator producing a block can reorder transactions in their slot.
- RPC-side observation: an RPC provider sees transactions before forwarding. A malicious or compromised RPC can leak.
- Pre-confirmation visibility: transactions broadcast through certain paths become visible to bots before they land, allowing front-running.
The practical impact on a trader is the same as Ethereum: your trade gets sandwiched, you pay more slippage than you should, and the difference goes to a bot.
Sandwich Attacks: How They Actually Work
A sandwich attack on Solana looks like this:
- You submit a swap of, say, 100 SOL into a memecoin via a DEX.
- A sandwich bot detects the pending swap.
- The bot front-runs you: buys the same memecoin first, pushing the price up.
- Your swap executes at the now-higher price.
- The bot back-runs you: sells immediately, capturing the price impact you just created.
You walk away with fewer tokens than the AMM math at submission time would have given you. The bot walks away with the difference, minus its own fees.
Volume on this is large. Any DEX-facing application without protection is a contributor to that statistic.
MEV Protection Patterns
There are several well-known patterns, each with different trade-offs.
1. Private Mempools / Private RPC Routing
The transaction never enters a public path. It goes from your client to a private endpoint that delivers it to a validator without intermediate visibility. This is the most direct mitigation: bots can't front-run what they can't see.
This is the model used by BoltTx. Every transaction routed through our endpoint is delivered without pre-confirmation exposure. There's no separate product, no opt-in, no extra integration — it's the default path.
2. MEV-Blocker Pattern
MEV-blocker is a documented pattern (originally on Ethereum) where the RPC routes transactions through searchers who agree not to front-run, and refunds users if the searcher extracts MEV. The Solana version of this concept is less standardised, but the idea — RPC-level economic guarantees against front-running — is gaining traction.
If you're researching mev-blocker rpc docs or the broader MEV-blocker ecosystem, you'll see references to this on Ethereum primarily. The underlying principle (RPC-level protection with economic accountability) is what BoltTx provides natively for Solana, without requiring you to evaluate a separate searcher economy.
3. Batch Auctions
Batch auctions are another MEV-protection approach: orders are collected over a window and matched together in one settlement, neutralising sandwich attempts because there is no individual transaction to front-run.
This pattern is used by some DEXes on Ethereum. Solana doesn't have a direct equivalent at the same scale, but several Solana DEXes are exploring similar mechanisms. For traders, the practical takeaway is: the chain matters, and what works on Ethereum doesn't always port directly.
4. Frontend-Level Anti-MEV (Built into Trading Terminals)
Some Solana trading terminals bundle their own MEV-protection layer into their trading flow. These work as long as you trade exclusively through that terminal. The moment you submit transactions through a different path, the protection is bypassed.
For dApp developers, this isn't a strategy — it's a constraint on the user. You can't enforce that every user trades through a specific frontend. You need protection at the RPC layer.
Where Each Pattern Fits
| Pattern | Best for | Trade-off |
|---|---|---|
| Private RPC routing (BoltTx-style) | dApps, bots, AI agents — any programmatic submission | Requires using a specific RPC |
| MEV-blocker | Ecosystems with mature searcher economies | Solana implementation less mature than Ethereum's |
| Batch auctions | DEXes building from scratch with this primitive | Higher implementation cost; not portable |
| Frontend-level (built into trading terminals) | End users locked into one trading UI | No protection if user routes elsewhere |
For most builders shipping Solana applications today, the realistic choice is: route transactions through an RPC with native Anti-MEV. That's the option with the lowest integration cost and the highest leverage.
What "Native Anti-MEV" Means in Practice
When we say BoltTx routes with native Anti-MEV, here's what that means concretely:
- Transactions submitted to
https://bolttx.io/?api-key=...are not exposed to the public observation surface that bots scrape. - The default path is the protected path. There is no "MEV mode" toggle to forget about.
- This applies to every transaction — DEX swap, NFT mint, token transfer, custom program call.
It's the same code path you use to send any transaction. You don't need to think about MEV at all; the protection is part of the routing.
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
// This sendTransaction is automatically routed with Anti-MEV protection.
const signature = await connection.sendTransaction(tx, signers, {
skipPreflight: true,
maxRetries: 0,
});
That's the entire integration. There's no "enable MEV protection" parameter, because there's no version that doesn't have it.
When MEV Protection Matters Most
Be honest about your workload. Not every transaction needs MEV protection.
Definitely needs protection:
- DEX swaps (any token-to-token trade)
- Liquidity provision and removal on AMMs
- Arbitrage routes
- NFT mints in competitive drops
- Any trading bot or market-making strategy
- Token launches and presales
Probably doesn't need protection:
- Simple SOL transfers between wallets
- Reading on-chain state (no transaction)
- Account creation
- Stake/unstake to validators (rarely sandwichable)
If your application is in the first category, RPC-level Anti-MEV is part of your cost structure whether you account for it or not. Better to make it explicit and choose the option that gets it right.
What to Do This Week
Whether or not you end up using BoltTx, this is the practical sequence we'd recommend:
- Audit your current transaction flow. Identify which transactions are MEV-exposed (DEX swaps especially).
- Measure the cost. Look at your historical trades and estimate slippage attributable to sandwiches. There are tools that help with this on Solana.
- Choose a protection layer. For most builders, native Anti-MEV at the RPC layer is the highest-leverage choice.
- Test with real volume. Free tiers are enough to validate the integration works.
- Monitor. Continue measuring slippage and sandwich incidence after the change.
Try BoltTx for Sandwich Protection
If you want native Anti-MEV without evaluating searcher economies or batch-auction implementations, BoltTx is one URL change away:
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Sign up for the free tier and run side-by-side benchmarks against whatever path you use today. If your sandwich exposure drops measurably, you have your answer.
FAQ
Does Solana have public mempools? Not in the traditional sense. Transactions go to the next-scheduled validator. But the exposure surface still exists — through RPC-side observation and pre-confirmation visibility — which is what Anti-MEV solutions address.
Is Anti-MEV the same as front-running protection? Front-running is one form of MEV. Anti-MEV protection covers front-running, sandwiching, and back-running.
What's the difference between MEV-blocker and a private RPC? MEV-blocker uses an economic accountability layer (refunds users if MEV is extracted). A private RPC just doesn't expose the transaction in the first place. Both work; the latter has lower coordination overhead.
Can I add Anti-MEV protection to my existing Helius / QuickNode integration? Helius and QuickNode both have their own MEV-protected offerings, typically packaged as separate products that require opting in. BoltTx routes everything with Anti-MEV by default, no separate path needed.
Does Anti-MEV cost extra? Depends on the provider. With BoltTx, it's bundled into the default tip-based pricing — there's no separate "Anti-MEV fee."