What is MEV protection? Ethereum, Base, Arbitrum, Arc

Your transaction can be profitable for someone else before it even executes, and it doesn’t have to fail to cost you money. A bot can profit from your swap before it executes, sandwich your trade to squeeze out a profit or exploit transaction ordering to capture value that could have been yours. This is Maximal Extractable Value (MEV), and as onchain activity grows, understanding how to protect your transactions becomes increasingly important.

In this guide, we’ll break down how MEV works across Ethereum, Base, Arbitrum and Arc, walk through how to configure MEV Protection and Optimized Submission, and show you how to route transactions privately, submit them through RPC endpoints and strengthen execution safeguards to reduce risk.

Short answer: On Ethereum and BNB Smart Chain, which have a public mempool, enable MEV Protection. On Base, Arbitrum and Arc, transactions are not broadcast to a public mempool, so use Optimized Submission for delivery and inclusion, and keep slippage limits and deadlines in your contracts.

What is MEV?

Maximal Extractable Value (MEV) is the value a participant can extract by changing which transactions get included in a block, the order in which they execute or how they interact with one another. Searchers, block builders and sequencers capture it through strategies such as front-running, back-running, sandwich attacks, arbitrage and liquidations.

Already familiar with MEV? Jump straight to the “MEV Protection on Ethereum” section below to choose how to protect against MEV attacks and route your transactions privately.

To understand MEV, let’s start with how a blockchain transaction works.

When a user swaps tokens on a decentralized exchange (DEX), the transaction specifies details such as the tokens being exchanged, the amount and the minimum acceptable output. The transaction is submitted through an RPC endpoint and enters the network’s transaction-processing pipeline. Depending on the network, it may become visible to searchers before execution in a public mempool. A block producer or sequencer then determines transaction inclusion and ordering according to the network’s rules.

That ordering creates an opportunity.

If another participant can identify a profitable outcome from a pending transaction and influence the order of execution, the participant may capture value at the original user’s expense.

MEV strategies generally fall into several categories.

Types of MEV strategies

Front-running: Front-running occurs when a participant places a transaction ahead of another transaction to benefit from its expected effect. For example, a searcher may observe a pending transaction that will change an asset’s price and attempt to trade before it executes. The searcher profits if the resulting price movement creates a favorable exit.

In April 2023, a rogue validator front-ran the back-run transactions of MEV sandwich bots and took about $25 million. The victims were bots, not ordinary users.

5/ In total, ~$25m was taken making this one of the largest MEV Bot exploits we’ve seen. pic.twitter.com/LhzMluY7H0

— CertiK Alert (@CertiKAlert) April 3, 2023

Back-running: Back-running places a transaction immediately after another transaction to capture an opportunity created by its execution. For example, a large swap may cause a temporary price difference between two liquidity pools. A searcher can execute an arbitrage trade immediately afterward to capture the difference. Back-running can support market efficiency, especially when used for arbitrage. Its effect depends on the strategy and the market conditions.

In July 2026, Arkham reported a trader who swapped $2 million of ETH for LIT and received only $14.1K, because the 0x router sent the order through a low-liquidity pool. Titan Builder’s MEV bot back-ran the trade and profited about $2 million.

HE SWAPPED $2 MILLION OF ETH FOR LIT – AND LOST IT ALL

Trader 0xfF8 withdrew $2M of ETH from Binance, then swapped his entire stack to LIT. He received $14.1K of LIT.

He lost 99% of his funds because the 0x router sent his order through a low liquidity AVAIL pool. Titan… pic.twitter.com/OQEkrnuaap

— Arkham (@arkham) July 6, 2026

Sandwich attacks: A sandwich attack targets a pending trade, often on a decentralized exchange. The user’s transaction is effectively sandwiched between the searcher’s two transactions. The attack’s profitability depends on liquidity, price impact, fees, gas costs, transaction ordering and the user’s slippage settings.

Arkham flagged a bot that took a $12 million flash loan to sandwich a user swapping $5K of SHFL to WETH with roughly 2% slippage. The bot made less than $20 after costs, which shows how a user’s slippage setting is what makes the attack possible.

An MEV Bot just took out a $12 Million flashloan to make less than $20 in profit.

It sandwiched a user trying to swap $5K of SHFL to WETH using around 2% slippage.

Unlucky. pic.twitter.com/I1llVBN4fH

