Ethereum developers have merged a fix for a deposit-handling flaw in the upcoming Glamsterdam upgrade that could have allowed a block builder to receive ETH intended for a new validator, following an initial decision to reject the proposed change.
Summary
- Ethereum merged a Glamsterdam deposit-handling fix on October 26.
- The flaw could have credited staking deposits to builders sharing the same public key.
- Developers initially rejected the correction before approving additional tests.
- A separate contract-compatibility investigation has delayed Glamsterdam’s Hoodi activation.
According to Ethereum’s consensus specifications, maintainer Justin Traglia merged the correction on October 26 after developer avsetsin identified a problem with how pending deposits would be processed during the Gloas fork. The change separates builder deposits from validator deposits according to their withdrawal credentials, preventing funds from entering the wrong account when both use the same public key.
The vulnerability concerned rules under development, not a confirmed theft from Ethereum’s mainnet. Developers have incorporated the correction into the specifications, although individual consensus clients still need to implement and test the revised behavior.
Ethereum Glamsterdam flaw exposed validator deposit risk
The issue emerged from changes planned under Glamsterdam’s enshrined proposer-builder separation, which assigns block construction and block proposal to different roles. Builders assemble transaction payloads, while validators participate in proposing and confirming blocks through Ethereum’s proof-of-stake system.
Researcher avsetsin described the flaw on October 12, identifying a problem in the rules used to process deposits waiting when the network upgrades. If a builder registered using a public key before a validator deposit arrived under the same key, the proposed logic could credit both deposits to the builder.
The researcher outlined a scenario involving a staking operator receiving funds from a liquid staking protocol to establish a new validator. By registering as a builder first, the operator could cause the protocol’s validator deposit to enter the builder balance, where the withdrawal address could be under the operator’s control.
“The operator can withdraw the protocol’s funds,” avsetsin warned in the GitHub report.
Since the expected validator would not be created, the staking service could struggle to obtain the proof needed to complete its normal deposit and recovery procedures.
The researcher examined potential exposure involving Lido, Origin and Rocket Pool through preliminary code research. Those findings were conditional on how individual protocols handled deposits, and the report did not establish that the projects had suffered an exploit.
Developers reverse decision after further review
The proposed correction initially encountered resistance from Ethereum client developers, despite the researcher’s description of the deposit-routing risk. On October 19, Traglia closed the pull request after discussions among core developers.
“There was not enough support from clients to make this change at this time,” Traglia wrote.
The decision did not remain in place, with developers reopening the proposal on October 23 following further examination.
Subsequently, reviewer potuz approved the approach but requested more tests for specific deposit combinations. Avsetsin added those tests on October 23, covering cases in which builder and validator deposits share a public key but require separate handling.
The final change was merged into Ethereum’s consensus specifications on October 26 after further client review. It directs valid validator deposits into the validator queue while allowing legitimate builder deposits to register or add funds to an existing builder.
The new rules distinguish deposits through withdrawal credentials, which determine the permitted withdrawal arrangements. They preserve separate builder and validator records even where the same public key appears in both roles.
Hoodi delay gives developers more time to investigate
The specification update arrived while Ethereum developers were reviewing a separate problem affecting Glamsterdam’s scheduled activation on the Hoodi testnet. The Ethereum Foundation postponed the October 26 upgrade after researchers identified compatibility risks involving EIP-8037.
As crypto.news previously reported on the postponement, the decision removed both the Amsterdam execution changes and Gloas consensus changes from Hoodi’s planned activation. The proposed increase to a 200 million gas limit was postponed with them.
Ethereum researcher Toni Wahrstätter explained that EIP-8037 could interfere with smart contracts relying on assumptions about gas remaining during execution. He identified cases where gas accounting could cause a transaction to revert unexpectedly or allow an execution path that developers had assumed was unreachable.
The contract-compatibility problem is distinct from the builder-deposit flaw addressed in the GitHub correction. Both concern Glamsterdam, but the Foundation’s October 22 postponement specifically cited further investigation of EIP-8037’s interaction with existing contracts.
Ethereum clients must implement the revised rules
Glamsterdam already activated on the Sepolia testnet on October 6, where developers examined block construction changes and higher transaction-processing capacity. The subsequent Hoodi rehearsal remains unscheduled, with no confirmed date for activation on Ethereum mainnet.
The merged deposit correction contains regression tests covering how deposits are classified during the Gloas transition. Client teams must incorporate the specification change into their software and complete further testing before the updated rules can operate during a future network upgrade.
