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#
Sequencing commitments describe how based-app activity can be committed and proven across lane partitions. 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 KIP-0021, RK-SEQCOMMIT, 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 Sequencing Commitments, the model is built around these anchors: KIP-0021 snapshot evidence describes sequencing commitments as implemented and activated in TN10; merged or broader network wording still needs repo-history, release, and params evidence; accepted activity uses lane keys, activity leaves, lane tips, and sequencing metadata; lane partitioning changes proof shape; operation proofs need access-window rules; apps still need settlement and indexer responsibilities. 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. KIP-0021 snapshot evidence describes sequencing commitments as implemented and activated in TN10; merged or broader network wording still needs repo-history, release, and params evidence. 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.
2. accepted activity uses lane keys, activity leaves, lane tips, and sequencing metadata. 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. lane partitioning changes proof shape. 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. operation proofs need access-window rules. Sequencing and based-app material depends on ordered accepted activity. The L1 can provide ordering evidence, while off-chain execution, proof generation, settlement, replay, and access-window handling are application responsibilities. The guide should make it clear which layer orders activity, which layer computes state, which layer proves or commits the result, and which source can verify each boundary.
5. apps still need settlement and indexer responsibilities. 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.
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#
| Step | Check | Evidence gate |
|---|---|---|
| 1 | Check KIP-0021 snapshot evidence describes sequencing commitments as implemented and activated in TN10; merged or broader network wording still needs repo-history, release, and params evidence. | Read KIP-0021, RK-SEQCOMMIT, DOC-TOCCATA-BASED-APPS; separate current release/source behavior from KIP PR or docs-orientation material. |
| 2 | Check accepted activity uses lane keys, activity leaves, lane tips, and sequencing metadata. | Read KIP-0021, RK-SEQCOMMIT, DOC-TOCCATA-BASED-APPS; separate current release/source behavior from KIP PR or docs-orientation material. |
| 3 | Check lane partitioning changes proof shape. | Read KIP-0021, RK-SEQCOMMIT, DOC-TOCCATA-BASED-APPS; separate current release/source behavior from KIP PR or docs-orientation material. |
| 4 | Check operation proofs need access-window rules. | Read KIP-0021, RK-SEQCOMMIT, DOC-TOCCATA-BASED-APPS; separate current release/source behavior from KIP PR or docs-orientation material. |
| 5 | Check apps still need settlement and indexer responsibilities. | Read KIP-0021, RK-SEQCOMMIT, DOC-TOCCATA-BASED-APPS; 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.
Related Pages#
- subnets-user-lanes-and-gas
- toccata
- activation-releases-and-params