What Toccata Changes

What this page explains#

Toccata is an application surface made of several connected protocol and tooling changes, not one isolated feature. This page sits in Toccata. It gives the topic a plain-language handle first, then shows the working idea, the mechanism, the source trail, and any limits that still matter. This category treats Toccata as a cluster of related changes rather than one feature. Transaction v1, compute budget, script pricing, lanes, sequencing commitments, covenants, and ZK have to be read together when an application depends on them.

The writing follows a simple Kaspa documentation pattern: answer the practical question first, then link outward for details. The closest public sources for this page are DOC-TOCCATA, DOC-TOCCATA-TX-V1, DOC-TOCCATA-SCRIPT-PRICING, DOC-TOCCATA-COVENANT-STATE, DOC-TOCCATA-INLINE-ZK. Local notes can help choose what to explain, but public-facing references resolve to upstream websites, repositories, papers, release pages, or docs.

How to think about it#

The practical model starts by naming the layer that owns the topic: wallet use, node operation, consensus, transaction validation, Toccata script behavior, tooling, or research. From there, the page shows which public source can support the explanation and where the explanation becomes incomplete.

For What Toccata Changes, the model is built around these anchors: transaction v1 expands the transaction surface through source-defined fields, serialization, hash, and signing paths at the pinned source commit; script pricing and compute budget meter script work through mass, validation, and runtime resource-meter paths at the pinned source commit; covenants bind successor state through covenant docs, txscript, covenant ID, and signing context, but readiness wording remains evidence-scoped; inline ZK verifies selected proof systems through tags, verifier source, and script-pricing evidence, while app validity remains separate; current-status wording remains unknown until release notes, docs, params, constants, and implementation evidence agree for the target network. This model is useful, but it does not encode every constant, branch, error type, or edge case. Those details belong in the source path and the source notes.

How it works#

1. transaction v1 expands the transaction surface through source-defined fields, serialization, hash, and signing paths at the pinned source commit. Transaction v1 is the entry point into Toccata because it changes the transaction surface that apps and tools must preserve. The guide traces versioned fields through struct definitions, serialization, transaction hash contexts, sighash commitments, RPC or wallet builders, mempool admission, and accepted evidence. A page should not imply a wallet, SDK, or indexer is compatible until that route has been checked.

2. script pricing and compute budget meter script work through mass, validation, and runtime resource-meter paths at the pinned source commit. Script pricing and compute budget are resource-accounting rules. They decide whether script execution can fit inside the transaction's allowed work, and they interact with mass, fee pressure, and validation errors. A useful Toccata page separates byte size, compute units, storage mass, fee rate, and policy admission instead of using one loose word like cost.

3. covenants bind successor state through covenant docs, txscript, covenant ID, and signing context, but readiness wording remains evidence-scoped. Covenants make Toccata stateful in the UTXO sense: a spend consumes an existing output, script logic inspects the transaction context, and the successor output must carry the allowed next state. The page should keep covenant state, covenant ID, authorization context, indexer head tracking, and negative successor checks separate.

4. inline ZK verifies selected proof systems through tags, verifier source, and script-pricing evidence, while app validity remains separate. Inline ZK adds verifier calls to the script path, but the verifier result is not the whole application transition. The guide identifies the verifier tag, proof format, public inputs or journal, cost rule, and the script or covenant condition that binds the proof to a successor output. Accepted network evidence still comes after transaction validation.

5. current-status wording remains unknown until release notes, docs, params, constants, and implementation evidence agree for the target network. Toccata status is settled by source, params, release notes, and network scope together. Docs can introduce the feature cluster, but rollout wording needs release evidence and source paths. KIP or PR-shaped details remain proposed until they are merged, implemented, and tied to the relevant network.

This mechanism section separates current release/source details from proposal-shaped KIP text. Transaction v1, script pricing, lanes, sequencing commitments, covenants, and ZK are related, but each has its own source boundary.

How to check it#

When using this page for Toccata material, separate deployed release/source details from open KIP or PR-shaped details. Transaction v1, lanes, sequencing commitments, script pricing, covenants, and ZK each need their own source boundary before the page presents them as current behavior.

Related Pages#

• toccata
• transaction-v1