Ethereal

A validator seeking an external execution payload can retain a local construction path; after signing a blinded block, it cannot safely substitute a differently signed block for that slot. Pinned specifications and controlled MEV-Boost tests make this change in operational dependence inspectable. The upstream fanout test confirms delivery of the signed request to two configured relays. Additional experiments in the V1 payload-return and V2 submission paths observe cancellation of a slower HTTP request after a successful response returns. Neither experiment establishes production broadcast behavior or operator independence. Current EIP-7732 and Gloas sources supply a prospective comparison in which payment and payload-availability responsibilities move into consensus rules. Following the proposer through information, alternatives and commitment identifies which component must act at each stage, without supplying a network-wide concentration index or a finding that infrastructure concentration caused a governance outcome.

A proposer’s alternatives change during block construction. Before signing, it can choose between a suitable external bid and a local block; afterward, a competing signature creates slashing exposure. Validator and relay counts describe distributions of resources, while this sequence identifies when a particular action becomes constrained.

External proposer-builder separation supplies a tractable case. The proposer obtains a bid and an execution payload header before receiving the full payload. It signs a blinded beacon block and submits that signed commitment through builder middleware. The full payload arrives later. Local construction, relay redundancy and protocol validation each address different parts of this sequence.

The examined payload-return sequence uses the Deneb GetPayloadV1 route. A separate experiment tests the request lifecycle in GetPayloadV2, which submits the signed blinded block without returning payloads and blobs. Their response contracts differ, and neither experiment follows a production relay’s subsequent broadcast. The sequence below is not an account of every supported API path.

At each stage, the question is what the proposer can know and change, and which component must act for the selected path to complete. Specification text and controlled software behavior identify the available paths. Whether an operator routinely uses them requires observation of its configuration and conduct.

Decentralization research already reaches beyond consensus counts. Ovezik, Karakostas and Kiayias’s stratified account includes hardware, software, network, consensus, tokenomics, client APIs, governance and geography (2024). Ovezik, Karakostas, Milad, Kiayias and Woods systematize the measurement workflow and show how extraction choices, estimation windows and resource definitions affect resulting measures (2025). These accounts already treat decentralization as a problem spanning protocol and surrounding infrastructure.

The narrower problem here concerns the relation between measurement and an action’s sequence. Relay delivery, builder identity and a proposer’s local alternative are different objects. A resource share can describe a distribution while leaving unresolved when a participant has committed, which information it possesses at that point and whether changing route would change the signed object. A stage table can clarify those questions without replacing concentration measures.

Heimbach, Kiffer, Ferreira Torres and Wattenhofer’s study of Ethereum PBS supplies the relevant economic and architectural context (2023). Outsourced construction organizes a market among builders, relays and proposers. The existence of several configured relays does not establish independent builders, independent ownership or equally competitive bids. Equally, a concentrated builder market would not by itself establish that a proposer lacks a technically available local construction route. These propositions require different evidence.

The software reconstruction and experiments examine the proposer’s available paths and their request lifecycles. They do not estimate market power, causal effects on censorship, the prevalence of any software configuration, or the costs operators face when changing providers.

The captured builder specification describes external building alongside local building. It requires an honest proposer using the external route to construct a local block in parallel and to abort the external route if no suitable bid arrives in time. A separate circuit breaker can select local construction when the beacon node considers the chain unhealthy. The conditions for that circuit breaker are implementation-dependent (Ethereum Builder Specifications n.d.).

The specification also identifies a boundary to this fallback. Once the proposer has signed a blinded block, publishing a signature for a distinct block in the same proposal slot can supply competing headers for proposer slashing. The local fallback is therefore a pre-signature alternative. A failure after signing does not make signing a different local block safe.

The table follows the specified full-payload-return route exercised through GetPayloadV1.

A validator can change future relay configuration or its future use of external construction. Those choices do not recover an already signed slot, and the constraint in that slot does not establish a general inability to operate independently.

The captured current Bellatrix builder document is byte-identical to the historical revision retained in the earlier study. Its rule remains documentary evidence at those pins. It is not a trace showing how a particular production validator configured local building or responded to a failure.

The experiments use MEV-Boost v1.12, released on February 23, 2026, at commit c48dbe4dfe97d74a724e701ee69d55c93dbb318e. This identifies the source under test, without asserting that production operators have installed it (Flashbots 2026).

At this revision, innerGetPayload constructs its relay list from all configured relay entries, rather than restricting submission to the relay associated with the selected bid. It launches requests concurrently, checks responses and returns the first successful result. This is a materially different path from dependence on one selected relay alone.

For the tested GetPayloadV1 path, a valid response means one accepted by MEV-Boost’s response-decoding and request/payload-matching checks. The experiment does not independently establish EVM execution validity or consensus validity. The released GetPayloadV2 path has a different response contract; its successful submission does not return payloads and blobs, and the source’s payload decoding and verifyPayload call apply to V1.

The upstream TestGetPayloadToAllRelays provides an executable check of V1. It configures two mock relays and a signed Deneb fixture, supplies a valid payload response and asserts both relay request counts and a successful response. The test was executed once in isolation and then three times alongside the added lifecycle test. All four executions passed. The result supports fanout in this controlled configuration. It does not show that every relay in production receives every request, that all configured endpoints are independent, or that relays have distinct payload suppliers.

Fanout must also be separated from completion. A source comment says the other requests will continue in the background to provide broadcast redundancy. The surrounding code creates a shared timeout context, defers its cancellation, and returns when the result channel supplies the first successful response. The deferred cancellation makes the request lifecycle an empirical question that the comment alone cannot answer.

An additional controlled test uses the unmodified implementation and the upstream signed fixture. Its slow mock relay first reads the signed request and signals receipt. The fast mock relay waits for that signal before returning a valid payload. After the caller receives HTTP 200, the test observes the slower request’s context being canceled. It also requires both relay request counts to equal one. The test passed on all three repetitions.

