BTC $79,780 
ETH $2,311 
MGLOEURO $111,813 
USDT $0.9986 
BNB $738.32 
XRP $1.30 
USDC $0.9993 
SOL $99.87 
TRX $0.3276 
FIGR_HELOC $1.02 Ethereum · Explained
Ethereum developers fix Glamsterdam validator deposit flaw
A bug that could route validator deposits to builder accounts was merged into Ethereum's consensus specifications after initial rejection.
Key takeaways
- Deposit routing rules now distinguish by credentials. The fix ensures validator and builder deposits are separated based on withdrawal credentials, preventing funds from entering the wrong account even when both roles share a public key.
- Multiple staking protocols faced exposure. Preliminary research identified potential risk to Lido, Origin, and Rocket Pool, though no confirmed exploits on mainnet were reported.
- Client implementation still required. Consensus clients must incorporate the specification change and complete testing before the updated rules can activate on the network.
What happened
Ethereum developers merged a fix on October 26 for a deposit-handling vulnerability in the Glamsterdam upgrade that could have allowed block builders to receive ETH intended for validators. The flaw concerned how pending deposits would be processed during the Gloas fork, the consensus-layer component of Glamsterdam. Under the original rules, if a builder and validator shared the same public key, both pending deposits for that key would be credited to the builder account, potentially allowing unauthorized withdrawal of funds.
The vulnerability was identified by Lido Chief Protocol Architect George Avsetsin on October 12, who described a scenario where a staking operator could register as a builder first, then receive validator deposits from a staking protocol under the same public key. Since both deposits would go to the builder balance, an operator controlling the withdrawal address could access funds intended for the validator, preventing the staking service from completing normal deposit procedures.
The fix separates validator and builder deposits by examining withdrawal credentials when deposits are pending at fork activation. Deposits designated for validators remain in the validator queue, while only deposits carrying builder credentials fund builder accounts. Preliminary research suggested exposure for Lido, Origin, and Rocket Pool, though Avsetsin noted these were conditional findings and not confirmed live exploits.
First $2.7KLatest $2.3K-14.2% over the period
Points are daily observations, not closing prices.
Why it matters
Glamsterdam introduces enshrined proposer-builder separation, formally assigning block construction to builders and block proposal to validators as distinct roles on Ethereum. This architectural change requires careful handling of the deposit system to prevent funds flowing to the wrong party. The deposit-routing flaw threatened to undermine this separation at a fundamental level, potentially allowing operators to exploit the system by manipulating which role received newly staked funds. Fixing the issue before mainnet activation prevents a class of attacks that could have caused significant disruption to staking protocols and individual stakers.
Background
Glamsterdam represents a major architectural shift for Ethereum's consensus layer. The upgrade formalizes the separation between block builders, who assemble transaction payloads, and validators, who propose and confirm blocks through proof-of-stake. Previously, these roles overlapped in practice but were not formally distinguished in protocol rules. Glamsterdam also includes execution-layer changes and a proposed increase to the 200 million gas limit through EIP-7885.
The fix was initially rejected on October 19 by Ethereum researcher Justin Traglia after discussions among core developers. Traglia wrote that there was insufficient client support for the change at that time. However, the decision reversed three days later after Lido Staking Head of Engineering Dmitry Gusakov requested reopening the issue, citing changes to Glamsterdam's timeline and a new opportunity to implement the correction. Prysm developer Potuz approved the change while requesting additional tests, and ChainSafe Protocol Engineer Nico Flaig confirmed the Lodestar client passed the tests on October 26, allowing Traglia to merge the fix.
What to watch
Glamsterdam's activation timeline remains uncertain following a separate postponement announced on October 22. The Ethereum Foundation delayed the upgrade's activation on the Hoodi testnet after identifying compatibility risks involving EIP-8037, which could interfere with smart contract assumptions about gas remaining during execution. The deposit-routing fix addresses a distinct issue but arrives as developers continue investigating other aspects of the upgrade. Sepolia successfully activated Glamsterdam on October 6, allowing developers to examine block construction changes, though the merged deposit fix was not yet included in that testnet activation. Individual consensus clients still need to implement and test the revised deposit-handling behavior before the updated rules can operate during a future network upgrade.
Questions readers ask
What was the original deposit-routing flaw?
Under the original Glamsterdam rules, if a builder and validator shared the same public key, both pending deposits for that key would be credited to the builder account. An operator could exploit this by registering as a builder first, then receiving validator deposits from a staking protocol under the same public key, allowing them to access funds intended for the validator.
Why was the fix initially rejected?
On October 19, Ethereum developer Justin Traglia closed the pull request due to insufficient client support. The decision was reconsidered three days later after the Glamsterdam timeline shifted and Lido requested reopening the issue to fix the flaw.
Does the fix need to be implemented by all clients?
Yes, individual consensus clients must incorporate the specification change into their software and complete additional testing before the updated deposit-handling rules can activate during a future network upgrade.
