MEV Protection: How to avoid front-running and sandwiching bots

In the world of DeFi, transaction anxiety is a genuine concern—particularly when it involves high-value transactions. Many traders have experienced the unsettling feeling of uncertainty as they await the settlement of their transactions. There’s a hidden maze of complexity happening between the moments your transaction is sent to the mempool and when it settles on-chain that many people rarely think about. 

One of the significant factors contributing to transactions not settling as expected is slippage caused by MEV (Maximum Extractable Value) front-running and sandwiching bots. To counter the negative externalities of MEV front-running and sandwiching, traders can send their transactions through a Protect RPC Endpoint. These specialized endpoints offer a layer of protection against MEV bots by bypassing the public mempool.

In this blog, we will explore how MEV bots cause slippage, when employing a Protect RPC endpoints makes sense, and a step-by-step guide on how to connect your Metamask wallet to a Protect RPC Endpoint. 

Understanding MEV Bots: How Slippage Can Affect Your Trades

Slippage is a negative change to the effective price of a token you are purchasing (i.e. you thought you were going to receive 5 ETH but instead you only received 3.5 ETH). While slippage can happen as a consequence of normal changes to market conditions, in some cases an external actor with access to superior information – and the knowledge and capabilities to act –  intentionally moves the price in a way that is favorable to them and unfavorable to you. 

To better understand this concept, let's follow Alice's journey into the world of DeFi. Alice diligently researched and found a decentralized exchange (DEX) to make her trade. She submitted her transaction without any issues and now awaits confirmation on the blockchain.

However, when Alice's transaction finally settles, she realizes that she received fewer tokens than she expected. She wonders where she went wrong.

It turns out, Alice's transaction was "sandwiched." This occurs when automated systems, commonly known as MEV bots, strategically moved the price of a token by placing transactions just before and after Alice's trade. These bots purchased the token – moving the price up – just before Alice's transaction went through (so she received fewer tokens than she expected) and then sold those tokens immediately after— capturing a small but far from negligible profit. 

As a result, Alice experienced slippage between the moment she submitted her transaction and when it was confirmed on the blockchain. To avoid falling victim to sandwich attacks and similar MEV tactics, Alice could have submitted her transaction through a Protect RPC Endpoint. This method protects against front-running and sandwiching bots, providing an additional layer of security and ensuring a more fair and predictable outcome for her trades.

What are Protect RPC Endpoints?

Protect RPC endpoints facilitate sending private transactions directly to a block builder to be included on-chain. As a result, these transactions completely bypass the public mempool.

In a typical web3 wallet, such as MetaMask, your transaction is broadcast to public mempools to be picked up by a block builder and put on-chain via an RPC endpoint that is setup by default. This ensures high execution speed as there is maximum visibility from the ecosystem. But, this also means maximum exposure to searcher bots. For small day-to-day transactions this default works well. For transactions that result in high liquidity events, however, this isn’t ideal.

Luckily, many crypto wallets allow you to change the destination location for your transaction. One location it can be changed to is Protect RPC endpoints that lead to private mempools. These Protect RPC endpoints are controlled by an entity - typically a block builder or an aggregator - and only they can see these transactions. Unless that entity allows searchers to see their private mempool your transaction remains hidden until they reveal it (typically once it lands on-chain, but this depends on the entity).

Note: Because you are routing your transactions to a private mempool, always be sure to do your research when connecting to a new RPC Endpoint and make sure you trust the entity you are sending your transaction to. 

Recommended Use Cases for a Protect RPC Endpoint

Protect RPC Endpoints are great to use when:

• Your transaction will result in a high liquidity event;
• Your transaction needs to remain private before landing on-chain.

When not to use a Protect RPC Endpoint

Because your transaction is being routed to a private mempool, settlement on-chain may take longer than expected. This is because you must wait until the specific block builder your Protect RPC Endpoint is connected to lands a block on-chain. For any transaction in which execution speed is critical, we do not recommend using Protect RPC endpoints.

Protect RPC Endpoint Aggregators mitigate some of these speed issues by sending to multiple block builders, however, this also results in less control over how many entities now have visibility into your transaction. 

How to Connect to a Protect RPC Endpoint

Follow my step-by-step guide on Youtube where I'll walk you through how to connect your Metamask wallet to a Protect RPC Endpoint. These steps will be roughly the same across different wallets and Protect RPC Endpoints. If you have any questions, be sure to join our Discord to chat.

For more information on the Blocknative Protect RPC Endpoint, check out our docs: https://docs.blocknative.com/blocknative-protect/protect-rpc-endpoint