Spartan: zkSNARKs in Rust with no trusted setup and no audit

What transparency buys, and what it costs

Spartan is a high-speed zero knowledge proof system, a cryptographic primitive that lets a prover convince a verifier of a mathematical statement without revealing anything besides the validity of that statement. The repository provides libspartan, a Rust library implementing a zkSNARK, a proof system with short proofs and fast verification times, and the design follows the paper published at CRYPTO 2020. The distinctive feature, and the one the README leads with, is transparency. Spartan does not require a trusted setup, it is a transparent zkSNARK, so there is no toxic waste, no trapdoor that must be kept secret, and no multi-party ceremony to produce public parameters. The security argument rests on a standard assumption, the hardness of computing discrete logarithms, in the random oracle model, and the library uses ristretto255, a prime order group abstraction on top of curve25519, with curve25519-dalek providing the arithmetic. The generality is the second feature, since Spartan produces proofs for arbitrary NP statements and libspartan supports them expressed as rank-1 constraint satisfiability instances, a language for which efficient transformations and compiler toolchains exist. Verification cost is the third, since Spartan is described as the first transparent proof system with sub-linear verification costs for arbitrary NP statements.

The performance table and the audit sentence

The Highlights section makes strong comparative claims, and they are the project's own. Among transparent SNARKs, Spartan is said to offer the fastest prover, with speedups of 36 to 152 times depending on the baseline, proofs that are shorter by a factor of 1.2 to 416, and the lowest verification times, with speedups of 3.6 to 1326 times. There is one admitted exception, proof sizes are smaller than Bulletproofs, but Bulletproofs in turn incurs slower verification both asymptotically and concretely. Against the state of the art zkSNARK with a trusted setup, the README says Spartan's prover is 2 times faster for arbitrary R1CS instances and 16 times faster for data parallel workloads. Every one of those figures is a comparison against a baseline the README chooses, so they are best read as the authors' summary rather than as a settled ranking. Far more important for an adopter is the line that appears in the README's introduction: this library has not received a security review or audit. For a proof system that other people's systems will depend on for correctness, that sentence is the single most consequential fact in the repository, and the sentence is stated plainly rather than buried.

The API in four calls

The shape of the library is small enough to read in one sitting. You size an R1CS instance, you generate the public parameters with SNARKGens::new, you obtain an instance, either synthetic or your own, you commit to it with SNARK::encode, which returns a commitment and its decommitment, you prove with SNARK::prove, and you check with proof.verify. The crate comment says the public API style is inspired by the underlying crates it uses, and the transcript handling shows it clearly, since the prover and the verifier each build their own Transcript with the same label, snark_example, and verification succeeds only if the two transcripts agree:

extern crate libspartan;
extern crate merlin;
use libspartan::{Instance, SNARKGens, SNARK};
use merlin::Transcript;
fn main() {
    // specify the size of an R1CS instance
    let num_vars = 1024;
    let num_cons = 1024;
    let num_inputs = 10;
    let num_non_zero_entries = 1024;

The remaining calls are produce_synthetic_r1cs, SNARKGens::new, SNARK::encode, SNARK::prove and proof.verify, and the same transcript discipline applies to the verifier. A dependency line in Cargo.toml is all the installation this needs:

spartan = "0.8.0"

The NIZK variant and hand built instances

Two variants ship in the same library, and the difference is what the verifier learns. The NIZK form, the non-interactive zero knowledge variant, uses NIZKGens instead of SNARKGens and NIZK::prove instead of SNARK::prove, and it keeps the instance itself, since the verifier needs it to check the proof, rather than working from a commitment. The third program in the README goes further and drops the synthetic instance altogether, producing a tiny instance by hand, with the R1CS structure and the assignment of variables and inputs built explicitly through VarsAssignment and InputsAssignment, and the curve25519-dalek Scalar type pulled in directly for the witness values. The repository also ships a worked program at examples/cubic.rs, and the interesting part of the hand built path is that it shows where the boundary of the library sits, the R1CS encoding is yours, and libspartan proves satisfiability of whatever you hand it.

Fiat-Shamir, transcripts and the RandomTape

The implementation details section explains two things. First, libspartan uses merlin to automate the Fiat-Shamir transform, which is the technique that turns an interactive proof into a non-interactive one by deriving the verifier's challenges from the prover's commitments. Second, the project introduces a type called RandomTape, which extends a Transcript in merlin to allow the prover's internal methods to produce private randomness using its private transcript, without having to create OsRng objects throughout the code. That is a design decision with a security dimension, because the randomness a proof depends on is tied to the transcript that is already secret, and an object of type RandomTape is initialised with a new random seed from OsRng for each proof the library produces. The dependency list backs this up, with rand and rand_core present for that seeding, subtle for constant time comparison, and byteorder and sha3 for the encoding work, plus flate2 and bincode for serialisation.

Crates, binaries, benches and wasm

The manifest describes more than a library. The package is named spartan with the library target renamed to libspartan, the edition is 2021, the documentation points at docs.rs, and the licence is declared as a licence file. Two binaries, snark and nizk, live under the profiler directory and require the std feature, and two criterion benchmarks share those names with the same feature requirement, so the performance claims in the README can be reproduced from the repository. The dependency set is deliberately narrow, with curve25519-dalek at 4.1.1 with the serde, alloc and rand_core features, merlin at 3.0.0, rand and rand_core, digest and sha3 for hashing, byteorder, serde with derive, bincode, subtle, itertools and flate2. Two optional pieces stand out, rayon for parallel proving and colored for the profiler output, and there is a wasm32 target section that pulls getrandom with its js feature so the library can be built for the browser. A typos tool sits in the dev dependencies, which is a small sign of how the project treats its own documentation.

Version drift and the state of the repository

Two numbers in this repository do not agree, and anyone who follows the README will notice. The dependency line the README gives you is spartan = "0.8.0", while the manifest declares version 0.9.0. The tagged releases are older still, with v0.4.1 and v0.4.0 both dated 2021-10-14, the first supporting the latest Rust with the corrected version number in the documentation, and v0.3.0 from 2021-04-22, which added support for padding instances so arbitrary sized R1CS instances work. So the crate you get from the registry, the version in the tree and the version in the documentation are three different things, and the release history has not been updated in years. The branch itself is not idle, since the last push was on 2026-09-22 and the repository is not archived. The licence is MIT, with a NOTICE.md file, and the repository carries a SECURITY.md file, a code of conduct, a contributing guide, a rustfmt.toml configuration, a .cargo directory, a benches directory and an examples directory, which is a complete project skeleton for something that is still, by its own admission, unreviewed.

Editorial conclusion

Spartan fits a researcher or engineer who needs a zero knowledge proof system they can read, fork and audit themselves, and who specifically wants to avoid a trusted setup ceremony and the secret it leaves behind. It is the wrong choice for anything that needs an audited or standardised proof system today, since the README states plainly that the library has not received a security review or an audit, and it is a poor fit if you need a proof system with an existing ecosystem of tooling, since Spartan is a research implementation rather than a deployed stack. Before you build on it, pin the version you actually get, because the README's dependency line and the manifest version do not match, and read the CRYPTO 2020 paper so you understand the protocol you are depending on rather than only its API.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/Spartan on GitHub
4. README
5. Releases