---
title: "Cryptographic review of the protocol and proof system"
description: "Cryptographic review of the protocol and proof system: Cryptography review. Layer: Proof system."
type: "option"
url: "https://zkpick.com/audit/cryptographic-review/"
section: "03 Auditing a ZK protocol"
authors:
  - "MarketComp"
publisher: "MarketComp"
version: "1.3"
updated: "2026-09-12"
license: "CC-BY-4.0"
json: "https://zkpick.com/data/audit/cryptographic-review.json"
---

*By MarketComp. Updated 2026-09-12. Version 1.3. CC BY 4.0.*

# Cryptographic review of the protocol and proof system — *Cryptography review*

> Cryptographic review of the protocol and proof system: Cryptography review. Layer: Proof system. Characteristic finds: Weak Fiat–Shamir, unsound composition and recursion boundaries, wrong concrete security parameters. Blind to: Implementation defects in the circuit above it; deployment and integration issues. Coverage claim: None — argument-based. Cost profile: High; cryptographers, not circuit engineers. Choose it when: Mandatory if you implement, modify or newly compose a proof system, add recursion or aggregation, change the transcript, or pick non-standard parameters. Reducible — not eliminable — if you use a mainstream library unmodified at a pinned, audited version.

Review of the argument system itself and everything below the arithmetisation: the soundness argument and its assumptions, what the Fiat–Shamir transcript absorbs, commitment instantiation, hash and sponge parameterisation, curve and subgroup structure, recursion composition, and the concrete bit-security the chosen parameters actually imply. This layer produces the highest-impact failures because they are construction-wide rather than deployment-specific.

**Strengths**

- The only layer that can catch construction-level soundness breaks
- Findings are reusable across the ecosystem and often warrant CVEs and coordinated disclosure
- Supported by shared artefacts: the ZKProof Community Reference, ZKDocs, soundness calculators

**Tradeoffs**

- Requires cryptographers rather than circuit engineers — a different and scarcer skill set
- Hardest layer to scope and schedule; results are not predictable per reviewer-week
- Frequently skipped because the upstream library is assumed 'already audited' — which is how weak Fiat–Shamir spread across many implementations
- Concrete-security arguments for newer hash-based systems still rest on unproven assumptions

**Choose it when:** Mandatory if you implement, modify or newly compose a proof system, add recursion or aggregation, change the transcript, or pick non-standard parameters. Reducible — not eliminable — if you use a mainstream library unmodified at a pinned, audited version.

Maturity: Established discipline · License: Service · Source: https://eprint.iacr.org/2023/691

**In the what each assurance technique can and cannot find** (https://zkpick.com/audit/#audit-matrix-cryptographic-protocol-review)

| Technique | Layer | Characteristic finds | Blind to | Coverage claim | Cost profile |
| --- | --- | --- | --- | --- | --- |
| Cryptographic protocol review | Proof system | Weak Fiat–Shamir, unsound composition and recursion boundaries, wrong concrete security parameters | Implementation defects in the circuit above it; deployment and integration issues | None — argument-based | High; cryptographers, not circuit engineers |