On the All Core Developers Consensus call of 17 September 2026, Ethereum client teams accepted 6 October as the activation date for the Glamsterdam upgrade on the Sepolia testnet. On the same call, they discussed a devnet result showing that the upgrade’s headline feature can be abused by an attacker with nothing to lose. Both things happened in the same meeting, and the fact that they did is the most informative detail available about how this upgrade is being reasoned about.
The pitch for enshrined proposer-builder separation — EIP-7732, ePBS — is that it ends the reliance on third-party middleware such as MEV-Boost by building the block-payload-for-payment exchange directly into consensus. That is true as far as it goes. What it does not do, and what the Sepolia result makes visible, is remove the reliance on a builder market. It relocates that reliance from patchable off-chain middleware into consensus code, where the fix path is a hard fork rather than a relay configuration change.
What is actually shipping, and when
Glamsterdam has two headliners.
EIP-7732 separates the proposer, which selects the consensus block, from the builder, which assembles the execution payload, and enshrines the handoff in protocol. Builders submit bids; the proposer selects a winner; the payload is revealed afterwards. A practical side effect is that the execution payload propagation window expands from roughly 2 seconds to about 9 seconds, giving nodes more time to distribute and verify larger payloads.
EIP-7928, Block-Level Access Lists, records all state accesses and post-execution values for a block up front. That is the unglamorous one, and probably the more consequential: knowing in advance which state a block touches is the precondition for parallel execution and parallel disk reads. It is infrastructure for throughput rather than a user-visible feature.
The calendar, as it stands:
- 29 September 2026 — client teams urged to finalise Sepolia-ready software, leaving roughly seven days for security review.
- 6 October 2026 — Glamsterdam activates on Sepolia. An earlier reported date of 28 September circulated and was superseded on the 17 September call; it is not current.
- Holesky — follows Sepolia, date not fixed.
- Mainnet — listed on the official Ethereum roadmap as expected in Q4 2026, with the page stating the date is not confirmed. Treat any specific mainnet date you see as speculation.
How the new handshake can be gamed
The abuse raised on the call runs in four steps, and none of them requires breaking any cryptography.
- Spin up a builder identity. In an open builder market this costs approximately nothing.
- Submit an oversized bid — large enough that a rational proposer selects it over honest bids.
- Win the slot, then withhold the promised execution payload. The proposer has committed to a payload that never arrives.
- When clients identify the misbehaving builder and reject it, return under a fresh identity and repeat.
The surface exists because bid and reveal are separated in time. That separation is the entire point of PBS — it is what lets a proposer commit to a block without seeing or building its contents — and it necessarily creates a window in which a winner has been chosen and the goods have not been delivered. Any design with that shape has to answer the question of what happens when the winner does not deliver.
Client-side rejection is the obvious answer, and on its own it is a weak one. Rejecting a builder only works if the builder cannot cheaply become a different builder. Identity disposability, not the bid mechanism, is the load-bearing variable here.
Why “it’s only testnet” is both true and the whole point
Developers were explicit on two counts, and both belong in any honest account of this. First, the severity observed on Sepolia is amplified specifically because test ETH has no meaningful monetary value. Second, the behaviour does not represent a direct threat to mainnet user funds. This is a testnet observation raised as a concern on a developer call. It is not a demonstrated mainnet exploit, and it is not a disclosed vulnerability with an advisory behind it.
Take that caveat seriously and it becomes the finding rather than a disclaimer. The reason the attack is cheap on Sepolia is that the attacker risks nothing: test ETH is free, so an oversized bid costs nothing to make and a burned identity costs nothing to replace. On mainnet, both of those costs are real. A builder needs capital to bid credibly, a failed or dishonest bid has a price, and established builders carry reputational standing with proposers that a fresh identity does not.
That is a genuine defence and it is also a conditional one. It holds while the builder market has real barriers to entry and real capital at stake. It says nothing about what happens if those conditions change — if bidding becomes cheap, or if an attacker with an unrelated motive is willing to absorb the cost. Sepolia is not a prediction about mainnet. It is a demonstration of what the mechanism does once the economic assumption is removed, which is a useful thing to have seen before the assumption is the only thing holding.
The trade nobody is naming
Here is what enshrinement actually buys and costs.
What it buys: trustless payment. Under MEV-Boost, a relay sits between proposer and builder as a trusted intermediary, and proposers have historically had to trust that relay to behave. ePBS removes that party. The payment and the commitment are enforced by consensus rather than by a third party’s good conduct. That is a real reduction in trust assumptions and it is why the change is worth making.
What it costs: the remediation cycle. When a relay misbehaves or a bug appears in middleware, the fix is a relay configuration change or a software update, deployable in hours by the parties affected. When the same class of problem appears in consensus code, the fix is a hard fork — coordinated across every client team, scheduled, tested on testnets, and activated at a block height. That is the difference between a patch measured in hours and one measured in months.
This is the honest frame for an upgrade being marketed as the end of MEV middleware. It is not the end of the builder market; it is the builder market with a slower fix path and fewer trusted intermediaries. Whether that trade is worth taking depends on how confident you are that the economics hold, which brings us back to why core developers accepted the October date on the same call where the concern was raised.
Their position is coherent and deserves stating at full strength: mainnet economics — costly stake, real bids, reputational builder identities — are precisely what make the Sepolia behaviour unrepresentative, and a testnet exists to surface exactly this kind of behaviour before mainnet. Testing it on Sepolia with free ETH is how you find out. The counter-position is not that they are wrong, but that an economic defence deserves to be named as one, because economic defences are contingent in a way cryptographic ones are not.
If you run a validator
The operational item is the 29 September software freeze, not the 6 October fork. Client teams are aiming to have Sepolia-ready releases out by then so there is a week of review before activation. If you operate on Sepolia, that is your upgrade window. If you operate on mainnet only, nothing is required of you yet, and anyone telling you a mainnet date is telling you something the roadmap explicitly does not say.

