MEV-Boost Achieved Out-of-Protocol PBS, But Glamsterdam Brings ePBS—Does Removing Relay Middlemen Actually Improve Decentralization?

So MEV-Boost has been running for over two years now, and ~90% of Ethereum validators are using it. It’s working pretty well as an out-of-protocol solution for proposer-builder separation. But with Glamsterdam coming in H1 2026, we’re about to get ePBS (Enshrined Proposer-Builder Separation) hardcoded into the protocol itself.

The pitch is straightforward: ePBS removes the relay middlemen. No more trusting Flashbots, bloXroute, or the handful of other relays to honestly forward blocks without censoring transactions. Everything moves on-chain with cryptographic guarantees.

But I’m genuinely curious: does this actually improve decentralization, or are we just shifting where the trust bottleneck lives?

What We’re Getting With ePBS

Under Glamsterdam, EIP-7732 brings PBS directly into consensus. Block builders assemble blocks and cryptographically seal the contents. Proposers (validators) simply choose the highest-paying sealed block without being able to see what’s inside until after finalization. This reduces MEV manipulation opportunities and removes the need for external relays entirely.

On paper, this is a huge trust improvement. Currently we’re trusting 8 active relays, with the top 5 controlling over 90% of block flow. That’s a centralized chokehold—governments could compel these relays to censor transactions, and we’d have no recourse except exit to non-relay block building (which means leaving MEV rewards on the table).

The Builder Centralization Problem

Here’s what worries me: removing relays doesn’t solve the builder centralization problem. Between late 2023 and early 2024, just three builders produced nearly 80% of all Ethereum blocks. Research shows that under ePBS, the Gini coefficient for builder profits rises from 0.17 (pretty equitable) to 0.84 (extremely concentrated). That’s because sophisticated MEV extraction requires serious infrastructure—low-latency connections to DEXs, private order flow from wallets, complex optimization algorithms.

So we remove 8 relay chokepoints, but we’re left with 3 builder chokepoints. Did we win?

The “Yes, But” Arguments I Keep Hearing

“Proposers stay decentralized, and that’s what matters.” True—proposer stakes evolve as a martingale (fancy math term meaning long-run stake distribution is preserved). So validator decentralization remains intact even as builders centralize. But if three builders control 80% of block production, what happens when regulators pressure them to censor?

“ePBS removes external trust assumptions.” Also true. Under MEV-Boost, we trust relays not to steal MEV, withhold blocks, or censor transactions. Under ePBS, those actions become provably attributable on-chain. That’s a genuine security improvement.

“The censorship problem exists either way.” Fair point. Under MEV-Boost, relays can censor. Under ePBS, builders can censor. In both cases, we need fallback mechanisms (like proposers building their own blocks) to maintain liveness. ePBS doesn’t create censorship risk; it just moves where that risk lives.

What Actually Changes

The way I see it, ePBS is a security upgrade but not necessarily a decentralization upgrade:

  • Security wins: No more trusting external relays. Block withholding attacks become attributable. Proposers can’t steal MEV because blocks are sealed before selection.

  • Decentralization neutral: We go from 8 relay bottlenecks to 3 builder bottlenecks. Proposers remain decentralized, but block contents still flow through a few hands.

  • Censorship resistance: Slightly better? If a builder censors, at least it’s on-chain and attributable. But enforcement mechanisms are still unclear.

Open Questions

  1. Does builder centralization matter if proposers are decentralized? The validator set chooses blocks, but builders control what goes in them. Where’s the balance of power?

  2. What happens in the first censorship incident? When a government compels a major builder to block certain transactions, will proposers actually fall back to self-building and sacrifice MEV rewards? Or will economic incentives win?

  3. Is this just Protocol Maturity 101? Maybe ePBS is simply the natural evolution—battle-test solutions out-of-protocol (MEV-Boost), then enshrine them once we understand the tradeoffs. Expecting ePBS to solve all MEV problems is unrealistic.

