Ethereum developers fix a validator deposit processing bug in the Glamsterdam upgrade
According to CoinDesk, Ethereum developers have fixed a bug in the upcoming Glamsterdam upgrade. The bug could have let operators take ETH that staking services intended for new validators. The fix changed the rules for handling validator deposits and was merged on Monday, after developers had rejected the change a week earlier.
Researcher avsetsin found that if an operator first registered as a builder with a specific public key and a staking service later used the same key to deposit ETH to start a validator, the draft rules would assign both deposits to the builder. avsetsin said this was a conditional code finding, not a confirmed live exploit, that existing checks could prevent the attack, and that there were no reports of losses. The new rules sort pending deposits by withdrawal credentials so that validator deposits still belong to validators. Glamsterdam has run on the Sepolia testnet, but its launch on the Hoodi testnet on October 26 has been delayed, and a new date must be set before mainnet launch.
Original source:
Title: Ethereum fixes Glamsterdam bug that could have sent staking deposits to builders Publisher: CoinDesk Publication date: 2026-10-27 URL: https://www.coindesk.com/tech/2026/10/27/ethereum-fixes-glamsterdam-bug-that-could-have-sent-staking-deposits-to-builders Source nature: mainstream crypto media report (quoting developers and researchers) Verification: cross-checked by multiple English-language reports, consistent with official development discussions. Supporting content: bug mechanism (builder and validator deposit attribution under the same public key), fix details (sorted by withdrawal credentials), merge timing, no loss reports, testnet status and delay.
ABAB AI Insight
Glamsterdam aims to separate the builder and validator roles, making deposit processing require stricter differentiation. The conditional finding shows a potential attribution error under specific public-key reuse and pending-deposit sorting, but existing checks already prevent real exploitation, and there are no loss reports. The fix was merged after initially being rejected, reflecting the effect of client team support and testing timelines on upgrade safety.
The testnet delay (Hoodi) provides a window to implement the fix, but it does not change the requirement that client integration must be completed before mainnet. Such conditional code issues are common in upgrades, and timely disclosure and fixes help reduce real-world risk.
ABAB News · Cognition Law
A conditional code finding does not mean a live exploit or fund loss has already occurred.
An upgrade-spec fix must be implemented by clients before it can take effect on mainnet.