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

URL Source: https://ethsystems.org/patterns/pattern-regulatory-disclosure-keys-proofs/

Markdown Content:
---
description: The pattern has two modes.
title: Selective Disclosure (Viewing Keys + Zero-Knowledge Proofs) · Pattern · EthSystems
image: https://ethsystems.org/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.
* A register of record (for example, a transfer agent or a securities registrar) must be able to rebuild beneficial ownership for any point in time.

#### 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/).

## 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.
* Register-of-record key (standing register mode): an encryption key held by the register of record, ideally under threshold custody. Every value-moving operation encrypts the resulting position data to it.

## Protocol

Mandate-based disclosure:

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.

Standing register disclosure:

1. operator The register of record publishes its encryption key and anchors the key's hash in the attestation log.
2. user Every value-moving operation (issuance, transfer, redemption) encrypts the resulting position data, such as owner identifier and amount, to the register key.
3. prover The circuit constrains that ciphertext to encrypt the same values the proof commits to. Without this constraint, completeness rests on the holder's legal obligation to encrypt honestly.
4. contract The ciphertext is published with the transaction, so the feed needs no separate delivery channel.
5. operator The register of record decrypts the feed, rebuilds beneficial ownership for any point in time, and reconciles it against its off-chain records.

## 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.
* Standing register disclosure: the register of record can rebuild beneficial ownership for any point in time without holder cooperation, provided the circuit constrains the ciphertext.

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.
* Register key compromise (standing register mode) exposes the entire register for every period the feed covers. Threshold custody and key rotation carry more weight than in the mandate-based mode.
* Unconstrained ciphertexts. If the circuit does not bind the register ciphertext to the committed values, a holder can publish data the register cannot decrypt, and completeness falls back to legal enforcement.
* 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.
* The standing register mode inverts least privilege, and feed granularity has no free option. Per-operation data lets the register rebuild holdings for any date, and with them most flows, since two holders' balances changing together reveal the pair. Coarser feeds, such as periodic snapshots, reveal less but may not meet record-keeping duties. What a register of record must minimally see is an open question. Constraining the ciphertext in-circuit also adds proving cost to every value-moving operation.

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

The transfer agent of a tokenized security holds the register key. Each issuance, transfer and redemption publishes position data encrypted to that key, bound to the proof by the circuit, so the register can reproduce holder records, eligibility status and tax reports for any date without asking holders.

## 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. The standing register mode discloses register data to the register of record by design, at a granularity the deployment sets; privacy against everyone else is unchanged.

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 blocks31
* [Atomic DvP via ERC-7573 (cross-network)](/patterns/pattern-dvp-erc7573/)
* [Compliance Monitoring](/patterns/pattern-compliance-monitoring/)
* [Confidential Policy Verdicts](/patterns/pattern-confidential-policy-verdicts/)
* [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 Geospatial Attestation](/patterns/pattern-private-geospatial-attestation/)
* [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/)
* [Reproducible Audit Extraction](/patterns/pattern-reproducible-audit-extraction/)
* [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/)
vendors11
* [Bermuda](/vendors/bermuda/)
* [Chainlink ACE](/vendors/chainlink-ace/)
* [EY](/vendors/ey/)
* [Fairblock](/vendors/fairblock/)
* [Gateway Open Privacy Suite](/vendors/gateway-open-privacy-suite/)
* [Hinkal](/vendors/hinkal/)
* [Orion Finance](/vendors/orion-finance/)
* [Privacy Pools](/vendors/privacypools/)
* [Railgun](/vendors/railgun/)
* [The Graph](/vendors/the-graph/)
* [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"}}]}
```