Ethereum’s ePBS Debate: Trusted Payments, Relays, and the High-Stakes Future of Block Building

A Quiet Debate Is Rewiring Ethereum’s Block Market

Inside Ethereum’s sprawling research ecosystem, a debate has been quietly intensifying over a question that cuts to the core of blockchain economics: who should pay for block production, and how much risk should each side bear? During a Lido discussion held from Sept. 8 to Sept. 11, Commit-Boost contributor Jason Vranek laid out a series of costs facing builders who use protocol-backed payments — idle Ethereum sitting in reserve, failed deliveries, and offers they would have preferred to cancel. Those costs, he argued, could make trusted connections more competitive. Around the same time, Titan Builder made a point of saying it expects validators to keep reaching it through relays, the auction-facilitating services that have long served as the connective tissue between block producers and validators. The stakes here are not merely theoretical. An operator’s configuration determines which block-payment opportunities its validators can see; for builders, the same settings determine whether they can reach those validators at all. That makes the conversation about payment types inseparable from a conversation about market access. With Ethereum’s block-building market becoming more competitive, small differences in connectivity and payment terms can add up quickly. The debate is unfolding against a backdrop of structural change across Ethereum. 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. But Glamsterdam’s technical purpose is distinct from the market choices being debated. By separating consensus work from execution processing, the upgrade gives validators more time for heavy lifting, whether operators continue using relays or not. Transaction-inclusion guarantees belong to a separate part of the roadmap: the Ethereum Foundation’s Sept. 7 priorities identify fork-choice enforced inclusion lists, or FOCIL, as a headline item. That planned mechanism would let validators impose inclusion requirements on builders’ blocks, adding another layer of accountability to a system already in flux.

Inside ePBS: Two Payment Models, One High-Stakes Tradeoff

At the center of the discussion is enshrined proposer-builder separation, known as ePBS, which formalizes the exchange between a validator proposing a block and a builder assembling its transactions. To understand why it matters, it helps to look at the status quo: validators today rely on external builders and relays to construct blocks, creating a complicated handoff that works but leaves room for efficiency gains and trust assumptions. ePBS is designed to make that handoff cleaner. In the proposed EIP-7732 design, which is still under Review, the proposer includes a builder’s signed commitment in its consensus block, and the execution payload containing the transactions follows separately. That split is deliberate: it allows the consensus layer to verify the commitment without forcing the proposer to handle the full payload immediately. The design accommodates two payment forms. A collateral-backed payment draws on Ethereum the builder has deposited into the protocol. A trusted payment, by contrast, depends on the builder honoring a promise made through another payment route — and that trusted payment can still be an ordinary on-chain Ethereum transfer. The mechanics matter. Under the current consensus specification, the protocol 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, so 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 itself against missing payloads, while the builder takes on exposure to paying without actually delivering its block. Choosing a trusted payment, meanwhile, leaves the proposer dependent on the counterparty’s promise. In other words, ePBS is not just a technical upgrade; it is a carefully calibrated system of incentives and protections designed to prevent either side from being stranded.

Why Collateral-Backed Payments Come With a Hidden Price Tag

Vranek’s Sept. 11 explanation walks through three potential costs for builders using protocol-backed payments. First, a builder must maintain ETH reserves inside the protocol to fund its payments. That capital is locked, effectively sitting idle when it could be deployed elsewhere. Second, the builder must be able to cover unusually valuable blocks, which means keeping even larger reserves on hand to handle spikes in demand and payment obligations. Third, a committed payment can remain due when delivery fails — or when the builder would have preferred to cancel its offer, subject to the protocol’s payment conditions. These costs can 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. But whether that produces a higher payment for a proposer depends on the amounts available and the counterparty’s performance. A visual breakdown of the tradeoffs compares protocol-backed and trusted ePBS builder payments across guarantees, costs, connection routes, operator limits, and Glamsterdam’s expected timeline, underscoring how much the final choice depends on context. The distinction between a possible advantage and a measured premium also shapes Mike Neuder’s August analysis. Neuder 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. That cautious read suggests the market may not shift dramatically overnight — but it also doesn’t rule out a slow transition toward trust-based relationships. For validators, the practical takeaway is that payment choices carry tradeoffs: protocol-backed payments offer stronger guarantees but come with hidden costs, while trusted payments may be cheaper in the short term but rely on human or relational accountability.

Trust, Relays, and the Case for Open Bidding

Much of the conversation has focused on how payment types should map to connectivity. 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, he stressed, 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. Relays, he argued, 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 Mike 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. But his argument leaves room for competition outside configured relationships, even if those relationships remain popular. This is a subtle but important point: the market does not have to choose between open access and curated relationships. Both can coexist, and the right balance may vary by operator, by builder, and by the level of trust already established in the network. Relays have long played a complicated role in Ethereum’s middleware stack, but they continue to matter because they solve a real coordination problem.

Valuing Offers and Keeping Operators Honest

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. This is where the philosophical debate meets real-world operational risk. 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. That is a significant concern for Ethereum, where client diversity is considered essential to network resilience. 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, but they highlight a broader reality: even the most elegant protocol design depends on how operators configure their nodes, how clients implement the rules, and how the network handles edge cases. Logging, for example, might sound like a simple accounting exercise, but it raises questions about what counts as a valid observation, how to handle missed messages, and what to do when different nodes see different versions of the auction.

What Comes Next for Ethereum’s Block Market

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. For now, the most telling signal from Ethereum’s research community is that neither side is declaring victory. The outcome will be settled less by ideology than by the messy, measurable realities of block production — the cost of capital, the reliability of counterparties, and the operational choices made by validators across the network. The timeline remains fluid. Even if Glamsterdam arrives on mainnet in the fourth quarter of 2026, the surrounding market structure could evolve in ways researchers haven’t fully anticipated. This is not just a Lido matter; it affects any protocol or service with a stake in proposer-builder separation. Whether ePBS ultimately ushers in a new era of trust-minimized block building or simply formalizes the relationships that already exist, the decisions being made in these discussions will shape the economics of Ethereum for years to come. If anything, the debate itself is a sign of the ecosystem’s maturation: rather than accepting a single default path, validators, builders and protocol researchers are wrestling with the tradeoffs in the open.