Stablecoins and irreversibility
An agent that pays a human-scale invoice by card can be rescued afterwards. An agent that pays $40,000 in USDC to the wrong address cannot. There is no chargeback, no issuer to call, and no reversal — which is why a governance layer for autonomous spending has to decide before the payment rather than review after it.
Why do AI agents pay in stablecoins? Because the alternatives assume a human. A card needs a cardholder, a bank transfer needs banking hours, and both assume someone who can be phoned. A stablecoin transfer settles in seconds, costs a fraction of a cent, works at machine scale and needs no counterparty relationship — and it is final the moment it settles.
The rail: HTTP 402, USDC, six decimals
x402 revives the HTTP status code nobody
used — 402 Payment Required — as a machine-to-machine payment handshake. A client
requests a resource, the server answers 402 with a price and an address, the client
pays and retries with proof. No account, no API key negotiation, no invoice.
| Property | Value | Consequence for a governance layer |
|---|---|---|
| Asset | USDC, a dollar-denominated stablecoin | Amounts look like money, so people reason about them as floats. They must not be |
| Precision | 6 decimals — one atomic unit is $0.000001 | Every amount is an integer count of atomic units internally, converted once at the boundary |
| Settlement | seconds, on chain | No window in which to intervene after the fact. Authorisation is the only control point |
| Reversibility | none | The entire argument on this page |
| Cost per payment | fractions of a cent | Micropayments become rational, so thousands of tiny payments becomes a normal pattern |
Irreversibility is the whole argument
Human payment systems are built on the assumption that mistakes get undone. That assumption is load-bearing and it is absent here.
| Card | Bank transfer | Stablecoin | |
|---|---|---|---|
| Reversal window | 120 days typical | hours, sometimes | none |
| Dispute process | chargeback | recall request | none |
| Who absorbs fraud | issuer or merchant | often the sender | the sender, entirely |
| Wrong recipient | recoverable | sometimes recoverable | gone |
| Practical control point | after | during | before |
Every control in a card network is detective — it finds the problem and then unwinds it. Detection is worth having, and on this rail it buys you a description of a loss rather than a recovery. So the useful controls move forward in time, and a limit that is only checked in a monthly report is not a limit at all.
This cuts against the intuition that crypto rails need less governance because they are permissionless. Permissionless means nobody will stop a mistake for you. Finality means nobody can undo one. Those two properties together are the reason an autonomous agent with a wallet needs a spend decision on every action, not a spending report every month.
Why money is an integer here, and never a float
USDC has six decimals, so $2.50 is exactly 2500000 atomic units. That number is
exact; 2.50 as a binary float is not, and the error compounds over a run of
micropayments.
>>> 0.1 + 0.2
0.30000000000000004 # a governance layer that accumulates here is wrong
>>> from tesoro.domain import usd_to_atomic
>>> usd_to_atomic("0.1") + usd_to_atomic("0.2")
300000 # exactly $0.30
Passing a float to tesoro raises TypeError at the
boundary rather than being tolerated, and the rounding direction is pinned so that a fraction of
an atomic unit never rounds in the spender's favour. $0.0000001 becomes
0, not 1: rounding that favours the spender is a slow leak rather than
an error, and a leak nobody reconciles is a leak nobody finds.
This is one of four hard invariants and it exists because of the rail, not because of taste. A float-denominated budget on an irreversible rail is a governance layer that will eventually approve something it believed was smaller.
Two channels, two currencies, one agent
An agent that pays for things also pays to think, and the two are not the same money.
internal | external | |
|---|---|---|
| What it buys | inference — the tokens the agent burns reasoning | data, services, goods from a counterparty |
| Denomination | real dollars on a provider invoice | USDC on chain |
| Counterparty | one model provider, contractual | anyone the agent decides to pay |
| Reversible | effectively — it is a bill you dispute | no |
| If the budget is exhausted | REJECT — the agent cannot think, so it must stop | REVIEW — a human can decide whether this payment is worth it |
They never share an envelope. Spending them from one budget would let an expensive afternoon of reasoning consume the money meant for purchases, and it would make the report meaningless — two currencies summed into one number is not a total, it is a coincidence.
Authorise, then settle — and why the envelope moves on the second
A payment on this rail has two moments, and conflating them is how a budget drifts:
- Authorisation — the decision, before anything moves. This is where every control runs, where a verdict is produced, and where the record of which control decided is written.
- Settlement — what actually happened on chain. It may differ from what was authorised, it may fail, and it may never occur because the agent abandoned the task.
Cumulative envelopes consume on settlement, not authorisation. An agent that asks about a $40 purchase and then abandons it has spent nothing, and a budget that had already deducted the $40 would refuse a later legitimate purchase for money that was never sent. The reverse error is worse: settling more than was authorised must consume the larger amount, and a version of this layer that consumed only the authorised figure let $5.00 settle against a $0.05 authorisation while recording $0.05 as spent.
What Tesoro does not touch
Worth being exact, because "agent payments" invites the assumption that this software moves money. It does not.
- No custody. Tesoro holds no funds and no wallet. It decides; something else pays.
- No keys. A key is never stored, logged or journalled, and a masked display path is the only way one is ever shown.
- No chain interaction. No RPC, no signing, no broadcasting. It never touches a node, which is also why a decision costs microseconds rather than a block time.
- No address validation. Whether an address is the right one is outside what a spend control can know. Tesoro governs how much, to whom by identifier, and for what declared purpose — not whether a counterparty is who it claims.
- No AML screening engine. There is a schema for an assessment and no engine behind it: no list, no matching, no jurisdiction model. No regulatory compliance is claimed or sought.
Does a per-payment cap solve this?
No, and the reason is arithmetic rather than opinion. A cap of $10 per payment permits an unbounded number of $9.99 payments, and on a rail where each one costs a fraction of a cent to send there is nothing to make that irrational. Bounding the total needs a cumulative envelope over a window; bounding the number of actions needs a count envelope, which is a different quantity again.
The four kinds of AEGL page sets out what each level of control can and cannot express, and why a per-payment cap is honestly enough for some deployments and structurally insufficient for others.
What about cards, AP2 or bank rails?
The governance model is deliberately rail-neutral: envelopes, verdicts, attribution and evidence say nothing about USDC. x402 is the first binding because it is where autonomous machine payments are actually happening, and a card or AP2 binding changes the adapter rather than the controls.
What does change per rail is how much the reversibility column above lets you relax. On a card, a missed control is a dispute. Here it is a transfer. The controls in a policy pack are the same either way; the cost of getting them wrong is not.
Where next
Four kinds of AEGL
What a per-payment cap cannot express, and where the useful boundary falls.
the four types →What Tesoro is
The implementation: ten deterministic engines and an honest list of what it does not do.
tesoro →