On May 12, 2026, Blockstream Research proposed a Bitcoin opcode called OP_CHECKSHRINCS that would verify signatures made with SHRINCS, a hash-based post-quantum signature scheme its researchers designed for Bitcoin. Jonas Nick, the Blockstream researcher who wrote the proposal, called it “a starting point” that “comes with downsides and raises a number of open questions.”
Opcodes are the instructions in Bitcoin Script, the programming language in which users write the conditions for spending their coins. Nick opened his post by writing that there was no concrete proposal for a post-quantum signature scheme in Bitcoin.
Blockstream calculated that Bitcoin could process up to 3 transactions per second if every signature used the compact SHRINCS path, compared with 6.5 using today’s Schnorr signatures.
Disclosure: Quantum Observer’s Editor-in-Chief Marin Ivezic is an advisor to Project Eleven, which works on post-quantum security for digital assets.
How SHRINCS signs
Nick and Mikhail Kudinov, both of Blockstream Research, studied hash-based signature schemes for Bitcoin in a December 2025 preprint, in which they covered SHRINCS briefly in an appendix. Later that month, Nick described SHRINCS at more length in a blog post, with “324-byte stateful post-quantum signatures with static backups” in its title.
In a stateful hash-based signature scheme, the signer uses one-time keys built from hash functions and must keep a record, called state, of which keys it has used. If a signer uses the same one-time key twice, an attacker may be able to forge signatures. Blockstream’s researchers gave SHRINCS two signing paths under one public key, a compact stateful path and a larger stateless fallback that needs no record.
Signature sizes and state
In the opcode proposal, Nick matched signature schemes to types of signer in four variants. Desktop and mobile wallets would use a stateless scheme with signatures of about 4,496 bytes. Nick excluded those wallets from stateful signing because a user who restored an old backup could roll back the wallet’s record of used keys, he wrote.
Dedicated signing devices would use the compact SHRINCS path, at about 580 bytes per signature from a primary device. A backup device would sign on a second compact path, called SHRIMPS, at about 3,000 bytes.
Nodes on Lightning, a payment network built on Bitcoin, would use a stateless fallback scheme at about 4,336 bytes for channel updates. Nick wrote that cooperative channel closes, in which both parties to a channel agree to close it, should be able to use the compact SHRINCS path at about 580 bytes.
Under the proposal, the state stays on the primary signing device and never leaves it. Nick wrote that the state is public and that “a software wallet can add an extra safety check.”
A user who loses or replaces the device loads the seed, the secret from which the keys are derived, into a new one. The replacement signs on the stateless path at about 4,336 bytes per signature.
Throughput
Blockstream based its throughput figures on an average transaction with 2.27 inputs and 2.64 outputs, the 90-day average as of March 30, 2026, and on Bitcoin’s current block size limit. Across the four variants of the proposal, Nick put effective throughput at 0.60 to 3.04 transactions per second. He wrote that a block size increase “is better left as a separate discussion.”
With ML-DSA, formerly CRYSTALS-Dilithium, at NIST security level 3, Blockstream calculated about 0.5 transactions per second. Blockstream put SLH-DSA, formerly SPHINCS+, at 7,872 bytes per signature, without naming a parameter set, and calculated 0.36 transactions per second with it. NIST published both as post-quantum signature standards in August 2024.
Activation and testing
Nick wrote that, after a soft fork, an output could commit to both a Schnorr key and a post-quantum key. A soft fork is a backward-compatible tightening of Bitcoin’s consensus rules. Nodes that have not upgraded do not enforce the new rules but still accept blocks that follow them.
Taproot, an upgrade already active on Bitcoin, lets coins be locked under several alternative spending paths. It reveals only the path actually used, so holders could keep spending with Schnorr signatures, Nick wrote. A quantum attacker who could forge Schnorr signatures could still spend such an output through the Schnorr path, so the dormant post-quantum path protects coins only if that path is later disabled.
The authors of BIP 360, a Bitcoin Improvement Proposal, defined an output type called pay-to-merkle-root. Nick wrote that the opcode “could ship via Taproot, Taproot v2, or BIP 360 pay-to-merkle-root.” Among his open questions, Nick listed reduced fungibility and privacy, coverage of layer-2 systems, and whether the reference implementation should be C++ code or a formal specification.
Nick wrote in May that SHRINCS “is already deployable in production” and that Blockstream had demonstrated it on Liquid, a sidechain that runs alongside Bitcoin. In its March announcement of that demonstration, Blockstream said it had broadcast Liquid transactions signed with a variant of SHRINCS, checked by a verifier written in the Simplicity smart-contract language.
Blockstream wrote then that the code “still needs thorough auditing and specification finalization.” It added that several critical components of Liquid remain secured by classical cryptography.
Update, November 13, 2026: On August 26, the SHRINCS Working Group posted a first-draft BIP to the Bitcoin developers’ mailing list, with 48-byte public keys, stateful signatures from 548 bytes, and 5,777-byte stateless signatures. The group wrote, “Do NOT use in production.” No BIP number had been assigned to OP_CHECKSHRINCS by November 13.
