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". (source) 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. (source) (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. (source) (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. (source)
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. (source) (source) (source) IzioDev said the comments he had raised were answered and addressed, while saefstroem said he would run one final test before merge. (source) (source)
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. (source) 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. (source)
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. (source) Sutton answered that the dependencies were pinned and that the SDK lives on another crate not used by kaspad. (source) 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. (source) (source) (PR #953)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
