Ethereum’s long-term “quantum-safe” story is still a roadmap. But one proposal is trying to make the near-term math less brutal.

In a Cointelegraph report, Ethereum’s Kohaku lead points to a SPHINCS proposal aimed at lowering the cost of post-quantum signature verification while the network develops a longer-term solution. SPHINCS here is the post-quantum signature scheme the researcher is trying to make cheaper to verify on-chain.

Why the cost matters, not the buzzword

Post-quantum cryptography isn’t just a cryptography debate. On a blockchain, signature verification turns into compute and gas. Higher verification costs mean higher execution budgets for smart contracts and higher friction for protocols that need cryptographic authentication.

Cointelegraph frames SPHINCS as a direct attempt to reduce the cost of post-quantum signature verification on Ethereum. The concrete hook in the article is the researcher’s estimate that quantum-proof accounts could be enabled for “just 7 cents.” That number is not a promise. It’s a cost estimate tied to this specific approach and its verification path.

What SPHINCS is trying to change

According to Cointelegraph, the SPHINCS proposal focuses on post-quantum signatures already needed for “quantum-proof” accounts. The bet is that verification can be made cheaper now, not after every bigger research milestone lands.

This matters because Ethereum’s quantum migration is not a single switch. The network needs something that can function under today’s constraints, then evolve as better or more efficient primitives become available. Cointelegraph explicitly says SPHINCS targets the cost of verification while Ethereum works toward a longer-term solution.

Roadmap reality check: short-term improvements, longer-term work

The headline claim is attention-grabbing. But the article’s framing is also familiar to anyone who has watched upgrades collide with engineering constraints. Even if verification costs fall dramatically, the “quantum-safe” requirement is broader than one signature primitive.

Cointelegraph’s piece keeps the scope clear. SPHINCS is presented as an optimization along the way, not the final destination. The network still needs a longer-term answer beyond reducing the cost of verification.

If the SPHINCS approach works as intended, it could let Ethereum start adopting post-quantum components with less performance pain than brute-force verification. If it doesn’t, or if the cost model shifts with implementation details, the proposal still provides something valuable: a measurable target for future designs.

The real question for validators and clients

Even a “7 cents” estimate only tells part of the story. The rest is implementation reality, including which clients implement what primitives, how the EVM or precompiles evolve, and how failures show up.

Cointelegraph does not provide additional details in the excerpt about validator incentives, client diversity, or outages. That means readers should treat the proposal as an engineering proposal with quantified potential, not a scheduled upgrade.

For a protocol-level change to land safely, it has to clear more than cryptographic correctness. It has to fit Ethereum’s execution environment and operational tolerance.

Still, cost reduction for verification is a sane place to start. If you can make post-quantum verification cheaper, you can leave the door open for broader adoption without forcing every use case to pay an extreme premium.

What to watch next

Cointelegraph’s report is essentially a checkpoint: a named proposal, a specific cryptographic target, and a cost estimate for enabling quantum-proof accounts.

Next steps readers can look for include:

  • More detail on how SPHINCS verification is implemented on Ethereum.
  • Any benchmarks or reproducible numbers that explain the “7 cents” figure.
  • How the proposal fits with the “longer-term solution” Ethereum is still working toward.

The quantum timeline is uncertain, but the engineering tradeoffs aren’t. SPHINCS is a concrete attempt to reduce one of the hardest costs in the transition. Whether it becomes a shipped component depends on the usual bottleneck. It has to survive implementation, measurement, and integration.