Selective disclosure (viewing keys + zero-knowledge proofs)

Provide on-demand, scoped visibility into confidential trades and positions via threshold-controlled viewing keys or zero-knowledge predicate proofs that answer specific regulator questions. The institution keeps plaintext private by default and releases only the minimum information required to satisfy a specific, logged mandate.

Works best when

  • A regulator needs targeted visibility into specific trades or accounts without blanket transparency.
  • The workflow can require an approval step that is logged and revocable.
  • Zero-knowledge predicates can answer most regulator questions without releasing raw data.

Avoid when

  • Policy requires fully public plaintext of all transactions.
  • The organisation cannot support the operational complexity of threshold key custody and audit storage.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions, regulator-initiated disclosure is a normal part of compliance. Both the subject and requester have audit obligations and legal recourse, and the approval workflow sits inside established supervisory channels.

Institution to end user

I2U

For end users, disclosure should remain user-controlled wherever possible; see pattern-user-controlled-viewing-keys. When disclosure is imposed on users without their consent or knowledge the pattern collapses to cr: low because the institution can reveal user activity unilaterally.

Post-quantum exposure

Risk · high
Vector
Viewing keys typically derive from EC-based key exchange and are stored as long-lived secrets; HNDL risk is high since ciphertexts and proofs can be archived now and broken later. Predicate circuits built on pairing-based proof systems are also affected.
Mitigation
Migrate key-encapsulation to post-quantum KEMs (for example, ML-KEM) and move predicate circuits to STARK-based systems with hash commitments. See Post-Quantum Threats.

Components

  • Threshold key management that holds viewing-key shares across independent operators and releases material only under policy.
  • Policy engine that checks each request against the active mandate (jurisdiction, scope, time window, requester identity) before assembling a response.
  • Predicate circuit library that can answer common regulator questions ("total volume in ISIN X on date Y"; "no trades with sanctioned parties in quarter Q") without releasing raw data.
  • Attestation log that records every access grant as a signed, hashed entry; a public registry can anchor these hashes for tamper-evidence without revealing content.
  • Approval workflow used by the institution's compliance team to review and sign off on requests before the policy engine acts.

Protocol

  1. regulator Submit a scoped request specifying account, instrument, time window, and mandate.
  2. operator The policy engine checks the request against the active mandate and approvals; an attestation logs the grant.
  3. operator Assemble the response: either a time-limited viewing key reconstituted from threshold shares, or a zero-knowledge proof generated by the predicate circuit over the relevant private state.
  4. operator Deliver the response to the regulator over an authenticated channel.
  5. auditor Verify the disclosure record against the anchored hash to confirm that the response matches the approved mandate.

Guarantees & threat model

Guarantees:

  • Least-privilege, revocable access: viewing keys are time-boxed; predicate proofs leak no raw data.
  • Full audit trail: every grant is recorded, signed, and anchored.
  • Predicate proofs can answer common compliance questions without exposing transaction content.

Threat model:

  • Threshold key custody integrity. A coalition of operators above the threshold can forge responses or leak keys.
  • Mandate parsing correctness. A bug in the policy engine can widen scope beyond what the mandate authorises.
  • Attestation log availability. If the log is rewritable or unobserved, disclosures can be retroactively denied.
  • Predicate circuit soundness and input binding. A misbound predicate may answer a different question than the one logged.
  • Side channels in custody infrastructure are out of scope for this pattern.

Trade-offs

  • Operational complexity: threshold key custody, rotation, and incident response need dedicated runbooks.
  • Predicate authoring requires discipline: circuits must mirror mandate semantics exactly, and changes need auditable version control.
  • Response latency increases with threshold reconstitution or proof generation time; batch workflows absorb this better than real-time supervisory queries.
  • Regulator tooling maturity varies: some supervisory authorities still require raw data formats, limiting applicable use cases.

Example

A supervisory authority asks for trades on a given date in a specific instrument. The policy engine matches the request against the institution's active mandate, an approval record is logged, and a 24-hour viewing key reconstituted from threshold shares is issued. The regulator reviews the trades during the window; at expiry the key is revoked automatically, and the attestation log retains a hashed record for future audit.

See also

Open-source implementations