The View-Key Model
The holder authorizes a slice. There is no master key.
Problem
How does an account holder authorize a third party — auditor, accountant, regulator with cause — to inspect a slice of their account history without granting blanket access?
Solution
Scoped view keys derived hierarchically. The holder authorizes the slice.
The holder generates a view key with a published scope: a time range, a counterparty filter, a transaction-type filter, or a combination. The view key, when presented to a verifier, decrypts exactly the slice of state the holder authorized. Outside that slice, the verifier sees nothing.
The view-key construction in StableZK is based on hierarchical deterministic key derivation, allowing scopes to be issued without exposing the holder's master account key. Phase 3 migration moves the underlying KDF to PQ-resistant primitives.
Discussion
No master key exists at the protocol layer. Every disclosure is mediated by the holder's authorization (or by lawful warrant against a regulated counterparty that already has off-protocol access to the holder's identity). The protocol cannot disclose what the holder has not authorized.
See Also
- § 6.2 · ZK Compliance Attestations — the case where no view key is issued and a property is proved instead
- § 6.3 · The Warrant Model — how view keys interact with lawful disclosure