A public key tells a blockchain who someone is. It does not, on its own, say whose money is being moved. A flaw found this month in Ethereum's next major upgrade, Glamsterdam, came down to exactly that difference, and the way it was handled is a useful lesson for anyone who designs, upgrades or depends on on-chain systems.
On 26 October, Ethereum's consensus-spec maintainers merged a fix titled Separate builder and validator deposits at the Gloas fork. Gloas is the consensus-layer half of Glamsterdam. The fix closes a scenario in which ETH that a staking service sent to create a new validator could have been credited to someone else. No losses have been reported, and the researcher who raised it described the findings as conditional rather than a confirmed live exploit. The interesting part is not a near miss. It is where the gap was hiding.
What Glamsterdam changes
Today, most Ethereum blocks are assembled by specialised builders that work outside the protocol itself, through relays. Glamsterdam brings that separation inside the protocol: builders assemble blocks, and validators, who stake ETH to secure the network, choose and attest to them. As CoinDesk explains, both roles can deposit ETH, and their balances are supposed to be tracked separately.
After the fork, that separation is clean: builder and validator deposits travel through different processing paths. The weak point was the moment of the fork itself. Deposits still waiting in the queue when the upgrade activates have to be sorted into the new structure in a single, one-time pass. The Gloas fork specification now describes that onboarding step as the only path through the validator deposit contract that creates builders.
How the money could have gone to the wrong place
The issue, filed on 12 October by a researcher who goes by avsetsin, opens with one sentence that sums it up: "The party that pays for a deposit is not always the key holder."
Under the draft rules, once a pending deposit registered a builder for a given public key, any later deposit for the same key topped up that builder, whatever its withdrawal credentials said. Withdrawal credentials are the setting that determines where a deposit's money can eventually go.
The issue describes a concrete sequence. Some staking protocols fund an operator's first validator deposit and then require proof that the new validator carries the protocol's withdrawal credentials before releasing the rest of the stake. An operator could first queue a builder deposit for a new key, using their own address. The protocol would then fund a validator deposit for the same key. If both were still pending at the fork, both amounts would go to the builder. In the issue's words: "The operator can withdraw the protocol's funds."
Worse, no validator would ever be created. The staking protocol could not produce the proof its normal recovery process depends on, and depending on its design, accounting could break or related funds could stay locked. CoinDesk reports that avsetsin, listed as a member of Lido's GitHub organization, looked at how Lido, Origin and Rocket Pool could be affected in what the researcher called "quick AI research", while noting that existing checks in some designs could stop the attack.
Turned down, then merged
The fix did not go through on the first try. It was closed on 19 October. "There was not enough support from clients to make this change at this time," wrote Justin Traglia, who maintains the consensus specifications, as quoted by CoinDesk. The proposal was reopened after further review, avsetsin added tests on 23 October, and Traglia merged it on 26 October.
The merged rule is simple to state. Pending deposits at the fork are routed by their withdrawal credentials, not by the public key alone:
- Validator deposits stay in the validator queue, even if a builder uses the same key.
- A valid builder deposit registers or tops up the builder, even if a validator uses the same key.
- The pull request adds regression tests for routing and for the order in which deposits arrive.
The work is not finished. The change is now part of the specification, but every client team still has to implement it. CoinDesk notes that Glamsterdam has already run on the Sepolia test network, that its 26 October activation on the Hoodi test network was postponed, and that a new Hoodi date is needed before a mainnet launch can be scheduled.
What we take from it
We do not run Ethereum clients, and this was not our bug. But the pattern behind it shows up in almost every system that records value, and it is worth naming plainly.
An identifier is not an entitlement. The draft rule treated "same public key" as "same owner". The fix uses the field that actually says where funds may go. Any system that tracks ownership, whether of stake, tokens, documents or music rights, should be clear about which field names a party and which field grants a right, and should never let the first stand in for the second.
Migrations are their own code path. The everyday logic after the fork was sound. The gap sat in a one-time pass that runs once and is then gone. Transition code is easy to review less carefully, precisely because it will not run again. It deserves the same tests and adversarial thinking as the code that runs every day.
Ordering is an attack surface. The scenario only worked because one deposit landed in the queue before another. When the outcome depends on the order of events, ordering belongs in the test suite. That is exactly what the merged pull request added.
A closed proposal is not a closed question. The fix was turned down for lack of client support, then accepted a week later once tests made its effects clear. Reviewers changed their minds when evidence arrived. That is how it should work, and it argues for keeping a door open when a credible report is first declined.
Downstream assumptions need checking too. The protocols that could have been exposed relied on a reasonable assumption: a funded validator deposit creates a validator. When the layer below changes, those assumptions should be written down and re-tested before the upgrade, not after.
It is a principle we care about across our Universe. A good record says who is named, and it also says who is entitled. Glamsterdam's deposit fix is a small change in a long specification, but it shows why the two must never be confused.
Sources: GitHub issue #5735 and pull request #5736 in the Ethereum consensus-specs repository; Gloas fork specification; CoinDesk, 27 October 2026.
