advanced

Threat Model

Adversarial assumptions and security guarantees

Overview#

Mini Veil is designed to protect sender and recipient privacy against a motivated adversary with full visibility of the Solana ledger. This document defines the threat model, adversarial assumptions, and the protocol's security boundaries.

Adversarial Capabilities#

We assume an adversary with the following capabilities:

| Capability | Details | |---|---| | Full ledger visibility | Can observe all transactions, accounts, and events on Solana | | Network monitoring | Can observe RPC traffic, IP addresses (but not break TLS) | | Computational bounds | Cannot break discrete log, Poseidon collision resistance, or SHA-256 preimage resistance | | Sybil attacks | Can create arbitrary number of wallets and deposit into the pool | | Timing analysis | Can observe transaction submission timestamps |

We do not assume the adversary can:

  • Break the BN254 pairing security
  • Extract information from the proving process (client-side snarkjs)
  • Corrupt the trusted setup ceremony
  • Access the user's local machine or browser state

Privacy Guarantees#

Sender Privacy#

The adversary cannot determine which deposit corresponds to a given withdrawal.

Why: The ZK proof reveals only the Merkle root, nullifier hash, recipient, and denomination. Without the witness (spending key, counter, secret, Merkle path), the adversary cannot link the proof to any specific leaf.

Boundary: If the anonymity set is small (e.g., only 1 deposit in the pool), the adversary can trivially link deposit and withdrawal. Privacy increases with pool usage.

Recipient Privacy#

The adversary observing a withdrawal cannot determine the ultimate recipient's wallet address.

Why: The withdrawal sends funds to a one-time stealth address. Only the intended recipient can detect and claim from this address. There is no on-chain link between the stealth address and the recipient's public wallet.

Boundary: When the recipient claims the stealth payment, the claim transaction reveals the stealth address and the destination wallet. An adversary monitoring the recipient's wallet could observe the claim. However, the claim can be delayed arbitrarily, and the adversary cannot retroactively link the withdrawal to the recipient without also monitoring the claim transaction.

Amount Privacy#

The adversary cannot determine the amount of a specific private transfer beyond the denomination.

Why: All withdrawals from a given denomination pool are for the same amount. The circuit constrains the withdrawal to match the denomination.

Boundary: The denomination is public. An observer can determine that a withdrawal was for 0.1, 1, or 10 SOL.

Attack Vectors#

| Attack | Feasibility | Mitigation | |---|---|---| | Nullifier collision | Negligible (2⁻²⁵⁴ per pair) | Counter ensures uniqueness per key; random secret prevents cross-key collisions | | Merkle root forgery | Requires 2-of-3 oracle signatures | Multisig prevents single-party root control | | Stealth address collision | Negligible (2⁻²⁵⁴ per pair) | 254-bit ephemeral key entropy | | View tag brute force | 2¹⁶ possible values, ~99.8% filtering rate | View tag only for quick rejection; full scan required for confirmation | | Deposit linkability via IP | High (IP visible to RPC) | Out of scope — use Tor, VPN, or private RPC | | Sybil attack on anonymity set | Feasible (adversary can deposit) | Anonymity set is all unspent deposits; sybil deposits increase set size | | Relayer censorship | Moderate | Multiple independent relayers; permissionless design | | Trusted setup toxic waste | Catastrophic if leaked | Powers of Tau ceremony with multiple participants |

Non-Goals#

The following are explicitly out of scope for Mini Veil's security guarantees:

  1. Network-level privacy. IP addresses may be visible to RPC nodes. Use Tor or a private RPC endpoint.
  2. Wallet-level privacy. The sender's wallet connection and transaction signing may leak metadata.
  3. Timing correlation. If a user shields and immediately unshields, timing analysis may suggest linkage. Best practice: delay withdrawals.
  4. Front-running protection. Validators could reorder transactions. The protocol does not provide ordering guarantees.
  5. Quantum resistance. All cryptography is classical. Post-quantum security is not addressed.

Recommendations for Users#

  1. Use a private RPC endpoint. Avoid exposing your IP to public RPC nodes.
  2. Delay withdrawals. Wait for multiple deposits to accumulate before withdrawing, increasing the anonymity set.
  3. Drain stealth addresses promptly. After claiming, move funds to a fresh wallet.
  4. Maintain wallet security. Key loss is irreversible. Use hardware wallets when possible.
  5. Monitor the nullifier set. If your nullifier is spent without your knowledge, your spending key may be compromised.