Concepts
Privacy Model
What Siphon hides, what remains visible, and trust assumptions.
Siphon layers multiple privacy technologies. Each addresses a different leakage surface.
Privacy stack
| Technology | Role |
|---|---|
| ZK (Groth16) | Prove vault ownership without revealing which deposit was spent |
| FHE (tfhe-rs) | Compare encrypted trigger prices to live oracle data |
| AES-GCM | Encrypt note secrets at rest on the trade executor |
| Wallet signatures | Derive encryption keys and authenticate API requests |
What stays private
- Which deposit a withdrawal came from (transaction-graph privacy within the pool)
- Strategy trigger prices and bounds (FHE-encrypted; client key in browser)
- Note nullifiers and secrets until spend time
What is visible
- Vault liquidity and Merkle root updates
- Nullifier hashes when notes are spent
- Recipients and swap parameters bound in the ZK proof public signals
- Timing and gas patterns (metadata leakage)
Trust assumptions
| Component | Assumption |
|---|---|
| Browser | Holds secrets; compromise exposes notes |
| Trade executor | Sees encrypted payloads and timing; cannot decrypt FHE bounds without client key |
| Smart contracts | Sound Groth16 verification; owner can pause deposits (not withdrawals) |
| Oracle (Pyth) | Accurate prices for trigger evaluation |
Privacy limits
Siphon provides pool-style privacy, not absolute anonymity. Correlation via timing, amounts, and public withdrawal addresses is still possible. The threat model assumes adversaries observing chain state — not broken cryptography.