Merkle Trees & Commitments
Understanding how Merkle trees enable private transfers
Merkle Trees & Commitments
Section titled “Merkle Trees & Commitments”The privacy mechanism relies on Merkle trees and cryptographic commitments. This page explains these concepts at a practical level.
What is a Commitment?
Section titled “What is a Commitment?”A commitment is a hash that “locks in” a value without revealing it. For private transfers, each deposit creates a commitment from two secrets:
commitment = poseidon(nullifier, secret)| Component | Purpose |
|---|---|
| nullifier | Random 32-byte value. Its hash is published on withdrawal to prevent double-spending. |
| secret | Random 32-byte value. Keeps the commitment secure even if nullifier is guessed. |
| commitment | The hash stored in the Merkle tree. Reveals nothing about nullifier or secret. |
The Merkle Tree
Section titled “The Merkle Tree”All commitments are stored in a Merkle tree - a binary tree where each node is the hash of its children:
The protocol uses depth-32 Merkle trees, supporting up to 2³² (4+ billion) deposits per token.
Why Merkle Trees?
Section titled “Why Merkle Trees?”- Efficient Proofs: Prove membership with only 32 hashes (the path from leaf to root)
- Privacy: The proof reveals nothing about which specific commitment you’re proving
- Compact Storage: Only the root hash needs to be stored on-chain
The Anonymity Set
Section titled “The Anonymity Set”The anonymity set is all deposits in the same Merkle tree. When you withdraw:
- You prove “I know the secret for one of these deposits”
- The verifier cannot determine which deposit
The larger the anonymity set, the stronger the privacy. Each Merkle tree is per-token and per-deposit-size.
Poseidon Hash
Section titled “Poseidon Hash”The protocol uses Poseidon hash function instead of SHA-256 or Keccak because:
- ZK-friendly: Much cheaper to prove in zero-knowledge circuits
- Secure: Designed specifically for ZK applications
- Efficient: Fewer constraints means faster proof generation
Your client code must use a Poseidon implementation compatible with the circuit. See the Deposit guide for reference implementations.
Practical Implications
Section titled “Practical Implications”| Concept | What It Means for You |
|---|---|
| Commitment generation | Must happen client-side for privacy |
| Secret storage | You are responsible for backing up nullifier + secret |
| Anonymity set | Wait for more deposits to increase privacy |
| Single use | Each commitment can only be withdrawn once |
Next Steps
Section titled “Next Steps”- Learn about Nullifiers and how they prevent double-spending
- Understand Why Relayers are essential for privacy
- See the Deposit Guide for implementation details