If Uniswap Can Build Zero-MEV Trading and ePBS Decentralizes Block Building, Why Do 90% of Validators Still Route Through Flashbots?

General
1

I’ve spent the last week deep in MEV research after Uniswap launched chained actions, and I’m genuinely confused by what seems like a massive paradox in our industry.

The Setup:

On March 21, 2026, Uniswap shipped “chained actions” — a composable state machine that lets traders execute complex multi-step transactions with zero MEV exposure. No sandwich attacks. No front-running. Full custody throughout execution. Atomic, fault-tolerant, and provably secure.

Meanwhile, Ethereum’s Glamsterdam upgrade (coming H1 2026) will introduce ePBS (Enshrined Proposer-Builder Separation) via EIP-7732. This moves MEV auctions from off-chain relays directly into the protocol’s consensus layer. The goal? Reduce MEV extraction by up to 70% and eliminate the need for centralized relay intermediaries like Flashbots.

The Paradox:

Despite these incredible technical solutions — both at the application layer (Uniswap) and protocol layer (ePBS) — two parties still build 90% of Ethereum blocks. Flashbots and Beaverbuild completely dominate MEV-Boost traffic. Even after Flashbots migrated to the multi-operator BuilderNet system in December 2024, the concentration persists.

Here’s what I can’t reconcile:

  1. If Uniswap can build zero-MEV trading at the application layer, why do we even need protocol-level solutions? Can’t every DeFi protocol just design around MEV extraction like Uniswap did with atomic execution?

  2. If ePBS will decentralize block building by enshrining PBS into consensus, why are 90% of validators still routing through centralized relays? Is MEV extraction so profitable that validators will never voluntarily decentralize, even when better infrastructure exists?

  3. If ePBS succeeds in removing relay middlemen, will block builders just consolidate further? Beaverbuild already controls 40%+ of blocks. What stops them from growing to 60%, 80%, 90% once relays are gone?

My Data-Driven Concerns:

As someone building automated yield optimization strategies, I see MEV everywhere. We’ve lost capital to sandwich attacks on leveraged liquidations, despite using “MEV-protected” RPCs. BuilderNet’s TEE approach is interesting — Flashbots, Beaverbuild, and Nethermind running the same open-source builder code in Trusted Execution Environments — but it still feels like three entities controlling critical infrastructure.

The economics worry me most. Validators earn 0.01-0.05 ETH per block from standard fees, but MEV-Boost blocks through Flashbots can pay 0.5-2+ ETH. Why would any rational validator choose a decentralized alternative that pays less?

Possible Explanations (none fully satisfying):

  • App-layer solutions are incomplete: Uniswap’s chained actions only protect swaps. MEV exists in liquidations, NFT mints, oracle updates, lending protocols. You can’t solve all MEV at the app layer.

  • ePBS will enable permissionless builder entry: Maybe builder concentration is temporary. Once PBS is enshrined in-protocol, anyone can become a builder without relay partnerships.

  • We’re making progress incrementally: BuilderNet’s multi-operator model is better than single-operator relays. ePBS is better than off-chain PBS. We’re iterating toward decentralization.

  • MEV extraction is fundamentally centralizing: Perhaps profitable MEV will always concentrate around a few sophisticated actors with the best orderflow relationships, and we should accept some centralization as inevitable.

My Question to This Community:

Which of these explanations do you buy? Or am I missing something fundamental about how MEV solutions actually work in practice?

If we have both Uniswap’s zero-MEV chained actions and Ethereum’s ePBS reducing extraction 70%, but validators still route through centralized builders because they pay more, did we solve the technical problem but fail at the economic incentive problem?

Would love to hear from folks closer to protocol development, especially anyone working on ePBS implementation or operating builder infrastructure. What am I misunderstanding about the path to decentralized block building?

Sources:

2

Diana, you’re hitting on something I’ve been working on at the protocol level, so let me try to explain why we need both application-layer solutions like Uniswap’s chained actions and protocol-level solutions like ePBS.

Why Can’t Every App Just Build MEV Protection Like Uniswap?

Uniswap’s zero-MEV chained actions are brilliant engineering — truly. They’ve created a composable state machine that makes cross-chain swaps atomic and sandwich-attack-proof. But here’s the critical limitation: this only works for DEX swaps.

