Lido Engineer Warns of Staking Deposit Hijack Risk During Ethereum’s Glamsterdam Transition

2026/10/21 14:09:00

Why Ethereum Developers Rejected the Protocol-Level Fix

Ethereum’s next major network upgrade aims to scale the base layer through enshrined proposer-builder separation and higher gas limits, yet a timing-specific vulnerability has drawn fresh attention from one of the largest liquid staking providers. On October 20, 2026, Dima Gusakov, Head of Engineering at Lido Finance, publicly detailed how the transition to Glamsterdam could allow a malicious node operator to front-run a staker’s validator deposit. The attack would use builder deposits carrying 0xB0-prefixed withdrawal credentials that temporarily share the deposit queue, potentially crediting the ETH to a builder account instead of activating the intended validator. The window is limited to the hard-fork transition itself. After the upgrade, builder deposits move to a separate contract path.

A proposed protocol-level fix in the consensus specifications was closed as “not planned,” shifting the defensive burden onto staking protocols. This article examines the technical mechanics of the risk, the upgrade’s design choices that created the temporary overlap, the reasons core developers declined a protocol patch, the practical steps liquid staking providers must take, the testnet timeline that gives operators only days to prepare, and the broader lessons for delegated staking security as Ethereum advances its scaling roadmap. The analysis draws exclusively on reporting and primary statements from the past 30 days, focusing on verified details rather than speculation.

Lido Engineering Lead Details the Front-Running Vector on X and in Developer Calls

Dima Gusakov issued the warning on October 20, 2026, addressing staking protocols and delegated stakers directly. He explained that a node operator could submit a builder deposit using the same public key before the legitimate validator deposit transaction lands. Because Glamsterdam introduces builder deposits that rely on 0xB0-prefixed withdrawal credentials, and because those deposits share the validator deposit queue during the transition, the first valid deposit can claim the funds. The outcome is that the staker’s validator never appears on the beacon chain while the ETH is credited to the attacker’s builder account. Gusakov emphasized that the attack is possible only at the moment of the hard fork. Pre-Glamsterdam, builder deposits travel through the existing validator deposit queue; afterward, they route through a dedicated contract. The limited duration, he noted, makes mitigation feasible for prepared protocols.

