MEVDAO

What Is MEV-Share? How Flashbots Pays Users Back for Their Order Flow

By Merunas Grincalaitis · · 9 min read · 0 views

By Merunas Grincalaitis, founder of MEV DAO and a developer who builds MEV, sniping and trading bots on Ethereum. Last updated: Oct 29, 2026.

TL;DR: MEV-Share is an open-source order flow auction run by Flashbots. You send your transaction privately, MEV-Share shows searchers a few selected "hints" about it, and searchers bid to place a backrun right after it. If a backrun lands, most of the profit comes back to you: by default 90% goes to the address that signed the transaction and the rest goes to the validator. Searchers never see your full signed transaction, so they can trade after you but not in front of you. If you use the Flashbots Protect RPC, you are already in MEV-Share without doing anything else.

I've been on both sides of this. I've sent swaps through Protect and seen a small ETH refund arrive afterwards, and I've written backrun bots that listen to the MEV-Share stream. The idea is simple. The details, which hints you share and who gets the money, are where it gets interesting.

What is MEV-Share in simple terms?

MEV-Share is a way for the person who creates MEV to get paid for it. When you make a big swap on Uniswap, you move the price. That price move creates an arbitrage opportunity for whoever trades right after you. Normally a searcher captures that value and the user gets nothing.

MEV-Share flips that. In the Flashbots docs it is described as a protocol "for users, wallets, and applications to internalize the MEV that their transactions create." The technical name for this is an order flow auction: searchers compete for the right to trade after your transaction, and the winning bid is mostly paid back to you.

Flashbots says the design is permissionless for searchers and doesn't lock you into a single block builder. Any searcher can connect, and bundles can be sent to more than one builder.

How does MEV-Share work, step by step?

The flow has four actors: you (or your wallet), the MEV-Share Node, searchers, and block builders. Here is what happens to one transaction.

  1. You send the transaction privately. Either your wallet uses the Flashbots Protect RPC, or an app sends it straight to the MEV-Share Node API. It never touches the public mempool.
  2. The node shares hints. The MEV-Share Node publishes a partial view of your transaction on an event stream. What it shares depends on your privacy settings.
  3. Searchers bid with partial bundles. A searcher who spots an opportunity builds a bundle that says "the user's transaction (by hash), then mine." They never get your signed bytes, only the hash.
  4. The node simulates and forwards. The node simulates each bundle and sends the ones that work to builders, with a condition attached: the user must be paid a set share of the MEV. Flashbots documents the default as 90%.

The thing that makes this safe for users is step 3. A searcher can only reference your transaction by its hash and append their own transaction after it. That rules out front-running by design. It is the same reason a sandwich attack can't be built through MEV-Share: a sandwich needs a transaction in front of yours.

The node itself was originally called the "MEV-Share Matchmaker." Flashbots renamed it in mid-2023, and the client library matchmaker-ts became mev-share-client-ts. Older blog posts and tutorials still use the old names, which confuses people.

What are MEV-Share hints?

Hints are the pieces of your transaction that searchers are allowed to see. Sharing more gives searchers more to work with, which usually means bigger refunds. Sharing less keeps more private.

According to the Protect MEV refunds page, the default Protect setup shares the transaction hash and default_logs, which are partial logs showing the pool and the fact that a swap happened on Curve, Balancer, and Uniswap V2/V3/V4-style pools. That's enough for a searcher to know "something swapped in this pool" without knowing the exact size or direction.

The hint types available in mev_sendBundle are:

Hint What a searcher sees
hash Only the transaction hash
calldata The input data of the call
contract_address The address being called
function_selector The 4-byte function signature
logs Event logs emitted when it runs
tx_hash The hash, shared as part of a bundle
full Everything except the signature

If you want maximum privacy, Flashbots suggests setting only the hash hint: https://rpc.flashbots.net?hint=hash. You still get front-running protection, but searchers have very little to go on, so refunds become rare.

How much do you get back from MEV-Share?

The honest answer is: usually nothing, sometimes a little, occasionally something worth having. A refund only happens when your transaction creates a profitable backrun. A plain ETH transfer or a small swap in a deep pool creates no opportunity, so there is nothing to share.

When there is an opportunity, the Protect settings guide says the default sends 90% of the MEV refund to tx.origin, the address that signed the transaction, and the remaining 10% to the validator. The refund arrives as ETH to that address.

There is a second, separate refund that people mix up with MEV-Share. Flashbots Protect also gives gas fee refunds when your transaction could have landed for less than you paid. Per the gas refund docs, these come from BuilderNet, they apply only to blocks BuilderNet lands, and transactions that you also sent to other RPCs, or that showed up in the public mempool, are excluded. So if you care about refunds, don't broadcast the same transaction everywhere at once.

