NixProtocol's Post-Quantum Research Track

Status: active research. This post describes an in-progress research track, not a shipped product. Specific primitive choices (HAWK, Chipmunk, the Frog ring, Kyber-based encryption, LatticeFold-style folding) reflect our current best bets given today's literature and performance data. They will change as we run benchmarks, as cryptanalytic understanding of these schemes evolves, and as our long-term product goals clarify. Nothing here should be read as a locked-in architectural commitment.

The state of play

Ethereum uses BLS for validator signatures and KZG for data availability. Bitcoin uses ECDSA. Most ZK rollups sit on KZG-based proof systems. NixProtocol v1 uses ECIES over Grumpkin and UltraHonk. Shor's algorithm breaks all of these once a cryptographically relevant quantum computer exists. Nobody knows exactly when that is. Estimates range from 2030 to 2050. The industry knows the threat and has mostly not started migrating.

Privacy protocols have more to lose than most. Anyone who captures encrypted note data today can store it and decrypt it in 2040 when the hardware arrives. For a payments or identity system, that retroactive exposure is worse than the forward-looking signature-forgery risk. So we are starting now.

Three bets

Harvest-now-decrypt-later, applied to privacy, is a real engineering deadline. Not a theoretical one. It means our migration window is shorter than the 15-year quantum-timeline consensus would suggest. Note ciphertexts produced this year need to be safe against a 2040 adversary, which means we need the encryption layer hardened well before then.

Post-quantum signatures inside ZK circuits are the most underdiscussed problem in the ZK ecosystem. When Shor arrives, every ZK proof that verifies an ECDSA or BLS signature inside the circuit becomes forgeable after the fact. Rollup identity systems, bridge proofs, zk-login schemes, auditor-access patterns in privacy protocols. All exposed on that axis. The fix is to embed a post-quantum signature inside the circuit instead. Which PQ signatures are actually circuit-efficient is an open question with no canonical reference. We want to produce that reference.

Gas efficiency is the bottleneck, not the cryptography. Most lattice papers optimize for proof size or signing time. Very few optimize for on-chain verification cost in EVM gas. The people who care about gas do not usually do lattice crypto; the people who do lattice crypto do not usually care about gas. Closing that gap is engineering work: ring parameters, NTT layout, field choice, verifier structure, memory access patterns, all tuned together. That is where NixProtocol's systems orientation earns its keep.

Where this sits relative to v1

NixProtocol v1, live on Avalanche Fuji and Base Sepolia, is a SNARK-based privacy stack. UltraHonk for proofs, ECIES on Grumpkin for note encryption, Poseidon2 for hashing, UTXO nullifiers for unlinkability. It is production-ready. It is also not post-quantum.

The PQ research track runs in parallel. V1 keeps shipping. Users keep using it. Nothing is deprecated. When the PQ stack is production-credible and the performance numbers make sense, we will define an upgrade path, probably starting with hybrid encryption and moving to a full migration later. Rushing that transition would mean shipping worse cryptography, which is the thing we are explicitly trying to avoid.

Our earlier article on post-quantum encryption on-chain covered the ECIES replacement question in detail. This track is wider: signatures, folding proofs, state commitments, and ZK-embedded verification.

The stack we are building toward

One choice in that table deserves explanation. The Frog ring (Z_q[X]/(X^16+1) with q = 15912092521325583641) is the same ring Nethermind's LatticeFold implementation uses for FrogRingNTT. We picked it to keep upstream integration possible if and when their prover reaches production, without forcing algebraic porting work later. Ring choice sounds arcane but it is a hard dependency across the whole stack, and keeping the door open to upstream infrastructure is cheaper than rebuilding against it.

Honest cost accounting

Lattice signatures are kilobytes, not tens of bytes. Public keys are hundreds of bytes to kilobytes. On-chain verification costs more gas than ECDSA. Ring-SIS Merkle proofs are larger than Poseidon2 ones. These are the reasons a fully post-quantum privacy protocol does not exist yet on any production chain, despite the threat being well understood.

Making the numbers tolerable is the hard part. Not the proofs of security, which we can largely inherit from the lattice literature. The work is in the implementation choices: NTT engineering, proof aggregation, circuit-friendly signature selection, and careful verifier design. This is where most of our time goes.

Milestones

We are early in this track, not late. Concrete next steps, roughly in order:

1. Open primitive crates for the Frog ring arithmetic, Ring-SIS state tree, and linear folding. Rust, MIT/Apache, with benchmarks. These ship standalone and do not depend on any chain integration. Other teams can pull them into their own PQ work.
2. Reference paper on IACR ePrint. Scheme definition, assumptions, best-known attacks, concrete parameters, explicit list of what is proved versus what is conjectured.
3. Constraint-count benchmark for PQ signatures inside ZK circuits. HAWK, Falcon, Dilithium, SPHINCS+, XMSS measured under Halo2 and Plonky3. The reference does not exist yet.
4. Private testnet with folded-proof block compression. Target numbers: 2.6 KB folded proofs per block independent of transaction count, light-client verification from the header alone, fully post-quantum assumptions end-to-end.
5. Defined migration path for v1 users.

None of these are done. All of them are scoped. Any of the primitive choices above can be revised if benchmarking, cryptanalysis, or product direction argues for it. We will publish the reasoning when that happens rather than rewrite history quietly.

The first primitive crate, pqe-hawk (pure-Rust port of HAWK-512 with byte-exact FFI cross-checks against the reference C implementation), is already live at github.com/nixprotocol/pqe-hawk. It is testnet-ready and explicitly not audited. The rest are in progress.

Engagement

We will publish the primitive repos with a clear statement of assumptions and a known-attacks section in each scheme. If you find a break, email [email protected] with a proof-of-concept. We will credit you publicly and publish a post-mortem within 30 days.

Teams working on rollups, bridges, or privacy protocols who want to discuss piloting PQ primitives: same address. Most projects in this space will need a post-quantum story within five years. Starting now is cheaper.

Closing

V1 gives you privacy on EVM today. The PQ track is the version that still works when the quantum threat becomes real. Both exist under the same brand, built by the same team, shipped in public with the primitives open for review and attack.