How agents pay without leaking your business

You are building agent products. Or you sell APIs to agents. Either way, your product touches an autonomous wallet that pays for things: data feeds, model calls, settlement fees, third-party services. Many times a day. Every day. Forever.

Every one of those payments lands on a public ledger. Each receipt names a vendor, a price, a timestamp, and the wallet that paid. After a month, anyone with a block explorer can map your entire operational stack: which APIs you depend on, what they cost you, when your agents are active, and which customers they serve.

You set out to settle a 0.001 EUR API call. You accidentally published your business model.

Meet Sofia.

1. The story

Sofia Marek runs a robo-advisor in Vienna called Stillwater Capital. Three people in a co-working space near the Stadtpark. Eighteen months of operating history. A MiFID II licence on file with the Austrian Financial Market Authority. About 1,200 retail customers across Austria, Germany, and Switzerland. Average portfolio: 8,000 EUR.

Stillwater does one job. It manages small, diversified portfolios of tokenised securities on chain: tokenised equity (the kind of regulated raise we already met in part 2, where Lukas bought into his Swiss supplier), tokenised bond ETFs, and tokenised money-market fund shares for the cash sleeve. Every customer signs the MiFID II suitability questionnaire when they sign up. Every customer is KYC'd through BlockReg, the same Austrian B2B registrar that handled Lukas's transaction. Every customer's KYC sits as one leaf in BlockReg's association set, the regulated equivalent of a member list on chain.

The advisor itself is one AI agent per customer.

Each agent reads its own customer's risk profile and investment horizon, then runs all day. It subscribes to live price feeds for the tokenised assets in the customer's universe. It pulls macroeconomic signals from a research vendor. It reads news-sentiment scores from a second vendor, volatility forecasts from a third. It decides whether to rebalance. When it does, it executes the trade on chain against the relevant tokenised security contract.

Every signal call, every data fetch, every trade, every settlement: a payment. Stillwater pays per call. It does not buy bulk subscriptions, because each customer's information needs differ and bulk pricing for a 1,200-account boutique would burn the margin. The agents pay vendors directly, through a payment protocol called x402.

A typical day for one customer's agent: about twenty payments to vendors, plus a small number of trade-execution and settlement fees. With 1,200 customers, Stillwater's agent infrastructure settles around 30,000 micropayments per day on chain. Each one names a vendor, an amount, and a timestamp.

One Monday morning, Sofia opens her own block explorer.

There it is. Stillwater's last 24 hours. A column of 30,000 transactions, each linked to one of about fifty vendor addresses. The vendors are labelled by anyone who paid attention: acmedata.eth, macrosignals.eth, volforecast.eth, newsmood.eth. A handful of trade-execution events against tokenised equity contracts. Gas fees to a relayer.

Sofia can read the entire shape of her business off her own wallet in thirty seconds. So can anyone else.

2. The two leaks

The first thing Stillwater accidentally publishes is what its customers own.

Customer holdings leak. Each agent's trades are public. Watch one agent's wallet for a week and you have one customer's full portfolio: which tokenised equities they hold, in what weights, with what cash buffer, reacting to which market events at which speed. Watch the agent for a month and you have a behavioural profile. Repeat across 1,200 agents and you have 1,200 retail-investor profiles, indexed by some quasi-identifier the agent uses to fund itself. None of them consented to this. GDPR's data-minimisation principle says firms should publish no more personal data than necessary. Stillwater currently publishes everything by default.

The second leak is the strategy.

Strategy leak. Stillwater's edge, what makes the platform worth a management fee, is the combination of signals it weights and the thresholds it acts on. Which research vendor does the agent trust for macro? Which one does it down-weight after a missed call? Which volatility forecast wins when they disagree? How quickly does the agent rebalance after a 3% drawdown versus a 5%? Sit on a block explorer for a month and you can answer every one of those questions for the cost of the same vendor subscriptions Stillwater pays. The day Stillwater goes from boutique to noticeable, three competitors will be quietly cloning the model.

Note who can do this. It is not a sophisticated nation-state adversary or a TLA agency with a warrant. Any competent analyst with a block explorer and a free week can pull the trick. The data is public. The vendors have publicly known addresses. The trades are public. The links are public. There is no break-in to make, no key to compromise.

The trap is not that Stillwater built something dangerous. The trap is the same one Lukas's chocolatier transaction hit in part 2: the chain is a permanent loudspeaker, and you have to be careful with it forever, across every customer and every transaction.

