MEV-Share

What Is MEV-Share?

MEV-Share is an open protocol developed by Flashbots that returns a portion of maximal extractable value (MEV) to the users whose transactions generate it. When a user swaps tokens on a decentralized exchange, the transaction often creates an arbitrage opportunity that searchers can exploit. Without MEV-Share, searchers capture this value entirely, sharing some of it with validators through priority fees. MEV-Share changes this dynamic by requiring searchers to send a refund back to the originating user as a condition of accessing their transaction data.

The protocol was introduced in 2023 as part of Flashbots Protect, an RPC endpoint that users add to their wallets to route transactions away from the public mempool. By keeping transactions private and selectively disclosing data to searchers through a matchmaker, MEV-Share creates a marketplace where users trade visibility for value redistribution.

How It Works

MEV-Share operates as a layer between users and the existing MEV supply chain. It sits between order flow submission and block building, adding a matchmaking step that enforces refunds.

1. A user submits a transaction to Flashbots Protect (an RPC endpoint) instead of broadcasting it to the public mempool
2. The MEV-Share matchmaker receives the transaction and strips it down to a set of configurable "hints" based on the user's privacy preferences
3. Searchers receive these hints via a streaming API and identify backrun opportunities
4. Searchers submit bundles that include the user's transaction along with their own backrun transaction, specifying how much MEV to refund to the user's address
5. The matchmaker selects the bundle with the highest kickback to the user and forwards it to block builders
6. If the bundle lands on-chain, the user receives the refund as a direct ETH transfer in the same block

The Hint System

The hint system is what makes MEV-Share programmably private. Users control which fields of their transaction are revealed to searchers. The available hints include:

• Transaction hash: the minimum disclosure, always shared by default
• Contract address: which contract the transaction interacts with
• Function selector: which function is being called (e.g., a swap)
• Logs: partial event logs revealing pool addresses or token pairs
• Calldata: the full input data of the transaction
• Full transaction: complete transaction details for maximum MEV extraction potential

By default, Flashbots Protect shares the transaction hash and partial swap logs. Users who want maximum privacy can share only the hash, though this typically reduces refund amounts because searchers have less information to construct profitable backruns. Users who want maximum refunds can share full transaction data.

Refund Mechanics

When a searcher submits a bundle to the matchmaker, they include a refundConfig that specifies which addresses receive what percentage of the MEV extracted. The bundle specification requires searchers to define a minimum refund percentage, and the matchmaker selects the bundle offering the highest return to the user.

// Simplified MEV-Share bundle structure
{
  "version": "v0.1",
  "inclusion": {
    "block": "0x1234..."
  },
  "body": [
    { "hash": "0xabc..." },        // user's transaction (by hash reference)
    { "tx": "0xdef...", "canRevert": false }  // searcher's backrun
  ],
  "validity": {
    "refund": [
      {
        "bodyIndex": 0,            // refund goes to tx at index 0 (user)
        "percent": 90              // 90% of MEV refunded to user
      }
    ]
  }
}

The bodyIndex field references the user's transaction within the bundle, and the percent field specifies how much of the extracted value to return. Competitive dynamics push searchers to offer higher refund percentages, since the matchmaker selects the most generous bundle.

Relationship to MEV-Boost

MEV-Boost and MEV-Share operate at different layers of the MEV supply chain. MEV-Boost handles the relationship between validators (proposers) and block builders: it allows validators to outsource block construction in exchange for a share of MEV revenue. MEV-Share operates upstream, handling the relationship between users and searchers. The two protocols are complementary: MEV-Share bundles flow through MEV-Boost's builder-proposer pipeline.

In the full flow, value moves through four parties: users generate order flow, searchers extract MEV and refund users via MEV-Share, builders assemble blocks containing these bundles, and proposers select the most valuable block via MEV-Boost. Each layer adds a redistribution mechanism to what was originally an opaque extraction process.

How MEV-Share Compares to Alternatives

Several approaches exist for protecting users from MEV extraction, each with different tradeoffs:

Use Cases

DEX Swap Protection and Rebates

