Kaspa ZK Scripts Move From Manual Opcodes To Builder Calls

Michael Sutton merged saefstroem's ZK SDK pull request into rusty-kaspa on June 23. The R&D channel line was short: "Merged the long awaited ZK SDK PR by @saefstroem". ^[1] GitHub records PR #953 as merged by michaelsutton at 2026-06-23T15:21:42Z, with 58 commits, 59 changed files, 3,217 additions, and 540 deletions. (PR #953)

That changes the status of the previous ZK SDK coverage. The June 21 kaspa.news article treated PR #953 as review-stage work because it was still open at the time. (previous coverage) The update now is narrower and stronger: the builder path is merged into the rusty-kaspa master branch. ^[1] (PR #953)

The merged PR adds a ZK SDK path around RISC Zero proofs. Its goal is to reduce the amount of low-level scripting knowledge required when a protocol wants to lock and spend Kaspa UTXOs behind a proof. The PR introduces an R0ScriptBuilder layer around ScriptBuilder, converting Groth16Receipt or SuccinctReceipt proof material into native Kaspa scripts. (PR #953)

The core flow is P2SH commit and reveal. The commit side builds the redeem script that can be hashed into a P2SH address and funded. The finalize side takes the proof and journal material, then returns the signature script and redeem script needed to spend the locked UTXO. (PR #953)

Practically, the SDK helps where ZK proof logic has to become spendable Kaspa transaction code: proof-gated UTXOs, application settlement scripts, browser or Node.js flows using the WASM/JavaScript builder surface, native Rust tooling, and Silverscript-generated verifier paths. It does not ship an application by itself. It gives builders a reusable way to produce the scripts those applications would submit. ^[2] (PR #953)

In a follow-up post, saefstroem framed the Rust and JavaScript examples as useful for new developers and AI agents. Read narrowly, that is an onboarding claim: the examples give humans and coding agents concrete script-building patterns to follow. It is not a separate AI feature inside rusty-kaspa. ^[3]

The final review pass was not just ceremonial. Sutton left a last GitHub suggestion on June 23, saefstroem applied the changes, and Maxim Biryukov approved shortly after. ^{[4] [5] [6]} IzioDev said the comments he had raised were answered and addressed, while saefstroem said he would run one final test before merge. ^{[7] [8]}

One small boundary stayed explicit during review. saefstroem agreed to reject unsupported hash functions on the WASM side so the SDK would not diverge from engine support. ^[9] Sutton also said the low-level fragments API now gives Silverscript what it needs for code generation around r0.succinct.verify(...), r0.g16.verify(...), and direct g16.verify(...) calls. ^[2]

The dependency boundary was checked before merge as well. Maxim asked saefstroem to confirm that the txengine path kept the same dependency versions as before. ^[10] Sutton answered that the dependencies were pinned and that the SDK lives on another crate not used by kaspad. ^[11] That makes the merge easier to read as SDK surface area, not a surprise consensus-node dependency expansion.

The important claim stays modest. This is not a tagged node release and not a production-readiness claim for ZK applications. What landed is a reusable script-building layer for proof-backed Kaspa UTXO flows, with native Rust and WASM/JavaScript-facing paths, final review approval, and a direct route for Silverscript code generation to target the verifier fragments instead of hand-assembling every opcode path. ^{[2] [1]} (PR #953)

All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.