Who Actually Builds Your Ethereum Block: ePBS and the End of the Relay

When your transaction lands in an Ethereum block, the validator whose turn it was to propose that block almost certainly did not build it. Around 91% of Ethereum blocks arrive through MEV-Boost, software that sits outside the protocol and connects validators to a small industry of professional block builders.

That industry is concentrated. As of April 2026:

Other measurements through mid-2026 put the top two at about 73% and the top four above 95%. The exact ranking moves; the concentration does not.

None of this appears in the Ethereum protocol. The builders are not registered anywhere on chain, the relays that connect them to validators are unpaid volunteer infrastructure, and the consensus rules have no idea any of it is happening.

EIP-7732, shipping in the Glamsterdam upgrade, writes it in.

The supply chain you are actually using

Ethereum runs in twelve-second slots. For each slot the protocol picks one validator at random to be that slot's proposer, the single participant responsible for producing the block. Every other validator on duty that slot acts as an attester, voting on whether the block is valid. Proposer is a role a validator holds for one slot, not a separate kind of participant, and it is the role that gets paid for the block.

Send a swap on Ethereum and it travels roughly like this:

1. Your transaction goes to the public mempool, or into a private order flow channel that keeps it hidden from the mempool.
2. Builders collect transactions, order them for maximum value, and assemble a complete execution payload. This is where the extraction happens, including the sandwich pattern we took apart in our piece on sandwich attacks.
3. Builders submit their payloads to relays, along with a bid: how much they will pay the slot's proposer for the right to have their block proposed.
4. The relay shows the proposer only a header and a bid amount, not the block contents.
5. The proposer signs the header with the highest bid, and only then does the relay release the full payload to the network.

Why there is a middleman

The builder and the proposer cannot trust each other, and the failure is symmetric.

If the builder hands over the full block first, the proposer can read it, see exactly where the profit is, discard the builder's block, and construct their own capturing that value. The builder has handed a competitor their work for free.

If the proposer commits to a block before seeing it, the builder can deliver something invalid, or nothing at all. The proposer loses the slot and the reward with it.

Neither side can safely go first. So MEV-Boost inserts a party both are willing to trust: the relay holds the payload, checks that it is valid, shows the proposer a header and a price, collects the proposer's signature, and only then releases the block. The relay is escrow.

It works, but it has three problems.

It is trusted infrastructure inside a system built to avoid trusted infrastructure. A relay that misbehaves can, in principle, hand a proposer a header for a block that is never released.

It is unpaid. Relays are public goods run at cost by a handful of organisations. Ethereum's block market depends on volunteers.

It censors, in practice. Several relays filter transactions involving OFAC-sanctioned addresses. A validator connected only to those relays produces a censoring block every time its turn to propose comes up, without ever making that choice and often without knowing.

What ePBS actually does

EIP-7732 removes the escrow problem by making the payment unconditional and enforcing it in consensus.

The block structure changes. The BeaconBlockBody loses three fields: execution_payload, blob_kzg_commitments, and execution_requests. In their place go two new ones: a signed_execution_payload_bid and a set of payload_attestations.

The builder commits before revealing. A builder signs an ExecutionPayloadBid containing the parent block references, the committed block_hash of the payload it intends to publish, prev_randao, the fee recipient, its own builder index, the slot, the value it will pay the proposer, and the blob KZG commitments. It does not contain the payload. The builder is promising a specific block without showing it.

The payment happens immediately, in protocol. When the beacon block containing that bid is validated, the committed value is deducted from the builder's staked balance right then. Builders under ePBS are staked entities with their own beacon chain registry, which is what makes this enforceable.

Then the builder reveals. It broadcasts a SignedExecutionPayloadEnvelope containing the actual payload, which must match the committed blockhash.

Now consider what happens if the builder never reveals. The proposer keeps the money anyway. The slot is marked "Empty": a beacon block exists with no execution payload attached. The builder has paid for nothing and taken a pure loss.

That single property is what deletes the relay. The proposer no longer needs anyone to hold the payload in escrow, because the proposer is paid whether or not the payload ever arrives. There is nothing left for a trusted third party to guarantee.

The Payload Timeliness Committee

Removing the relay creates a new question: who confirms the payload actually showed up on time?

ePBS assigns 512 validators per slot to a Payload Timeliness Committee. They broadcast PayloadAttestationMessage objects attesting to two things: whether the builder revealed the committed payload promptly with the correct blockhash, and whether the blob data was available from their vantage point.

