Nullifier Prime: Compliant & programmable privacy

[mmagician]

Project Abstract

Our vision is a chain where compliant and programmable privacy is a first-class citizen, and where UX is as smooth as using a wallet today, with the cryptography & private asset management abstracted away.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[mmagician]

I have read and hereby sign the Contributor License Agreement.

[mmagician]

@semuelle @AlistairStewart do you have any updates yet?

[AlistairStewart]

This proposal aims to integrate zerocash type shielded pools into the EVM and provide wallet support for shielded transactions. The SNARK part would have to differ from Zcash's orchard in a couple of ways

1. Using Poseidon instead of Sinsemilla. Presumably this is because there is better library support for the former e.g., for the Plonky3 plan?
2. Adding verifiable encryption for notes for compliance, which isn't part of this grant, right?
   This grant explicitly does not give any SNARK related work as a deliverable but instead focusses on the EVM and wallet integration. The goal is to obtain some privacy while using existing Defi infrastructure that is mostly built on EVM smart contracts.

This would be a good fit for the Kusama initiative if we are planning to deploy a Plaza like EVM smart contract chain to Kusama. The work requested would seem to be reasonable for the tasks.

It's not revolutionary but could be very useful for getting privacy with things that people actually use.

[mmagician]

@AlistairStewart thanks for the review.

---

Using Poseidon instead of Sinsemilla. Presumably this is because there is better library support for the former e.g., for the Plonky3 plan?

Exactly.

---

Adding verifiable encryption for notes for compliance, which isn't part of this grant, right?

Correct. That part would be done further down the line, either as a follow-up grant or as part of the Kusama initiative once that's in place.

---

This grant explicitly does not give any SNARK related work as a deliverable

We do, actually - Milestone 2.3 has ZKP verification precompiles that need to be added to the protocol. While the primitives themselves might not be novel, the circuits that verify Merkle Tree paths and hashes will need to be developed to account, e.g., different hash function, as well as some EVM-specific elements.

[mmagician]

@semuelle @takahser a friendly ping to see if you've had a chance to discuss the application yet :)

[takahser]

@mmagician this looks very interesting. 👍

Could you help me with the following questions?

• Proof Creation Performance: Do you foresee the proofs being generated directly on the user’s device (e.g., desktop or mobile wallet)? If so, is this viable in terms of latency/UX?

• Verification Performance: On the on-chain side, do you have any performance expectations or benchmarks for proof verification?

• Compliance & Backdoors: If the chain launches without embedded “compliance backdoors,” how would compliance be introduced later on? Am I correct in assuming that past transactions would remain non-deanonymizable?

• No-Click Privacy: Could you elaborate on how the “no-click privacy” will work in practice? In particular, what UX components are planned beyond the CLI, and how does this compare to existing privacy wallets?

• EVM Compatibility: Will users be able to call arbitrary EVM contracts directly from a shielded state? Or does unshielding need to happen first? Do contracts need to be privacy-aware, or can "legacy" apps integrate seamlessly?

• PVM Compatibility: Will your solution be compatible with PVM contracts (Hub)?

• DeFi collabs: Are there specific DeFi projects or verticals you’ve identified as natural early adopters for this? Would be great to understand your go-to-market thinking here.

[mmagician]

Thanks for the thoughtful questions @takahser. I answered all below:

Proof Creation Performance: Do you foresee the proofs being generated directly on the user’s device (e.g., desktop or mobile wallet)? If so, is this viable in terms of latency/UX?

Yes, initially desktop (via a CLI, Milestone 3.2 & 3.3). Since the circuits are "fixed" (i.e., there is no execution of arbitrarily large, user-defined programs, like in ZEXE), proof generation can be done in a few seconds on a consumer laptop (think 3-5 seconds) using FRI.

Verification Performance: On the on-chain side, do you have any performance expectations or benchmarks for proof verification?

ZKP verification has negligible time impact on the transaction verification. For example, FRI has a verification time of 3ms for a circuit size we expect (~2^20 2^22).

The numbers I quote for proof generation & verifier benchmarks of FRI (backend of Plonky3 which we consider using) are from Figure 2 of STIR.

Compliance & Backdoors: If the chain launches without embedded “compliance backdoors,” how would compliance be introduced later on? Am I correct in assuming that past transactions would remain non-deanonymizable?

