I still remember the first time I watched one of my own swaps get sandwiched. I had set a slippage tolerance I thought was reasonable, the trade went through, and when I looked at the block afterward there was a buy right in front of me and a sell right behind me, both from the same address, both in the same block. The price I paid was the price they manufactured. My slippage setting was not protecting me from the market. It was telling the bot exactly how much room it had to work with.
That is the whole game with public-mempool trading. When you send a swap to a normal RPC endpoint, it sits in the pending pool for a moment before it lands in a block, and during that moment anyone can see it. Searchers run software that scans that pool, spots a swap large enough to move the price, and wraps it with their own orders. You buy high because they bought right before you, and the block builder pockets a cut for including their bundle. You are paying a tax you never agreed to, and the size of the tax scales with how much your trade moves the pool.
Where the leak actually is
The mistake most people make is thinking slippage tolerance is a defense. It is not. It is a ceiling on how badly you are willing to be robbed. A bot looks at your transaction, sees you will tolerate say one or two percent of adverse movement, and pushes the price right up to that line before letting your trade execute. Tighten the tolerance and you just trade one problem for another, because now your swap reverts when the market moves for legitimate reasons and you eat the gas anyway.
The real leak is that your intent to trade became public before it settled. Everything downstream follows from that. So the fix is not a smarter slippage number. The fix is to never broadcast the trade to the open pool in the first place. There are roughly three ways to do that, and they stack.
Protected RPC endpoints
The simplest change, and the one that covers most people, is to swap out the RPC endpoint your wallet talks to. A protected or private RPC does not gossip your transaction to the public mempool. Instead it forwards the transaction directly to block builders through a private channel, so searchers scanning the public pool never see it coming. Some of these endpoints go further and share a slice of any MEV they can still capture back to you as a rebate, though I would treat rebates as a nice-to-have rather than the reason to switch.
The practical move is to add a protected endpoint as a custom network in your wallet and point your DEX activity at it. On most chains this is a two-minute change in wallet settings. The trade-off is trust and latency. You are now routing through one provider's infrastructure, so pick one with a track record, and understand that private submission can occasionally take an extra block or two to land because it is not being screamed to every node at once. For meaningful-size trades that delay is a rounding error next to the spread you were donating.
A few things worth checking before you rely on one:
- Does it actually withhold your transaction from the public mempool, or just claim to. Reputable ones publish how their flow works.
- Does it protect against front-running and sandwiching specifically, not only revert protection. Those are different features.
- What happens to a transaction it cannot include. You want it to fail cleanly, not sit forever or leak into the public pool as a fallback.
- Is it available on the chain you trade on. Coverage varies a lot by network.
Private order flow and batch auctions
Protected RPCs hide your trade from the crowd but still send it as a single order that a builder executes at some price. The next tier changes the shape of the order itself. Instead of you submitting a swap that runs against a specific pool at a specific moment, you submit an intent, meaning what you want to end up holding, and a network of solvers competes to fill it at the best price they can find. The winning solver only gets paid if they beat the alternatives, which flips the incentive. The party routing your trade is now working to get you a better price rather than a worse one.
Batch-auction venues take this further by settling many orders together at a uniform clearing price. When your trade clears in the same batch as everyone else at the same price, there is no ordering to exploit. A sandwich needs to be in front of and behind a specific victim in a specific sequence. Remove the sequence and you remove the attack. This is the cleanest structural defense I know of, because it does not rely on hiding you. It removes the thing the bot was exploiting.
The trade-off is that batch settlement is not instantaneous and not universal. You wait for the batch, and coverage is limited to the token pairs and chains the venue supports. For a large spot swap where you care more about execution quality than about landing in the very next block, that is usually the right call. For time-sensitive activity it may not be.
A setup that actually holds
Here is how I think about routing a trade depending on what it is. Small swaps where the notional is too tiny to be worth a bot's gas, honestly, do whatever is convenient, because you are below the threshold where anyone bothers. The protection matters once your order is large enough to move the pool.
For a meaningful-size spot swap, I default to a batch-auction or solver-based venue and let the competition work for me. When that is not available for the pair, I fall back to a protected RPC and submit through that instead of my default endpoint. Either way I keep slippage tolerance as tight as the market realistically allows rather than leaving it wide as a comfort setting, because a wide tolerance is a gift to anyone who does slip past the protection. And I split genuinely large orders into pieces rather than sending one swap that moves the price by several percent, because a huge single order is both the most profitable thing to sandwich and the most expensive to fill even honestly.
One failure mode to watch for. People set up a protected RPC, feel safe, then approve and execute a trade from a dapp's own embedded interface that quietly uses its default public endpoint, and the protection never applied. The protection lives at the point where the transaction is broadcast, so it only helps if that specific transaction went out through the protected path. Check what endpoint actually signed and sent, not what you configured somewhere else.
None of this makes you invisible. A determined searcher with a relationship to a builder can still see private flow in some setups, and no routing choice fixes a trade that is simply too big for the liquidity that exists. But moving your order out of the public pool and, where you can, into a batch where sequence does not matter takes you from being the easiest target in the block to being not worth the trouble. When we route non-custodial execution at Blockcircle, that ordering question is exactly the kind of thing we care about, because the fill you actually get is the only number that ends up mattering. Start with the RPC swap this week, add a batch venue for your larger trades, and check the endpoint every time before you sign.