KASPA

← Groth16 shielded pool·Post-quantumPrototype · not for real value

Post-Quantum Shielded Pool

The same private KAS-for-KAS pool — but every deposit and withdrawal is gated by a RISC Zero STARK, verified on-chain by Kaspa's 0x21 precompile. No trusted setup, no pairing-based cryptography: the proof system is transparent and its security holds against a quantum adversary. Proven live on testnet-10 — a full deposit → withdraw cycle, below.

Try it — deposit & withdraw

Click to deposit; you get a note to keep. Later, withdraw it to a fresh address with a zero-knowledge STARK. Proving runs on the local prover service (~2 min/op) — the panel is honest about exactly what leaves your browser.

What makes it post-quantum

Hash-based STARK

The proof is a RISC Zero succinct receipt — soundness rests on collision-resistant hashing, not on the discrete-log or pairing assumptions a quantum computer would break. That is what “post-quantum” means here.

No trusted setup

Groth16 needs a per-circuit ceremony whose toxic waste, if kept, forges proofs. A STARK is transparent — there is no ceremony and no secret to trust. The proving keys are just the guest program’s image id.

Verified by consensus

The node re-checks the STARK inside the 0x21 precompile and binds it to the baked image id and sha256(journal). An invalid proof is a consensus-invalid transaction — every node rejects it, no operator involved.

The live cycle on this pool

Real transactions on testnet-10, one covenant lineage — genesis to private payout. The deposit and withdraweach carry a real RISC Zero STARK the node verified under consensus. Open any and check the inputs consumed and outputs produced:

genesis
pool created (image ids + maxFee baked) · 5 TKAS
7f0faecbd190
deposit
send-to-fund: the depositor funds their own deposit from any wallet · 0x21 STARK · pool → 15 TKAS
1a3f0ca2c168
withdraw
operator-neutral 0x21 withdraw: single pool input, fee from the denom, pays a fresh address · pool → 5 TKAS
1c3552d7c0c0
Pool covenant id
521ef75b8147d9eea15b2fece4fdf30ea10d0a8244497712e2b2a96d16eb673d

Every box in the lineage carries this covenant_id — the pool's stable, Kaspa-internal identity. It is not an explorer search term (explorers index txids and addresses, not covenant ids). To verify the pool yourself, open any transaction above and follow output 0 forward — the pool's address changes at each state, but the covenant_id stays constant across them. Each note withdraws exactly once — the nullifier tree makes a replay consensus-invalid.

Two pools, side by side

Kaspa L1 exposes both proof systems as precompiles, so we run one shielded pool on each. Pick by what you value — tiny in-browser proofs today, or a transparent, quantum-resistant setup.

Groth16Post-quantum
Precompile0x20 · BN254 Groth160x21 · RISC Zero STARK
Trusted setupper-circuit ceremonynone — transparent
Post-quantumno — pairing / elliptic-curveyes — hash-based
Proof size~128–256 bytes~217 KB
Node verify cost140k grams250k grams
Where you provein your browser (WASM)locally / prover service (~min)
Best foreveryday private transfersfuture-proof, high-assurance

Neither is strictly better — that's the point. Groth16 gives you tiny, in-browser proofs today; the STARK pool trades proof size and prove-time for a transparent, quantum-resistant setup.

How you make a proof (the honest tradeoff)

Groth16 pool → your browser

The circuit is small enough that a WASM prover runs in your tab in a second or two. Your nullifier and secret never leave your machine — the page just publishes the ~128-byte proof.

Post-quantum pool → local prover service

A RISC Zero proof is ~217 KB and takes minutes of CPU — too heavy for a browser tab. So the app above stays one-click, but the proving runs on a local prover service (~2 min). Your notes live in your browser; a withdrawal hands its note to that prover. The on-chain guarantee is identical; only where you prove differs.

A prover-service and hardware acceleration are the obvious next step — the same succinct receipt, produced faster. Nothing about the on-chain covenant changes.

Where this demo is

doneThe 0x21 RISC Zero precompile verifies a real succinct receipt under Kaspa consensus — deposit and withdraw both proven on-chain (no trusted setup).
doneFull cycle closed on TN10: genesis → deposit → screen (governance proof-of-innocence) → private withdrawal, with nullifier double-spend protection.
doneStateful prover: an incremental Merkle deposit tree + a sparse-Merkle nullifier tree generate correct witnesses for any leaf — multiple deposits and arbitrary withdrawals, all confirmed on-chain.
liveFully interactive above: click to deposit/withdraw, backed by a local prover service (~2 min/op). The pool lineage is walkable from any public node.
nextHardware / GPU acceleration so the ~2-minute proof becomes near-instant, and a browser-friendly witness hand-off so the withdraw note never leaves your machine.
laterExternal audit of the guests and covenant. Only then is any of this considered for real value.

Testnet-10 only · unaudited prototype · prototype cryptographic parameters · not for real value. Built as open research from the kUSD covenant work; source opens with the framework release.