Lido Discusses Builder Payment Guarantees and Trusted Connections in Ethereum's ePBS Design

In a Sept. 8-11 Lido discussion, Commit-Boost contributor Jason Vranek argued that builders funding protocol-backed payments face costs from idle Ethereum, failed delivery, and offers they wanted to cancel.

Those costs could make trusted connections more competitive. Meanwhile, Titan Builder said it expects validators to continue reaching it through relays that organize auctions and handle publication.

An operator’s configuration helps determine which block-payment opportunities its validators can consider. For builders, the same settings help determine access to those validators.

As of Sept. 13, Ethereum.org lists Glamsterdam as testing on devnets, with mainnet expected in the fourth quarter of 2026 and no confirmed date. Lido contributors are discussing a proposed direction ahead of a future DAO vote.

Glamsterdam’s technical purpose remains distinct from those market choices. Separating consensus work from execution processing gives validators more time for heavy work, whether operators continue using relays or not.

Transaction-inclusion guarantees belong to another part of the roadmap. The Ethereum Foundation’s Sept. 7 priorities identify fork-choice enforced inclusion lists (FOCIL) as a Hegotá headliner.

That planned mechanism would let validators impose inclusion requirements on builders’ blocks.

What the payment guarantee covers

Enshrined proposer-builder separation (ePBS) formalizes the exchange between a validator proposing a block and the builder assembling its transactions.

In the proposed EIP-7732 design, which remains under Review, the proposer includes a builder’s signed commitment in its consensus block, and the execution payload containing the transactions follows separately.

The design accommodates two payment forms. A collateral-backed payment draws on Ethereum the builder has deposited into the protocol, and a trusted payment depends on the builder honoring a promise through another payment route.

That trusted payment can still be an ordinary on-chain Ethereum transfer.

The current consensus specification checks the builder’s available balance and records the collateral-backed amount as a pending payment to the designated fee recipient. Settlement uses withdrawals to the execution layer, while the recipient receives an execution-layer payment, rather than a direct increase in the validator’s effective staking balance.

For a timely proposer whose block receives the required support, the guarantee can survive the builder’s failure to deliver the committed payload.

The design also protects a builder when a proposer withholds the beacon block containing its commitment and reveals it late.

That risk allocation is the economic hinge. A proposer can protect against missing payloads, while the builder takes on exposure to paying without successfully delivering its block. Choosing a trusted payment leaves the proposer dependent on the counterparty’s promise.

Vranek’s Sept. 11 explanation identifies three potential costs. A builder must maintain ETH reserves inside the protocol to fund its payments, it must be able to cover unusually valuable blocks, and a committed payment can remain due when delivery fails, or the builder would have preferred to cancel its offer, subject to the protocol’s payment conditions.

Those costs could affect the amount a builder is willing to pay for the same block-building opportunity. Capital held in reserves to secure payments cannot simultaneously serve another use, while exposure to payment without successful delivery can also make a builder less willing to commit its maximum payment.

A trusted arrangement could reduce those costs and leave more room to pay the proposer. Whether that produces a higher payment for a proposer depends on the amounts available and the counterparty’s performance.

The distinction between a possible advantage and a measured premium also shapes Mike Neuder’s August analysis. He predicts that established trust between proposers, builders and relays will persist, but labels his market expectations conjectures.

In a subsequent reply, he says he expects the block-building market to remain largely unaffected, rather than necessarily become worse.

Open bidding and relay connections can coexist

Lido’s initial Aug. 22 direction divided offers by payment type: accept eligible collateral-backed offers broadly, while restricting trusted offers to a governance-approved allowlist.

Vranek’s Sept. 3 response proposed open peer-to-peer offers alongside configured builder or relay endpoints. Payment and connectivity are separate choices. Under the gossip specification, peer-to-peer offers have no trusted payment component. A configured connection can carry collateral-backed payments, trusted payments, or a mixture.

An open route lets an eligible builder reach validators without each operator first adding its endpoint, while a configured route can connect to a relay serving several builders.

Titan contributor George said on Sept. 8 that Titan does not plan to open its own direct proposer endpoint and expects validators to keep connecting through relays. He argued that relays can preserve a common auction, manage payload publication and reduce the burden of maintaining individual builder relationships.

His concern was that a builder with private access to a proposer could also watch the public relay auction and gain a last look at competing offers. In that situation, a relay offering shared access could help preserve competition.

The open bidding route also has advocates. Responding to Neuder, Justin Traglia argued that builders could register additional identities and improve connectivity to compete for proposers without configured connections.

He acknowledged latency disadvantages and the extra stake needed for additional identities. His argument leaves room for competition outside configured relationships, even if those relationships remain popular.

Even after an operator chooses its offer sources, it must decide how to value payment promises.

The builder specification lets a proposer set a maximum trusted payment to count from each builder. It values an offer by adding the collateral-backed amount to the trusted component, counted only up to that limit.

A zero limit leaves only the collateral-backed portion contributing to valuation, making trust a practical selection rule. A builder may offer a payment that the proposer’s settings don't count in full, while counting a trusted promise in full means relying on that builder to deliver.

What Ethereum operators can measure

Operators also need an accurate record of their choices. In the Sept. 8 Lido discussion, Stakely’s Paco asked that compliance be assessed against offers the proposing node observed. He also called for consistent offer sources and settings across backup nodes, plus a local-building fallback.

Paco warned that differences in offer handling across clients could increase incident-management costs and encourage operators to run fewer client types. Gabriella_S’s Sept. 9 response supported considering logging of observed offers and keeping that diversity risk in scope.

These remain policy and implementation questions under discussion.

The next meaningful evidence will come from the policy Lido puts forward, the offer-handling clients implement, and the payments available under those configurations.

An open route can broaden access, and protocol-backed settlement can reduce reliance on payment promises. A possible payment advantage for trusted arrangements will depend on how builders price that protection and which opportunities operators allow their validators to see.