Kaspa Kii posted a dense technical update on June 25: three post-quantum signature schemes were verified inside a zkVM, compressed into succinct proofs, and checked on Kaspa testnet with negative controls. The important part is not the slogan "post-quantum Kaspa." That would be too broad. The useful claim is narrower: Kii showed a post-quantum signature-verification path that can be proven off-chain and checked on-chain through Kaspa's emerging ZK and covenant stack. (Kii post)
That distinction matters because several different things can be "quantum-safe" or not: the signature scheme that authorizes a spend, the normal transaction envelope, the mining function, and the UTXO commitment layer. Kii's own clarification says the current result is about spend authorization, while ordinary transactions still use secp256k1 Schnorr and mining still uses kHeavyHash proof of work. In other words: this is a testnet proof-of-concept for a post-quantum authorization layer, not a claim that every layer of Kaspa has become post-quantum. (Kii clarification)
The Short Version
Kii tested whether a Kaspa script path can accept a zero-knowledge proof that says: a specific post-quantum signature verifier ran, over a specific public key and message, and accepted the signature. The signature verification itself happens inside a RISC Zero zkVM. The resulting proof is then checked by a Kaspa node using the KIP-16 ZK precompile opcode, which was proposed for verifiable computation on Kaspa and is active on testnet-10. (Kii post, KIP-16)
This is different from putting a post-quantum signature directly into the normal transaction format. The transaction still has the usual classical wrapper. The post-quantum part is inside the covenant/proof logic that decides whether a specific coin can move. That is why Kii calls the scope the "signature layer" and not the whole network. (Kii clarification)
What Was Actually Tested
The three signature families in Kii's table are the current NIST post-quantum signature track: ML-DSA, SLH-DSA, and FN-DSA/Falcon. NIST finalized ML-DSA as FIPS 204 and SLH-DSA as FIPS 205 in August 2024. FN-DSA, based on Falcon, is still moving through the FIPS 206 process, which is why Kii treated it more cautiously than the two finalized standards. (FIPS 204, FIPS 205, FIPS 206 presentation)
Kii's pipeline is: run the verifier inside a zkVM, produce a proof that the verifier accepted, then have Kaspa verify that proof on-chain. RISC Zero's model uses an image ID to identify the exact guest program and a journal for committed public outputs, so a valid receipt is meant to attest that a particular program ran and produced a particular public result. Kii's clarification leaned on that distinction: the proof is not just binding data together, it is proving execution of the verifier code that accepted the committed inputs. (RISC Zero terminology, Kii clarification)
Kii also ran negative controls. That matters. A cryptographic demo is much less interesting if the verifier accepts everything or if the proof is not actually tied to the intended message. Kii says the valid cases accepted, the tampered cases rejected, and the replayed spend did not move the second coin. (Kii post, Kii clarification)
Why The PQ-UTXO Is The Real Spend Story
The easiest place to misunderstand the post is the table of three signature verifications. Those table rows show that three post-quantum verifier programs can be proven and checked on-chain. By themselves, Kii says, those are replayable attestations. They prove a verifier accepted a signature over a message, but they do not automatically authorize a unique UTXO spend. (Kii clarification)
The spend-binding part is separate. Kii also built a "PQ-secured UTXO" using ML-DSA. A UTXO is just a coin-like output: if you can satisfy its spending rules, you can move it. In this construction, the covenant reconstructs the signed message from the transaction itself, including the input outpoint and the output details, using Kaspa introspection capabilities. KIP-10 is the relevant foundation here because it adds opcodes for scripts to inspect transaction inputs, outputs, amounts and script public keys. (KIP-10, Kii clarification)
That is the difference between "a valid signature exists" and "this exact coin may move in this exact way." A proof that can be replayed anywhere is not enough for money. The proof must be bound to the specific spend. Kii says it tested both sides: one authorized spend confirmed, and a replay against a second coin at the same lock was rejected. (Kii post)
Where Kii's Reply To Pavel Emdin Fits
Pavel Emdin pushed on the details, and Kii's reply is the part people should read before making sweeping claims. The reply separates three questions. First: does the proof attest to real verifier execution, or merely bind some inputs? Kii says it attests to real execution of the verifier program. Second: does that make the verifier itself formally correct against the NIST specifications? No. Kii says correctness still depends on the verifier implementation and test vectors. Third: does the result make Kaspa broadly post-quantum? No. It touches spend authorization, while the normal transaction envelope and mining remain classical. (Pavel Emdin profile, Kii clarification)
That reply is useful because it keeps the signal strong without pretending the unsolved parts are solved. Kii reported NIST known-answer testing for ML-DSA and SLH-DSA, plus end-to-end in-zkVM valid and tampered cases. For Falcon/FN-DSA, Kii explicitly did not claim final NIST-vector cleanliness because FIPS 206 is not final in the same way as FIPS 204 and 205. (Kii clarification, FIPS 206 presentation)
How This Relates To Max's XMSS Test
Kii also pointed to Maksim Biriukov's XMSS work as complementary. That is the right way to frame it. Max's route puts a hash-based post-quantum signature verifier directly into Kaspa script and demonstrated a covenant spend on testnet-10. Kii's route proves post-quantum verification inside a zkVM and asks Kaspa to verify the proof. (Max Biriukov on X, kaspa-xmss repo, Kii post)
Those are different engineering tradeoffs. Native script verification is direct, but it can become large and expensive when the verifier is heavy. zkVM verification lets heavier logic run off-chain, then submits a proof of correct execution on-chain, but proving time becomes a real constraint. Kii's own timings show that difference: Falcon was fastest in the experiment, ML-DSA took longer, and SLH-DSA was much heavier because hash-based verification performs many SHA-256 operations. (Kii clarification)
Update: Kii Adds A Computation-Lineage Test
Kii later posted another test in the same series: deterministic chain-seeded genetic computation. This is not another signature-authorisation test. It is a separate demonstration that a small evolutionary search program can run for 32 generations inside a zkVM, with each step proven correct, then folded into one proof that Kaspa verifies in a single transaction. (Kii update)
The useful detail is proof folding. Kii says the 32 step-proofs were folded into one 222 KB proof, the same size as a single step proof, while the prover still pays more time as more generations are added. That does not change the earlier spend-auth story, but it broadens the same theme: heavier computation can happen off-chain, while Kaspa checks a compact proof of the result on-chain. (Kii update)
The same warning still applies. Kii describes the computation demo as a feasibility experiment on testnet. It is deterministic, chain-seeded computation, not AI, not intelligence, and not a self-running on-chain process yet. The post-quantum part here refers to the hash-based STARK verification path, not to a full network quantum migration. (Kii update)
Why This Matters
The real story is not that Kaspa is suddenly immune to quantum computers. The real story is that Toccata-era primitives are starting to show how application-level authorization can move beyond today's default signature model. A coin can carry richer spend rules. A proof can show that some external cryptographic rule was followed. A covenant can bind that proof to the exact transaction being authorized. (KIP-10, KIP-16, Kii clarification)
For wallets, that hints at future post-quantum authorization experiments. For industrial systems, it hints at devices, proofs and compliance logic that can be checked by the base layer without forcing every validator to rerun heavy application code. For proof markets, Kii's comment about compute-heavy but parallel proving is also worth watching, although it is still only an early idea. (Kii clarification)
The limits are just as important. This is testnet-10. It is a proof-of-concept. The normal transaction envelope is still classical. Mining is still classical. MuHash and the UTXO commitment layer are separate problems. The proving times are measured in minutes, not wallet-friendly seconds. None of that ruins the result. It just defines it properly. (Kii post, Kii clarification)
The clean takeaway is this: Kii did not prove "Kaspa is quantum-ready." Kii showed that Kaspa's ZK and covenant path can verify post-quantum spend authorization logic on testnet, with tamper and replay controls. That is a serious result because it demonstrates a bridge between modern post-quantum signatures and Kaspa's programmable UTXO model. It is not the whole migration. It is one credible piece of the map.