What ZK trade proofs can—and cannot—prove

The proof has a statement

A zero-knowledge system can prove that private inputs satisfy a public computation. For trading, a circuit might check that an execution record came from an approved venue, used an approved asset, stayed inside a size limit or reconciled with a defined accounting rule. The exact circuit—not the word “ZK”—defines the claim.

What a well-scoped proof may establish

A committed record satisfies the encoded circuit constraints
A trade used an allowed asset, venue or function
A value stayed within a predefined range
Inputs and outputs reconcile under a defined accounting rule
The verifier accepted the proof for a specific circuit and public input

What it does not establish by itself

The strategy will be profitable
The underlying market data was complete, unbiased or timely
The approved venue is solvent or safe
The private strategy is sensible
Every relevant action was included in the proved dataset
The smart contracts, adapters or surrounding application have no vulnerabilities
The result is suitable for a particular user

Verified claim = circuit + committed inputs + public inputs + verifier result

One small statement, with an explicit boundary

Suppose a policy limits one recorded quantity to 100 whole units. A narrowly defined statement is: “I know a quantity q and blinding input r that open commitment C, and q is an integer between 0 and M, where the public maximum M is 100.” This is a scope worksheet, not an implemented circuit, generated proof or audit. It deliberately does not say that an exchange executed the recorded quantity.

Part	Definition in this worksheet	What implementation must settle
Public inputs	Maximum M = 100 units; commitment C; statement/version identifier	The verifier must use the intended public inputs and verification key.
Private witness	Quantity q and blinding input r	Use a reviewed binding and hiding commitment construction and its required randomness; a bare hash of a small quantity is not a substitute.
Range constraint	q and M are unsigned 32-bit integers, with q ≤ M	Constrain integer ranges; a field element is not automatically an ordinary bounded integer.
Binding constraint	C opens to this q and r under the specified encoding and statement domain	Specify the primitive, encoding and domain separation. Do not prove the range of an unrelated value.
Record provenance	Not supplied	A commitment to a prover's own input does not authenticate a venue, timestamp or fill.

With q = 75 and a matching commitment, the arithmetic condition is satisfied. With q = 125, it is not. With q = 75 but no authenticated trade record, the condition can still be satisfied without establishing that any trade happened. These are logical cases, not verification results from software run for this article. A zero quantity also satisfies this particular policy; exclude it explicitly if the intended claim requires positive execution.

What a real verification path must include

Publish the actual circuit and version, the commitment construction, the public-input encoding, the proving backend and verification key. Then generate and verify a proof for the intended statement, and test rejected cases, including a changed public maximum or commitment. Running an ordinary comparison in application code is not that verification step. Noir's public/private input documentation explains which values are exposed, while its assertion documentation explains how predicates become constraints. Its proving and verification walkthrough separates witness execution from proof generation and verification. Those steps do not authenticate the source of a trading record.

To claim a venue execution, a separate authenticated record and constraints binding that record to the proved quantity are needed. Even then, one record does not establish completeness of an account. That is why account valuation and coverage remain separate questions, as do the permissions of an agent and the evidence behind a return figure.

The coverage question

A valid proof can still cover an incomplete claim. Readers need to know which trades, venues, periods, accounts and accounting events enter the proof system. Coverage should be distinguished from validity: validity asks whether the proof verifies; coverage asks whether the proved claim represents the thing a user believes it represents.

Five questions for a proof-backed product

What exact public statement does the circuit verify?
Who produces and commits the underlying records?
What data or activity lies outside the proof boundary?
Which circuit version and verification contract are active?
Can an external user reproduce the verification path?

How to read a “verified” claim

“Verified” is not enough on its own. Look for the circuit, verifier, coverage documentation and audit evidence behind the exact public statement. If those materials are unavailable, the claim is a product description rather than something an outside reader can check.