— Arkham (@arkham) September 5, 2024

Arbitrage: Arbitrage takes advantage of price differences for the same asset across decentralized exchanges or liquidity pools. For example, a token trades at $1.00 on one DEX and $1.03 on another. An arbitrage bot buys the token at the lower price and sells it at the higher price. After accounting for trading fees, gas costs and price impact, the trade may generate a profit. Arbitrage can help bring prices across markets closer together. It is a common source of MEV and does not inherently harm other traders, although competition among searchers can increase network activity.

Liquidations: Lending protocols allow users to borrow assets against collateral. When a position falls below the protocol’s required collateral threshold, it can become eligible for liquidation. Searchers monitor lending positions and submit liquidation transactions when profitable opportunities arise. A successful liquidator may receive a liquidation bonus or discounted collateral, depending on the protocol’s rules. Liquidations help protocols recover outstanding debt and maintain solvency. However, transaction ordering and competition can determine which liquidator captures the opportunity.

Why does MEV matter?

Layer 2 networks increase throughput and lower transaction costs, making blockchain applications practical for more users, assets and transactions. But scaling execution does not automatically eliminate the inefficiencies created by transaction ordering and bot competition.

A June 2025 analysis by Robert Miller of Flashbots, “MEV and the Limits of Scaling”, estimated that classified spam bots consumed 56% of gas on Base and 57% on OP Mainnet across the sampled blocks.

Scaling requires more than processing transactions cheaply. Infrastructure must also support reliable transaction delivery, while application logic protects execution through slippage limits, deadlines and appropriate validation.

Before choosing an MEV protection strategy, evaluate three things:

1. Visibility: Can searchers observe pending transactions?
2. Ordering: How does the sequencer prioritize transactions?
3. Submission: How reliably does the transaction reach the sequencer?

A private RPC endpoint alone does not guarantee MEV protection. The following sections clarify these questions and explain how Chainstack RPC helps reduce MEV exposure across supported networks.

What is Optimized Submission?

Optimized Submission is a Chainstack add-on that routes your signed transactions, sent as eth_sendRawTransaction, through a private, optimized path for faster inclusion. It is available on Arbitrum, Base, Arc and Robinhood Chain Mainnet, where transactions are not broadcast to a public mempool, and it falls back to the standard node route if the private path fails.

It is on by default for new nodes, and on Global Nodes it is available on every plan, including the Developer plan. See the Optimized Submission page on the Chainstack Marketplace or the documentation for details.

The table compares it with Chainstack’s MEV Protection add-on, which covers Ethereum and BNB Smart Chain.

Feature	MEV Protection	Optimized Submission
Networks	Ethereum Mainnet, BNB Smart Chain Mainnet	Arbitrum, Base, Arc and Robinhood Chain Mainnet
Why it exists	Public mempool, so front-running is possible	No public mempool, so the focus is delivery and inclusion
How it works	Sends the transaction only through a private route to block builders	Sends the transaction through a private, optimized submission path
If the private route fails	Returns a JSON-RPC error and does not broadcast publicly	Falls back to the node’s standard route
Node types	Global Nodes, Trader Nodes	Arbitrum and Base: Global Nodes, Trader Nodes. Arc and Robinhood Chain: Global Nodes
Default on a new node	Yes	Yes

How to protect your transactions from MEV on each network

Setup differs by network. Ethereum uses MEV Protection, while Base, Arbitrum and Arc use Optimized Submission.

Ethereum

Ethereum is a Layer 1 blockchain secured by proof-of-stake consensus. When a transaction is submitted through a conventional public RPC endpoint, searchers may observe it before execution and attempt to profit from its expected market impact. For applications that interact with decentralized exchanges, lending protocols and other financial smart contracts, transaction privacy can make a meaningful difference. This is particularly relevant for large swaps, trades with loose slippage limits and time-sensitive DeFi operations.

Chainstack offers MEV Protection for Ethereum Mainnet to help reduce this exposure. Ethereum’s MEV Protection is designed to route transactions privately to help protect them from public-mempool front-running and related MEV strategies.

MEV Protection on Ethereum

Chainstack’s MEV Protection provides an alternative submission path intended to limit this public exposure. However, private routing cannot guarantee favorable execution or eliminate every form of MEV. Applications should continue to enforce slippage tolerances, deadlines and contract-level validation.

