Privacy Model
This page documents exactly what Lateo hides, what it reveals, and what the trust assumptions are. This is the page your security team should read first.
What an on-chain observer sees
| Data | Visible? | Details |
|---|---|---|
| Pool contract address | Yes | Public — anyone can see the pool exists |
| Total pool volume | Yes | Sum of all deposits/withdrawals |
| Commitment hashes | Yes | Opaque 256-bit values — amount and owner are hidden |
| Nullifier hashes | Yes | Opaque 256-bit values — which commitment was spent is hidden |
| Payment destinations (services) | Yes | x402 service addresses are visible |
| Payment amounts | Yes | Individual payment amounts to services |
| Batch timing | Yes | Payments within a batch window are grouped |
What an on-chain observer does NOT see
| Data | Why it’s hidden |
|---|---|
| Which agent made which payment | Payments come from pool wallet, not individual wallets |
| Which deposit funds which payment | ZK proof breaks the link — nullifiers are unlinkable to commitments |
| Agent wallet addresses | Never appear in payment transactions |
| Query content | Not stored on-chain (service-side only) |
| Individual balances | Only the pool’s total balance is visible |
What the proxy operator sees
This is the most important trust consideration:
| Data | Operator access | Mitigation |
|---|---|---|
| Agent identities | Yes — agents authenticate to the proxy | Encrypted in SQLite with AES-256-GCM |
| Agent balances | Yes — tracked for payment authorization | Per-field encryption with agent-specific keys |
| Payment requests (agent → service mapping) | Yes — proxy routes the request | Logs sanitized: no public keys, tx hashes, or agent IDs logged |
| ZK private keys and blindings | Yes — stored to generate proofs | Encrypted storage; planned migration to client-side proving |
| Agent notes (unspent commitments) | Yes — needed for proof generation | Encrypted; planned migration to client-side storage |
What the proxy operator does NOT see (with planned upgrades)
| Upgrade | What it removes from operator visibility |
|---|---|
| Client-side proving | ZK keys, blindings, notes — all move to client |
| FROST MPC wallet | Pool wallet control — no single party can move funds |
| Operator blindness | Agent → service mapping — proxy only sees encrypted relay requests |
Threat model
| Threat | Protected? | How |
|---|---|---|
| On-chain surveillance (competitor monitoring blockchain) | Yes | ZK proofs + batching |
| Network-level timing analysis (ISP/node operator) | Partial | Batching defeats timing; Tor can be used additionally |
| Compromised proxy operator | Partial | Encrypted storage protects at-rest data; active operator sees requests |
| Compromised proxy database | Yes | AES-256-GCM per-field encryption; master key not in DB |
| Double-spend attempt | Yes | Nullifiers verified on-chain; contract rejects duplicate nullifiers |
| Fake proof submission | Yes | Groth16 proof verified on-chain via BN254 pairing check |
| Pool drain (operator steals funds) | Partial | Pool contract requires valid ZK proof for transact(); operator CAN do direct SAC transfers (mitigated by FROST MPC in roadmap) |
Last updated on