I’ve been following the development of BIP-0360 by Hunter Beast on his work on BIP-360: QuBit - Pay to Quantum Resistant Hash.
And today I saw the news from Jameson Lopp regarding Apple adding cryptography to prep their web servers for quantum secureness.
So I decided to investigate further see how Stacks can prep ourselves, asked ChatGPT to make recommendations based on what it knows about Stacks and Bitcoin.
Below are the summary of the proposal. Might be completely off, I don’t know, but I hope it serves as a beginning of a discussion in Stacks how to prep ourselves.
Summary
This post (via ChatGPT) proposes a strategic, phased roadmap to begin preparing the Stacks ecosystem for post-quantum cryptography (PQC) threats.
While this is not an urgent risk today, the long-term security and credibility of any blockchain—especially one so closely aligned with Bitcoin—depends on forward-looking resilience against evolving cryptographic threats.
- By starting the conversation early and exploring low-lift design decisions now, we can protect the long-term value of sBTC, Stacks addresses, and on-chain assets, while positioning Stacks as a security-first ecosystem.
Rationale: Why This Matters
1. Quantum Threats to Bitcoin = Quantum Threats to Stacks
Stacks uses ECDSA (secp256k1) for most signatures, just like Bitcoin. If Shor’s algorithm or other quantum techniques become practical, attackers could potentially forge signatures and steal funds from public-key-exposed addresses like those used in:
- Taproot & P2PK Bitcoin addresses
- sBTC vault implementations
- On-chain smart contract logic relying on
verify_secp256k1
Stacks must begin preparing to ensure its assets remain secure even as cryptographic assumptions shift.
2. No Hard Fork Needed – If We Plan Ahead
Post-quantum readiness doesn’t require a hard fork today. Many changes can be opt-in, experimental, and built modularly. For example:
*Adding PQC signature verification primitives to Clarity
*Creating a new SegWit-style address format for PQ-safe keys
*Leaving upgrade flexibility in new sBTC or consensus-layer design paths
The sooner we plan, the smoother future migrations or upgrades can be—with far less disruption.
3. Ecosystem Confidence and Credibility
Developers and users increasingly care about long-term safety of their BTC-backed assets and smart contract logic. Signals that Stacks is preparing for emerging cryptographic threats can:
*Build trust with security-conscious users
*Make Stacks wallets and infra more competitive
*Align with emerging best practices from Ethereum, ZCash, Bitcoin R&D, and NIST
Proposed Actions (Initial Roadmap)
| Phase | Idea | Scope |
|---|---|---|
 Short-Term |
Publish educational brief & dev R&D post | Community & comms |
 Mid-Term |
Add PQ-safe signature verification to Clarity (e.g., verify_dilithium, verify_falcon) |
Core development |
 Mid-Term |
Experiment with PQ-compatible address or BNS descriptors | Dev tooling & infra |
 Long-Term |
SIP for opt-in transaction/output type with quantum-safe commitments (e.g., modeled after BIP-360) | SIP + consensus |
 Ongoing |
PQ-readiness planning for wallets, vaults, and BTC bridges | Wallets & sBTC teams |
Related Work
- BIP-360: Pay to Quantum Resistant Hash (Draft) — A Bitcoin proposal to introduce hybrid ECDSA + PQ signature scripts
Related article & Podcast
- The Quantum Shift Getting Ready For A New Computing Era by Anduro
- Preparing Bitcoin for Quantum Threats with Hunter Beast | SLP672 - Stephan Livera - 2nd July 2025
Call for Feedback, I’d love feedback on:
- Should this be added to the Stacks Roadmap?
- What level of priority should this topic have on the Roadmap?
Please mind that currently @larry is proposing Bitcoin address Proposing Bitcoin Addresses for Stacks - I don’t know how it affects one or another, and how they both are affected by BIP-0360