# EVM-Verifiable Post-Quantum Client-Side SNARK
*Status: preliminary proof size results and client-side benchmark results; gas benchmarking in progress.*
## Abstract
*This note summarizes the current status of an EVM-verifiable post-quantum client-side SNARK project.*
*In gas benchmarks against the state-of-the-art (SotA) baseline (previous WHIR Solidity verifier[^solwhir]), our implementation of WHIR verifier over KoalaBear field consumes 53% less calldata gas, it still consumes 3% more total transaction gas compared to baseline due to extension field arithmetic.*
*A second result is that our general direction appears feasible for client-side proving. Our current prover time and RAM benchmarks indicate that the candidate systems fit within the intended client-side setting.*
[^ourcode]: https://github.com/alxkzmn/spartan-whir-dev
## 1. Goal
The goal is a SNARK with the following properties:
* **post-quantum soundness**,
* **direct EVM verification**,
* **transparent setup**,
* **client-side feasible proving**.
## 2. Why this direction is justified
The SotA Solidity WHIR verifier (`sol-whir`)[^solwhir] is the strongest reference point we are aware of for direct on-chain verification of a post-quantum SNARK. Some of our measurements (e.g., tx calldata size and proof size) already improve on that baseline.
In particular, **Spartan-WHIR**[^ourcode] gives a total proof of **13,995 bytes**, while the public baseline reports **30,724 bytes** for the WHIR proof alone. The other tested WHIR-based candidates - Hyperplonk-WHIR[^hp] and Whirlaway[^waway] also reduce the WHIR proof size relative to the same baseline.
[^hp]: https://github.com/alxkzmn/csp-benchmarks/tree/the-definitive-csp/hyperplonk
[^waway]: https://github.com/alxkzmn/csp-benchmarks/tree/the-definitive-csp/whirlaway
The SotA WHIR verifier demonstrated 1.9 MGas[^solwhir] verification cost under 100 bits of security for a 2^22 size polynomial and 1.1 MGas[^solwhir] for a 2^16 size polynomial under 80 bits of security. We expect our resulting SNARK to verify 2^22-sized circuits under 1 MGas under 100-bit security.
See the table below for comparison of the SotA on-chain verification costs.
|ZKP system|Verification gas cost|
|-|-|
|Groth16|348K[^bbgas]|
|***Our Target***|***<1M***|
|***sol-whir***|***1.9M***[^solwhir]|
|Barretenberg|2.4M[^bbgas]|
## 3. Proof size benchmark
To assess the on-chain verifier feasibility we have conducted the proof size benchmarks with the following parameters (matching the baseline system parameters):
* polynomial degree k = 18,
* security bits = 80,
* soundness = CapacityBound,
* pow_bits = 30,
* folding_factor = 4,
* starting_log_inv_rate = 6,
* rs_domain_initial_reduction_factor = 1 where available,
* KoalaBear field with quartic extension for the Plonky3-based systems.
| System | WHIR proof (bytes) | PIOP proof (bytes) | Total proof (bytes) | Prime Field |
| ----------------- | ------------------:| ------------------:| -------------------:| --- |
| **WHIR baseline**[^solwhir] | **30724** | - | **30724** | Bn254 |
| **Spartan-WHIR**[^ourcode] | **11368** | 2627 | **13995** | KoalaBear |
| Whirlaway[^waway] | 19735 | 94728 | 114463 | KoalaBear |
| HyperPlonk[^hp] | 19509 | 125224 | 144789 | KoalaBear |
Observations:
* Spartan-WHIR has the smallest total proof size among the systems evaluated.
* All three candidate systems produce a smaller WHIR proof than the baseline.
* Spartan-WHIR’s full proof is smaller than the baseline WHIR PCS proof alone.
## 4. Verifier gas benchmarks
The Solidity verifier for whir-p3 has been implemented here:
https://github.com/alxkzmn/sol-spartan-whir/tree/stage4.
Below are comparative benchmark results for verification transaction gas.
| Measurement | Spartan-WHIR | **WHIR baseline**[^solwhir] |
| ------------------------ | --------------------------- | ------------------- |
| **Total tx gas** | **1,172,266** | **1,135,052** |
| Intrinsic + calldata | 234,060 | 435,876 |
| Execution | 938,206 | 699,176 |
| Wrapper overhead | 39,674 | 22,165 |
:::warning
The use of small field allows for saving the gas cost of the transaction calldata but incurs a higher computational gas overhead due to the extension field arithmetic.
:::
## 5. Client-side feasibility
The tested SNARKs are feasible for client-side proving.


