# Nova turns a folding scheme into a recursive SNARK library in Rust

> Nova is Microsoft's Rust implementation of a recursive SNARK built on folding schemes, with three curve cycles, three commitment schemes and optional proof compression through Spartan. It is a research library with a small API surface, and the documentation is written for people who already know the paper.

**microsoft/Nova** — Nova: High-speed recursive zero-knowledge arguments from folding schemes

- Repository: https://github.com/microsoft/Nova
- Stars: 866 · Forks: 254
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-nova

## What a recursive SNARK is supposed to solve

Nova is a library implementing Nova, a recursive SNARK, which the README defines as a cryptographic proof system where a prover proves a mathematical statement to a verifier with a short proof and succinct verification. The recursion is what makes it interesting: a recursive SNARK lets a prover produce proofs about prior proofs.

The concrete primitive underneath is incrementally verifiable computation. The prover takes a proof of the first i steps of a computation and updates it into a proof of the first i plus one steps. Two properties matter for cost, and the README states both plainly. The work the prover does to update the proof does not depend on how many steps have already been executed, and the work the verifier does does not grow with the number of steps.

That is the shape you need for a long running sequential computation, and the README lists the applications it enables: rollups, verifiable delay functions, succinct blockchains, incrementally verifiable versions of verifiable state machines, and proofs of machine executions such as EVM or RISC-V. The audience is protocol engineers, not application developers.

## Folding is what makes the verifier circuit small

The construction rests on a folding scheme, which the README describes as a primitive that reduces checking two NP statements into checking a single one. That reduction is the mechanism behind the headline numbers the project states about itself: that Nova is the simplest recursive proof system in the literature while providing the fastest prover, and that it achieves the smallest verifier circuit, which is constant sized and about 10,000 multiplication gates.

A constant sized verifier circuit is the property that makes recursive verification affordable at all. If the circuit grew with the step function, then folding another layer into the proof would cost more every time. Keeping it flat is what lets a long computation be verified in roughly constant work.

Zero knowledge is a separate ingredient. Before compression, the IVC proof is folded with a random instance, which is what makes the proof zero knowledge, and the README points at the HyperNova paper for the technique. The security argument itself is split across two papers, the CRYPTO 2022 paper on Nova as a recursive argument from folding schemes, and a later IACR ePrint on instantiating Nova over a cycle of curves.

## Three curve cycles and three commitment schemes

The library is published as nova-snark and works over a cycle of elliptic curves. Three cycles are supported: Pallas with Vesta, BN254 with Grumpkin, and secp with secq.

On top of that, three commitment schemes and their evaluation arguments are implemented. Pedersen commitments with an IPA based evaluation argument work on all three curve cycles, so that is the portable choice. HyperKZG works on curves with pairings, for example BN254, and Mercury is also pairing based and is described as an optimized variant that verifies faster than HyperKZG. The README points at the test test_ivc_nontrivial_with_compression for details on using the two pairing based schemes.

Both HyperKZG and Mercury require a universal setup, the so called powers of tau, and loading those parameters is what the default io feature is for. The example files include ptau_test_setup.rs and ppot_prune.rs, which is where to look if setup parameters are the part of the integration you do not yet understand.

## Building the crate and running the minroot example

The crate is a normal Cargo package, so building it is a cargo command. The README shows the default build, which includes the io feature:

```bash
# Default features (includes io)
cargo build

# With EVM verifier support
cargo build --features evm

# With experimental NeutronNova
cargo build --features experimental
```

The Cargo manifest names the package nova-snark at version 0.76.0, with edition 2021 and rust-version 1.88.0, so the toolchain floor is recent.

Tests are run in release mode, which the README recommends because it shortens run times considerably:

```bash
cargo test --release
```

and the minroot example is the quickest way to see the library do something:

```bash
cargo run --release --example minroot
```

One build detail is worth knowing before you start. The manifest enables the asm feature of halo2curves on x86_64, which the README says boosts performance by up to 50 percent, and the feature is switched off on other architectures. If the library fails to build or run, the documented fallback is to pass --no-default-features to the cargo commands.

## Compression turns an IVC proof into a SNARK proof

Nova by itself produces an incrementally verifiable proof, which is not yet a compact SNARK. The library implements a SNARK based on Spartan to compress those IVC proofs. There are two variants. One does no preprocessing at all. The other preprocesses circuits so that the verifier run time does not depend on the size of the step circuit, and that preprocessing variant is called MicroSpartan, described in the MicroNova paper.

The open source components of MicroNova referenced in the README include the HyperKZG polynomial commitment scheme and the MicroSpartan SNARK, with the latter provided in ppsnark.rs in the repository.

