MEV Mitigation at Protocol Level: PBS, Auctions, and MEV Tax

MEV Mitigation at Protocol Level: PBS, Auctions, and MEV Tax

Photo by Jakub Zerdzicki on Pexels

Quick Answer: Protocol-level MEV mitigation changes Ethereum's block construction rules to reduce harmful MEV extraction. In 2026, five mechanisms are deployed or in advanced research: (1) Proposer-Builder Separation (PBS) — splits block building from block proposal, preventing validators from extracting MEV directly (live via MEV-Boost since 2022); (2) ePBS (enshrined PBS) — PBS baked into the Ethereum protocol rather than middleware, planned for the Electra/Glacier upgrade; (3) MEV-Burn — auction mechanisms that burn MEV revenue instead of routing it to validators; (4) Encrypted Mempools (Shutter, SFX) — transactions are encrypted and only decrypted during block production, preventing frontrunning; (5) Execution Tickets — a new validator economic model separating block proposal rights from staking. The economic impact: MEV-Boost channels ~80% of MEV (500 ETH/day) to validators. MEV-Burn could redirect this to protocol revenue (similar to EIP-1559 burn). Based sequencing extends PBS principles to L2 rollups.

The MEV Flow

Today, the vast majority of extracted MEV goes to block proposers:

Total MEV extracted daily: ~600 ETH ($1.8M)

Where it goes:
┌──────────────────────────────────────────────────────────┐
│  Block Proposers (validators): 80% = 480 ETH              │
│  Builders: 15% = 90 ETH                                   │
│  Searchers: 5% = 30 ETH (before costs)                    │
└──────────────────────────────────────────────────────────┘

MEV-Boost channels:
  User tx → Public mempool → Searcher constructs bundle →
  Builder constructs block → Relay → Proposer

  Each actor extracts some value:
  - Searcher: frontrun/backrun profit
  - Builder: tips from searchers + order flow payments
  - Relay: optional fee (Flashbots: zero)
  - Proposer: block bid from builder (80% of total)

Proposer-Builder Separation (PBS)

PBS creates two specialized roles:

Before PBS:
  Validator = Proposer + Builder (does both)
  → Validator sees pending transactions
  → Can frontrun, sandwich, extract MEV directly

After PBS:
  Builder creates blocks (specialized, competitive)
  Proposer selects the best block (highest bid)
  → Proposer doesn't see transactions until they accept the block
  → Builder competes on block value
  → MEV extracted but proposer only gets the bid, not the full value

Economic consequence:
  Before: Validator extracts ALL MEV
  After: Validator gets bid (~80% of MEV)
         Builder keeps spread (~20% of MEV for risk + infrastructure)
  → Net: MEV still extracted, but distribution changes
  → Smaller validators get MEV revenue they couldn't access before

Photo by Joel Martinez on Pexels

MEV-Burn

MEV-Burn auctions block space using a mechanism similar to EIP-1559:

MEV-Burn Auction:
  Instead of: Builder pays proposer → proposer keeps bid
  MEV-Burn: Builder pays protocol → bid is BURNED

Like EIP-1559 base fee burning, but for block space auctions.

Benefit:
  - MEV becomes protocol revenue (instead of validator reward)
  - Reduces validator rewards → may require adjusted issuance
  - Makes ETH more deflationary (MEV burn ~= 500 ETH/day)
  - Aligns protocol incentives: MEV extraction is still possible
    but the value goes to ETH holders, not validators

Challenge:
  - Validator opposition (MEV is currently 30-50% of validator income)
  - Requires ePBS or similar protocol-level change
  - May lead to off-protocol side payments

