Kaspa Toccata explained

Direct answer

What Toccata changes

Design frame

It is not an EVM turn

Toccata does not make Kaspa an account-based global virtual machine. Kaspa still uses UTXOs: transactions spend specific outputs and create new outputs. The consumed and created state is explicit in the transaction, instead of hidden behind a shared global account state.

The design target is narrow: add enough rule expressiveness for money flows while keeping the base layer lean. A covenant can say, for example, "this next output must preserve the rule," "this spend needs a controller input," or "this refund path opens after the timeout." The app logic lives in constrained UTXO transitions, proofs, or app-side execution anchored back to L1.

That is why Toccata is better described as an expressiveness upgrade. It expands what L1 transactions can enforce and verify. It does not prove mature wallets, DeFi liquidity, audits, custody flows, or full app composition by itself.

Covenants

Spend rules become state rules

A normal payment proves the spender is allowed to move funds. A covenant-style spend can also inspect the spending transaction and require the next output to preserve a rule. That turns a UTXO into a small state machine: the coin moves, but the rule can continue.

KIP-17 adds the script tools for transaction introspection, byte manipulation, hashing, signatures from stack, and ZK precompile access. KIP-20 adds covenant IDs so a covenant family can carry a stable 32-byte identity through valid continuations. Together, they make stateful UTXO rules easier to inspect and harder to fake.

Good examples are vaults, spend limits, refund paths, controlled assets, assurance funding, escrow-like flows, and proof-gated payouts. Bad wording makes this sound like all smart-contract infrastructure is finished. The claim is narrower: Toccata gives Kaspa better L1 rule surfaces.

ZK apps

Proofs move computation off L1, then settle back

ZK verification changes the app-capacity question. A proof transaction may be heavier than a simple payment, but one proof can represent many off-chain app actions if the app is designed that way. The L1 transaction then serves as a settlement or verification event.

KIP-16 introduces OpZkPrecompile with initial Groth16 and RISC0-Succinct paths. That lets a script verify a proof about chosen public inputs. The proof still needs a defined statement, app design, and anchor for outside facts. ZK does not magically prove prices, bridge truth, game integrity, or real-world events unless the inputs and trust boundary are defined.

This is why "Kaspa TPS" needs workload labels. Payment TPS, covenant transaction capacity, proof-settlement capacity, and effective app actions per settlement cycle are different measurements.

KIP-21

Sequencing without proving the whole DAG

Based apps use Kaspa L1 ordering. A naive design is expensive: every app would need to prove which L1 transactions were for it and which were not. At scale, "not for me" evidence becomes the burden.

KIP-21 addresses that with partitioned sequencing commitments. A prover for one app lane follows that lane's activity. Proving cost tracks the app's own activity.

This gives based apps and later vProg-style systems a way to avoid proving unrelated network activity. It is not a consumer slogan and not proof that full synchronous app composition is live.

vProgs boundary

Based apps first, full vProgs later

The public kaspanet/vprogs repo describes an early Rust framework for based computation on Kaspa, with core, storage, state, scheduling, transaction runtime, node, L1, and ZK pieces. It shows the implementation direction.

Michael Sutton's Argent repo is related research tooling: an actor-style frontend that aims to generate Silverscript for multi-contract covenant systems. It points at the developer-experience problem directly. Writing many linked covenant contracts by hand is the hard part.

The status boundary stays clear: Toccata can support covenant apps, proof-gated flows, sequencing commitments, and standalone based-app foundations. Full vProgs are later architecture for richer execution and cross-app composition.

Fees and nodes

Operator changes

The Toccata guide is operational. It tells node operators to upgrade to v2.0.1 or newer before activation, notes the node database upgrade is one-way without resync, and tells service providers to test against Testnet-10.

It also changes standard fee policy for direct RPC submission: 100 sompi * max(compute grams, 2 * transaction bytes). Mempool policy and consensus are separate rule sets. Consensus-valid zero-fee transactions remain possible, but upgraded nodes can reject underpriced standard transactions from relay or RPC according to policy.

The byte-size change is tied to proof support. The guide points to the doubled transient-mass limit as a reason updated hardware specs changed, specifically to allow ZK-STARK proofs. That is proof-transaction capacity work. Ordinary payment-throughput claims need separate payment-specific assumptions. It expands the size envelope needed for proof transactions and adds programmability machinery.

Mining

Rust Stratum Bridge belongs in the sovereignty story

ASIC miners speak Stratum. Kaspa nodes speak Kaspa RPC. The Rust Stratum Bridge gives miners and pools a maintained path for connecting mining hardware to an upgraded Kaspa node through the Rusty Kaspa stack.

The operational point is direct: miners and pools need to preserve post-Toccata block-template fields and test mining flows before activation. The sovereignty point is also direct: a miner who can point hardware at their own node depends less on a pool interface.

Future miner-side plugins or external-claim verification ideas should stay labeled as future architecture until shipped code and activation evidence exist.

Wording boundary

Summary

Toccata is Kaspa's scheduled expressiveness upgrade. It adds covenant-based L1 rules, covenant IDs, ZK proof verification, sequencing commitments, and foundations for based apps. It does not turn Kaspa into an EVM, and full vProgs remain roadmap architecture.