What happened
On 26 August 2026 the first draft of SHRINCS was posted to the Bitcoin development mailing list as "SHRINCS: an efficient hash-based signature scheme for Bitcoin (first draft)", and the specification itself carries six authors: conduition, Ethan Heilman, Mikhail Kudinov, Oleksandr Kurbatov, Jonas Nick and remix7531. It has no BIP number and its status is "Draft". The text describes "a hash-based post-quantum signature scheme, for use in Bitcoin transaction authorization" that "combines compact stateful hash-based signatures with a stateless fallback", and it has been revised through 4 September. The specification was rechecked on 16 September: its security proof is still marked TODO. These are design targets for an experimental scheme, not a completed security proof.
What it changes
Bitcoin's current signatures, including the Schnorr signatures Taproot introduced, rest on the difficulty of one discrete-logarithm problem. Hash-based signatures rest on nothing but the hash function, which for SHRINCS is SHA256, and the draft is explicit that this conservatism is the point for outputs that "may remain unspent for long periods".
The cost of that conservatism has always been size, and this is a proposal about size. A SHRINCS public key is 48 bytes. A stateful signature runs from 548 to 4,619 bytes, and the draft claims the smallest combined public key and signature is "roughly 13.23x smaller than that of SLH-DSA-SHA2-128s and 6.26x smaller than that of the lattice-based ML-DSA-44", at its stated NIST category 1 target. The ML-DSA-44 comparison uses a different security category, category 2.
"Stateful" is where the interesting engineering sits. A stateful scheme holds a budget of one-time keys, with the number determined by its tree, and the signer must record which ones it has spent, because reusing a counter under the same key lets a forger produce valid signatures. That is an unforgiving invariant to hand a wallet, a backup, or a restored device. SHRINCS answers it by giving every keypair a stateless fallback, 5,777 bytes, so a signer that has lost track of its state pays in block space rather than in security.
Verification is cheap per byte and dearer per signature: 255 to 509 SHA256 compressions for a stateful signature and up to 2,792 for a stateless one, against roughly 127 compression equivalents for a BIP340 Schnorr signature.
What it does not change
The draft proposes no soft fork, no new output type and no witness version. It specifies a scheme; how Bitcoin would ever accept one is a separate argument that has not been had.
Nor does it make the sizes small. A Schnorr signature is 64 bytes. The best case here is roughly eight and a half times that, the fallback roughly ninety times, and block space is the scarce thing being spent. Larger witnesses would consume more block space under unchanged limits; the eventual capacity effect would depend on the integration and its rules.
It also does nothing for coins already sitting at addresses whose public keys are visible on chain. A new signature scheme protects what is locked under it, which is why the other line of work is about keeping the public key hidden until the moment of spending. Replacing the signature scheme of a system with money already locked to the old one is a migration problem before it is a cryptography problem, which is what crypto-agility names.
Context
This is the second family of candidate replacements to reach a written comparison in as many weeks. Blockstream Research's review of the lattice schemes, published the same day as this draft, put Falcon-1024 ahead of Dilithium and noted Hawk's withdrawal after a key-recovery attack; Mikhail Kudinov is an author of both documents. Lattices rest on newer assumptions and give smaller signatures. Hashes rest on an assumption Bitcoin already makes everywhere and give larger ones, with a state-management burden the stateless fallback is designed to survive.
Both are drafts. What they have in common is that the argument has moved from whether to replace the signatures to what the replacement costs per transaction, which is a more useful argument to be having.