Glamsterdam removes the relay, not the builder

Every bundle path I have built for Ethereum was designed for a world with three parties in the block auction: a searcher who finds the opportunity, a builder who assembles the block, and a relay that sits between the builder and the validator so that neither has to trust the other. Glamsterdam, the upgrade now in public testnets with a 2026 target, moves the auction into the protocol and deletes the third party. The headlines say this fixes the trust problem in block building. For a searcher it moves the problem rather than removing it, and the honest accounting of what changes is narrower than the headlines and more useful.

Three eras of the auction

The block auction has had three shapes. From January 2021, Flashbots' MEV-Geth let searchers send bundles straight to miners running a patched client. From the Merge in September 2022, MEV-Boost let validators outsource block building to specialised builders through relays, which hold the builder's block, show the validator only a header and a bid, and release the body once the validator has signed. And with Glamsterdam, EIP-7732 makes builders staked entities inside the beacon chain and lets the proposer commit to a builder's bid without anyone in the middle. The upgrade after it, Hegotá, is scoped for 2027 with inclusion lists as its headliner, which is the part of the roadmap that addresses censorship rather than trust.

What the relay was for

It is worth being precise about the job the relay did, because that is the job the protocol is absorbing. Under MEV-Boost a builder cannot show a validator the block before the validator commits to it, since a validator who saw the block could copy its contents and propose them as its own. And a validator cannot commit to a block it has not seen unless someone it trusts vouches that the block is valid and that the payment inside it is real. The relay was that someone. It received the full block from the builder, checked it, showed the validator only a header and a bid, collected the validator's signature on the header, and then released the body to the network. Both sides trusted the relay: the builder trusted it not to leak the block, and the validator trusted it not to lie about the bid.

That arrangement worked, and it had two costs that were obvious from the start. The relay saw everything, every bundle in every block from every builder that used it, which made it the most valuable vantage point in the system and a party whose operators had to be trusted not to use it. And it was a handful of companies running ordinary servers, so a relay outage or a relay's policy decision, about which transactions it would carry, became a property of the chain that no protocol rule described. Enshrining the auction was the answer to both: let the protocol carry the commitment, and let the protocol pay the validator.

What EIP-7732 actually changes

The mechanism is worth stating precisely, because the security argument depends on the details. A builder registers on the beacon chain with a stake and a balance. In each slot the builder signs a bid that commits to an execution payload by its block hash and names a value it will pay the proposer. The proposer includes the winning bid in the beacon block, and at that moment the payment is deducted from the builder's balance, unconditionally: the EIP's stated guarantee is that an honest proposer is paid whatever the builder does next. The builder then reveals the payload later in the slot, and a committee of 512 validators, the payload timeliness committee, attests to whether the payload arrived in time, without validating its contents. If the payload does not arrive, the slot's beacon block stands and its execution payload is empty.

Three things follow. The relay is gone, because the protocol itself now does what the relay did: it lets the proposer commit to a block it has not seen, and it guarantees the builder is paid only if it reveals what it committed to, or rather, in this design, that the proposer is paid regardless. The builder is now a first-class protocol entity with a balance the protocol can debit. And the builder has a window, between commitment and reveal, in which it has already paid and has not yet shown its hand.

The see-and-drop ledger

The tool I use to think about any change to the block-production path is a two-column ledger. For each path, who can see my transaction before it is final, and who can drop it? A trust change that moves a name from one row to another matters; a headline that does not change either column does not.

Filled in, the ledger says what the upgrade does for a searcher. In the seeing column, the relay leaves. That is a real gain: a relay is a company that saw every builder's block, and its operators were a party a searcher had to trust not to look. The builder stays. Whoever assembles the block reads every bundle in it, and no protocol change short of encrypted mempools alters that. In the dropping column, the relay leaves too, and a new entry appears: the builder can now withhold the entire payload after committing to it, and the protocol will accept an empty slot. Under MEV-Boost a builder who wanted to abandon a block had to do it before the relay released it; now the builder holds the decision until the reveal deadline.

The free option

That last entry is the one the formal analysis is about. Mazorra, Öz, Schlegel and Wu's The Free Option Problem of ePBS describes the window between commitment and reveal as an option: the builder has paid the bid and can still choose, when the reveal deadline arrives, whether the committed payload becomes canonical. The bid is the option's price. If the market moves against the block's contents in those few seconds, the builder can let the slot go empty and lose only the bid, and the paper's evidence is that exercising the option becomes markedly more frequent in volatile periods, when the bundles inside the block are worth the most to the searchers who built them. The mitigations it proposes, a shorter window or an additional penalty for exercising, are design choices the protocol has not yet made.

For a searcher, the option is a new correlation to price in. A bundle that captures a large move is exactly the bundle most likely to be in a block the builder has an incentive to drop, because the same move that made the bundle valuable changed the builder's own position. Under MEV-Boost that risk existed but was cut short by the relay's release; under ePBS it runs to the deadline and is paid for by the bid alone.

What a bundle path should do about it

The practical changes are modest, which is the point. The builder is still the party to trust, so the work of choosing builders, spreading bundles across several, and measuring each one's inclusion rate against what it saw carries over unchanged. Two new measurements join that list: how often each builder's slots come up empty, and whether those empties cluster in volatile minutes. A builder whose empties correlate with the moves that made my bundles valuable is exercising the option against me, and the ledger says the protocol will let it. The unconditional payment protects the proposer, not the searcher.

Inclusion lists, when Hegotá ships them, change the dropping column again, by letting attesters force transactions into a block, and that will be worth a second ledger. Until then, the honest summary of Glamsterdam for anyone sending bundles is that the middleman is gone and the counterparty is not, and the counterparty has one more way to say no.