How Zero-Knowledge Proofs Break the Deposit-Withdrawal Link On-Chain

AnonGate — Thu, 10 Sep 2026 17:55:12 +0000

Public blockchains are transparent by design — every deposit, withdrawal, and balance is visible to anyone who looks. That's great for auditability, but it means your entire transaction history is permanently linked to your wallet address. For developers building anything involving payroll, treasury management, or simple user privacy, that's a real constraint.

Here's how one approach — used in AnonGate's shielded pool — solves this using zero-knowledge proofs.

The Core Problem

If you deposit funds into a contract and withdraw them later, even to a different address, on-chain analysis can usually link the two transactions — timing, amounts, and address clustering heuristics make deanonymization straightforward in most naive implementations.

To break that link cryptographically (not just obfuscate it), you need a way to prove "I deposited into this pool" without revealing which deposit you're referring to.

Merkle Trees + Groth16 Proofs

The architecture uses two main components:

Commitment generation on deposit

When a user deposits, the contract generates a cryptographic commitment and appends it as a leaf to an on-chain Merkle tree:

commitment = Poseidon(secret, nullifier)

Poseidon is used here instead of something like SHA-256 because it's optimized for zk-SNARK circuits — dramatically cheaper to prove and verify inside a circuit.

Withdrawal via zero-knowledge membership proof

On withdrawal, instead of revealing which leaf in the tree corresponds to their deposit, the user generates a Groth16 proof demonstrating:

They know a (secret, nullifier) pair that hashes to some leaf in the tree
That leaf hasn't been spent before (via a nullifier hash check, preventing double-spends)
All of this, without revealing which specific leaf it is

The contract only needs to verify the proof and check the nullifier hasn't been used — it never learns which deposit maps to which withdrawal.

Why Groth16 Specifically

Groth16 is used over newer proof systems mainly for verification cost. On Ethereum, gas costs matter a lot, and Groth16 proofs are small (three group elements) and cheap to verify on-chain compared to alternatives like PLONK or STARKs — the tradeoff being a trusted setup requirement per-circuit, which is a known and accepted limitation in most current shielded pool implementations.

Practical Notes for Implementers

If you're experimenting with this pattern yourself:

Nullifier design matters — reusing the same nullifier derivation across pools/assets can leak information
Merkle tree depth is a tradeoff between anonymity set size and proof generation time
Multi-asset pools (e.g. supporting ETH, DAI, LUSD) need careful handling of denomination-based anonymity sets — mixing pool sizes across assets can reduce the effective privacy set for less-used assets
Closing Thoughts

Zero-knowledge shielded pools aren't a new idea, but the combination of Poseidon (circuit-efficient hashing) and Groth16 (cheap on-chain verification) remains a practical, gas-conscious pattern for anyone building privacy-preserving transaction systems on Ethereum today.

If you're curious about a live implementation of this pattern, AnonGate has this running on mainnet: anongate.io

DEV Community: AnonGate

How Zero-Knowledge Proofs Break the Deposit-Withdrawal Link On-Chain