FAQ
General
Is Lateo like Tornado Cash?
No. Tornado Cash had no compliance mechanism — anyone could deposit and withdraw anonymously. Lateo uses Association Set Providers (ASPs), the same model Vitalik Buterin co-authored in the Privacy Pools paper . Only verified participants can use the pool.
Can I use Lateo with any x402 service?
Yes. Lateo works with any x402-compatible service. The service doesn’t need to know about Lateo — it just receives USDC payments as normal.
How is this different from just using a shared wallet?
A shared wallet provides sender anonymity (payments come from one address) but no cryptographic guarantees. Anyone controlling the wallet can see everything. Lateo adds:
- ZK proofs that bind deposits to withdrawals without revealing the link
- On-chain nullifiers that prevent double-spending independently of the operator
- ASP compliance proofs
- Encrypted storage so even the operator can’t easily access raw data
What’s the anonymity set?
The anonymity set equals the number of participants in the pool. More agents depositing = stronger privacy for everyone. For deposits/withdrawals, the anonymity set is cryptographic (ZK-backed). For payments, it’s operational (batch-backed).
Technical
Why Groth16 and not PLONK or STARKs?
Groth16 has the smallest proof size (256 bytes) and fastest verification time (~3ms). Stellar Protocol 25 provides native BN254 host functions that make Groth16 verification efficient on-chain. STARKs would require custom verification logic that’s more expensive.
Why server-side proving instead of client-side?
Server-side proving is simpler to implement and doesn’t require users to download the 7.7 MB proving key. Client-side proving is on the roadmap — the WASM prover already compiles to WebAssembly.
Can the operator steal my funds?
The operator signs withdrawal transactions but cannot generate valid ZK proofs without your notes (amount + blinding). However, the operator controls the pool wallet and could theoretically make direct SAC transfers. FROST MPC (2-of-3 threshold signatures) is planned to eliminate this risk.
What happens if the proxy goes down?
Your funds are safe on-chain in the pool contract. The proxy stores your notes (encrypted) in SQLite. If the proxy restarts, it reconstructs the Merkle trees from on-chain events and loads agent state from the database. No data is lost.
What’s the maximum pool size?
The current Merkle tree supports 1,024 commitments (10 levels). This can be increased by deploying a new pool contract with a deeper tree.
Privacy
What can an on-chain observer see?
- That the pool contract exists
- Aggregate deposit/withdrawal volume
- Payment destinations (x402 services) and amounts
- Timing of transactions
What can an on-chain observer NOT see?
- Which agent made which payment
- Which deposit funds which withdrawal
- Individual agent balances
- Agent wallet addresses in payment transactions
- Query content or search terms
What can the proxy operator see?
The operator can see agent identities, balances, and payment requests. This is the main trust assumption. Encrypted storage protects data at rest, but the active operator processes requests. Client-side proving (roadmap) will eliminate this.