On the broader "block builders are a chokepoint what about metabuilder" discussion: Technically, I still think TEEs are the best solution for pre-trade privacy + verifiable logic. Threshold solutions (with current tech) prevent rich execution logic which in turn leads to inefficiencies like spam as we've seen on many chains. The largest outstanding technical problem is dealing with latency-based tampering of encrypted transactions, which no solution fully solves today. The governance problem is by the most thorny. I think for maximally decentralised systems, you want to leave as much as possible up to the market, but still there are things that need to be decided on (who runs the verifiable logic? how should that logic evolve? how much should operators get paid vs users vs validator?). Inside of Flashbots and across the ecosystem we have toyed with many ideas of "partial builders" that process transactions in a specialised way and that already exists to some extent. There is already an implicit political balance between large orderflow sources, execution infra operators (builders, relays, OFAs etc), and validators. Probably the biggest downside of the current balance is that power is concentrated too heavily with a few market making firms that choose the winning builder (and consequently too little with the rest of the users). Perhaps the two biggest reasons BuilderNet hasn't (yet) become the network-wide decentralised building solution it set out to be is (1) we didn't allow enough free market competition within the system since everyone has to run the same logic and (2) we didn't have a clear enough governance story to convince other actors to join. We're working on both. An interesting thought experiment: what if we had a dashboard that showed all the order flow processors that contributed bundles that formed a block instead of just attributing blocks to single builders, how differently would people see the market? Relays, "builders", OFAs, RPCs, app backends, all play some role in merging user intents before they hit the blockchain (even though "builders" do represent a chokepoint and that should be addressed)

As of today, BuilderNet supports prioritised updates This means propAMMs and other designs that want to prioritise some calls over others are now feasible This + Titan's announcement earlier this week mark the beginning of a new chapter in transaction execution on Ethereum with a whole new set of challenges, opportunities and unknown unknowns (definitely tighter spreads) Making this new market efficient and reducing the need to rely on trusted intermediaries will require a lot of coordination across the ecosystem As a first step, we want landing updates to be permissionless. So we're launching v0 of a registry format we hope will become an industry standard - one where builders don't need to trust the prioritised updater. We've been collaborating with other builders and DeFi teams on this behind the scenes - post coming soon. Landing updates is just the beginning, we're cooking on several related features. Some of them are predictable, some of them are not - stay tuned. Docs in next tweet