Don't want to trade it yourself?
Our desk runs DEX portfolios on profit share.
Currencies38857
Market Cap$ 2.76T+1.26%
24h Spot Volume$ 37.42B+8.54%
DominanceBTC57.67%-0.03%ETH10.92%+0.43%
ETH Gas0.06 Gwei
EthereumFeaturedStakingGovernanceEthereum FoundationQuantum
Aug 27, 2026
2min read
byLiam ‘Akiba’ Wright
forCryptoSlate
Ethereum developers opened PR #12235 (draft EIP-9999) on Aug. 24 proposing a flexible staking deposit contract that adds a scheme identifier and variable-length public key and metadata fields (capped at 8,192 bytes) to admit future post-quantum validator keys and introduces three one-way modes: disabled, BLS enabled, and BLS retired. The proposal supports protocol security and long-term staking adoption under Ethereum’s post-quantum roadmap (leanXMSS/leanVM, ~2029 target) but requires further credential specs and coordinated execution/consensus forks and may raise throughput and signature-size tradeoffs that impact DeFi costs and network adoption.
See what traders are focused on
Ethereum developers have opened an early proposal to make the staking deposit system flexible enough to accept future quantum-resistant validator keys, and it would also give a later network upgrade a one-way switch to stop new deposits using today’s BLS format.
The change would affect how new validators enter Ethereum, creating an entry path for future credential formats. Yet, those formats and the rules for verifying them still have to be designed and adopted separately.
Pull request #12235 was opened Aug. 24 and remained an unmerged Draft as of Aug. 26, with its working file still using the placeholder number 9999. An Ethereum EIPs editor suggested assigning 8394, but the proposal has not been published or accepted as EIP-8394.
How the deposit switch would work
Ethereum’s staking deposit contract is the entry point that receives a prospective validator’s funds and credential data. The current path expects public keys and signatures in fixed BLS12-381 formats.
The draft specification instead adds a scheme identifier and variable-length fields for the public key and credential metadata, each capped at 8,192 bytes.
Ethereum’s execution layer can record a deposit while its consensus layer decides whether the credential is valid and can create or update a validator. Under the proposal, the contract would carry non-BLS credentials as opaque data, meaning it would transport the bytes without checking the new cryptography.
The draft defines three contract modes: disabled, BLS enabled, and BLS retired. Those transitions only move forward, and once a protocol-controlled system call activates the retired mode, the new contract would reject BLS deposits and could not later switch BLS onboarding back on.
The proposal says deposits that entered the pending queue before the retirement boundary would remain eligible for normal processing under the current consensus framework.
A future credential-scheme proposal would still need to define signature validation, validator-state representation, top-ups, duplicate handling, uniqueness, and key replacement. Activating the deposit path would itself require a coordinated execution- and consensus-layer fork.
Ethereum’s post-quantum roadmap pairs the hash-based validator signature scheme leanXMSS with leanVM, which is intended to aggregate much larger post-quantum signatures efficiently, and separates key registration, signature verification, attestations, and full aggregation into staged milestones.
Ethereum says no quantum computer can threaten its cryptography today, and its approximately 2029 target is a planning goal.
The deposit proposal is one piece of migration infrastructure, specifying how the network could eventually admit new validator-key formats and close BLS onboarding for good.
Source: cryptorank.io