Maksim Biriukov posted a Kaspa testnet-10 transaction on June 24 and described it as the first post-quantum signature to land on a live Kaspa network. It is an experimental research result, not a wallet launch. What it demonstrates is narrower and more significant: a hash-based post-quantum verifier, written entirely in Kaspa script, passed through a covenant spend path on a public Toccata-enabled testnet node. (Biriukov on X, testnet-10 transaction, kaspa-xmss repo)
The repo, kaspa-xmss, labels the work experimental and unaudited. That matters because the result should not be read as a production signing scheme. The useful signal is technical: a post-quantum signature verifier can be expressed as txscript, bound to covenant state and accepted by a live testnet-10 node under the new Toccata-era script path. (README, tn10 worked example)
Why post-quantum matters
Bitcoin, Ethereum and Kaspa all rely on elliptic-curve signatures for ordinary transaction authorization today. A sufficiently capable quantum computer would threaten elliptic-curve and RSA-based public-key systems, which is why NIST has been standardizing post-quantum cryptography for both encryption and digital signatures. (NIST)
The pressure is now formal policy, not only research discussion. On June 22, 2026, President Donald Trump signed the executive order "Securing the Nation Against Advanced Cryptographic Attacks." It requires U.S. federal high-value assets and high-impact systems to use post-quantum cryptography for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. (White House executive order)
Cloudflare framed the order as two migrations: post-quantum encryption first, then post-quantum authentication. That distinction maps cleanly onto blockchain systems. Encryption protects private traffic. Authentication protects the ability to prove that a transaction, certificate, payload or software artifact was signed by the right key. Biriukov's test sits in the second bucket: it is about a signature verifier. (Cloudflare)
What XMSS is and why it works in script
Biriukov's implementation uses XMSS^MT, the multi-tree version of the eXtended Merkle Signature Scheme. The repo's scheme spec uses a NIST SP 800-208 profile with two height-12 trees, WOTS+ one-time signatures, 24-byte hash output and roughly 3 KB signatures. Verification is hash work, not elliptic-curve math. (XMSS^MT scheme spec, scheme overview)
That distinction is the reason this belongs in a Kaspa script story. A verifier built from bounded, deterministic hash steps can be compiled into txscript and checked by consensus rules without waiting for a dedicated post-quantum opcode. The repo's xmss-script crate is the on-chain side of that design: it emits the verifier, binds the signature to a canonical transaction message and tests the covenant spend path. (scheme overview, xmss-script crate)
XMSS carries a tradeoff. WOTS+ one-time signatures underpin the scheme, meaning each leaf index can only be used once. Reusing the same leaf index for two different messages breaks the security model. Managing that signing state is as important as the signature itself. (scheme overview, two-script covenant spec)
What the live test showed
Biriukov's repo compiles an XMSS^MT verifier into Kaspa txscript, binds the signature to a canonical transaction message and runs a covenant spend path that advances the signing state with each use. The live run on June 24 submitted three transactions to a testnet-10 node over wRPC: a genesis transaction, a bootstrap transaction and a demo spend. (tn10 runner, tn10 worked example)
The spend consumed the previous state output and vault output, created the next state output, delivered a payment output and was accepted by a live node. Biriukov linked the resulting transaction hash: 0c401bcf922eba67eadf1830c78578ac172d71f7735c0c669d681582aedc6e0c. Commit f55230b records the same live testnet flow. (testnet-10 transaction, commit f55230b)
State protection is built around a two-script covenant design. Vault A is a public deposit address with no signing obligation. State script B(i) carries the XMSS verifier and the current leaf index. Each valid spend must produce exactly one successor state output, B(i+1). Deposits land on A; signing state advances only through B. (two-script covenant spec, covenant.rs)
That split matters because unsolicited deposits are dangerous for stateful signatures. In a naive design, someone could send funds to the current signing address and pressure the wallet into signing with the same leaf again. In the two-script design, spending value requires the live state input, and the state input can only move once to its successor. (two-script covenant spec, reuse-rejection test)
Why the script is 84 KB
XMSS verification avoids curve math but still walks WOTS+ chains and processes Merkle authentication paths. That comes to roughly 1,650 hash operations unrolled in script. Biriukov noted the revealed script is about 84 KB, and the repo's testnet notes put the redeem script at about 84.5 KB. (Biriukov on X, scheme overview, tn10 worked example)
Placing a script that large directly in an output would exceed the Kaspa script-public-key limit, so the implementation uses pay-to-script-hash. Outputs commit only to the hash of the redeem script. Spenders reveal the full 84 KB body only when spending. The pattern keeps the locked output compact while still making the full verifier available to the script engine during the spend. (tn10 worked example, scheme overview)
What Toccata makes possible here
This result depends on the script and covenant surface that Toccata activates. The testnet runner checks the virtual DAA score to confirm the Toccata path is live before submitting transactions. Without Toccata's extended opcode support and covenant infrastructure, the covenant spend path the repo relies on would not exist on a Kaspa network. (tn10 runner, Toccata guide)
The timing is part of the story. Biriukov's test landed six days before Toccata is scheduled to activate on mainnet at DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC. It shows one of the new script-era paths being exercised before the same covenant surface reaches mainnet. (Toccata guide, PR #1059)
The limits are clear
Biriukov's repo calls the work experimental and unaudited. Per-device counter enforcement inside the redeem script is described as future work. One advancing state line is not a full multi-device key management system. A future native XMSS verification opcode could reduce the 84 KB script mass significantly, but the current test does not depend on one. (README, scheme overview, commit f11b2d5)
What changed on June 24 is the shape: XMSS^MT verification moved from a local unit test into a live Kaspa script execution path, with the state transition visible on a public testnet. Kaspa covenants and script introspection, now arriving on mainnet through Toccata, are expressive enough to carry a post-quantum signature verifier and enforce the state rules that make it safe to use. (Biriukov on X, commit f55230b, tn10 worked example)
