MEV in practice: Exclusive Best Orderflow Lists & PBS Tools
MEV is no longer a shadowy edge case. It’s a daily tax, a set of markets, and a growing toolbox. If you build or trade on Ethereum, you’re interacting with it,...
In this article

MEV is no longer a shadowy edge case. It’s a daily tax, a set of markets, and a growing toolbox. If you build or trade on Ethereum, you’re interacting with it, whether you see it or not. The practical question is simple: how do you get safer inclusion and better prices without leaking alpha?
This guide maps where value is extracted, where it’s returned, and which tools actually move the needle in the proposer–builder era.
Why MEV moved from folklore to tooling
Two forces brought MEV into the open. First, sophisticated searchers automated arbitrage, liquidations, and backruns at scale. Second, Proposer-Builder Separation (PBS) split block production into market roles, turning “who gets included” into a competitive pipeline. With markets came incentives, data, and real products.
The result: wallets, dapps, and protocols now negotiate orderflow. Some sell it. Some protect it. The best try to do both, returning a slice to users.
Orderflow auctions: what they are and why they matter
Orderflow auctions (OFAs) are venues where user intent is offered to matchers—searchers, solvers, or builders—who compete to execute it and share surplus. Instead of broadcasting a swap to the public mempool, a wallet submits to an auction that promises price improvement, privacy, or rebates.
The core trade is information for value. You grant controlled visibility into your order in exchange for protection from sandwiching and a better fill.
Quick comparison of common OFA flavors
Different auctions make different privacy and incentive trade-offs. The table sketches the patterns you’ll meet in production.
| Design | Who competes | Privacy model | User benefit | Examples |
|---|---|---|---|---|
| Solver batch auction | Solvers submit netted batch solutions | Intent revealed to solvers, not public mempool | MEV internalization and price improvement | CoW Protocol, 1inch Fusion |
| Dutch/English RFQ | Market makers bid over time | Partial data until fill; on-chain settlement | Competitive quotes, limited leakage | UniswapX, RFQ-based routers |
| MEV-share style | Searchers propose bundles around a protected tx | Selective “signals” (not full calldata) | Backrun revenue rebate; no sandwich | Flashbots MEV-Share, Protect RPCs |
| Private builder routing | Builders race to include private tx | Encrypted or private channel to builder/relay | Reduced sandwich risk; faster inclusion | MEV-Boost Protect routes, custom relays |
These models can stack. A wallet might send a swap to a solver auction first, then fall back to a private builder route if no good fill appears within a deadline.
Tiny scenarios: what “in practice” really looks like
A user submits a 20 ETH to stETH swap through a Protect RPC. Searchers can only see a hash and token pair, not the exact amount. One searcher proposes a backrun capturing an on-chain arb and returns 0.015 ETH to the user as a rebate. The bundle lands; no sandwich, better net price.
Another day, a liquidator targets an undercollateralized vault. A solver batch auction nets the liquidation with a set of arbitrages across two DEXs, reducing gas and slippage. The borrower pays a smaller penalty than in a public mempool race because the solver internalizes MEV in one shot.
Inclusion lists: censorship resistance with teeth
Inclusion lists let the proposer pre-commit to a set of valid transactions that builders must include to be eligible. If a builder tries to censor or dawdle, they lose the block. The list is a safety rail, not a scheduler, but it changes incentives for the worst behavior.
Practically, lists protect transfers, staking exits, or time-sensitive intents from being stalled due to policy filters or economic games. They also give wallets a signal: “txs on this list will make it.”
Two details matter in engineering terms. First, list construction should be cheap and deterministic for proposers. Second, builders need a clear rule: include the list in order unless it conflicts or is invalid; then document the conflict. That clarity keeps the auction competitive while lifting censorship guarantees.
The PBS-era stack: who does what
PBS formalizes roles that used to blur together. Once you know the handoffs, you can place your controls where they count.
- Wallet or dapp captures intent and picks a route. It may try a solver auction, then private submission if needed.
- Searchers and solvers compute bundles or batch solutions that maximize surplus while honoring constraints like no-sandwich.
- Builders assemble a full block from bundles and public mempool, maximizing value under gas and timing limits.
- Relays simulate, sanity-check for validity, and forward the best bid to the proposer.
- Proposer picks the highest-paying valid block, optionally with an inclusion list requirement attached.
A clean mental model helps with debugging, especially when a tx disappears. If you know which hop dropped it, you know which promise failed: privacy, inclusion, or price.
Tooling you can use today
Several production tools support safer routing and better execution. Choose based on your threat model: is your priority price improvement, data minimization, or inclusion guarantees?
- MEV-Boost and relays: Out-of-protocol PBS used by Ethereum validators; enables builder competition and supports private routes.
- Protect/Blocker RPCs: Send swaps privately to cooperating builders or MEV-share venues to avoid sandwiches and get rebates.
- Solver-based DEXes: CoW Protocol and similar systems batch and net trades, internalizing MEV for users.
- Intent protocols and RFQs: UniswapX and RFQ routers that expose minimal info until fill to limit predation.
- Simulation gateways: Pre-trade simulations with slippage and revert checks to avoid bait quotes in volatile blocks.
- Inclusion list clients (experimental): Research implementations you can test on devnets to study censorship safeguards.
Blend them. A wallet can attempt a solver route for price, fall back to a private builder path for safety, and still publish a minimal inclusion list item if the transaction becomes urgent.
Practical guardrails for builders and wallets
You don’t need to solve research problems to ship safer flows. A few defaults go a long way.
Start with routing policy. Decide when you tolerate public mempool and when you require private delivery. Codify thresholds: order size, token liquidity, or user-set privacy mode. Then enforce them in code, not docs.
On settlement, include non-negotiables in your intent: no-sandwich constraint, minimum fill, max gas, and refund rules. If a solver can’t meet them, it shouldn’t win. This narrows the surface for toxic flow.
Observe and adapt. Log per-route slippage, revert rates, and realized rebates. If a builder or relay underperforms, rotate them out. Don’t be sentimental with endpoints.
A simple decision sequence you can implement
This sequence reduces leakage while preserving fill probability for a retail swap.
- Try a solver auction with a tight deadline and a clear minimum-fill constraint.
- If it expires, submit privately to two reputable builders via a Protect RPC with MEV-share signals enabled.
- If both fail within your block deadline, publish to public mempool with widened slippage and a time-based cancel.
You’ll capture price improvement from solvers, avoid most sandwiches via private routing, and still settle in volatile conditions when privacy isn’t worth missing the market.
What to measure to know it’s working
Execution quality compounds. Instrument the obvious and the subtle so you can tell signal from noise.
Track four rates: percentage of swaps privately included, average rebate per notional, sandwich incidence, and missed-block retries. Add two distribution views: slippage by route and inclusion latency by builder or relay. These metrics translate directly into user outcomes and partner selection.
Where it’s heading
The direction is clear: more explicit markets for orderflow, stronger privacy by default, and protocol-level guardrails against censorship. Inclusion lists raise the floor on what must get in. OFAs compete to return surplus rather than extract it. Builders continue to specialize, but their incentives stay aligned by PBS and relay scrutiny.
In the meantime, concrete choices beat abstract purity. Route intent where it’s valued, keep data exposure minimal, and make inclusion someone’s enforceable job—not a wish.


