Post-Quantum Signatures on the EVM: Can Ethereum Be Quantum-Proofed for $0.07?

TL;DR

• On June 13, 2026, Nicolas Consigny proposed adding opt-in post-quantum account protection to Ethereum for as little as $0.07, without a hard fork. 
• The mechanism is account-level: it uses smart-account patterns and Solidity verifier contracts, adapting NIST‘s SPHINCS+ into a lighter variant the proposal calls SPHINCS-.
• This is not a protocol-wide migration. One optimized variant verifies at roughly 127,000 gas with a 3,704-byte signature, and the work includes a Lean 4 formal proof.
• Consigny framed the design as a bridge toward a future system, leanSPHINCS, that would lower costs further through signature aggregation. 
• The realistic scenario is that current quantum hardware is far from breaking 256-bit keys, so this is preparation for a multi-year horizon.
• For institutions staking on public proof-of-stake chains, the same long-horizon logic applies to staked-asset security. 

Why post-quantum, why now

Today’s Ethereum and Bitcoin accounts rely on ECDSA signatures tied to elliptic-curve cryptography. A sufficiently large quantum computer running Shor’s algorithm could derive a private key from its public key, threatening both chains at the signature layer.

The June 13, 2026 proposal was included into a broader Ethereum roadmap that already names privacy, security, and post-quantum work as technical priorities. Ethereum developers have discussed a Post-Quantum Public Key Registry and upgrades targeted between 2026 and 2029.

Institutional attention has sharpened the timing. On June 9, 2026, BlackRock characterized quantum as a manageable but serious long-term risk requiring proactive migration.

The threat remains theoretical for now. In April 2026, Project Eleven awarded its Q-Day Prize to a researcher who broke a 15-bit elliptic-curve key on a quantum computer, far below the 256-bit keys securing live accounts.

What Consigny actually proposed

Consigny proposed account-level, opt-in post-quantum protection that wallet teams or users can deploy without a hard fork. The design works through smart-account patterns and Solidity verifier contracts on the existing EVM, not through a new precompile or consensus change.

The variant, called SPHINCS-, is adapted from SPHINCS+ and tuned for on-chain verification cost. A central change replaces the standard SHAKE256 hashing function with KECCAK256, Ethereum‘s native primitive, which the EVM computes efficiently.

What the proposal is and is not:

• It is account-level protection a user can opt into.
• It is deployable today through smart-contract logic.
• It is not a protocol-wide migration.
• It is not a replacement for future consensus-level work.

Consigny credited contributors including Ethereum co-founder Vitalik Buterin, researcher Justin Drake, and members of Ethereum‘s cryptography team.

SPHINCS+ to SPHINCS- to leanSPHINCS

The proposal sits in a three-stage progression from a standardized base toward an aggregated future design. SPHINCS+ is the hash-based signature standard NIST published as FIPS 205 in August 2024, later named SLH-DSA.

• SPHINCS+ is stateless, meaning no state is tracked between signatures, but its signatures are large and expensive to verify on-chain. 
• SPHINCS- reduces that verification burden while preserving the stateless property, making it practical for a smart contract.

The C13 variant verifies at roughly 127,000 gas with a 3,704-byte signature. The work also carries a Lean 4 formal proof via Verity, which provides machine-checked assurance of the verifier logic.

leanSPHINCS is the future bridge target. It aims to reduce costs further through signature aggregation, with one architecture suggesting verification could eventually fall toward 3,000 gas through off-chain proof aggregation.

Stage	Role	Status
SPHINCS+	NIST FIPS 205 standard	Standardized Aug 2024
SPHINCS-	EVM-optimized, account-level	Research proposal, June 2026
leanSPHINCS	Aggregation-based future design	Direction, not deployed

The $0.07 claim in context

The $0.07 figure is an estimate per account under current conditions, not a fixed price. It reflects the C13 variant’s verification cost of about 127,000 gas multiplied by gas price and ETH price at the time Consigny posted on June 13, 2026.

Because gas price and ETH price both move, the dollar figure moves with them. A congested network or a higher ETH price would raise the cost above $0.07; quieter conditions would lower it.

The figure covers the on-chain verification of one post-quantum signature. It does not represent a one-time payment that permanently quantum-proofs an account, nor does it cover wallet integration, audits, or tooling work still in progress.

Quantum-resistant blockchains: the broader picture

Post-quantum cryptography on blockchains centers on replacing signature schemes vulnerable to Shor’s algorithm with quantum-safe alternatives. Two families dominate NIST‘s standardized set: lattice-based ML-DSA (FIPS 204) and hash-based SLH-DSA/SPHINCS+ (FIPS 205).

Hash-based schemes such as SPHINCS+ draw their security from the strength of cryptographic hash functions rather than the mathematical assumptions behind lattice systems. NIST originally selected SPHINCS+ as a backup candidate, included in case lattice-based ML-DSA proves vulnerable.

