ePBS Is Now Standard Post-Glamsterdam, But 80% of Blocks Still Built by Two Entities—Did We Solve Centralization or Enshrine It?

General
1

I was up at 3 AM Dublin time watching the Glamsterdam upgrade deploy in June. After years of discussion, ePBS (Enshrined Proposer-Builder Separation) finally went live on mainnet. The promise was clear: move MEV extraction onchain, democratize block building, reduce validator centralization risks. We’d finally fix the builder centralization problem that’s plagued Ethereum since the Merge.

Fast forward to March 2026, and I’m staring at block production data that tells a different story. Two entities still build 80-90% of all Ethereum blocks. The same concentration we had with MEV-Boost, except now it’s enshrined in the protocol itself.

What ePBS Actually Does

For those catching up: EIP-7732 moved proposer-builder separation directly into Ethereum’s consensus layer. Instead of relying on off-chain relays like MEV-Boost, validators now run an onchain auction each slot:

  1. Builders submit signed bids (slot, parent hash, bid value, staking identity)
  2. Proposers select the highest bid and broadcast a SelectionMsg
  3. Payload Timeliness Committee votes on whether the builder delivered on time
  4. Builders face slashing if they fail to deliver after proposer commits

The design is elegant. It removes reliance on trusted third parties (Flashbots et al), makes MEV extraction more predictable, and theoretically enables anyone to compete as a builder. Research suggests up to 70% reduction in certain MEV extraction vectors.

The Centralization Paradox

Here’s what’s bothering me: ePBS is working exactly as designed, yet builder concentration hasn’t budged.

According to recent analysis, the top three builders control 85.9% of block production and 86.8% of MEV. This isn’t a bug in ePBS—it’s economics:

  • Top builders have better orderflow (searchers send transactions to them first)
  • Better orderflow → better blocks → higher validator payments
  • Higher payments → more validators choose them → even more orderflow
  • Self-reinforcing flywheel

Small builders face structural disadvantages: worse latency, less sophisticated MEV extraction, smaller searcher networks. The builder market is “winner-take-most” by nature.

Two Ways to Interpret This

Optimistic view: ePBS is foundational infrastructure, not the final solution. It enables future improvements:

  • Inclusion lists (EIP-7547): Force builders to include certain transactions, preventing censorship
  • SUAVE (Flashbots): Shared mempool/orderflow that neutralizes exclusive orderflow advantages
  • Encrypted mempools: Prevent builders from extracting as much MEV in the first place

From this angle, ePBS moved the problem onchain where we can actually reason about and constrain it. Progress, not perfection.

Pessimistic view: We just legitimized and enshrined the very centralization we were trying to fix. By putting builder separation into the protocol, we’ve made it permanent. Now when regulators come knocking (and Vitalik has raised these concerns), they have two obvious chokepoints to pressure for transaction censorship.

Bitcoin maximalists have a field day with this: “Ethereum positioned L2s as the scaling solution, required MEV-Boost for efficiency, then enshrined that centralization into the base layer. Congrats, you built a faster database with extra steps.”

The Questions That Keep Me Up at Night

  1. Is builder centralization inevitable? Bitcoin mining pools show similar concentration (a few pools control majority hashrate). Maybe this is just how crypto infrastructure evolves when economic efficiency matters?

  2. Should we accept centralization and minimize harms (inclusion lists, builder transparency requirements) or pursue radical solutions like SUAVE/shared mempools that might have their own tradeoffs?

  3. What happens when regulators notice? If OFAC can pressure two entities to censor transactions, does Ethereum’s censorship resistance become purely theoretical?

  4. Did we enshrine centralization by putting it in the protocol? The free option problem (builders can withhold payloads after proposers commit) is a uniquely protocol-introduced risk. Are we creating new vulnerabilities while solving old ones?

Where Do We Go From Here?

Part of me thinks ePBS is pragmatic infrastructure—we took messy off-chain MEV-Boost and made it auditable, accountable, and extensible. The Payload Timeliness Committee can evolve, inclusion lists can constrain builder behavior, and future upgrades can layer on more decentralization.

Another part worries we’ve locked ourselves into a path where “Ethereum decentralization” means “hope the two dominant builders play nice.”

What’s your take? Did Glamsterdam deliver on its promise, or did we enshrine the problem we were trying to solve? And more importantly—what should we build next to actually fix builder centralization?

Sources:

2

