Zero-knowledge proofs and the audit that needs to see the data

The property that makes zero-knowledge valuable for privacy is the property that makes it unsuitable as an enterprise audit record: it deliberately does not say what happened, only that a rule was satisfied.

Part of Receipt cryptography and standards

What a proof establishes

That some witness exists satisfying a defined circuit, without revealing the witness. Verification confirms the constraint held.

# What a proof can establish
  "An approver with authority above the threshold approved
   a payment under the applicable limit."

# What an auditor asks
  "Who approved it? How much? To whom? At which account?
   What were they shown? Show me."

# The proof deliberately does not contain any of that.

The three audiences

The bottom two rows are real and valuable. The top three are where enterprise approval records live, and they want the opposite property.

The explainability problem

Beyond the content question there is a practical one. A signature verification is explainable to a judge or an examiner in two sentences: this public key belongs to that person, and only the matching private key could have produced this signature.

A zero-knowledge proof requires explaining the circuit, what it constrains, the setup assumptions, and why the implementation is faithful to the intended statement. Each of those is a place for a competent opposing expert to introduce doubt.

• Was the circuit correct — does it constrain what it claims to?
• If the system requires trusted setup, who participated and what if they colluded?
• Was the proving library free of defects at the version used?
• Can the verification be reproduced years later with the same parameters?

None of these is unanswerable. All of them take an expert witness and a day of testimony, which is a cost the signature approach does not incur.

Where the two combine well

The productive pattern keeps them in separate roles rather than choosing.

# Identity layer  — privacy matters
  proof: "this person is an authorised approver at tier 3"
  → the counterparty learns the authority, not the identity

# Record layer   — auditability matters
  signed statement: full payee, amount, account, approver
  → retained internally, disclosed to auditors and courts

# Different parties see different things, and the record
# that must be produced in litigation contains the facts.

This is close to how the paper world worked. A counterparty sees a signature block; the internal file contains the full authorisation.

Being fair about the criticism

This argument is about a specific application, not about the technology. Zero-knowledge proofs are an important construction with real deployments doing things nothing else can do.

The error is a category one, and it is usually made by people who understand the cryptography and have not sat through an audit. The requirement for an approval record is disclosure, not privacy, and a tool optimised for the opposite is the wrong tool however elegant it is.

A test worth applying

Before choosing a privacy-preserving construction for a record, ask one question: who will need to read this, and what will they need to see?

If the answer includes a regulator, an auditor, an insurer or a court, the record needs to contain the facts. If the answer is a counterparty who needs only to know a condition holds, a proof is exactly right.

The explainability cost

Each item in the right-hand cell is a place a competent opposing expert can introduce doubt. None is unanswerable; all of them cost an expert witness and a day of testimony that the signature approach does not.

Objections and honest limits

“This dismisses a valuable technology.” It does not. Proofs are the right tool for identity and eligibility, where a counterparty needs to know a condition holds without learning the data. The error is a category one.

“Both could be used.” They should be, in separate roles: a proof at the identity layer where privacy matters, a signed statement at the record layer where disclosure is required. That is close to how the paper world worked.

A test before choosing a construction

1. Who will need to read this record? Name them.
2. What will they need to see? Facts, or a satisfied condition?
3. Does the list include a regulator, auditor or court? Then the record needs the facts.
4. Is the counterparty only checking a condition? Then a proof is exactly right.

Terms used here

Zero-knowledge proof

A proof that a statement is true without revealing why it is true.

Trusted setup

A parameter generation ceremony some proof systems require, and an assumption an opposing expert will examine.

Circuit

The encoded constraint a proof demonstrates satisfaction of — whose correctness is a separate question from the proof's validity.

Frequently asked questions

Are zero-knowledge proofs useless for enterprises? No. They are well suited to identity and eligibility, where a counterparty needs to know a condition holds without learning the underlying data.

Why are they wrong for approval records? Audit, regulation and litigation need the payee, the amount and the approver. A proof deliberately omits exactly that.

What is the explainability problem? A signature is explainable in two sentences. A proof requires explaining the circuit, setup assumptions and implementation fidelity — each an opening for doubt.

Can both be used? Yes, in separate roles. A proof at the identity layer where privacy matters, a signed statement at the record layer where disclosure is required.

Can both be used together? Yes, in separate roles: a proof at the identity layer, a signed statement at the record layer where disclosure is required.

Sources and further reading

• Published literature on zero-knowledge proof systems and their assumptions.
• Federal Rules of Evidence on authentication and expert testimony.
• W3C Verifiable Credentials Data Model 2.0
• Audit standards on evidence sufficiency and appropriateness.
• Federal Rule of Evidence 902 — self-authentication