# Commission brief: a zero-knowledge proof that a label is the band of its document

**Status:** not commissioned. No cryptographer or firm has been engaged and no budget has been set. This is the brief we would send. Mirror will not hand-roll this proof; until a reviewed implementation exists, every verdict keeps stating `asserts.label_equals_value_band: "not_proven_here"`.

## 1. The gap this closes

Two banks' banders each commit a band label for the same shipment. The operator compares those commitments. It never sees a value, a band or a salt.

What the verdict proves today:

- the committed labels agree, or they do not;
- which member signed each label;
- that the label a bander committed matches the document its trade platform signed at booking (`mirror-origin`) — but only when someone opens it at audit, after the fact.

What no verdict proves at the moment it is signed: that the label **is** the band of the value in that signed document. A bander that commits a false label is caught with certainty at the first opening, but not before the clear.

A zero-knowledge proof attached to each leg would move that from audit time to verdict time, without revealing the value, the document, the salt or the band.

## 2. The relation to prove

Notation:

- `H` is SHA-256.
- `‖` is byte concatenation.
- `lp(x)` is `len(x) ‖ ":" ‖ x`, with the length as decimal ASCII.
- Every string is ASCII.

**Public inputs (per leg)**

| Input | What it is |
|---|---|
| `C_o` | The origin commitment, `"o:" ‖ hex(H(lp(ρ) ‖ lp("mirror:origin:v1") ‖ lp(canon(doc))))`. It is signed ES256 by a ratified origination key at booking; that signature is verified outside the proof. |
| `E` | The ratified corridor edges, a sorted list of positive decimals. The parties hold the table; the operator holds ratified edges by design. |
| `t` | The ratified tolerance, an integer from 0 to 6. |
| `{c_b}` | The leg's published commitment set, `c_b = hex(H(σ ‖ ":" ‖ dec(b)))`, for every band `b` in the window below. |
| `ctx` | A binding context: the leg's `shipment_ref` (an opaque locator commitment), its `role`, and the corridor reference. A proof must not transplant onto another leg. |

**Private witness**

| Witness | What it is |
|---|---|
| `doc` | `{ value, unit_qty, currency, basis, terms_hash }`, the figures the trade platform booked. `canon` is Mirror's canonical JSON (recursively sorted keys; decimals as their shortest exact string). |
| `ρ` | The 256-bit document salt, kept with the document in the trade platform. |
| `σ` | The per-shipment corridor salt, `HMAC-SHA256(K_corridor, "mirror:" ‖ ref)`. It may be supplied as a witness directly. |

**Statement.** There exist `doc`, `ρ` and `σ` such that all of the following hold:

1. `C_o` opens to `doc` under `ρ`, as defined above.
2. `β = bandOf(doc.value, doc.unit_qty, E)`, in **exact decimal**: `β` is the number of edges `e` in ascending order for which `value / unit_qty > e`, stopping at the first that fails. Each comparison is the integer cross-multiplication `v·10^(s_e+s_q) > e·q·10^(s_v)` over decimal mantissas and scales. No floating point; `2065.84 / 17` must band exactly as `121.52`.
3. The published set `{c_b}` is exactly `{ H(σ ‖ ":" ‖ dec(b)) : b ∈ [max(0, β−t), β+t] }`, in ascending order. If the corridor sets `edge_margin`, the near-edge extension in `mirror-kernel.commitLeg` also applies. Supporting it is optional in a first version, but it must be declared.
4. The proof is bound to `ctx`.

The reference semantics are the functions `bandOf` and `commitLeg` in `kernel/mirror-kernel.js`, and `originCommitment` in `kernel/mirror-origin.js`. When prose and code disagree, the code wins, and the disagreement is a finding.

## 3. Constraints

- **No trusted setup** is strongly preferred: a transparent system. A universal setup is acceptable only with a public, multi-party ceremony transcript that no single party, including Mirror, controls.
- **The prover runs inside the bank**, beside the bander, on commodity servers. It has no network and no GPU requirement. The bank's figures never leave its perimeter, not even to a proving service.
- **The verifier runs anywhere, offline:** in a browser (the console and the examiner pack) and in Node (the operator and the bander), as JavaScript or WebAssembly, with no network calls. A proof that fails to verify makes the leg `undetermined`, never a pass.
- **Hash choice:**
  - Proving against the deployed SHA-256 commitments is preferred.
  - If that is prohibitive, propose a v2 commitment, for example a circuit-friendly hash over fixed-width fields. Say how it is bound alongside v1 at booking, and give a migration path.
  - Any hash must have published cryptanalysis we can cite.
- **Mirror adds nothing that looks like judgement:**
  - The proof yields one bit per leg: proven or not.
  - No score, no probability, no ranking, no filing decision.
  - The operator must not need any secret or witness data to verify.

## 4. Acceptance criteria

1. **A specification:** the relation, the proof system, the encoding of exact decimals, and a security argument for soundness and zero-knowledge.
2. **An independent review:** a second cryptographer who did not write the implementation reviews the specification and the code. The report is published.
3. **Differential testing against the kernel.** On a published corpus, the prover accepts exactly the legs that `commitLeg` produces from the signed document, and nothing else. The corpus includes values sitting exactly on an edge, the first and last bands, tolerance 0 to 6, and decimal scales up to 12 places.
4. **Negative tests that must fail:**
   - a label off by one band;
   - a value altered from the signed document;
   - a salt that is not the corridor's;
   - substituted edges;
   - a widened tolerance;
   - a proof moved to another leg, role or shipment;
   - a malleated proof.
5. **Measured performance:** prover time, verifier time and proof size, measured and reported on stated hardware. These are reported numbers, not targets we assert today.
6. **Fail-closed integration:**
   - `asserts.label_equals_value_band` becomes `"proven"` only when every judged leg carries a verifying proof;
   - anything else leaves `"not_proven_here"`;
   - a verifier error is `undetermined`.
7. **Licensing** that lets the verifier ship inside Mirror's published, offline verification kit.

## 5. Deliverables

- The specification and the review report.
- Circuit or AIR source, with build instructions that reproduce the verification key.
- A prover command-line tool the bander can call offline.
- A verifier in JavaScript or WebAssembly, with an integration note for `mirror-leg` and `mirror-assertion`.
- Test vectors, positive and negative, in the format of `/conformance-vectors.json`.
- Benchmarks, with the hardware stated.

## 6. What the proof will not do

- **It will not make a document true.** A platform that books a false document gets a correctly proven false label. Only an independent witness on the price or the goods (`mirror-bulletin`, the independence gate) answers that.
- **It will not price anything.** There is no oracle and no computed price table, before or after.
- **It will not make the operator's comparison zero-knowledge or MPC.** The comparison stays equality of salted commitments, and the verdict record keeps saying so.

## 7. How a proposal is judged

In order:

1. soundness argument and reviewability;
2. no trusted setup;
3. fidelity to the deployed exact-decimal semantics;
4. verifier size and speed offline;
5. prover cost inside a bank.

A proposal that asks for the operator to hold witness data, or for a single party to run a setup, is out of scope, whatever its performance.