← → Print all
01 — Proof system · Proof system

Spartan

Transparent SNARK for R1CS

In one paragraph

Spartan: Transparent SNARK for R1CS. Setup: None (commitment-dependent). Proof size: Depends on commitment. On-chain verification: Not a settlement candidate alone. PQ: Commitment-dependent. Recursion: Used inside larger systems. Maturity: Established construction, widely built upon. Prover cost profile: Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries. Peak prover memory: Low and streaming-friendly. Off-chain verifier: Sublinear after preprocessing; commitment-dependent. Implementations and maintainers: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus. Where it is measured: Only inside zkVM benchmarks. Choose it when: An intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.

By MarketComp Updated v1.3 About the authors Changelog
Setup
None (commitment-dependent)
Proof size
Depends on commitment
On-chain verification
Not a settlement candidate alone
PQ
Commitment-dependent
Recursion
Used inside larger systems
Maturity
Established construction, widely built upon
Selection matrix · as Spartan · see the row in context
Prover cost profile
Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries
Peak prover memory
Low and streaming-friendly
Off-chain verifier
Sublinear after preprocessing; commitment-dependent
Implementations and maintainers
Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus
Where it is measured
Only inside zkVM benchmarks
Prover profile · as Spartan · see the row in context

What it is

A transparent SNARK for R1CS built on sumcheck and a multilinear commitment, with sublinear verification after preprocessing and no FFTs. Its distinguishing property is that the commitment scheme is swappable.

Strengths and tradeoffs

Strengths
  • No trusted setup, and the commitment is swappable — so post-quantum posture becomes a separate, independent choice
  • No FFT in the prover; costs are linear in the number of constraint entries
  • The sumcheck structure has become the foundation for much newer work
Tradeoffs
  • Proof size and verifier cost are worse than pairing-based SNARKs; not an EVM settlement candidate alone
  • Concrete performance depends almost entirely on the chosen commitment, so 'Spartan is fast' is not a meaningful statement unqualified
  • The reference implementation is a research artefact rather than a maintained product

Choose it whenAn intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.

Maintained implementations

Srinath Setty (Microsoft Research, 2019). Implementations: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus

Maturity: Established construction, heavily built upon · License: n/a (construction) · eprint.iacr.org ↗

How to decide
Other proof systems in §01
Groth16PLONK and the PLONKish familyFRI-based STARKsHalo2 with IPA, and Halo2 with KZGNova, SuperNova and HyperNovaBinius and binary-field systemsSTIR and WHIRGKR-based systemsBulletproofsLookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist

Sources cited on this page · 1

  1. Spartan — efficient and general-purpose zkSNARKs without trusted setuppaper

All 40 sources for §01 are listed on the section page →

Cite this page 
MarketComp (2026). Spartan. The ZK Field Manual (Version 1.3). MarketComp. https://zkpick.com/proof-systems/spartan/
@misc{zkfieldmanual-spartan,
  title        = {Spartan — The ZK Field Manual},
  author       = {MarketComp},
  year         = {2026},
  version      = {1.3},
  howpublished = {\url{https://zkpick.com/proof-systems/spartan/}},
  note         = {Accessed: YYYY-MM-DD}
}