Shielded Pool

The system for tracking assets without revealing them. When a user deposits funds, they create a cryptographic commitment (like a hashed IOU) added to a public Merkle tree. To spend, they reveal a corresponding nullifier, a unique identifier proving the commitment is being consumed, preventing double-spends.

• The public sees only hashed commitments and nullifiers, not amounts or owners.
• The Merkle tree root acts as a compact, verifiable record of all pool deposits.

Privacy strength depends on the anonymity set—the pool of all possible spenders a transaction could be linked to. Larger pools provide stronger privacy.

• Users automatically select decoy notes from the pool's history when constructing a transaction.
• An external observer cannot distinguish the real spender from the decoys.
• The size and activity level of the pool directly correlate with the practical privacy guarantee.

A core economic benefit. Shielded pools break the transparent history of assets like Bitcoin or Ethereum, where coins can be "tainted" by prior illicit activity. All withdrawn assets from the pool are cryptographically identical.

• This ensures fungibility, where every unit of the asset is interchangeable and equal in value.
• It prevents censorship or devaluation based on transaction history, a property essential for sound digital money.

A feature for auditability and compliance. Users can generate viewing keys—cryptographic keys that allow designated third parties (e.g., auditors, tax authorities) to view their transaction history within the shielded pool.

• This enables selective disclosure, maintaining default privacy while allowing for necessary transparency.
• It's a critical feature for institutional adoption and regulatory compliance frameworks.

A one-time cryptographic ceremony required to generate the public parameters for certain ZKP systems like zk-SNARKs. If the setup is compromised, an attacker could create counterfeit assets.

• Example: Zcash's original "Sprout" and "Sapling" setups involved a multi-party computation (MPC) ceremony to minimize trust.
• Newer zk-STARKs and some recursive zk-SNARK constructions eliminate this requirement, being "transparent" or "trustless."

The security of a shielded pool scales with its anonymity set—the number of unspent transaction outputs (notes) within it that are indistinguishable from each other. A larger pool makes chain analysis and transaction graph linking statistically harder. Key factors influencing the set:

• Total Value Locked (TVL): More deposits increase potential mixing.
• User Activity: Frequent deposits and withdrawals refresh the set.
• Uniformity: Identical note denominations enhance fungibility.

Many ZK-based pools (e.g., Zcash's original Sprout, Tornado Cash) require a trusted setup ceremony to generate public parameters. If compromised, false proofs could be created. Newer systems aim for trustless setups or updatable parameters. Security rests on the assumed computational hardness of underlying problems (e.g., Discrete Log, Elliptic Curve Pairings). A break in these cryptographic assumptions would compromise all user privacy.

Shielded pools create a tension between individual privacy and regulatory requirements like Anti-Money Laundering (AML) and Travel Rule. Solutions to bridge this gap include:

• View Keys: Allow designated parties to audit transaction history.
• Selective Disclosure: Users can prove compliance without revealing full history.
• Shielding/Deshielding Points: Transparency at the fiat on-ramp/off-ramp, with privacy in-between.

While the pool's interior is private, metadata leaks at its edges can weaken privacy. Attack vectors include:

• Timing Analysis: Correlating deposit and withdrawal times.
• Amount Analysis: Unique withdrawal amounts matching deposits.
• Interaction Patterns: Recurring transactions to/from the same external addresses.
• Network-Level Attacks: IP address linking during transaction broadcast.

A cryptographic primitive that allows a user to commit to a chosen value while keeping it hidden, with the ability to reveal it later. In shielded pools, a commitment is created for each deposit, recording the note's value and owner's address in a concealed form on the pool's Merkle tree.

• Function: Provides data integrity and privacy. The commitment hash is publicly stored, but the underlying data is secret.
• Revealing: To withdraw, the user must provide a ZKP that they know the secret data (a nullifier) corresponding to a valid commitment.

A unique cryptographic tag generated from a user's secret spending key and a note's details. It prevents double-spending within a shielded pool.

• Process: When a user withdraws funds, they publicly reveal the nullifier for the spent note.
• Purpose: The pool's smart contract checks a nullifier set; if the nullifier already exists, the withdrawal is rejected. This ensures each deposit note can only be spent once, all while keeping the link between deposit and withdrawal anonymous.

A hierarchical data structure used to efficiently and securely record the state of a shielded pool. Each leaf node is a cryptographic commitment representing a private deposit.

• How it works: The root of the Merkle tree (a single hash) represents the entire set of commitments. To prove membership of a note, a user provides a Merkle proof—a path from their leaf to the root.
• On-chain efficiency: Only the Merkle root needs to be stored on-chain, minimizing gas costs while allowing users to prove they own a valid, unspent note in the pool.

The group of all possible users who could have originated a transaction. In a shielded pool, the anonymity set is the set of all unspent notes (commitments) within the pool.

• Privacy Metric: The larger the pool's total value and number of users, the larger the anonymity set, making it statistically harder to trace individual transactions.
• Critical Factor: A small pool with few deposits provides weak privacy, as transactions are easier to correlate through timing or amount analysis.