Key Hierarchy

TL;DR: ZORB Cash uses separate keys for spending and viewing. You can prove your transaction history without giving someone the ability to steal your funds.

The Problem

Most privacy wallets use a single private key. This creates an all-or-nothing situation:

• Need to show transaction history? Share your key.
• Share your key? They can spend your money.

This makes compliance painful. Showing an accountant your transactions means trusting them with your entire balance.

Our Solution: Capability Separation

ZORB Cash derives multiple keys from your seed, each with different capabilities:

Your Seed
    │
    └── Spending Key (sk)
         │
         ├── ask → ak (authorizes spends)
         ├── nsk → nk (derives nullifiers)
         ├── ovk (view outgoing transactions)
         └── ivk (view incoming transactions)
              │
              └── Payment Addresses

What Each Key Can Do

The important part: Viewing keys are derived from your spending key, but you can't go backwards. Someone with your viewing key cannot compute your spending key.

Practical Uses

Share your viewing key with:

• Accountants — For tax reporting
• Auditors — For compliance verification
• Institutions — For loan applications
• Portfolio trackers — To show your balances

They see your full transaction history. They cannot move a single token.

Unlinkable Addresses

ZORB Cash also supports multiple addresses from the same wallet. Each address uses a different "diversifier," making them cryptographically unlinkable.

No one can tell two addresses belong to the same person without your viewing key or diversifier key.

This means you can:

• Give different addresses to different people
• Receive payments without linking your identity across transactions

Security Model

The hierarchy limits blast radius. Losing a viewing key is bad for privacy but doesn't lose funds.

See Also

• Nullifier Epochs — How we keep costs low
• Shielded Yield — Earning on private balances
• Circuit Design — How keys are used in ZK proofs