How do searchers use MEV-Share?

This is the part I spend most of my time on. A MEV-Share searcher bot is a backrun bot with a smaller view of the world.

Listening. Flashbots publishes events on a Server-Sent Events stream at https://mev-share.flashbots.net (with a Sepolia version for testing). You open an HTTP GET and events arrive as they happen; the stream sends a :ping every 15 seconds when it's quiet. The official clients are mev-share-client-ts for TypeScript and Paradigm's mev-share-rs for Rust.

Deciding. Each event gives you whatever hints the user allowed. With default logs you know which pool was touched, but often not the size or direction. Good bots keep a local copy of pool state and estimate both possible directions before bidding.

Bidding. You submit a bundle with mev_sendBundle. It's similar to a normal Flashbots bundle, but the body can contain the user's transaction by hash, followed by your signed transaction. It also has inclusion (target block range), optional validity (refund settings), and optional privacy (hints and which builders to send to). Flashbots notes that its own builder always receives the bundle, even if you list others.

Paying. Your bid is effectively the share of profit you agree to give up. If the user is owed 90% of the MEV, your bot keeps the remainder after gas. That is why MEV-Share backruns are a volume game with thin margins.

I wrote a full walkthrough of the strategy in Backrunning bot on Ethereum: the first MEV-Share strategy, so I won't repeat the code here.

Is MEV-Share the same as Flashbots Protect?

No, but they're connected. Flashbots Protect is the RPC you point your wallet at. MEV-Share is the auction that runs behind it. Every transaction sent through Protect goes through the MEV-Share Node with your chosen hints, which is why Protect users are automatically eligible for refunds.

You can use MEV-Share without Protect. Wallets and apps that send order flow can integrate the MEV-Share Node API directly and set their own hints and refund split. That's the "order flow provider" path in the docs.

Protect also has a "fast" mode at https://rpc.flashbots.net/fast. In that mode, transactions go to all registered builders, validators get a bigger share of the refund to improve inclusion odds, and full transaction details (without signatures) are shared with searchers running inside TEEs, trusted execution environments. Searchers outside TEEs still only see the hints you chose. It's a trade-off: faster inclusion, more data shared with vetted searchers.

If you're choosing between private RPCs, I compared the main two in Flashbots Protect vs MEV Blocker. MEV Blocker runs its own backrun auction with a similar idea.

What are the limits of MEV-Share?

MEV-Share is a good deal for users, but it isn't magic.

  • It only protects the path it controls. If you send the same transaction to the public mempool too, a sandwich bot can still see it there.
  • Refunds depend on hints. Maximum privacy means minimum refunds. There's no setting that gives you both.
  • It's about backruns. MEV-Share doesn't touch other kinds of MEV, like the price you get from your own slippage settings. A loose slippage limit is still a gift to someone. My guide on MEV protection covers the settings that matter.
  • Inclusion can be slower. Private transactions only land when a builder that received them wins the block. Most of the time this is fine, but it is a dependency on the builder market. If you want to understand that market, see what MEV-Boost is.

Frequently asked questions

What is MEV-Share?

MEV-Share is an open-source order flow auction from Flashbots. Users send transactions privately, searchers see selected hints and bid to backrun them, and most of the resulting MEV is refunded to the user.

Is MEV-Share safe to use?

For users, yes in the sense that searchers only get the hints you allow and can only place transactions after yours, not before. It doesn't protect you if you also broadcast the same transaction publicly.

How do I get MEV-Share refunds?

Point your wallet at the Flashbots Protect RPC, https://rpc.flashbots.net, or send transactions to the MEV-Share Node API. Refunds are paid automatically to the address that signed the transaction when a backrun lands.

What percentage of MEV does MEV-Share refund?

Flashbots documents the default as 90% of the MEV refund to the transaction signer and 10% to the validator. Order flow providers can configure the split, and Flashbots says the default may change as it tunes the system.

What is the MEV-Share SSE event stream?

It's the endpoint searchers listen to for new events, at https://mev-share.flashbots.net for mainnet. It uses Server-Sent Events, so you subscribe with a normal HTTP GET and receive pending transaction hints as they arrive.

Can searchers front-run my transaction through MEV-Share?

Not through MEV-Share itself. Searchers never receive your signed transaction, only its hash and hints, so they can only bundle their own transaction after yours.

For most people, MEV-Share is something you turn on once and forget, and that's fine. If you want to go the other way and build a bot that bids in it, that's the kind of work I do at MEV DAO through custom MEV bot development. You can also subscribe for more guides like this one.

← More on Flashbots & MEV Protection All articles