Thanks to the Sunnyside Labs team for the proposal and for taking the time to meet with us during Devconnect. We appreciate the opportunity to dig into the design space together to solve emerging needs of decentralized L2 block building. Below is a summary of our discussion and some reflections on areas that seem most promising for exploration.
Summary
The core question behind the proposal can be reframed as: how to safely delegate L2 block building to untrusted parties, and what new infrastructure is required to make this practical from both a security and performance perspective.
We focused on OP Stack based L2 block-building path, which today relies on a centralized sequencer with exclusive access to a private mempool. This initial proposal aims to preserve that private orderflow property while allowing external builders to construct blocks. This introduce new needs for verifiable integrity, encrypted orderflow distribution, and mechanisms for selecting next block’s payload.
Most of the initial design reuse concepts from L1 BuilderNet: TEE attestation, aTLS (or its successor), and a builder hub. Because gas is significantly cheaper on L2, many of the coordination functions that BuilderNet currently performs off-chain could be migrated on-chain, potentially making the system even more transparent and decentralized.
However, adapting these concepts in an L2 environment come with extra challenges.
Secure Mempool Sharing
We suppose that L2s will continue using private mempools for user protection and performance reasons. To share that orderflow with untrusted builders, the proposal mirrors BuilderNet’s model: builders attest to their TEE-verified execution environment, establish mutually verified encrypted channels, and exchange transactions without exposing them to operators.
The idea of an on-chain Builderhub is a major point of interest. Moving attestation verification, certificate management, and permissioning into smart contracts with flashtestations could meaningfully reduce trust dependencies and give L2s much more flexibility in configuring builder participation and enforcing policies.
The remaining challenge is the network-level identity problem: publishing IP addresses or connection metadata on-chain without compromising the operational security of TEE-protected keys. This will need dedicated design work.
Block Payload Selection and Incentives
After secure orderflow distribution, the next key component is determining which builder’s payload becomes canonical and ensuring builder’s participation:
- Leader election / payload selection, which could be implemented within rollup-boost.
- Incentive design, since untrusted builders require a reason to participate.
Incentive modeling, especially for MEV auctions in an L2 setting, is still a new design space and deserves its own focused research. It is unclear today what model can sustainably motivate independent builder operators without introducing unsustainable incentives or degrading UX. This is an area where collaboration across teams seems especially valuable.
An adjacent line of R&D would be in evolving the OP-Stack sequencer in a more traditional “validator” role.
Decentralization, Specialization, and System Goals
Finally, we discussed broader motivation for moving to a multi-builder L2 architecture. Specialization of builders could enable higher-performance block production, reduce spam, or surface more efficient strategies. At the same time, distributing transaction flow among multiple parties introduces meaningful network overhead, making performance-driven protocol choices essential (e.g., persistent websocket connections).
We want to ensure that any L2 builder network materially improves the system beyond the current centralized approach, not only in decentralization properties. Alongside the broader research effort, rigorous engineering validation will be required to ensure that a decentralized L2 builder network does not degrade performance or reliability and, ideally, enhances both.
Next Steps
From the discussion, we can establish the following concrete next steps:
- Builderhub design: further work on the network identity, permissioning, and reputation system needed for an on-chain Builderhub.
- Focused research sessions: schedule deeper dives on the hardest open questions, particularly around incentives, secure network metadata, and builder specialization models.
We welcome Sunnyside proposal and we look forward to continuing this exploration together.