diff --git a/README.md b/README.md
index bf6de03..fd6a50e 100644
--- a/README.md
+++ b/README.md
@@ -14,4 +14,5 @@ Kaspa Improvement Proposals (KIPs) describe standard proposals for the Kaspa net
 | [10](kip-0010.md) | Consensus, Script Engine | New Transaction Opcodes for Enhanced Script Functionality | Maxim Biryukov, Ori Newman | Active |
 | [13](kip-0013.md) | Consensus | Transient Storage Handling | Michael Sutton, coderofstuff | Active |
 | [14](kip-0014.md) | Consensus | The Crescendo Hardfork | Michael Sutton | Active |
-| [15](kip-0015.md) | Consensus | Canonical Transaction Ordering and Sequencing Commitments | Mike Zak, Ro Ma | Active |
\ No newline at end of file
+| [15](kip-0015.md) | Consensus | Canonical Transaction Ordering and Sequencing Commitments | Mike Zak, Ro Ma | Active |
+| [16](kip-0016.md) | Consensus | ZK Precompile Opcode | Alexander Safstrom | Active |
\ No newline at end of file
diff --git a/kip-0016.md b/kip-0016.md
new file mode 100644
index 0000000..b9bc491
--- /dev/null
+++ b/kip-0016.md
@@ -0,0 +1,309 @@
+```
+  KIP: 16
+  Layer: Script Engine, ZK
+  Title: New Transaction Opcodes for Verifiable Computation
+  Authors: Alexander Safstrom (@saefstroem)
+  Status: Proposed
+```
+
+**AI Use Disclosure**:
+This KIP was refined using AI based on a manually written draft.
+
+## Abstract
+
+This proposal introduces zero-knowledge proof verification opcodes to the Kaspa scripting language. The primary addition is `OpZkPrecompile`, an abstract opcode that invokes ZK frameworks to verify proofs passed as arguments. This enhancement aims to enable verifiable computation on the Kaspa network, potentially providing a foundation for decentralized Layer 2 solutions and other advanced applications requiring cryptographic proof verification.
+
+
+## Implementation Status and Scope
+
+This proposal presents a foundational framework for zero-knowledge proof verification on Kaspa rather than a fully finalized implementation ready for immediate deployment. The reference implementation provided with this KIP represents substantial engineering work and demonstrates viability of the approach, but it should be understood as an initial building block that establishes a possible architectural direction rather than a complete solution that has addressed all edge cases and operational considerations.
+
+Several aspects of this proposal would benefit from broader community input and additional technical review. The selection of specific proof systems, while informed by available evidence and benchmarking, reflects one reasonable path forward among several viable alternatives. The parameter adjustments proposed for script sizes and mass limits represent initial estimates based on current proof sizes, though real-world usage patterns may reveal different optimal configurations. The pricing model, though grounded in empirical benchmarking, establishes a starting framework that will likely require refinement as the network gains operational experience with proof verification workloads.
+
+The primary intent of this KIP is to initiate substantive technical discussion within the Kaspa community about integrating verifiable computation capabilities. By presenting a concrete implementation approach with working code, specific proof system integrations, and a coherent economic model, this proposal aims to move the conversation from theoretical possibility to practical engineering considerations. The community feedback process should help identify gaps in the current design, surface alternative approaches that may offer advantages, and contribute to establishing consensus around the specific technical decisions required for production deployment.
+
+This proposal deliberately takes positions on contentious technical questions—such as which proof systems to integrate first and how to price verification operations—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.
+
+Subsequent revisions of this proposal will incorporate feedback from the review process, address identified limitations, and potentially adjust technical specifications based on testing results and community input. The path from this initial proposal to activated network functionality will involve iterative refinement, and this document should be read as opening that process rather than concluding it.
+
+
+## Motivation
+
+The Kaspa ecosystem currently lacks a mechanism for verifiable computation directly on the base layer. Layer 2 networks and decentralized applications have historically relied on centralized solutions such as multisignature wallets or multi-party computation systems 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.
+
+Zero-knowledge proof verification opcodes could address this fundamental limitation by enabling on-chain verification of computational integrity. Any party could submit a cryptographic proof for verification, and upon successful validation, the transaction script would continue execution. While the immediate application would be trustless asset movement between layers, 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.
+
+## Specification
+
+### 1. New Opcodes
+
+This proposal introduces a single new opcode: `OpZkPrecompile` (opcode value: `0xc4`).
+
+### 2. Opcode Behavior
+
+The `OpZkPrecompile` opcode operates as a generic verification interface that dispatches to specific proof system implementations based on a tag identifier. The opcode expects a tag as its first argument, followed by additional parameters specific to the selected proof system.
+
+The tag value begins at `0x20` to ensure compatibility with the `OpData` opcode for stack operations. This design provides extensibility, as new 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.
+
+### 3. Implementation Considerations
+
+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.
+
+
+### 4. Opcode Pricing Model
+
+Proof verification consumes significantly more computational resources than standard signature verification. To maintain network efficiency and prevent resource exhaustion attacks, the cost of executing ZK precompiles is denominated in signature operation units (sigops). This approach provides an intuitive comparison metric: if a proof verification operation is 100 times more expensive than ECDSA signature verification, it consumes 100 sigops.
+
+This pricing model leverages existing infrastructure for limiting computational load per transaction while providing flexibility to adjust costs as proof systems evolve and hardware improves. The specific costs for each precompile are determined through benchmarking and detailed in subsequent sections.
+
+### 5. Zero-Knowledge Proof Systems Background
+
+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 languages, then generate proofs of correct execution without revealing inputs. With many proof systems, the proof can be verified in constant time regardless of program complexity, making it potentially practical to verify intensive computations on-chain without processing the full execution.
+
+This capability may enable two critical use cases. First, it allows proving knowledge of private information without disclosure, enabling privacy-preserving applications. Second, it permits proving that a computation occurred correctly without requiring on-chain re-execution, which may be fundamental to Layer 2 scalability solutions. A Layer 2 system could 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.
+
+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 requires careful evaluation of these factors.
+
+### 6. Proof System Selection Rationale
+
+The initial implementation integrates RISC Zero's proof systems, specifically their STARK-based "Succinct" receipts and Groth16 circuits. 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 seems to require nightly Rust compiler features, does not support compilation for Apple Silicon targets, and documentation indicates 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.
+
+**Integration Philosophy:** 
+This proposal takes a pragmatic approach while acknowledging the rapidly evolving nature of zero-knowledge proof systems. RISC Zero appears to offer sufficient production maturity for initial deployment at this time, and the precompile architecture is designed to support additional proof systems as they become viable candidates for integration.
+
+SP1 represents a compelling alternative that warrants consideration for future integration as the system continues to mature and the community gains more operational experience with it. Similarly, STWO and Cairo-based systems show promise and could be evaluated for integration as their ecosystems stabilize and address current limitations. The vProgs research initiative's exploration of Cairo implementation may provide valuable insights, and collaboration with StarkWare could potentially help resolve serialization efficiency concerns that currently appear to impact on-chain proof verification feasibility.
+
+The selection of RISC Zero for initial deployment should be understood as a starting point based on present circumstances rather than a definitive long-term commitment to a single proof system. The zero-knowledge cryptography landscape is developing rapidly, and what appears optimal today may be superseded by better alternatives tomorrow. The precompile architecture attempts to accommodate this evolution by enabling integration of additional or improved proof systems through subsequent proposals, though the actual trajectory will depend on how these technologies develop and what the community's needs prove to be.
+
+### 7. Security Considerations: Third-Party Dependencies
+
+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, 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. RISC Zero appears to meet these criteria with multiple years of production deployment and public security review, though continued monitoring would be appropriate.
+
+**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 can migrate between proof systems as needed.
+
+**Community Review:** All integrated libraries would undergo review by the Kaspa development community. The open-source nature of both Kaspa and the proof system libraries enables community security analysis.
+
+**Upgrade Path:** The precompile architecture allows deprecating insecure implementations and introducing improved alternatives without requiring fundamental protocol changes.
+
+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.
+
+### 8. Initial Precompile Implementations
+
+This proposal defines two initial precompiles leveraging RISC Zero's proof systems: RISC0-Groth16 (tag `0x20`) and RISC0-Succinct (tag `0x21`). Both precompiles verify proofs generated by RISC Zero's lift program, which itself verifies execution of arbitrary RISC-V programs and outputs a constant-size receipt.
+
+**RISC0-Groth16 Precompile (tag 0x20)**
+
+This precompile verifies Groth16 proofs of RISC-V 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 three arguments on the script stack, processed in last-in-first-out order. The first argument is the proof data itself, serialized in a compact binary format. The second argument is the journal digest, a cryptographic commitment to the public outputs of the verified program. The third argument is the image ID, a unique identifier of the program being verified derived from its compiled form.
+
+During verification, the precompile deserializes the proof, converts the image ID and journal to the appropriate digest format, binds these values to the proof's claim structure, and verifies the cryptographic integrity using RISC Zero's Groth16 verifier with the standardized BN254 curve parameters. Any failure in this process causes the transaction script to terminate with an error.
+
+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 same three arguments: proof data, journal digest, and image ID. 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 and journal digest to the proof's claim structure. This computation creates a canonical representation of the execution claim, combining the program identity, initial and final system states, exit code, and output commitments into a single digest. 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.
+
+### 9. Opcode Pricing
+
+Determining appropriate costs for proof verification requires empirical benchmarking against a known baseline. ECDSA signature verification provides this baseline, as it represents a well-understood computational cost already integrated into Kaspa's fee structure.
+
+Theoretical cost estimation for zero-knowledge proof verification presents significant challenges that make empirical benchmarking the more reliable approach. While some cryptographic operations have relatively straightforward cost models—Groth16 verification, for instance, primarily involves a fixed number of bilinear pairings on elliptic curves. STARK-based systems involve considerably more complex computational patterns. STARK verification requires FRI protocol execution with multiple rounds of polynomial evaluation, numerous Merkle tree queries for commitment verification, and hash function invocations that vary with security parameters and proof structure. The computational cost depends on factors including the specific hash function implementation, the degree of parallelization possible on given hardware, and memory access patterns that can vary significantly across different processor architectures. Additionally, the interaction between these components makes it difficult to construct accurate cost models from first principles without extensive profiling data.
+
+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.
+
+**Proposed Pricing:**
+
+- Standard signature verification: 1 sigop unit (1,000 grams)
+- RISC0 Groth16 verification: 140 sigop units (140,000 grams, approximately 0.0014 KAS)
+- RISC0 STARK verification: 740 sigop units (740,000 grams, approximately 0.0074 KAS)
+
+These costs reflect only the computational component. The total transaction fee includes additional charges based on transaction size. A STARK proof of approximately 223 KB would incur roughly 1 million mass units (approximately 0.01 KAS) when combining size and computation costs.
+
+This pricing model will likely require periodic review as hardware improves and proof systems evolve. Future optimizations in proof generation or verification may warrant cost adjustments to maintain economic balance while encouraging adoption of verifiable computation.
+
+### 10. Network Parameter Adjustments
+
+Supporting zero-knowledge proof verification requires substantial increases to several network limits. Current parameters were designed for simpler transaction types and cannot accommodate the data requirements of cryptographic proofs.
+
+RISC Zero's lift program generates STARK proofs of approximately 223 KB, representing the current practical target for on-chain verification. Supporting these proofs requires coordinated increases across multiple parameters to maintain network consistency.
+
+**Script and Element Limits:**
+
+The maximum script size would increase from 10,000 bytes to 300,000 bytes to accommodate proof data and associated verification logic. The maximum script element size would similarly increase from 250 bytes to 250,000 bytes to allow proof data to be passed as a single stack element. The maximum signature script size would increase to 300,000 bytes, enabling proofs to be included in the unlocking script where they are typically required.
+
+**Mass Limits:**
+
+Computational mass limits must account for both the proof data size and the high sigop costs of verification. With the most expensive precompile currently requiring 740 sigops, and anticipating potential future precompiles requiring up to 1,000 sigops, the maximum standard transaction mass would increase from 100,000 to 1,000,000 units. This would allow a transaction to include a large proof plus substantial verification logic without exceeding limits.
+
+Transient mass, which accounts, would increase from 100,000 to 600,000 units. This assumes a reduced transient byte-to-mass conversion factor of 2 instead of 4, recognizing that proof data, while large, is temporary and does not permanently burden the UTXO set.
+
+**Block Limits:**
+
+The maximum block mass would increase from 500,000 to 1,500,000 units, maintaining proportionality with transaction-level increases. This linear scaling is intended to ensure that block production remains stable while accommodating the new transaction types.
+
+The maximum number of standard P2SH signature operations would increase from 15 to 1,000, aligning with the sigop-based pricing model for ZK verification. This change reflects that sigops would now measure diverse computational work rather than exclusively signature verification.
+
+**Parameter Summary:**
+
+- `MAX_SCRIPT_SIZE`: 10,000 → 300,000
+- `MAX_SCRIPT_ELEMENT_SIZE`: 250 → 250,000
+- `MAXIMUM_STANDARD_SIGNATURE_SCRIPT_SIZE`: 1,650 → 300,000
+- `MAXIMUM_STANDARD_TRANSACTION_TRANSIENT_MASS`: 100,000 → 600,000
+- `MAXIMUM_STANDARD_TRANSACTION_MASS`: 100,000 → 1,000,000
+- `MAX_STANDARD_P2SH_SIG_OPS`: 15 → 1,000
+- `TRANSIENT_BYTE_TO_MASS_FACTOR`: 4 → 2
+- `MAX_BLOCK_MASS`: 500,000 → 1,500,000
+
+**Implications:**
+
+These parameters would support approximately one proof verification per block under current limits. This represents a conservative initial deployment that prioritizes network stability. As the community gains experience with proof verification workloads and their impact on block propagation and validation, these limits can be revisited.
+
+There is reasonable concern that one proof per block may be insufficient for active Layer 2 systems or other high-demand applications. Further discussions may be necessary to determine which parameters are most suitable for the network's needs.
+
+### 11. Forward Compatibility and Extensions
+
+The precompile architecture is designed for extensibility. New proof systems can be added by defining new tags and implementing the corresponding verification logic. This could allow Kaspa to adopt improved cryptographic systems as they mature without fundamental protocol changes.
+
+Several proof systems are potential candidates for future integration:
+
+**Cairo/STWO Integration:** The vProgs research initiative is actively exploring Cairo-based implementations. Integration would require addressing proof serialization efficiency, as current JSON-based Cairo proof formats exceed 1.9 MB. Collaboration with StarkWare on more compact serialization could potentially make Cairo verification practical for on-chain use.
+
+**SP1 Integration:** As Succinct's SP1 zkVM matures and addresses the concerns noted in the selection rationale, it may represent a strong candidate for addition. The competitive dynamics between multiple zkVM providers could benefit users through innovation and optimization.
+
+**Specialized Proof Systems:** Beyond general-purpose zkVMs, specialized proof systems optimized for specific applications (such as signature aggregation, light client verification, or privacy protocols) could potentially be added as dedicated precompiles.
+
+The key principle is that no single proof system will likely dominate permanently. The cryptographic landscape evolves rapidly, and Kaspa's architecture should ideally accommodate that evolution through measured, deliberate expansion of supported systems.
+
+### 12. Application 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 could potentially enable 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 full block headers or merkle proofs.
+
+**Computational Integrity:** Complex computations that would be too expensive to execute on-chain could be performed off-chain with proof generation, then verified on-chain. This might enable applications like on-chain game state transitions, complex financial calculations, or algorithmic verification.
+
+**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. This could potentially enable Kaspa to support application complexity that would be impractical with on-chain execution alone.
+
+### 13. Reference Implementation
+
+A complete reference implementation of the proposed opcodes and example usage is available in pull request #775 to the rusty-kaspa repository:
+
+[https://github.com/kaspanet/rusty-kaspa/pull/775](https://github.com/kaspanet/rusty-kaspa/pull/775)
+
+The implementation includes the core opcode handling, both RISC Zero precompiles, benchmarking infrastructure, and test cases demonstrating correct operation. Developers are encouraged to review the code and provide feedback during the review period.
+
+### 14. Acknowledgments
+
+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.
+
+## Conclusion
+
+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 and decentralized bridge infrastructure.
+
+The proposed implementation takes a measured approach, integrating what appear to be proven proof systems while maintaining architectural flexibility for future expansion. The economic model attempts to balance accessibility with resource protection, and the parameter adjustments aim to provide adequate capacity for initial adoption while preserving network performance characteristics.
+
+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.
+
+The next phase requires community input on the specification, thorough testing of the implementation, and careful planning of the deployment timeline. With successful execution, Kaspa could join the ranks of blockchain platforms supporting native verifiable computation, potentially opening new possibilities for decentralized application development.
+
+## References
+
+### Security Disclosures and Audits
+
+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
+
+### Performance Benchmarks and Technical Evaluations
+
+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.
+
+### Zero-Knowledge Proof Systems and Architecture
+
+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.
+
+### Layer 2 and Verifiable Computation Research
+
+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.
+
+### Implementation and Development Resources
+
+Kaspa Network. "KIP-16 Reference Implementation - Pull Request 775." rusty-kaspa GitHub Repository. Available at: https://github.com/kaspanet/rusty-kaspa/pull/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: https://github.com/starkware-libs/stwo-cairo/issues/1523
+
+Documentation of technical limitations encountered during attempted STWO integration, including platform compatibility and toolchain stability concerns.
+
+### Cryptographic Foundations
+
+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.
\ No newline at end of file