Ethereum Warns Glamsterdam Testnet Vulnerable to Builder Abuse

ETH
builder abuseGlamsterdamEthereumEIP-7732SepoliatestnetePBS
2 hours agoSource: crypto.news
Ethereum Warns Glamsterdam Testnet Vulnerable to Builder Abuse

Ethereum developers have confirmed an Oct. 6 Glamsterdam activation on Sepolia while warning that cheap test ether could let malicious builders repeatedly win block auctions and withhold their transaction payloads during the public test phase.

Summary

  • Ethereum developers confirmed Glamsterdam will activate on Sepolia October 6 before a later Hoodi test.
  • Developers warned free test ether could let disposable builders win bids and withhold execution payloads.
  • Client teams were urged to release Sepolia-ready software by September 29, leaving seven review days.
  • Devnet-11 completed its Gloas transition and raised gas limits from 60 million to 200 million.
  • Ethereum has not scheduled Glamsterdam mainnet activation, with its roadmap still targeting fourth quarter 2026.

Ethereum’s Sept. 17 All Core Developers Consensus transcript shows participants accepted the Oct. 6 date after reviewing recent Glamsterdam devnet results, though developers simultaneously raised concerns about how Enshrined Proposer-Builder Separation could behave on a public network where test ETH carries no meaningful economic cost.

Ethereum Glamsterdam test could face cheap builder attacks

At the center of the warning is EIP-7732, Glamsterdam’s Enshrined Proposer-Builder Separation design. Ethereum.org describes ePBS as a protocol change that separates the job of assembling transaction payloads from the validator’s consensus duties, moving a relationship that currently relies heavily on external infrastructure into Ethereum’s consensus rules.

Under the design, builders can submit bids for the right to supply an execution payload. Once a proposer commits to the winning bid, the builder is expected to release the transactions behind it. Ethereum’s consensus specification defines builders as separate staked actors that submit signed execution-payload bids before broadcasting the corresponding payload envelope.

During Thursday’s developer call, consensus developer Potuz warned that the economics change on a testnet because attackers can obtain test ETH without paying its mainnet market value. A malicious operator could create many builder identities, submit bids far above legitimate competitors and then refuse to provide the promised payload after winning.

“I can just spin up a thousand builders,” Potuz said, explaining that the attacker could rotate them, bid aggressively and withhold payloads. He later added, “Any teenager can do this.”

The developer framed the concern as a public-testnet availability problem, not a new route to steal mainnet ETH. On mainnet, a participant can already pay to produce an empty block, but the economic cost of obtaining block space limits the behavior. Test ETH makes persistent disruption much cheaper.

Clients may need builder-level circuit breakers

Existing safeguards may not be sufficient for the Sepolia environment. Potuz told developers that some client circuit breakers fall back to locally built blocks only after several payloads are missed, while he was not aware of universal protections that could reject individual abusive builders.

His concern centered on attackers returning under fresh identities. Even if a client reacts to missing payloads, disposable builders could continue bidding unless the defensive logic identifies and restricts the behavior quickly enough.

Developers did not present the builder attack as a confirmed exploit against Sepolia. The discussion concerned a scenario they expect public testing could expose once outsiders can participate under ePBS conditions. Potuz argued that Ethereum’s testnets need stronger safeguards because application and infrastructure teams rely on them to test software against functioning blocks.

Ethereum.org notes that Sepolia uses a permissioned validator set controlled by client and testing teams, while Hoodi has an open validator set intended for staking and protocol testing. Sepolia’s structure gives Ethereum developers more operational control if the first long-lived public Glamsterdam deployment encounters problems.

As previously reported by crypto.news, developers had tentatively selected Oct. 6 before the latest call, with the date still dependent on another stable private-devnet transition. The Sept. 17 consensus call moved that timetable forward after Devnet-11 completed its scheduled fork rehearsal.

Devnet-11 tested 200 million gas before Sepolia

Glamsterdam Devnet-11 was created as a controlled “happy-path” rehearsal rather than an adversarial attack network. Its official specification scheduled genesis for Sept. 14, the Gloas transition for Sept. 16 and a block gas-limit increase from 60 million to 200 million shortly afterward.

The test network used 84,000 validators across a multi-client configuration and carried the same core EIP set planned for Glamsterdam testing. Its organizers explicitly excluded deliberate attacks from the Devnet-11 scope, keeping adversarial experiments on the longer-running Platåberget environment.

CoinDesk reported that Devnet-11 completed the transition and moved the gas limit toward 200 million without losing finality. The 200 million setting is a test parameter, not a confirmed mainnet gas-limit commitment.

Ethereum’s own Glamsterdam roadmap says the upgrade is designed to increase Layer 1 capacity while changing how blocks are built and verified. EIP-7732 extends the execution-payload propagation window from roughly two seconds to around nine seconds, giving nodes more time to distribute and validate larger payloads.

The upgrade includes Block-Level Access Lists and a series of gas-pricing changes as well. Earlier Glamsterdam compatibility coverage reported that wallets, indexers and gas estimators using fixed assumptions can require changes because new-account creation and some state-heavy operations receive different gas treatment under the planned fork.

A separate smart-contract risk review found that contracts using fixed gas stipends or gas-sensitive execution patterns may require testing before the upgrade reaches mainnet.

Sepolia client review window falls to seven days

The Oct. 6 schedule gives client teams less review time than Ethereum’s normal upgrade process recommends.

During the Sept. 17 call, developer Fredrik Svantes told participants that the standard process calls for at least 14 days between release-ready client software and the first public testnet activation. He said those two weeks are normally used for internal security reviews, bug-bounty exposure and possible external security work.

With Sepolia approaching, developers discussed a Sept. 29 latest date for client releases. Seven days between Sept. 29 and Oct. 6 would leave half of the normal review period. Participants accepted that risk for Sepolia partly because its validator set is relatively centralized and the network can be recovered more easily if software breaks.

Core developer Alex Stokes urged teams to release software earlier where possible so more reviewers could examine it. Once release-ready clients are available, they can enter Ethereum’s bug-bounty process immediately.

The compressed schedule follows several earlier testing problems. A Sept. 3 developer agenda recorded non-finality during the Devnet-8 Gloas activation affecting multiple consensus clients, while later Devnet testing examined fixes and additional edge cases.

Another testing call recorded problems in which a Platåberget scenario knocked 12 of 13 Besu nodes offline and slowed Erigon and Ethrex nodes. Devnet-9 experienced unplanned non-finality, pushing teams into further iterations before Devnet-11.

Mainnet activation still has no confirmed date

Ethereum’s public roadmap continues to list Glamsterdam for the fourth quarter of 2026 but states that the mainnet date has not been confirmed. The next published milestone is the Oct. 6 Sepolia fork.

Hoodi is expected to follow Sepolia because it provides an open validator environment for staking and upgrade testing. Developers discussed the Hoodi stage during the Sept. 17 call but tied its timing to Sepolia’s progress, meaning problems on the first public testnet could move subsequent dates.

Ethereum’s draft mainnet incident-response plan still contains no activation epoch or timestamp. The document instead leaves the upgrade information fields blank while listing the client and coordination roles that will be filled before mainnet deployment.

As earlier crypto.news Glamsterdam coverage reported, the upgrade centers on ePBS, Block-Level Access Lists and gas repricing designed for higher Layer 1 throughput. Developers have continued treating successful multi-client testing as a prerequisite before setting the mainnet fork.

For now, client teams face the Sept. 29 software deadline discussed on the call, followed by Sepolia’s Oct. 6 activation. Ethereum developers have not published a mainnet epoch or final activation timestamp.