Note what they do not do: the PTC does not validate the full execution payload. It attests to delivery, not correctness. Those votes then adjust block weight in the fork choice rule.

The timing change nobody leads with

There is a second effect that matters as much as the relay removal.

Today a validator must complete both consensus validation and execution validation inside roughly four seconds before attesting. That is a hard deadline on a lot of work, and it is why large blocks and heavy blob loads create reorg risk.

ePBS decouples them. In the critical pre-attestation window, validators perform only the consensus state transition. Execution validation and data availability checks are deferred to the next slot. The proposer of slot N+1 gets six seconds to validate slot N's payload, and other validators get nine.

The propagation window widens from roughly two seconds to about nine. That is the change that makes the path toward much higher gas limits plausible, and it is why Glamsterdam also carries EIP-7928 (Block-Level Access Lists), which maps transaction dependencies up front so unrelated transactions can be validated in parallel.

What ePBS does not fix

This is the part worth being direct about, because most coverage is not.

ePBS does not reduce MEV. It does not decentralize block building. It does not stop your transaction being sandwiched.

Several summaries circulating ahead of the fork state that ePBS will cut MEV extraction by up to 70 percent. That figure appears in neither EIP-7732 nor the academic survey of the design, and nothing in the specification targets extraction volume at all. It should be treated as unsourced until someone produces the derivation.

What it fixes is the proposer's position: validators no longer need a trusted intermediary, and they cannot be cheated out of payment. The academic survey of ePBS puts it plainly: the design "transfers rather than eliminates" MEV concerns, moving extraction power from proposers to builders rather than removing it.

After Glamsterdam, builders still order transactions for maximum value, still hold exclusive private order flow, still enjoy an information advantage over everyone else, and are still three firms producing most blocks. Nothing in EIP-7732 addresses builder cartels, and nothing prevents a builder from simply declining to build when a block is unprofitable.

The relay disappears. The oligopoly it served does not.

The attack surfaces the EIP names itself

The specification is unusually candid about its own weaknesses, and they are worth reading before treating this as settled.

The 20% reorg. A colluding set of proposers and attesters controlling consecutive blocks and more than 20% of total stake can reorganise a builder's payload out of the chain and force the builder to pay the bid value regardless. The builder pays and receives nothing.

PTC equivocation. A single malicious committee member, working with a builder that can partition the network, can produce conflicting views of whether a payload arrived. The specification deliberately declines to add slashing for payload equivocation, choosing implementation simplicity instead. A proposed mitigation requiring two-thirds PTC agreement would force an attacker to control 33% of the committee, and the spec estimates a 35% staker would need on the order of 205,000 years to control a PTC majority by chance.

The free option. A builder that commits to a bid and then finds the block unprofitable can rationally withhold the payload, accept the loss of the bid, and leave the slot empty. The EIP acknowledges this directly.

None of these are fatal. All of them are new surface that did not exist when a relay was doing the work, and the honest framing is that ePBS trades a trusted-party risk for a set of cryptoeconomic risks that are cheaper but not zero.

Where it stands

Glamsterdam has cleared its final devnet stage and the EIP bundle is locked. The testnet schedule has moved, and the version that circulated widely in July was never real. A schedule of "Sepolia August 3, Hoodi August 17, mainnet around September 16" was repeated across secondary coverage and does not trace to any Ethereum Foundation, ethereum/pm or eth-clients source. As of August 6, the Sepolia network configuration contains no Glamsterdam fork epoch at all; its latest configured fork is still Fulu. The current plan runs a short-lived dedicated testnet first, then Sepolia and Hoodi in September 2026, with mainnet in Q4. Ethereum's own roadmap page still describes the contents as proposals under consideration rather than final, which is the appropriate amount of caution.

Slippage into Q4 or later is a real possibility, and the named reasons are specific: ePBS implementation complexity, achieving parity across client teams, and the gas repricing work that accompanies the move toward a 200 million gas limit.

Securing the unseen

The useful thing to take from this is not a date. It is that the path your transaction takes involves more parties than the protocol describes, and until now several of them were held together by goodwill.

Ask three questions about any chain you transact on. Who assembles the block your transaction lands in, and are they the same party the protocol pays? What stops that assembler from taking your ordering value, and is it a rule or a convention? If there is an intermediary holding things together, who pays them, and what happens the day they stop?

Ethereum has spent four years answering the third question with "some volunteers, and we would rather not find out." ePBS is the attempt to make the answer structural. It resolves the trust between proposer and builder and leaves the harder question, which is that a handful of firms decide what goes in almost every block, entirely open.

Learn more at 0xhades.io/research