Ethereum builders weigh locking ETH vs. trusted relays

Lido contributors met Sept. 8–11 to debate payment guarantees and connectivity under the proposed enshrined proposer-builder separation in EIP-7732. The proposal would have a proposer include a builder’s signed commitment in the consensus block while the execution payload with transactions is submitted separately. Payments under the design may be collateral-backed, drawing on ETH deposited into the protocol and recorded as pending payments, or trusted, relying on a builder’s promise to pay by other means, including ordinary on-chain transfers. The consensus checks a builder’s available balance for collateral-backed offers and settles those amounts via execution-layer withdrawals to the fee recipient; trusted offers depend on the builder honoring the commitment.

Jason Vranek, a Commit-Boost contributor, identified three costs for builders using protocol-backed payments: maintaining ETH reserves inside the protocol, holding enough capital to cover unusually valuable blocks, and remaining liable for committed payments when delivery fails or when a builder would prefer to cancel an offer. He explained that ETH locked as collateral cannot be used for other purposes and that failed delivery can leave a payment due regardless of benefit to the builder.

Participants noted that trusted payments can lower those capital requirements and allow builders to offer higher payments, while shifting risk to proposers who must rely on a counterparty’s performance. The builder specification lets proposers set a maximum trusted-payment amount that counts toward an offer’s valuation. If a proposer sets that limit to zero, only collateral-backed amounts contribute to the valuation.

The discussion also covered connectivity and auction architecture. Lido had earlier proposed broadly accepting eligible collateral-backed offers while restricting trusted offers to a governance-approved allowlist. Under the gossip specification, peer-to-peer offers carry no trusted payment component; configured connections can carry collateral-backed, trusted, or mixed payments. A Titan contributor, George, wrote that Titan does not plan to open a direct proposer endpoint and expects validators to continue connecting through relays that organize auctions, manage payload publication and reduce the burden of maintaining many individual builder relationships.

Other contributors argued for open routes. Justin Traglia proposed that builders could register additional identities and improve connectivity to compete for proposers without configured connections, noting the trade-offs of added latency and extra stake for more identities. An August analysis from Mike Neuder predicted that established trust among proposers, builders and relays will likely persist and that the block-building market may remain largely unchanged.

Operators raised implementation and policy questions. A Stakely contributor, Paco, asked that compliance be assessed against the offers the proposing node observed, and urged consistent offer sources and settings across backup nodes plus a local-building fallback. Gabriella_S supported logging observed offers and keeping diversity risk in scope. Contributors warned that differences in how clients handle offers could increase incident-management complexity and encourage operators to run fewer client types.

On the Ethereum roadmap, Glamsterdam is testing on devnets with a mainnet target in the fourth quarter of 2026. The Ethereum Foundation has identified fork-choice enforced inclusion lists (FOCIL) as a priority; FOCIL would allow validators to impose inclusion requirements on builders’ blocks.

The discussion outlined specific trade-offs between locking capital in protocol-backed settlement, accepting counterparty risk through trusted payments, and the connectivity models operators choose for validators. Continued policy decisions, client implementations and the availability of payments under different configurations will determine which offers validators can observe and how builders participate.