A sub-cent payment is uneconomic if the fee to move it costs more than the payment. That is the whole problem with charging agents per call. Here is how batched settlement and an off-chain signature solve it, and what you give up in exchange.
The arithmetic that kills per-call pricing
Charging an agent a tenth of a cent for an API call is a lovely idea until you price the transfer. If moving the money costs more than the money, the model does not work, and no amount of protocol design fixes arithmetic.
This is why most agent payment demos quietly charge a cent or more, or batch into a monthly invoice and reintroduce the accounts and API keys the whole thing was supposed to remove.
There are two honest ways out. Make the fee approximately zero, or stop settling every payment individually. The interesting designs do both.
Move the signature off-chain, keep the settlement on it
The mechanism is an authorization the buyer signs but does not broadcast.
Under EIP-3009, a token holder can sign a message that says "transfer this amount to this address, valid between these times, with this nonce". The signature is data. It costs nothing to produce, and the buyer never touches the chain or holds a gas token.
The seller receives that authorization and hands it to a facilitator, which verifies the signature, credits the seller immediately, and settles on-chain later, batching many authorizations into a single transaction. Thousands of sub-cent payments net into one transfer, and the per-payment fee becomes the batch fee divided across all of them.
That is Circle Gateway's batched settlement, and it is what makes a $0.001 call economically real rather than a rounding error you are subsidising.
What the buyer experiences
An agent calls an endpoint. It gets HTTP 402 with a challenge naming the network, the asset, the amount and the address to pay. It signs an authorization, attaches it, replays the request, and gets the resource.
No gas token. No account. No API key. No prior relationship with the seller. The agent needs a funded balance and a key, and nothing else.
You can see the challenge without paying anything: an unauthenticated GET to our Arc endpoint returns the 402 with the `accepts` block naming Arc testnet and native USDC. Nothing is charged for looking.
The chain choice does more work than it looks
On most chains the buyer needs the native token for gas even to receive value, which is a real onboarding problem for an autonomous agent: it has to acquire a second asset it has no use for.
On Arc the gas token is USDC. An agent holding dollars can transact with dollars. That removes an entire class of setup, and it is also why Circle Paymaster is not part of our Arc integration: a token paymaster exists to let an account pay gas in USDC where the native token is something else, and here that problem does not exist. We checked rather than assumed, and the published paymaster addresses have no contract behind them on Arc.
Naming the thing you did not integrate, and why, is usually more informative than the list of things you did.
What you give up
Batched settlement is not free of tradeoffs and the honest version is worth stating.
Finality is split. The seller is credited when the facilitator verifies the signature, but the on-chain transfer happens later, in a batch. For most flows this is fine. For anything that must be irreversible on-chain before you act, it is not, and you should settle individually.
There is a trust step. The facilitator sits between signature and settlement. This is a smaller surface than a custodian, since the authorization is scoped to an amount, a recipient and a time window, but it is not zero and pretending otherwise would be dishonest.
And authorizations expire. A signature carries a validity window, which is a feature, since a leaked authorization cannot be replayed forever. It also means an agent that signs and then stalls will find its authorization dead and have to sign again.
When to use which rail
Use per-call on-chain settlement when payments are large enough that the fee is noise, when you need on-chain finality before acting, or when you want each payment to be independently verifiable by a third party without asking a facilitator anything.
Use batched nanopayments when payments are genuinely small, when volume is high, and when the buyer should not have to hold a gas token to participate.
We run both. The trust oracle settles per call on X Layer, which is why every one of those 120 settlements has its own transaction hash you can check. The Arc rail uses Gateway batching. Same protocol, different economics, chosen per use rather than as a religion.
Trying it
Send an unauthenticated GET to our Arc nanopayment endpoint and read the challenge. It costs nothing, needs no key, and shows you the exact shape of an x402 v2 payment requirement on a chain where gas is already USDC.
If you want the paid tools instead, `trust_preview` is free and rate limited, and the rest are priced from $0.001 to $0.01 with the full table published.