What it is. Stacks is a smart-contract network built on top of Bitcoin, and the locks it uses to protect coins and approve actions are the same kind a future quantum computer could pick.
What we found. Nobody has started swapping in quantum-proof locks, no plan or test version exists, and because Stacks account addresses are shaped like Bitcoin's, it likely cannot move until Bitcoin itself moves first.
Why it matters. Any address you have already spent from is the one most at risk, the Bitcoin-to-Stacks transfer bridge is the weakest link because it funnels many approvers into one signature, and waiting on Bitcoin means a holder could be exposed for many years.
Stacks's quantum exposure is structurally dual: it inherits Bitcoin's ECDSA-secp256k1 exposure (PoX block commits and HASH160 addresses are Bitcoin-shaped), AND adds Stacks-native primitives (WSTS-Schnorr-secp256k1 for Nakamoto block-signing and sBTC peg) that have the same Shor-vulnerable curve. No PQ-safe primitive in any layer. sBTC's 14-of-15 federated signer set is single-key-aggregate (one Schnorr signature on Bitcoin per peg op), compelling for L1-bytes-efficiency, fragility for PQ exposure.
Summary
Stacks runs ECDSA secp256k1 for transaction authorization, Schnorr WSTS over secp256k1 for Nakamoto block-signing and sBTC peg signatures, RIPEMD-160 for HASH160 addresses, SHA-256 for hashing. Zero PQ family deployed. Mainnet PQC traffic 0%, no PQ-LOC in stacks-core, no PQ stacker keys, 5d voided per v3.1. Supply chain, Leather/Xverse/Asigna wallets, sBTC/Wormhole bridges, BitGo/Copper custody, Hiro/Ankr RPC: zero published PQ roadmaps across all four tiles. Nakamoto upgrade (2024-10-29) substantially changed block production (fast blocks, Bitcoin finality, WSTS aggregation) without changing the signature scheme. Post-Nakamoto signature posture is more concentrated (signer-aggregate single Schnorr per block). Gate 1a-Sig FAIL, Gate 1a-KEM FAIL. Bitcoin-coupling: Stacks's PQ trajectory is gated on Bitcoin's because HASH160 addresses are Bitcoin-shaped; a Stacks-leads-Bitcoin migration is architecturally possible but undeclared. SIP process and Hiro/Stacks Foundation coordination capacity exists for a future PQ-Stacks SIP, but no PQ-specific WG, statement, or architecture spec has been published. QRI 24, Band 3 Planning (borderline Band 2 Acknowledged).
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition AND or OR; no SIP, no spec branch, no testnet
- Gate 1a, Hybrid KEM: FAIL , Stacks RPC TLS, validator gossip, and sBTC signer-coordination channels use classical KEMs without documented hybrid PQ KEM
- Gate 1b, Commit-to-hash: COND , no OR-composition declared
- Gate 2, Evidence reconstruction: PASS , every sub-score has ≥3 URLs reconstructible by independent third party in 48 hours
- Gate 3, Primitive naming: PASS , ECDSA secp256k1, Schnorr WSTS over secp256k1, RIPEMD-160, SHA-256 named with mechanism
Burn-vs-rescue policy on file
Declared option f, Undeclared. Stacks inherits the broader Bitcoin community debate. The Bitcoin-anchored design implies any Stacks policy is gated on Bitcoin's decision (HASH160 cold addresses on Stacks share the same Bitcoin pubkey-hash, so a Bitcoin freeze/burn of HASH160-revealed-pubkey UTXOs would have Stacks-side correlates).
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 34 / 100
Inventory is named per-spec but not consolidated, a reader assembles it across SIP-021, SIP-025, c32check repo, and Hiro docs. Two points deducted for fragmentation.
ECDSA secp256k1 (transaction authorization, miner block-commit signatures on Bitcoin L1, PoX participation) · SHA-256 (PoX block hashing, Bitcoin-anchor hashing) · RIPEMD-160 (Stacks address scheme via c32check on top of HASH160 = RIPEMD-160(SHA-256(pubkey))) · Schnorr WSTS (Weighted Schnorr Threshold Signatures, FROST-derived) for Nakamoto block validation by signers and for sBTC peg signer aggregate signatures on Bitcoin L1 ECDSA secp256k1→ Shor-break-via-DL-without-pairingsSchnorr WSTS over secp256k1→ Shor-break-via-DL-without-pairingsSHA-256→ Grover-weaken (256→~128-bit post-quantum)RIPEMD-160→ Grover-weaken (160→~80-bit post-quantum, the same hash-address ceiling that constrains Bitcoin P2PKH cold-key protection)
0 families. Every signature primitive in active use is a discrete-log construction over secp256k1.
No NIST PQC primitive deployed, no NIST PQC primitive in any merged spec or testnet branch.
Clarity smart-contract language is decidable-by-design but this concerns contract-level safety, not chain signature-scheme implementation quality. stacks-core uses standard Rust libsecp256k1-derived bindings. No Formosa-Crypto / Libjade machine-checked implementations of any chain-internal primitive. Stateless. Cryptanalytic tier 1 for ECDSA secp256k1, SHA-256, RIPEMD-160, Schnorr/WSTS (WSTS as a threshold-signing protocol is a 2023-era construction with academic security analysis).
2 Quantum Recovery Exposure weight 10% 36 / 100
Stacks transactions and PoX participation reveal the secp256k1 public key on first signed action. Stackers explicitly register block-signing keys when they stack or delegate-stack, signer keys are revealed by definition. Active-trader / active-stacker addresses are Forge-vulnerable post-Shor on the same horizon as Bitcoin's revealed-pubkey set.
Stacks addresses are c32check-encoded HASH160 (RIPEMD-160(SHA-256(pubkey))), the same protection Bitcoin's P2PKH addresses use. Cold STX addresses that have never broadcast a transaction retain hash-protection: pubkey is not on-chain until first spend. Post-quantum ceiling for HASH160 is ~80-bit Grover-vs-RIPEMD-160.
Historical Stacks transactions (genesis 2021-01-14) signed under ECDSA secp256k1 are stored permanently. Post-Shor, every historical signature is forgeable. PoX block commits on Bitcoin L1 are signed under ECDSA secp256k1 by miners. Nakamoto-era blocks (post-2024-10-29) carry an additional Schnorr WSTS aggregate from Stackers, also Shor-vulnerable.
Stacks node P2P transport (per SIP-003) and public RPC surfaces (Hiro API, public node endpoints) use standard TLS and standard libp2p / chain-specific P2P framing. No documented hybrid PQ KEM. Bridge surfaces (sBTC peg WSTS coordination) use signer-to-signer encrypted channels described in SIP-025 / WSTS docs without specifying hybrid PQ KEM.
3 Metadata, Anonymity & Confidentiality weight 13% 25 / 100
Pseudonymous (Bitcoin-class). All Stacks transactions are public, sender, recipient, STX amount, contract calls, function arguments, post-conditions all transparent. Stacks addresses link directly to Bitcoin addresses via shared HASH160, cross-chain pseudonym linkage is structural, not statistical.
Top-3 RPC concentration: Hiro Systems operates the dominant public Stacks API (api.hiro.so) and provides the reference Stacks node infrastructure; block explorers similarly concentrated. No published distribution table. Mempool gossip: standard public mempool. Validator metadata retention policy: undeclared.
sBTC is the primary bridge in Stacks's economic gravity (Bitcoin → Stacks). The 14-of-15 federated WSTS signer set produces a single Schnorr aggregate signature on Bitcoin L1 to release/lock pegged BTC. Withdrawals (Phase 2, live since end-April 2025) similarly correlate. Composite linkability high.
Post-Shor, every revealed Stacks pubkey can be inverted, every historical ECDSA signature can be forged, every historical Schnorr WSTS signer-aggregate can be deconstructed if signer pubkeys were revealed. A future analyst with a CRQC and full chain history can identify which actor controlled which address, then cluster cross-chain Bitcoin holdings via the shared HASH160 mapping.
L1 profile uses 4 sub-scores for Dim 3; this entry not scored.
4 Migration Architecture weight 10% 33 / 100
Stacks has a SIP-driven hard-fork mechanism (SIP-015 Stacks 2.1 PoX upgrade; SIP-021 Nakamoto activated at Bitcoin block 867,867 on 2024-10-29). Swapping the signature scheme is a consensus-breaking change requiring SIP ratification and coordinated activation. Tx-authorization is tightly coupled to Bitcoin compatibility (HASH160 addresses share Bitcoin pubkey-hash format). No verifiable production instance of a cryptographic-algorithm switch in the last 5 years.
No ERC-4337-style account abstraction, no EIP-7702-style native AA. Multisig supported (SIP-027 covers non-sequential multisig). Clarity contracts can implement custom auth logic at the smart-contract level, but underlying tx-authorization to the protocol remains ECDSA secp256k1. Key rotation: not native, a user 'rotating' effectively transfers funds to a new address.
Coordinated forks delivered: SIP-015 (Stacks 2.1, 2022-12); SIP-022/023 (emergency PoX fixes, 2023); SIP-021 (Nakamoto, activated at Bitcoin block 867,867 on 2024-10-29). Nakamoto delays demonstrate the coordination cost of PoX-anchored upgrades: each window slip required re-aligning Bitcoin block targets, signer onboarding, and stacker re-registration.
A hybrid signature path on Stacks would require either a new tx-authorization type alongside existing standard / multisig types plus a Clarity-language extension for PQ-pubkey-hash derivation, or a parallel chain-state with PQ-only addresses. Neither has a published spec, testnet branch, or SIP draft.
No stateful hash-based signature scheme deployed. All current primitives (ECDSA secp256k1, Schnorr WSTS over secp256k1, SHA-256, RIPEMD-160) are stateless. Default full-credit per v3.1 rule.
Stacks's Nakamoto consensus uses WSTS over secp256k1 for block-signing, a Schnorr aggregate (not BLS), but functionally aggregating ≥70%-by-stake signer commitments into a single signature, putting Stacks in 4f scope. Replacing WSTS-Schnorr with a PQ-aggregating equivalent is non-trivial: candidate paths exist in research but none is declared, specified, or testnet-staged for Stacks consensus.
5 Deployment Execution weight 22% 15 / 100
0% of Stacks consensus or transaction-authorization traffic uses PQ primitives. No PQ-signed blocks, no PQ-authenticated transactions, no PQ-pegged sBTC operations.
stacks-core (the reference consensus client, Rust) has no merged PQ-primitive code. No SLH-DSA, ML-DSA, ML-KEM, Falcon, or any other NIST-PQC primitive in the consensus path.
0% of stackers / signers operate PQ keys. Nakamoto signer registration explicitly registers secp256k1 block-signing keys.
VOIDED per v3.1 since 5a = 0.
Trailing-12-month PQ announcements: 0. Shipped PQ on mainnet: 0. Ratio undefined; tag 'no narrative, no shipping.' No announcement-to-shipped because no PQC narrative to wash.
No PQ primitive deployed, no measured PQ-signature-bytes-per-block on Stacks mainnet, no published analysis of hypothetical PQ migration cost.
6 Supply Chain Vendor Readiness weight 22% 5 / 100
Top-3 Stacks wallets by user volume: Leather (formerly Hiro Wallet), Xverse (multi-chain Bitcoin/Stacks), Asigna (multisig-focused). PQ-roadmap status: zero public PQ posture from any of the three. All three sign Stacks transactions via standard secp256k1.
Top bridges: sBTC (the native federated peg, 14 elected signers, Asymmetric Research, Blockdaemon, Chorus One, Kiln, ALUM Labs, Bitcoin L2 Labs, and additional confirmed signers per SIP-028 onboarding); Wormhole. PQ-roadmap status: sBTC operates on WSTS-Schnorr-secp256k1, no PQ path declared. Wormhole has no public PQ roadmap for Stacks.
Custodians offering STX / sBTC custody include BitGo, Copper, and (per market evidence) some signer-operator entities double as institutional custody (Blockdaemon, Chorus One). PQ-readiness: no PQ-MPC product publicly available for Stacks-specific keys.
RPC: Hiro Systems is the dominant API provider (api.hiro.so); Ankr offers Stacks RPC. PQ-roadmap from RPC providers for Stacks: none published. HSM: standard HSMs used by signer-operators and custodians without PQ-key support for the secp256k1 keys they protect. TEE: not a documented part of the standard Stacks node operator set.
7 Governance & Coordination weight 8% 39 / 100
Nakamoto reduced the active block-producing set to a more concentrated stacker-signer pool than the pre-Nakamoto miner set; current operating signer count approximately 37 (per Stacks Q3 2025 / H1 2025 ecosystem briefs). Top stackers concentrate a meaningful share of total stacked STX; 70% of stacked STX is the signing threshold for block finality. Single client implementation (stacks-core, Rust).
Coordinated forks: SIP-015 (2022), SIP-022/023 (emergency PoX fixes, 2023), SIP-021 (Nakamoto activation 2024-10-29). Nakamoto required multiple schedule slips (April-29 → August-28 → October-29 windows). Emergency-fix track record (SIP-022/023) demonstrates capacity for hot-patches.
Named coordination structure: Stacks Foundation (foundation entity, distributes grants and coordinates SIPs), Hiro Systems (primary protocol-development entity, employs core stacks-core authors). SIP process is published (SIP-000) with named SIP editors, technical/governance/economics CABs, and a Steering Committee. No published PQC working group, no named PQC migration lead.
Stacks has not yet been forced to coordinate a cryptographic algorithm change with an active adversary. Emergency PoX fixes (SIP-022/023) were coordinated under economic pressure but not under active cryptographic attack. Bitcoin-anchored finality means Stacks has, in effect, never had to handle a Stacks-only adversarial scenario.
No published canary, honeypot, rate-limited spending rule, or cryptographic tripwire for quantum-attack detection at consensus or sBTC-peg level.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y > 2035, Crisis Zone (vs Z10 2030); Outside risk window (vs Z25 2035)
Z-compliance
Outside compliance window for both NIST 2030 deprecation and 2035 disallowance
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Bitcoin-coupled chains face a fundamental design question, should the L2 migrate ahead of, in lockstep with, or after the L1? Aggressive-L2-migration view: Stacks deploys hybrid signatures independent of Bitcoin's BIP timeline, accepting cross-chain HASH160 desync. Conservative-coupling view: Stacks waits for Bitcoin's PQ migration to land, accepting X+Y > 15-year Z exposure. Stacks has not published a position.
At scoring date, sBTC operates with 14 elected signers (Figment-replacement vote pending per SIP-028 update). Some evaluators classify the federated-14 as a temporary Phase-1 design pending the original whitepaper's permissionless-rotating model; others classify it as the operating reality.
Delta-QRI under alternative weighting
Under aggressive-migration weighting (+8 to +12) where Stacks committed to leading rather than following Bitcoin, Dim 4 hybrid-readiness and Dim 5 expected-deployment would re-weight upward. Material conclusions otherwise unchanged.
Announcement-to-shipped ratio
Announced: 0. Shipped: 0. Ratio: 0.
Tag: none, no narrative, no shipping. Stacks Foundation, Hiro, or Stacks core devs have made zero PQ announcements in trailing 12 months.
Peers in the L1 profile
9 chains closest to Stacks by Stage then QRI.