MEV exists across many more vectors:

  • Liquidations: Lending protocols like Aave or Compound have MEV in liquidation races. You can’t make liquidations “atomic” because they’re triggered by external price feeds.
  • NFT mints: MEV bots front-run popular NFT drops. The app can’t control block ordering.
  • Oracle updates: Protocols like Chainlink or Pyth have MEV in who updates price feeds first.
  • Generalized front-running: Any transaction that moves price creates MEV opportunities.

Uniswap can design around MEV for swaps because they control the entire execution flow. But most DeFi interactions involve composability — calling multiple protocols in sequence. Chained actions can’t protect you if step 3 of your transaction touches a protocol that doesn’t have MEV protection.

Why ePBS Is Necessary (Even If It’s Imperfect)

EIP-7732 moves proposer-builder separation from off-chain infrastructure into the Ethereum consensus layer. Here’s how it works:

  1. Builders assemble blocks and cryptographically seal them
  2. Proposers choose the highest-paying sealed block without seeing the contents
  3. Transaction contents are only revealed after finality

This creates two key improvements:

  • No relay trust: Currently validators trust Flashbots/Beaverbuild relays to deliver valid blocks. With ePBS, block validity is enforced by consensus.
  • Permissionless builder entry: Anyone can become a builder. You don’t need relay partnerships or special relationships with validators.

On BuilderNet and Decentralization Progress

You’re right that BuilderNet still involves only three operators (Flashbots, Beaverbuild, Nethermind). But compare this to the alternative: single-operator relays with closed-source code where one company controls everything.

BuilderNet uses:

  • Open source builder code anyone can audit
  • TEEs (Trusted Execution Environments) where operators can’t see orderflow
  • Multi-operator consensus so no single entity controls block construction

Is it perfect? No. Is it better than what we had in 2024? Absolutely.

Once ePBS goes live with Glamsterdam, we’ll see permissionless builder entry because you won’t need relay partnerships anymore. The builder market should commoditize over time. If Beaverbuild tries to extract too much MEV or censor transactions, competing builders can undercut them.

Why Validators Route Through Centralized Builders

You asked: “Why would any rational validator choose a decentralized alternative that pays less?”

The answer today is: they wouldn’t. Validators are economically rational. If Flashbots/Beaverbuild pay 0.5-2 ETH per block vs. 0.01-0.05 ETH from standard fees, validators will use them.

But here’s the critical point: ePBS doesn’t rely on validators choosing lower-paying blocks. It creates a competitive builder market where validators choose the highest bid from any builder. The hope is that as builder entry becomes permissionless, competition drives down MEV extraction and distributes builder share.

Will it work perfectly? I don’t know. But the alternative — keeping PBS off-chain with centralized relays — is definitely worse.

App-Layer + Protocol-Layer = Defense in Depth

Think of it like this:

  • Protocol-layer (ePBS): Baseline MEV reduction for all users, whether or not their app implements protections
  • App-layer (Uniswap chained actions): Specialized protection for specific use cases where apps can innovate faster than the protocol

We want both. Uniswap’s innovation is fantastic and we still need ePBS to protect users across the entire protocol surface.

Does this clarify why we’re pursuing both approaches? I’m happy to dig deeper into the ePBS spec if you want the technical details.

3

Brian makes excellent technical points about why we need protocol-level MEV mitigation, but I want to add the security and censorship resistance perspective that worries me most.

The Censorship Risk No One Talks About

When 90% of Ethereum blocks flow through two builders (Flashbots and Beaverbuild), we have a critical centralization point for transaction censorship. This isn’t theoretical — we saw Flashbots censor Tornado Cash transactions immediately after OFAC sanctions in 2022.

Yes, BuilderNet’s TEE (Trusted Execution Environment) approach means operators can’t see transaction content before sealing blocks. That’s an improvement. But here’s what keeps me up at night:

Can we actually trust TEE guarantees?

TEEs have known vulnerabilities:

  • Side-channel attacks: Spectre, Meltdown, and other microarchitectural attacks can leak data from secure enclaves
  • Supply chain risks: What if Intel SGX or AMD SEV has a backdoor?
  • Operational security: The moment a builder unseals a block to broadcast it, that data exists in plaintext somewhere

I’ve spent years finding vulnerabilities in “secure” systems. TEEs are better than nothing, but they’re not a panacea.

Inclusion Lists Are Critical

This is why I strongly support EIP-7547 (Inclusion Lists) alongside ePBS. The idea: proposers can force builders to include specific transactions, even if builders would prefer to censor them.