To configure MEV Protection for Ethereum Mainnet:

1. Sign in to the Chainstack console.
2. Create a new Ethereum Mainnet node or select an existing one.
3. Open the node’s Add-ons section. MEV Protection is on by default for a new node, so on a freshly deployed node you only need to confirm that the card shows Active. On an existing node, find MEV Protection and enable the add-on.
4. Make sure the add-on is active for the node you’re using. Enabling MEV Protection on one endpoint does not automatically protect transactions sent through a different, unprotected RPC endpoint.

• Chain ID: 1
• Mainnet: https://ethereum-mainnet.core.chainstack.com
• Network name: Ethereum Mainnet

For a complete reference covering supported endpoints, authentication, archive access, WebSocket connectivity and advanced RPC methods, see the Ethereum documentation.

Submit a transaction through MEV Protection

Ethereum uses the standard eth_sendRawTransaction JSON-RPC method to broadcast signed transactions.

const signedTransaction = '0x...'; // your signed, serialized transaction

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    id: 1,
    jsonrpc: '2.0',
    method: 'eth_sendRawTransaction',
    params: [signedTransaction]
  })
};

fetch('https://ethereum-mainnet.core.chainstack.com/<KEY>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

Here, signedTransaction is the serialized hexadecimal transaction produced by your signing process. The RPC request submits it for processing; it does not sign the transaction on your behalf. You don’t need a special transaction format to use Chainstack’s MEV Protection. The key requirement is to submit through the endpoint configured for the service.

Private transaction routing can affect how a pending transaction is propagated and observed. Depending on the service’s routing behavior, a privately submitted transaction might not immediately appear through every public RPC endpoint. Use the Chainstack endpoint and the service’s documented transaction-tracking behavior to monitor its status.

Monitor transaction execution

After submission, use the returned transaction hash to track the transaction lifecycle. Query eth_getTransactionReceipt to check whether it has been included in a block and whether execution succeeded.

For production applications, consider monitoring:

• Submission errors and RPC response times.
• Time to inclusion and transaction confirmation.
• Reverted transactions and nonce mismatches.
• Swap slippage and execution outcomes.

For DEX integrations, enforce an appropriate amountOutMinimum and transaction deadline. Private routing reduces certain transaction-visibility risks, but smart-contract safeguards remain essential.

Base

Base is an Ethereum Layer 2 built on the OP Stack. Its sequencer orders transactions and publishes execution results, while Ethereum provides the settlement and data-availability foundation.

If you want to learn more about Base and its architecture, this blog is worth a read: Base Architecture

Base also introduced Flashblocks, which provide preconfirmation updates at approximately 200-millisecond intervals. These updates can help applications react to pending execution more quickly, although a preconfirmation and final settlement represent different stages of transaction confidence.

Optimized Submission on Base

For production, provision an authenticated endpoint from an infrastructure provider such as Chainstack. Public endpoints are useful for development and initial testing; production systems benefit from measurable throughput, access controls and operational support.

Create a Base Mainnet node in the Chainstack console. During deployment, Optimized Submission is already selected under Add-ons on the last step, and its card shows Included. For an existing node, open its Add-ons tab, select Enable on the Optimized Submission card and complete installation.

Chainstack’s Optimized Submission routes transactions through a private, optimized path. If that path fails, the service falls back to the standard node route. This is different from the fallback behavior of Chainstack’s MEV Protection add-on for Ethereum and BNB Smart Chain.

• Chain ID: 8453
• Mainnet: https://base-mainnet.core.chainstack.com
• Network name: Base Mainnet
• Testnet chain ID: 84532
• Testnet: https://base-sepolia.core.chainstack.com
• Testnet network name: Base Sepolia Testnet
• Currency symbol: ETH

Since Base exposes the standard Ethereum JSON-RPC interface, common methods work exactly as they do on Ethereum. For example, you can retrieve the latest block number using eth_blockNumber:

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({jsonrpc: '2.0', method: 'eth_blockNumber', id: 1})
};

