Beginner’s Quickstart: Build a Silverscript Covenant and Try zk‑Opcodes on Kaspa Testnet

Why this quickstart matters

If you want to move from reading about Kaspa programmability to actually experimenting, the current testnet tooling gives a clear, low‑friction path: start with RPC/SDK interactions, compile a small Silverscript into a covenant, and exercise the L1 zk verification opcodes that are already present in test infrastructure. The point here is practical: follow tools that are documented and labelled experimental, and run everything on Testnet‑12 rather than mainnet until protocols are finalized.

Where the platform stands right now

Kaspa’s recent Toccata announcement describes the covenant‑centric upgrade and lists the core pieces already implemented on test infrastructure, including extended opcodes for covenants, covenant IDs, and zk verification opcodes — the pieces you’ll exercise in this quickstart ^[1]. The official builder docs also group the programmer-facing options (Covenants, vProgs, Inline ZK) and recommend beginning with RPC/SDK workflows before moving into higher‑level covenant tooling like Silverscript ^[2].

What you can try today (high level)

1. Set up access to Testnet‑12. The Silverscript toolchain and many examples are targeted specifically at Testnet‑12 — use that network for experiments rather than mainnet ^[3].
2. Use the Kaspa RPC/SDK to craft and submit transactions. The docs walk through the SDK and RPC patterns you’ll need for signing and broadcasting covenant transactions ^[2].
3. Write a minimal Silverscript program and compile it. Silverscript is a CashScript‑inspired, experimental language that compiles to native Kaspa Script; the repo includes a compiler, examples, and a tutorial to get you started ^[3].
4. Deploy a covenant using your SDK or RPC call, referencing the compiled script and a covenant ID. Covenant IDs and the extended opcodes required to run them are already available on the test infrastructure ^[1].
5. Exercise a zk verification opcode in a controlled test. A reference implementation of zk verification opcodes (OpZkPrecompile) and verifier precompiles was merged into the core test branch, so you can try bounded verifier flows in test deployments; note these are PoC implementations and come with provisional resource‑cost benchmarks ^[4].

Practical notes for each step

• Testnet choice: Silverscript examples in the official repo are explicitly valid on Testnet‑12; the repository README and tutorial clarify this constraint so you won’t be surprised by network mismatches ^[3].
• Start with SDK/RPC: The builder docs recommend beginning here because it lets you confirm transaction shape, signing, and node interactions before you introduce compiler or covenant complexity ^[2].
• Silverscript caveat: The language and compiler are labelled “experimental.” Expect syntax and compiled output to change as the project evolves; keep your experiments on TN12 and track the repo for updates ^[3].
• zk opcodes are available as PoC: The merged PR implementing zk verification opcodes includes example verifier tags (RISC0/Groth16 and STARK‑style tags), benchmarking, and a sigop‑cost model proposed as part of the proof‑of‑concept work — but those numbers are not final production pricing ^[4].

Quick troubleshooting checklist

• If compiled Silverscript fails on broadcast, confirm you are pointed at Testnet‑12 and are using the compiler version referenced in the repo README ^[3].
• When exercising zk verification, watch for gas/sigop failures; the core implementation carries provisional costs and expanded script‑size limits in the test branch, so local tool mismatch can lead to rejections ^[4].
• Read the builder docs for transaction payload and size constraints before attempting large or multi‑input covenants — the docs document node/SDK guidance and limits you must respect ^[2].

Where to read more and follow changes

Primary developer and reference materials you’ll want open while experimenting:

• Silverscript repository — compiler, examples, debugger and tutorial (experimental; TN12 target) ^[3].
• Kaspa builder docs and Kaspa /build — guidance on RPC/SDK usage, programmability choices, and transaction constraints ^[2].
• rusty‑kaspa PR #775 — merged proof‑of‑concept implementation of zk verification opcodes and benchmarking references (useful for testnet experimentation) ^[4].
• Kaspa Research post — background on opcode choices, hash tradeoffs, and design considerations for L1 zk verification ^[5].
• Kaspa Toccata announcement — overview of the covenant‑centric hard fork and the test infrastructure pieces currently in place ^[1].

Caveats and things beginners should watch

Two short cautions for newcomers: first, the Silverscript toolchain and L1 opcode implementations are experimental on testnet and may change; do not expect mainnet parity until official, final releases are posted ^[3][4]. Second, zk verifier implementations in the test branches are PoC‑grade and include provisional sigop/meters — treat their benchmarks as guides for experimentation, not production guarantees ^[4][5].

Next steps after you’ve completed the quickstart

Once you’ve deployed a simple Silverscript covenant and successfully invoked a test zk verifier, consider iterating by adding guarded spend conditions or small introspection hooks. If you plan to build more sophisticated stateful systems, review the vProgs draft to understand how sovereign off‑chain VMs and anchor patterns may evolve on Kaspa in future phases — vProgs are a longer‑term architecture that builds on these same foundations ^[6].

Run experiments on Testnet‑12, track the Silverscript repo and the core test branches, and use the official docs as your safety net. That approach will keep your learning practical, repeatable, and aligned with the current Kaspa developer surface.