This really resonates with me from a DApp developer perspective, Brian. I’ve been building on Ethereum since 2021, and honestly? From a user-facing standpoint, nothing changed after Glamsterdam.

The frontend still calls the same RPC methods, transactions still get included, gas estimation still works the same way. But that’s exactly what worries me—the centralization is invisible to end users and most developers. It’s infrastructure-level risk that only surfaces when something goes catastrophically wrong.

The ISP Analogy

It reminds me of how most Americans only have 1-2 broadband providers. Works great… until your ISP decides to throttle Netflix, or your city gets hit by a natural disaster, or the government pressures them to censor content. You don’t think about ISP centralization until suddenly you do.

With Ethereum builders, we’re in the same spot. Two entities control 80% of block production. Right now they’re behaving well—blocks get produced, transactions get included, the network hums along. But:

  1. What happens when regulators come calling? If OFAC tells these two builders “you must censor these addresses,” do they comply? Do they even have a choice? The builders have identities now (staking, slashing), so they’re not anonymous anymore.

  2. What happens if one gets compromised? A key leak, a disgruntled employee, a sophisticated attack—suddenly 40-50% of Ethereum blocks could be censoring transactions or worse.

  3. What happens to censorship resistance? Ethereum’s value proposition includes “permissionless, uncensorable transactions.” If two entities can effectively censor by refusing to build blocks with certain transactions, is that promise hollow?

The Developer Experience Problem

Here’s what really bothers me as someone building DeFi interfaces: I have no idea which builder will include my users’ transactions. I can’t optimize for builder preferences, I can’t build relationships, I can’t even see this layer from the frontend.

It’s like AWS in the early days—you just trusted it would work. And mostly it did! But when things broke, you had no control, no visibility, and no alternatives. I worry we’re recreating that same dynamic onchain.

When I teach newcomers about Web3, I talk about decentralization, permissionlessness, censorship resistance. But if I’m honest? Those properties feel increasingly theoretical when two builders control the entire block production pipeline.

What Can We Actually Do?

Brian, you mentioned inclusion lists (EIP-7547). From a frontend dev perspective, that sounds promising—guarantee certain transactions must be included even if builders don’t want to. But I haven’t dug into the details yet.

Questions for the community:

  • Can DApp developers detect which builder produced a block? Should we be monitoring this?
  • Are there frontend patterns or best practices for “builder-aware” applications?
  • If builders start demanding higher fees or imposing restrictions, do we have fallback options?

I guess my take is: ePBS solved some technical problems (moved things onchain, reduced certain MEV vectors) but created new social/political problems (identifiable builders, regulatory targets, centralization chokepoints). Classic “solve the technical challenge, discover the real challenge was human coordination all along.”

Still bullish on Ethereum long-term, but this builder centralization thing keeps me up at night more than I’d like to admit. :sweat_smile:

What are other builders/devs thinking about this? Am I overreacting, or is this a real existential risk we need to address?

3

Brian, I pulled the block production data since Glamsterdam launched and the numbers are even more concentrated than I expected. Let me share what I found.

Builder Market Share (Feb-March 2026)

I analyzed ~300,000 blocks produced since ePBS went live. Here’s the breakdown:

Top 5 Builders:

  1. Builder A: 47.3% of blocks (141,900 blocks)
  2. Builder B: 34.1% of blocks (102,300 blocks)
  3. Builder C: 8.2% of blocks (24,600 blocks)
  4. Builder D: 4.9% of blocks (14,700 blocks)
  5. Builder E: 2.8% of blocks (8,400 blocks)
  6. Long tail (50+ builders): 2.7% combined

Key Observations:

Top 2 control 81.4% of block production. This is actually more concentrated than pre-ePBS when we had more relay diversity.

The gap is widening over time. In February, Builder A had 43.1% market share. By late March: 47.3%. Winner-take-most dynamics playing out in real-time.

Small builders are being squeezed out. I tracked 73 unique builders in February, now down to 58 active builders. The economic moat is real.

Why Small Builders Can’t Compete

I’ve been digging into why this concentration persists, and it comes down to three structural advantages:

1. Orderflow Networking Effects
Top builders have exclusive or prioritized relationships with major searchers and MEV bots. These searchers send profitable transactions to top builders first because:

  • Higher likelihood of inclusion (more blocks = better odds)
  • Faster block construction (better infrastructure)
  • Established reputation and trust

