Dima Gusakov says malicious node operators could redirect staker ETH during the fork transition, after a proposed spec fix was closed as not planned
Ethereum ’s next big upgrade is supposed to make the network better. Lido’s head of engineering thinks it could also briefly make it easier to steal stakers’ ETH.
On October 20, 2026, Dima Gusakov, Head of Engineering at Lido Finance, publicly flagged a potential front-running attack. The risk targets delegated staking protocols during the transition to the Glamsterdam hard fork. The window is narrow, but the stakes involve the deposits that make liquid staking work.
Glamsterdam introduces builder deposits that use a specific type of withdrawal credentials, marked with the 0xB0 prefix. Withdrawal credentials essentially tell the network who owns the staked ETH and where it ultimately goes.
According to Gusakov’s warning, builder deposits and validator deposits will run through shared deposit queues around the fork. That overlap creates an opening. A malicious node operator with the right access could submit a builder deposit that preemptively claims ETH meant for a staker’s validator.
The result, if the attack succeeds: the deposit gets credited to the attacker’s builder account. The validator the staker was funding never activates. The vulnerability is specific to the pre-fork phase. It is not a permanent flaw baked into Ethereum’s design going forward. It is a timing problem tied to the moment the rules change.
The issue was raised in the Ethereum consensus-specs repository on GitHub as issue #5735. The proposal called for pre-deposit checks, a way to verify conditions before a deposit is accepted. That issue was closed as “not planned.”
Daily. Free. Join 34,000+ readers across crypto, finance, and policy.
So the protocol-level patch is off the table, at least for now. Gusakov’s response points to pre-deposit checks as the defense, with the burden shifting to staking protocols themselves rather than the core specification.
Glamsterdam is the combined name for two sets of changes. Gloas covers the consensus layer, while Amsterdam handles the execution layer. The upgrade is scheduled to activate on the Hoodi testnet on October 26, 2026, just six days after Gusakov’s warning. A mainnet date has not yet been set, though the launch is targeted for Q4 2026.
This is not Lido’s first encounter with deposit front-running. After vulnerabilities came to light in 2021, the protocol built a Deposit Security Module along with a guardian committee to oversee deposits.
Before deposits go through, a group of guardians checks that nothing suspicious has slipped in ahead of them. The new question is whether that infrastructure, and the equivalents at other staking providers, accounts for the new 0xB0 builder credentials and the shared queue dynamics at the fork boundary.
The practical risk depends heavily on how individual protocols handle deposits. Providers with robust pre-deposit verification, like the guardian model Lido already runs, appear better positioned. Smaller or newer staking services without comparable checks may need to move quickly before mainnet activation.
The “not planned” closure of issue #5735 signals that core developers are leaving this particular defense to the application layer. That means responsibility is distributed across staking providers rather than handled at the protocol level.
The Hoodi testnet activation offers the first real proving ground. Staking teams can use it to test whether their deposit pipelines correctly detect and block a builder deposit attempting to claim validator funds.