MEV-Share primary sources — 2026-05-08
Classification takeaway
MEV-Share is best cataloged as programmable-private order-flow-auction infrastructure. The key mechanism is not just “private transactions,” but a formal interface for selectively revealing transaction information, composing bundles, and attaching refund conditions so that users, wallets, dapps, searchers, builders, and MEV-Share Nodes can split order-flow value differently than in the ordinary public-mempool path.
Primary sources reviewed
-
Flashbots MEV-Share introduction — https://docs.flashbots.net/flashbots-mev-share/introduction
- Defines MEV-Share as an open-source protocol for users, wallets, and applications to internalize the MEV their transactions create.
- Says users selectively share data about transactions with searchers who bid to include the transactions in bundles.
- Says users can choose how the searcher bid is redistributed, including to themselves, validators, or other parties.
- Describes the MEV-Share Node as the actor that receives user flow, shares selected information with searchers, simulates searcher bundles, and forwards successful bundles to builders with refund conditions.
-
Understanding bundles — https://docs.flashbots.net/flashbots-mev-share/searchers/understanding-bundles
- Explains the
mev_sendBundlestructure and shows how MEV-Share extends bundle APIs with privacy settings, nested bundle composition, and post-execution validity / refund checks. - The privacy-hints section is the clearest source for how the protocol reprices visibility: hints can reveal only hashes, or progressively more data like logs, calldata, function selectors, and full transaction details.
- The bundle-composition section is especially important because it shows MEV-Share is not only about protecting one transaction; it is about permitting ordered collaboration and backrunning around partially hidden flow.
- Explains the
-
Protocol README / specs repo — https://raw.githubusercontent.com/flashbots/mev-share/main/README.md
- States clearly that MEV-Share is an open-source protocol, not a product or company.
- Frames the project as a standardizable interface for order-flow auctions intended to reduce switching costs, increase competition, and counter proprietary exclusive order flow as a centralizing force.
- Lists the main participant classes: orderflow providers, searchers, MEV-Share Nodes, and blockspace providers.
-
Bundle spec — https://github.com/flashbots/mev-share/blob/main/specs/bundles/v0.1.md
- Provides the most concrete technical expression of the mechanism: inclusion windows, nested bodies, refund and refundConfig fields, privacy hints, and builder restrictions.
- Makes clear that redistribution is not just a social promise; it is encoded into the bundle interface.
-
Flashbots Protect MEV refunds — https://docs.flashbots.net/flashbots-protect/mev-refunds
- Shows how MEV-Share appears to end users through Protect RPC.
- Useful because it makes the privacy/refund tradeoff tangible: users can share only hash-level data for maximum privacy or share more hints for better expected refunds.
- Confirms that MEV-Share is infrastructure beneath a wallet-facing product surface rather than a purely theoretical spec.
Whitepaper / technical-doc status
- No canonical standalone whitepaper surfaced in this pass.
- The strongest primary materials were the docs introduction, bundle guide, public protocol README/specs, and the Flashbots Protect refund docs.
Why it stays in the active corpus
- Strong comparison class for MEV Blocker, Primev/mev-commit, Atlas, and UniswapX because it isolates a distinct control surface: programmable visibility plus refund-conditioned order-flow auctions.
- Useful for reasoning about where authority concentrates when a system does not eliminate searchers or builders, but instead rewrites the rules about who gets to inspect order flow and how that rent is redistributed.
- Helps distinguish wallet-facing products from the lower-level protocol interfaces that actually structure order-flow markets.