Selective Disclosure (Viewing Keys + Zero-Knowledge Proofs)

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
• Aztec