SIP vs Pool Mixing: The Cryptographic Difference

Privacy in Web3 has evolved significantly. Tornado Cash pioneered pool mixing, Privacy Cash brought it to Solana with compliance features, and SIP Protocol introduced Pedersen commitment-based privacy. Let’s examine how these approaches actually differ.

Understanding Pool Mixing (Tornado Cash & Privacy Cash)

Pool mixing protocols break the on-chain link between deposits and withdrawals using zero-knowledge proofs and Merkle trees.

How It Works

1. User deposits tokens into a privacy pool
2. A commitment is added to a Merkle tree
3. User withdraws to a new address using a ZK proof
4. The proof shows “I deposited” without revealing which deposit

Your privacy comes from the anonymity set - the crowd of depositors you’re hiding in.

Evolution: Not Just Fixed Amounts Anymore

Classic Tornado Cash still uses fixed denominations (0.1, 1, 10, 100 ETH). But the ecosystem has evolved:

Tornado Cash Nova (2021) introduced:

• Arbitrary deposit amounts via UTXO model
• Shielded transfers within the pool
• Currently limited to 1 ETH max (beta)

Privacy Cash on Solana (August 2025):

• Arbitrary amounts from launch
• Selective disclosure for authorized parties
• AML/KYT integration hooks
• Auditor keys for compliance
• Over 680K SOL processed, 11.7K+ wallets

Pool mixing has matured. The “fixed amounts only” criticism applies to classic Tornado, not modern implementations.

The SIP Approach: Pedersen Commitments

SIP Protocol takes a fundamentally different approach. Instead of hiding in a crowd, we hide amounts mathematically.

How It Works

Commitment = value × G + blinding × H

This commitment is:

• Hiding: No one can extract the value from the commitment
• Binding: You can’t change the value after committing
• Homomorphic: You can verify Commitment(A) + Commitment(B) = Commitment(A+B) without knowing A or B

Stealth Addresses

Each recipient gets a unique one-time address. Your transaction can’t be linked to previous ones - not because you’re in a pool, but because the address itself is cryptographically fresh.

// Generate stealth address for recipient
const stealth = sip.generateStealthAddress(recipientPublicKey)
// Sender sends to stealth.address
// Only recipient can derive the private key to spend

Viewing Keys for Compliance

Like Privacy Cash’s selective disclosure, SIP includes viewing keys:

const viewingKey = sip.generateViewingKey({
  scope: 'transaction',
  recipient: 'auditor-public-key'
})

The auditor can verify your transactions; the public cannot.

The Real Differences

Let’s be honest about what actually differentiates these approaches:

1. Privacy Source

Approach	Privacy Comes From
Pool Mixing	Anonymity set (the crowd)
Pedersen	Mathematical hiding (cryptography)

Pool mixing: Your privacy depends on pool participation. Early pools or unusual amounts have weaker guarantees.

Pedersen: Privacy is cryptographically guaranteed regardless of how many others use the system. 1.5 SOL and 1,000,000 SOL have identical privacy properties.

2. Homomorphic Properties

Pedersen commitments are additively homomorphic:

Commit(5) + Commit(3) = Commit(8)

This enables:

• Proving transaction balances without revealing amounts
• Range proofs (amount is positive, less than X)
• Aggregate proofs across multiple transactions

Pool mixing can’t do this - you prove membership, not amount properties.

3. Chain Agnosticism

Protocol	Chain Support
Tornado Cash	Ethereum + EVM chains
Privacy Cash	Solana only
SIP Protocol	Chain-agnostic (Ethereum, Solana, NEAR, Bitcoin, Cosmos, Move chains)

SIP’s privacy layer sits above the blockchain - same primitives work everywhere.

4. Compliance Approaches

Both have compliance mechanisms now:

Protocol	Compliance Mechanism
Privacy Cash	Selective disclosure, auditor keys, AML/KYT hooks
SIP Protocol	Viewing keys with scoped disclosure

The implementations differ, but both acknowledge that “hide everything forever” isn’t viable for institutional adoption.

