TL;DR
- An Ethereum Research post proposes SPHINCS-, a stateless post-quantum signature verification scheme optimized for the EVM.
- The design replaces standard SHAKE256 functions with EVM-native KECCAK256, allowing a Solidity implementation without protocol changes or precompiles.
- The C13 variant is described as verifying at about 127,000 gas with a 3,704-byte signature.
- The proposal is non-standard and research-stage, but it adds to Ethereum’s growing post-quantum security conversation.
Ethereum researchers are exploring a new post-quantum signature design that could allow wallets to verify quantum-resistant signatures directly on the Ethereum Virtual Machine without requiring protocol changes.
The proposal, published on Ethereum Research on June 12, introduces SPHINCS-, pronounced as “SPHINCS minus,” as an efficient stateless post-quantum signature verification scheme designed for EVM compatibility. The post credits nicocsgy as author and includes special thanks to Vitalik Buterin and other contributors.
Post-Quantum Signatures For Ethereum Wallets
The basic problem is that today’s blockchain wallets rely on cryptographic assumptions that could eventually be weakened by sufficiently powerful quantum computers. That threat is not immediate, but Ethereum researchers and cryptographers are increasingly discussing how accounts could migrate to quantum-resistant signature schemes over time.
SPHINCS- is designed around a practical constraint: it should work inside the EVM as it exists today. Instead of requiring new precompiles or protocol-level changes, the proposal replaces standard SLH-DSA hash functions such as SHAKE256 with KECCAK256, which is native to Ethereum.
That design choice allows the verification logic to be implemented in Solidity. In other words, the proposal is not asking Ethereum to change its base protocol immediately. It is exploring how far post-quantum wallet verification can be pushed using existing EVM tools.
Lower Signature Budget, Lower Costs
The post also scales down the signature budget to a range more relevant for blockchain wallets. Instead of targeting the standard 2^64 signatures per key, SPHINCS- focuses on a budget between 2^14 and 2^20 signatures per key.
The argument is that normal Ethereum addresses do not need an astronomical number of signatures. The post says the average annual 99.9th percentile of Ethereum transactions is around 431 per address since the Merge, which suggests wallet-specific parameters can be more efficient than broad general-purpose standards.
For its C13 variant, the proposal reports verification costs of about 127,000 gas and a signature size of 3,704 bytes. It compares that with standard SLH-DSA-SHA2-128-24, which the post says costs 142,000 gas with a 3,856-byte signature and requires about 1.07 billion hash calls for signing.
Still Research, Not A Standard
The proposal is careful to note trade-offs. SPHINCS- is non-standard and does not strictly match FIPS 205 parameters because it uses Keccak and limited signing budgets. That means it should be treated as research rather than a finished Ethereum account standard.
There are also practical wallet constraints. The post says C11 and C12 variants are compatible with hardware wallets, but signing times on an ST33K1M5 secure element are listed at 390 seconds and 47.5 seconds respectively. That highlights the gap between theoretical verification efficiency and real user experience.
Even so, the direction is important. Ethereum’s long-term account security will likely require multiple approaches, including new signature schemes, account abstraction tools, migration paths and better wallet UX.
Why It Matters
Post-quantum security is still a future-facing issue, but blockchain networks cannot wait until quantum attacks are practical before thinking about migration. Wallet upgrades, standards, user education and ecosystem coordination can take years.
SPHINCS- does not solve that entire problem. But it gives Ethereum researchers another concrete design to test: a stateless, EVM-native, post-quantum verification path that may work without waiting for base-layer changes.
