Solana
Simulated route
$124.50 model
Example
Ethereum
Private bundle
$840.12 model
Example
BNB
Liquidation test
$45.20 model
Example
Base
Arbitrage test
$12.05 model
Example
Solana
Jito bundle
$310.00 model
Example
Polygon
Route check
$8.45 model
Example
Solana
Simulated route
$124.50 model
Example
Ethereum
Private bundle
$840.12 model
Example
BNB
Liquidation test
$45.20 model
Example
Base
Arbitrage test
$12.05 model
Example
Solana
Jito bundle
$310.00 model
Example
Polygon
Route check
$8.45 model
Example
InfraConversionэтап⏱ 5минута чтения

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, et

MEV-Share vs private bundle relays comparison
FR
Команда ФРБСпециалисты по МЭВ
Последнее обновление
#mev-share#private relays#flashbots#privacy#inclusion#ofa

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

The privacy model: what each leaks

Property Private relays MEV-Share
Public mempool visibility None None
Relay sees the full bundle Yes Yes
Builder sees the bundle At inclusion-evaluation time At inclusion-evaluation time
Other searchers see the bundle Never They see the hint — partial info designed for matching
Trigger user sees the bundle Never Identifies as the matched search target via the protocol

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

Criterion Private relays MEV-Share
Privacy of strategy IP Full Partial (hints)
Inclusion control Direct relay agreements + fan-out Builder appetite for hint-matched flow
Refund mechanics Manual / strategy-built First-class via refundRecipient / refundPercent
Right for production capital Default Specific routes only
Right for canaries Yes Yes
Right for matching specific flows Mempool monitoring path Native fit

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.

When MEV-Share Makes Strategic Sense

Despite the complexity, MEV-Share creates specific value in situations that private relays alone can't handle:

Order flow access: If you're building a DEX aggregator, wallet, or DEX front-end, MEV-Share lets you route your users' flow to searchers while returning a portion of extracted MEV to those users. This creates a user-aligned incentive structure that purely private mempool routing doesn't offer.

Refund-enhanced strategy performance: For searchers who work on tight-margin opportunities, the refund mechanic can flip marginal strategies positive. A strategy earning $8 gross after gas might be unprofitable without a refund share, but profitable with a 40% refund on extracted MEV returned from the hint-matched searcher.

Strategies that depend on pending-flow context: Some MEV strategies benefit from knowing that a specific large pending transaction exists — even without full details. MEV-Share's hint system provides this signal for opted-in transactions, creating a legitimate market for pending-flow signals that previously required either a private relay relationship or public mempool scraping.

The practical guidance for 2026: run private relays as your primary path, treat MEV-Share as a specialized secondary lane for specific strategies, and audit hint granularity carefully before production deployment.

References

Шаг после прочтения

Запустить панель управления FRB

Подключите свой кошелек, подключите клиент узла к 6-значному PIN-коду и назначьте контракт, упомянутый выше.

Нужен установщик?

Загрузите и проверьте FRB

Загрузите последнюю версию установщика, сравните SHA-256 с версиями, а затем следуйте контрольному списку безопасного запуска.

Проверьте выпуски и SHA‑256
Делиться𝕏 Твиттерв LinkedInf Facebook

Похожие статьи

Дальнейшее чтение и инструменты

Обсуждение

Примечаний пока нет. Добавьте первое наблюдение или поделитесь ссылкой со своей командой на X (@MCFRB).

Оставить заметку
Заметки хранятся только локально в вашем браузере.

Контролируйте пульс

Расширьте свое исполнение

Увеличьте свои преимущества, изучив полный набор инструментов FRB. От телеметрии институционального уровня до готовых к экспорту сценариев стратегии.

CTA

Установить агент FRB

Загрузите проверенные двоичные файлы Windows и проверьте SHA-256.

CTA

Прочтите документацию по быстрому запуску

Поделитесь 15-минутным процессом настройки с отделом эксплуатации и обеспечения соответствия.

CTA

Запустить панель управления

Подключайте клиентов узла и отслеживайте Ops Pulse в режиме реального времени.

Готовы развиваться?

Сделайте следующий шаг

Независимо от того, проверяете ли вы безопасность терминала или запускаете свой первый пакет, путешествие по FRB начинается здесь.

Рекомендуется

Установить агент FRB

Безопасная сборка Windows. Проверено через SHA-256 для максимальной целостности.

Рекомендуется

Прочтите документацию: краткое руководство

Освойте настройку за 15 минут. От сопряжения кошелька до первого пакета.

Рекомендуется

Запустить панель мониторинга

Контролируйте свой Ops Pulse и управляйте маршрутами транзакций в режиме реального времени.