That backstop role carries into Ethereum‘s calculus. A hash-based account verifier hardens against a wider class of failure modes than a single-algorithm approach.

The validator-readiness side of this question, covering Shor’s algorithm and broader PQC migration, is examined in the Everstake read on whether today’s validators are quantum ready.

Account-level vs protocol-wide protection

Account-level protection is opt-in and lives in smart-contract logic, while protocol-wide protection would change the rules every node enforces. Consigny‘s proposal is the former: an individual account or wallet team adds the SPHINCS- verifier without any network coordination.

Making post-quantum signatures a protocol-wide default would require changes to Ethereum‘s consensus rules, broad client updates, and a coordinated hard fork.

Account abstraction, which lets wallets define how transactions are approved, gives users a path to add SPHINCS- protection before any default exists.

The main differences:

• Opt-in account protection: deployable now, no coordination, user-driven.
• Protocol-wide default: requires a hard fork, client updates, and ecosystem-wide review.

What this means for validators and staked-assets

The same multi-year quantum-preparation logic that applies to user wallets applies to validator keys. Validators sign with cryptographic keys, and institutions staking across multi-year horizons have a direct interest in how those keys are secured and migrated.

Accounts holding large balances, such as institutional treasuries, custodians, and sizeable staking positions, can adopt account-level quantum-resistant protections before they become the protocol-wide default.

Ethereum validators sign consensus messages with BLS12-381 keys, hardening those is a protocol-level concern, addressed by upgrades like the hash-based consensus signatures on Ethereum’s roadmap, not by an account-level opt-in.

Treasuries, custodians, and large staking positions could use an account-layer approach like SPHINCS- to protect withdrawal credentials ahead of any default, while validator signing keys migrate through consensus-layer upgrades the whole network adopts together. 

For staked assets, that readiness depends on who controls the keys and how the infrastructure is designed to absorb a future cryptographic transition.

Everstake runs non-custodial infrastructure, so the staker retains control of withdrawal keys rather than handing custody to an operator. 

The long-horizon framing matters for any institution holding positions across years. Preparing validator infrastructure ahead of a default is the same posture Consigny‘s proposal takes at the account layer.

Reality check: how far off is the quantum threat

Current quantum hardware is far from breaking the 256-bit keys that secure live accounts. The April 2026 Q-Day Prize demonstration broke a 15-bit elliptic-curve key, which is many orders of magnitude below production strength.

What is “possible in a lab” and “deployable as a default” is the central point. Breaking a toy key proves the method works; breaking a real key requires quantum computers far larger and more stable than anything that exists today.

This is why Consigny and others frame the work as preparation, not panic. Building optional, deployable defenses now lets adoption grow gradually as efficiency improves, rather than forcing a rushed migration later.

Everstake has onboarded staking for over 130 networks, we track every change across the ecosystem so our infrastructure stays ready for shifts like this one as they unfold. 

FAQ

What is post-quantum protection on Ethereum?

Post-quantum protection on Ethereum means securing accounts against future quantum computers that could break today’s ECDSA signatures. 

Is this a hard fork?

No, the SPHINCS- proposal does not require a hard fork. It deploys through smart-account patterns and Solidity verifier contracts on the existing EVM, so individual accounts can opt in without any network-wide upgrade.

What is SPHINCS+?

SPHINCS+ is a stateless hash-based signature scheme that NIST standardized as FIPS 205 in August 2024, later named SLH-DSA. Its security depends on cryptographic hash functions rather than the lattice assumptions used by ML-DSA.

Can Ethereum be quantum-proofed for $0.07?

A single account can add opt-in post-quantum signature verification for roughly $0.07 under current conditions, per Consigny‘s June 13, 2026 proposal. The figure is gas-dependent and applies to account-level protection, not a protocol-wide migration.

What is leanSPHINCS?

leanSPHINCS is a future variant using a ZK-friendly hash function suited to zkEVM constraints combined with protocol-level STARK aggregation, frame-level verification could fall to roughly 3,000 gas.

Is quantum computing a threat to Ethereum today?

No, current quantum hardware cannot break the 256-bit keys securing Ethereum accounts. The April 2026 Q-Day Prize broke only a 15-bit key, so the SPHINCS- work is preparation for a multi-year horizon.

Why use KECCAK256 instead of SHAKE256?

SPHINCS- swaps the standard SHAKE256 hashing function for KECCAK256, Ethereum‘s native primitive. The EVM computes KECCAK256 efficiently, which lowers the on-chain verification cost enough to reach the 127,000 gas range for the C13 variant.

Does this affect staked ETH and validators?

The proposal targets account signatures, not validator keys directly, but the multi-year preparation logic applies to both. 

Disclaimer

This article is for informational purposes only. Nothing in this content constitutes legal, financial, or tax advice. Mentions of specific projects, platforms, or companies are for illustrative purposes only and do not constitute an endorsement. Consult qualified legal, financial, or tax professionals before making decisions based on the information presented.