Compliance Considerations

Lateo implements the Privacy Pools compliance model, designed to provide privacy without enabling illicit use.

Association Set Providers (ASPs)

ASPs maintain on-chain Merkle trees of approved participants. Every ZK proof must include a membership proof demonstrating the prover is in the approved set.

ASP Membership Tree: Binary Merkle tree. A leaf is inserted when an agent registers.
ASP Non-Membership Tree: Sparse Merkle tree. Proves the prover is NOT in the excluded set.

The pool contract verifies both proofs during transact(). If the prover is not in the membership set or IS in the exclusion set, the transaction reverts.

What compliance officers need to know

Question	Answer
Can bad actors use the pool?	No — ASP membership is required for every transaction
Can regulators see individual transactions?	Not by default. View keys can be implemented for selective disclosure.
Is this like Tornado Cash?	No. Tornado Cash had no compliance mechanism. Lateo uses ASPs — the same model Vitalik Buterin co-authored specifically to address regulatory concerns.
Who manages ASP membership?	The pool operator (admin). In production, this would be a governance process.
Can a participant be removed?	Yes — the admin can update the ASP trees to exclude participants.
What data does the operator store?	Agent notes (encrypted with AES-256-GCM), balances, and ZK state. No plaintext private keys.

Post-Tornado Cash regulatory context

After the Tornado Cash sanctions (2022), the crypto industry needed a privacy model compatible with regulation. Privacy Pools provide this:

Separating equilibrium: Honest users can prove their funds don’t originate from illicit sources. Bad actors cannot.
Association Sets: Curated by ASPs who verify participant legitimacy.
Coinbase Ventures backed this model: $3.5M investment in 0xbow (Privacy Pools on Ethereum).

Lateo brings this exact architecture to Stellar.