Ethereum’s New Deposit Contract Could Open Staking to Post-Quantum Keys

Ethereum developers have put forward a new validator deposit contract designed to do something the current system cannot: carry the much larger and more flexible credentials that a post-quantum staking system may eventually require.

The proposal is still a draft. It does not choose Ethereum’s future cryptography, schedule a fork, or switch off today’s BLS signatures.

But it builds a migration lane into one of the most important gateways in the network—the contract every new validator uses to enter staking.

That makes this more than a theoretical quantum-computing discussion. It is an attempt to remove a hard technical constraint before Ethereum needs to make the cryptographic decision itself.

The current deposit contract has a fixed-size problem.

As the draft proposal in Ethereum’s EIP repository explains, the existing validator deposit contract is built around BLS12-381. Its public keys are fixed at 48 bytes, while the associated signature metadata is fixed at 96 bytes, dimensions embedded in the current contract interface and carried through the validator-onboarding path.

The new design introduces an explicit scheme identifier so execution clients can carry different credential formats without guessing their meaning from length alone.

Those dimensions work for Ethereum’s current proof-of-stake system. They leave little room for post-quantum signature systems, which can require dramatically larger keys or signatures.

The replacement contract would accept public keys and credential metadata up to 8,192 bytes each. Every deposit would also declare a credential scheme.

Scheme zero would preserve the existing BLS path, while future Ethereum upgrades could assign other scheme numbers to new forms of validator credentials.

The draft also removes the old deposit contract’s Merkle-tree machinery because Ethereum’s newer request system already carries deposit data from execution to consensus. Deposits would be emitted in transaction order, preserving a canonical sequence while giving consensus rules—not the contract—the job of validating each credential scheme.

In plain English, the contract would stop assuming that every Ethereum validator key must always look like today’s key.

Is crypto prepared for the quantum threat?

Recently, legendary cryptographer @danboneh broke down the massive challenge of post-quantum (PQ) signatures for blockchains.

Let’s summarize the findings about hash-based signatures, SHRINCS, and the threshold problem. 🧵👇

— Thomas Coratger (@tcoratger) August 24, 2026

An irreversible off-ramp for BLS.

The draft lays out three operating modes: deposits disabled, BLS deposits enabled, and BLS deposits retired. A protocol-level system call would activate the new contract.

A later system call could permanently stop it from accepting new BLS validators.

That retirement step is deliberately one-way. Once Ethereum crosses the line, the proposal says BLS onboarding cannot be re-enabled by a later call.

The old deposit contract creates a complication because it is immutable. Even after retirement, it could still receive ETH.

Under the proposed design, however, execution clients would stop converting those late legacy deposits into validator requests. Wallets, staking providers, and launchpads would therefore need to move users away from the old route before the cutoff.

That is one reason this cannot be slipped into production as a small contract update. The current reporting from Decrypt notes that the draft still has undecided activation details, while the proposal itself requires coordinated changes across Ethereum’s execution and consensus layers.

The pull request opened on August 24 and remains under review. Its proposed contract address, deployment bytecode, request-type assignment, activation timestamp, and BLS retirement timestamp are all marked “TBD,” making the document a technical starting point rather than a scheduled network change.

The migration period would keep both the legacy and replacement routes working for BLS deposits before retirement. After retirement, pending deposits already admitted to consensus could continue through normal processing, but new legacy-contract deposits would no longer become validator requests.

The proposal builds capacity, not a finished quantum defense.

The most important caveat is also the most reassuring: this draft does not claim Ethereum has solved post-quantum signatures.

It gives the deposit pipeline room to carry a future credential. The validation rules, identity model, duplicate handling, key replacement, and other requirements for that credential would come in a separate proposal.

That distinction matters because post-quantum cryptography involves real tradeoffs. Stateless hash-based signatures can be large.

Smaller stateful systems can become dangerous if a signing counter is reused. Threshold designs—essential for many professional validator setups—add another layer of complexity.

Goodbye, Poseidon!

An epic 8-year, 8-figure rabbit hole in post-quantum cryptography reaches its dream conclusion. The Ethereum Foundation is abandoning Poseidon for L1, pivoting to SHA or BLAKE. This milestone unlocks ultimate security for lean Ethereum and foreshadows a golden…

— Justin Drake (@drakefjustin) August 13, 2026

Ethereum’s broader research direction is moving toward familiar hash functions and STARK-based proofs. Vitalik Buterin’s “Extremely Lean Chain” research post describes one possible architecture in which validators use compact onchain state while carrying more of the proof burden themselves.

That design would replace a long-lived validator record with a much smaller state entry built around an effective balance and deposit-tree index. Validators would periodically prove participation and balance updates with STARKs, while signature aggregation would keep the proof volume manageable at network scale.

The same research explores hash-based signatures, rotating validator keys, and privacy improvements. It remains research rather than an adopted roadmap, but it shows why the deposit layer needs flexibility: Ethereum’s future validator credential may differ sharply from the fixed BLS object the current contract expects.

None of that is finalized. The deposit-contract proposal is valuable precisely because it does not force the network to settle every cryptographic question today.

It creates a flexible door that future credentials can fit through.

What ETH holders should watch next.

For ETH holders, no imminent staking change follows from this draft, and current validators are not about to be shut out. The proposal is open, its key deployment values remain undecided, and any activation would require a future network upgrade.

The next meaningful signals will be review from Ethereum’s EIP editors and core developers, agreement on how the new request format fits into a fork, and eventually a separate credential proposal that defines the actual post-quantum signature system.

Still, the direction is clear. Ethereum developers are moving quantum readiness out of the white-paper stage and into the plumbing that would make a real migration possible.

That is early work—but in cryptography, early is exactly when infrastructure changes are supposed to begin.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.