u402 — Private Agent Payments
A compliance-ready, post-quantum private payment protocol for AI agents — extending x402 with zero-knowledge proofs.
u402
u402 extends the x402 protocol with private payments. Where x402 uses plaintext EIP-3009 signatures that expose sender, recipient, and amount on-chain, u402 replaces the signature with a zero-knowledge proof — the proof itself is the payment authorization.
Why u402?
AI agents make payments programmatically, at high frequency, to many services. On a public blockchain, this creates a complete map of every agent's:
- Vendor relationships — which APIs, data providers, and services it uses
- Spending patterns — budget, frequency, price sensitivity
- Operational activity — when it's active, what it's working on
u402 eliminates this leakage. Payments settle through the Universal Private Pool (UPP), where a ZK proof proves the payment is valid without revealing who paid.
How It Compares
| x402 | b402 (ClawPay) | z402 (Zcash) | u402 | |
|---|---|---|---|---|
| Privacy | None | Railgun-based | Zcash shielded | Privacy pool + ZK |
| Open spec | Yes | No (proprietary) | Yes | Yes (x402 v2 plugin) |
| Key handling | Client-side signing | Private key sent to server | Client-side | Client-side proof generation |
| Compliance | None | None | None | ASP proofs built into ZK circuit |
| Audit trail | Public chain | None | None | Viewing keys (selective disclosure) |
| Post-quantum | No | No | No | Yes (circle-stark proof system) |
| Token support | Any ERC-20 | Railgun tokens | ZEC | Any ERC-20 in UPP pool |
The Core Insight
UPP's transfer() and withdraw() functions don't check msg.sender. They verify a ZK proof. This means the proof itself is the payment authorization — a server can settle the payment on-chain without ever touching the client's private keys.
Agent Server (x402) Pool Contract
│ │ │
│ GET /api/data │ │
│──────────────────────────────────→ │ │
│ │ │
│ 402 + PaymentRequired │ │
│ { scheme: "private", ... } │ │
│←────────────────────────────────── │ │
│ │ │
│ Generate ZK proofs client-side │ │
│ (keys never leave the agent) │ │
│ │ │
│ Retry with Payment header: │ │
│ { proofs, nullifiers, ... } │ │
│──────────────────────────────────→ │ │
│ │ Verify proof format │
│ │ Check amount >= required │
│ │ Submit proofs to pool │
│ │──────────────────────────────→ │
│ │ │
│ │ ← tx receipt │
│ 200 OK + data │ │
│←────────────────────────────────── │ │Pluggable Proof Systems
u402 is proof-system agnostic. The proofSystem field in the payment header tells the server which verifier to use:
| Proof System | Curve | Security | Proof Size | Gas | Post-Quantum |
|---|---|---|---|---|---|
plonk | BLS12-381 | 128-bit | ~1.4 KB | ~200-250K | No |
circle-stark | M31 | 128-bit | ~5 KB | ~20M | Yes |
Both are supported by the same pool contract — transfer() / withdraw() for PLONK, transferSTARK() / withdrawSTARK() for Circle STARK. PLONK and STARK notes live in separate Merkle trees but the protocol handles both transparently.
Agents that choose circle-stark get protection against "harvest now, decrypt later" quantum attacks on their payment history.
Next Steps
- Protocol Specification — full format definitions, verification algorithm, settlement flow
- Quickstart — integrate u402 into your server and client
- Security Model — what's private, what's public, threat model
- x402-upd-starter — reference implementation with both x402 and u402 support