The signed object reached both mock relays, and a successful return canceled the still-active slower request. Fanout and the source comment therefore do not establish that slower HTTP requests remain active until completion.

A follow-up experiment examines V2 directly. Its slower mock relay consumes the signed object before the faster relay may return HTTP 202. After the caller receives that empty successful response, the slower request’s context is canceled. Three repetitions passed alongside the upstream V2 tests and fanout control. An upstream test titled “requests to all relays continue in background” checks request counts and an early response; the additional observation distinguishes those properties from continued HTTP-request activity. Both paths use the released implementation’s shared request context and deferred cancellation (Flashbots 2026).

Cancellation does not retract an already delivered signed object. A real relay may continue processing or broadcasting after its HTTP client disconnects. The test contains no production relay, gossip network, beacon-node publication or observed block inclusion. It establishes neither failed broadcast redundancy nor a vulnerability. Its value is to distinguish request initiation, request completion and downstream action, which require separate observations.

At the captured EIPs revision, EIP-7732 is in Last Call with a November 1, 2026 deadline. The captured consensus repository lists Fulu as stable and Gloas as unstable with activation fields marked TBD. Ethereum’s Glamsterdam roadmap gives an expected quarter and an unconfirmed date. These records document proposal and planning state; this collection does not establish mainnet activation (D’Amato et al. 2024; Ethereum Consensus Specifications n.d.; Ethereum Foundation n.d.).

EIP-7732 proposes an in-protocol builder role, a signed execution payload bid and later payload revelation. For its consensus-layer payment route, the committed value is deducted from the builder’s balance and processed through the specified withdrawal machinery. The source also accommodates trusted execution-payment promises. The latter should not inherit the guarantees claimed for the balance-backed route merely because both appear in one proposal.

The proposed Payload Timeliness Committee attests to timely payload revelation and the relevant data availability in its view. That duty is distinct from full execution validation. Moving an availability attestation into consensus therefore does not make it a completed EVM validation or collapse all stages into one event. The examined Gloas files specify the corresponding builder and validator responsibilities at their own immutable revision; they are not presented as byte-identical to the separate revision linked inside the EIP.

The comparison is institutional as well as technical. In the external route, a service receives the signed blinded block and supplies the corresponding payload. Under the proposed balance-backed route, consensus state carries a builder commitment and payment obligation, while designated validators supply availability evidence and later processing addresses execution. The allocation of responsibilities changes. One cannot conclude from that change alone that builder competition, transaction access, network connectivity or every dependence on surrounding services has been resolved.

Formalization can make an obligation enforceable through a different mechanism while preserving choices elsewhere. Assessment should name the obligation, its enforcement conditions and the conduct that remains discretionary. A general assertion that dependence has disappeared would obscure precisely what the proposed mechanism changes.

In an ePBS model, a builder that learns economically relevant information after commitment can benefit by withholding data needed for its payload to become canonical. Mazorra, Öz, Schlegel and Wu examine this free-option problem in their January 2026 study (2026), connecting the option’s value to volatility, the time window and exposure to external market signals.

This is an alternative mechanism to the simple claim that an operational dependency follows from having too few providers. A builder’s incentive can arise from the order of commitment and revelation, even before estimating how many organizations control builders. Competition and concentration may affect its consequences, but they do not replace the timing analysis.

The study combines a model with estimates on historical blocks under stated assumptions. Its hypothetical exercise rates are not observed current-mainnet withholding rates. Nor is a January model automatically a validation of every detail in the October EIP and consensus revisions. The captured EIP itself discusses profitable withholding and possible mitigations, so the concern is part of the proposal’s documented design space. Testing a particular mitigation would require fixing the relevant specification and economic assumptions together.

The external-route experiment and the ePBS model concern different options. The former observes a middleware request lifecycle after a proposer signature; the latter models a builder’s economic choice after its commitment. Keeping the actor, object and stage explicit allows comparison without treating these as the same failure or as evidence of one shared institutional outcome.

The analysis combines pinned builder and consensus specifications, release-source inspection and controlled mock-relay tests. Proposal status, paper version and software release identify different objects; none establishes which configuration a production validator used.

Each software experiment used the released source revision with one additional test file; implementation files match the release byte for byte. V1 and V2 experiments use different response contracts, with synchronized relay receipt, early success and cancellation observations. The repetitions reported above test those controlled request lifecycles.

The empirical scope comprises local mock-relay experiments. Operator configurations and behavior require separate observation. No configured production endpoint, current market-share population, builder ownership map, or end-to-end block trace is inferred. The stage table is a reconstruction of a specified route, not a measured census of all participant paths. Claims about whether operators possess an effective fallback require their actual client configurations and relevant failure behavior.

A useful next observation would join a signed-object identifier with client request and cancellation times, relay receipt and broadcast events, beacon-node responses and eventual inclusion. The collection would require authorization and a procedure that avoids conflicting signatures for the same slot. It could distinguish failure to receive, client cancellation after receipt, relay continuation and later propagation failure. Comparing independent failure domains would then require evidence about operators and upstream infrastructure, rather than an endpoint count.

The proposer retains a local alternative before signing and faces a different constraint afterward. MEV-Boost fanout supplies multiple request paths, while controlled experiments in both supported submission paths distinguish those requests from continued HTTP activity and leave downstream broadcast unobserved. Proposed ePBS reallocates specific payment and availability duties; its status and remaining choices require their own account.

Operational dependence changes with the information a participant holds, the commitment it has made and the action another component must take. Concentration measures can describe the resources available along that sequence. Establishing how the sequence operates in production requires joining client, relay and inclusion observations for the same signed object.