In the upcoming Ethereum Glamsterdam upgrade, a flaw buried within the consensus layer's deposit accounting rules has been identified in advance. Researcher avsetsin pointed out during the public review stage of the upgrade draft: if an operator first registers as a block builder using a certain public key, and the staking service subsequently deposits ETH for a new validator using the same public key, the existing rules may attribute both deposits to the builder's account, causing the staking funds intended for the new validator to be "misaccounted," potentially allowing the operator to withdraw them in extreme cases. Several Chinese media outlets quoted CoinDesk reports that this vulnerability was not exploited on the mainnet but was identified ahead of time by the review mechanism, leading to a discussion that created a fix; the core adjustment was to reorganize the handling of validator deposits to prevent new validator funds deposited by staking services from being incorrectly assigned to the builder's account. It was reported that the fix was merged into the Ethereum consensus specification on October 26, adding a clearer line of defense for the staking accounting security before the subsequent Glamsterdam upgrade goes live.
Seemingly harmless public key reuse: how it stumbled into the accounting trap
Let's rewind to the moment the flaw was deduced: First, the operator appears, registering as a block builder in the system using a string of public keys, leaving the first record in the consensus layer's deposit accounting table. Next comes the staking service, which, while depositing ETH for a new validator, coincidentally reuses the same string of public keys due to public key management. The problem arises here—under the original Glamsterdam draft rules, these two deposits, belonging to different roles, point to the same "builder account" in the system's view. Because the deposit accounting logic determines ownership solely based on whether the string of public keys has appeared as a builder, and does not treat "new validator deposits" as needing to be isolated as a separate role source, thus the second deposit, which should have activated the new validator, is incorrectly added to the builder's account.
From a design perspective, this combination of "first builder, then validator, and conveniently reusing public keys" was underestimated as a scenario that would hardly happen; however, in practical operation, the clear division of roles between the operator and the staking service, each maintaining their own public keys, leaves space for such unintended reuse. Once such a combination truly appears on-chain, the system will, according to the logic hardcoded in the draft, combine the two deposits into the builder account, opening up the opportunity for the operator to withdraw funds that were originally intended for the new validator's stake. This potential mismatch risk clearly cannot wait to be tested by the production environment after the upgrade is implemented.
Misaccounting a deposit: what the staking service might lose
Under this misalignment in accounting, what is truly pushed to the edge of the cliff is not the operator's own collateral, but rather the deposit made by the staking service on behalf of users, intended to activate the new validator. Once the on-chain rules mistakenly counts this money as belonging to the builder's account, the right to withdraw naturally falls into the operator's hands, even if the user never agreed to, nor realized, that the public key was reused; at the protocol level, the answer to "whose money is this" has already been rewritten. For custodial staking services, this creates a scenario that is extremely difficult to explain to the delegators: on the surface, the user sees "your ETH has been used to activate a new validator"; but in the underlying consensus ledger, this fund has technically turned into a balance that the operator can unilaterally access.
This mismatch directly impacts the already fragile trust boundary between users and operators. The business model of staking services is built on the division of labor where "protocol guarantees the rules, operators are responsible for execution," leading delegators to implicitly trust that even though operators control the keys, the distribution of principal and earnings is constrained by on-chain mechanisms. However, in the scenario exposed by this flaw, the incentive design and security boundaries overlapped: the same group of public keys participated in the incentives for the builder role while also holding the deposits for the new validator; as long as the accounting rules are slightly biased, they can quietly convert the ETH that should have been locked for the new validator into assets that the operator can withdraw, and this invisible shift in authority is a systemic risk that the consensus layer cannot tolerate.
Identifying hidden risks before the upgrade: how Ethereum developers close the loophole
While the public review was still underway, researcher avsetsin was the first to throw the issue back to the developers: if an operator first registers as a block builder using a certain public key and then the staking service uses the same public key to deposit ETH for the new validator, then under the current draft, both deposits would end up in the builder's account. As the details were repeatedly disclosed and deduced, the consensus specification maintainers quickly realized that this was not just a single implementation flaw, but rather a lack of boundary constraints in the deposit accounting rules themselves under the "same public key, different roles" scenario, leading to discussions on how to rewrite this part of the rules without disrupting existing processes.
Ultimately, the approved fix did not seek to tighten the registration process for builders but directly addressed the logic of handling validator deposits: redefining the attribution path of such deposits at the consensus layer to prevent new validator funds deposited by the staking service from being incorrectly allocated to the builder's account, thereby cutting off the space for operators to treat this ETH as their own asset at the rule level. According to several Chinese media outlets quoting CoinDesk, this fix was officially merged into the Ethereum consensus specification on October 26, serving as a preventive repair completed before the Glamsterdam upgrade goes live, and providing a more secure basis for staking accounting for subsequent upgrades on-chain.
From a bookkeeping flaw, observing the boundaries of public keys and responsibilities in staking services
The reason this accounting flaw exists is that the same public key was first used by the operator to register as a block builder and then was used by the staking service to deposit ETH for the new validator. By design, the Ethereum consensus layer sets deposit and permission rules separately for builders and validators, but this segment of logic in the Glamsterdam draft leaves a gray area: when the public key is reused across roles, the two deposits that should belong to different accounts are mixed into the builder's account, thus providing the operator with the opportunity to withdraw funds that should be used for the new validator's stake. This fix attempts to mitigate the accounting misalignment caused by roles' public key reuse by adjusting the handling of validator deposits, but the materials also highlight that this risk has been closely tied to the operational practices of staking services from the outset.
From a role design perspective, builders are responsible for packaging blocks, while validators assume consensus voting, and there should be a clear separation of responsibilities in terms of permissions and incentives between the two. The rule layer addresses boundary conditions but cannot substitute the public key management discipline of the staking service itself: whether to prohibit the same public key from being marked as different roles internally, and whether to obstruct the reuse path of "first acting as a builder and then as a validator" in the process determines the probability of such scenarios occurring in practical operation. The lesson from this incident for Ethereum's staking ecosystem is that security cannot be entirely outsourced to protocol upgrades; participants need to first eliminate such public key reuse risks within their internal processes before viewing consensus rules as the last line of defense.
After Glamsterdam, what security signals need to be monitored
From the outcome, this public key reuse vulnerability was locked down at the Glamsterdam upgrade draft stage and did not evolve into a mainnet incident. Moreover, according to several Chinese media outlets quoting CoinDesk, the fix was merged into the Ethereum consensus specification on October 26, with the marginal impact on perceptions of staking deposit security reflecting more of a "confidence restoration" rather than "panic escalation": on one hand, it revealed that the design layer of staking accounting does indeed have extreme scenarios that have not been fully modeled, reminding operators and developers not to take the existing processes for granted; on the other hand, the vulnerability was caught by external researcher avsetsin before going live and promptly went into specification repair, which has strengthened community trust in the Ethereum upgrade review mechanism. The signals worth monitoring next mainly fall into two categories: first, during the Glamsterdam advancement process, whether there will be further review and adjustments to staking and deposit rules—the materials did not provide a formal launch timetable, and any new rule adjustments need to be confirmed by official announcements; second, after the repair is merged, whether the community's discussion around these "consensus layer accounting details" heats up and whether it encourages more external researchers to continue participating in the review. Overall, this incident releases a slightly positive long-term signal: as long as public review continues and external researchers maintain collaboration with core developers, similar design layer risks are more likely to be identified and eliminated during the specification document phase, instead of waiting for the mainnet funds to pay the price before being discovered by the market.
Join our community to discuss and become stronger together!
Exclusive Hyperliquid benefits for AiCoin: https://app.hyperliquid.xyz/join/AICOIN88
Exclusive Aster benefits for AiCoin: https://www.asterdex.com/zh-CN/referral/9C50e2
On-chain Telegram community: https://t.me/AiCoinWhaleData
On-chain community: https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin on-chain Twitter: https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
