If you have read about sandwich attacks, you already know the basic problem. Your swap sits briefly in a public queue before a validator includes it, and a bot can see it there and trade around it to its own advantage, at your expense. One of the most common defenses offered today is something called an MEV protected RPC endpoint, sometimes marketed as a private transaction relay. This article explains what that actually is, how it changes what happens to your transaction, and where its limits are.
What your wallet normally does with a transaction
When you swap or send tokens, your wallet does not talk to the blockchain directly. It sends your signed transaction to an RPC endpoint, a server that relays it into the network. By default, that transaction usually passes through a public mempool, a waiting area that many parties, including specialized bots, can read before the transaction is confirmed. That visibility is what makes front running and sandwich attacks possible in the first place. For more on what that surveillance actually exposes, see our article on RPC privacy.
What a private relay changes
An MEV protected RPC does not change what your transaction does. It changes the path it takes to get into a block. Instead of broadcasting your transaction to the open public mempool, the RPC provider sends it through a private channel, often directly to one or more block builders it has a relationship with. Because the transaction is not visible in the public queue, a sandwich bot has nothing to react to before your trade lands. In effect, you are trading visibility for privacy during the brief window between signing and confirmation.
Some RPC providers offer this as a built in feature rather than a separate product. As one example, QuickNode has described MEV protection as available for Base endpoints, and automatically enabled by default on its paid plans, routing transactions through a private relay network rather than the open mempool. Other infrastructure providers have offered similar private builder routing for Base at various points. Because this space moves quickly and provider offerings change, check a given provider's current documentation rather than relying on any single list of who supports what today.
How you would actually use one
In most cases, you do not interact with an MEV protected RPC directly. It lives one layer below your wallet. A few paths exist:
- Some wallets let you add a custom RPC endpoint in their network settings. If your RPC provider gives you an MEV protected URL for Base, you can paste that in place of the default public endpoint.
- Some wallet apps or extensions have a built in toggle for private transaction routing, which quietly swaps the RPC used for sending transactions without you managing a URL yourself.
- Some dApps or aggregators route certain transaction types through a protected relay automatically, without exposing any setting to you at all.
If you are technical enough to add a custom RPC, treat the URL the same way you would treat any other configuration value. Only paste one you got directly from a provider's official documentation, never one sent to you in a message or comment, since a malicious RPC endpoint could misreport balances or manipulate what you sign.
What it does not do
A private relay is not a guarantee, and it is worth being clear about its limits.
First, it only protects the transaction sent through it. If your wallet still broadcasts other transactions through the regular public path, those remain just as exposed as before.
Second, sending a transaction privately does not guarantee it gets included quickly, or at all, through that path. If the private relay's builders do not include your transaction in a block for some reason, some providers will not automatically fall back to the public mempool, meaning the transaction can simply stall until you intervene. That tradeoff is worth understanding before you rely on one for anything time sensitive.
Third, it addresses one category of risk, transactions becoming visible before confirmation. It does nothing about a bad trade, a malicious contract, or an approval you should not have signed. It is a defense against being front run, not a general safety net.
Fourth, "private" in this context means not broadcast to the public mempool. It does not mean anonymous. The builder or relay operator you are routing through can typically still see the transaction content, and the transaction itself becomes fully public the moment it is confirmed on chain, like any other.
Is this something every Base user needs
For a routine, modest sized swap on a liquid pair, the amount a sandwich bot could realistically extract is often small, and many people simply accept that as a minor cost rather than seeking out private routing. For larger trades, or trades on thinner liquidity where price impact is more sensitive to being front run, an MEV protected endpoint is a reasonable precaution if your wallet or provider makes it easy to use. It is not something you need to chase down for every transaction, and it should not be treated as a reason to skip the more basic protections, like checking slippage settings and understanding price impact before you confirm a swap.
Bottom line
MEV protected RPC endpoints work by keeping your transaction out of the public queue until it is already in a block, removing the window a sandwich bot would otherwise use. They are a useful, narrow tool against one specific kind of extraction, not a replacement for understanding how swaps, slippage, and approvals work. If you want to use one, get the endpoint directly from your RPC provider's own documentation, confirm it currently supports Base, and understand that a transaction routed this way can still fail to land if the private builder does not include it.