Jul 31, 2026

What 120 real agent-to-agent payments actually look like

Data
What you'll learn

Almost everything written about agentic payments is a forecast. This is not. Here is the shape of 120 settlements our trust oracle actually took on mainnet, what the distribution says about how agents buy, and the numbers that surprised us.

Why this is worth writing down

The agentic payments literature is almost entirely forward looking. Market sizing, protocol explainers, diagrams of how it will work. Very little of it describes transactions that happened.

We run a trust oracle that agents pay per call to check each other. It has taken 120 settlements on X Layer mainnet, in real USD₮0, totalling $0.528. Every one is listed with its transaction hash and anyone can verify the set independently.

It is a small dataset and we are not going to pretend otherwise. But it is a real one, and there is more to learn from 120 payments that happened than from a projection of a billion that have not.

The shape of demand

Across 120 calls, five of the seven tools were bought at all. The distribution:

verify_agent, 32 calls, 27 percent. reputation_score, 29 calls, 24 percent. risk_check, 28 calls, 23 percent. agent_passport, 25 calls, 21 percent. counterparty_check, 6 calls, 5 percent.

The first thing to notice is how flat the top four are. We expected the cheapest call to dominate, since verify_agent costs a tenth of what agent_passport does. It did not. The four sit within six points of each other, which suggests buyers were choosing by what they needed rather than by price.

The surprise: price barely steered anything

Our prices span an order of magnitude, from $0.001 to $0.01. If agents were cost-sensitive at this scale, the mix would be heavily weighted to the cheap end. It is not: the $0.01 passport took 21 percent of calls, nearly matching the $0.001 identity check at 27 percent.

The average settlement was $0.0044, which sits near the middle of the range rather than near the floor.

The honest reading is that at sub-cent prices, cost is not a decision variable for an agent. A tenth of a cent and one cent are both effectively free relative to the value of the decision being made, so the agent picks the call that answers its question. This has an uncomfortable implication for anyone planning to compete on price in this market: below some threshold, price stops being a lever at all.

The tool nobody bought

counterparty_check took 6 calls, 5 percent of the total. It is the only tool that examines both sides of a proposed deal, and it is the only one that can detect same-operator self-dealing, where one entity runs both agents and manufactures a settlement history for both.

We think it is the most interesting check we offer, and it is the least used by a wide margin.

There is a plausible innocent reason. A buyer already knows who it is, so asking about itself feels redundant, and the value of the two-sided view is not obvious until someone explains what it catches. That is a documentation failure on our side rather than a demand signal.

There is also a less comfortable reading, and we cannot distinguish them from this data: the agents doing the checking are not yet worried about being on the wrong side of a manufactured reputation, because the ecosystem is small enough that nobody has been burned yet. If that is the reason, it changes as soon as the first person is.

What the data cannot tell you

We should be clear about the limits of this, because a small dataset presented confidently is how bad analysis starts.

A meaningful share of these calls are seeded usage rather than organic third-party demand, and the proof page marks which are which. Buyer diversity is low. Nothing here says anything about how the mix changes at a thousand calls a day, or at prices ten times higher, or on a chain with different fee dynamics.

What it does establish is narrower and still worth having: agents can and do pay per call for a trust check, the plumbing works end to end on mainnet, and the demand mix across check types is flatter than a price-driven model would predict.

The number we are not showing you

Our public policy counters read zero. Not a small number, zero.

They count decisions the guardrail engine has made for live third-party agents in production, and no live agent has produced one yet. The engine is real and enforcing, but nothing honest has passed through it, so the counter says nothing.

We publish that zero on the same page as the 120. It would be easy to fill it with demo traffic, and every incentive points that way. But a number you cannot reproduce is worth less than an absence you can trust, and the whole product is a claim about verifiable trust. Padding our own metrics would be the first thing a careful reader should hold against us.

Check it yourself

Every settlement in this post is listed at /proof with its transaction hash, and each one resolves on a public explorer. The scoring method behind the tools is published in full at /methodology, and it is deterministic, so you can recompute any score we have ever returned.

If you find something in that data we got wrong, we would genuinely like to know. Being checked is the point.

Keep reading