Privacy levels
A user’s funds can sit at one of three privacy levels, depending on whether they enter the ShieldedPool and how they enter it.- Public. Funds are held in a public address and visible on-chain. This is the baseline outside the pool.
- Pseudonymous shielded. Funds are held in the ShieldedPool but the entry point (the depositing address) is observable on-chain. The privacy gain is that intra-pool activity is hidden; the entry is not.
- Unlinkable shielded. Funds are held in the ShieldedPool and the entry uses shielded minting, so the deposit on the source side is not linkable to the resulting position inside the pool. This is the strongest privacy level.
The ShieldedPool
The ShieldedPool is a single global pool. All shielded assets sit in the same anonymity set; the cryptographic construction does not segregate assets by type into separate pools. This is intentional: separating assets into per-asset pools would weaken the anonymity set proportional to the number of types. Inside the pool, the cryptographic objects are:- Commitments. A Poseidon hash of (asset type, amount, owner public key, randomness). Commitments are added to a global Merkle tree. The Merkle root anchors the set of valid shielded notes.
- Nullifiers. A deterministic value derived from a note’s secret data. Spending a note publishes the nullifier; the same nullifier cannot be republished, which prevents double-spending. Nullifiers do not reveal which note was spent.
- Notes. The encrypted owner-side record that ties a commitment to a holder. Notes are encrypted to the owner’s viewing key and emitted on-chain as encrypted event data.
The privacy flow
A typical privacy-preserving sequence inside the pool:- The user holds a shielded note for some amount of some asset.
- The user wants to send a portion to another shielded address. They construct a transfer: input note (spent), output note (recipient), output note (change back to self).
- The user generates a zero-knowledge proof that: the input note exists in the Merkle tree; the input note’s nullifier has not been published; the input and output amounts balance per-asset; the user controls the input note’s spending key.
- The transfer is submitted to the chain. Observers see a transaction that includes a Merkle root reference, a nullifier, two commitments, and a proof. They cannot determine the asset, the amount, the sender, or the recipient.
- The Broadcaster, if used, pays gas and submits the transaction. The user pays the Broadcaster a fee from inside the transfer itself, in a way that does not reveal the user’s address.
Gas abstraction
The Broadcaster pays gas on the host EVM chain and is reimbursed inside the shielded transaction. The user never needs to hold native gas tokens of the host chain to interact with the ShieldedPool. This is a meaningful UX property: shielding into the pool with USDC does not require also holding a separate gas asset.Key hierarchy
A ShieldedPool account is rooted in a single seed. From the seed, a deterministic hierarchy derives:- Spending key. Authorizes spending of shielded notes. Held by the user; never shared.
- Viewing key. Allows reading of the user’s shielded transaction history. Can be shared selectively for compliance or accounting purposes.
- Nullifier key. Used to produce nullifiers on spend. Held with the spending key.
Viewing keys and selective disclosure
A viewing key is a one-way reveal: sharing it gives the recipient read access to history within the key’s scope, but the recipient cannot derive the spending key from it. Viewing keys can be scoped (to a time range, to an asset, to a counterparty) so that a regulator, auditor, or accountant receives exactly the scope they need and nothing more. See Privacy and compliance for the institutional integration patterns this enables.Proof system: Groth16 on BN254
The ShieldedPool uses Groth16 on the BN254 elliptic curve as its zero-knowledge proof system. The choice is deliberate:- Proving performance. BN254 has excellent client-side proving performance, important for a system where users generate proofs locally.
- Verifier cost. Groth16 verification is inexpensive in gas terms, important for an on-chain pool.
- Maturity. The BN254 + Groth16 combination has been deployed in production privacy systems for years; the security properties and the toolchain are well-understood.
Security properties
The privacy properties the ShieldedPool guarantees:- Transfer confidentiality. The asset, the amount, the sender, and the recipient of an in-pool transfer are not derivable from on-chain data.
- Balance confidentiality. Shielded balances are not derivable from on-chain data without the viewing key.
- Indistinguishability within the anonymity set. A specific in-pool transfer is indistinguishable from any other in-pool transfer of the same shape.
- Metadata privacy. Timing of transactions, gas patterns, and IP-level network observation are not addressed by the proof system. Network-level privacy is the integrator’s responsibility (use a relay broadcaster, route through a privacy network, etc.).
- Endpoint privacy. Once funds exit the pool to a public address or to an external chain, the destination is observable. Privacy on entry and exit depends on using shielded minting and the RelayAdapter pattern respectively.
Design properties
A few properties worth calling out explicitly:- The pool is multi-asset: USDC, other ERC-20s, and ZEC and chain-native assets share the same anonymity set.
- The pool is upgradeable through governance with strict change-control: the proof system, the curve, and the commitment hash function are not changeable without a coordinated migration.
- The pool is agnostic to the host chain: the same constructions ship on the host EVM chain and on Z Chain when it is live, with no protocol changes between the two.