Key Management
How Dust derives, stores, and protects your stealth keys — and what you should back up.
Key Derivation
Dust derives two secp256k1 private keys — a spend key and a view key — purely in the browser. They are never sent to any server.
Because the derivation uses both the wallet signature and the PIN, neither alone is sufficient to reproduce the keys. An attacker who compromises your wallet cannot derive stealth keys without knowing your PIN, and vice versa.
The Two Keys
Spend Key
HIGH SENSITIVITYControls the ability to claim funds from stealth addresses. Used to derive the per-payment stealth private key when a payment is detected. Never leaves the browser. The public part (spendKey × G) is registered on-chain as half of your meta-address.
View Key
MEDIUM SENSITIVITYUsed to detect incoming payments by scanning announcements. Cannot spend funds. The public part is registered on-chain. The private part is used only in the scanner and never leaves the browser.
V2 Key Derivation (Privacy Pool)
DustPool V2 uses a separate key derivation for its ZK-UTXO model. V2 keys operate on the BN254 curve (required for FFLONK proofs) rather than secp256k1.
Spending Key
HIGH SENSITIVITYDerives the ownerPubKey (via Poseidon hash) that appears in UTXO commitments. Required to spend notes. The ownerPubKey is public; the spending key is secret.
Nullifier Key
MEDIUM SENSITIVITYUsed to compute nullifiers: N = Poseidon(nullifierKey, leafIndex). Knowing this key allows an auditor to track which notes have been spent — used in view keys for voluntary disclosure.
View Keys & Selective Disclosure
A view key allows a third party (auditor, tax authority, compliance officer) to verify your transaction history without gaining spending authority. It contains the ownerPubKeyand nullifierKey — enough to verify commitments and track spent notes, but not enough to move funds.
View key security
What Is Stored Locally
| Item | Where | Sensitivity |
|---|---|---|
| PIN hash (bcrypt) | localStorage | Medium — reveals PIN if brute-forced |
| Scan cursor (last scanned block) | localStorage | Low — public information |
| Detected stealth addresses + balances cache | localStorage | Low — public information |
| DustPool deposit notes (nullifier + secret) | localStorage | HIGH — losing this = losing funds |
| DustSwap deposit notes (nullifier + secret) | localStorage | HIGH — losing this = losing funds |
| Payment link definitions | localStorage | Low |
| Claim addresses (HD-derived) | localStorage | Low — derivable from keys |
| V2 deposit notes (encrypted) | IndexedDB | HIGH — AES-256-GCM encrypted, key from spendingKey |
| V2 note encryption key | Derived on-demand | Never stored — SHA-256(spendingKey bytes) |
Back up your deposit notes
What If I Lose Something?
I forget my PIN
You cannot re-derive your stealth keys. However, your wallet address still holds any funds you've claimed to it. You can re-register by creating a new PIN and a new .dust name — you'll lose the old name and any unclaimed stealth payments.
I lose access to my wallet (seed phrase)
You cannot re-derive your stealth keys (wallet signature required). Same outcome as forgetting your PIN. Claimed funds are whatever your seed phrase controls — they are not in the stealth system.
I clear my browser localStorage
Stealth keys can be re-derived (log in again with wallet + PIN). Your .dust name is on-chain — it persists. Deposit notes are lost — DustPool / DustSwap deposits become unrecoverable if not backed up.
Someone sees my localStorage
They see deposit notes and cached scan data. They cannot derive stealth keys from localStorage alone (keys are never stored — only re-derived on demand). Deposit notes are bearer instruments — treat localStorage like a physical notepad.
I want to share my transaction history with an auditor
Generate a view key from Settings → Disclosure. The view key contains your ownerPubKey and nullifierKey — enough for the auditor to verify all your notes and spending, but not enough to move funds. The auditor can independently verify commitments using Poseidon hash checks.
Security Best Practices
- →Use a strong, unique PIN — it is the second factor protecting your stealth keys.
- →Export deposit notes from the Wallet page and store them offline or in a password manager.
- →Do not share the private view key — it allows others to see all your incoming payments.
- →The spend key is never stored — it is re-derived each session. This is a feature, not a bug.
- →Settings → Danger Zone lets you clear all keys and start fresh if your PIN is compromised.
- →V2 deposit notes are encrypted with AES-256-GCM in IndexedDB — even browser access doesn't expose note data without your keys.
- →View keys allow selective disclosure. Share them only with trusted parties — they reveal your full transaction graph.