Ethereum developers have merged a correction for a deposit-handling flaw in the upcoming Glamsterdam upgrade after reversing an earlier decision to reject the change.
The issue could have caused ETH intended to create a new validator to be credited to a block builder instead, if both were linked to the same public key. The fix was added to Ethereum’s consensus specifications on 26 October.
The problem affects rules still under development and does not describe a confirmed theft from Ethereum’s mainnet. Consensus clients must now implement and test the revised behaviour.
Deposit records separated
The flaw was identified by researcher avsetsin on 12 October in rules for handling deposits waiting when the Gloas fork takes place.
Under the original logic, a builder registered before a validator deposit arrived could have received both deposits if the same public key was used. The correction separates builder and validator deposits according to their withdrawal credentials.
That would ensure a valid validator deposit is sent to the validator queue, while a legitimate builder deposit can either create a builder record or add funds to an existing one.
The risk arose from Glamsterdam’s enshrined proposer-builder separation, which gives block construction and block proposal to different participants. Builders assemble transaction payloads, while validators propose and confirm blocks under Ethereum’s proof-of-stake system.
Avsetsin described a possible scenario involving a staking operator receiving money from a liquid staking protocol to create a validator. If the operator registered as a builder first, the validator deposit could have been routed to a builder balance with a withdrawal address controlled by the operator.
The expected validator would then not be created, potentially leaving the staking service unable to obtain the proof required for its usual deposit and recovery processes.
Preliminary code research also examined possible exposure involving Lido, Origin and Rocket Pool. The findings depended on how each protocol handled deposits and did not establish that any of the projects had been exploited.
Developers reopen rejected proposal
Ethereum client developers initially rejected the proposed correction. Justin Traglia closed the pull request on 19 October after discussions among core developers, but it was reopened on 23 October following further review.
Reviewer potuz subsequently approved the approach while asking for additional tests covering particular combinations of deposits. Avsetsin added tests that day for cases in which builder and validator deposits use the same public key but must remain separate.
Traglia merged the final correction on 26 October after further client review. It includes regression tests covering the classification of deposits during the Gloas transition.
Hoodi upgrade remains delayed
The change was made as developers separately investigated a compatibility issue delaying Glamsterdam’s activation on the Hoodi testnet.
The Ethereum Foundation postponed the planned 26 October upgrade after risks were identified involving EIP-8037. The delay removed both the Amsterdam execution changes and Gloas consensus changes from Hoodi’s schedule, along with the planned increase to a 200 million gas limit.
Ethereum researcher Toni Wahrstatter said EIP-8037 could affect smart contracts that rely on assumptions about the gas remaining during execution. Some transactions could revert unexpectedly, or follow execution paths developers had considered unreachable.
That investigation is separate from the builder-deposit flaw. Glamsterdam activated on the Sepolia testnet on 6 October, but Hoodi’s rehearsal has no confirmed new date, and no mainnet activation date has been set.