I’ve been working with the ePBS spec implementations, and I genuinely think it’s good engineering. The trust model is cleaner. The attack surface is smaller. But I’m not convinced we should call this “more decentralized”—we’re replacing one kind of intermediary (relays) with another (builders), and builders might actually be more centralized than relays were.

What do you all think? Am I overthinking the builder centralization angle? Or is this something we need to address before claiming Ethereum has solved the MEV problem?


Sources:

Great breakdown, Emma! You’re hitting on exactly the right tension.

I’ve been following the ePBS spec development pretty closely (submitted some comments on EIP-7732 actually), and your framing as “security upgrade, not necessarily decentralization upgrade” is spot-on.

The Relay Trust Problem Was Real

To give some context on why ePBS matters: under MEV-Boost, relays had to be trusted for three critical things:

  1. Honest block forwarding - relay promises to send you the highest-paying block
  2. No MEV theft - relay sees unsealed blocks and could theoretically front-run or steal MEV
  3. No censorship - relay could filter transactions before passing blocks to validators

That’s a LOT of trust. And we only have 8 relays, with Flashbots + bloXroute + Agnostic + Ultra Sound controlling most flow. When people say “Ethereum is decentralized,” pointing to 8 gatekeepers who control 90%+ of block production is… awkward.

Why Builders Might Actually Be Worse

But here’s where your builder centralization concern becomes crucial. At least with 8 relays, there’s SOME distribution. With builders, we’re talking about literally 3 entities producing 80% of blocks in recent months.

And unlike relays (which are relatively simple forwarding infrastructure), builders need:

  • Sub-millisecond DEX connections
  • Private order flow deals with wallets (MetaMask, Coinbase Wallet, etc.)
  • Sophisticated optimization algorithms for MEV extraction
  • Massive capital to competitively bid for block space

This creates natural economies of scale that favor the biggest, most well-funded builders. The Gini coefficient going from 0.17 → 0.84 is WILD. That’s basically “moderately equitable” to “oligopoly.”

The Proposer Fallback Question

You asked: “When a government compels a major builder to block certain transactions, will proposers actually fall back to self-building?”

I think the answer is NO in practice, even though it’s technically possible. Here’s why:

  • Top validators earn 10-15% MORE revenue via MEV-Boost than vanilla block building
  • If proposers self-build to include censored transactions, they sacrifice that premium
  • Economic incentives strongly favor selecting from available builders, even if builders censor

So we get a perverse outcome: ePBS removes relay trust assumptions, but increases economic pressure to use builders, which might be more centralized AND more susceptible to regulatory capture than relays were.

Is There A Better Path?

Some folks are working on alternative approaches:

DPaaS (Distributed Proposer as a Service) - aims to decentralize the builder role itself by distributing MEV extraction across multiple parties

Inclusion lists - proposers can force-include certain transactions even if builders try to censor (coming in future upgrade)

Multiple concurrent block proposals - instead of one sealed block, proposers receive multiple options and can mix/match

But none of these are part of Glamsterdam. ePBS ships first, and we deal with builder centralization later.

My Take

I think ePBS is good engineering and worth shipping, but we need to be honest about what it solves:

:white_check_mark: Removes relay trust assumptions
:white_check_mark: Hardens security model (no more MEV theft by relays)
:white_check_mark: Makes censorship attributable on-chain

:cross_mark: Doesn’t solve builder centralization
:cross_mark: Might actually increase economic pressure toward centralized builders
:cross_mark: Censorship still possible, just more visible

The “more decentralized” framing is marketing. This is a trust model upgrade that moves us from “trust 8 relay operators” to “rely on 3 builders but with cryptographic guarantees.” Better, but not solved.

What concerns me is if we ship ePBS, declare victory on MEV, and never address builder centralization. That would be a mistake.

This is such a good discussion. I wanted to add some actual data from on-chain analytics because the builder centralization numbers are… yeah, they’re concerning.