Mechanism:
  ┌─────────────────────────────────────────────────────────┐
  │  1. Builders submit bids (how much ETH they'll burn)    │
  │  2. Proposer selects highest-bid block                   │
  │  3. BID is burned, not given to proposer                 │
  │  4. Proposer gets: protocol reward + tx fees             │
  │                     (not MEV bid)                        │
  │  5. Builder gets: MEV profit - burned bid                 │
  └─────────────────────────────────────────────────────────┘

Expected outcome:
  Builders bid up to their expected MEV profit
  → MEV is burned → ETH deflation
  → Validators compensated via higher issuance (if needed)

Encrypted Mempools

Encrypted mempools prevent frontrunning by hiding transaction contents until inclusion:

Standard mempool:
  Transaction: Swap 100 ETH for USDC [VISIBLE to everyone]
  → Frontrunner sees, buys USDC first, user gets worse price

Encrypted mempool (Shutter):
  Transaction: Encrypted(swap 100 ETH for USDC)
  → No one sees content
  → Sequencer/validator selects tx for inclusion
  → Transaction decrypted ONLY during block execution
  → Frontrunner can't see or frontrun

Technical flow:
  1. User encrypts tx with Shutter's threshold network key
  2. Valid tx submitted to mempool (encrypted)
  3. Validator includes encrypted tx in block
  4. During block execution:
     - Threshold network (distributed key holders) decrypts
     - Transaction executes normally
  5. Frontrunning prevented because tx was hidden until included

Key property:
  Threshold encryption ensures no single party can decrypt
  A threshold network of N nodes holds shares of the decryption key
  Any K-of-N must cooperate to decrypt

Order-Flow Auctions

Order-flow auctions let users sell their transaction order flow to the highest bidder:

Current model:
  User submits tx to public mempool → searchers compete → 
  worst execution for user (frontrunning, sandwiching)

Order-flow auction:
  1. User creates order → auction starts
  2. Searchers/builders bid for exclusive order flow
  3. User picks: best execution price + rebate
  4. Winner executes the order without competition
  5. User gets: market price + rebate (bid amount)

Benefits:
  - User captures value that currently goes to MEV searchers
  - No frontrunning (order is executed privately)
  - Competitive pricing (searchers bid against each other)

Implementation:
  ┌────────────────────────────────────────────────────────┐
  │  1. User signs intent: "Sell 10 ETH for USDC"           │
  │  2. Auction broadcast to searcher network                │
  │  3. Each searcher bids: "I'll execute at 3450 USDC/ETH  │
  │     + rebate of 5 USDC"                                  │
  │  4. User picks highest total value                       │
  │  5. Searcher executes (sandwich-free, competitive)      │
  │  6. User receives: 3450 USDC/ETH + 5 USDC rebate        │
  └────────────────────────────────────────────────────────┘

Related Reads

• MEV Extraction Strategies: Sandwich, Arbitrage, Liquidations
• TEEs and Confidential Computing in Blockchain
• How to Avoid Capital Gains Tax on Crypto (Legal Guide 2026)

MEV Tax: Dynamic Fee Structures for Toxic MEV

A MEV tax introduces a protocol-enforced fee on harmful MEV activities, such as sandwich attacks or liquidation frontrunning, to disincentivize toxic extraction while preserving benign forms like arbitrage. Unlike MEV-Burn, which targets all MEV revenue, a MEV tax is selective—it applies only to transactions identified as harmful by predefined rules (e.g., multi-block sandwiches or excessive slippage). The tax could be implemented as a percentage of the extracted value or a fixed fee per toxic transaction, with proceeds either burned or redistributed to affected users. For example, a 50% tax on a sandwich attack that extracts 10 ETH would impose a 5 ETH fee, reducing the attacker’s profit margin and making such strategies less viable.

The technical challenge lies in accurately identifying toxic MEV without false positives. One approach uses on-chain heuristics, such as detecting rapid back-to-back transactions from the same address or abnormal slippage in DEX trades. Alternatively, off-chain detection (e.g., via relays or builder APIs) could flag suspicious bundles before inclusion, though this risks centralization. A hybrid model might combine on-chain rules with optional builder attestations, where builders certify that blocks comply with MEV tax policies. This creates a reputation system: builders who consistently include toxic MEV face penalties, such as exclusion from relays or reduced block rewards. Over time, the tax could evolve into a dynamic fee structure, where the tax rate adjusts based on network congestion or the prevalence of toxic MEV, similar to EIP-1559’s base fee mechanism.

Based Sequencing: Extending PBS to Layer 2 Rollups

Based sequencing applies PBS principles to Layer 2 (L2) rollups, separating the roles of sequencers (L2 block proposers) and builders to mitigate MEV at the rollup level. In a based rollup, the L1 proposer (Ethereum validator) selects the L2 sequencer, who then outsources block construction to specialized builders. This creates a competitive market for L2 block space, where builders bid for the right to construct the next rollup block, and the highest bidder’s block is included. The sequencer’s role is reduced to selecting the best bid, mirroring Ethereum’s PBS model. This structure prevents sequencers from extracting MEV directly, as they never see pending transactions until block inclusion, and ensures that MEV revenue flows to builders or the protocol rather than centralized sequencers.

The economic implications are significant for rollup decentralization. Today, most rollups rely on single sequencers (e.g., Arbitrum’s sequencer or Optimism’s sequencer pool), which can extract MEV monopolistically. Based sequencing introduces competition, allowing multiple builders to propose blocks and forcing sequencers to act as neutral auctioneers. This also enables cross-rollup MEV strategies, where builders construct blocks for multiple rollups simultaneously, optimizing for arbitrage or liquidation opportunities across chains. For example, a builder might construct a block for both Arbitrum and Optimism, capturing cross-rollup arbitrage while bidding for inclusion in both sequencers’ auctions. The challenge lies in synchronizing these auctions without introducing latency or trust assumptions. One solution is to use a shared mempool or encrypted sequencing layer, where transactions are encrypted until inclusion, preventing frontrunning even in cross-rollup scenarios.

Execution Tickets: Decoupling Proposal Rights from Staking

Execution tickets are a novel validator economic model that separates block proposal rights from staking, creating a market for block proposal slots independent of ETH collateral. Under this system, validators still stake ETH to secure the network, but the right to propose blocks is auctioned separately via non-transferable “execution tickets.” These tickets are sold in periodic auctions, with proceeds burned or redistributed to stakers. The winning bidder (ticket holder) proposes the next block and receives the MEV bid from builders, while the protocol captures the ticket’s auction value. This decoupling reduces the capital requirements for block proposal, as validators no longer need large ETH stakes to access MEV revenue, and aligns incentives by ensuring that MEV extraction benefits the protocol rather than just stakers.

The design space for execution tickets includes several key parameters:

• Ticket duration: Tickets could be valid for a single block, a fixed number of blocks, or a time-based epoch (e.g., 1 hour). Shorter durations increase competition but may introduce latency.
• Auction mechanism: Options include sealed-bid auctions (where bidders submit hidden bids) or ascending-clock auctions (where the price increases until demand clears). Sealed bids reduce collusion but may lead to overpayment.
• Ticket transferability: Non-transferable tickets prevent speculation but may reduce liquidity. Transferable tickets could create a secondary market, though this risks centralization around ticket holders.
• Revenue distribution: Auction proceeds could be burned (like MEV-Burn), redistributed to stakers, or used to fund public goods.

A critical trade-off is the impact on validator incentives. If execution tickets are too cheap, validators may underbid, reducing protocol revenue. If they’re too expensive, only well-capitalized entities can participate, recreating centralization. To mitigate this, the protocol could implement a dynamic reserve price, where the minimum bid adjusts based on recent auction outcomes or network MEV levels. Another challenge is ensuring that ticket holders don’t collude with builders to extract MEV off-protocol. This could be addressed by requiring builders to post bonds or by using cryptographic proofs (e.g., zero-knowledge attestations) to verify that MEV bids are fair and transparent.

Key Takeaways

• Proposer-Builder Separation (PBS) shifts MEV extraction from validators to specialized builders, democratizing access to MEV revenue for smaller validators while maintaining block production incentives—MEV-Boost already channels ~80% of MEV to proposers via competitive bids.
• MEV-Burn redirects builder bids to protocol-level burns, converting MEV into deflationary pressure for ETH (potentially adding 400-600 ETH/day to burns) but may require adjusted validator issuance to offset lost rewards.
• Encrypted mempools (e.g., Shutter) prevent frontrunning by hiding transaction details until block execution, relying on threshold encryption to ensure no single party can decrypt transactions prematurely.
• Order-flow auctions let users capture MEV value by auctioning their transaction flow to searchers, replacing public mempool competition with private, user-beneficial execution and rebates.
• ePBS (enshrined PBS) is slated for Ethereum’s Electra/Glacier upgrade (2026/27) but faces challenges like builder trustlessness and backward compatibility with MEV-Boost infrastructure.
• Protocol-level MEV mitigation doesn’t eliminate MEV but reshapes its distribution: reducing toxic forms (via encryption), redirecting value to users (via auctions), and capturing revenue for the protocol (via MEV-Burn).