# zkSnip — Addressless Private Payments > zkSnip is a privacy payment protocol that eliminates wallet addresses entirely, replacing them with short-lived, human-shareable claim codes called "snips." It prevents transaction graphs from forming at the protocol level rather than obfuscating them after the fact. Website: https://zksnip.com Contact: hello@zksnip.com Architecture Paper (PDF): https://zksnip.com/architecture.pdf ## What zkSnip Is zkSnip is a privacy payment protocol built on three mutually reinforcing structural properties: 1. **Addresslessness (Mutual Address Blindness):** Persistent wallet addresses are eliminated. Value is transferred via short-lived claim codes ("snips") instead of identity-bearing endpoints. The sender never learns the recipient's address, the recipient never learns the sender's address, and no reusable identifier is exposed on-chain. No transaction graph can accumulate over time. 2. **Privacy as Yield-Bearing Infrastructure:** Protocol fees are converted into active cover traffic via veil amplification, increasing the veil multiplier k as usage grows. Privacy compounds with participation rather than degrading under load. Anonymity is economically reinforced infrastructure, not a fixed-cost feature. 3. **Selective Compliance Without Surveillance:** Optional, proof-based enforcement of rules without identity disclosure. Transactions may carry zero-knowledge attestations (e.g., membership in an allowed set, non-membership in a deny list) without revealing identity, transaction history, or counterparties. Compliance state is encoded via cryptographic accumulators whose updates are proven correct by a decentralized operator set. zkSnip is explicitly not a mixer. It suppresses correlation at graph formation rather than relying on delayed withdrawal or address reuse. ## How It Works ### Deposit Flow A sender deposits funds into a shielded pool, generates a secret and a voucher hash, and stores an encrypted payload on the Payload Availability Layer (PAL). The sender then shares a short-lived snip code off-chain (e.g., via messaging, email, or link) with the recipient. On-chain observers see only the voucher hash. ### Claim Flow The recipient uses the snip code to derive a decryption key, retrieves and decrypts the payload from PAL, computes a nullifier to prevent double-spend, and produces a zero-knowledge proof of inclusion and non-spend. Upon verification, funds are released to the recipient's address, and k veil amplifiers emit k indistinguishable cover transactions simultaneously. External observers see k+1 identical events and cannot determine which is real. ### Bidirectional Anonymity Uncertainty is expanded at both entry and exit points. Deposits are obscured via batched state transitions, amount bucketing, and protocol-injected decoy commitments. Claims are protected via veil amplification. An adversary must succeed in correlating both deposit and withdrawal events — imposing a multiplicative cost on linkage attacks. ## Core Architecture Components - **Shielded Pool:** Holds user funds inside a privacy set. - **Voucher Manager:** Tracks voucher commitments, Merkle roots, nullifiers, and expiry. - **Payload Availability Layer (PAL):** Off-chain availability layer for encrypted, unlinkable payloads required for snip redemption. PAL stores only client-encrypted, content-addressed payloads. Compromise or censorship of PAL impacts only liveness, never privacy. - **Veil Amplifiers:** Decentralized actors emitting indistinguishable cover transactions. Selected via stake-weighted VRF. Compensated from protocol fees. Subject to slashing for non-performance. - **Selective Assurance Layer (SAL):** Decentralized predicate enforcement using ZK-verified accumulator roots. Operated by the same staked operator set that provides veil amplification. - **ZK Coprocessor:** Verifies veil amplification correctness, enforces liveness, and settles amplifier payouts atomically with claims. Live and deployed. ## Cryptographic Primitives - Commitments and Merkle trees for deposit accumulation - Nullifiers for double-spend prevention without deposit linkage - Poseidon2 (or equivalent) ZK-friendly hashing - STARK-style zero-knowledge proofs (no trusted setup, no pairing-based cryptography) - Post-quantum security: all security derives from hash-based primitives and transparent proof systems - VRF or unbiased beacon for veil amplifier selection ## Veil Amplification Details Each real claim is accompanied by k computationally indistinguishable veil transactions (k ∈ {8, 16, 32, 64, 127}, user-selectable as "veil tiers"). All k+1 transactions are validated in an aggregated proof without revealing execution order. ### Formal Unlinkability Bound For a veil tier τ with adversary controlling fraction α of bonded stake and deposit-side advantage β: Pr[de-anonymization] ≤ β · α^τ + negl(λ), where λ = 256. Example: At τ = 127, α = 1/3, β = 0.1: Pr[link] ≤ 1.8 × 10⁻⁴¹. ### Economic Flywheel Protocol fees (target: 0.20% settlement fee) → veil amplifier rewards → more amplifier participation → higher veil multiplier k → stronger unlinkability → more usage → more fees. Privacy compounds with participation. ## Selective Compliance Compliance is optional, proof-based, and enforced at the transaction level via pre-checks: - **Accumulator-based enforcement:** Allow-lists, deny-lists, jurisdictional constraints, and risk tiers are committed to cryptographic accumulators. Only roots are published on-chain. - **ZK coprocessor proving:** Heavy computation (set membership, non-membership, multi-criteria scoring) is performed off-chain and proven succinctly. - **On-chain pre-check hook:** Minimal verification step checks the proof against the latest root and reverts on failure. - **Proof types:** Membership proofs, non-membership proofs (sanctions), multi-criteria proofs (wallet age, reputation, risk), sybil/bot filtering. - **Default mode:** No pre-check (maximum privacy). Compliance is opt-in. - **Decentralized execution:** Accumulator updates are deterministic and proven correct via ZK proofs. Operators execute fixed verification logic; they do not exercise discretion. ## Use Cases - **Gifts and peer transfers:** Send value like sending a link. No address exchange, no graph formation. - **Payroll and contractor payouts:** Mutual address blindness — neither employer nor employee reveals a permanent address. - **Treasury operations and bilateral settlement:** Strategic moves without exposing long-lived endpoints. - **Institutional distribution with compliance zones:** Private by default, provable when required. - **Activists, journalists, and high-risk recipients:** Receive funds without revealing a durable identifier. ## Fee Model - Target flat 0.20% settlement fee on transferred value (governance-configurable) - Configurable fraction α of fee revenue distributed to veil amplifiers - Fee sponsorship supported (third-party payment of fees for payroll, enterprise payouts, consumer apps) - Sponsorship is represented as a separate commitment verified at claim time without linking sponsor identity to recipient identity ## Competitive Positioning Unlike Tornado-style mixers (visible entry/exit, high boundary correlation), Railgun (shielded addresses required, visible entry/exit), Zcash (optional shielded pools with visible t→z/z→t transitions), or Monero (fixed ring size of 16): zkSnip has no visible entry, no visible exit, no persistent addresses, and structurally suppressed boundary correlation. Additionally, zkSnip uses STARKs (post-quantum) rather than Groth16 or ElGamal (quantum-vulnerable). ## Implementation Status A working proof of concept validates the full end-to-end payment flow including shielded deposits, snip generation/redemption, nullifier-based enforcement, veil amplification, and selective compliance. The ZK coprocessor for privacy amplification and the selective compliance engine are live and deployed as production-grade systems, not theoretical constructs. ## Technical Paper The full architecture paper (Version 1.1, February 2026, 32 pages) is available at: https://zksnip.com/architecture.pdf It covers: protocol specification, sequence diagrams, veil amplifier economics and formal guarantees, selective compliance architecture, anonymity set growth analysis, competitive landscape comparison, attack model and assumptions, and proof of concept status.