Ethereum developers have approved a fix for a deposit-handling flaw in the upcoming Glamsterdam upgrade after initially rejecting the proposed change. The issue could have allowed ETH intended to create a new validator to be credited to a block builder instead, potentially placing the funds under a different withdrawal arrangement.
The correction was merged into Ethereum’s consensus specifications on October 26. It changes how the network distinguishes builder deposits from validator deposits when both use the same public key. However, a merged specification is not the same as a live network fix: Ethereum client teams still need to implement and test the revised rules.
The flaw affected rules being developed for the upgrade. It was not a confirmed theft from Ethereum’s mainnet, and the report did not establish that any staking service had lost funds through it.
How the Glamsterdam Deposit Flaw Worked
The problem emerged in deposit-processing rules planned for Gloas, the consensus-layer part of Glamsterdam. Those rules support enshrined proposer-builder separation, a design that assigns block construction and block proposal to different roles. Builders assemble transaction payloads, while validators help propose and confirm blocks.
Researcher avsetsin reported the issue on October 12. The concern involved deposits waiting to be processed when the network transitions to the new rules. Under the proposed logic, a builder that registered with a public key before a validator deposit arrived under that same key could receive credit for both deposits.
In simple terms, the system could recognize the shared key but fail to keep the two purposes separate. ETH meant to fund a validator could end up in the builder’s balance instead.
That distinction matters because the person controlling the builder’s withdrawal address might not be entitled to withdraw the funds supplied for the validator. The flaw therefore created a possible route for staking funds to be redirected.
Ethereum’s ongoing protocol changes can affect both staking infrastructure and validator operations, making it important to understand how proposed network changes may influence participants. Read more about Ethereum staking yields works
Why Staking Services Faced a Potential Risk
The researcher described a scenario involving an operator that receives funds from a liquid staking protocol to create a validator. If that operator registered as a builder first using the same public key, the protocol’s deposit could be routed to the builder balance. The operator could then control the address permitted to withdraw those funds.
The expected validator would not be created in that scenario. That could also complicate the staking service’s recovery process if its normal procedures required proof relating to the missing validator.
Preliminary research examined possible exposure involving Lido, Origin, and Rocket Pool. However, the findings depended on how each protocol handled deposits. They were not proof that those projects were vulnerable in every case, nor did the report identify an actual exploit against them.
The central concern was therefore a potential failure in the upgrade’s deposit-routing rules, not evidence of a wider breach across Ethereum staking platforms.
Developers Reversed Their Initial Decision
The proposed fix did not receive immediate support from Ethereum client developers. After discussions among core developers, consensus-specifications maintainer Justin Traglia closed the pull request on October 19 because there was not enough client support to make the change at that time.
Further review changed that position. Developers reopened the proposal on October 23, and reviewer potuz approved the approach while asking for more tests covering specific deposit combinations. Avsetsin added those tests the same day.
The review focused on situations where builder and validator deposits share a public key but still need to be processed separately. Following additional client review, Traglia merged the correction on October 26.
The sequence highlights the difference between identifying a risk and agreeing on a protocol-level response. In this case, the initial rejection was followed by further examination, expanded tests, and approval of the revised behavior.
How the Fix Keeps Deposits Separate
The correction uses withdrawal credentials to distinguish between deposit types. These credentials define the permitted withdrawal arrangements and help the network determine how a deposit should be handled.
Under the revised rules:
- Valid validator deposits enter the validator queue.
- Legitimate builder deposits can register a builder or add funds to an existing builder.
- Builder and validator records remain separate, even when they share a public key.
This approach addresses the core routing problem without treating every deposit associated with the same key as belonging to one role. The merged change also includes regression tests designed to check that the corrected behavior remains intact as development continues.
Although protocol upgrades can influence market sentiment, technical developments alone do not determine ETH’s price. Explore why crypto markets are highly volatile to understand the other factors that can affect digital asset prices.
A Separate Issue Has Delayed the Hoodi Upgrade
The deposit correction arrived while developers were investigating another Glamsterdam concern. The Ethereum Foundation postponed the upgrade’s planned October 26 activation on the Hoodi testnet because of potential contract-compatibility risks involving EIP-8037.
Researcher Toni Wahrstätter identified cases where changes in gas accounting could affect contracts that rely on assumptions about how much gas remains during execution. Those changes could cause unexpected transaction failures or allow execution paths that contract developers had considered unreachable.
This problem is separate from the validator deposit flaw. The Hoodi postponement specifically concerned EIP-8037’s interaction with existing contracts, rather than the builder-deposit issue addressed by the October 26 correction.
The delay removed both the Amsterdam execution-layer changes and the Gloas consensus-layer changes from Hoodi’s planned activation. A proposed increase to a 200 million gas limit was postponed as well.
What Happens Before Glamsterdam Goes Live?
Glamsterdam activated on the Sepolia testnet on October 6, allowing developers to examine changes to block construction and transaction-processing capacity. However, the next Hoodi rehearsal remains unscheduled, and there is no confirmed date for activation on Ethereum mainnet.
Client teams must now incorporate the deposit correction into their software and complete further testing. The specification change defines the intended behavior, but client implementations must apply it consistently before the rules can operate during a future network upgrade.
For staking users and operators, the key distinction is that developers have corrected a potentially harmful design flaw before its mainnet activation. The remaining work is to turn that agreed correction into tested client software while resolving the separate compatibility questions holding up Glamsterdam’s next rehearsal.
