Ethereum fixes Glamsterdam bug that could have redirected staking deposits to builders

Ethereum developers have fixed a flaw in the upcoming Glamsterdam upgrade that could have sent ETH intended for new validators to block builders instead. The change was merged into Ethereum’s consensus specifications on October 26, following an initial rejection and further testing.

The issue involved how Ethereum would process deposits waiting to be credited during the upgrade. Under a specific scenario, a builder could receive ETH deposited by a staking service to create a validator, potentially leaving the service unable to recover its funds through its usual verification process.

The researcher who identified the issue stressed that the findings were conditional and did not confirm a live exploit. No losses have been reported.

The fix comes as Ethereum continues testing Glamsterdam, a major upgrade intended to improve Layer 1 scaling and change how block builders and validators coordinate. Its next Hoodi testnet activation has been postponed, and developers have not announced a replacement date.

How the Glamsterdam bug could have put ETH at risk

Glamsterdam introduces enshrined proposer-builder separation, which gives block builders a more formal role within Ethereum’s protocol. Builders assemble transactions into execution blocks, while validators help secure the network and participate in proposing and confirming blocks.

The two roles can have separate deposits, and the protocol must track those funds according to their intended withdrawal credentials.

The flaw emerged in the rules for processing deposits that remained pending when the upgrade took place.

According to the issue filed in Ethereum’s consensus-specifications repository, a builder could register using a particular public key before a staking service deposited ETH to create a validator associated with the same key.

Under the earlier draft rules, the builder’s registration could cause the subsequent validator deposit to be credited to the builder as well, regardless of the deposit’s withdrawal credentials.

That could create a serious problem for the staking service. If the validator was never created, the service might not be able to produce the proof required by its normal recovery process. Meanwhile, the builder could potentially withdraw the misallocated funds.

The researcher, known as avsetsin, examined possible effects on Lido, Origin and Rocket Pool. However, the researcher cautioned that the analysis was preliminary and that the consequences depended on each protocol’s deposit-handling logic.

The findings did not establish that every named protocol was vulnerable or that an attack had occurred.

Developers reversed their decision after further review

The fix did not receive immediate approval.

Developers initially closed the proposed change on October 19, with Ethereum consensus-specification maintainer Justin Traglia citing insufficient support from client teams at that time.

The proposal was subsequently reopened as developers reviewed the issue again. Additional tests were added on October 23, giving reviewers more evidence to assess the change and its potential effects on client implementations.

Traglia merged the fix on October 26 in pull request #5736, titled “Separate builder and validator deposits at the Gloas fork.”

The revised rules determine how pending deposits are handled using their withdrawal credentials, rather than allowing a builder’s registration under a shared public key to redirect validator deposits.

This means a deposit intended for a validator remains in the validator queue even when a builder uses the same public key. Only deposits with the appropriate builder withdrawal credentials can fund builders during the fork’s onboarding process.

The distinction matters because a public key identifies an entity in the protocol, but it does not by itself establish who should ultimately receive the funds.

Glamsterdam’s Hoodi test has also been postponed

The deposit fix arrives during a delay in Glamsterdam’s testnet rollout.

The Ethereum Foundation announced on October 22 that Glamsterdam’s planned October 26 activation on the Hoodi testnet had been postponed. Developers said they needed more time to investigate how EIP-8037, which changes gas costs associated with creating blockchain state, interacts with existing mainnet smart contracts.

The deposit-handling flaw was a separate issue. However, the postponed schedule gave developers additional time to review the proposed deposit fix before the next testnet activation.

Glamsterdam activated on the Sepolia testnet on October 6. Hoodi was due to be the next public test network, but the Ethereum Foundation has not set a new activation date. The mainnet launch date also remains unconfirmed.

Related: For more background, read Altcoin Buzz’s coverage of the Glamsterdam Hoodi testnet delay and smart contract gas risks.

Why the fix matters for Ethereum staking

The incident highlights how protocol upgrades can introduce risks even when they are designed to improve network performance and efficiency.

Ethereum’s staking system depends on deposits being assigned to the correct validators and on withdrawal credentials directing funds to their intended destinations. An error in that process could affect staking services’ accounting, validator onboarding and recovery procedures.

That makes the issue relevant as Ethereum continues to attract substantial staking participation. Altcoin Buzz recently reported that Ethereum’s staking queue held about 1.5 million ETH in early October, illustrating the scale of demand to enter the network’s validator system.

The Glamsterdam fix also demonstrates why upgrades need repeated testing across protocol specifications and client implementations. A change can be correct in the written rules but still require careful review to ensure different clients interpret and implement it consistently.

The immediate issue has been addressed in the consensus specifications, but implementation remains important. Client teams must incorporate the revised rules into their software and test them before the upgrade can proceed.

What happens next?

The merged change closes the identified deposit-routing scenario in the specification, but it does not mean Glamsterdam is ready for mainnet deployment.

Developers still need to continue testing the upgrade, coordinate client implementations and establish a new Hoodi activation schedule. The Ethereum Foundation’s latest Hoodi announcement confirms that the October 26 activation was postponed and that no replacement date has been set.

For ETH holders and existing mainnet stakers, the reported issue does not indicate that funds on the live Ethereum network were exposed to this specific flaw. It concerned the rules planned for an upcoming upgrade, and no losses have been reported.

The key milestone to watch is the next Hoodi testnet date, followed by evidence that client teams have implemented and tested the corrected deposit-handling rules.

Until those steps are completed, Glamsterdam’s mainnet timeline remains uncertain.