Agent Payments: Privacy, Reputation and Verification Layers

An AI agent about to pay a stranger over x402 is really answering three different questions, and no single tool answers all of them:

Privacy: who gets to see that this payment happened, and for how much?
Reputation: who is the counterparty, and what history do they have?
Verification: is the request in front of me well-formed, and did the payment settle the way it said it would?

These are three layers of the same stack. They solve different problems, they depend on different data, and they pull against each other in a few places. This post walks through each layer, what it can and can't tell you, and where the tensions are. It doesn't rank products against each other. It describes the problem each layer solves.

Why Agent Payments Are Public by Default

A standard x402 payment on an EVM chain settles as an ordinary token transfer. With the exact scheme on USDC, the agent signs an EIP-3009 authorization and a facilitator submits it. The result is a normal ERC-20 Transfer event on a public ledger such as Base: sender address, recipient address and amount, readable by anyone, permanently.

For a human buying something once, that's mostly a curiosity. For an agent making thousands of small payments, the public record can reveal:

which APIs the agent depends on (its suppliers)
how much it spends and when (its activity pattern)
which wallets belong to one operator (by linking them through repeated payments)

That is useful competitive and security information to someone watching, which is why a privacy layer exists.

Layer 1: Privacy

Privacy tooling for payments tries to break the public link between sender, recipient and amount while keeping the settlement itself valid. The common building blocks, in general terms:

Zero-knowledge proofs: a cryptographic proof that a transaction is valid (the funds exist and haven't been spent) without revealing the details. Shielded pools use this to hide who paid whom.
Stealth addresses: a one-time recipient address derived for each payment (see ERC-5564), so repeated payments to the same party don't appear linked on-chain.
Viewing keys and selective disclosure: a way for the owner to reveal specific transactions to a chosen party, such as an auditor, without making them public.

What privacy at the payment layer doesn't hide:

The HTTP request itself. The seller still sees the agent's request, even if the payment link is hidden.
Timing and size patterns, which can still correlate activity.
The existence of a payment at all, as opposed to its contents.

The practical takeaway: payment privacy and request privacy are separate properties, and an agent that needs both has to address both.

Layer 2: Reputation

Reputation answers a different question: who is this, and have others had good experiences with them? In the Ethereum agent stack the relevant standard is ERC-8004, "Trustless Agents," which defines three on-chain registries:

Registry	What it holds
Identity Registry	An ERC-721 token per agent, a portable, ownable identity
Reputation Registry	Standardized feedback signals about an agent's behavior
Validation Registry	Hooks for third-party attestations

A reputation lookup can tell an agent that a counterparty is registered, has a wallet on file, publishes readable metadata, and has received feedback from a number of distinct clients. The ERC-8004 Inspector reads the Identity and Reputation registries directly with eth_call.

Two limits matter. First, ERC-8004 doesn't standardize a value scale for feedback, so comparing one agent's raw feedback score with another's isn't meaningful. Presence and breadth of feedback are safer signals than magnitude. Second, reputation is only as good as the link between an identity and its behavior, which is exactly what Layer 1 tries to weaken.

Layer 3: Verification

Verification asks whether what's in front of the agent is what it appears to be, before and after payment.

Before payment, the 402 challenge is untrusted input. The agent should check the recipient, amount, asset, network, scheme and resource before it signs, as laid out in the x402 pre-payment checklist. The x402 Inspector automates the structural parts.

After payment, a settlement receipt shows what actually happened on-chain. Receipt verification reads the transaction's ERC-20 Transfer logs and compares them against the challenge's declared recipient and amount. A mismatch, where funds confirmed but didn't reach the declared payTo, is a strong warning signal.

Verification is the only layer that depends on being able to observe the chain, which is where the layers start to interact.

Where the Layers Pull Against Each Other

Tension	Why it exists
Privacy vs. receipt verification	Receipt checks compare a public transfer against the declared recipient and amount. If a payment's on-chain footprint doesn't show a direct transfer to `payTo`, that comparison can't confirm it. As built today, ContextIQ's receipt check looks for a matching transfer in public logs. How best to verify a payment that settles through a privacy mechanism is an open design question.
Privacy vs. reputation	Reputation accumulates against an identity. A payer who hides which identity they paid makes it harder to attach feedback to the right counterparty.
Reputation vs. verification	A good reputation says nothing about whether this challenge is well-formed. A reputable agent can still publish a misconfigured endpoint.

Selective disclosure is the usual bridge: keep the payment private by default, and reveal specific details to a verifier when needed. That's a design pattern, not a solved interoperability problem, and what an automated verifier can accept as proof is still an open question.

Which Question Needs Which Layer

Question	Layer
Can a competitor see my agent's suppliers and spending?	Privacy
Is this counterparty registered, and do others vouch for them?	Reputation
Is this 402 challenge well-formed and consistent with the URL I called?	Verification (before payment)
Did my payment settle to the address the challenge named?	Verification (after payment)
Should my agent pay this at all?	A policy that combines the above

Policy Check sits in the last row for the reputation and verification layers. It combines an ERC-8004 lookup with the x402 challenge scan into a single allow, warn or block decision, with an itemized reason for every point of the score. The rubric is deliberately transparent: a caller can see exactly why a check failed, and can adjust their own thresholds.

FAQ

Are x402 payments private?

Not by default. A standard x402 payment on an EVM chain settles as a public ERC-20 transfer, so the sender, recipient and amount are visible on-chain. Privacy needs an additional layer such as shielded transfers or stealth addresses.

What is a stealth address?

A stealth address is a one-time recipient address derived for each payment, so that repeated payments to the same party can't be linked together on-chain. ERC-5564 standardizes the approach for Ethereum.

Does ERC-8004 provide privacy?

No. ERC-8004 provides portable identity, reputation and validation registries that are public on-chain. It's a trust layer, and it doesn't hide who an agent is or who has given it feedback.

Can you verify a private payment?

It depends on the mechanism. A verifier that checks a public transfer to a declared recipient can't confirm a payment that doesn't appear that way on-chain. Selective disclosure, where the payer reveals specific details to a chosen verifier, is the usual approach. It's an active design area rather than a settled one.

What is a pre-payment check for AI agents?

It's a set of checks run before an agent signs a payment: whether the payment challenge is well-formed, whether the recipient, asset, network and amount match policy, and whether the counterparty's identity and reputation look sound. Policy Check automates this as an allow, warn or block decision.

Try It

Use the ERC-8004 Inspector to read a counterparty's identity and reputation, the x402 Inspector to check a payment challenge, or Policy Check to get both as a single decision before your agent pays. Policy Check is a Pro feature, and the inspectors are free.