The same concern surfaced in the All Core Devs Consensus call (ACDC #189). Gusakov highlighted that Glamsterdam’s one-time builder onboarding mechanism can interfere with the deposit-protection patterns staking protocols have long relied upon. Under current rules, the first valid deposit for a public key sets the withdrawal credentials permanently. Protocols often deposit a small amount first, confirm the expected credentials appear, and only then top up the remaining balance. During the fork transition, the special onboarding path can produce a third outcome: no validator activates, and the full deposit is attributed to a builder. Core developers declined a late specification change that would have preserved the distinction between validator and builder deposits during the one-time onboarding, citing the fact that Sepolia had already activated under the existing rules and Hoodi client releases were already in preparation. Changing behavior at that stage would have required redeploying Sepolia and additional testing cycles.

How 0xB0 Builder Credentials Interact With the Shared Deposit Queue

Glamsterdam introduces builder deposits as part of the move to enshrined proposer-builder separation. These deposits carry withdrawal credentials beginning with the 0xB0 prefix, distinguishing them from ordinary validator credentials. During the transition period, the two types of deposits share the same queue processing path. A node operator who controls or can influence deposit submission order can therefore insert a builder-credentialed deposit that matches a pending staker public key. Once the first deposit is accepted, the network treats the public key as claimed under the builder credentials. Subsequent deposits under the same key are either ignored for validator activation or redirected according to the new interpretation rules that apply around the fork boundary.

The practical effect is that the staker loses both the expected validator and the deposited ETH, which now sits under the builder’s control. Existing activated validators and already-processed deposits remain unaffected. The risk is confined to new or still-queued deposits that cross the activation epoch. Because the shared-queue behavior ends once the fork completes and builder deposits move to their dedicated contract, the exposure is temporary. That temporary character is the central reason Gusakov advised against panic while still urging every delegated staking service to implement or strengthen pre-deposit verification before mainnet activation.

Core Developers Close the Consensus-Specs Proposal as Not Planned

The technical discussion of a protocol-level remedy appeared in consensus-specs issue #5735. The proposal called for pre-deposit checks that would verify certain conditions before a deposit is accepted into the queue. After review, the issue was closed with the status “not planned.” The decision leaves the defensive responsibility at the application layer rather than embedding additional checks in the core protocol. Gusakov’s public guidance therefore centers on staking protocols performing their own pre-deposit validation. Timing constraints heavily influenced the outcome. Sepolia had already forked under the existing specification on October 6, 2026.

Hoodi client releases were advancing toward the October 26 activation. Introducing a late behavioral change risked forcing a Sepolia redeployment and further testing delays. Core developers judged that the limited window and the ability of application-layer teams to add checks made a protocol patch unnecessary at this stage. The result is a distributed security model in which each liquid staking provider must confirm that its deposit pipeline correctly distinguishes or blocks 0xB0-prefixed deposits that attempt to claim validator public keys.

Pre-Deposit Checks Become the Primary Defense for Liquid Staking Services

Lido itself has operated a Deposit Security Module and guardian committee since earlier deposit-related vulnerabilities surfaced years ago. Guardians review deposit-root snapshots before batches proceed, and a single honest guardian can pause deposits. The open question is whether that existing infrastructure already accounts for the new 0xB0 credential type and the temporary shared-queue dynamics, or whether additional logic is required for the Glamsterdam transition. Other protocols that lack comparable multi-party oversight face a steeper preparation task.

Pre-deposit checks can take several concrete forms. A protocol may refuse any deposit whose withdrawal credentials begin with 0xB0 when the intent is a standard validator activation. It may require an on-chain or off-chain attestation that the public key has not already been claimed under builder credentials. It may pause new deposits for a short window surrounding the activation epoch until the shared-queue period ends. Because the attack surface exists only while the queues overlap, a temporary pause or heightened scrutiny during that interval can eliminate most practical exposure. Smaller or newer staking services that have not yet built guardian-style committees will need to move quickly if they intend to accept deposits through the mainnet transition.

Glamsterdam Activation Schedule Leaves Little Margin for Preparation

The Ethereum Foundation confirmed that Glamsterdam will activate on the Hoodi testnet at epoch 132,352, slot 4,235,264, corresponding to October 26, 2026, at 17:42:48 UTC. At the same epoch, Hoodi’s gas limit rises to 200 million. Sepolia was already activated on October 6. Mainnet timing remains undecided, with candidate dates in early December under discussion, contingent on a clean Hoodi fork. Node operators and staking teams therefore have only days after Gusakov’s warning to validate their deposit pipelines on Hoodi.

Client teams have published compatible releases for both consensus and execution layers. Operators must upgrade both the beacon nodes and the validator client, review any changes to builder interfaces introduced by enshrined proposer-builder separation, and confirm that deposit-submission logic correctly handles the new credential prefix. The short interval between the public warning and the first public testnet activation underscores why application-layer defenses need to be ready before the mainnet transition window opens.

Enshrined Proposer-Builder Separation Introduces the New Deposit Pathway

Glamsterdam combines the Amsterdam execution-layer changes with the Gloas consensus-layer changes. Its two headlining features are enshrined proposer-builder separation (EIP-7732) and block-level access lists. Under ePBS, builders register on-chain with their own balances and public keys, submit bids, and later reveal execution payloads. The protocol itself handles the payment to the proposer, reducing reliance on external relays. Builder deposits and exits become first-class execution requests, which is why the 0xB0 credential prefix and the temporary queue overlap appear.

The design improves scalability by giving validators more time to process larger payloads and by enabling higher gas limits. At the same time, it creates a new onboarding path for builders that must be carefully distinguished from ordinary validator deposits. The one-time transition mechanics are the source of the temporary ambiguity. Once the network has fully switched, builder deposits travel through their own contract, and the shared-queue risk disappears. The upgrade therefore improves the long-term architecture while requiring short-term vigilance from any service that submits deposits on behalf of users.

Lido’s Earlier Deposit Security Experience Informs the Current Response

Lido encountered deposit front-running risks in prior years and responded by formalizing the Deposit Security Module together with a guardian committee. The committee signs off on deposit-root snapshots; a single guardian can trigger a pause. That infrastructure has already proven useful in other operational incidents. The Glamsterdam case tests whether the same controls correctly recognize the new credential type and the brief period of queue sharing.

Protocols that adopted similar multi-signature or guardian patterns after earlier incidents are better positioned than those that have not yet implemented comparable safeguards. The broader pattern is familiar: protocol upgrades can surface edge cases that application-layer systems must absorb. Because core developers declined a late specification change, the industry must treat pre-deposit validation as a standing requirement rather than an optional enhancement. Teams that already monitor deposit roots and can pause rapidly will face lower operational risk during the transition.

Node Operators and Delegated Stakers Face Concentrated Exposure During the Window

The attack requires a malicious or compromised node operator who can submit a deposit transaction that lands ahead of the legitimate one. Ordinary stakers who simply deposit into a liquid staking protocol are not themselves able to execute the front-run; the risk sits with the operator that ultimately signs or submits the on-chain deposit. Existing activated validators and already-confirmed deposits remain outside the attack surface. Only public keys that still have pending or newly submitted deposits during the transition epoch are exposed.

Delegated stakers should therefore confirm that their chosen protocol has published guidance on deposit handling around the Glamsterdam activation. Operators themselves should audit submission ordering, rate-limit or sequence deposits carefully, and verify that no 0xB0-prefixed deposit can claim a key intended for a standard validator. Because the window is short, a temporary reduction in new deposit throughput or an elevated monitoring posture can close most practical attack paths without long-term disruption to staking operations.

Hoodi Provides the First Live Environment for Deposit Pipeline Testing

The October 26 Hoodi activation is the earliest public opportunity for staking teams to observe the shared-queue behavior under realistic conditions. Protocols can submit test deposits with both ordinary and 0xB0 credentials, measure ordering outcomes, and confirm that their pre-deposit filters reject or quarantine the unwanted path. Client teams have already shipped Hoodi-compatible versions; operators must ensure both execution and consensus clients are updated and that any external builder tooling has been reviewed for the new interfaces.

Successful testing on Hoodi will give the industry higher confidence before the mainnet window opens. Failures or unexpected edge cases discovered on the testnet can still be addressed with application-layer changes or short pauses without requiring a protocol redesign. The short calendar between the public warning and Hoodi activation makes coordinated testing essential.

Responsibility for Mitigation Now Sits With Each Staking Protocol

By closing the consensus-specs issue as not planned, core developers signaled that the temporary risk is best handled at the application layer. Liquid staking providers, solo-operator platforms, and any service that submits deposits on behalf of users must therefore implement their own checks. Providers that already maintain guardian committees or deposit-root attestation processes can extend those processes to cover the 0xB0 prefix. Providers without such infrastructure face a tighter deadline to add equivalent controls.

The distributed model has both advantages and drawbacks. It allows rapid, tailored responses without waiting for a network-wide hard-fork change. It also means that the security of any given staker’s deposit depends on the specific practices of the protocol they chose. Transparency about deposit-handling procedures around the activation epoch will help users evaluate residual risk.

Scaling Goals and Temporary Edge Cases Remain Linked in Ethereum Upgrades

Glamsterdam advances Ethereum’s L1 scaling roadmap by raising the practical gas limit toward 200 million, enabling parallel transaction processing through block-level access lists, and removing external relays from the critical path of block production. Those gains require new on-chain primitives for builders, which in turn create the temporary deposit-queue overlap. The pattern is characteristic of major upgrades: long-term architectural improvements can surface short-lived edge cases that application teams must manage.

The industry’s ability to absorb those edge cases without user-fund losses will influence confidence in subsequent upgrades. Pre-deposit validation, temporary deposit pauses, and clear operator communication are the practical tools available in the present case. Because the risk is confined to a known, short interval, the cost of preparation is finite, and the benefit is the preservation of user deposits through the transition.

Pending Deposits Require Heightened Monitoring Until the Transition Completes

Any public key that still has an unprocessed deposit at the moment the Glamsterdam rules activate sits inside the potential attack window. Protocols can mitigate this by draining or accelerating their deposit queues before the epoch, by rejecting 0xB0 credentials for validator intents, or by pausing new submissions for a brief period surrounding activation. Continuous monitoring of deposit-root changes and public-key claim status during the critical hours will allow rapid response if anomalous activity appears.

Once the fork completes and builder deposits move to their separate contract path, the shared-queue vector closes. The monitoring burden therefore has a clear end date. Teams that treat the transition as a high-attention operational period rather than a routine upgrade will be best positioned to protect staker funds.

🔥 Beyond the Headlines: What KuCoin 5.0 Means for You

Market news moves fast — but where you act on it matters just as much. This October, KuCoin launches KuCoin 5.0, transforming KuCoin into a rebuilt platform. Here's what actually changes for you:

One account for everything. Older platforms split your money across separate "spot," "margin," and "futures" accounts and expected you to understand why. KuCoin 5.0's unified account removes that entirely — deposit once, and everything is simply there (only available to VIPs for now).
Stocks, indices, and commodities. KuCoin 5.0 expands beyond crypto into global markets. When crypto chops sideways and equities rally (or the reverse), you rotate in minutes instead of opening a brokerage account and waiting days for fiat rails.
Real-world assets (RWA). Tokenized exposure to traditional assets like commodities, right inside your crypto account. One of the fastest-growing segments in global finance is no longer reserved for institutions — you access it from the same balance you trade with.
Earn while you learn. Not ready to trade? KCUSD lets your stablecoins earn daily, auto-compounding interest. The lowest-stress way to put your idle deposit to work for 4% yield.
An AI assistant in plain language. Ask questions, get market context, understand what you're looking at — built into the platform, no jargon required.
An app that doesn't overwhelm. Faster, cleaner, and consistent — intuitive from the first tap, not after a tutorial.
Safety you can check, not just trust. A MiCAR-licensed EU entity, Proof of Reserves you can verify yourself, and internationally certified security (SOC 2 Type II, ISO 27001:2022).

Create your account in minutes — and start on the platform built for where crypto is going, not where it's been.

FAQs

What exactly is the Glamsterdam upgrade, and why does it matter for staking?

Glamsterdam is the combined name for the Amsterdam execution-layer and Gloas consensus-layer changes. Its primary goals are enshrined proposer-builder separation and block-level access lists that support higher gas limits and more efficient block processing. For staking, the introduction of on-chain builder registration and the associated deposit pathway creates the temporary queue-sharing behavior that underlies the front-running risk.

How long does the deposit-hijack window last?

The window exists only while builder deposits still travel through the validator deposit queue. That condition holds during the hard-fork transition itself. After the upgrade completes, builder deposits are processed through a separate contract, closing the shared-queue path. The practical duration is therefore measured in the hours surrounding the activation epoch rather than in days or weeks.

Does the risk affect already-activated validators or existing staked ETH?

No. The attack targets new or still-queued deposits for public keys that have not yet produced an active validator. Existing validators and their balances remain under their established withdrawal credentials and are outside the described attack surface.

What can ordinary stakers do to protect themselves?

Stakers who deposit through a liquid staking protocol should confirm that the protocol has published specific guidance on deposit handling around the Glamsterdam activation. Choosing a provider that already operates multi-party deposit security or guardian-style oversight reduces residual risk. Stakers who run their own validators should ensure their deposit submission logic does not allow a competing 0xB0 deposit to claim the same public key.

Why did core developers decline a protocol-level fix?

The proposal for pre-deposit checks was closed as not planned largely because of schedule pressure. Sepolia had already activated under the existing rules, and Hoodi client releases were advancing. A late behavioral change would have risked additional testnet redeployments and delays. Developers judged that application-layer mitigations were sufficient given the limited duration of the exposure.

Disclaimer: This content is for informational purposes only and does not constitute investment advice. Cryptocurrency investments carry risk. Please do your own research (DYOR).