# MEV protection
When you trade on a decentralized exchange, your transaction is briefly visible to network participants before it's confirmed on-chain. Specialized bots — known as **MEV searchers** — can exploit that visibility to profit at your expense, most commonly by sandwiching your trade between their own buy and sell orders to push the price against you.
goodcryptoX routes every swap through transaction paths that protect against this kind of harmful MEV. The exact mechanism depends on the chain you're trading on.
What is MEV, exactly?
**MEV** stands for **Maximal Extractable Value** — the profit that block producers and searchers can extract by reordering, inserting, or omitting transactions in a block. On AMM DEXs, the three forms that matter most for traders are:
* **Sandwich attacks** — a searcher spots your pending swap, places a buy order in front of it (pushing the price up), lets your order execute at the worse price, then sells back at the new higher price. You pay the difference, the searcher pockets it.
* **Frontrunning** — a searcher copies your transaction with a higher fee to execute first, capturing an opportunity you would have captured yourself.
* **Backrunning** — a searcher places a transaction *immediately after* yours to capture arbitrage opportunities your trade creates (e.g. a price imbalance between two DEXs). Unlike sandwiching, backrunning doesn't worsen your execution price — it's generally considered "productive" MEV.
Sandwich attacks are the form that costs traders the most, and they're the main thing MEV protection is designed to prevent.
### **EVM chains: Ethereum, Base, Arbitrum, BNB Chain**
On EVM chains, goodcryptoX submits every swap through **ERC-4337 bundlers** with private transaction routing — **Alchemy** on Ethereum, Base, and Arbitrum, and **Pimlico** on BNB Chain.
When you sign a swap, your transaction is sent to the bundler through a private channel — not the public mempool. The bundler packages it and forwards it directly to validators or block builders for inclusion. Because no searcher ever sees the transaction before it lands on-chain, there's no window during which a sandwich or frontrun can be inserted around it.
This protection is automatic and applies to every order routed through goodcryptoX on these four chains — manual swaps, bot trades, and triggered orders alike. You don't need to enable anything.
### **Solana**
Solana works differently from EVM chains: there's no traditional public mempool. Transactions are streamed directly to the current block leader. This eliminates classic Ethereum-style frontrunning, but a different MEV surface still exists — searchers run their own infrastructure to observe pending transactions through RPC nodes and submit competing transactions via Jito bundles.
By default, goodcryptoX broadcasts Solana transactions using **priority fees** — fast and inexpensive, but not MEV-protected. For larger swaps where MEV exposure matters, you can switch the broadcast mode to **Jito**:
1. Open DEX order form
2. Click the ⚙️ settings cogwheel
3. Under **Broadcast mode**, switch from **Priority fees** to **Jito**
When you broadcast via Jito, your transaction is included in a **Jito bundle** — a group of transactions that validators must execute atomically, in the exact order specified, or not at all. Because the bundle locks transaction ordering on-chain, no searcher can insert their own swaps around yours to sandwich you.
> **When does MEV protection actually matter?**
>
> Sandwich attacks are only profitable on trades large enough to move the price meaningfully — the searcher needs slippage to extract value from. For small, frequent orders (like the individual trades placed by a DCA bot or a grid bot), the economics don't work for attackers, and these orders are rarely targeted. The default priority-fee mode is usually fine for them.
>
> Consider switching to Jito when you're sending **large one-off swaps** on Solana — especially on volatile or low-liquidity tokens where slippage is wider and the attack surface bigger.
#### **A note on "productive MEV" on Solana**
Some MEV is actually beneficial — particularly **backrunning arbitrage**, where a searcher rebalances prices across DEXs immediately after your trade executes. This doesn't worsen your execution (your trade already filled); it just captures the small price imbalance your swap creates.
On Solana, goodcryptoX uses **Helius Sender** to route transactions, and we've opted into the Helius backrun rebate program. Here's what that means for you:
* Your swap always executes first — searchers can only act *after* it lands on-chain, and only post-trade backruns are permitted.
* The searchers participating in the auction are vetted and KYC'd by Helius; no frontrunning or sandwiching is allowed.
* When your trade creates an arbitrage opportunity, the captured value is split 50/50 between Helius and goodcryptoX.
The goodcryptoX share is added to the same pool we use for our DEX swap fee [revenue sharing](/ecosystem/revenue-sharing.md) and [GOOD token](/good-token/summary.md) buyback & [burn](/good-token/burn.md) programs — so it flows back to the ecosystem rather than going to external extractors.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.goodcrypto.app/dex-trading-spot/orders-mechanics/mev-protection.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.