fetch('https://base-mainnet.core.chainstack.com/<KEY>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

Keep the real endpoint and credentials out of source control. See Chainstack’s environment variables guide.

To check out all endpoints available on Base, including archive, debug and trace methods, go through the Base API reference.

Submit the signed transaction

The application continues to use the standard eth_sendRawTransaction JSON-RPC method. With Optimized Submission enabled, Chainstack routes the transaction through its private, optimized path.

const signedTransaction = '0x...'; // your signed, serialized transaction

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    jsonrpc: '2.0',
    method: 'eth_sendRawTransaction',
    id: 1,
    params: [signedTransaction]
  })
};

fetch('https://base-mainnet.core.chainstack.com/<KEY>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

Here, signedTransaction must be a valid, already signed serialized transaction produced by the wallet or signing process. The example assumes that the signing flow has been completed separately.

Validate execution

Track the transaction hash, inspect its receipt and handle reverts. For swaps, set an appropriate amountOutMinimum and deadline in the contract call. Flashblocks can provide earlier execution feedback when the relevant endpoint and methods support it, but the application should still distinguish preconfirmation from final settlement.

Arbitrum

Arbitrum One is an Ethereum Layer 2 built on the Arbitrum Nitro stack. Its sequencer receives transactions, orders them and publishes transaction data to Ethereum. Understanding the sequencer’s ordering policy is important when assessing MEV exposure.

If you want to learn more about Arbitrum and its ecosystem, this blog is worth a read: Arbitrum vs Optimism RPC infrastructure

Arbitrum One uses Priority Gas Auctions (PGA), where transactions compete for ordering priority through their priority fees. The sequencer processes transactions in short rounds and the mempool remains private. This differs from the public-mempool model on Ethereum Mainnet, where searchers may observe pending transactions before inclusion. See the Arbitrum sequencer documentation for the ordering rounds in detail.

Optimized Submission on Arbitrum

For Arbitrum applications, Optimized Submission focuses on transaction delivery and inclusion. Since transactions are submitted through the sequencer’s private transaction pipeline, the relevant infrastructure questions include submission latency, RPC reliability and how transactions are handled when the preferred route fails.

Chainstack supports Optimized Submission on Arbitrum Mainnet.

• Chain ID: 42161
• Mainnet: https://arbitrum-mainnet.core.chainstack.com
• Network name: Arbitrum Mainnet
• Testnet chain ID: 421614
• Testnet: https://arbitrum-sepolia.core.chainstack.com
• Testnet network name: Arbitrum Sepolia Testnet
• Currency symbol: ETH

The application can continue using standard Ethereum JSON-RPC methods. Once the add-on is enabled, submit the serialized signed transaction through the configured Chainstack endpoint using eth_sendRawTransaction.

const signedTransaction = '0x...'; // your signed, serialized transaction

const response = await fetch(process.env.ARBITRUM_RPC_URL, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "eth_sendRawTransaction",
    params: [signedTransaction],
  }),
});

const result = await response.json();

if (result.error) {
  throw new Error(result.error.message);
}

console.log("Transaction hash:", result.result);

Here, signedTransaction is the serialized hexadecimal transaction generated by the wallet or signing process. The private key remains outside the RPC request.

After submission, use the returned hash to query eth_getTransactionReceipt and check execution status. Applications should also handle pending transactions, RPC errors, nonce management and retries.

For the list of all Arbitrum APIs, refer to Arbitrum methods.

Arc

Arc is an EVM-compatible Layer 1 designed for stablecoin-native finance and onchain markets. Unlike Base and Arbitrum, Arc is not an Ethereum L2. Arc Mainnet went live on September 16, 2026.

Arc uses USDC as its native gas token, allowing transaction fees to be paid in the same asset used by many payment and financial applications. This can simplify fee management for stablecoin-based workflows, although it does not remove the need to account for transaction ordering, execution quality and infrastructure reliability.

To learn more about Arc and its infrastructure, we recommend reading “What is Arc? A deep dive“.

MEV considerations on Arc depend on the application’s transaction flow and the network’s ordering behavior. A payment application may prioritize reliable transaction delivery and clear settlement status, while a DEX or trading application also needs slippage controls, price validation and safeguards against adverse execution.

Optimized Submission on Arc

Chainstack lists Arc Mainnet as a supported network for Optimized Submission.

To enable it:

1. Create an Arc Mainnet node in the Chainstack console.
2. Open the node’s Add-ons section. On a new node, Optimized Submission is selected by default and shows Included. On an existing node, enable it and confirm activation.

