Ethereum MEV Extraction and Rewards Part 2 - Revisiting Stance in Light of ePBS

Department of Decentralisation
1

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.

image (16)
image (16)1068Ă—707 235 KB

From this, Lido’s original goals for MEV extraction were ratified as follows:

  1. Node Operators should not build their own blocks for Lido validators
  2. Blocks should come from open, publicly accessible builder markets
  3. Bid selection (through relays) should be governed by a DAO-maintained allowlist
  4. 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.

2 Likes
2

Disclaimer, I’m part of the Commit-Boost team and helped shepherd the specs that shape the flow from proposers to builders. We do not run validators ourselves but have been thinking about and working with core devs on sidecar support post-ePBS. I’m very positive about this proposal, just wanted to point out some places where the latest version of the specs may be informative.

Does the two-track approach make sense to builders and operators? Are there any unaccounted scenarios where this approach breaks down?

I think that rather than slicing the tracks along the trust dimension (trusted vs trustless), it could make more sense to slice along the transport dimension (direct vs p2p).

Some nuance on the bidding mechanics since the trust and delivery method are often conflated: ePBS bids allow builders to include a trustless value and a trusted execution_payment, and proposers receive the same ePBS bid format over p2p and direct-to-builder connections. All p2p bids must be trustless (execution_payment = 0), while direct-to-builder bids may contain a mixture of trustless and trusted payments.

trustless bids should be accepted from any builder meeting protocol requirements […] Applying an allowlist here would only reduce competition and limit block value.

Splitting along the trust dimension raises questions here. Direct connections definitionally require an explicit allowlist, since your client needs the relay/builder’s URL to contact them for bids. The most straightforward way to apply this principle while avoiding allowlists is a policy to prevent disabling p2p bids (the specs allow this easily). They are trustless, permissionless for builders to submit to, and do not require per-builder configurations to connect to.

Over direct connections, builders can be trusted to respect transaction filtering requirements, abstain from exercising the free-option problem, and deliver their trusted bids. This requires curating an allowlist with more to consider beyond just trusted vs trustless payments.

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?

  • Absolutely holds post-ePBS. The KeyManager API now allows you to configure a blanket min_bid that applies across p2p bids and a per-builder min_bid that applies to direct connection bids. These along with a builder_boost_factor give you fine-grained control over how you value locally built payloads vs external bids.

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?
[…] Supporting an additional PBS payment method would require Node Operators to run and maintain parallel flows

Relays, builders, and sidecars will operate on top of the ePBS flows using the latest Builder Spec, there’s no need to maintain parallel flows. Clients and sidecars will adjust to ePBS flows / payments will flow to the standard fee_recipient.

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.

Due to the cost of capital, lack of block cancellations, delivery risk, tail-end MEV opportunities, it’s been argued that the competitive MEV opportunities will be over direct trusted connections.

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?

Clients are discussing circuit breaker behavior which would blacklist builders that fail to deliver payloads. These are implement per-client and still under development, so we’d encourage Lido to engage/explore policies aligned with their MEV extraction goals.

Putting all of this together, our position would be to slice the two tracks along the transport layer:

  • P2P Bids: Set sensible config values (min_bid/ builder_boost_factor) to accept all trustless bids
  • Direct-to-Builder Bids: Maintain allowlist of approved builders/relays via DAO governance

These tracks would be directionally aligned with the proposal while requiring minimal changes to existing allowlists as most relays will continue operating post-ePBS.

4 Likes
3

Hi all, Paco from Stakely here. Thanks Gabriella for the post. The two-track direction makes sense to us, and we’d echo @JasonVranek’s framing: split by transport, not by trust. From an operator’s perspective, this is the option that simplifies operations. The p2p track needs no list at all (the client verifies builder collateral on-chain), and the allowlist is only needed where there is a real identity: direct builder/relay connections.

Three points we’d like to highlight as a NO:

  1. Professional operators run redundant BN/CL setups, and a proposal can be served by a backup node at any moment. Whatever is ratified must behave identically on every node that could propose (same bid sources, same allowlist state, same min-bid), so a routine failover should not become a compliance breach.

    One edge case worth mentioning: p2p bid visibility depends on gossip mesh health. A BN that restarted minutes before a proposal, or is still acquiring peers, will see a much smaller bid set than a healthy node. Unlike blocks or attestations, bids can’t be backfilled: what the node didn’t see is gone. Proposing on the second-best bid, or falling back to a local block via min-bid, is correct operator behavior in that state, not underperformance. Our request: judge compliance on the bids the node actually saw at proposal time, not on a network-wide best bid reconstructed afterwards. Clients logging the observed bid set would make this auditable.

  2. Keeping min-bid preserves local building as the liveness fallback if the builder market degrades. And with signed bids, enforcement is easier post-ePBS, not harder.

  3. On operational cost, today all bid logic lives in the sidecar (CB, Mev-Boost), so it behaves the same no matter which BN client we run. With ePBS, part of that logic moves into each BN client, with its own defaults and details. For operators running several BN flavors, like us, the testing and incident-response surface grows with each client. We expect the extra cost to come mainly from incident management, not from day-to-day config. There is also a risk that some operators reduce BN client diversity to limit that surface, consistent bid handling and observability across clients would mitigate this.

