Ethereum Nearly Let Node Operators Grab Staked ETH

1 week ago 4

Key Takeaways

Validator deposits can no longer fund same-key builders Only deposits queued at the faced risk Hoodi testnet delay revived a rejected fix Teku and Lodestar still need matching code

The specification change was merged on October 26, two weeks after the flaw was reported on GitHub.

How an operator could have taken a staker’s deposit

Pooled staking protocols commonly split the work of running a validator. The protocol puts up the ETH, and an outside node operator holds the validator’s signing key. Ethereum keeps signing and withdrawals separate, so the operator can run the validator without being able to withdraw the protocol’s stake.

Glamsterdam pairs execution-layer changes with a consensus-layer upgrade called Gloas, and adds builders as a new kind of participant under enshrined proposer-builder separation. Builders assemble the transaction-carrying part of each block and hold their own balances. At the fork, Ethereum converts qualifying deposits still waiting in the queue into builder accounts.

That conversion is where the flaw sat. Under the old rule, once a pending deposit registered a builder for a key, every later deposit for that key topped up the builder, regardless of where its withdrawal credentials pointed. An operator could queue a builder deposit for a fresh key from an address they controlled. If the staking protocol then funded a validator deposit for the same key, and both were still pending at the fork, the protocol’s ETH would be credited to the operator’s builder balance, which the operator could then withdraw.

No validator would be created either. Some protocols release the rest of a stake only after proving that a new validator carries their withdrawal credentials, and that proof would never arrive.

In a follow-up comment, the issue’s author listed designs the bug could disrupt, Lido’s predeposit guarantee, Origin’s OETH and Rocket Pool’s Saturn, while flagging the list as quick AI-assisted research that may contain errors. In each case the exposure is a first deposit, 1 ETH in the Lido and Rocket Pool examples, with the rest of the stake left locked until recovery steps run. The author described these as conditional code findings, not live exploits.

Only deposits still queued when the fork activates could be misrouted, and because Glamsterdam has not reached mainnet, no funds have been lost.

Swiss Regulator Clears First Retail Bitcoin ETF

Rejected on October 19, merged a week later

The fix was proposed on October 12. After discussion on two core developer calls, it was closed on October 19 for lack of client support, and the testing call floated prototyping it after the Hoodi testnet upgrade rather than disrupting the schedule.

Three days later, the Ethereum Foundation postponed Glamsterdam’s activation on Hoodi to investigate how EIP-8037 interacts with existing smart contracts, a problem unrelated to deposits (we covered the pause here). The extra time reopened the debate. An October 23 comment on the next testing call’s agenda tied the deposit change to the revised timeline, the author added deposit-ordering tests the same day, and the change was merged on October 26.

What the new rule does

After the fork, builder and validator deposits already travel separate paths under EIP-8282. The fix applies the same logic to the queue at the fork: withdrawal credentials, not the public key, decide where each pending deposit goes.

Pending deposit at the fork Old rule New rule

Validator deposit, same key as a builder	Credited to the builder	Stays in the validator queue
Valid builder deposit, same key as a validator	Blocked from registering	Registers the builder
Invalid builder deposit, existing validator	Kept for the validator	Kept for the validator

Reusing one key for a validator and a builder is still allowed; the purpose stated in each deposit now decides which account it funds.

What still has to happen before the fork

Client teams now have to ship the same rule. A Teku change opened on October 27 was still under review, and Lodestar’s remained open.

A late change also has to land identically in every client. Older reference tests encode the previous routing, so a client following the new rule fails them. Teku’s author reports passing the tests generated from the updated specification, which has not yet been packaged in a specification release. If clients reached the fork applying different rules to the same queue, they would compute different balances and disagree on the chain’s state.

The Foundation has not set a new Hoodi date or a Glamsterdam mainnet date. Staking protocols that rely on deposit proofs also have their own line of defense: according to the issue’s author, pre-deposit checks that reject a key already carrying a builder deposit can prevent this scenario.

The post Ethereum Nearly Let Node Operators Grab Staked ETH appeared first on Coindoo.

Read Entire Article