Mentioned in This Article
1. What did Ethereum developers fix in Glamsterdam?
Ethereum developers have merged a change to the planned Glamsterdam upgrade that closes a flaw which could have let an operator take ETH meant to fund new validators. The fix altered the rules for handling validator deposits and was accepted on Monday, October 26, one week after developers had first turned it down. No losses have been reported, and the Ethereum upgrade still has to be built into client software before it can move toward mainnet.
The episode is a reminder of how much scrutiny a network upgrade receives between its specification and its launch. A problem in the rules for deposits touches the mechanism by which people put capital behind the network, so even a flaw that never reached live users deserves a careful correction.
The change now lives in Ethereum's consensus specifications, the written rules that every client team implements. Until each team has coded and tested the revised deposit handling, the upgrade cannot be scheduled for the main network.
2. How do builders and validators differ under Glamsterdam?
Glamsterdam separates two roles that are currently bundled together. Builders assemble blocks of transactions, while validators stake ETH to help secure the network, proposing and confirming those blocks. Under the upgrade both kinds of participant can deposit ETH, and the protocol is supposed to track those deposits separately.
Ethereum's clients, the separate software programs that validators run to take part in the network, process deposits that are still waiting to be credited. The flaw arose in that step, where the draft rules did not fully distinguish between a deposit meant for a builder and one meant for a validator.
Separating the roles is designed to make the block-production process more orderly. The price of that design is additional bookkeeping, and the bug shows how an identifier shared between the two roles could blur the accounting.
3. How could staking deposits have gone missing?
The scenario was laid out by a researcher using the name avsetsin. An operator registers as a builder using a specific public key, the identifier tied to a validator or builder. If a staking service then deposits ETH to start a validator under that same key, the draft rules would credit both deposits to the builder.
The consequence, in the researcher's assessment, is that the operator could withdraw funds that belonged to the staking service. Because no validator is ever created, the service cannot produce the proof it would need to recover its money, leaving it without a path to reclaim the deposit.
Avsetsin, who is listed as a member of Lido's GitHub organization, also looked at how Lido, Origin and Rocket Pool might be affected, describing the work as quick AI research. The exposure depended on how each protocol handles deposits, so the answer differed from one to the next.
The researcher characterized the findings as conditional code issues rather than confirmed live exploits. Existing checks that reject an earlier builder deposit could block the attack in some configurations, and no losses have been reported.
4. Why was the fix turned down and then merged?
Developers closed the proposed fix on October 19. Justin Traglia, who maintains Ethereum's consensus specifications, said there was not enough support among client teams to make the change at that point. Because every client must implement any change to the rules, a proposal without broad backing tends to stall.
After further review the fix was reopened. Avsetsin added tests on October 23, and Traglia merged the change on Monday. Delays in testing the upgrade appear to have given developers additional time to examine the flaw, which helped the proposal gain acceptance.
The sequence illustrates how Ethereum's open process works in practice. A change can be rejected on one day and adopted a week later when the evidence and the schedule shift, without any single person overriding the others.
5. What do the new deposit rules say?
Under the revised rules, pending deposits are sorted by withdrawal credentials, the setting that determines where a deposit's funds can ultimately go. The practical effect is that validator deposits stay with validators, even when a builder uses the same public key.
This closes the path described in the report. A staking service depositing under a key that happens to match a builder's would no longer see its funds credited to the builder, because the credentials attached to the deposit determine where it is applied.
Sorting by withdrawal credentials is a conservative choice. It keys the decision on the destination of the funds rather than on the key alone, which is the piece of information that cannot be shared between a builder and a validator without being obvious.
6. What happens next for the Ethereum upgrade?
Client teams must now implement the revised deposit rules in their software. Glamsterdam has already run on the Sepolia test network, but its October 26 launch on Hoodi, a second test network, was postponed.
The upgrade needs a new Hoodi date before a mainnet launch can be scheduled. No mainnet date has been set, and the timing will depend on how quickly the client teams integrate and test the fix.
An earlier postponement, reported on October 23, followed a warning from security developers about risk to existing contracts. Together, the two episodes show developers choosing to slow the schedule when a review turns up a concern, rather than pressing ahead to hit a date.
7. What is staking, and why do deposit rules carry so much weight?
Staking is the process by which holders lock ETH to act as validators, the participants who propose and confirm blocks and who earn rewards for doing so. Becoming a validator requires a deposit, and that deposit is tied to a public key and to withdrawal credentials that say where the funds can eventually be sent. Everything about a validator's identity and its right to its own money flows from that registration step.
Many holders do not run validators themselves. They use staking services and liquid staking protocols that pool deposits and start validators on their behalf, which is why Lido, Origin and Rocket Pool were examined in the report. These services depend on the protocol to credit each deposit to the validator it was meant to create, since a mismatch leaves them with no easy way to prove their claim.
That dependence is why deposit handling is treated as one of the most sensitive parts of the specification. A misapplied deposit is not an inconvenience that can be reversed with a support ticket, because the protocol itself decides who owns the funds.
8. How does Ethereum decide which changes get adopted?
Ethereum has no central owner who can approve a change. Proposed edits to the consensus specifications are discussed publicly, and maintainers merge them once there is enough confidence and enough agreement among the independent teams that build the clients. A change that lacks that support, as this one did on October 19, can be set aside without anyone concluding that the underlying concern is invalid.
Upgrades such as Glamsterdam move through public test networks before the main network. Sepolia and Hoodi serve as rehearsals where client teams can confirm that their software behaves the same way and that the new rules work as intended. A postponed test launch is therefore a normal part of the process, and it creates room for additional review.
The deposit fix passed through that process in full: a report, a rejection, new tests, a second look and a merge. Each stage is visible to anyone who follows the specification repository, which is part of why the network can adjust its own rules without a single point of authority.
9. Who is affected by the Glamsterdam deposit bug?
In its draft form, the flaw would have mattered most to staking services that deposit ETH on behalf of others, because they are the parties that start validators in bulk. An individual staker depositing under a unique key would have been unlikely to encounter the problem, since the scenario relies on a builder registering with a key that a validator deposit later reuses.
The researcher's analysis of Lido, Origin and Rocket Pool found that the exposure varied with each protocol's deposit design, and existing checks that reject an earlier builder deposit could prevent the attack in some cases. That is why the findings were described as conditional rather than as a confirmed way to steal funds today.
Because Glamsterdam has not reached mainnet, no live deposits were ever at risk. The relevance of the report is to the design of the upgrade, and the merged change means the issue is resolved in the specification before any such deposit could be processed.
10. Why do small specification bugs matter so much?
Ethereum secures a very large amount of value through rules that are written once and then run identically by thousands of machines. A flaw in those rules is not like a bug in a single application, because it can be copied across every client that follows the specification. Catching it before launch is far cheaper than responding after it is live.
Deposits are a particularly sensitive area. They are the entry point for staked ETH, and staking services handle money on behalf of many users. A rule that could misdirect even a single deposit undermines the trust that those services rely on, which is why developers revisited the fix despite the earlier rejection.
The case also shows the growing role of automated analysis in protocol review. The researcher described the work as quick AI research, and the finding was still concrete enough to produce tests and a merged change. Human maintainers remained the decision-makers, weighing the report against client support and the testing schedule.
For stakers and staking providers, the immediate lesson is that nothing in the report describes a live loss. The relevant question is whether the revised rules are implemented correctly by every client, and that work now moves to the teams that build the software validators run.