3. What x402 is

A quick interlude on the protocol the agents speak.

x402 is an HTTP-level payment protocol. It uses the long-dormant HTTP status code 402 (Payment Required) that was reserved in the original HTTP specification but never given a real meaning. Coinbase published a working scheme in 2025.

The flow is short. The agent makes a request:

GET /api/macro-signal/eur HTTP/1.1

The server replies:

HTTP/1.1 402 Payment Required
X-Payment: scheme=exact, network=base, asset=0xEURC,
           amount=1000, recipient=0xAcmeData

The agent signs an EIP-3009 transferWithAuthorization over those terms. The signature is off-chain, no gas, no key sent to the server. It retries:

GET /api/macro-signal/eur HTTP/1.1
X-Payment-Signature: 0x...

The server checks the signature, settles the transfer on chain, returns the data. Per-call payment, no API keys, no accounts, no login, no monthly bill.

It is a clean protocol for agent-to-API plumbing. It has one design property that becomes a problem at Stillwater's scale: every settled payment is a public transaction. The whole point of x402 is on-chain settlement, and the whole problem with on-chain settlement is that everyone can read it.

x402 is the right HTTP protocol. The wrong settlement layer.

4. The naive workarounds

Sofia, like Lukas in part 2, will spend a weekend thinking about clever fixes. Each one fails for the same kind of reason.

One wallet per customer. Spin up 1,200 sub-wallets. Each agent uses its own. Looks better at first. But each sub-wallet has to be funded. The funding comes from Stillwater's master wallet. The funding pattern itself links every sub-wallet back to Stillwater, and the time-of-day funding bursts cluster by customer cohort. An hour with the data and the link is rebuilt.

Batched trades. Wait until end of day and aggregate all customer trades into one settlement. Loses real-time responsiveness, which is half the point of an algorithmic advisor. MiFID II best-execution rules require timely execution. And the batch itself is still public: the strategy leaks at lower temporal resolution but at higher per-trade volume, which is in some ways worse.

Off-chain via a market maker. Stillwater hires an OTC desk and sends instructions over an API. Defeats the point of tokenised securities (self-custody, atomic settlement, programmability) and reintroduces full counterparty risk. Does not help with the x402 vendor payments anyway, which are independent of trade execution.

Mixers. Will not pass BlockReg's compliance check, will not pass regulators, will not pass customer trust. Off the table.

Cycling addresses. Generate a fresh wallet for every payment. Funding still links them. Sequencing still links them. Same trap as Lukas's "fresh wallet" trick, multiplied 30,000 times a day.

The trap is the same. You have to be perfect forever, across 1,200 agents, 50 vendors, and 30,000 daily payments. One funding pattern that crosses lanes, one batch boundary that aligns with a customer cohort, one wallet that gets used twice, and the picture rebuilds itself.

You cannot scale be careful forever to thirty thousand transactions a day.

5. How private agent payments work

Stillwater's fix is not to abandon x402. It is to keep the HTTP flow exactly as it is, and to replace the on-chain settlement with a privacy-preserving one. The HTTP-level extension that does this is called u402.

Walk through what changes.

The agent calls GET /api/macro-signal/eur. The server replies with a 402 Payment Required, but the scheme is private: the server is expecting a zero-knowledge proof, not a plaintext signature. The agent's wallet already has a private commitment inside a privacy pool called UPP (Universal Private Pool, the pool in our stack). The agent generates a ZK proof locally that says, roughly: "I am authorised to spend amount X out of one of the commitments in this pool, here is a new commitment for the change, here is a nullifier so this authorisation cannot be reused, and by the way, the customer behind this commitment is in BlockReg's association set."

The agent retries:

GET /api/macro-signal/eur HTTP/1.1
X-Payment-Proof: { proof, nullifier, new_commitment, ... }

The server validates the proof structure, submits it to UPP, and waits for the pool to confirm. UPP verifies the proof, records the nullifier, inserts the new commitment, and credits the server's own commitment with X. The server returns the macro signal.

What lands on chain is one privacy-pool transaction. A commitment was inserted. A nullifier was recorded. No wallet address went through, no vendor name was named, no amount was visible in the clear. The 30,000 receipts per day collapse into a stream of opaque pool state changes.

