Hush Privacy Protocol
Privacy-preserving shielded transactions using Miden STARK zero-knowledge proofs
Shield, transfer, and unshield tokens with cryptographic guarantees that deposits cannot be linked to withdrawals.
Operations
Three core operations enable privacy-preserving transactions with cryptographic guarantees
Shield (Deposit)
Shielding moves tokens from Solana into the privacy pool.
Generate spending_key, derive note_secret and randomness, compute commitment
Call shield instruction - tokens transfer from wallet to program vault
Detect shield event, run CipherOwl OFAC check on shielder address
If clean, add commitment to Merkle tree, create voucher (ACTIVE immediately)
Store secrets locally for later proof generation
The shielder's Solana address is screened but not stored on zrchain - filtering happens at the sidecar.
Unshield (Withdraw)
Unshielding moves tokens from the privacy pool back to a Solana address. The ZK proof ensures the withdrawal is valid without revealing which deposit is being spent.
Load spending_key, query current Merkle root
Generate STARK proof proving knowledge of a valid commitment and correct nullifier derivation
Verify proof, check nullifier hasn't been spent, mark as spent
Create UnshieldRequest, build Solana transfer transaction
Sign transaction, sidecar broadcasts to Solana
Sidecar detects completion, updates request status
The unshield amount is visible on Solana after completion. Privacy comes from unlinkability - observers cannot determine which shield was spent.
Shielded Transfer
Transfers within the privacy pool. Amounts are encrypted - only the recipient can decrypt.
Generate ephemeral keypair, compute recipient and change commitments
Encrypt amounts using ECDH shared secret with recipient's public viewing key
Generate STARK proof, submit MsgShieldedTransfer
Verify proof, add new commitments to Merkle tree, emit event
Scan chain events, attempt ECDH decryption to find transfers addressed to them
Privacy: Transfer sender/recipient link is hidden. Amounts are fully encrypted.
Cryptographic Design
Built on Miden STARKs for quantum-resistant, trustless privacy
Why Miden STARKs
- No trusted setup (unlike Groth16/PLONK)
- Hash-based, does not rely on algebraic assumptions broken by Shor's algorithm
- Configured for ≥128-bit classical security, providing post-quantum resistance
- Native RPO hash is efficient in-circuit
Primitives
| Primitive | Implementation | Purpose |
|---|---|---|
| Hash | RPO (Rescue Prime Optimized) | ZK-friendly, native to Miden |
| Merkle Tree | Sparse binary, depth 20 | ~1M commitment capacity |
| Proof System | Miden STARKs | ZK proof generation/verification |
| Key Exchange | X25519 ECDH | Stealth addresses for transfers |
| Amount Encryption | ChaCha20-Poly1305 | Shielded transfer amounts, voucher recovery |
| Key Derivation | SHA-256 | Voucher amount encryption keys |
Comparison
How Hush compares to other privacy protocols
| Feature | Hush | Zcash | Tornado Cash |
|---|---|---|---|
| Proof System | Miden STARKs | Groth16/Halo2 | Groth16 |
| Trusted Setup | No | Yes | Yes |
| Quantum Resistant | Yes | Partial | No |
| Flexible Amounts | Yes (UTXO) | Yes | No |
| Shielded Transfers | Yes | Yes | No |
| Viewing Keys | Yes (tiered) | Yes | No |
| Wallet Recovery | Yes (Seed phrase) | Seed phrase | Manual |
| Compliance | Built-in | Optional | None |
Privacy Model
Understand what's hidden and what's public in Hush transactions
Hidden
- Link between shield and unshield
- Depositor identity
- Transfer sender/recipient link
- Shielded transfer amounts
Public
- Unshield amount (visible on Solana)
- Merkle root in proof (approximate timing)
- Nullifier (prevents double-spend)
- Recipient address (unshield only)
Maximizing Privacy
Best practices for maintaining anonymity in your transactions
Use Standard Denominations
Custom amounts make correlation easier. The UI provides standard amounts: 0.1, 1, 10, 100, 1000.
Custom amounts reduce anonymity
Wait Before Unshielding
Immediate unshield after shield creates timing correlation. Wait some time between operations.
Use Different Networks
Don't use the same IP for shield and unshield. Consider Tor/VPN for unshield operations.
Standard Denominations
Using standard amounts helps maintain anonymity by making transactions indistinguishable.
OFAC Compliance
Built-in compliance screening for all shield operations
Shield events are screened at the sidecar using CipherOwl. The shielder address is not propagated to zrchain, ensuring privacy while maintaining compliance.
Screening Process
Privacy Preserved: The shielder address is not stored on zrchain. Filtering happens at the sidecar level, maintaining the privacy guarantees of the protocol.
Key Hierarchy
Tiered viewing keys enable flexible privacy and auditing capabilities
spending_key
Root secret - never share
full_viewing_key
For auditors
incoming_viewing_key
Receive only
Key Derivation
Viewing Key Access: The nullifier formula allows full_viewing_key holders to compute nullifiers and verify spent status without spending capabilities.
Fees and Supply
Fee Structure
| Operation | Fee Type | Policy |
|---|---|---|
| Shield | Percentage | Zero (encourage pool growth) |
| Shielded Transfer | Flat | Fixed per transfer, burned |
| Unshield | Percentage | % of amount, deducted before transfer |
Supply Accounting
Every token is accounted for. Whether shielded in the pool, pending withdrawal, successfully unshielded, or burned as fees—the total remains constant and verifiable.
Supported Assets
Privacy-preserving transactions for multiple Solana assets
jitoSOL
solana/programs/hush-sol
zenBTC
solana/programs/zenbtc
zenZEC
solana/programs/zenzec
ROCK
solana/programs/rock
USDC
solana/programs/usdc