Best MEV Relays by Chain: A Documented Route Map
**Answer first** - There is no universal "best MEV relay." Ethereum and Solana expose different submission models. Flashbots documents target-block bundles and optional multiplexin
Answer first - There is no universal "best MEV relay." Ethereum and Solana expose different submission models. Flashbots documents target-block bundles and optional multiplexing to multiple builders. Jito documents same-slot Solana bundles that execute sequentially and atomically if selected. Neither an accepted request nor a returned identifier proves inclusion. Other chains require separate provider and chain documentation.
What counts as a relay or bundle route?
Use the terms precisely:
- A public RPC accepts ordinary transactions and may rebroadcast them.
- A private transaction endpoint changes pre-inclusion visibility and routing for one transaction.
- A bundle API accepts an ordered transaction group with provider-specific execution rules.
- A builder or block engine evaluates submissions for possible inclusion.
- A private RPC service is not automatically a bundle relay.
This distinction matters because copying Ethereum assumptions to Solana, an L2 sequencer, or another EVM chain can produce incorrect failure handling.
Documented route map
| Network | Documented path | What the documentation establishes | What it does not establish |
|---|---|---|---|
| Ethereum mainnet | Flashbots bundle API | Ordered transactions can target a block; the API supports builder multiplexing | Inclusion, execution quality, or profit |
| Solana | Jito Block Engine | Up to five signed transactions can execute sequentially and atomically within one slot | That a returned bundle ID will land on-chain |
| Other EVM chains and L2s | Chain- or provider-specific | Only the current provider documentation can define privacy, ordering, and fallback behavior | Flashbots-compatible semantics by default |
The table is a capability map, not a ranking. Endpoint availability, policies, pricing, builder participation, and regional performance can change.
Ethereum: Flashbots bundles and multiplexing
Flashbots defines a bundle as one or more transactions submitted to a builder for a target block. The transactions are evaluated in the order supplied. Some APIs also allow a sender to select multiple builders through documented parameters.
A safe implementation should:
- Simulate the exact bundle against an appropriate state reference.
- Define the target block and expiry behavior.
- Record which builders receive the submission.
- Treat API acceptance as receipt, not inclusion.
- Confirm the resulting transaction hashes on-chain.
- Reconcile gas, builder payments, and failed or expired attempts.
Multiplexing broadens the set of builders that can evaluate a submission. It is not evidence of a particular inclusion rate.
Solana: Jito bundles
Jito documents bundles as groups of up to five signed transactions. They are processed in listed order and atomically within one slot if selected. The bundle participates in an auction that considers its tip, and the sender must query bundle status after submission.
A production workflow should keep three states separate:
- Received: the block engine returned a bundle identifier.
- Landed: the bundle appears in a slot.
- Confirmed: the signatures reach the chosen commitment level and costs are reconciled.
Do not describe "received" as "executed." Jito explicitly notes that a bundle identifier does not guarantee on-chain landing.
How to evaluate any provider
Before using a route, capture this evidence:
| Check | Required record |
|---|---|
| Interface | Current official API documentation and version |
| Privacy | Exact statement about rebroadcast or pre-inclusion visibility |
| Ordering | Provider-defined ordering and atomicity rules |
| Failure behavior | Revert, expiry, replacement, and partial-execution rules |
| Fees | Network fees, tips, builder payments, and provider fees |
| Observability | Request ID, bundle ID, transaction hashes, and status method |
| Fallback | When fallback occurs and whether it changes privacy assumptions |
| Measurement | Timestamped local tests from the operator''s own region |
Latency and inclusion results are environment-specific. Publish them only with a reproducible method, sample window, region, and configuration.
Where FRB fits
FRB Agent is a Windows desktop execution assistant for user-configured EVM and Solana workflows. It is not a relay and does not replace provider documentation. Operators remain responsible for endpoint selection, fee caps, simulation settings, and on-chain confirmation.
Use the private bundle workflow to understand the product boundary, then review the simulation workflow before any controlled live test.
For route selection, separate three adjacent questions: use the private mempool endpoint guide to evaluate visibility and fallback policies, the Ethereum private RPC guide to distinguish wallet protection from searcher submission, and the Jito bundle guide for Solana-specific semantics.
FAQ
Does private submission ensure inclusion?
No. It changes routing and, depending on the provider, visibility or ordering rules. Selection and on-chain inclusion still depend on network state and provider behavior.
Is a private RPC the same as a bundle relay?
No. A private transaction endpoint may accept one transaction without supporting ordered multi-transaction bundles.
Should one configuration be reused across chains?
No. Confirm the route, ordering, fee, and fallback semantics from current documentation for each network.
Primary sources
Related Articles
Further reading & tools
Discussion
No notes yet. Add the first observation, or share the link with your team on X (@MCFRB).