BuilderNet's Infrastructure Monoculture: Centralization with Extra Steps
A Freer Future—Yet, for Now, Every “Builder” Is Still Bolted to the Same Intel-Azure-Flashbots Assembly Line.
Disclaimer
The content of this post has been provided by a third-party researcher, DeFi Alice, and does not necessarily reflect the views, opinions, or positions of EigenPhi. We are sharing this information for informational purposes only.
“The rule is, jam tomorrow and jam yesterday—but never jam today.”
— the White Queen, Through the Looking-Glass (1871)
Flashbots' BuilderNet initiative is positioned as a major step toward a more decentralized and neutral block-building market on Ethereum. By enabling multiple parties to run builder nodes within secure enclaves, it aims to break the dominance of a handful of centralized builders. Now, BuilderNet is still only open to limited builders, and it imposes strong constraints on how blocks are built.
All BuilderNet nodes today run the same builder software (Flashbot’s rBuilder), inside the same trusted hardware (Intel's TDX), deployed on the same cloud provider (Microsoft Azure). This creates an infrastructure monoculture: a network of nominally independent nodes built from the same parts, running the same code, and depending on the same vendors.
Uniform Stack, Shared Dependencies
BuilderNet's trust model relies on reproducible builds and remote attestation, yet so far, we have not come across any credibly neutral parties measuring the remote attestations and confirming that BuilderNet actually runs what they say they do. Nodes boot into pre-verified VM images inside Intel TDX enclaves, attested by Azure and validated by Flashbots' BuilderHub. This ensures all participants follow the same logic and don't leak or tamper with orderflow. It's a pragmatic approach to ensure integrity and privacy, but it also means all builders are running an identical environment. This could be on par with the worst-case scenarios for Ethereum client supermajority risks if all blocks built through the PBS pipeline were using the same corrupted software or hardware.
This uniformity has some clear benefits: it provides consistency, performance parity, and verifiability. But it also introduces a set of shared dependencies. If there's a flaw in Intel's TDX or if Azure's attestation pipeline experiences downtime, every BuilderNet node is affected. This is a common-mode failure risk—precisely the kind of systemic dependency Ethereum's multi-client philosophy is designed to avoid.
Vendor Lock-in and Participation Barriers
Currently, BuilderNet only supports deployment on Azure using Intel TDX-enabled VMs. Other providers and attestation systems are reportedly in development, but not yet available. This limits who can participate. Running a BuilderNet node requires access to specific hardware, a compatible cloud platform, and operational knowledge of enclave infrastructure. It's not yet a permissionless system in the same way Ethereum's validator network is, and there is no clear path towards permissionless behavior.
This also places a significant amount of trust in external vendors. While TEEs reduce reliance on the honesty of node operators, they shift that trust to hardware and cloud platforms. Intel, Azure, and Flashbots' BuilderHub all play roles in defining and enforcing who can build blocks.
Central Coordination and Flashbots' Role
While BuilderNet aims to decentralize block construction, Flashbots still plays a central role in its operation:
BuilderHub as Gatekeeper: BuilderHub, operated by Flashbots, verifies TEE attestations and authorizes node participation. This service controls who can join the network.
Provisioning and Configuration: BuilderHub supplies runtime configurations and secrets. If misused, it could selectively deny or manipulate access.
Allowlisting and Governance: Only a handful of operators (e.g., Flashbots, Beaverbuild, Nethermind) currently run BuilderNet nodes. The onboarding process is controlled by Flashbots, and currently they provide no clear path for approval.
Orderflow Infrastructure: The Orderflow Proxy is operated by Flashbots, which handles the routing of encrypted transactions to builder nodes. This code has not been “developed in the open” as Flashbots usually demands of other research studios, and has no mention if it is run in a TEE. If democratizing orderflow is the goal of BuilderNet, this is a huge oversight.
Software Updates: Flashbots develops and maintains the rBuilder software and enclave image. Updates are centralized under its release cycle.
Missing Components: Not all components of BuilderNet are open source. Like the Orderflow Proxy, the bidding isn’t open, and this could be a crucial piece that provides missing information.
In short, BuilderNet reduces trust in individual builders but introduces new trust dependencies in Flashbots’ infrastructure and processes. While many of these are interim design choices, no clear pathway to a sustainable solution has been presented, so these represent key areas to watch as the network matures.
A Measured Step
BuilderNet wants to decentralize the builder role in seemingly meaningful ways. It allows for shared orderflow, standardizes refund logic, and provides privacy guarantees through enclave isolation. But this decentralization is superficial—an architectural sleight of hand that reshuffles power without fundamentally redistributing it. The reality is that Flashbots controls the gatekeeping, the infrastructure, the software lifecycle, and the flow of encrypted transactions.
For a system claiming to solve the problems of builder centralization, it has reproduced nearly all of them, just with better branding and a fresh coat of TEE-powered trustwashing. Flashbots asks the community to trust that this will all be opened up someday, but there's no public roadmap, no transparent governance process, and no mechanism to enforce accountability.
The longer BuilderNet operates under a closed, curated, and opaque model, the more it becomes part of the problem it set out to fix. It’s not enough to replace builder duopolies with enclave monopolies.
If BuilderNet is serious about decentralizing Ethereum's block-building layer, it needs to prove it and do so quickly and publicly. That means open access, open source, and open governance. Anything less isn't innovation; it's centralization with extra steps. If it can evolve to include more diverse hardware, software, and operators or whether it simply shifts centralization to new dependencies remains an open question. As the ecosystem continues to evaluate new approaches to PBS, these questions will help determine which trade-offs are acceptable and which aren't.
Disclaimer: This post represents independent research and not EigenPhi's official stance.
 | A guest post by
|