Viewing Keys & Selective Disclosure
The Selective Disclosure system is DarkNet's primary differentiation. It lets a user prove specific properties about their transaction history — clean funds, range compliance, or identity binding — without disclosing any underlying transactions.
Key Hierarchy
Each DarkNet address derives a four-level key hierarchy. Keys can be marked expirable (auto-invalid after t1) and revocable via an on-chain registry.
| Key Type | Capability | Use Case |
|---|---|---|
| sk | Authorise spends | Owner only |
| fvk | Decrypt all incoming and outgoing notes | Auditor, tax authority |
| ivk | Decrypt incoming notes only | Compliance, exchange withdrawal |
| svk | Decrypt notes within defined time / amount / asset range | Partial audit, investor reporting |
Scoped Viewing Keys (svk) bind to a time window [t0, t1], an amount ceiling vmax, and an optional asset filter A. Using a scoped key outside its bound returns no valid decryptions — without revealing that the scope was exceeded.
Compliance Proof Types (MVP)
Proof of Clean Funds
Proves that an amount V was not derived from a blacklist B.
The prover reveals only the aggregate sum and the negative-membership claim — not individual notes, amounts, or origins.
Proof of Transaction Range
Proves all transactions within [t0, t1] were below a threshold vmax.
Satisfies FATF Travel Rule threshold reporting without disclosing the actual amounts.
Proof of Identity Binding
Proves the wallet holder has completed KYC verification with an approved identity provider, without revealing the identity itself. See the Identity Layer documentation for the ZK-KYC credential flow.
Proof Lifecycle
- All proofs are generated locally by the user's wallet — no data leaves the device.
- Proofs require no trusted third party beyond the initial Groth16 setup ceremony.
- Artifacts are exported as a JSON bundle
{π, public_inputs, verifying_key_hash, ipfs_cid}. - Any counterparty with the circuit's verifying key can verify a proof independently.
- Proof artifacts are stored on IPFS and referenced by content hash.
Expiry & Revocation
Expirable Keys
Scoped and incoming viewing keys auto-invalidate after t1. No further decryptions succeed after expiry.
On-Chain Revocation
Any key can be revoked at any time via a lightweight on-chain transaction against the revocation registry.