User-controlled viewing keys
In many privacy-preserving systems the institution operating the service holds viewing keys or equivalent decryption capabilities for all user transactions, which gives it surveillance power over users even when on-chain data is encrypted. User-controlled viewing keys invert that model: the user holds the private viewing key and selectively shares derived sub-keys with specific parties (regulators, auditors, counterparties) for scoped, time-limited access. This pattern is the institution-to-user complement to selective disclosure, which covers the workflow once a scoped key has been shared.
In many privacy-preserving systems the institution operating the service holds viewing keys or equivalent decryption capabilities for all user transactions, which gives it surveillance power over users even when on-chain data is encrypted. User-controlled viewing keys invert that model: the user holds the private viewing key and selectively shares derived sub-keys with specific parties (regulators, auditors, counterparties) for scoped, time-limited access. This pattern is the institution-to-user complement to selective disclosure, which covers the workflow once a scoped key has been shared.
- Dual-key cryptography: a spending key authorises transfers and a separate viewing key grants read access. The split must be enforced at the protocol level so the institution cannot reconstruct one from the other.
- Key-derivation functions: produce scoped sub-keys per note, per account, or per time window. The derivation hierarchy determines how fine-grained disclosure can be.
- Wallet-side key management: holds the master viewing key, produces scoped sub-keys on demand, and never exposes the master key to the service operator.
- Selective-disclosure interface: an authenticated channel for delivering scoped keys to the requesting party along with the scope metadata (time range, account, transaction set).
- Optional threshold splitting or social recovery: backs up the master viewing key across user-controlled devices or custodians without granting the service operator access.
Guarantees:
- User sovereignty: no party can read the user's transaction history without a key the user explicitly provided.
- Scope limitation: derived keys grant access only within the specified scope; over-disclosure is prevented by the derivation scheme, not by policy.
- Auditability without surveillance: regulators can audit when the user cooperates, but cannot conduct ongoing surveillance.
- Damage containment: compromise of a scoped key does not compromise the master key or other scopes.
Threat model:
- Soundness of the underlying cryptographic assumptions (elliptic-curve discrete log for current deployments).
- Correct protocol-level enforcement of the view-spend split inside the privacy-layer circuit, so a malicious operator cannot recover the viewing key from spending operations.
- User-side key-management hygiene: device compromise, poor backup, or coerced disclosure of the master key all defeat the guarantee.
- Out of scope: the pattern does not hide metadata from the service operator outside the encrypted fields, and it does not prevent service denial or censorship at the institution.
- Regulatory tension: some jurisdictions may require always-on institutional access (for example travel-rule implementations or continuous suspicious-activity monitoring). Hybrid models exist where the user holds the master key but pre-commits to granting scoped access under defined conditions.
- Key loss is terminal on the read side: if the master viewing key is lost, historical transaction data is permanently undecryptable. Encrypted backup, social recovery, or threshold splitting across user-controlled devices are the standard mitigations.
- UX burden: users must manage additional key material and make disclosure decisions; wallet UX can simplify this but the user has to understand the consequences of sharing keys.
- Granularity varies by implementation: some privacy stacks expose account-level viewing, others support per-note disclosure, and full viewing keys may reveal both incoming and outgoing flows. The choice of derivation hierarchy determines the privacy-versus-usability trade-off.
- Scope enforcement depends on the circuit design: if the derivation scheme is misspecified, a scoped key may leak data beyond its intended range.
A fund manager executes trades on a privacy L2 where balances remain encrypted to the operator. For quarterly reporting, the manager derives a Q1-scoped viewing sub-key and shares it with compliance through an authenticated channel; compliance verifies Q1 transactions against the on-chain commitments without access to earlier or later periods. When a regulator requests an audit of specific asset holdings, the manager derives an asset-scoped key that reveals positions in a single instrument across all time, again without granting access to the rest of the portfolio. Scoped keys are rotated after each engagement so a later audit cannot piggyback on an earlier disclosure.