Threat Model & Architecture Brief

For a security or legal team evaluating Mirror. This is the document to hand a reviewer who asks "what could go wrong, and what would an attacker actually get?" It states the architecture as facts, states the threats against it, and — deliberately — states its own residual weaknesses, because a threat model that only lists its strengths is marketing, not a threat model.

It asserts no legal conclusion. Whether this architecture places Mirror outside a given data-protection regime's definition of a "processor" is a question for your counsel; this brief gives them the facts to answer it, not the answer.

1. What the operator receives — the whole posture in one line#

For a reconciliation, the operator receives an opaque salted commitment (a sha256 string) and, for concurrent-exposure checks, an asserted financing window (two dates). That is all. It never receives — and has no way to derive — the price, the value, the amount, the currency, the commodity, the counterparty, the customer, the document, or a name. The raw figure is banded and committed on the member's own machine, inside its own perimeter, before anything is sent.

Everything below follows from that one fact.

2. The honeypot question — the difference that matters#

The dominant model for cross-bank fraud detection is a central registry: banks submit trade document data (or fingerprints of it) to one operator that holds it and checks for matches. That operator is a data custodian, and a data custodian is a single catastrophic breach away from exposing every institution that trusted it — which is also why it carries the cross-border transfer friction and the processing agreements.

Mirror is the structural opposite: the operator holds nothing worth stealing. You do not have to take that on faith — the "Break it" console lets you attack a simulated operator and read exactly what each adversary gets:

There is no "honey pot" to change data-residency laws around, because there is no pot.

3. What travels, and what leaks — stated honestly#

An honest threat model names its residual exposures. Mirror's are these, and every record it emits repeats them in its own disclaimer field:

• Set sizes and linkability. The operator learns how many commitments a member sends for one shipment, and — because a commitment is a stable pseudonym by design (that is what makes it a join key) — it can link every submission about that one shipment and count how many distinct shipments a member submits. It cannot open any of them.
• A key-holder enumeration oracle. Both counterparties hold the corridor key by construction, so either can compute the commitment for a reference it guesses and recognise it. Trade reference spaces are low-entropy and sequential, so a key-holder can enumerate a counterparty's space. Mirror blinds the operator, not a fellow key-holder — and where a key is consortium-wide (duplicate- financing across independent lenders), the blast radius is the whole membership.
• A leaked key is retroactive. A corridor key that leaks de-anonymises every shipment ever joined under it. Rotate per corridor, per period, knowingly.
• Not the physical truth. A cargo-intrinsic key binds a container or vessel to a voyage leg as the transport document states it. Mirror reconciles what two banks independently assert; it has no satellite, no sensor, no chain of custody, and cannot compare either party to reality.

These are boundaries, not bugs. Stating them is what makes the rest defensible.

4. Verifiability — trust routes through the math, not the company#

• Every verdict is ES256 (ECDSA P-256) over canonical JSON, checkable offline against the operator's published keys, with no call to any Mirror server. The in-page verifier does it in your browser; the worked examiner pack does it with the network unplugged.
• The bander is one dependency-free file whose sha256 is its identity — read it, hash it, run it. No dependency tree, no install step, no network. It computes the same commitments the operator verifies against, byte for byte, so a browser-made or bander-made verdict cannot silently diverge.
• The operator is a hosted bundle whose exact bytes you can hash, and a continuous canary runs known-answer trades the operator cannot see coming — public, ongoing proof that the live operator is answering honestly, not merely that it answered.

5. What Mirror is not — for the reviewer's file#

• Not zero-knowledge, and not multiparty computation. The blindness is salted band-commitments over standard primitives (SHA-256, ECDSA P-256, canonical JSON, an RFC 6962 Merkle log), plus one genuine Diffie-Hellman PSI kernel. Any claim of "ZK" would be false and we do not make it.
• Bands, not exact values. A clear is same-band agreement, not equality of prices.
• Needs a ratified corridor table. The two banks agree the bands, the units, the basis and the legal basis first; Mirror invents no price.
• A clear is a defensible reconciliation, never a verdict of innocence. Two parties who agree a false number reconcile perfectly, and nothing in the cryptography can see that.
• It decides nothing and settles nothing. Mirror emits a signed verdict; it makes no filing decision, holds no money, and touches no wire. A divergence routes into the review process you already run, under your own anti-tipping-off obligations. It cannot hold the decision, which is precisely why it cannot leak it.

6. Deployment posture#

The bander runs inside your perimeter; the operator receives only commitments. Data that never leaves the institution is data there is nothing to process, transfer, or agree terms over — a factual consequence of the architecture. What that means under a specific regime (GDPR, CCPA, a data- localisation rule) is your counsel's call; this brief is written so they can make it quickly.

Read alongside the protocol specification, the conformance vectors, and the corridor-table standard. Nothing here is a legal representation, and Mirror is pre-registration: pilot enquiries are taken by direct introduction.