Key Insights
- Deposit classification matters. Shared public keys could create an accounting conflict under the draft rules making withdrawal credentials central to correct deposit handling.
- Client coordination remains essential. A specification change requires implementation and testing, across Ethereum client software before the network can rely on the revised behavior.
- Two issues affect upgrade preparation. The deposit correction addresses a staking risk while the separate EIP-8037 investigation continues to complicate Hoodi testing.
The developers of Ethereum have found a bug that could lead validator deposits into block builder accounts, so they’ve issued a correction for upcoming Glamsterdam on October 26. The update to Ethereum’s consensus specs and fixes a conditional risk with staking of funds, but researchers say there have been no confirmed exploits or losses.
How the deposit flaw Could affect staking funds
Ethereum’s Glamsterdam upgrade introduces changes to proposer-builder separation, which distinguishes block construction from block proposal. Builders assemble transaction packages, while validators stake ETH and participate in securing the network. However, the draft deposit rules created a potential conflict when builders and validators used the same public key.
Researcher Avsetsin identified the problem on October 12 while examining deposit processing during the planned Gloas consensus fork. Under the proposed logic, an operator could register as a block builder before a staking service deposited ETH for a new validator using the same key. Consequently, the system could credit both deposits to the builder’s account.
That outcome could prevent the intended validator from being created and leave the staking service unable to complete its normal recovery procedures. Avsetsin warned in the GitHub report that an operator could withdraw funds intended for the protocol’s validator.
The researcher also examined possible exposure involving Lido, Origin and Rocket Pool. However, those findings depended on each protocol’s deposit procedures and did not establish that any service had suffered a breach. Avsetsin also acknowledged that existing checks could prevent the scenario under certain conditions.
Developers Reverse Their Initial Decision
Ethereum developers initially rejected the proposed correction on October 19 because client teams had not expressed sufficient support. Justin Traglia, a maintainer of Ethereum’s consensus specifications, closed the pull request after discussions among developers.
The proposal returned for review on October 23 as developers reconsidered the deposit-handling risk. Potuz agreed with the methodology, but called for more tests to be conducted on certain permutations of the builder and validator deposits. Avsetsin later extended the tests to include the case of both roles sharing a public key.
Traglia took the correction into the consensus specifications on October 26. The updated rules are based on the withdrawal credentials for the deposit, which will be the withdrawal arrangements linked to deposited funds.
This way, the validator’s deposit is not mixed with the builder’s balance, even if the same public key is used for both of them. It also preserves the intended treatment of legitimate builder deposits.
The correction now forms part of Ethereum’s specifications, but individual client teams must implement and test the updated rules. Therefore, the merge resolves the specification-level issue without establishing that every client has already adopted the change.
Glamsterdam faces wider testing challenges
The deposit correction arrived as developers investigated a separate compatibility problem affecting Glamsterdam’s Hoodi testnet activation. The Ethereum Foundation postponed the planned October 26 upgrade after identifying concerns involving EIP-8037.
Researcher Toni Wahrstätter explained that EIP-8037 could affect smart contracts that depend on assumptions about gas remaining during execution. Under certain conditions, altered gas accounting could cause transactions to revert unexpectedly or change execution paths that developers considered unreachable.
The Hoodi postponement removed both the Amsterdam execution-layer changes and Gloas consensus-layer changes from the planned activation. Developers also delayed the proposed increase to a 200 million gas limit.
These concerns remain separate from the deposit-routing flaw. Nevertheless, both issues demonstrate why protocol changes require coordinated testing across consensus rules, execution behavior and existing applications.
Glamsterdam activated on the Sepolia testnet on October 6, allowing developers to examine planned network changes. However, developers have not confirmed a new Hoodi activation date or a mainnet launch date.
What the fix means for Ethereum
The correction reduces a specific risk in the planned deposit process, but it does not eliminate every possible staking vulnerability. Its effectiveness will depend on client implementations, regression testing and consistent handling of deposits during the upgrade transition.
The episode underscores the need for stakeholders of staking providers to conduct due diligence on updates to protocols before implementing deposit flows. It reinforces the importance of testing for developers of Ethereum, unusual combinations of accounts and how transactions that are waiting to be processed are treated during upgrades.
The Glamsterdam upgrade to Ethereum continues in development and there are still some client testing left to do and Hoodi preparations to make. Both the merged correction and the separate EIP-8037 investigation have impacted the upgrade schedule.
