On March 3rd, Blockstream Research demonstrated the use of post-quantum (PQ) signatures on the Liquid Network, the Blockstream powered federated sidechain. Researchers Oleksandr Kurbatov, Viktor Mashtaliar, Dmytrii Kurbatov, Mikhail Kudinov, and stringhandler were able to sign a real Liquid mainnet transaction leveraging Simplicity, Blockstream’s smart contract language, and its capacity to express custom, complex spending conditions to demonstrate what one potential quantum safe signature scheme might look like.
The scheme used for this test transaction was another produce of Blockstream Research: a hash-based algorithm called SHRINCS.
First presented by Director of Research Jonas Nick and cryptography researcher Mikhail Kudinov in December 2025, SHRINCS combines both stateful and stateless hash schemes, attempting to leverage the benefits of stateless signing while reducing the onchain footprint.
Before diving into the technical details, let’s take a moment to define the difference between stateful and stateless cryptographic signatures, highlighting the corresponding trade-offs.
Stateful and Stateless
Stateful hash-based signature schemes, such as XMSS, rely on so-called One-Time Signatures (OTS), where each key-pair must be used exactly once. Reusing a key means breaking the security fundamentals of the cryptographic scheme, allowing attackers to forge signatures and potentially steal funds. Thus, it is crucial to keep track of which keys have already been used (a.k.a. the state) to avoid compromising the funds. This means updating the state after each signature, so that we keep track of which keys have already been used. Holding onto this state introduces a layer of complexity in keys management, making static backups, or ones that aren’t updated after every use, de facto dangerous. Currently, you can find all of your funds from 12 seed words, and can sign for any key under those words without worrying about saving any additional information. A stateful scheme would mean you wouldn’t be able to do this without possibly leaking information and losing funds.
Despite their need to remember every signature, stateful schemes produce smaller size signatures, and require minimal computational effort for verification. The smaller size makes them attractive, particularly when compared to stateless signature schemes.
On the other hand, stateless signature schemes do not need to keep track of which keys have been used, making key management as simple as remembering a static backup, similar to how 12-words work today. The same key-pair can be used multiple times without compromising the safety assumptions behind it. To achieve this, stateless schemes make use of massive, multi-layered trees, which create a pool of possible signatures so large that makes the possibility of using the same key twice statistically irrelevant. As you may have already guessed, this comes at the price of way larger signatures than stateful schemes and a higher computational cost for verification.
SHRINCS: An Hybrid Approach
SHRINCS combines stateful and stateless signature schemes, attempting to take advantage of the strengths of each while mitigating their specific limitations. Specifically, SHRINCS leverages the efficiency in size and verification of a stateful scheme, while allowing users to easily recover their keys and safeguard their funds with a stateless counterpart in case the state is lost.
To achieve this, SHRINCS is built using both a stateless scheme (SPHINCS+) and a stateful scheme (Unbalanced XMSS).
During normal operation, SHRINCS uses the stateful unbalanced XMSS tree, producing a 324 bytes signature, a tiny signature compared to most other PQ signature proposals. The state is updated every time a message is signed and is securely stored, to be sure not to reuse the same key twice.
What happens if we need to restore our keys? As we said, it is not possible to recover a key from a stateful scheme with a static backup, since it would result in compromised security and possible loss of funds. If the state of the keys is ever lost, SHRINCS can fallback to the SPHINCS+ stateless signature scheme instead. Signature size will explode, reaching up to 8KB, but the funds aren’t at risk of being lost or stolen.
Unbalanced XMSS of WOTS
SHRINCS uses a stateful scheme based on an unbalanced XMSS tree of OTSs. This is basically a Merkle tree where each leaves represent an OTS.
To sign, the algorithm chooses a new OTS based on the current state, signs the message, and updates the state to signal that the chosen key should never be used again.
To verify a signature, we have to demonstrate that the OTS we are using belongs to the tree. Thus, the whole authentication path (a.k.a. the Merkle path) need to be provided together with the signature, which requires storing every hash of each sibling node up to the root.
To speed things up, SHRINCS uses an unbalanced tree, which results in a smaller authentication path and, as a consequence, smaller signatures. Moreover, the tree being unbalanced helps simplifying state tracking, since it basically matches the height of the Merkle tree.
The following image helps clarifying this concept. For the first signature, WOTS_1 will be used. The authentication path will be composed only by WOTS_1 sibling hash, while state = 1 . After use, the state will be updated to state = 2 , signaling the algorithm that the next signature would have to use WOTS_2.
To dive deeper in the chosen scheme, let’s analyze each component:
WOTS+C: WOTS is considered the state of the art and the basis for more complex schemes. It is an hash-based signature function and, as the name suggests, a given key pair cannot be used twice. In particular, SHRINCS leverages an extension of WOTS+, called WOTS+C (which stands for “Compact”), which presents reduced signature size.
eXtended Merkle Signature Scheme (XMSS) Tree: It is a hash-based signature scheme that combines OTS with a Merkle tree. Each OTS key represents a leaf in the binary tree, which has a predefined height
h. The internal nodes of the tree represent the hashes of its children, while the root acts as the global public key. To verify an OTS signature, the authentication path (i.e. the Merkle proof, the sequence of sibling nodes from the chosen leaf up to the root) must be computed.Unbalanced Tree: Instead of having all the OTS at the same depth
has in a balanced tree, an unbalanced one allows to minimize the authentication path for the early signatures. In fact, the first OTS will haveheigth = 1, the second oneheigth = 2, and so on, strongly reducing the Merkle proof.
Putting this all together, we obtain the stateful scheme for SHRINCS.
SPHINCS+
The chosen scheme for stateless signing is SPHINCS+, or, as the author suggests, a variant of it.
SPHINCS+ is a complex signature scheme, built using several layers of post-quantum signature utilities, such as WOTSs, Forests Of Random Subsets (FORS), and XMSSs. When combined, SPHINCS+ produces a single quantum safe key-pair which can be used to sign many messages safely. Unlike XMSS, the algorithm doesn’t need to remember anything about prior signatures made with the key-pair for any subsequent signatures. One SPHINCS+ structure produces a single pubkey that can safely sign many messages without revealing the secret key.
This can be achieved because the final structure is huge, and the possibility to choose the same key twice is statistically irrelevant. Of course, this results in heavy signatures compared to those produced by stateful schemes, making them less practical for use in a system with limited space (like blocks).
If you want to know more about this PQ signing scheme, refer to this amazing article by Nifty.
Putting It All Together
To implement SHRINCS, there are four functions that are required: KeyGen, which sets up the initial SHRINCs structure with an Unbalanced XMSS and SPHINCS+ sub-pyramids and returns the top-level public key; Restore, which, given the seed, returns the same public key as KeyGen, and marks the state as LOST; Sign, which returns a valid signature for a message using one of the two sub-schemes (Unbalanced XMSS or SPHINCS+). If the state has been marked as LOST via a call to Restore, it uses SPHINCS+, otherwise, it signs using the Unbalanced XMSS tree. And finally, Verify, which takes a pubkey, a message, and a signature and returns true if the signature verifies, or false if not.
Most signature schemes include a KeyGen, Sign, and Verify methods; Restore is uncommon, as it marks which of the two internal schemes to use.
As outlined by Nick in the Delving post, here’s a more in-depth explanation of how each of the four functions work:
KeyGen(): The algorithm creates a master seed and derives two secret keys, one for the stateful scheme,sk_1, and one for the stateless,sk_2. From these, the function derives the two public keys,pk_1andpk_2. The SHRINCS public key is the hash ofpk_1andpk_2, such thatpk = H(pk_1, pk_2). In the end, the function return the masterseed, the master public keypk, and the initialstateof the stateful scheme.Restore(seed): This function is responsible for recovering the keys and for setting thestatetoLOSTto signal that the stateful scheme cannot be used anymore.Sign(seed, state, m): The signing algorithm first checks whetherstateisLOSTor not:if (state ≠ LOST): The stateful scheme is used, thus the algorithm derivessk_1andpk_2and signs messagemusing the current state andsk_1. Then it returns the updated state,state’along with the signature concatenated withpk_2.else if (state == LOST): The stateless scheme is used, thus the algorithm derivessk_2andpk_1, and signs message m usingsk_2. Then it returns the signature concatenated withpk_1.
Verify(pk, m, sig): The verification algorithm parsessigto obtain the actual signature and the public key concatenated with it. It then verifies the signature according to the signature scheme used, and checks that the two public keys hash to the correct SHRINCSpk.
Algorithmic Agility
A question we could try to give an answer to now is: Is this algorithmic agility?
TL:DR: The short answer is no. Longer answer follows.
The Internet Engineering Task Force (IETF) gives a precise definition of this in RFC7696, which states that “Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time” due to the fact that “advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete”.
Thus, we can see algorithmic agility as the ability for a cryptography-based system to be ready for anything (”in omnia paratus!”) that could happen to the primitives in use.
On the other hand, the goal of the hybrid approach proposed by SHRINCS is not to provide an alternative cryptographic scheme in case the main one gets broken by advancements in research and technology. Instead, it aims to supply users with a fast and efficient signing algorithm, while at the same time providing a safety net that will prevent them from losing their funds due to its already known limitations.
Why Does This Matter?
One of the greatest drawback of PQ signatures scheme is their size. This is not a problem per se, but it becomes so in the context of a decentralized protocol with limited storage capabilities. The smallest PQ signature is 10x larger than the simplest key in use today, allowing for around 3 transactions-per-second (tps), against the 7 tps currently achievable through Schnorr.
SHRINCS is a clever solution, that helps demonstrate the problem space of how to compress known hash-based signature schemes to work for the Bitcoin use case in a PQ world while retaining the current static-backup, 12-word experience that users are accustomed to. The SHRINCS innovation is a great approach for maintaining user experience while balancing the realities of limited blockspace.
On May 12th, Blockstream Research presented a first proposal for a hash-based signature Opcode for Post-Quantum Bitcoin, called OP_CHECKSHRINCS , leveraging SHRINCS as the chosen signature scheme. Research is continuing to prepare a quantum-secure future for Bitcoin.