*The figures show benchmark results of Hyperplobk and Whirlaway with 100 and 128 bits of security against the baseline of ProveKit*
*[TODO add Spartan-WHIR CSP benchmarks]*
Our current prover time and RAM benchmarks indicate that the candidate systems fit within the intended client-side setting. In this project, the feasibility cutoff for prover RAM is 4 GB, motivated by our prior survey of mobile hardware[^hwsurvey].
At this stage, the client-side prover speed is not the main goal. However, we use ProveKit as our baseline for performance as it is one of the most production-ready client-side WHIR-based ZK-SNARKs with satisfactory performance[^cspbenches].
WHIR PCS parameters allow fine-tuning of proving speed versus proof size. Since reducing proof size is our priority, we may end up with a SNARK whose proving speed could be worse than the current popular client-side systems[^cspbenches]. In that case we consider applying mobile GPU acceleration to the most demanding cryptographic primitives of our prover such as NTT *[TODO add more info on GPU acceleration]*.
[^cspbenches]: https://ethproofs.org/csp-benchmarks
[^hwsurvey]: https://hackmd.io/@clientsideproving/AvgMobileHardware
## 6. Next steps
- Implementing full Spartan-WHIR verifier (April)
## 7. Future plans
- Mobile GPU acceleration
- Adding ZK:
- https://eprint.iacr.org/2026/391
- https://eprint.iacr.org/2026/683
- Adding frontend (Spartan is using R1CS arithmetization so a modified Circom with 31-bit field support may be a natural choice)
## Appendix A: Design Choices
This section explains the choice of cryptographic primitives for our SNARK.
### A.1 WHIR for the PCS
The SotA baseline[^solwhir] already shows that WHIR can support direct EVM verification, and this result has not yet been contested for a post-quantum ZK scheme. WHIR is a hash-based PCS that does not require a setup (is transparent). Therefore, WHIR enables three of the four desired properties of our SNARK, namely PQ-soundness, transparency and on-chain verifiability.
[^solwhir]: https://ethresear.ch/t/on-the-gas-efficiency-of-the-whir-polynomial-commitment-scheme/21301
### A.2 Spartan for the PIOP
In the current measurements, **Spartan-WHIR** has by far the smallest non-PCS contribution among the tested systems:
* **Spartan-WHIR PIOP proof:** **2627 bytes**
* **Whirlaway PIOP proof:** **94728 bytes**
* **HyperPlonk PIOP proof:** **125224 bytes**
Besides that, Spartan-based SNARKs are know to have strong client-side performance (second-best[^cspbenches] for heavy workloads) while having a modest RAM footprint. Therefore, Spartan enables the remaining desired property of client-side feasibility.
### A.3 Small prime field
A small field is attractive for multiple reasons:
- smaller field elements reduce proof size and therefore reduce the calldata size;
- small-field arithmetic is a natural fit for efficient prover implementations because it's well-suited to CPU optimizations like SIMD and may also create room for batching tricks on the EVM side when multiple small-field elements can be packed into a 256-bit word before reduction;
- small fields are better suited for arithmetization of many kinds of circuits that don't require big values (and this is one of the reasons why the industry is gravitating towards them).
We use a WHIR implementation[^whirp3] based on Plonky3 library offering a wide variety of efficient 31-bit fields (KoalaBear/BabyBear/Mersenne31). As we can see from the proof size benchmarks, KoalaBear field enables a [much smaller proof size](#31-Proof-size-benchmark-results) compared to Bn254 in the WHIR baseline.
[^whirp3]: https://github.com/tcoratger/whir-p3/
## Appendix B: Living research document
A more detailed writeup can be found here: https://hackmd.io/@clientsideproving/whir-based
[^bbgas]: https://blog.base.dev/benchmarking-zkp-systems