Shielded Layer Preview
The Encrypted Balances layer hides values on named encrypted accounts. The planned Shielded layer is designed to hide transaction links as well.
This page is a preview, not a current implementation reference.
From accounts to notes
Encrypted Balances use per-account encrypted balances. A transfer updates the sender's encrypted balance and adds an encrypted amount to the recipient's encrypted balance.
The Shielded layer uses a different model: private notes in a shared pool.
A note represents value controlled by a holder. Instead of publicly updating a named account balance, the system records commitments to notes and later spends them with zero-knowledge proofs.
High-level lifecycle
At a high level, the planned Shielded layer works like this:
- Funds enter the pool and create one or more hidden notes.
- The chain records commitments to those notes, not plaintext owners or amounts.
- Spending a note reveals a nullifier so the same note cannot be spent twice. Importantly, nullifier can not be linked to any specific note.
- A zero-knowledge proof shows the spend is valid and the new outputs are well formed.
- New notes or withdrawals are created without revealing the link to the spent note.
This is a preview of the intended model, not a complete protocol specification.
Commitments
A commitment is a public value that binds hidden data without revealing it.
For a shielded note, the hidden data includes the value and holder-related data needed by the spend proof. The chain sees the commitment, but not the note contents.
The commitment lets the system record that a note exists while keeping the value and owner hidden.
Nullifiers
A nullifier prevents double-spending.
When a note is spent, the transaction reveals a nullifier derived from that note. The contract records the nullifier and rejects any later transaction that tries to reuse it.
The proof links the nullifier to the hidden note. The contract then rejects reuse by checking whether that nullifier has already appeared.
Proofs
A shielded spend uses a zero-knowledge proof to show that:
- the spender knows a valid note
- the note is part of the pool
- the revealed nullifier belongs to that hidden note
- the new outputs are formed correctly
The proof does this without revealing the original note, the amount, or the transaction link.
How this differs from Encrypted Balances
| Layer | Amounts | Account graph | Model |
|---|---|---|---|
| Encrypted Balances | Hidden | Visible | encrypted balances on named accounts |
| Shielded | Hidden | Hidden | private notes in a shared pool |
Shielded transfers are designed to hide more than Encrypted Balances, but they do not make all activity disappear. Public observers can still see pool activity, commitments, nullifiers, and timing. Any controlled disclosure model for the Shielded layer belongs in the future Shielded specification.
Encrypted Balances are simpler and useful when hiding values is enough. Shielded transfers are designed for stronger privacy when transaction links should also be hidden.