What The Data Shows

I pulled block production stats for January-February 2026 from our analytics platform, and here’s what we’re seeing:

Builder Market Share (Feb 2026):

  • Builder #1 (Titan): 47.3% of blocks
  • Builder #2 (Flashbots): 28.1% of blocks
  • Builder #3 (rsync): 9.8% of blocks
  • All others: 14.8% combined

So the top 3 control 85.2% of block production. That’s even more concentrated than Brian mentioned for 2023-2024.

MEV Value Capture:

  • Total monthly MEV extracted: ~$180M (Feb 2026)
  • Titan alone captured: ~$92M (51% of total)
  • Average MEV per block: Titan = $185, smaller builders = $45-60

The gap is widening. Titan has better order flow deals (they have exclusivity with 3 major wallets), faster infrastructure, and more capital to bid aggressively. Small builders literally can’t compete.

Why Builders Centralize Faster Than Relays

Relays are relatively commodity infrastructure - you need good uptime and honest operation, but the technical requirements aren’t crazy different between big and small relays.

Builders are totally different. They compete on:

  1. Order flow access - exclusive deals with wallets/apps for first look at transactions
  2. Speed - milliseconds matter for arbitrage, you need co-located servers near DEXs
  3. Capital - you’re bidding against other builders, deeper pockets win
  4. Optimization algorithms - complex MEV extraction strategies (sandwich attacks, arbitrage routing, liquidation cascades)

This creates natural monopoly pressure. Once you’re the biggest builder, you get more order flow → can bid higher → win more blocks → get even more order flow. Classic network effects.

The ePBS Data Gap

Here’s what worries me about shipping ePBS without addressing builder concentration: we don’t have good observability tools for this yet.

Under MEV-Boost, we can track:

  • Which relays validators connect to
  • Which builders submit to which relays
  • Block bid amounts and MEV extraction

Under ePBS, some of this moves fully on-chain (good!), but we lose visibility into:

  • Why proposers chose specific blocks (highest bid? censorship avoidance? other factors?)
  • Off-chain order flow deals between builders and wallets
  • Private negotiations that affect block production

If we can’t measure builder behavior clearly, how do we know if they’re censoring? How do we prove regulatory capture?

What I’d Want To See

Before declaring ePBS a “decentralization win,” I’d want to see:

  1. Builder diversity metrics tracked on-chain (HHI index, Gini coefficient, etc.)
  2. Minimum builder count requirements - if fewer than X builders are active, something’s wrong
  3. Transparent order flow routing - wallets should disclose exclusive builder deals
  4. Inclusion list implementation before ePBS ships (not after)

Right now we’re shipping ePBS with “we’ll figure out builder centralization later” vibes, and that makes me nervous from a data person’s perspective. Once the infrastructure is live, changing it is way harder.

Random Personal Note

My mom asked me last week “So is Ethereum really decentralized?” and I tried explaining the 8 relays → 3 builders thing. She just laughed and said “That’s like when we had 10 banks and now there’s 3.”

She’s not wrong? :sweat_smile:

I still think ePBS is better than MEV-Boost (removing trust from relays is a real win), but calling it “more decentralized” feels like we’re moving the goalposts on what decentralization means.

From a security research perspective, I need to push back slightly on the “builder centralization is worse” narrative. The trust model improvements with ePBS are more significant than this thread is acknowledging.

What ePBS Actually Fixes (Security-Wise)

Under MEV-Boost, relays represent a critical security vulnerability with multiple attack vectors:

1. Block Withholding by Relays
A malicious or compromised relay can withhold blocks from proposers, causing missed slots. This isn’t theoretical—we’ve seen relay outages cause chain issues. Under ePBS, block withholding becomes attributable on-chain. Proposers can prove which builder withheld blocks and slash them (once slashing is implemented).

