Security Model
Privacy guarantees, threat model, and post-quantum considerations for u402 private agent payments.
u402 Security Model
What's Private
| Property | Protected | How |
|---|---|---|
| Payer identity | Yes | ZK proof doesn't reveal which note was spent |
| Payment history | Yes | Nullifiers can't be linked to deposits |
| Shielded balance | Yes | Only the withdrawal amount is revealed |
| Agent-service relationship | Yes | On-chain: pool → service, not agent → service |
| Note contents | Yes | Notes encrypted with AES-256-GCM |
What's Public
| Property | Visible | Why |
|---|---|---|
| Withdrawal amount | Yes | Required for ERC-20 transfer to the service |
| Service address | Yes | Must be the recipient of the withdrawal |
| That a payment happened | Yes | On-chain transaction is visible |
| Pool contract | Yes | The pool address is in the Payment-Required header |
| Token type | Yes | The ERC-20 address is a public parameter |
Threat Model
Passive On-Chain Observer
An observer monitoring the pool contract sees:
- A note was transferred (new commitments inserted)
- A withdrawal was made to the service address for a specific amount
- They cannot determine which deposit funded the withdrawal
- They cannot link the transfer and withdrawal to a specific agent
The size of the anonymity set equals the number of unspent notes of the same token in the pool. More pool activity = stronger privacy.
Malicious Server
The server receives the ZK proofs but learns only:
- The payment amount
- That a valid proof was submitted
- The nullifiers (which reveal nothing about the payer without the pool's full note history and decryption keys)
The server cannot extract the payer's identity, viewing key, or remaining balance from the proofs.
Malicious Relayer / Gas Payer
The entity that submits the proofs on-chain (typically the server or a paymaster) sees the same public inputs as any on-chain observer. The pool contract's functions are permissionless — msg.sender is not checked, only the ZK proof.
Key Compromise
If an agent's spending key is compromised:
- The attacker can spend the agent's shielded notes
- Past transactions remain private (nullifiers can't be reversed)
- The agent should spend remaining notes to a new key immediately
If an agent's viewing key is compromised:
- The attacker can see the agent's transaction history for the disclosed notes
- The attacker cannot spend funds
- Viewing keys are per-note, so only disclosed notes are affected
Comparison: u402 vs ClawPay Key Handling
| ClawPay (b402) | u402 | |
|---|---|---|
| Where proofs are generated | Server-side | Client-side |
| Does the server see the private key? | Yes — sent over HTTPS | No — only ZK proofs sent |
| Trust model | Trust the server | Trustless — proof is self-contained |
| Server compromise impact | All agent keys exposed | No key material to extract |
| Key storage | Server memory (or enclave) | Agent's local environment only |
Post-Quantum Security
PLONK (BLS12-381)
PLONK proofs over BLS12-381 provide 128-bit classical security. They are not quantum-resistant — a sufficiently large quantum computer running Shor's algorithm could break the discrete logarithm assumption on the BLS12-381 curve.
Harvest-now-decrypt-later risk: PLONK proofs published on-chain embed elliptic curve points. These are permanent records that become vulnerable when quantum computers reach sufficient scale.
Circle STARK (M31)
Circle STARK proofs rely only on hash collision resistance (Keccak-256). They are quantum-resistant — Grover's algorithm halves the security level, but 128-bit hash security remains at 64-bit quantum security, which is above practical attack thresholds.
Recommendation for high-value or long-horizon agents: Use proofSystem: "circle-stark" to protect payment history against future quantum attacks. The gas cost is higher (~20M vs ~250K), but the privacy guarantee is permanent.
Migration Path
Agents can freely switch between plonk and circle-stark by shielding into the respective Merkle tree. Notes in the PLONK tree and STARK tree are independent — there is no need to migrate existing notes.
Compliance and Viewing Keys
ASP Compliance
Every u402 payment includes an ASP membership proof in the ZK circuit. This proves the original deposit address is in the specified ASP's allowlist without revealing which address.
Servers set their compliance requirements via the aspId field. An aspId of 0 with isRagequit: true bypasses compliance — the agent withdraws to their original deposit address.
Selective Disclosure
Agents can export viewing keys for specific notes to prove transactions to auditors, accountants, or regulators. A viewing key reveals:
- Amount, token, timestamp
- Proof of receipt or payment
It does not reveal:
- Other notes or transactions
- Spending key
- Remaining balance
- Counterparty identities (unless the disclosed note's metadata contains it)
This allows agents to maintain privacy by default while satisfying audit requirements on demand.