Lido Contributor Recommendations for the Glamsterdam Upgrade

# Lido Contributor Recommendations for the Glamsterdam Upgrade Important Disclaimer: This assessment has been compiled from extensive discussions and inputs provided by numerous contributors within the intersection of Ethereum and Lido communities. It aims to capture the key arguments and perspectives shaping the current debate. However, it is crucial to note that this document is not an official publication of the Lido DAO and does not represent a formal governance position or the unanimous opinion of all contributors. --- ### **Choice** Lido Contributors advocate in favor of the following paths as headliners for Glamsterdam: 1. Execution Layer: EIP-7928, or Block-level Access Lists (BALs) for a high-impact, low-risk proposal that enhances transaction execution efficiency. 2. Consensus Layer: Slot Pipelining. Lido supports either as a viable slot pipelining solution, with a preference for solutions that are simpler to implement and monitor on the Consensus Layer. - **EIP-7886, or Delayed Execution**: offers a potentially lower-complexity integration path. - **EIP-7732, or ePBS:** brings more efficiency than Delayed Execution and is a more mature proposal. Our collaboration with [Potuz](https://x.com/potuz_eth) from [Prysm](https://www.offchainlabs.com/prysm) (Ethereum Client team from [Offchain Labs](https://www.offchainlabs.com/)) on EIP-7732 has been invaluable, leading to a design that is significantly more workable for on-chain staking protocols. Our concern is not with the current specification, but with the inherent risk that any proposal of this complexity can change during its final stages of development. For decentralised staking middleware protocols like Lido, late-stage modifications can require significant and costly engineering efforts to adapt. From this operational risk perspective, the simpler architecture of EIP-7886 presents a more predictable path, with a preference for an EIP-7886 variant that takes lessons from EIP-7732. Finally, we are supportive of the following EIP potentially as a co-headliner: 3. Consensus Layer: EIP-7805 or FOCIL, enabling in-protocol credible neutrality with strong cryptoeconomic guarantees. ### Introduction The selection of a [headliner EIP for Ethereum's Glamsterdam](https://forkcast.org/upgrade/glamsterdam) upgrade is more than a technical decision; it is a statement of the Ethereum ecosystem’s collective priorities. As contributors to the largest and decentralised Ethereum staking protocol, our objective is to advocate for a path that maximizes long-term value for the entire ecosystem, and select EIPs that uphold Ethereum’s and Lido’s values. A core tenet of the EIP process is the necessity of robust community discussion and consensus before an upgrade is enshrined in the protocol. Adhering to this principle requires us to respectfully set aside several proposals as non-headliners for Glamsterdam. These are hard choices. ### The Five Contenders We consider the following proposals to be headliner contenders: 1. [EIP-7805](https://forkcast.org/upgrade/glamsterdam#eip-7805), or Fork-Choice Inclusion Lists (FOCIL). 2. [EIP-7782](https://forkcast.org/upgrade/glamsterdam#eip-7782), or Reduce Block Latency. 3. [EIP-7886](https://forkcast.org/upgrade/glamsterdam#eip-7886), or Delayed Execution (DE). 4. [EIP-7732](https://forkcast.org/upgrade/glamsterdam#eip-7732), or Execution Payload-Block Separation / enshrined Proposer Builder Separation (ePBS). 5. [EIP-7928](https://forkcast.org/upgrade/glamsterdam#eip-7928), or Block-level Access Lists (BALs). These five proposals represent the most potent paths forward for Glamsterdam. FOCIL brings powerful, in-protocol censorship resistance by providing strong cryptoeconomic guarantees of transaction inclusion. EIP-7782 aims to directly enhance user experience and DeFi efficiency by reducing block latency. ePBS and Delayed Execution both address the vital goal of laying the groundwork for scaling network throughput via slot pipelining (a mechanism that separates the validation of a block's header from its computationally intensive payload). Block-level Access Lists introduces baseline protocol functionality to meaningfully boost efficacy of parallel execution of transactions. ### The Tradeoff: Latency vs. Pipelining Shorter slots are an inevitability in Ethereum’s roadmap. They offer better UX for Dapp users, and shorter slots are a net good for reducing LVR-specific issues in on-chain secondary markets. While the immediate benefits of shorter block times from EIP-7782 are clear, pursuing latency reduction first could potentially be a tactical gain at the expense of a strategic one. From a [recent analysis of shortening slots versus slot pipelining](https://ethresear.ch/t/the-glamsterdam-equation/22760), [aelowsson](https://ethresear.ch/u/aelowsson) shows that in a shortened-slot regime, payload propagation becomes the primary bottleneck to solve. Aggressively shortening slots without first optimizing the underlying process could amplify existing bottlenecks, leaving the network with little room to increase throughput. By first implementing a robust slot pipelining solution, we can prioritise addressing the root cause of inefficiency. Pipelining decouples block validation from execution and makes the entire block production process more efficient. This allows us to not only immediately increase gas limits and blob count but also makes future reductions in slot time safer and more impactful. There is also a chance that (pending observations and analyses) slot re-structuring could potentially allow us to reduce latency further than the initially proposed 6 seconds in EIP-7782. In that sense (regardless of which slot pipelining EIP gets selected) we advocate for slot re-structuring before reducing slot duration. The critical work lies in choosing between the two primary proposals for slot pipelining: EIP-7732 (ePBS) and EIP-7886 (Delayed Execution). Both aim to improve network efficiency by reimagining block production as a decoupled, two-stage process. This allows the simple consensus header to propagate first for fast attestation, while the complex execution payload is processed later, creating more time for validation. The result is a direct path to higher gas limits, larger blob counts, and fewer orphaned blocks. While they share a goal, they present different trade-offs in their design and maturity. ### Slot Pipelining, Part I — The Case for ePBS (EIP-7732) EIP-7732 (ePBS) represents a more comprehensive, mature, and strategically sound path forward. 1. ePBS is [already being implemented and tested by multiple client teams](https://x.com/ChodoKamil/status/1945154735058657357). This significant head start de-risks the Glamsterdam timeline and provides ample time for refinement, which cannot be said for Delayed Execution. 2. ePBS optimizes the entire block production pipeline, providing more time for both payload execution _and_ blob propagation. This directly advances our goals of scaling both L1 compute [and data availability for L2s](https://ethresear.ch/t/the-glamsterdam-equation/22760#:~:text=Overall%2C%20ePBS%20is%20once%20again%20decidedly%20stronger%20than%20DE%20in%20terms%20of%20blob%20throughput%2C%20at%20all%20possible%20slot%20times), whereas Delayed Execution primarily addresses compute. 3. The research community has signaled [strong compatibility of ePBS with FOCIL](https://ethereum-magicians.org/t/epbs-focil-compatibility/24777), our best tool for censorship resistance. Furthermore, emerging solutions for preconfirmations are being designed with ePBS compatibility in mind, highlighting its role as a foundational layer for future UX improvements. The primary argument against ePBS is its apparent complexity, as it introduces a new validator duty via the Payload-Timeliness Committee (PTC) and modifies the fork-choice rule. This concern is valid, but we must evaluate complexity not just by the number of components, but by their nature and purpose. Drawing from Ethereum's core design principles, ePBS represents a step forward in [_encapsulating complexity_](https://vitalik.eth.limo/general/2022/02/28/complexity.html) (Vitalik Buterin, 2022). It achieves a cleaner and more robust separation of concerns between the consensus and execution layers with a simple interface between the two (the PTC) which has a narrowly defined role; this allows for a significant simplification of the protocol. #### The cons of in-protocol proposer builder separation, as per ePBS The primary challenge of ePBS for a staking protocol like Lido stems from its introduction of an in-protocol option that must coexist with the established MEV-Boost ecosystem. This creates an immediate dual-pipeline operational environment; as a protocol, Lido cannot enforce which path its node operators choose. Consequently, Lido contributors must build and monitor two separate systems for block production and reward accounting: a non-trivial increase in protocol complexity. Complexity carries security and implementation burdens. The initial ePBS specifications, for instance, contained an existential security risk where a malicious entity could theoretically drain a validator's entire delegated stake through the in-protocol bidding mechanism—an immediate non-starter for Lido. Addressing such deep-seated issues, which are a direct consequence of modifying the consensus layer, requires careful and costly development across our infrastructure. Lido contributors have engaged in extensive collaboration with client teams, such as with [potuz](https://ethresear.ch/u/potuz) from the Prysm team. The goal of these discussions has been to refine the EIP, ensuring that the final specification is not only secure but also operationally viable for the staking protocols that form a core part of Ethereum's infrastructure. Some suggestions borne out of these discussions are: 1. A dedicated `0x03` withdrawal credential prefix must be required by validators registered as ePBS builders. Staking protocols can now safely manage risk by not assigning the `0x03` credential to validators in permissionless modules like the CSM, effectively preventing them from acting as builders, while still allowing them to build locally. 2. The builder's bid must include a `feeRecipient` address. Successful ePBS building bids are processed as a standard withdrawal directed to this address, entering the main withdrawal queue. This ensures that rewards are sent to the correct smart contract on the Execution Layer, thereby re-using existing, battle-tested fee-collection infrastructure without modification. 3. The Lido protocol permits local building with (only) zero-value bids to any validator (including `0x00` - `0x02` withdraw credential types) in their own slot; the block's intrinsic value capture from transaction base fees and priority tips is still directed towards the [`LidoExecutionLayerRewardsVault`](https://docs.lido.fi/contracts/lido-execution-layer-rewards-vault). This effectively preserves local-building as a safe, economically neutral fallback, maintaining the same security principles found in [Lido’s Standard Node Operator Protocol](https://github.com/sssngth/documents-and-policies/blob/BlockProposalsV3.0/Lido%20on%20Ethereum%20Standard%20Node%20Operator%20Protocol%20%E2%80%93%20Block%20Proposals.md) policies. ### Slot Pipelining, Part II — The Case for Delayed Execution (EIP-7886) Delayed Execution (DE) emerged as a simpler, more narrowly focused alternative. Its appeal lies in its promise to deliver the core benefits of pipelining with what appears to be minimal changes to the consensus layer, which could present a less risky integration path for Lido. The primary challenge with DE is its immaturity. The specifications are not yet well-established, and there is [still a chance that consensus layer changes may be required](https://ethereum-magicians.org/t/eip-7886-delayed-execution-the-case-for-glamsterdam/24500/2?u=fiddy), creating a risk of the unknown. From [The Glamsterdam Equation](https://ethresear.ch/t/the-glamsterdam-equation/22760), Delayed Execution may be better if slots are between 6-9 seconds, whereas ePBS is significantly better out of this range (i.e. shorter or longer slots). This has to do with the fact that ePBS advocates for an approach where the block header (containing consensus layer metadata) is attested first and the payload attested later, whereas DE advocates for the delayed validation of the entire block. Since the beacon chain metadata is small, the propagation across the p2p network is significantly faster than propagating entire blocks: thus, DE has measurable degradation of performance below the 7.3 second mark where shortening slots forces proposers to build smaller blocks leading to a reduction in throughput despite an improvement in latency. A hybrid DE + PTC variant represents the best-case scenario, combining the lower implementation risk of DE with the key performance benefit of ePBS. By adding a PTC, the network can prioritize the propagation of the small beacon block for early attestation, solving the performance degradation issue at shorter slot times. This evolved version of DE is a powerful contender, offering a path to high throughput across a wide range of potential slot times without adopting the full complexity of ePBS, making it a strategically sound option for Lido and the broader ecosystem. ### Verdict: Advocating for the ideal scenario From our vantage point, the choice of an in-protocol option for PBS adds significant protocol complexity to the consensus layer. The most appealing part of both EIPs is the introduction of delayed execution/payload-validation via a slot-pipelining approach. From this standpoint: 1. Analysis suggests that ePBS offers a significantly better slot pipelining approach than delayed execution. 2. There is a chance that the in–protocol PBS option will probably be under-utilised in favor of out-of-protocol options. 3. The Delayed Execution approach suits Lido’s needs best, simply by ignoring the need for in-protocol PBS. The [Delayed Execution + PTC variant](https://ethresear.ch/t/the-glamsterdam-equation/22760#p-55351-alternative-pipelining-variants-10) or ePBS’s slot pipelining sans an in-protocol PBS could be a potent middle ground. As of writing this assessment, there is an [overwhelming consensus from Ethereum Client teams in favor of ePBS over DE](https://x.com/terencechain/status/1945837782376788296) and stronger support for DE from Ethereum Researchers. Given that ePBS being included instead of DE would entail a larger lift from a protocol-changes perspective, Lido contributors will strive to work towards ePBS specs that are maximally secure for the protocol and simple in implementation and effects on the consensus layer. ### Why FOCIL (EIP-7805) Cannot Wait While scalability is a critical focus, it should not overshadow an equally fundamental pillar of Ethereum's long-term health: credible neutrality. EIP-7805 (FOCIL) delivers precisely this through strong, in-protocol censorship resistance, and its consideration cannot be deferred. To do so would send the signal that performance gains are valued over foundational principles, creating a precedent where censorship resistance is perpetually sidelined for other goals, like lower latency. A credibly neutral settlement layer is a universal good, essential for all users; cypherpunks, DeFi protocols, institutions, and rollups; who depend on a platform that cannot be weaponized against them. For this reason, FOCIL must be considered a headliner; it is a statement of our unwavering commitment to Ethereum's core values. ### Final Recommendation For headliners, the task is to choose one for the consensus layer and one for the execution layer. For the execution layer, our nomination would be [EIP-7928: Block-level Access Lists](https://forkcast.org/upgrade/glamsterdam#eip-7928). This is a relatively easy choice: BALs offer significant improvements to transaction execution and thereby scaling the L1. For the Consensus Layer, the choice between slot pipelining proposals is more complex. From a pure risk-management perspective for large-scale infrastructure, EIP-7886 (Delayed Execution) is preferable due to its smaller potential impact on the consensus layer and lower risk of costly last-minute changes. However, we must acknowledge that EIP-7732 (ePBS) has significant momentum, deeper specification maturity, and broader support among client development teams. Our position is therefore pragmatic: while we see the merits in DE's lower-risk profile, we are committed to working collaboratively to ensure that whichever pipelining solution is chosen (and we recognize this is likely to be ePBS) is implemented in a way that is secure and operationally viable for the entire ecosystem. Finally, we must address EIP-7805 (FOCIL). While some may argue that the network's current censorship resistance is strong enough to defer FOCIL to the next H\* hardfork, we believe this view misinterprets the nature of that strength. Today's resilience is built on social consensus and historical performance, not on in-protocol, cryptoeconomic guarantees. History has shown, from traditional financial rails to other global systems, that foundations built on assumptions are brittle; they work perfectly, until they suddenly don't. For developers and users to build the future of finance on Ethereum, they need the certainty that the base layer is a credibly neutral platform that cannot be weaponized. Including FOCIL is not about fixing a present-day crisis; it is about laying a foundation of stone instead of sand for the decades to come. Therefore, our final recommendation is for a Glamsterdam that headlines EIP-7928 (BALs) and a robust slot pipelining solution–either EIP-7886 or EIP-7732–while treating the inclusion of EIP-7805 (FOCIL) with the gravity it deserves.