BuilderNet and the Return of Exclusive Orderflow—With Extra Steps
How exclusive deals and shared infrastructure risks undermine Ethereum's decentralization promise.
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.
“Now, here, you see, it takes all the running you can do, to keep in the same place.”
—-Red Queen, from Chapter 2 - The Garden of Live Flowers, THROUGH THE LOOKING-GLASS
One of BuilderNet’s core promises is to move Ethereum away from exclusive, opaque orderflow relationships that fueled centralization in the current builder landscape. In practice, however, signs are emerging that these exclusivity dynamics are returning, just under a more complex wrapper.
The top orderflow aggregators (OFAs), searcher teams, and some other major wallet providers have shared that they were approached to join BuilderNet under terms that would effectively recreate exclusivity. The pitch: become an operator and send all your flow only to BuilderNet. While this may seem like a commitment to decentralization by pooling order flow across multiple builders within the network, it introduces the same structural fragility that came with routing transactions to a single builder like Titan or Beaverbuild.
The recent ~12-hour outage affecting the entire BuilderNet operator set underscored this risk. Additionally, they experienced an outage during the Pectra upgrade on the 23rd of May, lasting approximately 17 hours.
During this window, any application or OFA that would have exclusively routed through BuilderNet would see degraded or completely halted performance. Because all BuilderNet operators share a common infrastructure dependency (same codebase, same enclave stack, same cloud platform, GCP, which had a major outage recently), any issue on any of those layers affects all builders simultaneously. Some teams mentioned there had been an outage on submitting bundles and private transactions for almost a full week, while the only orderflow they were using seemed to be Beavers. That’s not resilience; that’s monoculture.
Relying on a single builder was risky. Relying on a set of builders who all run the same stack and go down together is arguably worse.
This also raises questions about BuilderNet’s incentive alignment. If a key input to the network’s decentralization—open, shared access to orderflow—is quietly being reshaped into a set of exclusive or preferential deals, we haven’t escaped the old model. We’ve just added more layers of indirection.
Instead of one builder cutting deals with one searcher, we may now have a “trusted enclave consortium” cutting deals with OFAs. Functionally, it's not much different.
If BuilderNet wants to break the cycle of exclusive orderflow and centralizing incentives, it needs to ensure that:
Orderflow routing remains open to all builders and non-exclusive, regardless of BuilderNet participation
Infrastructure dependencies are diversified
External applications aren’t penalized for refusing exclusivity
Anything else risks recreating the same extraction dynamics, just with extra steps.
Here is the previous post from the same guest researcher.
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: This post represents independent research and not EigenPhi's official stance.
 | A guest post by
|