OP_CHECKSHRINCS: Blockstream’s Stateful Bet on a Hash-Based Post-Quantum Bitcoin

Blockstream Proposes a Signature Opcode Built From Bitcoin’s Own Assumptions

June 3, 2026 — On May 12, 2026, Blockstream Research published OP_CHECKSHRINCS, a sketch for a new Bitcoin opcode that would verify SHRINCS, a hash-based post-quantum signature scheme the team designed for Bitcoin’s block-space and wallet constraints. The post, authored by Blockstream researcher Jonas Nick, argues that optimized hash-based signatures are a pragmatic near-term choice for a post-quantum Bitcoin, and describes SHRINCS and its multi-device sibling SHRIMPS as the smallest post-quantum schemes available on mature cryptographic assumptions.

SHRINCS itself dates to December 2025, when Nick and Blockstream cryptographer Mikhail Kudinov published Hash-based Signature Schemes for Bitcoin on the IACR ePrint archive and introduced the construction on the Delving Bitcoin forum. The scheme places two signing paths under a single 32-byte public key: a compact stateful path built from Winternitz one-time signatures in an unbalanced XMSS-style tree, and a stateless SPHINCS+-style fallback that is always available. A first signature on the compact path is 324 bytes. Recovery requires nothing beyond the master seed, matching the BIP-39 backup workflow wallets already use, and every internal hash operation runs on SHA-256, the function Bitcoin’s proof-of-work already depends on.

The bottom line for anyone tracking Bitcoin’s quantum migration: for the first time, the network has a post-quantum signature candidate whose assumptions, size profile, and deployment story were engineered for Bitcoin specifically, and its throughput cost is a roughly 2x haircut rather than the 4-5x collapse the NIST schemes impose.

Blockstream’s numbers anchor that comparison. Using the 90-day average transaction shape of 2.27 inputs and 2.64 outputs (per transactionfee.info) packed into the current block weight limit, a Schnorr-only Bitcoin supports about 6.5 transactions per second. ML-DSA (formerly CRYSTALS-Dilithium) drops that to roughly half a transaction per second at NIST security level 3, and SLH-DSA (formerly SPHINCS+) to 0.36 TPS at level 1. The SHRINCS compact path recovers up to 3 TPS. Blockstream also notes that the NIST schemes eliminate the features modern Bitcoin infrastructure is built on, including BIP-32 unhardened key derivation, MuSig, and planned upgrades such as cross-input signature aggregation and silent payments.

TPS figures are Blockstream’s, computed at the average transaction shape above and the current 4M-WU limit.

The compact path’s efficiency comes from a deliberately shrunken signature budget, the parameter in every hash-based scheme that caps how many times a key can safely sign. SLH-DSA sets it at 2^64; SHRINCS exploits Bitcoin’s norm against address reuse to set it near the floor. The cost is state: the signer must track how many one-time keys it has consumed, because reusing one breaks the scheme’s security. Blockstream’s answer is to confine state to a dedicated signing device that never exports it. Because the state is public, a software wallet can independently check that a candidate signature does not reuse state before broadcasting. A device that is lost or restored from seed falls back to the stateless path and produces a signature of several kilobytes rather than losing funds. SHRIMPS, published March 27, 2026, extends compact signing to multiple devices initialized from the same seed, producing signatures of roughly 2.5-3 KB with a conservative bound of 1,024 device initializations and security that degrades gradually rather than collapsing if the bound is exceeded.

The opcode sketch assembles these pieces into four specialized variants: desktop and mobile wallets use a stateless scheme at roughly 4,496 bytes (trading signing time for compactness), dedicated signing devices use SHRINCS at roughly 580 bytes with a SHRIMPS backup path near 3,000 bytes and a stateless fallback near 4,336 bytes, and Lightning nodes reuse the fallback scheme for channel updates. Effective throughput across the variants ranges from 0.60 to 3.04 TPS. Two design principles govern the parameterization: verification time never exceeds SLH-DSA’s, and per-byte verification cost lands more than six times below Schnorr’s, which Blockstream says preserves headroom for any future block-size discussion and simplifies proof generation if block-wide signature aggregation is ever adopted.

SHRINCS is not confined to paper. In March 2026, Blockstream deployed SHRINCS verification on the Liquid sidechain mainnet via Simplicity smart contracts and broadcast what it describes as, to its knowledge, the first post-quantum-signed transactions on a production Bitcoin sidechain, padding the extra transaction space with the text of the Bitcoin whitepaper. The company has published a C++ implementation, a Simplicity verifier, a draft specification, and the parameter scripts behind its size and throughput figures. Nick presented the opcode concept, under the working name OP_SHRINCSVERIFY, at the OP_NEXT conference in April. Blockstream states plainly that the code still needs thorough auditing and a finalized specification, that the Liquid verifier leaves several classical components in place, and that deployment on Bitcoin’s base layer requires a soft fork. The opcode could ship via Taproot, a proposed Taproot v2, or BIP-360’s P2MR leaves. No BIP number has been assigned.

