Privacy for x402

About this session

Rahul Kothari of Aztec argued that calls for private x402 skip the real work of privacy design: deciding precisely what to hide and from whom. He expected x402 traffic to run agent-to-company and company-to-agent, with no human wallet ever in the loop, and built the talk around what that setup exposes and what ought to stay hidden.

He named four things a transaction can reveal: the resource being paid, the agent doing the paying, metadata such as token type and amount, and the facilitator that settles it. He judged the resource and the facilitator safe to keep visible, since exposing them supports analytics and lets a reputation system judge facilitators by their behavior. The agent and the metadata were the two he wanted hidden. An agent's identity can expose the user behind it, and metadata like the amount transferred gives outside observers nothing useful. He then split the question by audience: the resource being paid needs to know who it is dealing with just to accept the payment, so hiding the agent from the resource defeats the purpose, while a facilitator, in his view, only needs to verify and settle, not see who is involved.

To frame the trade-offs, he laid out a spectrum: fully transparent, then anonymity (amounts visible, parties hidden), then confidentiality (parties visible, amounts hidden), then a default-private model with selective disclosure. He used Aztec, where he works, to show what default-private with optional public calls could look like, then spent more time on approximating that on a public chain like Base, which he said is where most actual x402 activity already happens. His suggestions there included routing many agents through one shared entry point to obscure which user triggered a payment, stealth addresses (which he flagged as weak at scale because of address proliferation), and depositing into privacy pools such as Railgun or 0xbow, or wrapping funds in an FHE token from Zama to hide a recipient or an amount. Each option had its own cost: privacy pools require pre-funded balances, stealth addresses require a constant supply of new addresses, and holding funds still to gain privacy runs into the latency that fast payments cannot tolerate.