The ZK SDK discussion became much sharper than the earlier "API shape" thread. Sutton said the most important part of the SDK is the implementation of commit_to_groth16, while finalize_with_proof is only partly helpful because it maps from the Risc0 receipt object. His proposed direction was that the low-level SDK should be oriented around script builders and should not assume it owns the full end-to-end script flow. (source)
That matters for SilverScript. Sutton described SilverScript as a main client that needs less stack cleverness but can use help mapping Risc0 objects, so a contract like require(risc0.groth16.verify(imageId, journalHash, proof)); can compile into a commit_to_groth16 call while signature-preparing software separately turns the receipt and journal into pushed proof data. (source)
He then wrote a concrete low-level API sketch. For Groth16, push_r0_groth16_witness would consume a receipt and prepare the stack shape, while append_r0_groth16_verifier would append the verifier fragment expecting journal_hash and compressed_proof on stack. For succinct receipts, push_r0_succinct_witness and append_r0_succinct_verifier would follow the same pattern around journal, claim data, control data, and seal. (source)
The main disagreement was journal-hash binding. saefstroem argued that users sometimes need to unlock only for a specific journal hash, and that this should be available at the public API level. Sutton's counter was that a fixed journal is a one-time proof covenant, so a covenant writer can push the constant journal hash before the verifier fragment. (source) (source) (source) (source)
Max143672 pushed the same direction from the low-level side. He argued the SDK should prefer general cases over specific ones, that journal hash can be produced by runtime calculation or passed from redeem script / sigscript arguments, and that higher-level helpers can be built on top once the low-level blocks exist. (source) (source) (source) (source) (source) (source)
IzioDev proposed the compromise: accept lower-level manipulation only for now, and demonstrate fixed or dynamic argument passing in examples until the SDK has enough maturity to justify a higher-level surface. Sutton later added that the receipt-to-proof-byte mapping should probably live in a separate function, because it is often called by the user building the transaction and then pushed into the signature script as pure data. (source) (source)
The thread ended with a smaller but concrete RPC interface proposal: Max143672 proposed using bytes instead of strings for block hashes and hashes in every new RPC endpoint, and IzioDev said this better aligns with wRPC. (source) (source)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.