IPTF
testnet hybrid I2I + I2U

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.

CR
Medium
Censorship Resistance
O
Partial
Open Source
P
Full
Privacy
S
Medium
Security
CROPS context
Censorship Resistance
Regulator-mandated disclosure is normal institutional operation and does not block transaction flow, so CR stays medium. Drops to low when disclosure is imposed on end users outside the institution's governance boundary. Threshold custody with independent operators can push CR toward high by preventing any single party from forcing a reveal.
Open Source
Openness depends on the implementation. Pool-native viewing keys and open predicate circuits are inspectable; proprietary threshold KMS deployments are not. Disclosure policy code, mandate verification logic, and revocation flows should be auditable for the pattern to remain interoperable.
Privacy
Disclosure is scoped: the regulator learns only what the mandate authorises. Zero-knowledge predicate responses leak no raw data. Viewing-key responses leak everything inside the key's scope, so key segmentation and time-boxing are important.
Security
Rides on threshold key custody, hardware-rooted policy engines, correct mandate parsing, and tamper-evident audit storage. Key compromise yields retroactive loss of privacy across the key's scope.
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.
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.
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.
Intent

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.

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.
Post-quantum
high risk
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.
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.

Open-source implementations
Ethereum Attestation Service contracts, useful for logging disclosure grants
Solidity