Kusama ZK Bounty: Transparency Report, Q2 2026
From the curators of the Kusama Zero Knowledge Bounty
“A note on links: new forum accounts are limited to two links per post, so only two addresses in this report are clickable. The rest are written as plain text you can copy, and everything referenced is also reachable from the two live links.”
This bounty was set up with a remit that is easy to say and hard to do: make privacy native to Kusama, so that zero knowledge becomes ordinary infrastructure any builder here can reach for. This report arrives alongside news worth your attention: ZK Email’s first milestone for Kusama has just shipped.
Fourteen proposals
Fourteen detailed, strong proposals have come through the door so far, and the range is striking. Private voting for OpenGov. Proof of personhood. Biometric identity. A bridge from EU digital identity credentials. Developer SDKs and verifier tooling. Formally verified AI agents. On-device proving so farmers can evidence their fields for credit. Email verification. Benchmarking studies. If anyone doubted there was appetite for zero knowledge work in this ecosystem, the pipeline says otherwise.
To every team that has put work in front of us: thank you. The standard has been high. The first funding decision has been made, and there will be more to share in due course.
Improving tooling and developer experience
We have prioritised work that optimises modern zero knowledge tools to run faster and more cheaply on PolkaVM. Our first funding wave onboards a popular zero knowledge toolkit into Kusama, and includes work on making tools such as Noir run more efficiently, at lower cost, on PolkaVM.
Why ZK Email
The first project to reach delivery is ZK Email (zk.email). If you haven’t met it before, the idea is disarmingly simple. Almost every email you receive is already cryptographically signed by the sending mail server under a standard called DKIM. ZK Email lets you prove things about a signed email (that you received it, who sent it, what a particular field says) without revealing the email itself. That allows a wide range of applications, from anonymously proving you received an email to running projects such as peer.xyz and ZK Passport. For any application that sends confirmation emails, you can now write ZK programs that let your smart contracts verify that you have paid for your music ticket via email. ZK Email is a mature project: the circuits are audited, open source, and already run account recovery in production for Safe, Base and Clave on Ethereum. This isn’t speculative research; it’s a working primitive that Kusama didn’t have.
We have allocated $70,400 to bring it here, split evenly across two milestones and released as each one is delivered and verified.
Milestone one is live
M1 is the foundation: the DKIM registry, compiled to PolkaVM and live on Paseo Asset Hub. The registry records the mail-server signing keys (as hashes) that every email proof is checked against, with registration, rotation and revocation, so it’s the trust anchor for everything built on top. We checked it ourselves on chain before accepting it, and the full release, deployment addresses and all, is public on Github.
You don’t need to wait for mainnet to try the underlying technology. Go to the ZK Email registry at registry.zk.email, pick a blueprint or build your own, and generate a proof from an email in your inbox today. The docs (docs.zk.email) are good, and the code is all public — it lives in the same repository as the release above.
What the numbers suggest about Kusama
The part most worth your attention sits in the M1 cost benchmarks — the file 05_cost_benchmarks.md in the release linked above. Registering a signing key costs 4,267 gas on PolkaVM against 50,318 on the EVM, though the two virtual machines meter gas differently, so money is the fairer comparison. At the quietest gas prices the benchmark records, the two chains cost about the same. In the 5 to 20 gwei range the benchmark also models, the same registration runs $0.45 to $1.79 on Ethereum against about $0.014 on Kusama, roughly 30 to 125 times dearer. The team is plain about the caveats: the Kusama figures are projected from Paseo weights, and prices move.
There is a structural reason to think this holds beyond one benchmark. The stack behind these numbers is PolkaVM, a RISC-V virtual machine built in Rust, and pallet-revive now documents built-in BN254 precompiles for the pairing operations that Groth16 verification needs. A Groth16 proof is a few hundred bytes whichever chain verifies it; what differs is the cost of verifying it and of maintaining the state around it, and that is where this stack looks strong. A good deal of modern proving tooling is written in Rust, which suits it, and existing Solidity contracts come across through resolc. Early days, but if you’re choosing where to build a ZK application, the economics here deserve a look.
What is still to come
Milestone two, the verifier tooling, is in review now. It generates a Groth16 verifier contract for each email blueprint, targeting EVM and PolkaVM from one codebase and wired into the M1 registry, and we’ll say more when the review is done.
Beyond that, a mainnet phase is on the roadmap but not yet funded: the blueprint deployment pipeline, on-chain verification in the SDK, and the registry pointed at Kusama itself. If that lands, the whole thing becomes self-service. Any builder could pick an email blueprint, or write one, and verify proofs of it on Kusama without asking anyone’s permission.
What might you build then? Wallet recovery through the email account you already own is the obvious one; it’s the pattern Safe and Clave proved on Ethereum. From there it gets more interesting: proving you received a ticket or a payslip without showing anyone its contents, contracts that accept an instruction authorised by an organisation’s own email domain, attestations feeding the identity and proof-of-personhood efforts taking shape across the ecosystem. Email is one of the most widely held identifiers on the internet; this makes it a private, verifiable one.
Open source mandate
The curators have agreed an open source mandate: we will only fund open source applications, aligning with Kusama’s vision of inspiring open, creative experiments.
The bigger picture
None of this is a one-off. The direction of travel is set out in RFP#000, the Privacy OS, on the RFPs page of the bounty site: a stack where private data storage, private communication and a unified Rust SDK make privacy the default. An email primitive slots straight into the identity layer of that stack, and it’s exactly the kind of building block we hope others will pick up and compose into things we haven’t thought of. That is the web3 this bounty exists for: trust that comes from mathematics rather than institutions. The RFPs are living documents, and as RFP#000 itself puts it, “There are no gatekeepers. Good ideas and solid engineering win.”
Do you have a crazy privacy idea? We will fund you! Applications that utilise permissionless and resilient execution on Kusama are of particular interest — apply today via the bounty site below.
Get involved
If you’re building in this space, or want to be, apply at zk.kusama.vision. Before you write a word, come and talk to us in the ZK Space on Matrix — open the room #kusama-zk:virto.community in any Matrix client; we read everything. The RFPs are the best picture of the work we want to see, and they’re open for anyone to challenge or extend. Fourteen proposals in, we want the next fourteen.
More from us when there is more to show.
The ZK bounty curators