Kaspa One Stop

In brief

This page is source-sensitive. Treat application, covenant, proof, and readiness wording as bounded by the listed public sources and Open Questions.

What this page explains#

Lanes and subnetwork fields should be taught as application ordering and payload surfaces with source-backed boundaries. 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 RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION, KIP-0021, DOC-TOCCATA-BASED-APPS. 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 Subnets, User Lanes, And Gas, the model is built around these anchors: native and coinbase contexts differ from user lanes in source-defined subnetwork IDs; user lanes use a nonzero namespace while preserving the remaining lane shape defined by source; gas and payload fields need preservation through transaction and body-validation paths; not every covenant spend is a based-app user operation; reserved or special lane wording remains source-policy guidance until the exact source path is 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. native and coinbase contexts differ from user lanes in source-defined subnetwork IDs. Lanes, subnetwork IDs, gas, and payload fields are application-facing transaction surfaces. The page explains what must survive serialization, signing, wallet handling, RPC submission, indexer decoding, and replay. It also separates reserved or special contexts from ordinary user operations so app designers do not borrow a field without checking its source meaning.

2. user lanes use a nonzero namespace while preserving the remaining lane shape defined by source. Lanes, subnetwork IDs, gas, and payload fields are application-facing transaction surfaces. The page explains what must survive serialization, signing, wallet handling, RPC submission, indexer decoding, and replay. It also separates reserved or special contexts from ordinary user operations so app designers do not borrow a field without checking its source meaning.

3. gas and payload fields need preservation through transaction and body-validation paths. Lanes, subnetwork IDs, gas, and payload fields are application-facing transaction surfaces. The page explains what must survive serialization, signing, wallet handling, RPC submission, indexer decoding, and replay. It also separates reserved or special contexts from ordinary user operations so app designers do not borrow a field without checking its source meaning.

4. not every covenant spend is a based-app user operation. 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.

5. reserved or special lane wording remains source-policy guidance until the exact source path is read. Lanes, subnetwork IDs, gas, and payload fields are application-facing transaction surfaces. The page explains what must survive serialization, signing, wallet handling, RPC submission, indexer decoding, and replay. It also separates reserved or special contexts from ordinary user operations so app designers do not borrow a field without checking its source meaning.

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#

StepCheckEvidence gate
1Check native and coinbase contexts differ from user lanes in source-defined subnetwork IDs.Read RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION; separate current release/source behavior from KIP PR or docs-orientation material.
2Check user lanes use a nonzero namespace while preserving the remaining lane shape defined by source.Read RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION; separate current release/source behavior from KIP PR or docs-orientation material.
3Check gas and payload fields need preservation through transaction and body-validation paths.Read RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION; separate current release/source behavior from KIP PR or docs-orientation material.
4Check not every covenant spend is a based-app user operation.Read RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION; separate current release/source behavior from KIP PR or docs-orientation material.
5Check reserved or special lane wording remains source-policy guidance until the exact source path is read.Read RK-SUBNETS, RK-TX-VALIDATION, RK-BODY-VALIDATION; separate current release/source behavior from KIP PR or docs-orientation material.

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.

  • compute-budget-and-script-pricing
  • toccata
  • sequencing-commitments
Source-linkedReviewed 2026-07-09 · 6 public sources · 1 open questionEvidence and sources
Evidence and sources6 public sources · reviewed 2026-07-09
Based AppsPublic source
docs.kaspa.org/toccata/based-apps
Technical details

Reference key: DOC-TOCCATA-BASED-APPS

Recheck this public source before relying on exact current details.

Rusty Kaspa Body ValidationRusty Kaspa source
github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/src/pipeline/body_processor/body_validation_in_isolation.rsgithub.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/src/pipeline/body_processor/body_validation_in_context.rsgithub.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/src/pipeline/body_processor/processor.rs
Technical details

Reference key: RK-BODY-VALIDATION

Recheck this public source before relying on exact current details.