"Use a MEV relayer" is common advice for anyone running a bot on Solana. What that actually means is much less commonly explained, and the term gets used for at least three different things.
If you are about to route production traffic through one, it is worth knowing which of those three you are buying.
First: What Is Actually At Risk on Solana
Solana has no public mempool. That single fact changes the threat model compared to Ethereum, and a lot of MEV advice gets copied over without adjusting for it.
On a chain with a public mempool, your pending transaction sits in a shared pool where anyone can read it. Bots watch that pool, spot a profitable swap, and submit their own transactions around yours. That is a sandwich attack, and the exposure window is the entire time you sit in the mempool.
On Solana there is no such pool. Your transaction goes from your RPC toward the validator scheduled to produce the next blocks. So where does the exposure come from?
Two places, and they are worth separating:
Your submission path. Every hop between your process and a block producer is a party that can see your transaction bytes. Not a public pool — specific intermediaries. If any of them runs a strategy of their own, or sells order flow, your intent is visible before it lands.
The block producer itself. Validators have ordering power within the block they produce. They see everything they are about to include and choose the sequence.
★A relayer can do something about the first. Nothing can fully eliminate the second.★ Any vendor claiming otherwise is overselling.
If you already know which kind you need, a free BoltTx key is one line to benchmark against.
The Three Things Called "MEV Relayer"
1. A private submission path
The transaction goes from you to a block producer without passing through parties that would inspect it. No shared pool, no order flow sold, minimal intermediaries.
What it protects against: front-running and sandwiching by anyone who would otherwise see your transaction in transit.
What it does not: validator-side ordering.
This is the most common meaning, and for most trading workloads it is the one that matters.
2. Bundle-based submission
Several transactions submitted as an atomic group — all land together in the same block, or none do. Inclusion is competed for with a tip.
What it is for: multi-leg strategies where partial execution is worse than no execution. A two-hop arbitrage that fills one leg and misses the other leaves you holding an unwanted position.
What it costs: an auction you may lose, plus complexity you may not need. If your strategy is a single swap, bundles add machinery without adding safety.
3. Ordering guarantees
Some services promise position within a block. Read the wording carefully. ★Ordering inside a block is ultimately the block producer's decision★ — a service can influence it, not guarantee it, unless it is the producer.
How to Tell Which One You Need
A short decision path:
Single-transaction strategies — a swap, a snipe, a liquidation with one instruction set. You want a private submission path. Bundles solve a problem you do not have.
Multi-leg atomic strategies — arbitrage across two pools, anything where partial fills are a loss. Bundles are the mechanism built for this.
High-frequency anything — the submission path dominates. Every hop is latency, and the transaction is exposed at each one until it lands.
Reads, indexing, getBalance display — none of this applies. There is nothing to protect.
The Question Most Comparisons Skip
Vendors publish latency numbers. Almost nobody publishes the thing that actually decides your outcome: ★what happens to your transaction between "accepted" and "in a block."★
Worth asking directly:
Who sees the transaction between submission and inclusion? Not "is it private" — the specific list of parties. A vendor that cannot answer this concretely is selling you a slogan and calling it an architecture.
Is order flow sold or shared with anyone? This should be a one-word answer.
Does the service hold custody at any point? For a submission path the answer should be no. You sign locally; the relayer moves bytes.
What happens when the network is congested? This is where paths diverge. Under light load everything performs the same.
What is the tip model, and what is it competing for? A tip competing for inclusion is different from a fee for access. Make sure you know which one you are paying.
Measuring Whether It Works
MEV protection is unusual in that success is invisible. Nothing happens. That makes it easy to pay for something that is not working.
Two things you can actually measure:
Realised slippage versus quoted. Track the difference between the price you were quoted and the price you got, on the same pairs and sizes over time. Sandwiching shows up here as a persistent negative gap on profitable-looking swaps.
// Log both sides of every fill, then compare distributions
// before and after a routing change. One trade tells you nothing;
// a few hundred tells you whether the gap moved.
log({
pair,
sizeIn,
quotedOut, // what the quote said
actualOut, // what you received
slippageBps: Math.round(((quotedOut - actualOut) / quotedOut) * 10_000),
route, // which path you submitted through
});
Landing rate split by network condition. A protection path that fails to land is worse than no protection — you lose the trade instead of losing a few basis points. Bucket by congestion and compare:
const recent = await connection.getRecentPrioritizationFees();
const fees = recent.map((r) => r.prioritizationFee).sort((a, b) => a - b);
const medianFee = fees[Math.floor(fees.length / 2)] ?? 0;
metrics.record("submission", {
landed: didItLand,
route,
bucket: medianFee > 50_000 ? "busy" : "calm",
});
★Run both for at least a week across both conditions.★ A single congested afternoon proves nothing either way.
The Trade-Off Behind Every Relayer Pitch
Protection and speed pull against each other.
A path with fewer intermediaries is more private and usually faster. But a path that routes around the normal flow to achieve privacy can add hops, and every hop is time. A bundle that loses its auction does not land at all.
For a strategy where the opportunity closes in a slot or two, ★an unlanded transaction and a sandwiched transaction are both losses★ — and the unlanded one is usually the larger of the two, because you also gave up the position.
This is why "most protected" is the wrong target. The target is landing reliably through a path that does not leak your intent, which is a different optimisation.
What Landing Looks Like
Real transactions through our delivery nodes: median confirmation 336ms — under one slot.
If a protected path lands materially slower than this, the protection is costing you more than it saves.
Where BoltTx Fits
We route transaction submission, and that is the whole product. Not indexing, not parsed history, not NFT metadata.
Submissions go through our own delivery nodes in four regions with stake-weighted routing. There is no public mempool exposure, so a transaction is not observable in transit before it lands. You sign locally — we never hold funds, never sign, and never modify transaction contents.
On the tip: you include it in the transaction itself, paid on chain from your own wallet. If the transaction reverts, the tip reverts with it, because that is how Solana handles atomic transactions. You pay only on transactions that reach the chain.
Get a free API key. No monthly fee:
// Pick the region closest to where your bot runs
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
Then run the slippage and landing-rate comparison above against whatever you use now. That comparison is worth more than any vendor's numbers, including ours.
FAQ
What is a MEV relayer on Solana? A service that carries your signed transaction toward a block producer through a path that limits who can observe it in transit. On Solana there is no public mempool, so the exposure being addressed is intermediaries on the submission path rather than a shared pending pool.
Does Solana have MEV if there is no mempool? Yes, but in different forms. Without a public pool, the exposure comes from parties on your submission path and from the block producer's ordering power within the block it builds. It is a narrower attack surface than a mempool chain, not an absent one.
What is the difference between a MEV relayer and a bundle service? A relayer carries a single transaction through a private path. A bundle service submits several transactions as an atomic group that all land together or not at all, competing for inclusion with a tip. Bundles are for multi-leg strategies; a single swap does not need them.
Can a relayer guarantee I never get sandwiched? It can remove exposure on the submission path. It cannot control the block producer's ordering decisions within its own block. Any service promising complete elimination is describing something it does not control.
Do I need MEV protection for a single swap? If the swap is large enough to be worth sandwiching, a private submission path is worth having. If you are moving small amounts or interacting with illiquid pairs where there is no profitable sandwich, it changes little.
How do I know if I am being sandwiched? Compare quoted output to realised output across many trades on the same pairs and sizes. A persistent negative gap concentrated on your most profitable-looking swaps is the signature. One bad fill is noise; a distribution shift is evidence.
Does MEV protection slow down my transactions? It depends on the path. Fewer intermediaries can be both more private and faster. A path that adds hops to achieve privacy costs latency, and a bundle that loses its auction never lands. Measure landing rate alongside protection rather than assuming a trade-off in either direction.
What is a bundler in crypto? A service that groups multiple transactions for atomic execution — they are included together in one block or not at all. On Solana this is used for multi-leg arbitrage and any strategy where a partial fill is worse than no fill.
Should I use a MEV relayer for liquidations? Liquidations are competitive and profitable, which makes them a target. A private submission path helps. But landing speed matters at least as much, since a protected transaction that arrives after someone else's does not earn anything.
Is MEV protection worth it for a low-volume bot? Do the arithmetic on your own fills before deciding. If your realised slippage is already close to quoted, there is little to recover. Protection matters in proportion to how much value your transactions visibly carry.
Do I need a relayer if I only trade small amounts? Probably not. Sandwiching is only profitable above a size threshold that depends on pool depth. Below it, there is little value for an attacker to extract from your transaction.
What happens to my transaction if a relayer goes down? That depends entirely on whether you built a fallback. A relayer is a single point of failure in your send path, so treat an unreachable one as a routing decision rather than an outage: fall back to your normal submission path and accept the reduced protection for that transaction.
Can I combine a relayer with priority fees? Yes, and you generally should. They address different things: the relayer limits who observes your transaction, the priority fee affects scheduling once a validator has it.
How is a relayer different from a regular RPC? A general-purpose RPC serves reads, history, subscriptions, and sends from the same infrastructure. A relayer carries signed transactions and nothing else, which is what lets its routing and stake weight exist for one purpose.
Will a relayer protect me from a validator reordering my transaction? No. Ordering within a block is the block producer's decision. A relayer limits exposure on the path toward that producer, which is a different part of the problem.