How it works
How shielding works
What happens when you move funds into the shielded pool, spend them inside it and take them out again.
- Proof system
- Groth16
- Hash
- Poseidon
- Proofs made
- On your device
- Keys held by
- You
The short version#
The shielded pool is one contract holding everyone's deposited stablecoins together. Inside it, money is tracked as notes: small private records of "this much of this asset belongs to this key". The chain only stores a fingerprint of each note. To spend one, your device proves in zero knowledge that it owns a note in the pool without saying which one. The contract checks the proof and records that some note was used, so it cannot be used twice.
Strictly, the privacy comes from commitments and zero-knowledge proofs, not from encrypting balances on chain. Encryption is used for one job: delivering each new note to its owner.
Step by step#
Shield
You send stablecoins from your public wallet to the pool. Your device creates a note for that amount and the contract adds the note's commitment to its Merkle tree. The deposit amount and your wallet are public at this step.Sync
Your device reads new pool entries, decrypts the ones meant for you and stores the notes locally. Your balance is the sum of your unspent notes.Spend inside the pool
To pay someone, your device proves it knows notes whose commitments are in the tree, that it holds their spending key, and that inputs equal outputs. It publishes nullifiers for the spent notes and commitments for the new ones.Contract checks
The verifier contract checks the Groth16 proof, that the Merkle root is one it has recorded, and that no nullifier was seen before. Then it stores the new commitments.Unshield
To leave, you prove ownership of notes the same way and the contract pays out to a public address you name. The amount and that address are public at this step.
Notes, commitments and nullifiers#
Note
A note is a handful of values: the asset, the amount, the owner's public key and a random value called blinding. Think "12.50 pathUSD, owned by key K, with random salt r". The note itself never goes on chain in readable form.
Commitment
The commitment is a Poseidon hash of the note's values. It is what the pool stores. Because of the random blinding, two notes with the same amount and owner produce unrelated commitments, and a commitment cannot be reversed to read the amount.
Merkle root
Commitments are leaves of a Merkle tree kept by the contract. The root is a single hash that summarizes every leaf. A spend proof says "my note is one of the leaves under this root" without saying which leaf. The contract keeps a short history of recent roots so a proof made a moment ago still checks after new deposits land.
Nullifier
A nullifier is a second hash, made from the note and the owner's secret key. Spending a note publishes its nullifier, and the contract refuses any nullifier it has already seen. Only the owner can compute it, and it cannot be linked back to the commitment it came from. That is how double spends are blocked without revealing which note was spent.
| Value | Where it lives | What it reveals |
|---|---|---|
| Note | Your device only | Everything, to you |
| Commitment | On chain, as a tree leaf | That some note exists |
| Merkle root | On chain, in root history | The state of the tree |
| Nullifier | On chain, when spent | That some note was spent |
| Proof | On chain, in the transaction | That the rules were followed |
How notes reach their owner#
When you pay someone, you create their note, so you know its values. They do not, yet. To deliver it, your device encrypts the note (and any memo) to the recipient's viewing key, which is part of their UMBR address, and the ciphertext is posted alongside the commitment.
The recipient's wallet scans new pool entries and tries to decrypt each one with its viewing key. Most fail, because they belong to someone else. The ones that succeed are their notes. This scanning happens locally: no server is told which entries are yours.
- The viewing key can read notes but cannot spend them. The spending key is needed to make a nullifier and a valid proof.
- Both keys are derived from secrets stored on your device. Lose them without a backup and the notes cannot be found or spent.
- If the ciphertext were lost, the commitment alone would not tell the recipient anything. That is why note delivery uses the chain itself rather than a separate service.
What the chain still records#
- Shield deposits: the asset, the amount and the depositing wallet.
- Unshield withdrawals: the asset, the amount and the receiving address.
- For every pool transaction: its time, the number of inputs and outputs, and who paid the gas.
- Commitments, nullifiers and encrypted note blobs, which are unreadable without keys.
These edges and patterns are where most real-world privacy is lost. The privacy model covers how to keep them from giving you away.
What we do not claim#
- The design follows a well-studied pattern: Zcash-style notes, Groth16 proofs and Poseidon hashing. We did not invent it, and we do not claim new cryptography.
- The circuits and contracts are running on testnets and have not been through an external security review. Groth16 also needs a trusted setup; see the production gate for the ceremony we require before any mainnet.
- Zero knowledge hides the contents of a transaction, not its existence. Timing, amounts at the edges and network metadata can still link activity.
- Your privacy is only as good as the security of the device holding your keys.
Go deeper