The exact mechanics of "I prove I can spend without revealing the commitment" are unpacked in part 2 of this series, where Lukas's transaction walks through the proof piece by piece. For Sofia's purpose, the point is the shape of the change: x402's HTTP flow is preserved, x402's payment-required dance is preserved, and only the on-chain settlement is replaced with a proof. The agent's code change is small. The server's code change is small. The on-chain footprint becomes opaque to everyone outside the pool.

6. Compliance survives

Three properties keep the regulator, and Sofia herself, in the picture.

Audit visibility. Each commitment in the pool is encrypted to a small set of viewing keys when it is created. Stillwater holds one viewing key by operational necessity. The customer holds another. With Stillwater's key, Sofia's risk team can pull the full history of every customer's portfolio. Her CFO can pull monthly spend breakdowns by vendor. Her compliance officer can produce MiFID II transaction reports on request. The audit trail is complete; it is just no longer broadcast.

KYC stays binding. Every u402 proof carries an association-set membership proof, the same primitive UPC ships and the same one BlockReg already runs for the rest of Stillwater's business. Only customers in BlockReg's tree can transact through Stillwater's u402 endpoints. Sanctions screening, AML obligations, and KYC continuity all live inside the proof. If BlockReg removes a customer from the tree, that customer's payments stop verifying that same block.

Regulator access. The Austrian Financial Market Authority, or any regulator with a court order, can hold a viewing key by mandate. They see what they are authorised to see, when they are authorised to see it. There is no backdoor; there is explicit programmable access for parties who are legally entitled to it.

The line is the same one part 2 finishes on, in the same compliance world: privacy is not the absence of visibility. Privacy is programmable visibility, with the keys spread across exactly the parties who need them, and no one else.

7. u402 today

u402 today is in three stages.

The draft specification is published in the permissionless-technologies docs. It defines the x402 v2 plugin format, the proof shape, the settlement semantics against UPP, and the viewing-key hooks for audit. It is stable in structure, still open in details. Feedback channel on GitHub.

The starter repo x402-upd-starter is working. It runs the x402 baseline: agents pay servers via EIP-3009 transferWithAuthorization, gasless from the agent's side, settling on chain in plaintext. This is the runway, not the destination. It exists so builders can integrate x402 today, against any EIP-3009 token (USDC, EURC, UPD), and switch the settlement layer to private later.

The private settlement is under active build. The pool circuit changes are specified; the production wiring against UPP is being written. We will not call it shipped until the circuit is audited and proof generation is fast enough for per-call payments in real time. We will call it an open-source preview when the integration tests pass, and an open invitation while we work on the rest.

If your team is building agent products, or selling APIs to agents, you are in the audience this is being built for. The spec is there to read, the starter is there to fork, the GitHub issue tracker is there to argue with us in.

8. What this means for you

Sofia's 1,200 customers will get strategies that do not leak on the day they are traded. Sofia gets to keep the alpha her customers pay her for. Her vendors keep getting paid, traceably to a KYC'd payer and opaquely to everyone else. Nothing about the business stops working.

The four actors did their jobs.

BlockReg KYC'd Sofia's customers once and added each one to the association set. Same job as in the rest of this series.

Each customer's agent generated proofs, paid vendors via u402, and never sent identifying data anywhere it should not go.

The privacy pool verified the proofs and settled the value. It learned nothing about which customer paid which vendor for what.

The Observer saw 30,000 abstract pool operations and a handful of vendor commitments getting larger. Sofia's strategy stayed in Vienna.

This post did not cover three things. The exact circuit changes that make u402's proofs fit in the standard pool: those follow in the technical posts. The economics of streaming per-call payments at scale: that is x402-community work, partially independent. The legal status of agent-initiated transactions under MiFID II: it deserves its own piece, by someone with a regulatory licence, not by us.

For now, Stillwater's agents pay privately. That is enough.

Stay tuned for Part 4: Picking a ZK-friendly hash. When it ships we will edit this footer to link to it.

Privacy Pool 101: nine short posts.

  01. What is a privacy pool?                ← see part 1
  02. How a ZK proof hides everything       ← see part 2
  03. How agents pay (u402)                  ← you are here
  04. Picking a ZK-friendly hash             coming soon
  05. The audit finding that made us redo it coming soon
  06. Wrapping a STARK in a SNARK            coming soon
  07. Why our Merkle tree got eight times wider coming soon
  08. What you must encrypt                  coming soon
  09. Compliance without surveillance        coming soon