MEV-Share

A user submits a large swap intent to MEV-Share. Searchers compete to execute it, often by backrunning the trade with their own arbitrage or liquidation. The winning searcher pays the user a rebate from their profits. This is the most common use case, turning a user's simple swap into a revenue-generating opportunity.

• User Benefit: Receives a portion of the MEV as a refund.
• Searcher Benefit: Gains exclusive, private access to a profitable opportunity.
• Example: A user swapping 100 ETH for USDC might receive a 0.5 ETH rebate from the searcher's arbitrage profit.

By submitting transactions through MEV-Share with calldata hashing and conditional hints, users can obscure their exact intent until execution. This prevents malicious searchers from frontrunning the transaction for their own gain at the user's expense. The protocol's commit-reveal mechanism ensures only the winning, compliant searcher learns the full transaction details.

• Core Feature: Privacy via encrypted mempools.
• Result: Users are protected from predatory sandwich attacks and toxic MEV.

Liquidation bots (searchers) monitor for undercollateralized positions. When a user's transaction (e.g., a price update) creates a liquidation opportunity, MEV-Share allows the liquidation bot to bundle the user's trigger transaction with its own liquidation tx. The user receives a share of the liquidation fee as a reward for creating the opportunity.

• Efficiency: Liquidations happen faster and more reliably.
• Incentive Alignment: The user who triggers the state change is compensated, not penalized.

A user signals an intent to buy a specific NFT at a floor price. Searchers scan for profitable NFT arbitrage opportunities across markets like Blur and OpenSea. A searcher bundles the user's buy order with their own sell order on a different platform, capturing the spread and sharing a portion with the user.

• Market Efficiency: Helps correct price discrepancies across NFT marketplaces.
• New Revenue Stream: NFT traders earn MEV rebates on their purchases.

At its core, MEV-Share operates as a sealed-bid auction for transaction bundles. Searchers receive partial hints about a user's intent, then submit encrypted bundles containing:

• The user's transaction.
• The searcher's profitable side transactions.
• A bid (rebate) for the user. The validator (via Flashbots Relay) selects the bundle with the highest total bid, decrypts it, and includes it in the block. This creates a competitive market for MEV opportunities.

MEV-Share operates by creating a private order flow auction. Users submit transactions to a relay, which strips identifying details and creates a bundle hint. Searchers bid on the right to include these hinted transactions in their MEV bundles. The winning bid's value is then shared back with the original user, creating a value loop.

• Relay: Receives and anonymizes user transactions.
• Bundle Hint: A partial, privacy-preserving representation of a transaction.
• Backrunning: A common strategy where searchers place their transactions directly after a user's hinted swap to capture arbitrage.

The primary adoption driver is enabling everyday users and decentralized applications (dApps) to capture a portion of the MEV their transactions generate. Before MEV-Share, this value was extracted entirely by searchers and validators.

• Rebates: Users receive a share of the winning searcher's bid, often as an ERC-20 token transfer in the same block.
• Privacy: Transactions are shielded in the mempool, reducing frontrunning risk.
• dApp Integration: Protocols can integrate MEV-Share to return value to their users, improving their product's effective yield.

MEV-Share created a new marketplace for searchers (bots that identify and execute MEV opportunities). They now compete in auctions for valuable order flow, requiring new strategies and infrastructure.

• Bundle Bidding: Searchers must develop systems to bid on and integrate hinted transactions into complex MEV bundles.
• Flashbots Suite: Searchers often use the Flashbots Protect RPC to access the MEV-Share market and tools like the Flashbots Builder for bundle construction.
• Strategy Shift: Moves from pure public mempool scanning to participating in private auctions for higher-quality, hinted opportunities.

MEV-Share is integrated by wallets, dApps, and infrastructure providers to retroactively pay users for the MEV they create.

• Wallet RPCs: MetaMask and Rabby can route transactions through MEV-Share via the Flashbots Protect RPC endpoint.
• DeFi Protocols: DEX aggregators and lending platforms can integrate to give users MEV rebates on swaps and liquidations.
• Real Example: A user swapping a large amount of ETH for USDC on Uniswap may have their transaction included in a searcher's arbitrage bundle, receiving a rebate that improves their effective exchange rate.

