Kaspa KIP-16 implementation reached merged reference code on February 5, 2026 through Rusty Kaspa PR #775. It added OpZkPrecompile with Groth16 and RISC Zero succinct verification paths, tests, examples, benchmarks, and resource accounting. The merge targeted a development branch and required a future hard fork; it was not evidence of mainnet availability or production readiness.

Key takeaways

• PR #775 merged 73 commits, 2,430 additions, and 121 deletions across 56 files into covpp-reset1.
• OpZkPrecompile uses a tag to dispatch to a specific proof verifier rather than allocating a separate top-level opcode to every system.
• The initial paths were Groth16 (0x20) for compact proofs and RISC0-Succinct (0x21) for larger STARK-based, post-quantum-oriented proofs.
• The code included Rust tests, JavaScript examples, verification benchmarks, and sigop-style cost accounting, but the pricing model still required review.
• KIP-16 explicitly accepts third-party cryptographic dependencies and requires consensus activation, so an application must evaluate library, circuit, data, and upgrade risks separately.

What did Rusty Kaspa PR #775 implement?

The official Rusty Kaspa PR #775 is titled “KIP-16.” GitHub records a February 5, 2026 merge into the experimental covpp-reset1 branch after 73 commits and 56 changed files. The diff added proof-verifier modules, script-engine integration, error handling, test data, benchmarks, mass and sigop accounting, and Node.js examples.

The PR description calls the work a reference implementation that demonstrates viability and establishes architectural direction. It specifically asks for technical review and says it should not be treated as production-ready. That boundary is essential: merged development code is a stronger artifact than a concept, but weaker evidence than an activated, audited network feature.

How does OpZkPrecompile work?

The current KIP-16 specification defines OpZkPrecompile as a generic script interface. The first argument is a hexadecimal tag identifying the verifier; the remaining stack arguments follow that verifier’s format.

A prover performs a complex computation away from Layer 1 and creates a cryptographic proof. A Kaspa transaction supplies the proof and the statement-specific public data. The opcode verifies that evidence during script execution. If verification succeeds, the rest of the script may continue and unlock the UTXO according to its rules.

This separates computation from verification. Kaspa nodes would verify the defined claim; they would not rerun the complete off-chain program.

Which proof systems were included?

The Groth16 path uses tag 0x20. KIP-16 describes compact proofs verified with an Arkworks implementation and public inputs supplied to the script. Groth16 is not quantum-safe and requires careful verification-key and circuit handling.

The RISC0-Succinct path uses tag 0x21. It verifies a STARK-based succinct receipt that binds a RISC-V program identity, execution claim, and public output commitment. The proof data is larger and verification more expensive, while the design targets post-quantum security properties.

Neither tag makes an arbitrary application private or trustworthy automatically. A proof only establishes the statement encoded by the chosen program, inputs, verifier, and commitment scheme.

What tests and cost evidence were added?

The PR added unit tests for valid proofs and invalid inputs, fixture data for succinct receipts, and JavaScript examples for both Groth16 and RISC0-Succinct. It also introduced a benchmark suite comparing the proof verifiers with ECDSA signature verification.

The PR proposed costs of 140 sigops for Groth16 and 740 for the STARK path, based on measured ratios. The later KIP text reports sample averages of 1.648881 milliseconds for Groth16 and 9.080792 milliseconds for STARK verification versus 12.311 microseconds for ECDSA on the tested hardware, while acknowledging that a theoretical upper bound remained future work.

Those figures are implementation measurements, not universal latency promises. Hardware, compiler, library versions, inputs, and benchmark methodology matter. Resource pricing must also consider worst-case behavior and denial-of-service resistance, not only an average run.

What security assumptions does native ZK verification add?

KIP-16 openly states that nodes inherit risk from RISC Zero, Arkworks, and related cryptographic dependencies. A verifier bug could affect funds governed by that precompile even if Kaspa’s proof-of-work consensus remains intact. Tag isolation can limit some blast radius, but applications still depend on the selected verifier.

Developers must also audit circuit or program logic, public-input binding, proof generation, data availability, bridge or Layer-2 state commitments, upgrade keys, and recovery procedures. A mathematically valid proof can still attest to the wrong program, incomplete data, or an unsafe application rule.

The opcode does not solve oracle authenticity. If an application uses an external price or event, the proof can show how supplied data was processed; it cannot establish that the source data was true without a separate trust or attestation design.

What did KIP-16 enable in principle?

The specification discusses Layer-2 state verification, bridge evidence, privacy-related applications, computational integrity, and selective-disclosure credentials. Each follows the same pattern: expensive execution happens elsewhere, then Layer 1 verifies a compact claim before allowing a UTXO transition.

These were application scenarios, not products shipped by PR #775. A secure Layer 2 also needs sequencing, state commitments, data availability, exit rules, and economic incentives. The adjacent DagKnight simulation update covers a separate consensus research track, while Kaspa community merch as education explains why public communication should keep such distinctions visible.

What were the activation and roadmap limits?

KIP-16 says deployment requires a hard fork because older nodes would reject transactions containing the new opcode. Activation therefore needs predetermined consensus parameters, compatible releases, operator upgrades, test evidence, and advance communication.

PR #775’s target branch and reference-implementation wording show that the February 5 merge was one engineering gate, not the final gate. Stable specifications, independent review, network tests, pricing validation, and explicit activation records are stronger evidence for production status.

What does KIP-16 mean for Kaspa’s price outlook?

Native proof verification could broaden Kaspa’s application design space if it is securely activated and adopted. It may eventually support uses that generate transactions and fees, but the merge alone supplies no adoption or revenue data.

Accordingly, it supports no KAS price target. Market impact depends on implementation safety, activation, developer tooling, application quality, liquidity, regulation, and user demand. Technical readers should track auditable milestones without converting each one into a guaranteed valuation claim.

Frequently asked questions

Does OpZkPrecompile generate proofs?

No. Provers generate proofs off-chain. The Kaspa script opcode verifies a supplied proof and its associated public claim.

Are both initial proof systems quantum-safe?

No. KIP-16 describes the RISC0-Succinct STARK path as post-quantum-oriented, while Groth16 is compact but not quantum-safe.

Was KIP-16 live on mainnet when PR #775 merged?

No evidence in the PR supports that conclusion. It merged into a development branch, and the specification says deployment requires a coordinated hard fork.

Source and verification note

This article is based on merged kaspanet/rusty-kaspa PR #775, its public changed-file record, tests, examples, benchmark additions, and the official KIP-16 specification. Status is stated narrowly: the sources establish merged reference code and a hard-fork proposal, not February 5 mainnet activation, independent audit completion, application adoption, or a KAS price forecast.