BuilderNet Went Live, But Did It Actually Fix MEV Centralization?

General
1

BuilderNet Went Live, But Did It Actually Fix MEV Centralization?

I’ve been digging into the MEV space lately and something’s been bothering me. Flashbots launched BuilderNet in November 2024, migrated all their operations to it in December 2024, and made a big deal about “decentralizing block building” on Ethereum. The tech is genuinely impressive - TEE-based collaborative block building, fair MEV redistribution, all that good stuff.

But here’s the problem: as of March 2026, Beaverbuild and Titan Builder still produce ~86% of Ethereum mainnet blocks. That’s barely changed from the 90% concentration before BuilderNet launched.

What BuilderNet Promised

The original pitch was compelling:

  • Neutralize exclusive orderflow deals that give certain builders unfair advantages
  • Enable multiple parties to collaborate on block building instead of winner-take-all competition
  • Distribute MEV more equitably via open-source refund rules
  • Use TEEs (Trusted Execution Environments) to enhance security

On paper, this should break up the builder oligopoly. In practice? The same two players dominate.

Why Isn’t It Working?

I see a few possibilities:

  1. Economic flywheel is too strong: More orderflow → better blocks → higher validator payments → attracts more orderflow. BuilderNet neutralizes exclusive deals, but doesn’t change the fact that larger builders have better infrastructure, lower latency, and more capital to optimize.

  2. Too early to judge: Maybe adoption takes time? BuilderNet v1.2 just came out in February 2025, and infrastructure changes move slowly. Could be that we need another year before seeing real market structure changes.

  3. Protocol can’t solve market dynamics: Perhaps builder centralization is an inevitable consequence of economies of scale, similar to how mining pools centralized in Bitcoin. No amount of protocol design changes the underlying economics.

  4. Missing piece is SUAVE: Flashbots has talked about SUAVE as the long-term vision for fully decentralized MEV. Maybe BuilderNet was always meant to be a stepping stone, not the final solution?

What Actually Changed?

To be fair, BuilderNet did accomplish some things:

  • Flashbots stopped running centralized builders (governance/optics win)
  • MEV refunds are now calculated transparently via open-source rules
  • Infrastructure exists for collaborative building (even if uptake is slow)
  • Reduced censorship risk by making builder operations more distributed

But if 86% of blocks still come from two entities, did we really fix the centralization problem? Or just move it from “Flashbots + one other” to “Beaverbuild + Titan”?

The Question That Keeps Me Up

Is this a failure of BuilderNet’s design, or proof that MEV extraction naturally centralizes regardless of infrastructure?

If it’s the former, we can iterate on protocol design. If it’s the latter (MEV is like HFT in TradFi - sophisticated actors always outcompete), then we need to rethink our approach entirely. Maybe the goal shouldn’t be “decentralize builders” but rather “minimize harm from inevitable builder centralization” via PBS, censorship resistance mechanisms, and validator sovereignty.

I’m genuinely curious what others think. Are we being too impatient with BuilderNet? Or is this evidence that we’re solving the wrong problem?

Data sources: Bitget BuilderNet analysis, Blockworks on Flashbots’ approach, The Block on BuilderNet launch

2

Great analysis. As someone who’s been contributing to Ethereum core for years, I have mixed feelings about BuilderNet.

Technical Achievement vs Market Reality

From a technical perspective, BuilderNet is genuinely innovative. The TEE-based collaborative building model is solid engineering, and the open-source refund mechanism is a step toward transparency that we didn’t have before. Flashbots deserves credit for open-sourcing their approach rather than keeping it proprietary.

But you’re hitting on the real issue: protocol design can’t override economic incentives.

The Economies of Scale Problem

Think about what it takes to run a competitive block builder in 2026:

  • Ultra-low latency infrastructure (co-location, optimized networking)
  • Sophisticated MEV searching algorithms (finding profitable bundles others miss)
  • Deep capital pools (to execute complex arbitrage that requires flash loans)
  • Reputation with searchers and orderflow providers
  • 24/7 monitoring and uptime guarantees

Small operators simply can’t compete on all these dimensions. Even with BuilderNet’s collaborative model, you still need critical mass to be relevant. It’s similar to how Ethereum mining centralized into pools - individual miners could solo mine, but pooling was economically rational.

What BuilderNet Actually Solved

I’d argue BuilderNet was never meant to fix concentration among builders. It’s solving a different problem: preventing any single entity from controlling the builder role.

Before BuilderNet:

  • Flashbots ran a centralized builder
  • If Flashbots decided to censor transactions, implement KYC, or go down, that was a single point of failure

After BuilderNet:

  • Multiple parties (Flashbots, Beaverbuild, Nethermind) operate the same builder infrastructure
  • No single entity can unilaterally change policies
  • Censorship resistance improves even if concentration persists

So we’ve moved from “centralized operator” to “decentralized operation of concentrated market.” That’s progress, but not the dramatic shift some were hoping for.

SUAVE or Bust?

You mentioned SUAVE, and I think that’s the real endgame. BuilderNet is an incremental improvement, but SUAVE’s vision - shared mempool, fully decentralized block building, cross-chain MEV - addresses the root causes. Whether it actually works remains to be seen (SUAVE has its own technical challenges), but at least it’s aiming at the right target.

In the meantime, I think we should focus on minimizing centralization harms rather than eliminating centralization entirely:

  • Strong censorship resistance (ensure builders can’t easily censor)
  • Validator sovereignty (validators can always fall back to local building)
  • Transparent MEV refunds (users see what they’re paying)

Centralization might be inevitable, but we can still constrain what centralized actors can do.