1.  Why Plan for PQ Migration Now

The migration question

Organizations around the world are considering upgrading their security stacks to be resilient to adversaries with quantum computing capabilities, commonly referred to as a “cryptographically relevant quantum computer” (CRQC). Regardless of the credibility of CRQCs becoming a reality in the near future, events like NIST disallowing quantum vulnerable cryptosystems (in the 2030s) mean that organizations that wish to stay compliant with standards must have a “post-quantum” (PQ) migration plan.

It is broadly accepted that migration timelines for encryption and signatures are driven by different levels of urgency as well as cost considerations. Particularly in the blockchain domain, the cost implications of a naive migration are profound, illustrated by the fact that the smallest standard PQ signature is at present larger than an entire ECDSA-authenticated transaction. Justin Thaler discussed the issue at length in a recent a16z crypto blog post, and the recent position paper by Coinbase gave a comprehensive accounting as well. The lower level of urgency, and high stakes for PQ signature migration allows us some space to explore the various downstream implications of choosing to migrate to one signature scheme versus another.

Industry deadlines, in writing

In March of this year, Google announced an internal 2029 PQ migration target, which was soon matched by Cloudflare. As for the US government, NSA CNSA 2.0 mandates ML-DSA-87 for US National Security Systems with software/firmware signing exclusive by 2030 and full NSS PQ resistance by 2035. NIST IR 8547 sets deprecation of classical signatures by 2030 and removal by 2035. The EU’s DORA (in force January 2025) does not mandate switching to post-quantum technologies directly, however it requires the systems to be crypto-agile and remain up to date with current cryptanalysis including threats from quantum advancements. Combined, these set an industry-wide deployment window of roughly five to ten years.

Blockchain has started to move

