Toccata

What this page explains#

Explain Toccata as a sourced upgrade and application surface without blending docs, releases, implementation, proposals, and local experiments. 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-REFERENCES, DOC-TOCCATA-TX-V1, DOC-TOCCATA-SCRIPT-PRICING, DOC-TOCCATA-COVENANT-STATE. 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 Toccata, the model is built around these anchors: Toccata is a feature cluster: transaction v1, script pricing, lanes, sequencing commitments, covenants, and ZK must be source-checked separately; Release, params, and implementation evidence decide current status; proposal-shaped KIP details stay proposed; Wallet, RPC, SDK, and indexer compatibility claims require field-preservation evidence; Application pages must distinguish protocol enforcement, tooling support, local experiments, and production readiness; Open Questions remain visible where current upstream evidence has not been read. 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. Toccata is a feature cluster: transaction v1, script pricing, lanes, sequencing commitments, covenants, and ZK must be source-checked separately. 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. Release, params, and implementation evidence decide current status; proposal-shaped KIP details stay proposed. 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.

3. Wallet, RPC, SDK, and indexer compatibility claims require field-preservation evidence. Developer integration pages explain an interface by naming the source object behind it. API, RPC, wRPC, SDK, wallet, and indexer surfaces are useful only when they preserve the fields and evidence that the protocol layer actually defines. Accepted-state evidence, replay behavior, schema choices, and endpoint disagreement must be checked separately.

4. Application pages must distinguish protocol enforcement, tooling support, local experiments, and production readiness. Readiness pages are evidence gates. A testnet result is useful only with network name, date, release or branch, node/wallet/tool versions, and accepted evidence. Release notes and source paths support stronger claims; old testnet observations remain historical unless refreshed.

5. Open Questions remain visible where current upstream evidence has not been read. Toccata pages explain how transaction v1, compute budget, lanes, script pricing, sequencing commitments, covenants, and ZK fit together. The page marks which part is source behavior, which part is docs orientation, and which part is readiness-sensitive.

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.

Expanded Category Guide#

This category carries status-sensitive Toccata material. It should keep transaction v1, script pricing, lanes, sequencing commitments, covenants, ZK, releases, KIPs, docs, and source paths separated.

Use this category as a curated path. Start with the category README to understand the boundary, then read the mechanism pages, then follow source-path or open-gap pages for claims that need stronger evidence. If a page contains needs checking rows, keep those claims visibly unresolved until a reader reads the cited public source directly.

The category should not be treated as final authority by folder name alone. The authority comes from page Source Notes, Source Lists, public URLs, and the status labels attached to each claim.

Related Pages#

• toccata
• what-toccata-changes

Topic pages#

• What Toccata Changes: Toccata is an application surface made of several connected protocol and tooling changes, not one isolated feature.
• Transaction V1: Transaction v1 is the field-level foundation for Toccata-era application behavior, but implemented source fields and KIP-0024-PR proposal text must be read as separate claim classes.
• Compute Budget And Script Pricing: Compute budget and script pricing are described through docs, KIP-0025-PR proposal text, and source paths; this page should not treat proposal-only material as final deployed behavior.
• Subnets, User Lanes, And Gas: Lanes and subnetwork fields should be taught as application ordering and payload surfaces with source-backed boundaries.
• Sequencing Commitments: Sequencing commitments describe how based-app activity can be committed and proven across lane partitions.
• Activation, Releases, And Parameters: Activation pages teach how to verify Toccata status without blending mainnet, testnet, and history.
• Toccata Decision Guide: The decision guide asks for the smallest model that carries the invariant: ordinary transaction, covenant, ZK covenant, based app, or vProgs-style execution.
• Toccata Source Walkthrough: A Toccata source walk ties transaction fields, hashing, sighash, mass, subnets, seqcommit, txscript, opcodes, and ZK precompiles into one review path.
• Toccata FAQ And Failure Modes: This question-led page corrects common Toccata misreadings before they become unsafe app designs.

Topic notes#

This category is accepted when the subpages explain the actual topics, not merely the source links. Each subpage carries public source IDs, claim labels, Open Questions, and a path from first contact into source review.