Happy to test on devnets/testnet and share operational data.

3 Likes
4

Hey, George from Titan Builder here.

Thanks for posting this, we’re broadly very aligned with the stance here.

One thing I think is worth adding some context on is how we’re thinking about connecting to proposers post-ePBS. From our side, we’re not planning on opening up a direct Titan Builder endpoint. Our expectation is that validators will keep connecting to us through relays.

We think relays remain very valuable infra even once ePBS provides the underlying payment guarantee. They preserve a common/open auction between builders and enable new innovations like multi-party block construction. They also handle a lot of the complexity around payload publication (especially with the PTC changes), and mean every validator or operator doesn’t have to maintain its own set of direct relationships with individual builders.

The last point I think is particularly important. There are going to be cases where additional policies are required on top of just the payment guarantee ePBS provides. The clearest example is regulatory tx filtering. There is, and will likely continue to be, a significant portion of stake that needs a trusted agreement with the parties they configure in their clients to satisfy those requirements. Without relays providing equal access this creates a big integration and trust barrier for new builders. It also makes it hard to preserve an open auction if some builders have private/direct access to proposers while also getting a “last look” at the relay auction via the public top-bid stream.

Our preference is therefore for private/configured Builder API connections to generally point at relays rather than individual builders. The relay can itself appear as a builder under ePBS and still run an open auction across the builders behind it. Where possible we also think operators should keep listening to the P2P layer for trustless bids, as a robustness fallback if all relays go down.

We’re planning on working on a full write-up, together with the other major builders and relays, on how we’re thinking about the post-ePBS market structure and how node operators can connect. But wanted to add our perspective quickly here as it seems very aligned with the direction of this discussion!

4 Likes
5

Thanks all for the response and feedback so far! I want to highlight and answer a couple of these:

@JasonVranek:

I think that rather than slicing the tracks along the trust dimension (trusted vs trustless), it could make more sense to slice along the transport dimension (direct vs p2p).

In my opinion this distinction is very valid i.e: treating trust and transport as a single axis in the evaluation instead of two separate points. However, it doesn’t necessarily change the direction of the approach (basically, having broad acceptance of trustless bids) although the implementation mechanism should be in discussion, keeping p2p enabled might very well be a solution here.

Due to the cost of capital, lack of block cancellations, delivery risk, tail-end MEV opportunities, it’s been argued that the competitive MEV opportunities will be over direct trusted connections.

Can you expand a bit on this idea? Since it seems to invert an assumption the post rests on (trustless as the expected default, with trusted connections served on request) I don’t fully understand how or why competitive flow would actually concentrate around direct trusted connections.

@Pacobits:

Our request: judge compliance on the bids the node actually saw at proposal time, not on a network-wide best bid reconstructed afterwards. Clients logging the observed bid set would make this auditable.

Personally agree that this should be stated as a principle in whatever gets drafted.

Things like: bids can’t be backfilled, gossip mesh health can vary, a node could restart before its proposing slot and because of that see a smaller bid set, all probably points to correct behavior rather than underperforming. As it is a genuine departure from how the reference-block comparison works today, it only really works if clients log the bid set they actually observed at proposal time.

I think this is something that should be raised with the client teams early.

There is also a risk that some operators reduce BN client diversity to limit that surface, consistent bid handling and observability across clients would mitigate this.

Flagging that we don’t want this to drop. If bid logic moving from the sidecar into each BN client pushes operators toward running fewer flavors, that’s a decentralization cost the policy would be creating by accident. No good answer yet from me, but it belongs in scope.

@gd-0:

Our preference is therefore for private/configured Builder API connections to generally point at relays rather than individual builders. The relay can itself appear as a builder under ePBS and still run an open auction across the builders behind it.

Thanks for sharing. This is helpful for sizing the practical change. If relays remain the primary path for direct connections and appear as builders under ePBS while running an open auction behind them, that wouldn’t materially change the allowlist approach.

2 Likes
6

Yes! Sharing my thoughts below but recommend these articles that do a much better job at explaining. At a high level, the protocol offers unconditional/trustless payments as an option, but exercising this option comes with subtle costs that would be reflected in bid values (and scale with the size of the MEV opportunities).

  • capital - the builders must manage their in-protocol (non-productive) eth reserves to payout bids
  • delivery - the builder must payout for bids they wanted to cancel or if for whatever reason their payload was not delivered in time
  • opportunity - the builder must have enough eth reserves to payout tail-end MEV blocks

Sorry, I can’t share links so writing here:

  • Mike’s ethresearch post: “epbs-distilled”
  • Titan’s Summer 2025 post: “builders-and-relays-in-epbs”
1 Like