Lido Engineer Warns of Staking Deposit Hijack at Glamsterdam

A malicious node operator could divert a delegated staker’s new Ethereum deposit into a builder account during the Glamsterdam hardfork, Lido’s staking engineering head warned on Oct. 20.

Posting as gusakov.eth (@d_gusakov), the engineer said an operator could front-run a validator deposit with a deposit using builder withdrawal credentials, identified by the `0xB0` prefix. The result: “your deposit will be credited to a builder with the same pubkey.”

The linked consensus-specs issue, opened by GitHub user avsetsin on Oct. 12, was closed as “not planned” on Oct. 19. 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.”

A One-Time Deposit Crossover

Glamsterdam brings proposer-builder separation into Ethereum’s consensus rules. Builders assemble the transaction payloads that block proposers use; 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 remain pending at the fork, the onboarding logic credits both amounts to the builder. The operator can then withdraw the protocol’s funds, according to the report.

No validator is created in that scenario. A protocol that requires proof of a validator’s withdrawal credentials before releasing more funds may therefore be unable to obtain that proof. Depending on its design, accounting, staged funds or recovery procedures could be disrupted, the issue says.

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

After the fork, EIP-8282 routes builder deposits through a separate contract. It retains 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.

Checks Before Funding

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.

Glamsterdam activated on Sepolia on Oct. 6. Ethereum’s deployment tracker proposes Hoodi activation on Oct. 26 and still lists mainnet timing as TBD.