Adoption relies on a trusted relay to facilitate the auction and a block builder to construct the final block. This decouples the roles in the MEV supply chain.

• Relay (Flashbots Relay): The neutral party that receives hinted transactions, runs the auction, and forwards the winning bundle to a builder. It ensures user privacy and fair auction execution.
• Builder: A specialized entity (e.g., Flashbots Builder, Titan Builder) that constructs full blocks from winning bundles and plain transactions, optimizing for validator payouts.
• Trust Assumptions: Users must trust the relay not to censor or frontrun their transactions.

Success is measured by the volume of order flow routed through the system and the value returned to users, creating a reinforcing network effect.

• Order Flow Share: The percentage of total Ethereum transaction value processed by the MEV-Share relay.
• User Rebates: The total ETH or USD value returned to users as rebates, demonstrating tangible benefit.
• Searcher Participation: The number of active searchers/bots bidding in auctions indicates a healthy, competitive marketplace. Higher participation drives up bid prices, increasing user rebates.

MEV-Share allows users to selectively reveal parts of their transaction data to searchers via intents, rather than exposing the full transaction publicly in the mempool. This is achieved through a commit-reveal scheme where a user's transaction is hashed and sent to a trusted relay. The relay shares only the data the user permits (e.g., token amount, contract address) with searchers, who then compete to build profitable bundles. This reduces frontrunning and sandwich attacks by limiting the information advantage of adversarial searchers.

The system's security hinges on the neutrality and liveness of the relay. The relay is a centralized component that receives hashed transactions, facilitates the auction, and forwards the winning bundle to builders. Users must trust that the relay:

• Will not censor transactions.
• Will correctly enforce the user's data-sharing preferences.
• Will not collude with specific searchers or builders.
• Maintains high uptime to prevent transaction delays. This introduces a trusted third-party risk, though the relay's code is open-source and its behavior is publicly verifiable.

A core security benefit for users is the backrunning guarantee. When a searcher includes a user's transaction in a profitable bundle, a portion of that profit is returned to the user as a rebate. This mechanism:

• Incentivizes honesty by aligning searcher profit with user reward.
• Compensates users for the value extracted from their order flow, making certain MEV attacks economically irrational for searchers.
• Relies on the builder to correctly include the rebate payment in the block. The protocol uses conditional transactions to ensure the user's transaction only executes if the rebate is paid.

While MEV-Share protects against public mempool attacks, it creates a new coordination layer between searchers and block builders. Risks include:

• Builder censorship: A dominant builder could refuse to include bundles from certain searchers or for certain users.
• Information leakage: A malicious searcher-builder pair could use private order flow information for their own advantage on other chains or venues.
• Auction manipulation: Collusion could distort the bidding process, reducing competition and the size of user rebates. The protocol's design assumes a competitive builder market to mitigate these risks.

The system must cryptographically guarantee that the data searchers bid on is authentic and will result in a valid on-chain transaction. This is enforced by:

• Hashed commitments: Users submit a hash of their transaction to the relay, which searchers cannot reverse.
• Reveal phase: Only after a winning bundle is selected does the user reveal the full transaction details to the relay for execution.
• Validity proofs: The relay and builders must ensure the revealed transaction matches the commitment and is semantically valid (e.g., correct nonce, sufficient gas). Failure here could lead to failed transactions or wasted gas for searchers.

MEV-Share operates in a complex regulatory gray area. Key considerations include:

• Order flow payment (rebates): These may be viewed as payment for order flow (PFOF), a practice heavily scrutinized in traditional finance.
• Information asymmetry: Selectively revealing transaction data to professional searchers could raise fair access concerns.
• AML/KYC: The relay, as a central coordinator of financial transactions, could become a focus for regulatory enforcement regarding anti-money laundering checks. These factors contribute to adoption risk for large, regulated institutions.