Private Mempools and User-Side Defenses

The on-chain defenses in §4.13.3 protect users by changing the protocol's design. The defenses in this section protect users by changing how they submit their transactions, without requiring any contract modifications. They are not a complete solution — they cannot eliminate all MEV, and they shift trust to new actors — but they are widely deployed, cheap to adopt, and worth understanding for any audit that addresses MEV exposure.

Flashbots Protect

A drop-in RPC endpoint that, when a user submits a transaction:

  • Does not propagate it to the public mempool.
  • Submits it directly to Flashbots' block builder (and, optionally, other compliant builders).
  • Re-attempts it across multiple blocks until inclusion or expiry.

What it protects against:

  • Sandwich attacks (no public searcher ever sees the tx).
  • Generalized front-running (the tx is invisible until inclusion).
  • Failed-transaction-cost ambiguity (Flashbots-only transactions don't pay gas if not included).

What it does not protect against:

  • The builder receiving the transaction can see it. Flashbots Protect relies on Flashbots not abusing this position; the trust assumption is moved, not eliminated.
  • Back-running by the builder or by searchers that share the same builder, in cases where the tx's effect is visible after inclusion.
  • Censorship: a single builder can refuse to include the transaction, and the user has to wait for re-submission to a different builder.
  • L2 transactions (Flashbots Protect is an Ethereum L1 service).

Audit notes:

  • A protocol can recommend Flashbots Protect (or an equivalent) to its users for high-value transactions; this is good practice and worth surfacing in the report's "centralization & MEV" section.
  • A protocol that requires Flashbots Protect to function safely is fragile — what happens when Flashbots is unavailable or censors the user?

MEV-Share

A Flashbots protocol that lets users selectively share information about their transactions with searchers in exchange for a kickback when the searcher captures MEV.

Mechanics:

  1. User submits a transaction to MEV-Share with hints about its structure (e.g., "this is a swap on Uniswap V3 ETH/USDC").
  2. Searchers see the hints but not the full transaction.
  3. Searchers submit bundles that back-run the user's transaction profitably.
  4. The winning bundle's MEV is split: some to the searcher, some rebated to the user.

For users whose transactions create predictable back-run opportunities, MEV-Share can produce net-positive outcomes — they capture some of the MEV that would otherwise have gone entirely to searchers.

Audit notes:

  • MEV-Share is more relevant to wallet/aggregator design than to protocol design.
  • For protocols whose users naturally create back-runnable opportunities (large swaps, oracle-dependent actions), recommending MEV-Share is a user-friendly default.

MEV-Blocker, Eden, BloXroute Protect, Others

The private-mempool space has multiple providers, each with slightly different policies on builder selection, transaction privacy, and back-run rebates. The general shape of the protection is similar across them:

  • Public mempool exposure: avoided.
  • Sandwich protection: strong.
  • Back-running protection: partial to none, depending on the service.
  • Censorship resistance: dependent on the diversity of builders the service forwards to.

Audits that recommend "private mempool submission" should ideally point to specific tools and acknowledge the trust trade-offs.

EIP-7732 and PBS Future Direction

Ethereum's roadmap includes proposer-builder separation (PBS) at the protocol level (in-protocol PBS, ePBS, or the family of EIPs around it). The current MEV-Boost setup is an off-protocol approximation; in-protocol PBS would formalize and (somewhat) constrain the builder-validator interaction.

For audits written in 2026, the practical landscape is:

  • MEV-Boost is dominant and stable.
  • In-protocol PBS is on the roadmap but not yet live.
  • L2 sequencing remains centralized but is moving toward shared sequencers and based rollups, which will change the L2 MEV picture significantly.

Audit findings should reflect the current MEV landscape, not the speculated future one, but findings about "long-lived contracts whose MEV exposure may change as the chain evolves" are appropriate where relevant.

Wallet-Level Defenses

Several wallets now default to private-mempool submission for swaps:

  • MetaMask (when "Smart Transactions" is enabled, uses MEV-Blocker by default for relevant tx types).
  • Rabby (MEV-aware routing).
  • Various smart-contract wallets and account abstraction stacks (4337 paymasters and bundlers can incorporate private routing).

For protocol audits, the user's wallet choice is out of scope, but it influences the realistic MEV exposure of a protocol's users. A protocol primarily used through MetaMask in 2026 has different default MEV exposure than the same protocol used through a stripped-down Ethers script.

Account Abstraction and Bundlers (ERC-4337)

Under ERC-4337, user operations are submitted to a separate UserOp mempool (the "alt-mempool"), then bundled by bundlers and submitted to the main mempool as handleOps calls.

MEV implications:

  • The UserOp mempool is currently public; bundlers see all pending UserOps.
  • Bundlers can themselves extract MEV from the UserOps they bundle, similar to how builders extract MEV from regular transactions.
  • Private UserOp submission services are emerging but less mature than their EOA counterparts.
  • Paymasters that sponsor gas can introduce additional MEV considerations (the paymaster signs over the UserOp; this signing can be manipulated).

For audits of 4337 contracts:

  • Verify that the contract validates the entire UserOp data structure, including paymaster data and signatures.
  • Verify that gas-sponsorship signatures are bound to a single UserOp and cannot be reused.
  • Verify that the contract does not assume the UserOp came from any specific bundler.

What Auditors Should Recommend

When an audit identifies MEV exposure that cannot be cheaply eliminated at the contract level, a reasonable report includes:

  • Specific user-side mitigations (Flashbots Protect, MEV-Share, wallet recommendations).
  • The trust trade-offs of those mitigations (single-builder reliance, censorship risk).
  • A clear statement of what residual exposure remains even with the recommended mitigations in place.

"Users can use private mempools" is not enough on its own. Audit readers — developers, DAOs, end users — deserve actionable guidance, not a deferred problem.