The previous post shared a general overview of quantum computers and explained that the quantum threat is not here yet. But it is clear that the day will come when quantum computers become a reality. This blog post is specifically about Nimiq. Like every blockchain, Nimiq secures real value with cryptography that a large enough quantum computer could eventually break, and we have been researching what that could mean for our blockchain. What follows is an analysis of where our cryptography stands today and how we plan to start moving toward post-quantum security without weakening the protections that keep the network safe.
If there is no imminent quantum threat, why start now?
Because cryptographic infrastructure moves slowly.
Changing the signing algorithms used by wallets, validators, and proof systems requires protocol upgrades, ecosystem-wide adoption, and years of testing.
The NIST standardization process for post-quantum (PQ) cryptography began almost a decade ago and is only now producing final standards.
Migrating a live blockchain while preserving security for existing users is not a problem you solve in a sprint.
The prudent approach is to treat quantum computing the way an engineer treats a slow-moving but certain geological process:
You don't wait for the earthquake to start reinforcing the building.
The threat is not imminent.
The preparation is.
What follows is Nimiq's honest account of where our cryptography stands today, what needs to change, and how we intend to make those changes without sacrificing the security properties that matter right now, against the adversaries that exist right now.
Where Nimiq's cryptography stands today
To talk concretely about migration, we have to be specific about what's actually in the protocol. Nimiq's cryptographic stack rests on four pillars:
- BLS signatures over the MNT4/6-753 curves, used by validators to sign macro blocks. The key property here is aggregation: all of validator signatures collapse into a single short signature.
- Ed25519 (Schnorr) signatures for user accounts and micro block signing, with passkeys as an additional option for accounts backed by WebAuthn-compatible authenticators (P-256 ECDSA).
- Groth16 recursive zkSNARKs, also over MNT4/6-753, underpinning Nimiq's light-client and succinct-history architecture.
- Blake2b and Blake2s as the main hash functions throughout the protocol (our contracts support a few others too).
Of these, only the last one is comfortable. Hash functions face Grover's algorithm at worst, and as the physics section explained, that's a quadratic speedup, which is easily absorbed by the output sizes we already use.
The other three pillars all rely, ultimately, on the hardness of elliptic-curve discrete logarithms or on pairing-based assumptions on those curves. Shor's algorithm breaks all of them. So every signing and proving layer in Nimiq needs a post-quantum story.
Two principles guide how we want to write those stories:
We will not weaken Nimiq's security in the name of preparing for quantum. Any change we make should leave Nimiq at least as secure as it is today against classical attackers, while adding protection against quantum ones. Adopting a younger, less-scrutinized primitive because it carries the "post-quantum" label, against a threat that doesn't yet exist, could leave us more exposed than before.
The community needs lead time. Anything that touches user keys, wallets, or validator software has to be announced and shipped well before it's actually load-bearing. We're aiming to have the major pieces in place by 2029, with earlier milestones for the parts that need the most runway. To be clear: 2029 is not a prediction about when quantum computers will threaten Nimiq. It's a target chosen to give the community enough buffer between "PQ is available" and "PQ is required."
The consensus layer: BLS aggregation is the hard problem
This is where we currently face the largest uncertainty: there is no plug-and-play post-quantum replacement for BLS aggregation. None of the standardized and existing PQ signature schemes supports anything like BLS's one-shot, non-interactive aggregation. Research-stage PQ aggregate and threshold schemes do exist, but they typically require multiple rounds of interaction during signing, produce signatures orders of magnitude larger than BLS, or both. And by our first principle, they're significantly younger and less battle-tested than what they'd be replacing.
We see two realistic paths and want to start a conversation about which (or which combination) makes sense for Nimiq.
Path A: SNARK-aggregated hash-based signatures. Each validator signs with a hash-based scheme (in the XMSS / leanXMSS family for stateful signing, or SLH-DSA / leanSPHINCS for stateless), and per-block aggregation happens by generating a succinct proof that some threshold of valid signatures exists. The construction leans on hash-function security, which we already trust deeply. This is conceptually the cleanest answer and is roughly the direction Ethereum is heading. This will come at a cost: PQ SNARK proving is expensive, the proof systems are themselves still maturing, and the "SNARK-friendly" hashes that make proving practical (Poseidon and its relatives) are much younger than Blake2 or the SHA family (and come with their own security issues).
Path B: Staged migration with PQ checkpoints. Keep BLS for the day-to-day consensus signatures for now, but layer on periodic PQ-signed checkpoints, e.g., every election block, validators co-sign the current chain tip with a PQ scheme. Because every block already hash-chains to its predecessor, a single trustworthy PQ checkpoint retroactively anchors all the history before it against forgery. If BLS were ever broken, the damage would be bound to the window since the last checkpoint, and that window could be resolved through social consensus. This buys us years to let the PQ aggregation landscape mature before we commit to a specific scheme.
Our current thinking leans toward starting with Path B as a near-term safety net while we work toward Path A as the long-term answer. We genuinely want community input on this.
The execution layer: protecting user accounts without breaking them
Nimiq accounts are protected today by Ed25519 Schnorr signatures, with ECDSA passkeys as an alternative. Both are Shor-vulnerable. Addresses are derived by hashing the public key, which matters for what attacks become possible once key material is exposed.
The naïve fix would be to swap Ed25519 for ML-DSA tomorrow. We're not going to do that. Ed25519 has more than a decade of intense cryptanalytic scrutiny behind it. ML-DSA is excellent work and we have no specific reason to doubt it, but it is years rather than decades old. Trading well-understood security against the adversary that actually exists today for hypothetical security against an adversary that doesn't yet exist is, in our view, a downgrade.
What we'd build toward instead is a hybrid scheme that combines a classical signature (Ed25519 today, or a passkey) with one or more post-quantum signatures. There are two flavors of this we're actively weighing, and we'll come back to the choice between them at the end of this section.
The first is a 1-of-N scheme, achievable through our existing 1-of-N signing functionality: addresses can be derived from a Merkle tree whose leaves are valid public keys, potentially under different signature schemes. The second is a 2-of-2 scheme, where every transaction requires both a classical and a PQ signature.
In the 1-of-N variant, a user could already commit today to a tree containing their current Ed25519 (or passkey) public key as one leaf and a post-quantum public key as another. Spending requires revealing one leaf and producing a valid signature under that scheme. Until the day Nimiq decides PQ has to take over, users sign with Ed25519 exactly as they do now, with minimal extra cost in signature size. The PQ leaf stays hidden behind a hash, contributing nothing to the attack surface. When the network decides the time has come, it stops accepting Ed25519 leaves and PQ takes over.
This approach has an important property: as long as the PQ leaf remains unrevealed, the only way to forge a current transaction is to break Ed25519. Adopting the hybrid doesn't lower the security bar today, it just adds a second floor for tomorrow. And because the construction is genuinely 1-of-N rather than 1-of-2, users (or wallet software on their behalf) can commit to multiple PQ schemes simultaneously (e.g., a lattice-based one and a hash-based one), hedging against the possibility that any single PQ family turns out to need replacement. The address itself becomes crypto-agile.
In the 2-of-2 variant, every transaction is signed under both an Ed25519 (or passkey) key and a PQ key from day one. This is strictly stronger against today's adversary: forging a transaction requires breaking both schemes, not just one. The trade-off is that users pay the PQ cost (larger signatures, more verification work) on every transaction, not only when PQ becomes necessary. There's no "switchover day"; the PQ leg is simply load-bearing from the moment a user opts in.
The 1-of-N variant optimizes for cost-today and flexibility; the 2-of-2 variant optimizes for unconditional security improvement. We're still working out which one fits Nimiq better, and we'd like the community to weigh in (see below).
The work here is mostly convention, tooling, and wallet UX, not protocol changes at the address layer. Concretely: we want to make multi-leaf Merkle addresses the recommended default for new accounts, give wallets the affordances to generate and back up the PQ leaves correctly, and ensure the path from "today's account" to "PQ-protected account" is something a normal user can complete without expert help.
There's also a path that costs users nothing at all. The Ed25519 standard computes the signing scalar as s = H(k) for a 32-byte seed k. That means every existing Nimiq account already holds the preimage needed for a hash-based ZK proof of "I know the seed that produced this public key", which allows PQ recovery with no separate PQ key and no user action required. The Merkle-tree hybrid above remains the right path for users who want to commit explicitly to a specific PQ scheme, but for everyone else, PQ recoverability is already latent in the keys they hold.
Passkeys are a harder open question. The user doesn't choose the signing primitive there, but the authenticator hardware does. The PQ migration of the WebAuthn / FIDO ecosystem is outside our control, and our timeline depends on theirs. We're tracking this closely and would rather not commit to a specific passkey solution before the broader ecosystem settles on one. The good news is that the Merkle-tree address structure handles this gracefully: a passkey can simply be one leaf among several, with a separately-managed PQ leaf as a fallback.
The proving layer: Groth16 is the most structural problem
Of all Nimiq's cryptography, the Zero-Knowledge Proof scheme used in the protocol (Groth16 zkSNARKs) might be the most clearly quantum-broken. Pairing-based proof systems don't just lose privacy under a quantum attacker, they lose soundness: false statements become provable. For a protocol where Groth16 underpins recursive proofs of chain history and light-client verification, this is a crucial problem, and one we don't want hanging over us.
This has us seriously considering retiring Groth16 from Nimiq early, ahead of the rest of the PQ migration, and falling back to direct verification of the underlying BLS signatures on election blocks until a hash-based recursive proof system is ready to take over. We're leaning toward this, though the decision isn't final, and we want to lay out the reasoning here.
What makes this deliberation plausible is that the alternative turns out to be cheaper than it might sound. Verifying a macro block's BLS signature directly costs roughly 23 ms in steady state (the pairing check itself is ~18 ms; G2 key validation is the rest, and is cached across epochs because validator sets persist). Nimiq produces two election blocks per day, so a light client catching up on a year of history pays a few seconds of BLS verification. The SNARK was compressing this work, but the work itself was never a real bottleneck. Furthermore, the sync is a one-time cost per node as opposed to recurring costs during running of the node.
Either way, the longer-term answer is the same: hash-based recursive proving. Hash-based proof systems (FRI-based STARKs, the newer hash-based SNARKs being built for projects like leanVM) are largely unaffected by quantum attackers, modulo some tightening of soundness parameters to account for Grover, and they restore the succinct sync property that Groth16 was providing. PQ proofs are typically larger and proving is more expensive, but the verification cost, which is what matters for light clients, stays low.
Migrating to a hash-based recursive system is a substantial engineering effort, and some of the design choices the MNT4/6-753 stack made specifically to enable efficient pairing-based recursion are unlikely to be the right choices for a hash-based system. We'll be working out where the new constraints actually bind, in close coordination with the BLS replacement on the consensus side. The two are tightly coupled, since whatever signature scheme validators move to has to be efficiently verifiable inside whatever proof system we land on. We're treating this as the longest-lead-time item on the roadmap.
One caveat we want to be transparent about: high-performance hash-based proving leans heavily on SNARK-friendly hashes like Poseidon, and Poseidon's security has received noticeably less scrutiny than Blake2 or SHA. We're glad to see initiatives like the Poseidon Initiative pushing on this, but we'd rather not put load-bearing weight on a hash function we don't yet trust as deeply.
Crypto-agility: building the change in, not bolting it on
A theme running through all three layers: the migration itself should be designed so that we never have to do another one this painfully. Cryptographic schemes get broken (MD5, SHA-1, SIKE). Key sizes need to grow (RSA-1024 → RSA-2048). Post-quantum schemes in particular are young enough that some of them will probably need to be replaced again as we learn more.
So we want to bake crypto-agility into the migration itself and integrate some protocol-level support for switching signature schemes, proof systems, or hashes. There is a fine line between agility and overengineering to be taken, and we will follow this route only where it makes sense. At the address layer, the Merkle-tree construction described above is already a form of this and will dramatically simplify our PQ migration route.
What about abandoned coins?
Every chain doing a PQ migration eventually has to decide what happens to balances held by owners who never migrate. The options reduce, roughly, to "flag day" (after some date, classical-only accounts are frozen) or "leave them" (in which case they become a juicy target for the first quantum attacker who shows up).
We don't think we should pre-announce a position on this without community input. Both options have real downsides: users who simply didn't see the announcement losing funds is bad; leaving a quantum honeypot for the first capable adversary is also bad. But one thing we're confident about: not deciding is itself a decision, and the resulting uncertainty has costs of its own. We'd rather start the community conversation early and arrive at a clear answer well before it matters than discover at the last minute that we have to.
This blog post introduced a technical foundation on Quantum-Resistant technologies and how Nimiq plans to take the first steps on this journey. There is more to come, see you in the next blog post.
Pura Vida
Team Nimiq