Skip to content
Last updated 2026-11-05

MEV Protection Tutorial

This page explains front-running and sandwich attacks and the settings that make your swaps a less attractive target, so a routine trade does not hand value to a stranger.

A sandwich attack runs in three moves. Someone sees your buy before it settles, buys the same asset ahead of you to push the price up, lets your trade fill at the worse price, then sells into the move. You get the asset you asked for and pay more than the screen implied. Front-running is the same idea without the second half: someone acts on your pending transaction before you do.

Status on Bitgold

Bitgold does not advertise a MEV-protection service, a private transaction relay, or an ordering guarantee. The measures below reduce exposure. None of them removes it.

Who this is for

Anyone swapping tokens through a DApp with their own wallet. If you only send and receive BTG, the slippage section still applies to any swap you make later.

Before you start

  • A wallet on Bitgold mainnet, and a DEX you chose from a source you trust rather than a link.
  • A rough idea of your trade size relative to the pool you are using.
  • The explorer, so you can check what actually settled.

Steps

1. Set slippage on purpose

Slippage tolerance is the worst price you agree to accept. A wide tolerance is the room a sandwich uses to take value from you. Set the smallest tolerance that still lets the trade fill, and raise it only when you understand why the trade failed.

2. Split the order

Two or three smaller swaps across separate confirmations make a worse target for a sandwich than one large swap. Each fill also gives you a real price to compare against the quote you were shown.

3. Check pool depth before size

Open the pool and read its liquidity and the price impact the DEX quotes. If your order is large relative to the pool, that impact already includes your own trade pushing the price. Split the order or wait rather than accepting it.

4. Use an RPC you can name

An endpoint you cannot identify can delay or hold what it forwards, which is exactly the window a searcher needs. Use a Bitgold endpoint or a provider you chose deliberately, and confirm the result on the explorer.

5. Read minimum received, not expected

The confirmation screen shows both figures. Minimum received is the floor the contract enforces; the expected amount is an estimate. If the floor sits far below the quote, the trade is priced for someone else's gain.

Verify it worked

  • The explorer shows the swap settled at a price inside the range you set.
  • The amount received matches the minimum or does better.
  • No second transfer left your wallet alongside the swap.
  • The pool's price after the swap is close to the quote you accepted.

Troubleshooting

Problem What to do
Every swap fails with a slippage error The tolerance is below normal movement for that pool. Raise it slightly, or split the order.
The swap filled far below the quoted price Your tolerance was wide. Check the pool depth and lower the tolerance before the next trade.
Another wallet bought the asset moments before your fill That is the shape of a sandwich. Reduce size and tolerance next time.
A "MEV protection" toggle appears in an app you do not recognize Verify the app before enabling anything. No Bitgold feature carries that name.
The transaction sits unconfirmed for minutes The endpoint may be holding it. Switch to a known Bitgold RPC and check the explorer.

Next steps

Self-check

  • I set slippage rather than accepting the default.
  • I checked the pool's depth before choosing the size.
  • I read the minimum received amount on the confirmation screen.
  • I can name the RPC endpoint my wallet uses.