The chain wouldn't launch without compliance checks on. As explained in my comment above, "That part would be done further down the line, either as a follow-up grant or as part of the Kusama initiative once that's in place."
Note that we already have a design of a compliant protocol in place, as well as its sample implementation. As you can see from the implementation write-up, adding the compliance component is rather "trivial" (at least compared to the rest of the work outlined in the three milestones here). However, our implementation naively uses RSA, which is not the most efficient primitive for the job. In the follow-up work, we will finalize the concrete cryptographic primitives and instantiation for our design (most likely using ElGamal encryption, but still TBD).

No-Click Privacy: Could you elaborate on how the “no-click privacy” will work in practice? In particular, what UX components are planned beyond the CLI, and how does this compare to existing privacy wallets?

The goal is for the user to perform no more clicks than they need to today using crypto wallets. Specifically, users shouldn't have to think (and by extension, shouldn't take action) regarding the value of their transactions. Compare that to e.g. Tornado Cash, which required deposits of fixed bucket amounts (0.1, 1, 10, 100 ETH), so if a user wanted to privately use 14.20 ETH in a DeFi protocol, they'd have to manually send the amounts to various pools (7 tx in total, all manual). Instead, we'd have splitting of amounts integrated directly into the wallet, and rather than using fixed buckets - utilize randomized splitting (wallet supplies randomness to determine how many Tx's to split into, and what are the individual amounts. This is based on the current chain activity: more temporary volume means we can split into less transactions, since the current anonymity pool is larger).

No other wallet does anything remotely similar. As such, a ton of wallet innovation is needed as part of our project. If we have any hopes of widespread privacy, we need to revamp the existing wallet infra.

Note that this is work reserved for the Kusama initiative and not part of the deliverables here.

EVM Compatibility: Will users be able to call arbitrary EVM contracts directly from a shielded state? Or does unshielding need to happen first? Do contracts need to be privacy-aware, or can "legacy" apps integrate seamlessly?

Unshielding needs to happen first, but the wallet will do this automatically (no-click😃 ).
Contracts don't need to change anything at all - that's the beautiful part of our design, allowing devs to port contracts seamlessly.
Any EVM contract can be called (but as you rightly notice - it's not "from a shielded state" but rather by unshielding first).

PVM Compatibility: Will your solution be compatible with PVM contracts (Hub)?

This grant only covers compatibility via Frontier, i.e., EVM contracts only. For the Kusama initiative, we will evaluate the scope of work involved in extending to PVM.

DeFi collabs: Are there specific DeFi projects or verticals you’ve identified as natural early adopters for this? Would be great to understand your go-to-market thinking here.

We're leaning towards a hybrid approach now (à la Berachain with their Native dApps) of curating a few apps in-house that work really well but also giving developers who care about privacy a platform for reaching the community they care about. We would like to roll out the first app ourselves, most likely DEX, which can simply be a branded version of an existing AMM. This will be a demo to show how such apps integrate seamlessly with our privacy design.

Majority of the current EVM chains (across any ecosystem) have the same EVM-only functionality. A privacy-by-default protocol provides differentiation in a market where neither users nor the liquidity is sticky. We believe that such strong differentiation and value proposition will be enough to attract swaths of app developers to port their apps to our chain.

Interestingly, since we require little-to-no-integration from devs, the majority of our BD efforts will need to focus on bringing in liquidity (classic problem for new chains) and working with market makers, so that DeFi apps deployed on our chain provide a good (financial) UX.

Let me close with outlining the vision timeline for our chain:
Short-term: target crypto-native users’ needs, focus on DeFi.
Mid-term: onboard the incoming wave of web3 users (currently - memecoin traders; next - AI Agents & other emerging trends) onto our private-by-default blockchain.
Long-term: position ourselves as the go-to solution for institutional entities (e.g., asset management, investment) who value performance and privacy.

While the above GTM discussion focuses on short-term, we have ambitious plans to become the go-to infrastructure for institutional adoption of crypto, and as such will place high importance on stablecoins & payments support going to mid & long term.

[keeganquigley]

Thanks for the deep dive @takahser and your thorough answers @mmagician I'm personally willing to support it.

[takahser]

@mmagician thanks for the clarificaitons, I'm happy to add my approval here. 👍

[laboon]

Approved, after additional discussion with @mmagician offline

[semuelle]

@mmagician, could you fill out the KYB form (assuming you are applying as a company, otherwise please use this form)?

[mmagician]

@semuelle Done, it's under review now

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section on our website for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Also, if you haven't yet, consider signing up for the Polkadot Alpha Program. The program offers plenty of resources for people building on Polkadot. Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