The post also surveys the alternatives Blockstream examined and set aside for now: Falcon^WS, a recent lattice proposal near 1 TPS that the team calls far too immature; feature-preserving lattice schemes such as a modified Raccoon-G with 16 KB public keys and 20 KB signatures; SQIsign, whose isogeny assumptions need years of scrutiny; and block-wide SNARK aggregation of every signature in a block (recent examples include BitZip and LeanVM), which could reach roughly 6.7 TPS but carries open questions about who computes the proofs and how to avoid mining centralization. On the block-size question, Blockstream’s position is that an increase could offset the throughput cost, but bundling a post-quantum deployment with that debate would likely sink both, so the two should be decided separately.

The proposal has moved quickly into mainstream tracking. Fidelity Digital Assets’ mid-2026 trends review, published in late May, cites OP_CHECKSHRINCS alongside the simplified BIP-360 as evidence of building momentum behind Bitcoin’s long-term security upgrades.

My Analysis

I updated my Bitcoin post-quantum migration roadmap to add this family, because it changes two of that article’s load-bearing numbers: the throughput cost of going post-quantum and the identity of the compact-signature option. What follows is the longer assessment, as part of my Quantum Threat to Cryptocurrencies series.

What 324 Bytes Actually Buys

Start with the claim-evidence gap, because the headline number needs unpacking. The 324-byte figure is real but conditional: it is the first signature from a fresh key on the compact stateful path, per the formula in the December construction, and Blockstream’s own marketing page rounds it into “7x smaller than the NIST standard” (ML-DSA-44’s 2,420-byte signature, so 7.5x on signatures alone). The parameterization Blockstream actually proposes for deployment in the opcode sketch puts primary-device signatures at roughly 580 bytes, backup devices near 3,000, and the stateless paths at 4,300-4,500. Anyone who restores a seed onto a new device, which is most people eventually, signs at fallback size until SHRIMPS-style paths ship in their wallet. Ecosystem-average witness size therefore depends on wallet behavior, and consensus engineering has to budget for the fallback, because the fallback is what an adversarial or merely unlucky block looks like.

None of that undoes the result. The honest metric is throughput at realistic transaction shapes, and there SHRINCS moves the needle from catastrophic to tolerable: 6.5 TPS today, up to 3 TPS on the compact path, versus 0.36-0.5 TPS for the standardized schemes. My May witness-economics modeling put a hybrid ML-DSA-44 Bitcoin at 500-700 transactions per block against 2,500-3,000 today; SHRINCS turns a 75-80 percent capacity loss into something closer to half. A haircut of that size is absorbable inside the existing 4M-WU limit through fees, which means the migration no longer has to route through the block-size question at all. Blockstream is right to decouple the two, and its verification-cost discipline (per-byte cost more than six times below Schnorr’s) keeps the block-size option open for whoever wants to fight that war later, on its own merits.

Statefulness Is the Trade, and Blockstream Is Candid About It

Every hash-based scheme carries a signature budget; SHRINCS just stops pretending the budget needs to be 2^64 for keys that Bitcoin’s own best practices say should sign once. Shrinking the budget is where the bytes come from, and state is where the risk goes. Reuse a one-time key and the scheme’s security breaks, which is why pure stateful schemes like XMSS have always terrified wallet developers: an ordinary backup restore silently rewinds the counter.

The containment story is the best part of the design. State lives on a dedicated signing device and never leaves it. State is public, so a watching wallet can refuse to broadcast a signature that reuses it. Losing state costs bytes, through the fallback, rather than funds. And Blockstream’s framing of the residual risk is analytically correct: lattice-assumption risk and throughput collapse are systemic, landing on every user of the network at once, while state mismanagement is localized to the wallet that mismanaged it. For a system allergic to imposed risk, localized beats systemic.

What the design does break is an assumption Bitcoin wallet culture has carried since BIP-32 (2012) and BIP-39 (2013): that the seed is the wallet, and any device restored from it is fully equivalent to the original. Under SHRINCS, only the primary device signs small. SHRIMPS, arriving three months after SHRINCS with bounded multi-device support, reads as Blockstream conceding that point and engineering around it. Statefulness also has more standards precedent than Bitcoin discourse tends to acknowledge: NIST SP 800-208 approves the stateful hash-based schemes LMS and XMSS for firmware and code signing in controlled environments, and CNSA 2.0 adopted them for the same role. A dedicated signing device is precisely the controlled environment those standards envision. The unresolved friction sits with institutions: exchanges and custodians control a large share of the 6.7 million exposed BTC, their signing lives inside FIPS-validated hardware, and SHRINCS has no validation path. A consensus-valid scheme that cannot run in the hardware the biggest holders are required to use creates a gap someone will have to close.

