🔎 Reports: summary · individual zkVMs

A universal soundness calculator across hash-based zkEVM proof systems and security regimes.

It aims to answer questions like:

• "What if OpenVM moves from Babybear⁴ to Goldilocks³?"
• "What if ZisK moves from the Johnson Bound Regime to the Unique Decoding Regime?"

You can run the calculator by doing python3 -m soundcalc. As a result, the calculator generates / updates reports in reports/.

Tests can be run with pytest.

We currently support the following zkEVMs:

• ZisK
• Pico
• OpenVM
• Airbender

We support the following polynomial commitment schemes:

• FRI
• WHIR

We support the following security regimes (see below for explanation of regimes):

• Unique Decoding Regime (UDR)
• Johnson Bound Regime (JBR)

We support the following lookup protocols:

• LogUp

Consider a fixed set of parameters describing the prover and verifier of a FRI-based zkEVM. To evaluate the concrete soundness level of such a system, we introduce a parameter θ in the range (0, 1).

The soundness level is then determined as a function of θ and the zkEVM parameters (e.g., field size, code rate). Depending on the value of θ, the analysis falls into different regimes:

• UDR (Unique Decoding Regime): $\theta \leq (1 - \rho)/2$, where $\rho$ is the code rate.
• JBR (Johnson Bound Regime): $(1 - \rho)/2 < \theta < 1 - \sqrt{\rho}$.

Crucially, θ is not an input to the prover or verifier code—it is only used in the soundness analysis. All regimes therefore apply to the same zkEVM instance without any change.

The soundcalc proof size estimate is based on counting Merkle proofs and their sizes. It is only an estimate and should be treated as such. To get the actual proof size you need to run the actual prover.

Reports show two estimates:

• Expected: Accounts for Merkle path sharing when random queries overlap in the tree (path pruning optimization)
• Worst case: Assumes no overlap: each query contributes a full independent path.

In practice, actual proof sizes tend to be closer to the expected estimate.

At the moment, soundcalc estimates the security level of the interactive oracle proof (IOP) underlying hash-based zkEVM proof systems, for the notion of round-by-round soundness. That is, security levels are shown for each round, and the total security level is the minimum of all these levels.

For an explanation why the minimum of these levels also corresponds (roughly) to the security level of the non-interactive construction obtained via the BCS transform, we refer to the section on round-by-round soundness here.

Note that this correspondence holds for classical adversaries, but is different for quantum adversaries in the quantum random oracle model, and we refer to this work for details.

We may integrate the compilation to the non-interactive setting (classically and/or quantumly) in the future.

A flurry of new results on proximity gaps were published in November 2025 (see Nico's summary).

In soundcalc we have incorporated:

• The improved JBR security bounds of BCHKS25
• The removal of the CBR regime, following the results of DG25 and CS25

• soundcalc/main.py: Entry point
• soundcalc/zkvms/: One directory per supported zkVM
• soundcalc/proxgaps/: Proximity gaps related functionality
• soundcalc/pcs/: Polynomial commitment schemes functionality
• soundcalc/common/: Common utilities used by the entire codebase
• soundcalc/report.py: Markdown report generator (ugly!)

Inspiration:

• RISC0 Rust calculator
• stir-whir-scripts
• Winterfell calculator
• xkcd

Based on papers (links point to specific versions where possible):

• BCIKS20
• ethSTARK
• Ha22
• BCHKS25
• eSTARK
• RISC0