Toccata changed Kaspa from a network mainly for moving coins into one that can also enforce application rules on its base layer. It activated on mainnet on 30 June 2026, bringing covenants, covenant identities, native cryptographic proof verification, and new commitments to transaction ordering. [1][2]
From payments to programs
In the *Kaspa Programmability MasterClass*, Manyfest explained the purpose: Kaspa already provided a fast, decentralized money layer, but applications needed more than transfers between addresses. Toccata added ways to enforce more complex financial interactions while keeping Kaspa’s focus on speed. [3]
The important distinction is between sending coins and attaching rules to their future use. Toccata’s covenants can restrict both who may spend an output and how it may be spent, including rules that carry application state into the next transaction. [1]
What the upgrade added
1. Covenants: rules that continue across transactions
A covenant is a set of spending rules attached to a transaction output, a piece of spendable value. Toccata lets scripts inspect transaction details and enforce conditions on the outputs that replace it. That supports contracts whose rules and state continue through successive transactions. [2]
This opens the way to vaults, smart wallets and native assets. These are uses enabled by the upgrade, rather than applications that the upgrade automatically supplied. [1]
2. Covenant IDs: a way to identify the same program over time
When an output is spent, a new output can carry its updated state. Toccata introduced covenant IDs to preserve a verifiable identity through those changes. [2]
Michael Sutton explained why this matters in October 2026. A timelock only needs to protect its own KAS. Someone copying its script onto their own coins does not undermine it. A name registry or native token is different: the identity and history of its state matter, so imitation and forgery become concerns. Covenant IDs provide that lineage. [4]
Sutton also said native state-carrying covenants can support assets, decentralized exchanges and lending. That describes what the building blocks support, not a claim that every such application is deployed or ready to use. [4]
3. Native verification of cryptographic proofs
Toccata added a native instruction for checking zero-knowledge proofs, cryptographic evidence that a computation followed specified rules. This lets applications perform computation outside the base network and submit a proof for verification on Kaspa. [2]
The upgrade can check two widely used kinds of proof, Groth16 and RISC Zero STARK proofs, directly on Kaspa’s base layer. The verifier checks proofs; it does not mean every application’s full computation runs inside the node. [1][2]
4. Partitioned commitments to transaction ordering
Toccata also added partitioned sequencing commitments. These are commitments to application transaction order, allowing proofs to focus on the relevant application activity rather than the network’s entire transaction flow. [2]
One detail matters to anyone building proofs on these commitments: Sutton noted on 15 October 2026 that a block with a wrong sequencing commitment can still join Kaspa’s block graph, but it can never become a chain block, one of the blocks on Kaspa’s main chain that decide which transactions are accepted. A proof that a transaction was accepted must therefore also show that its block counted as a chain block. [5]
5. A higher minimum fee rate
At activation, the minimum fee rate rose a hundredfold, from 1 to 100 sompi per gram of transaction mass. Nodes refuse to relay transactions that pay less, and wallets that ask the node for a fee estimate adjusted on their own. Node operators had to run Rusty Kaspa 2.0.1 or newer to stay on the network. [6]
What builders and users gained
SilverScript provides a higher-level way to write covenant logic and compile it into Kaspa Script. [1] IzioDev explained that shared conventions also matter: wallets and indexers need compatible ways to recognize application programs, or each application risks needing its own isolated tools. [7]
Toccata supplied the foundation, not automatic adoption. Sutton emphasized that developers still needed to turn its new building blocks into usable products. [2]
For the plain-language explanation of why Kaspa needed this change, watch Manyfest’s *Kaspa Programmability MasterClass, “Why Kaspa needs Toccata”*, starting at 8:14. [3]