Inline ZK Covenant Model

What this page explains#

Inline ZK is best taught inside the covenant loop: current UTXO, proof, script verification, successor output. This page sits in ZK, Groth16, And RISC Zero Succinct. 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 separates proof verification from application validity. Groth16 and RISC Zero Succinct can verify selected statements, while covenant scripts, successor checks, source limits, and accepted evidence still carry separate responsibility.

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-INLINE-ZK, DOC-TOCCATA-COVENANT-STATE, RK-ZK-TAGS, RK-COVENANTS. 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 Inline ZK Covenant Model, the model is built around these anchors: the proof can compress or hide selected transition work; inline ZK verifies a proof inside the covenant spend while the script still validates the successor output and state; proof verification is metered work; proof outputs must bind to the covenant transition before an app claim can be promoted, and this binding remains an open source checking item until exact covenant, transaction-validation, and accepted-evidence paths are attached; accepted evidence after spend remains a readiness checklist item until timestamped public evidence is recorded. 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. the proof can compress or hide selected transition work. A ZK proof can make selected computation compact to verify or hide private witness material, but it only proves the statement encoded by its circuit or zkVM program. The guide names the statement, the public commitment, the verifier identity, and the witness boundary before connecting that proof to Kaspa script execution.

2. inline ZK verifies a proof inside the covenant spend while the script still validates the successor output and state. ZK-and-covenant pages are about binding a verified statement to the state transition the application actually cares about. The proof may check a statement, but the script still has to bind the prior state, successor output, verifier identity, public input or journal, fee/resource context, and accepted-state evidence.

3. proof verification is metered work. Proof verification consumes metered script work. The page has to connect verifier tags and proof sizes to pricing or mass evidence, then show how under-budget, malformed, or mismatched verifier inputs fail before accepted-state claims are made.

4. proof outputs must bind to the covenant transition before an app claim can be promoted, and this binding remains an open source checking item until exact covenant, transaction-validation, and accepted-evidence paths are attached. A proof output is useful only when the application binds it to the old state, new state, covenant ID or script context, and public input or journal. Without that binding, a valid proof may still be irrelevant to the UTXO transition being spent.

5. accepted evidence after spend remains a readiness checklist item until timestamped public evidence is recorded. Proof success is not accepted evidence. After local construction and script validation, the spend still needs transaction validation, mempool or block inclusion context, virtual-state acceptance, and an observable state surface such as UTXO or indexer evidence.

This mechanism section separates proof verification from application validity. A verifier result still needs script binding, covenant checks, transaction validity, and accepted-state evidence before an app claim is closed.

How to check it#

When using this page for ZK material, separate proof verification from application validity. Check the verifier path, proof format, public inputs or journal, compute cost, covenant binding, failure cases, and accepted evidence before claiming a transition is valid.

Related Pages#

• 01-zk-first-contact-and-vocabulary
• zk-groth16-risczero
• 03-opzkprecompile-tags-and-costs