Proof of Innocence (Association Set Proofs)

Components

• Shielded pool contract that stores deposit commitments and nullifier sets.
• Zero-knowledge proof verifier that checks Merkle-branch statements against set roots.
• Set providers that publish curated set roots. Two models:
  • Association-set providers publish flexible, jurisdiction-specific sets. Sets can be inclusion-based ("low-risk deposits permitted"), exclusion-based ("all except sanctioned"), or hybrid.
  • Blocklist providers publish exclusion-based lists of flagged addresses and transactions (for example, sanctions-oracle feeds).
• Data-availability path for the full set data (IPFS or off-chain storage with on-chain integrity anchors).
• Proof-inheritance tracker (deposit-side variant) that carries forward the proof status of a commitment through intermediate transfers.

Protocol

Two variants share the same primitive but differ in flow.

Variant A, prove at withdrawal:

1. user Deposit tokens into a shielded pool; the contract stores a commitment in the global Merkle tree.
2. operator Set providers publish curated association sets, each defined by a Merkle root over a subset of deposits.
3. user Select a set and generate a zero-knowledge proof that the deposit is in the global tree and is a member of the chosen set root, or that the deposit is not in an exclusion set.
4. contract Verify the proof against the pool root and the set root; the verifier learns neither which deposit nor when it was made.
5. user Complete the withdrawal carrying a clean compliance signal.

Variant B, prove at deposit with proof inheritance:

1. user Shield tokens into the pool contract.
2. prover Auto-generate an exclusion proof that the deposited tokens are not present in any blocklist provider's dataset.
3. contract Enforce a standby window during which the deposit may only be unshielded back to the original address; this gives list providers time to update.
4. user Subsequent shielded transfers inherit the proof status of their inputs; the tracking service records which commitments have been checked.
5. user On unshield, any external verifier can reconstruct the proof chain from initial deposit through intermediate transfers.

Guarantees & threat model

Guarantees:

• Compliance signal without surveillance: the verifier learns clean or not proven clean for a specified set, never the transaction graph.
• Deposit unlinkability: the proof does not reveal which deposit belongs to the user.
• Voluntary disclosure: the user chooses which set to prove against, avoiding a single mandatory global allowlist.
• Separating equilibrium: honest users benefit from proving; users excluded from credible sets cannot produce valid proofs against them.

Threat model:

• Set-provider integrity. A malicious or compromised provider can include or exclude specific deposits, effectively censoring users or diluting the compliance signal.
• Soundness of the zero-knowledge proof system and its trusted setup if applicable.
• Stale sets. Between set updates, newly flagged deposits still produce valid proofs.
• Small anonymity sets. Even a valid proof conveys little privacy when the set is tiny.
• Metadata such as relayer IPs, timing, and gas payer is out of scope for this pattern.

Trade-offs

• Multiple providers introduce governance and coordination overhead for relying parties that accept proofs.
• Non-provers may be treated as non-compliant, penalising users with limited compute or connectivity.
• Regulatory acceptance of exclusion proofs as equivalent to traditional screening varies by jurisdiction and is still evolving.
• Set-update cadence trades off freshness against availability: standby windows delay usable funds, while long refresh intervals widen the window in which newly flagged deposits remain provable as clean.

Example

A user withdraws from a shielded pool to an institutional exchange. The exchange requires proof of non-association with sanctioned addresses. The user generates a zero-knowledge exclusion proof against the relevant set and submits it with the withdrawal. The exchange verifies the proof, accepts the deposit, and never learns which deposit the user made or when.

See also

• Privacy Pools paper (Buterin et al. 2023)
• Vitalik on Privacy Pools