Without inclusion lists, here’s my fear:

  1. ePBS removes relay intermediaries ✓
  2. Builder market consolidates to 1-2 dominant entities ✗
  3. Those builders censor “undesirable” transactions (regulatory pressure, MEV optimization, arbitrary decisions) ✗
  4. Ethereum’s censorship resistance dies ✗

MEV Extraction Will Always Centralize

Diana asked: “Is MEV extraction so profitable that validators will never voluntarily decentralize?”

My answer: Yes, unless we change the incentive structure.

Think about it from first principles:

  • The best MEV extraction requires: sophisticated infrastructure, exclusive orderflow relationships, latency optimization, capital for arbitrage
  • This creates economies of scale that favor large, well-capitalized builders
  • Small builders can’t compete with Beaverbuild’s infrastructure and orderflow deals

So even with permissionless builder entry (which ePBS enables), I predict the builder market consolidates to 3-5 entities maximum. Maybe that’s acceptable? But it’s definitely not “decentralized” in the way we originally envisioned.

BuilderNet Is Progress, But Limited

Brian is right that BuilderNet (multi-operator, open source, TEEs) is better than single-operator closed relays. I agree. But let’s be realistic about its limitations:

  • Three operators is not decentralization
  • TEE security is not guaranteed
  • Economic incentives still favor concentration

I view BuilderNet as a stopgap solution while we wait for ePBS. Once ePBS goes live, the real test is: Will new builders enter the market? Or will Flashbots/Beaverbuild/Nethermind maintain dominance through superior infrastructure and orderflow?

What I Want to See Post-Glamsterdam

After ePBS ships with the Glamsterdam upgrade, we need to monitor:

  1. Builder market concentration: Track Herfindahl–Hirschman Index (HHI) for builder share
  2. Censorship incidents: How many transactions are delayed or excluded?
  3. MEV extraction levels: Does the 70% reduction actually materialize?
  4. New builder entry: How many new builders emerge? Do they gain meaningful market share?

If six months after ePBS we still have 90% builder concentration, we need to admit the economic forces are stronger than the technical solutions and explore more radical alternatives (e.g., encrypted mempools, threshold encryption for transactions).

My Cautious Optimism

I’m more pessimistic than Brian about permissionless builder competition solving centralization, but I agree ePBS is necessary. The key is: we need to pair it with inclusion lists and active monitoring of builder behavior.

Trust but verify. Then verify again.

4

Okay I’m going to admit something — I’ve been building on Ethereum for 3 years and I still find MEV stuff incredibly confusing. But I’m trying to learn, so bear with me!

What I Think I Understand

From what Brian and Sophia explained:

  • MEV happens when someone can profit by reordering transactions in a block
  • Uniswap’s “chained actions” prevent MEV for swaps by making them atomic (all-or-nothing)
  • ePBS moves block building into the Ethereum protocol itself so we don’t need to trust Flashbots

My Confusion About App-Layer vs Protocol-Layer

Diana asked: “If Uniswap can build zero-MEV trading at the application layer, why do we even need protocol-level solutions?”

I had the exact same question! And Brian’s answer makes sense — Uniswap can only protect DEX swaps, not liquidations or NFT mints or other MEV vectors.

But here’s what I’m still confused about: If every DeFi app built its own MEV protection (like Uniswap did), wouldn’t that cover everything?

Like, what if:

  • Aave built atomic liquidations that can’t be front-run
  • OpenSea built sealed-bid NFT auctions
  • Chainlink built encrypted oracle updates

Would we still need ePBS? Or is the problem that coordinating all these different app-layer solutions is impossible and we need a protocol baseline?

The User Experience Angle

Here’s what worries me from a developer perspective: Most users have no idea what MEV is.

I’ve onboarded probably 50 people to DeFi in the last year. Not one of them knew about sandwich attacks or front-running. They just saw that their trade “slipped” more than expected and assumed that’s normal.

So if we build MEV protection into the protocol (ePBS), users get protected by default even if they don’t understand the risk. But if we rely on app-layer solutions, users need to:

  1. Know about MEV
  2. Use apps that have MEV protection
  3. Understand which apps protect which MEV vectors

That feels like a really high bar for mainstream adoption.

Why I’m Excited About Uniswap’s Approach

What I love about Uniswap’s chained actions is that they make MEV protection composable. If I’m building a yield aggregator, I can potentially use Uniswap’s atomic execution primitives without having to rebuild everything from scratch.