Technical Comparison

Feature	Pool Mixing (Modern)	Pedersen (SIP)
Amount flexibility	Arbitrary (Nova/PrivacyCash)	Arbitrary
Privacy source	Anonymity set	Cryptographic
Compliance	Selective disclosure	Viewing keys
Homomorphic proofs	No	Yes
Chain support	Single chain	Chain-agnostic
Pool dependency	Yes - privacy scales with usage	No - constant guarantees
Stealth addresses	No	Yes (EIP-5564)

Amount Correlation Attacks Explained

One of the most significant differences between these approaches is vulnerability to amount correlation attacks - statistical techniques that deanonymize users by analyzing transaction amounts.

The Classic Pool Mixing Vulnerability

With fixed-denomination pools (classic Tornado Cash), an attacker traces users by following amounts:

Scenario: Alice deposits 3.7 ETH, then 1.3 ETH to reach 5 ETH total

Attacker observes:
  Pool A (0.1 ETH): 37 deposits from Alice
  Pool B (1 ETH):   1 deposit from Alice
  Pool C (0.1 ETH): 3 deposits from Alice

Later, withdrawals:
  50 × 0.1 ETH withdrawals to Address X

Correlation: The unique pattern (37+1+3 deposits, 50 withdrawals)
is statistically rare. Alice is likely the only user with this exact pattern.

Even though each individual deposit is hidden in the pool, the combination of amounts creates a fingerprint.

Modern Pool Mixing (Arbitrary Amounts)

Privacy Cash and Tornado Nova allow arbitrary amounts, but correlation attacks adapt:

Scenario: Alice deposits 1,234.56 SOL

Problem: How many other users deposited exactly 1,234.56 SOL?

If Alice is the only one → 100% deanonymized
If 5 others did → 20% anonymity set
If 1000 others → strong privacy

Arbitrary amounts reduce the correlation attack surface but do not eliminate it. The attack becomes probabilistic rather than deterministic.

Timing Correlation

Pool mixing is also vulnerable to timing analysis:

Timeline:
09:00 - Alice deposits 500 SOL
09:15 - 3 other deposits
09:30 - Withdrawal of 500 SOL to Address X

Analysis: The 09:30 withdrawal is likely Alice's.
Few deposits occurred between her deposit and this withdrawal.

Even with arbitrary amounts, the temporal relationship between deposits and withdrawals leaks information.

Why Pedersen Commitments Resist Correlation

With Pedersen commitments, amounts are cryptographically hidden - not statistically hidden:

Commitment = amount × G + blinding × H

Two commitments:
C1 = 1,234.56 × G + r1 × H
C2 = 1,234.56 × G + r2 × H

For an observer: C1 and C2 look completely different
(because r1 ≠ r2, the random blinding factors differ)

Even if Alice and Bob commit to the same amount, their commitments are indistinguishable from commitments to any other amount. There is no statistical fingerprint to correlate.

The Fundamental Difference

Attack	Pool Mixing Defense	Pedersen Defense
Amount correlation	Statistical (depends on pool size)	Cryptographic (mathematically hidden)
Timing correlation	Requires delay, reduces UX	Not applicable (no pool entry/exit)
Graph analysis	Breaks with mixing	Not applicable (stealth addresses)

Pedersen commitments provide information-theoretic hiding - even with unlimited computing power and perfect knowledge of the system, the amount cannot be extracted from the commitment alone.

When to Use What

Pool Mixing (Privacy Cash, Tornado) is great when:

• You need simple deposit/withdraw privacy
• You’re on a single chain (Solana or Ethereum)
• The pool has sufficient participation
• You want battle-tested, simpler cryptography

Pedersen Commitments (SIP) excels when:

• You need provable amount properties (range proofs, balance verification)
• You’re building cross-chain applications
• You need privacy guarantees independent of adoption
• You want stealth addresses for recipient privacy

Security Analysis: Pool Mixing Risks