Vitalik’s November 2025 thesis on de-enshrining ECDSA and Justin Drake’s “Lean Ethereum” announcement (https://blog.ethereum.org/2025/07/31/lean-ethereum) are among the most prominent signals at the protocol layer. On Bitcoin, BIP-360 (Beast et al., December 2024; https://bips.dev/360/) introduces a SegWit v2 quantum-resistant address format with both ML-DSA and SPHINCS+ tapscript opcodes. Algorand has had Falcon-1024 state proofs live since 2022. The chains are moving on different schemes, and that is exactly the case for an abstraction layer above them.

Figure 2.  Cryptanalysis milestones (above) and standards-body deadlines (below). The window between them is the deployment window.

2.  What This Means for Blockchain

Every classical signature on a public chain breaks under Shor’s algorithm on a CRQC: ECDSA on Bitcoin and Ethereum, EdDSA on Solana / Aptos / Sui / Cardano / Algorand, Schnorr on Bitcoin Taproot, BLS on Ethereum consensus and most bridges. The substantive question is which post-quantum signature should take their place.

While there have been several candidates for PQ signatures across multiple families of cryptography, NIST has standardized four signature schemes:

3.  Mistakes Not to Repeat

A useful PQ signature for institutions has to satisfy four properties at once: deployable in the HSMs and KMS APIs they already run; compatible with current threshold-signing architectures; and composable across multiple chains. Three earlier signature standardizations did not fully account for the second and third, and the industry is still cleaning up:

We see a clear pattern start to emerge, in that locally optimal choices have led to substantial costs in retrofitting threshold protocols, precompiles, and translation layers down the line. abhi shelat’s keynote address at DeCompute ‘24, “The Shackles of Legacy” explored a similar theme at length.

We argue that any PQ scheme that institutions choose to standardize—lattice, hash-based, or hybrid—needs a credible threshold-signing story before deployment. Section 7 walks each NIST scheme through that lens.

4.  Why MPC — and Why MPC-Friendliness

There are several factors that determine the choice of a cryptographic algorithm, including the plausibility of its hardness assumption, ease of secure implementation, and resilience to side channel attacks among other considerations. One relatively new concern is the “MPC friendliness” of the algorithm, particularly for signature schemes. It is common today to decentralize signature generation using Multiparty Computation (MPC) techniques, especially in the digital asset custody domain. The decentralization of spending authority—also known as threshold signing—adds an important layer of security, and is a standard practice in the industry today.

The notion that different signature schemes can entail vastly different MPC complexities is already well understood in the classical context. With elliptic curves for instance, threshold signing with BLS is almost trivial, Schnorr/EdDSA is the next easiest, and ECDSA requires more effort (but remains practical). RSA supports very efficient distributed signing once the key has been sampled, however distributed key generation is very complex. It is therefore not unprecedented that a similar disparity should emerge amongst post-quantum signatures.

5.  Silence Laboratories’ PQ + MPC Initiative

At Silence Laboratories, we have been investigating the MPC-friendliness of different standardized post-quantum schemes, by tracking the academic literature as well as through in-house research. We restricted our scope to the NIST-standardized schemes: Dilithium (ML-DSA), Falcon (FN-DSA), Sphincs+ (SLH-DSA), and XMSS as they are bound to comprise the choices available in many contexts.

6.  How to Evaluate MPC-Friendliness?

Readers with a cursory knowledge of MPC and threshold signatures may be aware that “linear” operations are generally easier to decentralize. This is because most natural secret sharing schemes enable parties to derive linear functions of secrets (a*[x]+b*[y], where a,b are public and [x], [y] secret values) by simple local transformations of their shares.

One may draw some broad intuitive lessons about MPC friendliness from the literature. Schnorr’s scheme is in many ways a canonical baseline, as the signing equation is simply a linear combination of the secret key and nonce—a[x]+[y] where [x] is the signing key, [y] the nonce, and a=H(R,pk,m) is a public value. Next, ECDSA entails a non-linear signing equation (m+r*[x])/[y], which with some clever rewriting can be reduced to one or two secure multiplications in the scalar field of the elliptic curve. This in itself has been the subject of theoretical study and years of research. Symmetric key primitives on the other hand—particularly standardized ones—can be highly nonlinear with functions like SHA3 requiring tens of thousands of secure multiplications (mod 2, aka logical AND). The lack of algebraic structure in such primitives makes workarounds for efficient MPC highly unlikely. 

Beyond these basic observations, there is no widely accepted methodology for gauging MPC-friendliness of a signature scheme—each construction (or family of constructions) will have to be carefully evaluated. In the next section, we elaborate on the lessons so far from the state of the art in research on decentralizing the established post quantum standards.

7.  The NIST PQ Signatures

Our high-level takeaway is that from an MPC perspective, Dilithium has the simplest structure among these schemes, and is well positioned to enable performant threshold signing deployments particularly for digital asset custody use cases. This is perhaps a side effect of Dilithium being explicitly designed to be simple to implement. In contrast, Falcon is heavily optimized for signature size, which wins its favour in space-sensitive domains such as blockchains, but comes at the expense of a complex structure that makes threshold signing difficult. Finally, the hash based schemes SLH-DSA and XMSS suffer inherent provable barriers to concretely efficient threshold signing, at least with standard hash functions such as SHA2/3. While it may be possible to threshold sign XMSS in limited circumstances, hash based schemes in general appear to provide the least appealing structure for MPC.

7.1 Dilithium / ML-DSA

Dilithium, now standardized as ML-DSA, is inspired in its design by Schnorr’s signature. At a high level, Dilithium, like Schnorr, can be interpreted as a three-round interactive identification protocol (in a commit-challenge-response format) that is compiled into a non-interactive proof using the Fiat-Shamir transform. However, Dilithium draws its hardness from lattice problems, which are believed to withstand quantum adversaries. Given the structural similarity with Schnorr, it stands to reason that Dilithium should inherit some of its qualities, perhaps even its MPC-friendliness.

Lattice based constructions are in many ways more expressive compared to discrete logarithm based cryptography, but unfortunately working with lattices is rarely as clean. While elliptic curves only admit generic algebraic attacks and thus are believed to yield optimal hardness, the hardness of lattice problems also relies on the geometry of the underlying lattice and requires us to argue about short secret and short signature vectors in high dimensions. The naive masking of secret values in a short signature vector requires substantially larger parameters compared to elliptic curves. This has resulted in schemes like Dilithium resorting to space saving tricks, that make its decentralization less straightforward than Schnorr. One prominent example is its use of rejection sampling. Put simply, while Dilithium signing can abstractly be characterized as linear combinations of the form z=a[x]+[y] like Schnorr, even though a, [x], and [y] may be individually valid values, not every z=a[x]+[y] is a valid signature—signing therefore entails trying different candidate z values until a valid one is found. This is because not every z is safe to reveal, as z values that are “too large” may inadvertently leak bits of the signing key. For the MPC setting, this means that one can not naively reveal a[x]+[y] values to all signers as one would do for Schnorr, as corrupt signers may obtain leakage on the shared signing key.

While Dilithium is not as straightforward as Schnorr for decentralization, the community has found ways to make it work, and maturity for threshold signing is on the horizon. One can broadly categorize known approaches into two types: generic MPC, and partial signature aggregation. The rejection sampling step—i.e. testing for validity of z—essentially entails a range check, which is not prohibitively expensive to implement with generic MPC tools as demonstrated in recent works by Bienstock et al. and Dufka et al. The partial signature aggregation approach exploits the fact that the parameterization of Dilithium is not “tight”; it deliberately allows for some slack in parameters in order to support a signing algorithm that is easier to implement securely. This slack permits a Schnorr-esque threshold signing protocol wherein signers interactively compute “partial” signatures structurally similar to an individual one. Then, simply aggregating them in the clear yields a full signature that passes standard verification. Importantly, the partial signatures are sampled within tighter bounds compared to Dilithium itself, so that when aggregated, the resulting signature has a high chance of remaining within the bound enforced by Dilithium verification. Celi et al. employed the hyperball-based rejection sampling method of Devevey et al. to achieve this effect and construct a threshold signing protocol for Dilithium. An important caveat is that the number of signers supported by their protocol is determined by the gap in efficiency between the canonical hypercube based rejection sampling method of the Dilithium standard, and the tighter hyperball-based rejection sampling. In practice their protocol can handle up to six signers, which is already good enough for custody related use-cases.

7.2 Falcon / FN-DSA

While Dilithium implements a lattice-based version of Schnorr, Falcon follows a different paradigm: the “hash and sign” method. Roughly, the public and private keys in Falcon are bases of the same NTRU lattice, the difference being that the private key is short, and the public key is relatively long. Signing entails hashing the message to a challenge vector, and using the short private basis to find the closest point on the lattice to it. Then the proximity can be verified using the long public basis.

Unfortunately, neither of the methods to decentralize Dilithium are known to translate to Falcon. For one, Falcon is highly optimized for signature size over all else, and so unlike Dilithium it does not leave obvious slack to allow for partial signatures to be aggregated. Given the tight proximity of the sampler in Falcon to the expected length of the shortest basis in the NTRU lattice, translating the partial signature approach of Dilithium to Falcon seems challenging. Generic MPC is not straightforward to adapt to Falcon either. In particular, the sampler in Falcon as written makes use of high precision floating point arithmetic, for which known generic MPC techniques yield prohibitively expensive latencies for threshold signing applications. Moreover, the sampler induces a relatively deep circuit representation, which translates to high round complexity for many classes of MPC techniques.

Threshold signing for Falcon is not a mature research area, to be able to draw definitive conclusions. What we can say however, is that between the two lattice-based schemes, the case for Dilithium's MPC-friendliness is substantially more evident.

7.3 Hash-based Schemes: SLH-DSA and XMSS

Departing from lattice based cryptography, the hash-based signature schemes SLH-DSA/Sphincs+ and XMSS base their security on hash functions alone. They are easy to understand and implement, and are widely considered to be the most conservative schemes available in terms of security assumptions. However, the only known method of decentralizing their computation is to evaluate their circuit representations in generic MPC. This is quite expensive; hash functions like SHA3 are highly nonlinear and induce circuits with tens of thousands of AND gates, meaning that securely evaluating tens or hundreds of thousands of hashes as required for signing would be much too slow for most applications.

Unfortunately there is evidence that this cost is inherent. Doerner et al. showed that threshold signing for certain types of hash based signatures must necessarily make use of the circuit representation of the hash function. The broad intuition of their result is that when signing with such schemes, there are a number of unavoidable private queries to the hash function that are ultimately never revealed by the signer—exposing them would lead to forgeries or even outright secret key recovery. This follows from a “straightline witness extraction” property that characterizes the schemes that they consider. In the multiparty signing setting, these private queries must not be exposed to any individual signer, meaning that the hash function must be evaluated upon these queries via a secure multiparty computation. A recent workshop talk by Kumar presented ongoing research that generalizes and extends the techniques of Doerner et al. to apply to SLH-DSA and XMSS as well.

While it may be possible to achieve limited notions of decentralization such as through a trusted dealer for XMSS (Kelsey et al.) or replacing the dealer with expensive per-signature preprocessing, the evidence indicates that hash-based signatures will in general pose barriers to efficient threshold signing.

8.  Where the Stack Is Already Converging

Outside of blockchain, ML-DSA adoption has run faster than the other PQ schemes, for two reasons that matter to institutions.

HSMs are widely considered by institutions to be the most conservative deployment surface in cryptography—vendors do not ship algorithms that are not certified, audited, and validated. As of April 2026, Thales Luna v7.9, Entrust nShield v13.8.0, and Utimaco Quantum Protect all ship NIST-CAVP-validated ML-DSA in production; none ships Falcon. CNSA 2.0 cited Falcon’s implementation complexity and side-channel exposure as the reason. Custodians, banks, and CAs effectively cannot deploy a signing scheme without HSM support.

The standards and infrastructure layers have followed the same path. FIPS 204 (ML-DSA) was finalised August 13, 2024; FIPS 206 (Falcon) remains in draft. NSA CNSA 2.0 mandates ML-DSA-87 for National Security Systems. RFC 9881 specifies X.509 algorithm identifiers for ML-DSA; working-group drafts cover ML-DSA in TLS 1.3, CMS, COSE, and SSH. AWS KMS and Private CA went GA on ML-DSA in 2025; Google Cloud KMS preview shipped February 2025; Cloudflare scheduled ML-DSA for origin connections by mid-2026. Android 17 ships native ML-DSA across Keystore, Verified Boot, Play App Signing, and Remote Attestation. Germany’s BSI / Bundesdruckerei eID demonstrator runs on ML-DSA; ICAO Doc 9303 is updating to ML-DSA for the ePassport PKD across 90+ countries.

To our knowledge, every regulated and infrastructure-grade stack that has shipped a PQ signature standard has shipped ML-DSA first. 

9.  Where the Chains Are Landing

On-chain decisions diverge: pragmatists are converging on ML-DSA precompiles, conservatives push hash-based, Falcon survives in Algorand and pockets of Ethereum thinking. The fragmentation across chains is itself the architectural case for an MPC abstraction layer above them.

Ethereum’s strategy is instructive: hash-based at consensus, signature-agnostic at execution via account abstraction plus precompiles for both ML-DSA and Falcon. Picking a single scheme at execution would force every wallet, custodian, and passkey integration to rebuild around its tradeoffs. The same insight motivates an MPC layer above the chains rather than a single-scheme institutional standard.

10.  MPC as the Institutional PQ Layer

Institutions that serve multiple chains do not have the option to pick a single PQ scheme. MPC threshold signing has five concrete properties that matter:

• Multi-authorisation without the multisig tax. — A 2-of-3 smart contract costs 263,000 gas to deploy and 6–10K gas per signature. An MPC-produced signature is indistinguishable from a standard EOA signature on-chain at 21,000 gas.

• Private quorum. — A SC wallet reveals its threshold and signers on-chain, whereas MPC in general reveals neither.

• Chain-agnostic composition and crypto-agility. — MPC produces whatever signature the chain accepts — Bitcoin Schnorr, Ethereum ECDSA, future ML-DSA. The same property gives crypto-agility: a custodian can swap ECDSA → ML-DSA internally without any on-chain change. This is what DORA actually requires.

• Policy off-chain. — Counterparty whitelists, amount thresholds, time-locks, geographic constraints live in the policy engine, not on-chain.

• Tiered signers. — Hot / warm / cold co-signer architectures place shares in different security tiers; on-chain multisig forces all signers to be equivalently reachable.

The broad market adoption of MPC validates these advantages. Roughly 68% of institutional digital asset custody runs on MPC (ChainUp 2025). Fireblocks reports $10T+ lifetime transaction volume across 2,400+ organisations; BitGo reports $100B+ assets across 4,600+ institutional clients. MiCA’s strict CASP liability, DORA’s crypto-agility requirement, and Hong Kong SFC’s 2025 reversal of its HSM-only posture have together made MPC the regulator-compatible default for digital asset infrastructure. Tier-1 bank pilots are live on MPC-anchored infrastructure (JPMorgan Kinexys, HSBC Orion, Citi Token Services, SocGen FORGE).

The institutional layer also extends beyond custody. Cross-chain bridges have been the largest single source of crypto loss ($3B+ across Ronin, Wormhole, Nomad, Multichain); MPC-secured bridges replace single-validator-holds-the-key with threshold validation. Passkey portability and account-abstraction wallets use the same architecture

11.  Closing

In an upcoming blog post we will elaborate on the issues involved by exploring the underlying technical aspects. In the meantime, we welcome you to reach out to us at Silence Laboratories to learn more about threshold signing, post-quantum security, and MPC in general.

The choice of which PQ signature to use may have implications that underlie every signed transaction, message, and document for the next several decades. In this post, particularly Sections 6 and 7, we have given our preliminary evaluation of the MPC-friendliness of the available standard schemes. We strongly advocate for standards chosen by chains and institutions to have a credible threshold story before deployment.