Skip to content
Prices
  • BTC$79,565▼ 0.58%
  • ETH$2,305▼ 0.58%
  • BNB$734.42▼ 0.56%
  • XRP$1.30▲ 1.43%
  • SOL$99.64▼ 0.95%
  • TRX$0.3277▼ 0.71%
  • HYPE$77.81▲ 2.14%
  • DOGE$0.0773▲ 0.72%
  • LINK$11.33▼ 0.14%
  • ADA$0.2037▲ 0.81%
  • AVAX$8.76▼ 0.84%
EthereumNewsExplainer

Ethereum patches Glamsterdam bug that misrouted staking deposits

A Glamsterdam spec flaw could have credited a staking service's validator deposit to a builder using the same key. How the bug worked and how the merged fix stops it.

· · 3 min read

Share
A silver physical Ethereum coin with the ETH diamond logo on a white surface (illustrative photo)
Image: Stock Catalog / Wikimedia Commons, CC BY 2.0

Ethereum developers have merged a fix for a bug in the upcoming Glamsterdam upgrade that, under certain conditions, could have handed ETH deposited for a new validator to a block builder instead, CoinDesk reported. The flaw lived in the specification, not on mainnet, and no funds were lost.

Background: builders and validators get separate books

Today two jobs are bundled together: builders assemble blocks of transactions and validators, who stake ETH, propose and confirm them. Glamsterdam formally splits these roles inside the protocol, and both builders and validators can deposit ETH. Their balances are supposed to be tracked separately. (If staking itself is new to you, start with what crypto staking is.)

How the bug worked

The problem appeared at the moment of the upgrade, when Ethereum would process deposits still waiting in the queue. A researcher using the handle avsetsin described this sequence:

  • an operator registers as a builder under a particular public key;
  • a staking service then deposits ETH to launch a validator using that same key;
  • the draft rules credit both deposits to the builder.

"The operator can withdraw the protocol's funds," avsetsin wrote. Because no validator is ever created, the staking service cannot produce the proof it would need to reclaim its ETH.

Avsetsin, listed as a member of Lido's GitHub organisation, ran what they called "quick AI research" on how Lido, Origin and Rocket Pool might be exposed. The results depended on how each protocol handles deposits, and the researcher stressed these were "conditional code findings, not confirmed live exploits"; existing checks that reject an earlier builder deposit could block the attack.

Rejected, then merged

Developers first closed the proposed fix on Oct. 19. "There was not enough support from clients to make this change at this time," wrote Justin Traglia, who maintains Ethereum's consensus specifications. After further review it was reopened, avsetsin added tests on Oct. 23, and Traglia merged it on Monday, Oct. 26.

Under the new rule, pending deposits are sorted by their withdrawal credentials, the field that says where a deposit's money can ultimately go. A validator deposit stays with a validator even if a builder uses the same key.

What happens next

The change is now part of the consensus specs, but client teams still have to build it into their software. Glamsterdam has already run on the Sepolia testnet, while its Oct. 26 Hoodi fork was postponed over a separate gas-rule risk. A new Hoodi date is needed before mainnet can be scheduled. For how network upgrades like this are rolled out, see hard fork vs soft fork.

This article is for information only and is not financial advice. Crypto assets are volatile; do your own research. Read our disclaimer

Share

More from Ethereum

View all →

Read next