Machine payments have a phantom-volume problem, and it is not a rounding error. It is the difference between "millions of agent transactions" and a few thousand dollars of real commerce.
One of the largest live x402 hubs reports millions of agent transactions, growing fast. When you divide its actual settled value by that transaction count, the average settlement is on the order of half a cent. Millions of events, almost no money. That is not a growth story — it is a counting story. The same request that a crawler makes to read a price, that a client makes to decide whether to pay, and that a free trial makes to get a first call, is being counted as a transaction.
The rails are real. The accounting is not. Here is what honest machine-payment accounting looks like, and the two small spec changes I proposed to the x402 tax & accounting working group to get there.
In x402, the payment flow starts with an HTTP 402 response carrying a signed challenge — the amount, the payTo address, and the accepted settlement schemes. That single response is simultaneously:
amount, and may not pay.Only the fourth thing that happens after all three — the client actually signs, the facilitator settles, and /settle returns result.success = true — is commerce. If you count challenges, or count "challenge served" as a transaction, you are counting discovery, indecision, and giveaways as revenue. That is how headline volume runs two orders of magnitude ahead of settled value.
Even the result.success = true flag is not enough on its own. It is a facilitator-side claim: it says the facilitator believes it settled. It does not prove a chain event exists that matches the (amount, payTo) the resource advertised. For accounting you want both the flag and a matching on-chain transfer — otherwise you are summing intents and confirmations indiscriminately.
That is why I proposed, and the working group adopted, a settle-only definition of volume: count a transaction only when a chain-confirmed transfer exists, matched to the challenge.
A settle-only rule is necessary but not sufficient. Two loopholes open the moment you try to game it, and each needs an explicit predicate.
Predicate 1 — value > 0, not success. A gateway can implement free trials as a zero-amount settle whose result.success is true. Count by the flag and the trials re-enter your books as settled transactions. The predicate must exclude zero-value settles by value, not by flag.
Predicate 2 — anchor to the advertised amount. "Value > 0" alone still lets a promotional $0.0001 settle register as volume. The stronger rule is: settled value ≥ the amount the resource advertised in its 402 challenge. Trials that settle below the advertised amount drop out of gross volume automatically, regardless of unit.
Predicate 2 is the subtle one. A free trial that settles a nominal single micro-unit — economically zero, technically "on-chain" — is the exact shape of the half-cent-per-transaction number above. Anchoring to the challenge amount makes it disappear from the gross metric without any judgment call.
There is a second, quieter gap in the same ledger. Machine-payment accounting wants to attribute a chargeable event to the right legal person — that is the entire point of an audit receipt. But in the agent economy there is an extra hop: the signing key is held by an agent acting on behalf of a principal. The signature binds the key; nothing in the flow represents the principal → agent delegation.
Two small additions close it:
onBehalfOf field on the authorization declaration — and crucially, it must sit inside the signed payload. If it is a loose field the wallet signature does not cover, any intermediate hop (an agent runtime, a gateway, an aggregator) can attach an attribution the principal never authorized, turning "who was this acting for" into "who can I pin this cost on."principalAttribution member on the receipt, derived from that signed declaration rather than independently asserted at settlement time. That keeps attribution verifiable end-to-end instead of self-reported after the fact.Without this, a delegated agent transaction settles fine but is unattributable for tax purposes — the exact gap settle-only provenance exists to eliminate.
Every layer of the machine-payment stack — rails, facilitators, settlement, discovery — is being commoditized at speed. The one layer that cannot be faked with a marketing number is verification of what actually happened. Settle-only accounting is the accounting half of that; pre-payment verification is the security half.
We run a live gateway, and we report our numbers the honest way on purpose. Chain-confirmed settlement, matched to the challenge, in USDC: a single small figure — not a headline total-requests number that is inflated by bots and self-polling. It is a less impressive number. It is also the only number that survives contact with an auditor.
The proposal is now part of the x402 tax & accounting working group's baseline, alongside the settle-only definition and the principal-attribution fields — the working group is folding it into its unified spec PR this week. If you run an x402 endpoint, you can adopt the discipline today without waiting for anyone: count a settle only when there is a chain transfer, at or above the advertised amount, attributed to a principal, not a key.