Protected paths.Less sandwich risk.
Solana has no public mempool, but sandwich attacks still happen through private validator pools, searcher bundles, and RPC operators with transaction visibility. This page explains that attack surface and where protected submission paths can help reduce exposure.
Sandwich attacks on Solana, explained.
Solana does not have a public mempool like Ethereum. That does not make it MEV-free, it makes the attack surface different. Searchers observe transactions through private validator pools, RPC operators, and Jito bundles, then try to place trades around user flow.
Searchers watch
Some validators run private transaction pools. Some RPC providers forward user transactions to searchers before inclusion. Some front-end bots inspect user flows.
Buy before you
A searcher sees your pending swap and places a buy before yours, usually via a Jito bundle, pushing the price up before you land.
At a worse price
Your transaction executes at the inflated price. If your slippage tolerance is too loose, you silently absorb the loss.
Sell after you
The searcher sells immediately after yours in the same bundle and pockets the spread. The attack surface is different from Ethereum, but the extraction is real.
Submit through protected paths.
The point is not to promise perfect protection. The point is to reduce unnecessary visibility, reduce avoidable ordering risk, and use cleaner submission paths than a standard single-endpoint RPC flow.
Protected submission paths
One way to reduce exposure is to submit through paths that avoid the RPC operators and private transaction pools where searchers may watch.
Bundle-aware ordering
When bundles are part of the flow, protective ordering flags can reduce insertion risk inside the same bundle where supported.
All or nothing
Bundle semantics are atomic: transactions execute completely or fail entirely. That helps avoid partial states, but it is not a blanket MEV guarantee.
Isolated submission flow
Keeping user flow separate from third-party searcher activity is part of the general goal: reduce visibility and reduce opportunities for ordering abuse.
Closing the RPC-layer vector
The most common retail-side MEV vector is an RPC operator forwarding a pending transaction to a searcher. Private send ships your signed transaction straight to the slot leader instead — RPC operators are not on the path, so there's nothing for them to leak. One flag on /v1/send, no SDK swap.
Two submission paths. Different tradeoffs.
This comparison is directional, not absolute. The practical question is whether your flow benefits from lower visibility and bundle-aware submission versus a standard RPC send path.
| Property | Standard RPC | Venum |
|---|---|---|
| Transaction visibility | May pass through operators with more visibility | Can be reduced through protected paths |
| Sandwich exposure | Can be higher on large or loose-slippage swaps | Can be lower |
| Submission method | Single endpoint | Protected or bundle-aware paths |
| Bundle protection | None by default | Protective flags where supported |
| Confirmation | Standard polling is common | Realtime lifecycle feedback can be added |
| Integration work | You usually stitch it together | Hosted path available |
Learn the attack surface, then choose your path.
If you want a simpler protected submission path in practice, Venum exposes one as part of the execution stack.