2. MEV Theft by Relays
Relays see unsealed blocks before forwarding them to proposers. A dishonest relay could extract MEV itself or sell information to front-runners. ePBS eliminates this entirely—blocks are cryptographically sealed, relays don’t exist, and proposers can’t see contents until after commitment.

3. Single Point of Failure
When a major relay goes down (happened with Agnostic Relay in October 2024), validators lose access to high-MEV blocks. Under ePBS, no relay = no single point of failure.

These are REAL security improvements, not just theoretical wins.

Why Builder Centralization ≠ Relay Centralization (Security View)

Yes, builders are more concentrated than relays (3 vs 8 entities). But the attack surface is fundamentally different:

Relays:

  • See all blocks in plaintext
  • Can steal MEV undetectably
  • Can censor without on-chain proof
  • Required for 90% of validators to earn competitive rewards

Builders (under ePBS):

  • Cannot see proposer choices until after commitment
  • Cannot steal MEV (blocks are sealed)
  • Censorship is on-chain attributable
  • Proposers can fall back to self-building (even if economically costly)

The centralization DEGREE might be worse, but the centralization RISK is lower because cryptographic guarantees replace trust assumptions.

The Censorship Resistance Question

Mike and Brian are right that economic incentives create pressure to use builders even if they censor. But ePBS introduces important accountability mechanisms:

  • On-chain attribution: If builders consistently exclude certain addresses, it’s provably visible
  • Social coordination: Community can pressure proposers to avoid censoring builders
  • Future inclusion lists: Proposers can force-include transactions even if builders try to censor

The question isn’t “can builders censor?” (yes), but “can they censor undetectably?” (no).

My Security Threat Model

Here’s how I rank the actual security risks:

Highest Risk:
:red_circle: Regulatory capture of all 3 major builders → coordinated censorship
:red_circle: Builder collusion to manipulate MEV markets
:red_circle: Zero builders available (all offline/compromised) → chain halt

Medium Risk:
:yellow_circle: Single builder dominance (>50%) → effective centralization
:yellow_circle: Private order flow deals create information asymmetry
:yellow_circle: Builder infrastructure compromised (hacked, DDoS)

Low Risk (due to ePBS cryptographic guarantees):
:green_circle: MEV theft by builders (impossible with sealed blocks)
:green_circle: Undetectable censorship (on-chain attributable)
:green_circle: Block withholding without slashing consequences

What I’d Actually Worry About

If I were advising the Ethereum Foundation on ePBS security, my concerns would be:

  1. Slashing mechanisms not ready - ePBS enables attributability, but are we actually ready to slash misbehaving builders? What’s the governance process?

  2. Emergency fallback procedures - If all major builders go offline, do we have tested procedures for proposers to self-build? Have we war-gamed this scenario?

  3. Builder key security - Builders commit to blocks cryptographically. If builder private keys are compromised, can they be rotated? What’s the recovery process?

  4. Timing games - Can builders game the sealed-block auction by revealing strategically timed bids? Have we modeled all the auction mechanism edge cases?

My Take

I support shipping ePBS because the security model is strictly better than MEV-Boost. We’re removing trusted intermediaries (relays) and replacing them with cryptographic guarantees. That’s progress.

But we should be clear about what ePBS solves:
:white_check_mark: Removes relay trust assumptions (major security win)
:white_check_mark: Makes censorship attributable (enables future countermeasures)
:white_check_mark: Eliminates MEV theft by relays

:cross_mark: Doesn’t solve builder centralization (still a problem)
:cross_mark: Doesn’t prevent builder collusion (requires governance)
:cross_mark: Doesn’t eliminate censorship risk (just makes it visible)

Builder centralization is a governance and incentive design challenge, not a security vulnerability that ePBS can fix with cryptography. Those are different problems requiring different solutions.

The fact that we’re conflating “decentralization” with “security” in this thread shows we need clearer threat modeling. ePBS improves security. Builder centralization harms liveness and censorship-resistance. Both can be true simultaneously.