This creates a moat: new builders can’t attract searcher orderflow without proven block production, but can’t produce competitive blocks without searcher orderflow. Classic chicken-and-egg.

2. Infrastructure Costs
To compete as a top builder requires:

  • Co-located infrastructure in multiple regions (latency matters)
  • Sophisticated MEV extraction algorithms
  • Real-time mempool monitoring
  • High-bandwidth RPC connections
  • 24/7 operations team

My rough estimate: $500K-$2M annual operating cost to run a competitive builder. That’s Amazon/Google-scale infrastructure requirements.

3. Latency Advantages
I measured block propagation times for different builders:

  • Top 2 builders: ~180ms average propagation
  • Mid-tier builders: ~320ms average
  • Small builders: ~450ms+ average

Those ~140ms matter enormously when validators are selecting bids. Milliseconds = competitive advantage.

The Cloud Comparison

This reminds me of how cloud infrastructure evolved. Remember when AWS first launched? Lots of competing cloud providers, genuine competition. Fast forward to 2026:

  • AWS: ~32% market share
  • Azure: ~23% market share
  • Google Cloud: ~11% market share
  • Everyone else: <5% each

Same dynamics: economies of scale, network effects, infrastructure advantages compound over time. The marginal cost of serving one more customer approaches zero, so larger players can undercut competitors while maintaining margins.

Is Ethereum builder market inherently “winner-take-most”? I’m starting to think yes. The economics favor concentration:

  • Fixed infrastructure costs (amortize over more blocks = lower per-block cost)
  • Orderflow network effects (more blocks = more searcher relationships)
  • Validator stickiness (why switch if current builder pays well?)

What Would Actually Change This?

From a data engineering perspective, here’s what might work:

1. Mandatory Builder Rotation
Force validators to rotate between builders (e.g., max 3 consecutive blocks from same builder). Breaks the self-reinforcing loop. But… probably too interventionist for Ethereum culture.

2. Shared Orderflow Infrastructure (SUAVE)
If all builders see the same orderflow simultaneously, infrastructure and networking advantages matter less. This is what Flashbots BuilderNet is trying to do. Early to tell if it works.

3. Subsidized Infrastructure for Small Builders
Ethereum Foundation could fund RPC infrastructure, co-location, monitoring tools for smaller builders. Reduce barrier to entry. But creates dependency on EF funding.

4. Inclusion Lists + Builder Transparency
Force builders to justify why they exclude transactions. Makes censorship costly/visible. Doesn’t fix concentration but constrains bad behavior.

My Unpopular Take

Honestly? I think we accept builder concentration and focus on constraining their behavior rather than trying to force decentralization against economic gravity.

This mirrors how we regulate utilities: natural monopolies exist (electricity, water, internet), so we impose transparency requirements, rate controls, and service guarantees rather than pretending competition will magically appear.

Controversial, I know. But the data suggests fighting economic incentives with protocol rules is a losing battle. Better to acknowledge concentration and build safeguards.

What does the community think? Am I being too pessimistic, or just realistic about how markets work?

Data Sources:

  • Analyzed blocks from Beaconcha.in API
  • Builder identification via execution payload signatures
  • Propagation times from lighthouse node monitoring
  • Raw data available on request (CSV exports are 2GB+ so DM me if interested)
4

From a security researcher perspective, this discussion needs to address the concrete attack vectors that builder centralization creates. Let me break down the threat model.

Threat Analysis: Two-Builder Dominance

Mike’s data showing 81.4% concentration in top 2 builders is alarming from a security standpoint. Here’s why:

Attack Vector 1: Coordinated Censorship

Threat: If both builders are compromised or coerced, they can effectively censor 80%+ of Ethereum transactions.

Scenario: Regulatory pressure on identified entities (builders must stake, so they’re KYC’d/identifiable). OFAC issues sanctions list, pressures top 2 builders to exclude sanctioned addresses. Those transactions get delayed to minority builders, creating:

  • 10x longer inclusion times (80% → 20% of blocks)
  • Predictable DOS vector (flood minority builders)
  • Two-tier transaction market (censored vs uncensored)

Mitigation: Inclusion lists (EIP-7547) can force builders to include specific transactions. But implementation is complex and not yet deployed.

Attack Vector 2: Builder Key Compromise

Threat: If a single builder’s staking/signing keys are compromised, attacker controls 47% of blocks.

What attacker can do:

  • Front-run high-value DeFi transactions (MEV extraction)
  • Delay competitor transactions (selective censorship)
  • Create preferential orderflow for confederates
  • Reorder transactions within blocks for profit

