Aglovale spent a post-quantum vault on Kaspa testnet-10 by checking a hash-based signature inside ordinary script. He posted the proof of concept to Kaspa Core R&D on August 27 and pushed the public kaspa-pqv repository the same day, after creating it on August 26. (Kaspa Core R&D, kaspa-pqv, commit 8198cc6)
The vault is a normal Kaspa pay-to-script-hash address, and the redeem script itself verifies the signature. There is no zero-knowledge proof, no precompile, and no opcode added for this purpose. Earlier testnet work in June used two different approaches. Maksim Biriukov's kaspa-xmss put an XMSS^MT verifier in script behind a two-script covenant that advances signing state. Kii's test proved post-quantum verifiers inside a zkVM and checked the proof on testnet through the KIP-16 precompile. (kaspa-xmss, KIP-16)
After Toccata, a verifier of this kind can be assembled from KIP-10 and KIP-17 introspection plus the version-1 transaction compute_budget field. Those already exist, so the design does not wait on a post-quantum precompile. Scripts of this size were impossible under the earlier limits. They remain large even now: the published SLH-DSA redeem script is 89,235 bytes inside a 97,472-byte transaction, and the LMS redeem script is 19,717 bytes inside a 24,890-byte transaction. Declared compute budgets are 136 and 40 units, but transient mass dominates both, so the spend is paying for bytes rather than for verification work. The README occupancy estimate is about two SLH-DSA spends or about ten LMS spends per block. (vault spec §1 and §11, KIP-10, KIP-17, slh-script, lms-script)
Aglovale reported both schemes spending on testnet-10, at 0.2339 TKAS for SLH-DSA and 0.0597 TKAS for LMS. The repository lists four testnet-10 transaction IDs, two for each scheme, including a second SLH-DSA spend that reuses the same key and address over a different message: 4f4f96c2494d741b3cc0f30bde3a15faa956bbdfeed60ba184cbef185dc2cd6c, 25a8dc25735ec649f3d99379f969c5c7761d8546514c783050b34c5ad6c8d3d4, 9df246be429549dfd7635f2c95c6fed580f491632db9ee5777a9fab22fce755a and 7dd3834583a9b501f969420b4aff1b7ef6fe51b8151463ba30672fa2671e0a00. Those IDs are repository-reported evidence, not an independent confirmation of the spends. (Kaspa Core R&D, README)
SLH-DSA-SHA2-128s is the reusable path. It is the FIPS 205 stateless parameter set, and its hypertree leaf is derived from the message rather than from a counter, so one address can be reused. The second reported SLH-DSA spend is that reuse on chain: the same key and address, a different message. LMS is smaller and stateful. Height 15 with Winternitz w=2 is the RFC 8554 / NIST SP 800-208 set, with 32,768 one-time leaves. The leaf index is pinned into the script, so each leaf has its own redeem script and its own address, and change must go to leaf q+1 because the spend burns leaf q. SLH-DSA change returns to the same address. (README, vault spec, FIPS 205, RFC 8554, SP 800-208, SLH-DSA vault)
Both schemes still have to live inside Kaspa script, which has no loops. They sign the same binding digest, reconstructed by the redeem script from introspection: transaction version, this input's outpoint, and every output amount and script public key. Output iteration is unrolled, so the vault commits to exactly two outputs, destination plus change, and both redeem scripts assume exactly one vault input. vault-core holds the only binding-digest implementation, shared by both schemes, because a silent divergence would brick funded UTXOs. (vault-core, vault spec §3 and §5)
Kaspa script already has SHA-256, BLAKE2b and BLAKE3. It does not have Keccak or SHAKE, so ML-DSA and Falcon are out of reach without a zkVM or a new primitive. SLH-DSA-SHA2-128s is the stateless scheme the generators actually emit. Aglovale credits kaspa-xmss, and credits Gaurav's comments on off-chain signing for pushing the secondary stateless SLH-DSA design. (Kaspa Core R&D, slh-script)
This proof of concept is experimental, unaudited, heavily LLM-assisted, and testnet-only. It has not been run on mainnet. Toccata is live there, and the opcodes, transaction format and mass rules match, but that is not a mainnet spend. LMS remains stateful: an off-chain signature on the same one-time key as a later spend is reuse, and the chain cannot see it. Vault addresses are ordinary script-hash addresses, so no wallet can label them as post-quantum. Parameters, the two-output spend shape and the witness blob size are baked into the address.
It is meant to protect coins at rest against Shor. It does not migrate the existing UTXO set, does not address quantum mining, and is not a general payment format. (Kaspa Core R&D, README limitations, vault spec)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