The primary use case for MEV-Share is protecting users who trade on decentralized exchanges. A large swap on Uniswap or another AMM creates an arbitrage opportunity because the swap moves the pool price away from the market price. Without MEV-Share, a searcher would backrun the swap, pocket the arbitrage profit, and the user would receive nothing. With MEV-Share, the searcher must refund a portion of that profit to the user as a condition of accessing the order flow.

Oracle Extractable Value (OEV)

MEV-Share's design has been proposed for redistribution of oracle extractable value. When price feed updates create liquidation or arbitrage opportunities in lending protocols, MEV-Share's matchmaking approach can route the resulting value back to the protocol or its users rather than allowing searchers to capture it entirely.

Protocol-Level MEV Redistribution

DeFi protocols can integrate with MEV-Share as orderflow providers, routing their users' transactions through the matchmaker and capturing a share of the MEV generated by their own pool interactions. This creates a new revenue stream for protocols while simultaneously protecting their users.

Adoption and Ecosystem

Flashbots Protect, the primary entry point for MEV-Share, accounts for roughly 2% of all Ethereum transactions that land on-chain. The majority of Protect transactions are DEX swaps, reflecting the protocol's focus on swap-related MEV. By early 2025, approximately half of all Ethereum transactions were routed through private channels of some kind, with Flashbots Protect being one of several private RPC providers alongside MEV Blocker, Blink, and Merkle.

Flashbots publishes Protect and MEV-Share data openly. Searchers access the MEV-Share event stream through a Server-Sent Events (SSE) API that broadcasts transaction hints in real time. The bundle specification is open, and multiple searcher implementations exist across languages including TypeScript and Rust.

Risks and Considerations

Centralization and Trust

The most significant criticism of MEV-Share is its reliance on Flashbots as a trusted intermediary. The matchmaker is a centralized component that receives user transactions, manages hint disclosure, and selects which bundles to forward to builders. Users must trust that the matchmaker operates honestly: that it does not front-run transactions, leak data to preferred searchers, or manipulate bundle selection.

This centralization is in tension with Ethereum's decentralization goals. While the protocol specification is open, the primary matchmaker implementation is operated by Flashbots. Research into trusted execution environments (TEEs) for the matchmaker is underway, and Flashbots has introduced a TEE-based "fast mode" that shares full transaction data with TEE-verified searchers while providing only hints to others.

Bypass Risk

If a searcher obtains enough information from the hints to reconstruct the full transaction, they can submit their backrun directly to a block builder without going through MEV-Share. In this scenario, the user receives no refund. The hint system mitigates this by allowing users to limit what is revealed, but users who share more data for larger refunds also increase their exposure to bypass.

Incomplete Coverage

MEV-Share primarily addresses backrunning opportunities. It does not eliminate all forms of MEV extraction. For instance, cross-domain MEV involving multiple chains or rollups falls outside its current scope. Similarly, value extracted through ordering manipulation at the sequencer level on Layer 2 networks is not addressed by MEV-Share.

Settlement Quality

Research has shown that private transaction routing does not always produce better outcomes for users. In some cases, transactions sent through private RPCs can settle at worse prices than public mempool transactions, particularly when the private route introduces latency or when builder competition is insufficient. Users should understand that MEV-Share reduces but does not eliminate the cost of MEV, and the net benefit depends on market conditions and the competitiveness of the searcher ecosystem.

Why It Matters

MEV-Share represents a shift in how the Ethereum ecosystem thinks about MEV: from an unavoidable tax on users to a partially redistributable resource. By creating a market for transaction data and enforcing refunds through bundle validity conditions, it aligns searcher incentives with user outcomes. For a deeper analysis of how MEV redistribution fits into Ethereum's validator economics, see Ethereum MEV, PBS, and Validator Economics.

The broader trend toward private order flow and MEV redistribution is relevant across blockchain ecosystems. Bitcoin Layer 2 networks like Spark avoid many of these MEV dynamics by design: Spark's architecture does not rely on a public mempool or competitive block building, which eliminates the primary vectors for MEV extraction that protocols like MEV-Share exist to address.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.