One disclosure the reader should weigh: the proposal’s happy path runs through dedicated signing devices, and Blockstream manufactures one (Jade). The design stands on its merits, and I would flag the same incentive alignment if a lattice-hardware vendor were championing ML-DSA. It changes nothing about the cryptography and something about who profits from the recommended deployment pattern.

Where This Leaves BIP-360, FN-DSA, and My May Verdict

In May I called ML-DSA-44 the pragmatic baseline for Bitcoin’s initial migration and FN-DSA-512 the compact upgrade path once FIPS 206 finalizes. The baseline verdict stands. SHRINCS is a few months old; its components are mature (Winternitz chains date to the Merkle era, XMSS is RFC 8391, the fallback is the SPHINCS+ lineage behind SLH-DSA, and the WOTS+C and PORS+FP optimizations are peer-reviewed work, the former co-authored by Kudinov), but the composition has not accumulated independent cryptanalysis, the specification is a draft, and Blockstream itself says the code needs audits. Bitcoin should not anchor its consensus rules to a scheme at that maturity, and Blockstream is not asking it to yet.

The compact-option verdict is another matter. FN-DSA’s case was always its 666-byte signatures; its liabilities are lattice assumptions, a Gaussian-sampling signing operation that is notoriously hard to implement without side channels, and a FIPS standard still not final. SHRINCS beats it on size along the happy path, matches Bitcoin’s existing assumption set instead of importing a new one, and arrives with a working verifier securing real funds on Liquid. If I had to bet on which compact path Bitcoin’s culture ultimately accepts, I would now bet on hash-based over lattice-based, and I did not hold that position in May. The two are not mutually exclusive in any case: P2MR commits to a Merkle root of scripts, so an ML-DSA leaf, a SHRINCS leaf, and an SLH-DSA emergency leaf can coexist in one output, and Blockstream explicitly lists BIP-360 among the opcode’s deployment vehicles. Blockstream’s opening claim that no concrete post-quantum signature proposal exists for Bitcoin today is fair on a strict reading: BIP-360 defines the output type and deliberately leaves algorithm selection to future BIPs, and the BTQ testnet’s ML-DSA opcodes are an external implementation rather than a consensus proposal.

I will also note the tension Blockstream has left itself to resolve. The post opens with a list of failure modes for a post-quantum upgrade, two of which are complexity and non-adoption, and then sketches a proposal containing four signature variants across three device classes. Four schemes where Bitcoin currently runs on one is a real review burden and a real fungibility and privacy cost, which the post itself concedes. The design space argument for specialization is sound; whether Bitcoin’s review culture will swallow it is the open question, and it is the same culture that has been chewing on far simpler opcodes for years.

The Aggregation Sequencing Falls Into Place

Hash-based one-time and few-time signatures are the best-behaved inputs to SNARK and STARK aggregation, a result established in the 2021 aggregation literature: inside the proof circuit, the individual signature is just a witness, so thousands of them compress into a 100-200 KB proof regardless of their standalone size. Blockstream’s own survey puts block-wide aggregation near 6.7 TPS, above the Schnorr baseline, and its verification-cost design principle exists partly to keep that door open. Ethan Heilman argued the sequencing on the dev list back when the discussion was more abstract, calling deployed PQ signatures “a useful stepping stone to PQ transaction compression.” OP_CHECKSHRINCS is what the first step of that sequence looks like in concrete form: a single opcode soft fork now, with aggregation as a separable later fork once schemes are settled and someone solves prover economics. Meanwhile the no-fork constructions I covered in the roadmap article, StarkWare’s QSB and Osuntokun’s zk-STARK seed-lifting prototype, keep occupying the emergency niche that requires no one’s consensus.

On timelines: nothing here changes when a CRQC capable of running Shor’s algorithm against secp256k1 arrives. It changes how much of the defensive menu is Bitcoin-shaped. The soft-fork math is the constraint that matters: Taproot went from published BIPs in January 2020 to activation in November 2021, 22 months for an upgrade nobody seriously opposed, and OP_CHECKSHRINCS does not yet have a BIP. The medium-term activation window in my May roadmap (2027-2029) survives only if a BIP materializes within the next year and the review process treats a seven-month-old scheme with the urgency the governance situation warrants. What to watch between now and then: a numbered BIP draft, independent cryptanalysis of the SHRINCS composition, the Liquid audit outcomes, whether Bitcoin Core contributors engage substantively on Delving Bitcoin, and whether the four-variant proposal slims down under review.

The opcode is a sketch, and Blockstream says so. What the December-to-May arc demonstrated is that Bitcoin’s post-quantum menu no longer consists solely of standards written for other problems and other threat models. The next move belongs to the review process, and to whoever writes the BIP.