KIP: 16
Layer: Script Engine, ZK
Title: New Transaction Opcodes for Verifiable Computation
Authors: Alexander Safstrom (@saefstroem)
Status: Proposed, Implemented and activated in TN10
This KIP introduces a new zero-knowledge (ZK) proof verification opcode: OpZkPrecompile to the Kaspa scripting language. It's name refers to the ability to execute ZK "precompiles", i.e. predefined specific programs meant to alleviate some of the complexities that are involved in designing ZK proof verification systems. The addition of this opcode is the first to enable verifiable computation on the Kaspa network, providing a concrete foundation for Layer 2 solutions and other advanced applications.
This proposal presents an initial framework for introducing zero-knowledge proof verification on Kaspa. Future additions of ZK capability may involve more granular opcodes such that the dependency on concrete precompiles is eliminated. However, the complexity of implementing such contracts at a scripting level makes it very prone to errors. The abundance of exploits and discovered vulnerabilities in ZK systems, make it seem very reasonable to rely on proven implementations instead.
There are several aspects of this proposal that have benefited from broader community input and additional technical review. These have involved the selection of specific proof systems and they now reflect one reasonable path forward among several viable alternatives.
The primary intent of this KIP is to extend the functionality of the Kaspa network and its adoption in the broader DeFi ecosystem through verifiable computation capabilities. By presenting a concrete implementation approach with working code, specific proof system integrations, and a coherent economic model, it is believed to have been achieved. As with any decentralized open source software, the community feedback process should help identify gaps in the current design and surface alternative approaches that may offer advantages.
This proposal deliberately takes positions on contentious technical questions such as which proof systems to integrate first and how to execute them in practice. It should be noted though, that this is done not because these necessarily represent the only defensible choices, but because concrete proposals may enable more productive discussion than abstract frameworks. The reference implementation exists to be examined, tested, critiqued, and improved through community collaboration.
The Kaspa network currently lacks a mechanism for verifiable computation directly on the base layer. Layer 2 networks and applications built upon Kaspa have historically relied on centralized or semi-centralized solutions such as multisignature wallets (multisig), multi-party computation systems (MPC) to facilitate cross-layer asset movement. While functional, these approaches introduce trust assumptions and potential censorship vectors that run counter to blockchain's core principles. They create risks with developing on Kaspa and can be a source of avoidance in integrating Kaspa into the greater DeFi ecosystem.
Zero-knowledge proof verification opcodes address this fundamental limitation by enabling trustless on-chain verification of computational integrity. Any party can define explicit complex rules that cannot fit within the allowed UTXO scripting limits and verify that the rules have been duly followed. Upon successful validation, the transaction script would continue execution and the funds will be unlocked. While the immediate application would be trustless asset movement between layers or other blockchains, the broader implications may extend to privacy-preserving transactions, scalable computation, and novel decentralized application architectures.
The addition of these opcodes represents a potential step toward making Kaspa competitive with other platforms that have integrated similar capabilities.
This proposal introduces a single new opcode: OpZkPrecompile (opcode value: 0xa6).
The OpZkPrecompile opcode operates as a generic ZK precompile execution interface that dispatches to specific proof system implementations based on a tag identifier. A tag identifier is merely a hexadecimal value identifying the opcode to be executed. The opcode expects a tag as its first argument, followed by additional parameters specific to the selected precompile, which usually manifests as a proof system.
The tag value begins at 0x20 to ensure compatibility with the OpData opcode for stack operations.
This opcode design was chosen primarily for extensibility, as new precompiles/proof systems can be added by defining new tags without modifying the core opcode structure. Each precompile implementation defines its own argument structure following the tag identifier.
This architecture separates the generic verification interface from specific proof system implementations, allowing the network to potentially evolve its cryptographic capabilities over time while maintaining backward compatibility with existing precompiles. It should also be noted that this is an inherently critical part of precompile systems as should any third party vulnerabilities arise in the precompiles, they must be isolated from the rest of the system.
The deployment of these opcodes requires a network hard fork, as nodes running older software will reject transactions containing the new opcode. The activation should occur at a predetermined DAA score announced well in advance, providing sufficient time for node operators to upgrade their software.
The pricing model for this opcode will be elaborated in an upcoming KIP.
Recent advances in zero-knowledge cryptography have produced integrated proof systems that significantly simplify verifiable computation implementation. Two primary architectural approaches have emerged: zkVMs that compile arbitrary programs to arithmetic circuits, and domain-specific languages that provide controlled environments for provable computation.
zkVMs based on RISC-V instruction set architecture allow developers to write standard programs in conventional programming languages. These programs can then generate proofs of correct execution proving that: your program X, executed with the following inputs Y, and produced this output Z. Intuitively, this is what Layer 2 networks are doing that are secured by ZK technology. They prove their state which unlocks the funds on the base layer. A Layer 2 system can now batch thousands of transactions, execute them off-chain, generate a proof of correct state transition, and have the base layer verify only the proof rather than re-executing every transaction. Luckily, with many proof systems, the proof can be verified in constant time regardless of program complexity, making it practical to verify intensive computations on-chain.
Several zkVM implementations exist in the ecosystem, each with distinct trade-offs in proof size, generation time, verification cost, and maturity. The selection of initial proof systems for Kaspa integration required careful evaluation of these factors.
The initial implementation integrates the RISC Zero's proof systems, specifically their STARK-based "Succinct" receipts and an Arkworks Groth16 verifier. This selection follows evaluation of available alternatives including SP1, STWO, and other emerging systems.
RISC Zero Evaluation: RISC Zero represents one of the longer-running zkVM projects in production, with substantial deployment history and a relatively mature codebase. The system provides both STARK proofs (quantum-resistant but larger) and Groth16 proofs (compact but not quantum-safe). Their recursion architecture using lift and join programs enables compression of large execution traces into constant-size proofs, which appears critical for on-chain verification with bounded resources. Independent benchmarking by VAC Research comparing multiple zkVM implementations found RISC Zero to be the fastest system for their particular use case, providing third-party validation of performance claims in at least one context.
SP1 Considerations: Succinct's SP1 zkVM has gained attention in the ecosystem and demonstrated competitive performance in certain benchmarks. However, several factors influenced the decision to prioritize RISC Zero for initial integration. A security vulnerability discovered in early 2025 by LambdaClass and 3MI Labs, while responsibly disclosed and patched, raised some questions about the relative maturity of the system at this point in time. Additionally, questions have been raised by competitors regarding benchmark methodology, specifically around the use of a FRI blowup factor of 2 versus the industry-standard factor of 4, which according to a16z analysis provides a roughly 1.5x performance improvement that may not reflect real-world costs once recursion is fully implemented. These concerns do not necessarily preclude SP1 integration in the future, but may suggest allowing additional time for the system to mature and for more independent evaluation to occur.
STWO Status: StarkWare's STWO prover shows promise as a next-generation STARK system, but appears to face current limitations for production integration. The project, at the time of evaluation required nightly Rust compiler features, did not support compilation for Apple Silicon targets, and documentation indicated the prover remains under active development. An attempt to integrate STWO encountered repository stability issues and lack of response from maintainers. The ongoing audit activity observed in the repository suggests the system may not yet be ready for production deployment. During the further discussions with the STWO team, it was deemed that the project had not yet reached the maturity needed in order to be considered for this initial implementation. However, it should be noted, that the STWO is the most promising candidate for an upcoming expansion/addition of the OpZkPrecompile opcode.
Arkworks Groth16: The Arkworks ecosystem provides a mature Rust implementation of the Groth16 proving system that has seen extensive production deployment across the broader zero-knowledge ecosystem. Groth16 itself, introduced by Jen Groth in 2016, remains one of the most widely deployed succinct non-interactive argument systems, with proofs consisting of only three group elements and verification reducible to a small fixed number of bilinear pairings on the BN254 curve. This compactness makes it particularly well-suited for on-chain verification where both proof size and verification cost directly impact transaction economics.
A critical aspect of integrating zero-knowledge proof systems is the explicit acceptance of third-party security dependencies. When Kaspa nodes verify proofs using external cryptographic libraries, they inherit the security properties and potential vulnerabilities of those implementations.
This dependency differs from typical blockchain security models where the network relies primarily on its own cryptographic primitives. In this model, a vulnerability in a proof verification library (such as RISC Zero's verifier, Groth16 implementations (arkworks), or future systems) could potentially compromise the security of transactions using those precompiles.
The following principles guide risk management in this context:
Library Selection Criteria: The proposal suggests integrating only proof systems with substantial production history, active maintenance, security audit history, and open-source transparency.
Isolation and Versioning: Each precompile operates independently, identified by its tag. A vulnerability in one proof system would not necessarily compromise other precompiles or the base layer's fundamental security. Applications could migrate between proof systems as needed, but this may not always be possible.
Users and developers building on these opcodes should understand that their security depends partially on the ongoing maintenance and security of external cryptographic libraries. This represents a conscious trade-off to enable advanced functionality that would be impractical to implement entirely within Kaspa's core codebase and arguably more dangerous.
This proposal defines two initial precompiles leveraging RISC Zero's proof systems and Arkworks Groth16 verifier: Groth16 (tag 0x20) and RISC0-Succinct (tag 0x21). The RISC0-Succint precompile verifies proofs generated by RISC Zero's lift program, which itself verifies execution of arbitrary RISC-V programs and outputs a constant-size receipt.
Groth16 Precompile (tag 0x20)
This precompile verifies Groth16 proofs of any program execution. Groth16 provides extremely compact proofs that are suitable for on-chain verification where transaction size matters. The verification algorithm checks that the proof cryptographically attests to correct execution of a program identified by an image ID, with public outputs committed in a journal digest.
The precompile expects a number arguments on the script stack. The first argument is the uncompressed verifying key itself, serialized in a compact binary format. The second argument is the proof itself, a cryptographic commitment to the public outputs of the verified program. The third argument is the number of public inputs and finally all the public inputs for this verification. Exact detail on which arguments should be specified and in which format are best found within the repository itself which contains a number of examples in both Rust and JavaScript.
The downside however is that this proof system is not quantum safe due to its reduced security when Shor's algorithm is applied.
RISC0-Succinct Precompile (tag 0x21)
This precompile verifies STARK-based succinct receipts, providing quantum-resistant proof verification at the cost of larger proof sizes. The verification process follows a similar structure to Groth16 but uses RISC Zero's STARK verification algorithm.
The precompile expects the three arguments: proof data, journal digest, and image ID. It should be noted though that to allow for more flexibility of the usage the proof data has been split up into more granular elements, see the rusty-kaspa repo for examples and boilerplate code. The proof data for succinct receipts is larger than Groth16 proofs but provides post-quantum security properties. The verification algorithm validates the STARK seal, confirms the control root matches the expected recursion circuit parameters, and ensures the output hash matches the provided claim.
Both precompiles implement a common pattern: they bind the verified program's identity (image ID) and public outputs (journal) to the cryptographic proof, then verify the proof's integrity. This is intended to ensure that the verification confirms not just that some computation was performed correctly, but specifically that the expected program was executed with the claimed outputs.
Common Verification Logic
Both precompiles share a critical verification step that binds the image ID or a verifying key and journal digest or public input to the proof. This computation creates a canonical representation of the execution claim, combining as an example: the program identity, initial and final system states, exit code, and output commitments into a single digest (or the generic public input in the case of Groth16 verification). The verification succeeds only if this computed claim matches the claim embedded in the proof.
This binding is designed to prevent proof malleability attacks where an attacker might attempt to use a valid proof with different claimed inputs or outputs. The cryptographic commitment structure is intended to ensure that the proof verifies the specific execution instance defined by the image ID and journal parameters.
Determining appropriate costs for proof verification with a theoretical upper bound seems to be a research on its own. The reasons for this is that the programmatic computation of bilinear pairings is not done as intuively as on paper. Similarly for STARKs, which require FRI protocol execution with multiple round of polynomial evaluation and Merkle tree queries. Therefore, empirical benchmarking against a known baseline is a rational choice. ECDSA signature verification provides this baseline, as it represents a well-understood computational cost already integrated into Kaspa's fee structure and an expense node operators are used to.
Given these complexities, a benchmark suite was developed to measure actual verification time for ECDSA signatures, RISC Zero STARK proofs, and RISC Zero Groth16 proofs under realistic conditions. To ensure fair comparison, all measurements used identical program execution: a SHA-256 hash computation using RISC Zero's example program. Each verification type was measured over one thousand iterations to establish stable averages and account for variance in execution time.
The benchmark results, conducted on representative hardware, yielded the following average verification times: ECDSA signature verification completed in 12.311 microseconds, Groth16 proof verification required 1.648881 milliseconds, and STARK proof verification took 9.080792 milliseconds. These measurements reflect real-world performance including all overhead from deserialization, memory allocation, and the complete verification procedure as it would occur during transaction validation.
Computing the performance ratio relative to ECDSA provides the cost multiplier for the pricing model. Groth16 verification operates approximately 134 times slower than ECDSA, while STARK verification operates approximately 738 times slower. These ratios translate directly to signature operation unit costs, providing a concrete basis for resource pricing that reflects actual computational burden rather than theoretical estimates. However, it should be noted that future work should ideally compute the upper theoretical bound in order to give an insight on the network's health in non-ideal scenarios.
While this proposal focuses on the mechanism for proof verification, understanding potential applications provides context for the design decisions.
Layer 2 State Verification: A Layer 2 system could execute transactions off-chain, generate a proof of correct state transition, and submit that proof for verification on Kaspa's base layer. The base layer script would verify the proof and, upon success, allow movement of funds corresponding to the proven state change. This allows for scaling without sacrificing security.
Privacy-Preserving Transactions: Zero-knowledge proofs could prove that a transaction satisfies certain properties (such as having sufficient balance or coming from an authorized source) without revealing the underlying details. While Kaspa's UTXO transparency differs from privacy-focused chains, selective privacy features might be built using these opcodes.
Cross-Chain Bridges: Decentralized bridges often require proving events on one chain to another. ZK proofs could attest to blockchain state or transaction inclusion without requiring the verifying chain to process the full blockchain data
Computational Integrity: Complex computations that would be too expensive to execute on-chain could be performed off-chain, followed with a generated proof and then verified on-chain.
Identity and Credentials: Selective disclosure of credentials or attributes could be implemented using zero-knowledge proofs, allowing users to prove they meet certain criteria without revealing underlying personal information.
These applications share a common pattern: separating computation from verification, with cryptographic proofs bridging the gap.
A complete reference implementation of the proposed opcodes and example usage is available in pull request #775 to the rusty-kaspa repository:
The implementation includes the core opcode handling, RISC Zero precompile and a Groth16 verifier, benchmarking infrastructure, and test cases demonstrating correct operation. Developers are encouraged to review the code and provide feedback during the review period.
This proposal builds on extensive research by the Kaspa community into scalability solutions and verifiable computation. The vProgs research initiative has been instrumental in identifying use cases and requirements. Conversations with developers building Layer 2 solutions helped shape the practical requirements for proof verification.
The RISC Zero team's open-source zkVM implementation provided a foundation for integration. The broader zero-knowledge cryptography community's work on proof systems, benchmarking, and security analysis informed the selection criteria and risk assessment.
The addition of zero-knowledge proof verification to Kaspa represents a potential expansion of the network's capabilities. By enabling on-chain verification of off-chain computation, these opcodes could unlock applications ranging from scalable Layer 2 systems to privacy-preserving transactions, decentralized bridge infrastructure and much more.
As the zero-knowledge ecosystem continues to evolve, Kaspa's precompile architecture may position the network to adopt improved cryptographic systems through subsequent proposals. This could create a pathway for continuous enhancement of verifiable computation capabilities while maintaining the stability and security properties that define Kaspa.
LambdaClass, 3MI Labs, and Aligned. "Responsible Disclosure of an Exploit in Succinct's SP1 zkVM." LambdaClass Blog, January 2025. Available at: https://blog.lambdaclass.com/responsible-disclosure-of-an-exploit-in-succincts-sp1-zkvm-found-in-partnership-with-3mi-labs-and-aligned-which-arises-from-the-interaction-of-two-distinct-security-vulnerabilities/
Succinct Labs. "SP1 Security Update 1-27-25." Succinct Blog, January 27, 2025. Available at: https://blog.succinct.xyz/sp1-security-update-1-27-25/
StarkWare. "STWO Cairo Audit Commit." GitHub Repository, 2024. Available at: https://github.com/starkware-libs/stwo-cairo/commit/369cfa89a07f80f0717b4e17b927632663bb7ce0
RISC Zero. "Beating Moore's Law with zkVM 1.0." RISC Zero Blog. Available at: https://risczero.com/blog/beating-moores-law-with-zkvm-1-0
This analysis presents RISC Zero's performance benchmarks and discusses methodology considerations in comparing different zkVM implementations, including commentary on competitor benchmark practices.
a16z Crypto. "FAQs on Jolt's Initial Implementation." a16z Crypto Posts. Available at: https://a16zcrypto.com/posts/article/faqs-on-jolts-initial-implementation/
This independent analysis provides third-party evaluation of zkVM performance claims, specifically noting that SP1's reported speedup factors include approximately 1.5x advantage from using a FRI blowup factor of 2 rather than the industry-standard factor of 4, and that SP1's benchmarks at the time of writing did not account for recursion costs as the feature was not yet fully implemented.
VAC Research. "zkVM Testing and Evaluation." VAC Research Logs. Available at: https://vac.dev/rlog/zkVM-testing#summary-table
This independent third-party evaluation compared multiple zkVM implementations for production use and found RISC Zero to be the fastest system for their specific use case, providing unaffiliated validation of performance characteristics.
RISC Zero. "Recursion in RISC Zero." RISC Zero Developer Documentation. Available at: https://dev.risczero.com/api/next/recursion#recursion-programs
Documentation describing RISC Zero's lift and join programs for proof compression and recursion, which enable constant-size proofs regardless of execution trace length.
RISC Zero. "SHA Example Program." RISC Zero GitHub Repository. Available at: https://github.com/saefstroem/risc0/tree/main/examples/sha
Example program used for benchmarking proof generation and verification performance across different proof systems.
Boundless. "Zeth: Zero-Knowledge Ethereum Block Prover." GitHub Repository. Available at: https://github.com/boundless-xyz/zeth
Example implementation of a zkVM-based Ethereum execution layer using RISC Zero, demonstrating Layer 2 state verification patterns applicable to Kaspa.
Kaspa Research. "vProgs Yellow Paper: Verifiable Programs on Kaspa." Kaspa Research Repository, Page 4. Available at: https://github.com/kaspanet/research/blob/main/vProgs/vProgs_yellow_paper.pdf
Research paper describing verifiable programs architecture for Kaspa, including proof stitching mechanisms and state verification patterns that informed this proposal's design.
Kaspa Network. "KIP-16 Reference Implementation - Pull Request 775." rusty-kaspa GitHub Repository. Available at: kaspanet/rusty-kaspa#775
Complete reference implementation of the proposed OpZkPrecompile opcode, RISC0-Groth16 and RISC0-Succinct precompiles, benchmarking infrastructure, and test cases.
StarkWare. "STWO Cairo Implementation Issues." GitHub Issues. Issue regarding Apple Silicon compilation and verification challenges. Available at: starkware-libs/stwo-cairo#1523
Documentation of technical limitations encountered during attempted STWO integration, including platform compatibility and toolchain stability concerns.
Groth, Jens. "On the Size of Pairing-based Non-interactive Arguments." Advances in Cryptology - EUROCRYPT 2016. Describes the Groth16 proving system used in one of the proposed precompiles.
Ben-Sasson, Eli, et al. "Scalable, transparent, and post-quantum secure computational integrity." IACR Cryptology ePrint Archive. Foundational work on STARK proof systems.