KIP-16 introduces OpZkPrecompile, a Kaspa script opcode that verifies supported zero-knowledge proofs inside transaction validation. The first specification defines tagged Groth16 and RISC0 Succinct paths. It brings proof verification to the base layer, but it does not generate proofs, create an L2 automatically, or guarantee that an application’s circuit is sound.

Key takeaways

• KIP-16 defines OpZkPrecompile at opcode value 0xa6 as a tagged interface to specific ZK verifiers.
• The initial tags are 0x20 for Groth16 and 0x21 for RISC0 Succinct verification.
• A successful call verifies a cryptographic claim bound to expected public data; it does not re-execute the entire off-chain application.
• Groth16 offers compact proofs but is not quantum-safe, while the specified RISC0 STARK-based path targets post-quantum properties with larger proof data.
• Security still depends on correct circuits, verifier libraries, pricing, serialization rules, and application design.

What did the KIP-16 specification add?

The merged KIPs pull request #31 added kip-0016.md and linked it from the repository index. The maintained KIP-16 specification describes one generic opcode rather than assigning a new opcode to every proof system.

OpZkPrecompile takes a tag first, followed by arguments defined for that verifier. This dispatch model keeps one script-level entry point while allowing later proposals to add separately identified precompiles. The tag begins at 0x20, which the specification says is compatible with the script engine’s data-push conventions.

That architecture is easier to reason about than an undefined “verify any proof” instruction. Every accepted tag has a concrete parser, cost model, verification algorithm, and failure behavior. Unsupported or malformed inputs must not silently fall through to another verifier.

How do the two initial verification paths differ?

The Groth16 tag accepts a verifying key, proof, and public inputs in the representation expected by the implementation. Groth16’s small proofs and fixed pairing-based verification make it attractive where transaction size matters. Its tradeoff is a trusted-setup and elliptic-curve security model; KIP-16 explicitly notes that this path is not quantum-safe.

The RISC0 Succinct tag verifies a STARK-based receipt associated with a RISC-V program. Its inputs bind proof data to a journal digest and image ID, so the verifier checks the claimed program identity and public output commitment. The specification characterizes this path as quantum-resistant, while acknowledging larger proof data and higher verification work.

“Native” therefore means that consensus-validating nodes execute the verifier as part of Kaspa script evaluation. It does not mean the expensive application computation happens on every node. A prover runs that computation elsewhere, produces a proof, and a transaction supplies the proof and public values for on-chain checking.

Why is this useful for Kaspa applications?

Proof verification creates a cryptographic bridge between off-chain work and a UTXO spending condition. A script can require evidence that a named program produced a committed result before funds move. KIP-16 discusses Layer 2 state transitions, cross-chain evidence, selective disclosure, and complex computation as possible application classes.

Those examples are capabilities, not deployed products. An L2 still needs a state model, data availability, sequencing, escape or recovery rules, proof generation, and audited contracts. A bridge still needs a precise statement about the remote chain and a way to keep verification inputs current.

The lane-oriented data commitments described in the KIP-21 inactivity-shortcut article address a different layer of the problem: how a prover can follow authenticated Kaspa activity efficiently. KIP-16 is the script primitive that can consume a supported proof.

How are proofs priced and bounded?

Cryptographic verification is substantially more expensive than simple stack operations. The specification reports empirical comparisons with ECDSA verification and uses them to motivate script-unit pricing. Those measurements are hardware- and implementation-dependent evidence, not universal performance guarantees.

Safe pricing must account for both successful verification and adversarial failure paths. A malformed verifying key can consume parsing work before rejection; an oversized witness can trigger hashing before a verifier discovers that the final claim is invalid. Later implementation hardening therefore added input bounds, stricter decoding, and worst-case-oriented metering.

Developers should consult the exact node release they target rather than copying benchmark ratios from an early document. Consensus is defined by activated code and parameters. Tooling should reject unsupported tags, enforce canonical lengths before expensive work, and estimate mass using the same rules as the destination network.

What are the security boundaries?

KIP-16 intentionally relies on external cryptographic implementations. That brings mature proof systems into Kaspa, but it also imports their assumptions and possible bugs. A vulnerability in a verifier library could affect scripts that depend on that tagged precompile even if Kaspa’s proof-of-work consensus remains otherwise healthy.

Tag isolation helps scope upgrades and incident response, but it cannot make an unsafe application safe. Developers must review at least four layers:

1. the statement encoded by the circuit or zkVM program;
2. the prover and verifier implementation;
3. serialization, public-input binding, and script construction;
4. the UTXO contract that decides what a valid proof is allowed to spend.

The lineage rules covered in KIP-20 explained can help identify covenant state across transitions. They do not replace a correct ZK statement or verifier.

Limitations: what KIP-16 does not prove

A valid ZK proof only establishes the formal statement accepted by the verifier. If the program omits a business rule, uses the wrong public inputs, or commits to unavailable data, cryptography may faithfully prove the wrong thing. KIP-16 does not supply data availability, decentralized sequencing, user exits, application governance, or an audit.

It also does not make every transaction private. Public UTXOs, amounts, scripts, and proof inputs remain visible according to the transaction format. Privacy depends on what is hidden by the chosen proof statement and what metadata leaks elsewhere.

Finally, merging PR #31 added the specification. It did not, by itself, activate a hard fork. The maintained KIP now carries an Active status, but operators should use current node release and activation documentation to determine network behavior at a particular DAA score.

Frequently asked questions

Does Kaspa create the ZK proof on-chain?

No. Proof generation occurs off-chain. Kaspa nodes validate the supplied proof and public claim when evaluating the spending script.

Can any proof system use OpZkPrecompile?

Only a proof system assigned an implemented and activated tag can be used. The generic interface is extensible, not permissionless arbitrary code execution.

Is the RISC0 path the same as Groth16?

No. They have different proof formats, verification algorithms, sizes, costs, and security assumptions, even though both are dispatched through the same opcode.

Source and verification note

This article is based on kaspanet/kips PR #31, merged on May 28, 2026, and the maintained KIP-16 text. Opcode values, tags, proof-system descriptions, and stated security tradeoffs come from those primary sources. Deployment status and exact pricing should be rechecked against the current rusty-kaspa release used by the target network.