Grant Application: Formal Verification of Zcash's Halo 2 Proof System and Orchard Protocol in Lean 4

I’ve submitted a grant application to ZCG for formal verification of Zcash’s Halo 2 circuits and Orchard protocol using Lean 4.

GitHub Issue: Grant Application - Formal Verification of Halo 2 in Lean 4 · Issue #244 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

Summary: This proposal covers systematic formal verification of Orchard’s core circuit gadgets (Sinsemilla, Poseidon, ECC, MerklePath, LookupRangeCheck), protocol-level security analysis of ZIP 224, and forward-looking research on post-quantum migration and privacy extensions.

Amount: $201,600 over 18 months ($11,200/month)

Category: R&D

Full proposal details are in the GitHub issue linked above. I welcome community feedback and questions.

@ZcashGrants

9 Likes

As a developer building the Hera’s Ledger privacy protocol on Halo 2, I’m thrilled to see this initiative for formal verification. Our current focus is heavily centred on minimising arithmetic constraints, so having a verified foundation is of immense value to our architecture. Looking forward!

2 Likes

I started to look at formalizing one of the Halo 2 gadgets already. You can also view it here.

2 Likes

Just a heads-up that I have amended the original proposal to 1) take into account work already completed, and 2) tighten the scope/timeline. Please have another fresh look at your convenience.

1 Like

Hello, and thank you for the proposal. I have a few general questions I would like to raise.

I find it difficult to assess your background in this specific area, since I do not have direct experience working with cryptography of this level myself. These are complex matters, so the only things I can really rely on are the public discussion around the proposal and publicly available sources. I was able to find some of your academic work, but it appears to be focused mainly on applied mathematics in the medical domain, rather than cryptography or zero-knowledge proof systems. Could you say more about what drew you to Halo in particular, especially in the context of Zcash?

I would also appreciate some clarification on how you frame this work. Do you see it primarily as work intended to improve the Zcash protocol, or more as work aimed at advancing Halo-related cryptographic research more broadly? It would be very helpful if you could provide some concrete practical examples of how the results of this work could be used.

Finally, how much interaction with the Zcash protocol team do you expect this work would require? Would it depend on substantial involvement from them during the course of the project? This is an important question to me, because specialist time is limited, and I am reading broader signals from community leadership that Zcash may have a relatively narrow window of opportunity to realize its potential.

2 Likes

Hi artkor, thank you for the thoughtful questions. I am happy to address each.

1. Background and motivation

My PhD thesis is from 2010 and was indeed in applied mathematics (mathematical biology). That was 16 years ago. In the time since, my career has been in software engineering, with the last several years focused specifically on Rust in the blockchain space, and my very recent work involving cryptographic protocols and formal verification.

Some concrete recent work that is more relevant than the thesis:

  • I have been an active security researcher across ZK and DeFi protocols, including bounty programs on PancakeSwap, Euler, Hyperliquid, and LayerZero, with confirmed findings involving smart contract analysis and protocol-level reasoning.

  • I have contributed to GitHub - GaloisInc/cryptol: Cryptol: The Language of Cryptography · GitHub , Galois’s domain-specific language for cryptographic algorithm specification, including implementing a DIMACS SAT adapter and a :count command for model counting (sharpSAT integration). Cryptol is used by the NSA and DARPA for crypto specification work.

  • Most directly relevant: I have already completed the LookupRangeCheck formalization in Lean 4 ( GitHub - MavenRain/halo2-formal · GitHub ) before requesting any funding. This is 244 lines of Lean 4 with soundness and completeness proofs grounded in Mathlib, covering the running-sum range check, the short range check, and the no-wrap guarantee for the Pallas field. It demonstrates the exact methodology that carries through to the remaining gadgets.

What drew me to Halo 2 specifically: the Zcash Orchard circuit is one of the more consequential deployed ZK systems (it protects real user funds and privacy), it has mature public specifications (ZIP 224, the Orchard book, the Halo 2 book), and Nethermind’s Halva framework proved the viability of extracting Halo 2 constraints into Lean 4, including discovering a severe soundness bug in Scroll’s Keccak circuit using this approach. Zcash’s own gadgets have not received this treatment yet, and the methodology is a natural fit for my current interests and skills.

2. Project framing

This is Zcash-specific work, not general Halo research. Every deliverable targets Zcash’s actual deployed Orchard circuit.

Concretely:

  • Phase 1 produces Lean 4 proofs that Zcash’s five Orchard gadgets (Sinsemilla, Poseidon/Pow5, ECC, MerklePath, LookupRangeCheck) correctly enforce the intended computation. If a constraint in the production circuit is unsound, these proofs will surface it. Over 80% of findings in ZK audit reports trace back to the circuit layer, and manual audits cannot provide completeness guarantees.

  • Phase 2 lifts this to the protocol layer, proving that Orchard (ZIP 224) achieves spend authorization, balance, and Fiat-Shamir soundness when instantiated with the verified circuits.

Practical example: Nethermind used Halva (the same framework I build on) to discover that Scroll’s deployed Keccak-256 circuit had a soundness bug, meaning an attacker could have produced accepting proofs for incorrect hash outputs. This class of vulnerability is exactly what formal verification catches and manual audit misses. My work would provide that assurance for Zcash’s own circuits.

3. Protocol team interaction

Minimal. The core inputs to this work are all public:

  • The Halo 2 Rust crates (zcash/halo2, zcash/orchard) on GitHub

  • The Halo 2 book and Orchard book

  • ZIP 224 specification

  • Nethermind’s open-source Halva framework

I do not anticipate needing substantial protocol team involvement. The work is self-contained: read the public code and specs, extract constraints into Lean 4, prove properties. If ambiguities arise in the specification, I would ask targeted questions (in a forum post, for example), but nothing that would consume ongoing specialist time.

The proposal is also structured to protect against overcommitment: milestone-gated payments, a scope-down option (Phase 1 only at $67,200 over 4 months), and the fact that one gadget is already done before any funding has been requested.

I hope this helps. Let me know if you have any further questions!

2 Likes

artkor raises fair points about background. Formal verification of Halo 2 circuits carries real value if the team can demonstrate ZK-specific depth. The amended scope narrowing to Orchard circuit correctness and the open GitHub repo where progress is publicly trackable are the two strongest indicators so far.

Based on the Aborist call details, I support this grant. :student:

1 Like