Ethereum Researchers Say Wallets Can Go Quantum-Safe Without Touching the Protocol

Here’s a surprise. A new post-quantum signature scheme for Ethereum wallets runs entirely inside the network as it exists today: no base-layer changes, no new precompiles, no hard fork required. It slots into ordinary Solidity code. That’s the pitch behind SPHINCS- (pronounced “SPHINCS minus”), a design published on the Ethereum Research forum on June 12, 2026 by an author going by nicocsgy (Nicolas Consigny, a coordinator and privacy researcher at the Ethereum Foundation), with thanks credited to Vitalik Buterin and others.

Do note that this is a research-stage forum proposal, not a shipped feature and not a standard. Nobody’s wallet is running it. The numbers below are what the author measured and modeled, and the whole post lives one link deep on ethresear.ch, exactly where Ethereum’s cryptography debates happen before anything becomes tangible.

The problem is patient, and that’s what makes it dangerous

Ethereum wallets currently sign transactions using elliptic-curve cryptography. That works because reversing the math is infeasible for classical computers. A large enough quantum computer running Shor’s algorithm would make that math tractable, which means a future machine could forge signatures and drain addresses whose public keys are already exposed on-chain.

That machine doesn’t exist yet. The threat is a timeline, not a present day event. Ethereum’s response has progressed on multiple fronts: from signature schemes to account abstraction to migration planning, and the Foundation created a dedicated post-quantum team earlier this year. You can read how Ethereum framed quantum as an imminent threat when it launched that group.

Coordinating security changes across millions of users takes years. That’s why people are building migration paths now, before anyone needs one.

How SPHINCS- fits through the door that’s already open

SPHINCS is a well-studied family of hash-based signatures. Its security rests on hash functions being one-way, which is a property quantum computers don’t break the way they break elliptic curves. The standardized version, SLH-DSA under FIPS 205, uses hash functions like SHAKE256.

The Ethereum Virtual Machine (EVM) doesn’t support SHAKE256 cheaply. It supports KECCAK256 natively, which is already available in every contract. The proposal swaps the hash function for the one the EVM already runs, allowing verification to happen in plain Solidity without asking the protocol for special treatment.

The second change is tightening the signing budget. The full standard targets 2^64 signatures per key, which is an astronomically high ceiling. SPHINCS- argues wallets don’t need that. It targets a range between 2^14 and 2^20 signatures per key, citing that the 99.9th-percentile Ethereum address has averaged about 431 transactions per year since the Merge. Smaller signing budgets mean smaller signatures and cheaper verification. For background on why hash-based schemes keep coming up, this explainer on quantum-resistant tokens lays out the mechanics.

The measured numbers, and where they hurt

For its C13 variant, the proposal lists verification at about 127,000 gas with a signature size of 3,704 bytes. It compares that to SLH-DSA-SHA2-128-24, which the post puts at 142,000 gas, a 3,856-byte signature, and around 1.07 billion hash calls to sign. On paper, SPHINCS- is cheaper and smaller.

Verification is only half the story. Signing is where the pain lives. The C11 and C12 variants are described as hardware-wallet compatible, but signing times on an ST33K1M5 secure element are listed at 390 seconds and 47.5 seconds. Waiting six and a half minutes to sign a single transaction is not an experience users will tolerate.

The author doesn’t hide this. From the ethresear.ch post, Consigny writes, “verification efficiency alone does not solve user experience.”

That line is important: cheap on-chain verification is useless if the device in your pocket takes minutes to produce a signature.

What this is, and what it isn’t

SPHINCS- is a forum proposal with benchmarks, published for critique. It doesn’t follow FIPS 205, because it uses Keccak and caps the signing budget, so it deliberately sits outside the standardized family. It has no audit, no reference implementation in production, and no adoption. The hardware-wallet signing times remain the open obstacle the author calls out.

What it does demonstrate is narrower but useful: you can express stateless post-quantum verification inside today’s EVM at a gas cost wallets could plausibly pay, without waiting for a protocol upgrade. That’s a genuine data point for Ethereum’s quantum-safe roadmap toward 2029, and it fits the pattern of stress-testing designs early.

The verification math is true and measured. Everything else, including the signing speed, standardization, and actual deployment, is still a problem waiting to be solved.