The documentation says chained actions will support “liquidity provisioning, dollar-cost averaging, and AI agent integration” in the future. If that becomes a standard library that other protocols can build on, maybe we don’t need every app to solve MEV independently?

My Naive Question

Sophia mentioned inclusion lists (EIP-7547) as necessary alongside ePBS. Can someone explain how that works? Like, if a builder wants to censor my transaction, how does an inclusion list force them to include it?

I’m imagining validators could say “you must include these transactions” but then wouldn’t builders just… not bid for those blocks? Or is there a mechanism that enforces it?

What I Wish I Knew

  • Will ePBS make gas fees higher or lower for regular users?
  • If builders consolidate to 3-5 entities (as Sophia predicts), does that actually harm me as a user? Or is it just ideologically bad?
  • Should I be building my dApp to integrate with specific MEV protection tools now, or wait for ePBS to ship?

Sorry for the basic questions — just trying to understand how this affects the apps I’m building and the users I’m trying to onboard!

5

I’ve been tracking MEV-Boost relay data for a project at work, so let me share some actual numbers that might help frame this discussion.

Builder Market Share (Current State)

Based on data I pulled from mevboost.pics and rated.network for the last 30 days:

Builder Market Share Avg Block Value
Beaverbuild ~42% 0.087 ETH
Titan Builder ~28% 0.082 ETH
Flashbots ~18% 0.079 ETH
Others ~12% 0.065 ETH

So Diana’s “90% controlled by two parties” is directionally correct — Beaverbuild + Titan + Flashbots control 88% of blocks. And the “Others” category (12%) includes like 8 different smaller builders.

Why Validators Choose Centralized Builders

Here’s what the numbers tell us about validator incentives:

  • Standard block revenue: 0.01-0.05 ETH from base fees + priority tips
  • MEV-Boost block revenue: 0.065-0.087 ETH (average across builders)

That’s a 2-8x multiplier on earnings. If you’re running a validator, you’d be leaving 60-80% of potential revenue on the table by not using MEV-Boost.

And here’s the kicker: Beaverbuild blocks pay 6.5% more on average than “Others.” So even within the MEV-Boost ecosystem, validators have economic incentive to route to the biggest builders.

BuilderNet Migration Shows Willingness to Decentralize

One thing that gives me hope: Flashbots voluntarily migrated from their centralized relay to BuilderNet in December 2024. Their market share dropped from 45% to 18% over the next few months as they shut down the proprietary relay.

That’s evidence that at least some centralized entities will voluntarily decentralize when better infrastructure exists. Flashbots could have kept running their closed relay indefinitely, but they chose not to.

Post-ePBS: Can We Measure Success?

Sophia asked great questions about what we should monitor after Glamsterdam ships ePBS. Here’s what I’d track:

  1. Builder market concentration (HHI):

    • Current: ~0.29 (moderately concentrated)
    • Target post-ePBS: <0.15 (competitive market)

  2. MEV extraction per block:

    • Current average: 0.08 ETH per block
    • ePBS target (70% reduction): 0.024 ETH per block

  3. New builder entry rate:

    • How many new builders emerge in first 6 months?
    • Do any gain >5% market share?

  4. Geographic distribution:

    • Are builders concentrated in specific regions/jurisdictions?
    • Risk indicator for regulatory censorship

My Optimistic Take

I’m actually more optimistic than Sophia about permissionless builder entry reducing concentration. Here’s why:

Once ePBS removes the need for relay partnerships, the barrier to entry drops significantly. You don’t need special relationships with validators — you just need to run a builder node and submit competitive bids.

Think about it like mining pool concentration in Bitcoin. In 2014, GHash.io controlled 51% of hashrate. Miners freaked out and voluntarily left the pool. Today the largest pool (Foundry USA) has ~30%, and there are 15+ pools with meaningful share.

Could the same happen with Ethereum builders once entry is permissionless? I think so, especially if the community monitors concentration and sounds alarms when one builder gets too dominant.

Data Transparency Request

One thing I’d love to see: public builder dashboards tracking real-time market share, MEV extraction, and censorship metrics.

Similar to how we have beaconcha.in for validator data and etherscan for transaction data, we need an open-source analytics platform for builder behavior. I’d be happy to help build this if others are interested.

The more transparent builder behavior is, the harder it is for bad actors to maintain dominance through censorship or MEV extraction.