The preprocessing variant is the interesting engineering trade here. Preprocessing costs something up front, in exchange for a verifier whose cost does not scale with the step circuit, which is exactly the property you want when the circuit is large. The uncompressed variant is simpler to deploy and does not need that setup.

Compression also is where the setup requirement bites. HyperKZG and Mercury both need powers of tau, so choosing a pairing based scheme adds a setup ceremony to your deployment that the Pedersen and IPA path does not have.

## Front ends are the least documented part of the project

A front end is defined in the README as a tool that takes a high level program and turns it into an intermediate representation, such as a circuit, that can be used to prove executions on concrete inputs. Two ways of writing provable programs are described.

The native path uses the native APIs of Nova, which accept circuits expressed with bellman style circuits. The README points at examples/minroot.rs and at benches/sha256.rs for that style. Other examples in the repository include and.rs, hashchain.rs, ptau_test_setup.rs and ppot_prune.rs.

The second path is Circom, a DSL and compiler for turning high level programs into circuits. Middleware exists to turn Circom output into a form suitable for proving with Nova, namely Nova Scotia and Circom Scotia, both separate projects. The README is candid about the state of this: it says that examples using these tools with Nova will be added to the repository in the future.

That admission matters for anyone whose code is already in Circom. The interoperability story exists but is not yet exercised inside this repository, so you are committing to a middleware you would have to read separately.

## Cargo features that gate riskier features

The feature table is short and each entry has a clear purpose. io is on by default and enables loading commitment keys from powers of tau files. evm enables EVM friendly serialization. experimental enables experimental features such as NeutronNova. test-utils enables insecure test utilities including random tau generation, and the table marks that one as not for production.

That last entry is the one to internalise. Random tau generation produces setup parameters that are not secure, which is fine for a test suite and catastrophic in a deployment, so it is good practice that it sits behind a feature flag rather than being a default.

The manifest also shows how the implementation is put together at the dependency level. halo2curves provides the curve arithmetic, blitzar is present as an optional dependency, and ff, subtle, num-bigint and rand_chacha handle field arithmetic, constant time operations, big integers and randomness. Rayon is in the dependency list, which is how the field arithmetic work is spread across cores.

On licensing, the repository carries an MIT licence and the manifest points at a LICENSE file. The cryptography itself was published at CRYPTO 2022 and the curve instantiation as an IACR ePrint, so if you need the security argument rather than the code, those papers are where it lives.

## An MIT licensed crate with no published releases

The repository is not archived and the last push was on 2026-09-18, so the code is still moving. There is a version in Cargo.toml, 0.76.0, which is where a Cargo dependency resolves to. The repository has no GitHub releases, so there is no changelog with release notes and no tagged binaries to point at.

The practical consequence is that Cargo treats this as a moving target when you depend on it from a git reference rather than the published crate, and that upgrading means reading diffs rather than release notes. The repository does carry SECURITY.md and SUPPORT.md at the root, which are the places to look for how to report a problem and where to ask for help.

The other limitation worth naming is the documentation itself. The README is written for someone who already understands folding schemes, universal setups and the difference between an IVC proof and a SNARK proof. There is no tutorial, no API reference beyond the crate docs at docs.rs, and the two front end paths are described in a handful of sentences each. Adopting Nova means reading the two papers alongside the source.

## Conclusion

Nova suits engineers building rollups, verifiable delay functions or proof of EVM execution who want a recursive proof system they can read end to end and adapt, and the crate builds with a single cargo command. It is the wrong choice for anyone who needs a documented, stable public API, because the crate version moves and the README is written in the vocabulary of the underlying papers rather than as user documentation. Before depending on it, run cargo test --release and cargo run --release --example minroot, read the Universal Setup section before choosing HyperKZG or Mercury, and confirm that your prover chain matches the step circuit shape the library expects.

## FAQ

### What is the crate name for the Nova proof system?

The repository provides nova-snark, a Rust library implementation of Nova over a cycle of elliptic curves. The Cargo manifest lists version 0.76.0 with rust-version 1.88.0 and edition 2021.

### Which curves does Nova support?

Three curve cycles are supported: Pallas with Vesta, BN254 with Grumpkin, and secp with secq. Pedersen commitments with IPA based evaluation arguments work on all three, while HyperKZG and Mercury require curves with pairings.

### Does Nova need a trusted setup?

HyperKZG and Mercury require a universal setup, the so called powers of tau, and the default io feature exists to load commitment keys from those files. The Pedersen and IPA based path works without a pairing setup.

## Sources

- [Issues](https://github.com/microsoft/Nova/issues)
- [License: MIT](https://github.com/microsoft/Nova/blob/main/LICENSE)
- [microsoft/Nova on GitHub](https://github.com/microsoft/Nova)
- [README](https://github.com/microsoft/Nova/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-nova