Keys & authorization
One wallet identity. Distinct permissions for spending, receiving, and observing.
Protocol behavior is proposed. This release is an interface preview; no funds or wallet signatures are accepted.
Permission separation
| Material | Role | Exposure |
|---|---|---|
| Wallet private key | Authorizes spending | Stays in the existing signer |
| Incoming viewing key | Decrypts received notes | Sensitive; local or trusted proxy |
| Outgoing viewing key | Recovers sent-note records | Sensitive; optional disclosure |
| Nullifying key | Derives spent-note identifiers | Sensitive protocol material |
| Receiving key | Enables encrypted delivery | Registered publicly |
| RPC access credential | Protects private service data | Treat as a secret |
Deterministic derivation
The reference design derives privacy material from a fixed wallet signature, with distinct derivation domains for each purpose. A receiving key combines wallet identity, a public nullifying-key commitment, and an encryption public key.
Jammer must validate deterministic signing and signature normalization for every supported wallet. Re-signing a message is a recovery mechanism only when the exact message, account, algorithm, and serialization reproduce the same result.
Authorization is bound to intent
The spending proof must verify the standard transaction signature and bind its recipient, amount, asset, chain context, nonce, and fee constraints to the resulting state transition. Possession of viewing material must not substitute for wallet authorization.
Key registry
On-chain registration binds an address to its receiving material. A Merkle inclusion check inside the proof prevents an intermediary from silently replacing the recipient’s registered encryption key. Recovery and key rotation need explicit release specifications.