Beyond MEV: Navigating Ethereum’s decentralization and block building future
At its core, Ethereum was designed with one intention: decentralization. But as Ethereum grows, staying true to that intention becomes harder.
One of the thorniest challenges? MEV (Maximal Extractable Value). It's not just a technical vulnerability or an incentive misalignment. It reshapes how blocks are built, who builds them, and who benefits from them.
MEV forces the protocol to answer uncomfortable questions: Should Ethereum give up on local block production? Should Ethereum hand over block construction to sophisticated external builders? Should Ethereum enshrine those builders in-protocol?
On May 13, 2025, a discussion between the Lodestar and Flashbots teams offered a window into how these questions are being tackled, not just at the protocol level, but at the level of Ethereum's values. The conversation wasn’t just about MEV. It was about what kind of network Ethereum wants to become and what it might have to give up along the way.
ePBS: Fixing the relay problem, or locking in a new one?
When Ethereum introduced PBS (Proposer-Builder Separation) via MEV-Boost, it did so off-protocol, using relays as trusted intermediaries to pass signed blocks from builders to proposers. The decision was made in the interest of time. It allowed Ethereum validators to access more competitive, high-MEV blocks without requiring them to run sophisticated infrastructure themselves. But in doing so, it introduced a new layer of complexity and risk.
Relays aren’t part of the protocol. They can fail silently, be censored, or gamed.
ePBS (enshrined PBS) is meant to fix that. By baking PBS into the protocol itself, ePBS would remove the need for relays entirely. Builders would communicate directly with proposers in a trustless, standardized way. Payments would be enforced. Timing games, like waiting to see other bids or delaying payload publication, would be harder to pull off.
The current ePBS design introduces a Payload Timeliness Committee (PTC), a selected group of validators who vote on whether a builder’s execution payload arrived on time. Their vote determines whether the block is treated as valid and full, or ignored as empty, discouraging strategic delays. In simpler terms: the committee acts as a check on builder behaviour. If a builder stalls, the protocol can penalize them by excluding their block or reducing its reward, keeping things fair and timely.
It’s a clever design. One trust assumption, relays, is replaced by another, but this time inside the protocol, with cryptoeconomic enforcement.
Sounds like a win… Until you zoom out.
“Many MEV researchers... are quite nervous about enshrining any PBS solution at this point in time because it's still changing very rapidly. You run a very high risk, frankly, of enshrining something suboptimal.”
—Hasu, Strategy Lead, Flashbots
Hasu’s worry isn’t about the goal of ePBS, it’s about the timing. Ethereum’s block-building market is still in flux. New designs like pre-confirmations, based rollups, and encrypted mempools are just beginning to take shape.
Hasu’s worry isn’t about the goal of ePBS, it’s about the timing. Ethereum’s block-building market is still in flux. New designs like pre-confirmations, based rollups, and encrypted mempools are just beginning to take shape.
That’s the deeper tension. Today, builders are offchain actors. Their role is shaped by market forces, not protocol mandates. Validators can choose to use them or build locally. But once PBS is codified into the protocol, that flexibility shrinks. The builder-proposer relationship becomes part of Ethereum’s core logic. And in doing so, it might crowd out other designs entirely.
By embedding one version of PBS into the protocol, Ethereum risks freezing out other paths, like deterministic ordering, encrypted mempools, or preconfirmations, before they’ve had a chance to mature. Enshrining PBS now might lock-in the wrong assumptions into the protocol.
“ePBS basically means we give up on... solutions [like deterministic ordering] and just hand it over to the builder network.”
—Nico Flaig, Protocol Engineer, Lodestar
Enshrining PBS might solve one trust problem (relays) while hardcoding a bigger one: permanent dependence on external builders, most of whom are private, profit-maximizing entities.
BuilderNet: De-risking our dependence on private builders
Flashbots don’t want to enshrine PBS. But they do want to fix the builder market.
Their proposal? BuilderNet, a decentralized block building network that runs on hardware-secured enclaves, known as Trusted Execution Environments (TEEs).
The idea is ambitious: keep the performance and sophistication of external builders, but remove their opacity and control. Use hardware to prove that builders aren’t front-running users. Use privacy to stop sandwich attacks. Use structure to return value to users and validators alike.
On paper, it sounds like the best of both worlds: privacy, transparency, decentralization, and efficiency.
“If your transaction creates any MEV or pays any excess transaction fee, you can be refunded… when BuilderNet generates any surplus against other builders, anybody who contributed to that surplus can get a refund.”
—Hasu
That surplus comes from order flow. If BuilderNet can attract high-quality transaction flow from wallets, dapps, and users, then win blocks with it, it can split the rewards among the people who made that order flow possible. Not just validators. Not just builders. But users, too.
It’s a new kind of auction. Not just for blockspace, but for attention.
Still, BuilderNet asks for trust in a different place. Instead of trusting a builder’s incentives, you’re trusting the guarantees of the TEE: a black box of silicon, manufactured by Intel or AMD, running unobservable code. It’s verifiable in theory but fragile in practice. SGX, Intel’s last TEE, was retired. Flashbots now uses Intel TDX and hopes to diversify across manufacturers for redundancy. But for now, trust in the hardware is table stakes.
The other risk? Success. If BuilderNet works too well, if it becomes the only place builders want to build, does Ethereum just recreate the same centralization under a new banner?
That’s the paradox BuilderNet is trying to navigate: use centralizing forces (speed, scale, specialization) to create decentralizing outcomes (user refunds, public infrastructure, transparency). Whether it works will depend not just on tech, but on governance. Hasu was clear:
“BuilderNet is intended to become its own decentralized network with open contribution, several teams, a governance process, BuilderNet improvement proposals.”
—Hasu
It’s a protocol by another name, but unlike ePBS, it isn’t enshrined. It can evolve in the open or fail fast without taking Ethereum with it.
The builder dilemma
For a long time, building blocks was the validator’s job. You ran a node, had a mempool, and ordered transactions. It wasn’t always the most profitable, but it was yours.
MEV changed that. As the value of block construction increased, so did the pressure to specialize. Enter block builders, external actors with fast infrastructure, deep exchange access, and custom logic to extract value from every transaction. Suddenly, the validator’s job wasn’t to build, it was to outsource its right to propose a block to someone else in exchange for a share of the profits.
For some, this tradeoff feels unavoidable. For others, it feels like capitulation.
“The builders are antithetical to the ethos of why we all join the blockchain space... to build a better future that is more egalitarian and more meritocratic.”
—Matthew Keil, Protocol Engineer, Lodestar
Keil’s concern isn’t about performance. It’s about power. When only a few players can build blocks, they set the rules for who gets in and who doesn’t. That’s not meritocracy. That’s gatekeeping.
Hasu sees it differently. In his view, builders are already solving real problems: they keep the validator set decentralized, distribute MEV more evenly, and improve user experience by reducing gas costs and sandwich attacks. To him, the question isn’t whether builders should exist, it’s how to constrain them. In his view, MEV should be minimized at the wallet and app layer, where users can assert control, and harnessed at the builder layer, where incentives and enforcement can be standardized.
And then there’s a third perspective, asking not what’s ideal, but what’s feasible.
“How far do you think that we can scale local builders and still keep good liveness rates?”
—Data Always, Researcher, Flashbots
In other words, even if you want decentralization, can you actually run it onchain, on time, on hardware that doesn’t cost a fortune?
The deeper question here is not “Are builders good or bad?” It’s: What kind of decentralization do we want, and who gets to participate in it? Is it about making sure every validator can build blocks locally on a Raspberry Pi? Or is it about making sure users, not just builders, benefit from block production? Ethereum may not be able to have both.
Building on shared ground
Even if they don’t agree on how to get there, there was definitely one major consensus among both teams: keep Ethereum credible, decentralized, and performant.
And in some areas, the paths converge.
Inclusion Lists (FOCIL) came up again and again. Both Lodestar and Flashbots saw them not as a silver bullet, but as a pragmatic step, one that could improve censorship resistance without overhauling the builder market.
Inclusion lists allow block proposers to require certain transactions to be included in blocks. Used wisely, they can reduce the worst effects of MEV and reintroduce some protocol-native accountability.
Lower slot times also drew agreement. The logic is straightforward: when blocks happen faster, the window for MEV games gets smaller.
Hasu noted that lower latency reduces MEV in decentralized exchanges, especially in backrunning scenarios. Nico pointed out that faster slots could improve user experience while aligning with rollup-centric futures. No one saw it as controversial, just incomplete. A useful tool, but no cure.
Ethereum doesn’t need everyone to think the same. It needs people to build things that challenge each other’s assumptions and make the network stronger in the process.
Where it goes from here
No one left the conversation thinking the problem was solved. If anything, the discussion sharpened the uncertainty.
BuilderNet might work. It might not. ePBS might prove essential. Or it might ossify too early. Local block building might fade. Or it might stage a comeback, but realistically this would only happen if we can give it better incentives. Right now, it’s just so much more rational to outsource to builders who can extract more MEV.
What’s clear is that Ethereum is at a fork, not just in the protocol, but in its design philosophy. Does the network want to stay flexible, relying on external markets and modular upgrades? Or does it want to fold its infrastructure inward, codifying roles and responsibilities at the protocol layer?
BuilderNet, for now, represents an attempt to have it both ways: a system that isn’t enshrined, but still aspires to protocol-level trust.
It’s a bold bet, not because it solves everything, but because it buys time. Time for Ethereum to keep experimenting without rushing into permanence.
The work isn’t done. But it’s clearer now where the edges are.
About ChainSafe
ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, infrastructure development, co-development and web3-enabled gaming.
Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, ChainSafe creates solutions for developers and teams across web3.
As part of its mission to build accessible and improved tooling for developers, ChainSafe embodies an open source and community-guided ethos to advance the future of the internet.