Lido Engineer Warns Staking Deposits Could Be Hijacked During Ethereum's Glamsterdam Upgrade

Lido Engineer Warns Staking Deposits Could Be Hijacked During Ethereum's Glamsterdam Upgrade

Lido engineer flags deposit diversion risk tied to Glamsterdam

A staking engineer at Lido has warned that a malicious node operator could redirect a delegated staker's new Ethereum deposit into a builder account during the Glamsterdam hardfork. The engineer, who posted as gusakov.eth (@d_gusakov) on Oct. 20, said an operator could front-run a validator deposit with a deposit that uses builder withdrawal credentials, identified by the 0xB0 prefix.

In that case, the engineer said, "your deposit will be credited to a builder with the same pubkey."

A related issue on the Ethereum consensus-specs repository, opened by GitHub user avsetsin on Oct. 12, was closed as "not planned" on Oct. 19.

What the consensus-specs discussion says

  • Justin Traglia, an author of Ethereum's builder-deposit proposal, wrote that developers had discussed the topic but that "There was not enough support from clients to make this change at this time."
  • Glamsterdam brings proposer-builder separation into Ethereum's consensus rules. Builders assemble the transaction payloads that block proposers use, and the upgrade introduces staked builder accounts within the protocol.
  • The issue describes an operator first queuing a valid builder deposit for a new public key, with withdrawals directed to the operator's own address.
  • A staking protocol then funds a validator deposit for that same key using its intended validator withdrawal credentials, such as 0x02.
  • If both deposits are still pending at the fork, the onboarding logic credits both amounts to the builder, and the operator can then withdraw the protocol's funds, according to the report.
  • No validator is created in that scenario, which could leave a protocol unable to obtain proof of a validator's withdrawal credentials before releasing more funds.
  • Depending on its design, the issue says a protocol's accounting, staged funds, or recovery procedures could be disrupted.

Which deposits are exposed

The current fork specification keeps deposits for already-registered validators in the validator queue. The exposure described applies to pending deposits for new keys where the operator's builder deposit sits ahead of them, not to existing validator balances.

After the fork, EIP-8282 routes builder deposits through a separate contract. It keeps the one-time onboarding of builder-credentialed deposits from the old queue so builders can exist from the upgrade's first slot. That transition is where the two deposit types can cross over.

Pre-deposit checks proposed as a defense

The GitHub report identifies pre-deposit checks that reject an earlier builder deposit as a way to prevent the scenario. Gusakov urged delegated-staking developers to review the details and prepare mitigation measures.

What is confirmed

It is confirmed that a Lido staking engineer raised the warning publicly on Oct. 20, that a consensus-specs issue on the same topic was opened on Oct. 12 and closed as "not planned" on Oct. 19, and that a proposal author cited a lack of client support for the change. It is also confirmed that Glamsterdam activated on Sepolia on Oct. 6, that Ethereum's deployment tracker proposes Hoodi activation on Oct. 26, and that mainnet timing is still listed as to be determined.

What is still unclear

The source material does not say whether the described scenario has occurred, whether any protocol has suffered losses, or whether any mitigation has been adopted. It also does not state a confirmed mainnet activation date for Glamsterdam, and the exposure is described as a reported risk rather than a confirmed exploit.

Why this matters for staking users

People who stake Ethereum through a delegated staking service hand their deposit process to an operator. The report suggests that during the Glamsterdam transition, a pending deposit for a new key could be diverted if a builder deposit for the same key is queued first. Staking protocols are being asked to check for that earlier builder deposit before releasing funds.

Sources

Newisty Editorial Team
Written by

Newisty Editorial Team

Technology · Crypto · Digital Economy
View all posts

Newisty Editorial Team covers technology, cryptocurrency, digital products, online platforms, developer tools and the wider digital economy. Our content is researched from official sources, company announcements, public documentation, market data and other primary or reputable sources. Articles are reviewed and edited before publication for clarity, accuracy and useful context.

Comments (0)

Leave a comment
Your comment will appear publicly after submission.
No comments yet. Be the first to comment!