Ethereum builders face a choice between locking up too much cash or relying on trusted brokers

Ethereum builders are debating whether to lock up large amounts of ETH as collateral or rely on trusted payment arrangements. The discussion took place in Lido's forums from Sept. 8 to 11 and centers on how the network should pay builders who assemble blocks under the proposed ePBS system. The stakes are practical: how builders pay affects what proposers receive and whether smaller builders can compete. Commit-Boost contributor Jason Vranek laid out the problem on Sept. 11. He argued that builders funding protocol-backed payments face three distinct costs. They must hold ETH reserves inside the protocol to fund their payment promises. They need enough capital to cover unusually valuable blocks. And a committed payment can remain due even when delivery fails or the builder would have preferred to cancel its offer, subject to the protocol's terms. Those costs matter because capital held in reserves cannot serve another purpose at the same time. A builder tying up ETH to secure payments has less flexibility. Vranek's argument is that these frictions could reduce what a builder is willing to pay for the same block-building opportunity, which means less for the validator who proposes the block. The current consensus specification checks a builder's available balance and records the collateral-backed amount as a pending payment. Settlement uses withdrawals to the execution layer, while the recipient receives an execution-layer payment rather than an increase in the validator's effective staking balance. That mechanism is the reason the collateral requirement feels so heavy. The alternative is a trusted payment, which depends on the builder honoring a promise through an ordinary on-chain Ethereum transfer rather than locked collateral. That arrangement can reduce the capital burden and leave more room to pay the proposer. But it comes with a trade-off. The proposer becomes dependent on the counterparty's promise rather than on protocol-enforced guarantees. The proposed EIP-7732 design, which remains under Review, formalizes the exchange between a validator proposing a block and the builder assembling its transactions. The proposer includes a builder's signed commitment in its consensus block, and the execution payload containing the transactions follows separately. The design accommodates both payment forms, giving operators a choice. 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. A builder offering a large trusted promise may find it is not fully counted if the proposer's settings cap it. Mike Neuder's August analysis predicted that established trust between proposers, builders, and relays will persist even as the protocol opens new paths. He labeled his market expectations conjectures and said in a reply that he expects the block-building market to remain largely unaffected rather than necessarily worse. His analysis is the closest thing to a prediction on where competitive dynamics settle once ePBS goes live. Relays may still matter even in an open bidding world. 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. His argument is that relays preserve a common auction, manage payload publication, and reduce the burden of maintaining individual builder relationships. He also flagged that a builder with private access to a proposer could watch the public relay auction and gain a last look at competing offers. An open route lets an eligible builder reach validators without each operator adding its endpoint first. Under the gossip specification, peer-to-peer offers have no trusted payment component, so connectivity and payment type are separate choices. Justin Traglia argued that builders could register additional identities and improve connectivity to compete for proposers without configured connections, though he acknowledged latency disadvantages and the extra stake needed. Glamamburg is listed on Ethereum.org as testing on devnets, with mainnet expected in the fourth quarter of 2026 and no confirmed date, as of Sept. 13. Separately, the Ethereum Foundation's Sept. 7 priorities identify fork-choice enforced inclusion lists as a Hegotá headliner. That mechanism would let validators impose inclusion requirements on builders' blocks, adding another layer to the payment and connectivity choices already under discussion. Operators also need consistent records of their choices. Stakely's Paco asked in the Sept. 8 discussion that compliance be assessed against offers the proposing node actually observed, with consistent settings across backup nodes and a local-building fallback. He warned that differences in offer handling across clients could increase incident-management costs and push operators to run fewer client types. These remain policy questions without settled answers.