MEV-Share vs Private Relays: When to Use Each

Answer first — MEV-Share and private bundle relays aren't competitors — they're tools for different jobs. Private relays (Flashbots eth_sendBundle, Titan, beaverbuild, etc.) keep your full bundle sealed from public view until inclusion; the relay sees the bundle, the builder sees it on inclusion consideration, nobody else does. MEV-Share is an Order Flow Auction (OFA) hint protocol — it exposes partial information about pending transactions (a swap is happening on this pool, in roughly this size, but not the exact bytes) so searchers can build OFA-aware bundles that backrun the trigger and refund part of the captured value to the original user. You generally use private relays for production capital (you want zero strategy leakage) and MEV-Share for purpose-built routes where matching with specific user flows is part of the strategy. Most serious operations run both — private as the default, MEV-Share for canaries or specific OFA targets — and keep the budgets separate so one path can't drain the other.

Mastery path

• Flashbots bundles explained
• Best Ethereum private RPCs
• Inclusion probability 101
• MEV-Share vs private relays (current)

The privacy model: what each leaks

So the central trade-off: MEV-Share gives you better matching with specific order flow (users explicitly opting into having their tx hinted at), at the cost of leaking partial signal to the searcher pool. Private relays preserve full secrecy but you find your own opportunities through mempool monitoring rather than via hint-matching.

When private relays are the right tool

• Production capital. Anything you wouldn't be comfortable seeing partially leaked, even as a hint.
• Strategies whose IP is the strategy. If you've found an unusual route or filter that competitors haven't, MEV-Share's hint stream lets adjacent searchers reverse-engineer it from your behaviour patterns. Keep it sealed.
• Backrun strategies on public-mempool flow. You're already monitoring the mempool; the trigger txs are visible to you regardless. No matching benefit from MEV-Share.

When MEV-Share is the right tool

• Routes that benefit from explicit user opt-in. MEV-Share users have signalled they want value-aware execution and are receptive to OFA pricing. The economics tilt toward the searcher who can land on those flows.
• Refund-aware strategies. Some strategies are profitable because they refund a portion to the trigger user (better fill for the user → better order flow → keeps coming). MEV-Share's refundRecipient and refundPercent are first-class citizens.
• Niche pool flows that aren't visible in standard mempool. Some user paths (sandwich-protective wallets, MEV-Share-routing aggregators) only emit hints, not raw txs. The only way to backrun those flows is via MEV-Share.

The inclusion picture

Private relays:

• Inclusion depends on builder coverage of your fan-out and your fee competitiveness.
• Fan-out across Flashbots + Titan + beaverbuild + rsync-builder pushes coverage near 95%.
• Latency to relay matters; sub-150 ms RTT is plenty.

MEV-Share:

• Inclusion depends on builder attention to MEV-Share-routed bundles + the attractiveness of your bid.
• Builder participation is partial — not every builder integrates MEV-Share equally.
• Hint freshness matters: stale hints (>1 second) often mean the trigger's already in a block.

A bundle submitted to one path doesn't automatically work on the other. Schemas differ; submitting MEV-Share-style hints to the standard Flashbots Relay silently fails, and vice versa.

Operational discipline for running both

If you run both lanes:

1. Separate budgets. A bug in one lane shouldn't drain the other.
2. Separate measurement. Track inclusion, refund, and PnL per lane independently. Comparing aggregate numbers across lanes hides which lane is actually working.
3. Default to private. The MEV-Share lane is opt-in for specific strategies, not your fallback.
4. Document who approved MEV-Share use and for which strategies. Enables rollback if hint-leakage shows up as adverse selection later.
5. Throttle hint granularity if you author the trigger flow. Over-revealing hints turns into selling alpha to the searcher pool.

Evaluation matrix

Common mistakes

• Submitting the same bundle to both paths simultaneously. Schemas differ; one or both fails. They're separate products, not redundant infrastructure.
• Assuming MEV-Share inclusion = private-relay inclusion. Different builder-side attention; different headline numbers. Measure each.
• Ignoring refund recipient on MEV-Share. If you don't set it, you leave value on the table that the user could otherwise have received (and that incentivises them to keep using MEV-Share-routed wallets).
• Running MEV-Share without auditing what your hints reveal. Over-specific hints can let other searchers reverse-engineer your filters.

References

• MEV-Share documentation
• Flashbots eth_sendBundle reference
• Best Ethereum private RPCs