-0.13%
-0.97%
-2.80%
-2.54%
-2.13%
-1.73%
What the Proposal Aims to Do
The core objective of SPHINCS minus is to enable Ethereum wallets to verify quantum-resistant signatures, addressing a long-term vulnerability where powerful quantum computers could compromise current cryptographic assumptions. By integrating a new signature design, the network aims to preemptively protect user assets and transaction integrity.
The proposal was published on Ethereum Research on , crediting nicocsgy as the author, with notable contributions from Vitalik Buterin and others. It forms part of a broader effort to secure the blockchain’s future against advanced computational threats.
How SPHINCS Minus Works
SPHINCS minus is specifically engineered to be compatible with the current EVM architecture, avoiding the need for complex precompiles or alterations to the base Ethereum protocol. Three design principles stand out.
Hash function adaptation: The scheme replaces standard SLH-DSA hash functions, such as SHAKE256, with KECCAK256. This matters because KECCAK256 is already native to Ethereum and can be directly used in Solidity verification logic.
Optimized signature budget: Rather than targeting the broad standard of 2^64 signatures per key, SPHINCS minus narrows the budget to between 2^14 and 2^20 signatures per key. This adjustment is grounded in real usage data: the average annual 99.9th percentile of Ethereum transactions has sat around 431 per address since the Merge, which supports tighter, wallet specific parameters.
EVM integration: The design prioritizes seamless integration with the existing EVM so the verification scheme can be implemented without disruptive protocol changes, aiming for a smoother transition to quantum resistant signatures.
The C13 Variant by the Numbers
The C13 variant of SPHINCS minus offers a useful look at how it performs against existing standards.
| Specification | C13 (SPHINCS minus) | SLH DSA SHA2 128 24 |
|---|---|---|
| Verification Cost | ~127,000 gas | ~142,000 gas |
| Signature Size | 3,704 bytes | 3,856 bytes |
| Hash Calls (Signing) | Not specified | ~1.07 billion |
| Hash Function | KECCAK256 | SHAKE256 |
| Signing Budget | 2^14 to 2^20 signatures/key | 2^64 signatures/key |
The C13 variant edges out the comparison standard on both gas cost and signature size, while relying on a hash function that’s already built into Ethereum.
Where the Challenges Remain
The theoretical framework is solid, but practical implementation still has hurdles. The most pressing one involves hardware wallets.
Hardware wallet compatibility: The C11 and C12 variants are described as compatible with hardware wallets, but signing times on an ST33K1M5 secure element run long, listed at 390 seconds for C11 and 47.5 seconds for C12. Efficient verification alone doesn’t solve the user experience problem for hardware backed transactions.
FIPS 205 deviation: The SPHINCS minus design doesn’t strictly follow FIPS 205 standards, mainly because of its use of Keccak and its limited signing budgets. This is a deliberate trade off made to optimize for the Ethereum environment specifically.
What Comes Next
SPHINCS minus represents one piece of Ethereum’s broader push toward post-quantum security, alongside ongoing work on new signature schemes, account abstraction, migration planning, and wallet design. Coordinating account security changes across such a large user base and infrastructure is no small task, and these developments are likely to take years to fully roll out.
Ethereum’s continued engagement with quantum security research signals its commitment to long term network resilience. The Ethereum Foundation continues exploring multiple paths to keep the network secure against emerging threats.
Follow Hashlytics on Bluesky, LinkedIn , Telegram and X to Get Instant Updates
