Compute Budget And Script Pricing

What this page explains#

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. 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-SCRIPT-PRICING, KIP-0025-PR, RK-MASS, RK-TX-VALIDATION, RK-RUNTIME-RESOURCE-METER. 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 Compute Budget And Script Pricing, the model is built around these anchors: script units are the practical metering vocabulary described by docs, PR text, and source paths under review; free allowance and budget interactions need exact source details before stronger wording; ZK verification has cost planning requirements through tag and script-pricing evidence; under-budget behavior needs validator and runtime-meter evidence before app intent matters; fee policy claims remain narrower than script-pricing mechanics unless source details 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. script units are the practical metering vocabulary described by docs, PR text, and source paths under review. 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.

2. free allowance and budget interactions need exact source details before stronger wording. Resource accounting needs its own explanation because size, compute, storage, budget, script units, and fee pressure are not the same thing. A transaction may be structurally understandable and still fail admission or validation if the resource rule is violated. The source path for these claims is usually mass, script pricing, validation, and mempool policy together.

3. ZK verification has cost planning requirements through tag and script-pricing evidence. 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.

4. under-budget behavior needs validator and runtime-meter evidence before app intent matters. 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.

5. fee policy claims remain narrower than script-pricing mechanics unless source details is read. Toccata pages need to keep the feature cluster separated by evidence type. Release notes and current source can support deployed context; open KIP PRs describe proposal-shaped details; wallet, RPC, SDK, indexer, script, covenant, and ZK behavior each needs its own source path before the guide presents it as current.

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#

• transaction-v1
• toccata
• subnets-user-lanes-and-gas