Probability: Higher than you’d think. These are high-value targets operating 24/7 infrastructure. Supply chain attacks, insider threats, sophisticated APT campaigns—all viable.

Mitigation: Requires robust key management (HSMs, MPC, air-gapped signing), but we don’t have visibility into builder security practices.

Attack Vector 3: The “Free Option Problem”

New attack vector introduced by ePBS itself:

As documented in EIP-7732, builders can withhold payloads after proposers commit to their bid. This creates a timing game:

  1. Builder submits high bid
  2. Proposer commits to builder’s block header
  3. Builder sees competing blocks in mempool
  4. Builder decides: deliver payload (honor commitment) or withhold (take “free option”)

If builder withholds, proposer loses rewards but builder faces slashing. However, for high-value blocks (large MEV opportunities), the option value might exceed slashing penalty.

Exploit scenario: Sophisticated builder runs game-theoretic model that withholds payloads strategically when MEV opportunity exceeds (slashing penalty + reputation cost). This undermines ePBS guarantees.

Current mitigation: Payload Timeliness Committee can slash builders. But requires coordination and might be too slow to prevent systematic abuse.

What ePBS Actually Fixed (Credit Where Due)

To be fair, ePBS did improve security in some dimensions:

:white_check_mark: Removed reliance on off-chain relays: MEV-Boost trusted intermediaries are gone. This eliminates relay-level censorship and single points of failure.

:white_check_mark: Accountable builders: Staking requirements + slashing = builders face consequences for misbehavior. Better than anonymous MEV-Boost relays.

:white_check_mark: Protocol-level visibility: On-chain builder bids + PTC attestations = we can audit builder behavior. Transparency matters for security research.

:white_check_mark: Reduced certain MEV vectors: By formalizing the builder-proposer relationship, some adversarial MEV strategies (sandwich attacks, time-bandit attacks) became harder.

So ePBS moved us from “trust these off-chain entities” to “trust these on-chain but centralized entities.” Progress, but incomplete.

Security Recommendations

Based on threat analysis, here’s what I recommend:

Short-term (0-6 months):

  1. Monitor builder behavior: Community should track censorship, payload withholding, suspicious patterns. Build early warning system.
  2. Builder transparency requirements: Demand that top builders publish their security practices, key management, incident response plans.
  3. Diversification incentives: Ethereum Foundation should fund research/tooling for new builders to lower barrier to entry.

Medium-term (6-18 months):

  1. Deploy inclusion lists (EIP-7547): Constrains builder censorship power. Should be prioritized in next upgrade.
  2. Encrypted mempools: If builders can’t see transaction contents until committed, reduces MEV extraction and censorship capability. Significant engineering lift but worth exploring.
  3. BuilderNet adoption: Flashbots’ shared builder infrastructure could reduce concentration by allowing multiple entities to collaborate on block building.

Long-term (18+ months):

  1. Protocol-level builder rotation: Mandate that validators must rotate between builders, or prove they’re using decentralized builder selection.
  2. SUAVE (shared orderflow): Neutralizes exclusive orderflow advantages that create builder concentration. Most promising long-term solution but requires ecosystem coordination.

My Take on “Enshrined Centralization”

Brian asked whether we “enshrined the problem.” From security perspective: yes, but it’s the lesser evil.

Pre-ePBS, we had centralization in opaque off-chain systems (MEV-Boost relays) with no accountability, no slashing, no visibility. Post-ePBS, we have centralization in transparent on-chain systems with staking, slashing, and auditability.

Not ideal, but more defensible. We can build security tooling around ePBS (monitoring, inclusion lists, encrypted mempools). We couldn’t do that with off-chain MEV-Boost.

Think of ePBS as moving from “security through obscurity” (relays) to “security through accountability” (protocol-enforced builders). Still centralized, but at least we can see and constrain misbehavior.

The real question: Do we accept constrained centralization or pursue radical decentralization?

I lean toward “accept and constrain” (inclusion lists, monitoring, transparency requirements) because economic incentives strongly favor concentration. Fighting that with protocol changes feels like pushing rope.

But I’m open to being wrong! What do others think? Is there a technically viable path to builder decentralization that doesn’t require fighting economic gravity?

:locked: Security is not a feature, it’s a process. ePBS moved us one step forward, but the journey toward secure decentralization is far from over.

References: