A pull request opened on August 24th, PR #12235, sits unmerged in the go-ethereum repository. It carries a placeholder number, 9999, in its working file. This is the proposed change to Ethereum's staking deposit contract, and it is not a new signature scheme. It is not a new proof system. It is a structural admission: the current BLS12-381 credential format is a dead end, and the protocol needs a new door before it can build a new lock.
Most commentary on this will focus on the word 'quantum.' That is a mistake. The cryptographic threat is real, but it is a distant one. The immediate engineering problem is more mundane: the deposit contract, the single entry point for all new validators, is hardcoded to a specific signature scheme. To change the scheme later, you would have to break the entry point. This proposal is an attempt to make the entry point scheme-agnostic before that becomes a crisis.
I have spent the last few years auditing smart contracts and studying ZK proof systems. When I see a proposal that deliberately defers the core cryptographic details, my first instinct is suspicion. But after tracing the logic of this design, I think the deferral is not a flaw. It is the point. The proposal is not trying to solve post-quantum security today. It is trying to create the conditions under which that solution can be adopted without a hard fork that destroys the staking ecosystem.
The Current Bottleneck
Ethereum's deposit contract is a one-way door. A user sends 32 ETH and a BLS public key to the contract, and that data is committed to the beacon chain. The validator's identity, for the life of that stake, is tied to that BLS key. BLS12-381 is an efficient scheme, particularly for aggregation, which is why it was chosen. But it is not post-quantum secure. Shor's algorithm, running on a sufficiently large quantum computer, would break the elliptic curve discrete logarithm problem that underpins it.
The timeline for that is uncertain. The Ethereum Foundation's own research suggests a target around 2029 for having a plan in place. That is not a prediction of when a quantum computer will exist. It is a prediction of when the risk becomes too large to ignore, given the lead time required to migrate a live network with hundreds of thousands of validators.
The problem is structural. You cannot simply swap BLS for a post-quantum scheme like a hash-based signature. The deposit contract expects a 48-byte BLS public key. A hash-based signature public key is a different size, a different format, and requires different verification logic. The entire validator lifecycle, from deposit to withdrawal, is built around the BLS assumption.
The Proposal: A Flexible Credential Format
The new proposal, which will likely become EIP-8394, introduces a variable-length credential field. The current fixed 48-byte BLS format is replaced by a field that can hold up to 8,192 bytes. This is a significant increase in data capacity. It is also a significant increase in complexity.
The proposal defines three modes for the deposit contract. The first is 'disabled,' which is the current state. The second is 'BLS enabled,' which maintains the status quo. The third is 'BLS retired,' which is the end state. The key design decision is that the switch from 'BLS enabled' to 'BLS retired' is one-way. Once BLS is retired, it cannot be re-enabled.
This is a deliberate signal. It tells the ecosystem that the migration is not a parallel support structure. It is a transition. The core developers are not planning to support both schemes indefinitely. They are planning to move to a new scheme and leave BLS behind.
The proposal treats non-BLS credentials as 'opaque data.' The deposit contract does not attempt to verify the signature or the format of the new credential. It simply stores the data. This is a critical design choice. It means the security of the new credential format is not defined by this proposal. It will be defined by a future proposal, likely one that specifies a scheme like leanXMSS, a hash-based signature scheme, and leanVM, a virtual machine for aggregating and verifying these signatures.
This is where the proposal gets interesting from a security perspective. By treating the new credentials as opaque, the proposal avoids making any security assumptions about them. The deposit contract is not a security boundary for the new scheme. It is a data storage mechanism. The actual verification will happen in the consensus layer, after the new scheme is fully specified and implemented.
The Trade-Off: Flexibility vs. Uncertainty
This design has a clear benefit: it decouples the deposit contract from the cryptographic details. This means the deposit contract can be upgraded now, without waiting for the final post-quantum scheme to be chosen. It also means that if the chosen scheme needs to be tweaked, the deposit contract does not need to be changed again.
The cost is uncertainty. The proposal creates a framework, but the framework is empty. The signature verification logic, the state representation, the aggregation mechanism, all of these are undefined. This is a risk. A future proposal could specify a scheme that is inefficient, insecure, or both. The framework would then be a trap, not a solution.
Based on my experience auditing smart contracts, I can say that this is a common pattern in protocol design. You create an abstraction layer to isolate a known problem, but you defer the solution to the unknown problem. This is often the right call, but it requires discipline. The team must resist the urge to fill the framework with a half-baked solution just to show progress.
The 8,192-byte limit is another point of concern. It is generous, but it may not be sufficient for all post-quantum signature schemes. Some schemes have very large public keys or signatures. If a future scheme exceeds this limit, the deposit contract will need another upgrade. This is not a fatal flaw, but it is a sign that this proposal is a temporary measure, not a final destination.
The Coordination Problem
This proposal is not just a smart contract change. It requires a coordinated fork across both the execution layer and the consensus layer. The deposit contract lives on the execution layer, but the validator credentials are used on the consensus layer. Any mismatch between the two layers could lead to a network split or, worse, a loss of funds.
This is the kind of change that requires extensive testing on public testnets. It also requires a clear communication plan for the ecosystem. Staking services, liquid staking protocols, and individual validators all need to understand the timeline and the implications.
The proposal is still in its early stages. It is a draft PR, not a formal EIP. It has not been through the full review process. This means the details could change. The three-mode design could be simplified. The byte limit could be adjusted. The timeline for the BLS retirement could be pushed back.
The Contrarian View: The Real Risk Is Not Quantum
The narrative around this proposal will be about quantum computers. That is the hook. But the real risk is not a quantum attack. The real risk is a governance failure.
The proposal is a bet that the Ethereum community can agree on a post-quantum scheme within the next few years. This is not a trivial bet. The choice of a signature scheme involves trade-offs between security, performance, and complexity. Different stakeholders will have different priorities. Validators will want efficiency. Security researchers will want conservative assumptions. Application developers will want compatibility.
I have seen this play out before. The transition from Eth1 to Eth2 was delayed multiple times, not because of technical challenges, but because of governance disagreements. The same could happen here. The framework could sit empty for years while the community debates the details.
There is also a subtler risk. By creating a flexible framework, the proposal may encourage a false sense of security. People may assume that Ethereum is 'post-quantum ready' because the deposit contract has been upgraded. This is not true. The deposit contract is just the entry point. The entire validator ecosystem, including the consensus layer, the networking layer, and the client software, will need to be updated to support the new scheme. That is a much larger project.
The Takeaway: Watch the Signals, Not the Hype
The market impact of this proposal is negligible. It does not change the supply of ETH, the staking yield, or the gas costs. It is a long-term infrastructure play. The value is in the optionality it creates.
For developers and infrastructure providers, this is a signal to start planning. If you are building a staking service or a validator client, you should be thinking about how to support a future credential format. The transition will not happen overnight, but it will happen. The one-way switch is a commitment.
For the rest of us, the takeaway is simpler. Zero knowledge isn't magic; it's math you can verify. The same applies to protocol upgrades. This proposal is not a solution. It is a placeholder for a solution. The real work is still ahead. The question is not whether Ethereum can build a post-quantum signature scheme. The question is whether the community can agree on one before the clock runs out.
I don't have an answer to that question. But I know that the clock is ticking, and this proposal is the first real step towards answering it. The framework is sound. The execution will be the test.