While Privacy Cash has advanced beyond classic Tornado Cash, pool-based privacy carries inherent risks that cannot be fully mitigated.

Anonymity Set Degradation

The privacy of pool mixing depends entirely on the anonymity set - the crowd you are hiding in. This creates several vulnerabilities:

1. Small Pool Problem

If a pool has 10 participants:
- Your anonymity is 1 in 10
- Statistical analysis can narrow this further

If a pool has 10,000 participants:
- Your anonymity is 1 in 10,000
- Much harder to correlate

New pools, niche assets, or low-activity periods reduce anonymity sets significantly.

2. Pool Fragmentation Privacy Cash supports arbitrary amounts, but this fragments the anonymity set:

Users depositing ~100 SOL: 500 users
Users depositing ~1000 SOL: 50 users
Users depositing ~10000 SOL: 5 users

A whale depositing 50,000 SOL might be unique in their cohort.

3. Time-Based Degradation

Day 1: Pool has 1000 deposits, strong anonymity
Day 30: Most have withdrawn, only 50 remain
Day 90: Only hardcore users remain, pattern emerges

Long-term holders become increasingly identifiable as the active set shrinks.

Blockchain Analysis Countermeasures

Chain analysis firms (Chainalysis, Elliptic, TRM Labs) have developed sophisticated techniques against pool mixing:

Heuristic Clustering

Assumptions attackers exploit:
- Same user often deposits and withdraws similar amounts
- Deposits and withdrawals cluster temporally
- Users have patterns (time of day, gas prices paid)

Graph Analysis

Pre-pool: Track all addresses that deposit
Post-pool: Track all addresses that withdraw
Cross-reference: Behavioral patterns, dust attacks, timing

Probabilistic Deanonymization Instead of proving “Alice = Withdrawal X,” assign probabilities:

Withdrawal to 0xABC is likely from:
- Deposit 0x123: 40% probability
- Deposit 0x456: 30% probability
- Deposit 0x789: 20% probability
- Unknown: 10% probability

For regulatory purposes, 40% may be enough for investigation.

Compliance Mechanisms: Strengths and Weaknesses

Privacy Cash added compliance features, but they have limitations:

Auditor Keys

• Strength: Provides authorized disclosure path
• Weakness: All-or-nothing per transaction (no partial disclosure)
• Weakness: Auditor learns full history if they have the key

AML/KYT Integration

• Strength: Can block known bad actors
• Weakness: Relies on external risk scoring
• Weakness: Does not prevent novel attacks

Selective Disclosure

• Strength: User can prove specific transactions
• Weakness: Cannot prove “I did NOT do something”
• Weakness: Disclosure scope is per-transaction, not time-bounded

SIP’s Architectural Advantages

SIP’s approach avoids these pool-specific risks:

Risk	Pool Mixing	SIP Protocol
Small anonymity set	Vulnerable	Not applicable (no pool)
Pool fragmentation	Vulnerable	Not applicable
Time degradation	Vulnerable	Not applicable
Graph analysis	Partially vulnerable	Stealth addresses break graphs
Timing attacks	Requires artificial delays	No entry/exit timing
Amount correlation	Statistical defense	Cryptographic defense

The fundamental difference: SIP’s privacy is deterministic (guaranteed by cryptography), while pool mixing privacy is probabilistic (depends on usage patterns).

Conclusion

Pool mixing and Pedersen commitments solve privacy differently. Pool mixing has evolved beyond fixed denominations, and protocols like Privacy Cash have added compliance features. The “Tornado bad, Pedersen good” narrative oversimplifies reality.

The real question is: Do you want crowd-based anonymity or mathematical hiding?

SIP Protocol chose mathematical hiding because:

1. Privacy guarantees don’t depend on pool size
2. Homomorphic properties enable richer proofs
3. Chain-agnostic design fits our vision of universal privacy

Both approaches have their place. We’re building the cryptographic primitive layer that makes privacy a default, not an afterthought.

---

Next up: Deep-dive into Pedersen commitment mathematics and range proofs.