Skip to main content

Overview

Today, orderflow originators like wallets and dapps do not actively participate in MEV. Their users generate MEV when transacting, but this value is captured by builders, searchers, and validators -- not users, wallets, or dapps.

MEV-share is a protocol that enables users, wallets, and dapps to capture the MEV their transactions create.

Introduction​

The MEV-Share Matchmaker was renamed to the MEV-Share Node to better reflect the role we envision this actor will play in SUAVE. This change will be reflected in our documentation after June 2023. The client library previously named matchmaker-ts has also been renamed to mev-share-client-ts.

What is MEV-share?​

MEV-Share is an open-source protocol for orderflow auctions. It allows users to selectively share data about their transactions with searchers who bid to include the transactions in bundles. Users can choose how the searcher's bid is redistributed -- between themselves, validators, or other parties.

MEV-Share is credibly neutral, permissionless for searchers, and does not enshrine a single block builder. It aims to reduce the centralizing impact of exclusive orderflow on Ethereum while enabling wallets and other sources of order flow to participate in the MEV supply chain.

To start earning MEV refunds from MEV-share, submit your transactions to the Flashbots MEV-Share Node, either by connecting your wallet to the Protect RPC, or sending a private transaction to the MEV-Share Node API.

What is a MEV-Share Node?​

A MEV-Share Node is a service that implements the MEV-Share protocol. It is responsible for merging user transactions with searcher bundles. Flashbots runs a MEV-Share Node on Ethereum mainnet. Users submit their transactions to the MEV-Share Node, which shares select information about them with searchers. Searchers propose transactions for the MEV-Share Node to bundle with the user transactions. Currently we only support backruns. The MEV-Share Node forwards these bundles to a block builder with a requirement that the user is paid a refund percent of the winning searcher's bid.

Connect Your Wallet​

Ethereum users can start earning MEV refunds today by connecting their wallets to Flashbots Protect.

Advanced options
MEV-Share Hints
Builders


ℹ️ By default, users will connect to the Stable configuration, which is tuned by Flashbots to optimize execution speed while protecting users from harmful MEV. This configuration can be modified to include more data. See the Flashbots Protect MEV-Share docs to learn more.

Technical Information​

Wallet users connected to Flashbots Protect do not have to do anything to benefit from MEV-Share. Transactions received by the Protect RPC are automatically forwarded to MEV-Share with the Stable configuration.

Searchers should check out the Getting Started guide for a walkthrough of MEV-Share and how it differs from searching on the mempool.

Wallet/Dapp Developers should check out the Integration Guide for information about MEV-Share and instructions on how to integrate your wallet.

Sending Transactions​

To send transactions directly to Flashbots MEV-Share Node, use a [client library](https://github.com/flashbots/MEV-Share Node-ts) or send a request to the sendPrivateTransaction endpoint with the privacy parameter.

Listening for Transactions​

MEV-Share dispatches data about pending transactions via an SSE event stream. To learn more, see the MEV-Share Event Stream Docs.

Sending Bundles​

Bundles on MEV-Share consist of signed transactions and transaction hashes from the event stream, as well as some metadata about the bundle's validity conditions.

To send a bundle to MEV-Share, use a [client library](https://github.com/flashbots/MEV-Share Node-ts) or send a request to the mev_sendBundle RPC endpoint. For more information about sending bundles, see Sending Bundles.

ℹ️ Currently, MEV-Share only allows constructing bundles containing a single input and a single backrun. If the input is also a bundle, the rule applies recursively to that nested bundle. Concretely this means that searchers can only place hashes in the first position of their bundles; and each bundle may include up to one hash. The MEV-Share Node will reject any bundles that violate these rules. This ensures that searchers cannot frontrun users in-protocol.