• Chain ID: 5042
• Mainnet: https://arc-mainnet.core.chainstack.com
• Network name: Arc Mainnet
• Testnet chain ID: 5042002
• Testnet: https://arc-testnet.core.chainstack.com
• Testnet network name: Arc Testnet
• Currency symbol: USDC

Submit a signed transaction

Arc supports EVM-compatible JSON-RPC methods, including eth_sendRawTransaction. The same transaction-submission pattern can be used with the Arc endpoint.

const signedTransaction = '0x...'; // your signed, serialized transaction

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    id: 1,
    jsonrpc: '2.0',
    method: 'eth_sendRawTransaction',
    params: [signedTransaction]
  })
};

fetch('https://arc-mainnet.core.chainstack.com/<KEY>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

The transaction must be signed for Arc’s chain ID and contain valid transaction parameters. The example assumes signing has already taken place. To try the flow without real funds, point the same request at an Arc Testnet endpoint.

After submission, track the transaction hash and inspect its receipt. Payment applications should reconcile successful execution with their internal payment state, while trading applications should validate execution prices and enforce contract-level limits.

For network details, see the Arc developer documentation.

Optimized Submission is an infrastructure feature, not a contract-level security guarantee. Chainstack’s docs say Arc doesn’t broadcast transactions to a public mempool, and Arc nodes on Chainstack reject pending-transaction subscriptions, but ordering rules still depend on the network’s design, so keep slippage limits and deadlines in your contracts.

For tooling and supported-network details, see Arc tooling.

Considerations

Understand the product distinction

Chainstack offers two separate add-ons:

• Optimized Submission: Available for Arbitrum Mainnet, Base Mainnet, Arc Mainnet and Robinhood Chain Mainnet. It routes transactions through a private, optimized path designed for faster inclusion.
• MEV Protection: Available for Ethereum Mainnet and BNB Smart Chain Mainnet. It routes transactions privately to reduce exposure to public-mempool front-running and related extraction.

On the supported sequencer chains (Arbitrum, Base, Arc and Robinhood Chain), Chainstack documents that transactions are not broadcast to a public mempool. The Optimized Submission path therefore addresses delivery and inclusion characteristics rather than providing the same protection model as private builder routing on Ethereum Mainnet.

Design the correct fallback behavior

Chainstack’s Optimized Submission path falls back to the node’s standard route if private routing fails. Its MEV Protection add-on behaves differently: a failed private route returns a JSON-RPC error rather than broadcasting the transaction to the public mempool.

Applications should handle these behaviors deliberately. Log errors, track transaction hashes, manage pending nonces and make retries idempotent at the business-logic layer.

Protect execution at the contract level

RPC routing cannot replace contract-level safeguards. Use:

• Slippage bounds and deadlines for swaps.
• Fresh and validated oracle data for lending and liquidation logic.
• Access control and authorization checks for sensitive operations.
• Reentrancy protections and appropriate invariant checks.
• Monitoring for reverts, latency spikes, failed submissions and unusual execution outcomes.

Benchmark under realistic conditions

Measure transaction submission latency, time to inclusion, revert rates and user-facing completion time. Compare results across network load conditions and transaction types. A single successful transaction is insufficient evidence of a production improvement.

Keep infrastructure configuration secure

Use environment variables or a secrets manager for RPC credentials and signing configuration. Avoid exposing privileged endpoints in client-side bundles. Separate application logic from signing logic where the threat model requires it, and never log private keys or seed phrases.

Conclusion

MEV protection on Ethereum, BNB, Base, Arbitrum, Arc and Robinhood Chain starts with understanding each network’s transaction pipeline and ordering model. Public-mempool protection, sequencer-aware submission and application-level execution safeguards address different risks.

Chainstack’s Optimized Submission provides a supported path for improving transaction delivery through private routing. Ethereum Mainnet and BNB Smart Chain applications can evaluate Chainstack’s separate MEV Protection add-on when public-mempool front-running is part of the threat model.

The most reliable approach combines appropriate infrastructure, contract-level execution controls, transaction monitoring and realistic production testing.

Frequently asked questions

Related reading

• Optimized Submission on the Chainstack Marketplace
• MEV protection (Chainstack docs)
• Optimized submission (Chainstack docs)
• Flashblocks on Base (Chainstack docs)
• Base architecture: migration to the OP Stack
• Arbitrum vs Optimism RPC infrastructure
• What is Arc? A deep dive