First Post-Quantum Signature Runs on Kaspa Testnet-10

On June 24, 2026, researcher Maksim Biriukov published a transaction on Kaspa testnet-10 and described it as the first post-quantum signature to land on a live Kaspa network. The result is experimental — the kaspa-xmss repo labels the work as such — and it is not a wallet launch. What it demonstrates is narrower and more significant: a hash-based post-quantum signature verifier, written entirely in Kaspa script (txscript), passed through a covenant spend path on a public Toccata-enabled testnet node. (source)

The transaction hash is 0c401bcf922eba67eadf1830c78578ac172d71f7735c0c669d681582aedc6e0c. Commit f55230b records the same live testnet flow. The timing matters: the test landed two days after a U.S. executive order that formalized post-quantum migration as federal policy.

What changed — and what didn't

Today, Bitcoin, Ethereum and Kaspa all rely on elliptic-curve signatures (ECDSA on secp256k1 or equivalent) for ordinary transaction authorization. A sufficiently capable quantum computer would threaten those public-key systems, which is why NIST has been standardizing post-quantum cryptography for both encryption and digital signatures.

Biriukov's result does not fix that for Kaspa's mainnet. The kaspa-xmss repo is explicit: the code is experimental and unaudited. What it does fix is a technical question that was previously open: can a post-quantum signature verifier be expressed as txscript, bound to covenant state, and accepted by a live testnet node under the Toccata-era script path? As of June 24, the answer is yes.

The signature scheme: XMSS^MT

The implementation uses XMSS^MT, the multi-tree version of the eXtended Merkle Signature Scheme. The repo's scheme spec follows a NIST SP 800-208 profile with two height-12 trees, WOTS+ one-time signatures, a 24-byte hash output and signatures of roughly 3 KB.

The key distinction is that verification is built from hash operations, not elliptic-curve math. A verifier constructed 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 component: it emits the verifier, binds the signature to a canonical transaction message, and tests the covenant spend path.

XMSS carries a real tradeoff

XMSS is built on WOTS+ one-time signatures. Each leaf index in the Merkle tree can only be used once. Reusing the same leaf index for two different messages breaks the security model entirely. Managing signing state — which leaf is current, whether it has been consumed — is as important as the signature verification itself.

This is not a footnote. For any future production scheme built on XMSS or similar hash-based constructions, state management is the engineering problem. A lost state file means potential key reuse; a corrupted state file means potential key reuse. The scheme is quantum-resistant only as long as the user's software never double-spends a leaf.

The two-script covenant design

Biriukov's testnet implementation addresses the state problem architecturally, using a two-script covenant split:

• 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.

This 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 to its successor once. A separate test in the repo verifies that this reuse-rejection path works.

Why the script is 84 KB

XMSS verification avoids curve math but still walks WOTS+ hash chains and processes Merkle authentication paths. Unrolled in script, that comes to roughly 1,650 hash operations. Biriukov noted the revealed script is about 84 KB; the repo's testnet notes put the redeem script at approximately 84.5 KB.

Placing a script that large directly in an output would exceed Kaspa's scriptPublicKey size limit. The implementation works around this with pay-to-script-hash (P2SH): outputs commit only to the hash of the redeem script, and spenders reveal the full 84 KB body only when spending. The pattern keeps the locked output compact while making the full verifier available to the script engine during the spend.

What Toccata makes possible

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 covenant infrastructure, the two-script state machine — vault A, state B(i), mandatory successor B(i+1) — would have no enforcement surface in consensus.

That is the broader signal for Kaspa holders and builders: Toccata is not only a feature for vaults and escrow. It is the scripting and covenant foundation on which more complex on-chain constructions, including post-quantum signature schemes, become expressible in txscript.

The policy backdrop

Two days before Biriukov's test, on June 22, 2026, President Donald Trump signed the executive order "Securing the Nation Against Advanced Cryptographic Attacks." The order 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.

Cloudflare framed the order as two sequential migrations: post-quantum encryption first, then post-quantum authentication. That distinction maps onto blockchain systems directly. Encryption protects private traffic (handshakes, mempool propagation). Authentication protects the ability to prove that a transaction was signed by the right key. Biriukov's test sits in the second bucket: it is a signature verifier.

The order does not mandate anything for permissionless blockchains. But it sets the tempo for the broader cryptographic ecosystem. Vendors, libraries, hardware security modules and browser engines will all be migrating toward PQ signature support over the next five years. Blockchains that can demonstrate PQ signature compatibility in their scripting layer — even at the experimental stage — will be better positioned to absorb that infrastructure as it matures.

What this means for KAS holders and self-custody users

The honest read is threefold:

1. Nothing changes for users today. This is a testnet research demo on an unaudited codebase. No wallet, no signing tool, no production scheme exists yet.

2. The technical question is answered. A hash-based PQ verifier can run inside Kaspa's script engine, inside a covenant, on a live Toccata-enabled node. That is a prerequisite checked off, not a product launched.

3. The timeline is real. Whether or not quantum computers arrive on schedule, the institutional and regulatory pressure to migrate signatures is formalizing. Kaspa's scripting surface under Toccata has now demonstrated that it can carry that migration when it comes.

For anyone who holds their own keys — and especially for anyone building tools that help others do so — the relevant takeaway is that Kaspa's covenant infrastructure is being tested against the hardest cryptographic problem on the horizon. The results are early and experimental. But they are on-chain, on a public testnet, and repeatable.

The kaspa-xmss repository is open source. The testnet transactions are public. The two-script covenant spec is documented. If you build on Kaspa, this is worth reading.