Introduction
The original MEV stance groundwork post was written in mid-2022. At the time, the PBS pipeline was still taking shape, software like MEV-boost had not been battle-tested, and enshrined Proposer-Builder Separation (ePBS) was firmly in the research category. Four years later, the landscape has shifted substantially.
Out-of-protocol PBS has become the de facto standard for block production. Today, over 90% of Ethereum blocks are built off-chain through software like MEV-Boost and Commit-Boost, and the protocols and procedures (SNOPs) that guide Node Operator behavior for block production when running validators as part of Lido have evolved accordingly.
However, the next major chapter in Ethereum’s block production pipeline is approaching. Glamsterdam, Ethereum’s upcoming upgrade, brings ePBS directly into the protocol via EIP-7732. This is the right moment to revisit the assumptions that have shaped Lido’s MEV approach to-date and consider how should change going forward.
This post lays out the relevant changes, a direction Lido contributors consider rational as a starting point, and solicits input from node operators, relay operators, builders, stakers, and the broader community.
What changes with ePBS (EIP-7732)
EIP-7732 allows the exchange of timely payloads between validators and builders to happen partially or entirely in-protocol, with Ethereum itself enforcing the deal.
With the newly introduced payment settlement, builders can become in-protocol staked entities by depositing ETH into the beacon chain. When a builder submits a bid for a slot, they commit to a specific block hash and payment value. Once that bid is included in a beacon block, the committed value is deducted from the builder’s balance and credited to the proposer. From that point on, the proposer’s payment is guaranteed regardless of what the builder does next. From here on, we refer to these as Trustless payments.
The protocol also introduces a Payload Timeliness Committee (PTC), a subset of validators that attest to the committed execution payload being revealed in time, which introduces new operational responsibilities for validators.
- Payments come in two forms. Trustless payments are enforced on-chain and require builder collateral. Trusted payments are promises fulfilled elsewhere; a builder who withholds the payment (or declares but fails to include a trusted payment) risks network-wide blacklisting by validator clients.
- Every bid is cryptographically signed by the builder (or relay) that produced it, so validator clients can identify who signed every bid regardless of how it arrived. Validators can also self-built blocks which are also identifiable, assuming unmodified software.
- Validators will maintain a list of registered builders / relays through the validator clients, with new configuration parameters - most importantly whether a given builder’s bids are accepted on a trusted or trustless basis.
What this means for Lido’s MEV stance
Before getting into specifics, it’s worth restating the philosophy behind the current guidelines: validators should maximize value for stakers, while preserving Ethereum’s credible neutrality and decentralization properties.
From this, Lido’s original goals for MEV extraction were ratified as follows:
- Node Operators should not build their own blocks for Lido validators
- Blocks should come from open, publicly accessible builder markets
- Bid selection (through relays) should be governed by a DAO-maintained allowlist
- Compliance should be monitorable and deviations actionable
In practice, this has meant that Node Operators have adopted both MEV-Boost and Commit-Boost as MEV extracting software, that Lido has up until now favored PBS and rejected the vertical integration of proposing and building, that min-bid was adopted to preserve censorship resistance as an optional mechanism, and that local block building remained a viable fallback so validators never fully depend on builders and relays.
ePBS changes the underlying infrastructure but the underlying principles are expected to carry over. Side channels and private arrangements remain just as undesirable, and censoring of transactions could remain an issue to address.
Proposed direction
Lido contributors have been engaging in conversations with client teams and builders to determine how the market is expected to develop when the upgrade is rolled out. As a result of these conversations, a two-track approach using both payment modes and trust models is currently the research direction Lido contributors are taking, and one of the main topics we would like the broader community to consider:
-
Maximize market access through Trustless bids: trustless bids should be accepted from any builder meeting protocol requirements, such as registration and sufficient balance. Because settlement is backed by on-chain collateral, the protocol (not the validator) manages counterparty risk. Applying an allowlist here would only reduce competition and limit block value.
Bids from unregistered or unknown builders should only ever be considered on a trustless basis.
-
Keep the current allowlist approach for Trusted bids: trusted bids depend on the builder honoring payment off-chain, so they should remain limited to builders and relays approved through the existing DAO governance process.
The proposed combination preserves the properties the original stance was designed around: revenue is maximized because operators source from the full market, MEV hiding remains detectable because every bid is signed and attributable, and the trust that used to sit with relays is either eliminated or explicitly scoped through the regular governance process.
Next steps
We’re putting this direction forward as a starting point, not a conclusion. We’re particularly interested in perspectives on:
- Trusted vs. trustless split: Does the two-track approach make sense to builders and operators? Are there any unaccounted scenarios where this approach breaks down?
- Economic tradeoffs: In-protocol payments are credited on the consensus layer, which has different implications depending on the receiving validator’s effective balance. Whether trustless payments are economically favorable therefore depends on the composition of a validator set. What are the potential economic tradeoffs that affect Lido’s Node Operator set?
- Self-building: Lido’s stance has enforced self-building limits through the optional min-bid value. Does that stance hold in a post-ePBS world and if so, how?
- Client defaults: Client defaults will do much of the enforcement work against non-paying builders, including potential blacklisting. Should Lido’s policy define its own expectations, or defer to client behavior?
- Parallel payments: How should Lido handle a period in which out-of-protocol PBS and ePBS flows coexist, either as a transition period or as an ongoing situation once Glamsterdam is released?
- Operational cost and complexity: Supporting an additional PBS payment method would require Node Operators to run and maintain parallel flows, with monitoring/compliance tooling accounting for both. Is the operational burden justified?
- Bids market: What is the expected market default once the upgrade is live, especially regarding builder activity? The proposed direction assumes that trustless payments will be the default, with trusted bids served to operators who explicitly require them.
Timeline
Glamsterdam devnets are now running and public testnet activations are expected ahead of mainnet, with Q3/Q4 2026 widely seen as a realistic estimate. This gives us a narrow but workable window to move from discussion to a draft update before the upgrade lands.
We’ll aim to consolidate feedback from this thread into a proposal for comment by Q3, with the goal of a DAO ratification process soon after.