Title: Selective Disclosure (Viewing Keys + Zero-Knowledge Proofs) · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-regulatory-disclosure-keys-proofs/

Markdown Content:
---
description: 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.
title: Selective Disclosure (Viewing Keys + Zero-Knowledge Proofs) · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### 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

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.

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.

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](../domains/post-quantum.md).

## 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

* [EAS documentation](https://easscan.org/docs)
* [Aztec](/vendors/aztec/)

### Open-source implementations

* [ github.com Solidity Ethereum Attestation Service contracts, useful for logging disclosure grants ↗ ](https://github.com/ethereum-attestation-service/eas-contracts)

CROPS profile

Censorship-resistance: mediumOpen source: partialPrivacy: fullSecurity: medium

CRCensorship-resistancemedium

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.

OSOpen sourcepartial

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.

PPrivacyfull

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.

SSecuritymedium

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.

#### Referenced by

approaches7
* [Private Bond Issuance & Trading](/approaches/approach-private-bonds/)
* [Private Identity](/approaches/approach-private-identity/)
* [Private Money Market Funds](/approaches/approach-private-money-market-funds/)
* [Private Payments](/approaches/approach-private-payments/)
* [Private Smart Derivatives](/approaches/approach-private-derivatives/)
* [Private Trade Settlement](/approaches/approach-private-trade-settlement/)
* [White-Label Infrastructure Deployment](/approaches/approach-white-label-deployment/)
use cases2
* [Private Identity](/use-cases/private-identity/)
* [Resilient Identity Continuity](/use-cases/resilient-identity-continuity/)
building blocks28
* [Atomic DvP via ERC-7573 (cross-network)](/patterns/pattern-dvp-erc7573/)
* [Compliance Monitoring](/patterns/pattern-compliance-monitoring/)
* [Cross-Chain Privacy Bridge](/patterns/pattern-cross-chain-privacy-bridge/)
* [Crypto-registry bridge (eWpG) with EAS mirroring](/patterns/pattern-crypto-registry-bridge-ewpg-eas/)
* [ERC-3643 Tokenized RWAs](/patterns/pattern-erc3643-rwa/)
* [Hybrid Public-Private Modes](/patterns/pattern-hybrid-public-private-modes/)
* [ICMA Bond Data Taxonomy (canonical terms/events)](/patterns/pattern-icma-bdt-data-model/)
* [Low-cost L2 + Off-chain Encrypted Audit Log](/patterns/pattern-l2-encrypted-offchain-audit/)
* [Modular Privacy Stack](/patterns/pattern-modular-privacy-stack/)
* [Noir Private Contracts](/patterns/pattern-noir-private-contracts/)
* [Origin-Locked Cross-Chain Confidential Ledger](/patterns/pattern-origin-locked-confidential-ledger/)
* [Permissioned Ledger Interoperability](/patterns/pattern-permissioned-ledger-interoperability/)
* [Privacy L2s](/patterns/pattern-privacy-l2s/)
* [Private Client Authentication for Institutional EOAs](/patterns/pattern-private-mtp-auth/)
* [Private Intent-Based Vaults](/patterns/pattern-private-vaults/)
* [Private ISO 20022 Messaging & Settlement](/patterns/pattern-private-iso20022/)
* [Private PvP (cash to cash) Settlement via ERC-7573](/patterns/pattern-private-pvp-stablecoins-erc7573/)
* [Private Shared State (FHE)](/patterns/pattern-private-shared-state-fhe/)
* [Private Shared State (MPC + ZK / co-SNARKs)](/patterns/pattern-private-shared-state-cosnark/)
* [Private Shared State (TEE)](/patterns/pattern-private-shared-state-tee/)
* [Private Stablecoin Shielded Payments](/patterns/pattern-private-stablecoin-shielded-payments/)
* [Proof of Innocence (Association Set Proofs)](/patterns/pattern-proof-of-innocence/)
* [Shielding](/patterns/pattern-shielding/)
* [User-controlled viewing keys](/patterns/pattern-user-controlled-viewing-keys/)
* [Verifiable Attestation](/patterns/pattern-verifiable-attestation/)
* [ZK Wrappers](/patterns/pattern-zk-wrappers/)
* [zk-KYC/ML + ERC-734/735 identity claims](/patterns/pattern-zk-kyc-ml-id-erc734-735/)
* [zk-promises (stateful anonymous credentials)](/patterns/pattern-zk-promises/)
jurisdictions1
* [Banking Secrecy (multi-jurisdiction)](/jurisdictions/int-banking-secrecy/)
vendors8
* [Chainlink ACE](/vendors/chainlink-ace/)
* [EY](/vendors/ey/)
* [Fairblock](/vendors/fairblock/)
* [Hinkal](/vendors/hinkal/)
* [Orion Finance](/vendors/orion-finance/)
* [Privacy Pools](/vendors/privacypools/)
* [Railgun](/vendors/railgun/)
* [TX-SHIELD](/vendors/tx-shield/)
RFPs1
* [Privacy Pools Institutional Integration](/rfps/rfp-privacy-pools/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```