Nanopayments: settling sub-cent agent payments

A nanopayment is a transfer worth less than the fee it would cost to send it. Circle's nanopayments advertise USDC transfers as small as $0.000001, one ten-thousandth of a cent. Send that on Ethereum during a normal 2025 base fee of around $0.53, and the network fee is roughly 53 million times the payment. No rail built for human commerce can settle that. The whole problem of nanopayments is moving value at a size where the transaction cost, not the payment, dominates.

This matters now because agents pay per call. When an autonomous agent buys a vector search, a token of inference, or a single API response, the natural price is a fraction of a cent, metered thousands of times a minute. The answer is not a cheaper transaction. It is to stop settling every payment as its own transaction. This is how sub-cent settlement actually works: aggregation, netting, and payment channels, plus the ledger discipline to account for fractional cents without losing money to rounding.

Why a per-transaction fee kills a sub-cent payment

Every payment rail carries two costs: a percentage and a fixed floor. The percentage scales down fine. The fixed floor is what breaks micropayments. Card processing runs about 2.9% plus $0.30 for online transactions (a standard published rate). On a $0.003 API call the percentage is a rounding error, but the 30 cent floor is 100 times the payment. You would pay $0.303 to move $0.003.

On-chain settlement has the same shape with a different floor. Instead of interchange you pay gas, and gas is priced per transaction regardless of the amount moved. That is why the on-chain data already shows the distortion. Chainalysis reports that on Base, x402 payments of a dollar or more grew from 49% of volume in early 2025 to 95% by early 2026, while payments between 10 cents and a dollar collapsed from 46% to 4%. Real sub-cent demand did not disappear. It cannot economically settle one transaction at a time on-chain, so it has to move somewhere else. That somewhere is a batching layer.

What a nanopayment actually is

A nanopayment is not a tiny on-chain transfer. It is a signed promise to pay, verified instantly off-chain, that settles on-chain later in a group. The payment your agent authorizes and the settlement that hits the chain are two different events, deliberately decoupled.

Circle's implementation builds directly on the x402 protocol and the EIP-3009 "transfer with authorization" standard. An agent signs an authorization for an exact amount. The seller submits that signature to be verified against the agent's available balance, and the amount is deducted immediately. The signed authorizations pile up off-chain, and Circle Nanopayments periodically submits a single batch transaction that settles thousands of them at once. One on-chain transaction, thousands of payments, gas cost per payment approaching zero. Verification and batching happen inside a Trusted Execution Environment (TEE) that signs the batch, and the on-chain contract checks that signature before updating balances.

The user-facing experience is a sub-second confirmation. The chain sees a commitment minutes later. That gap is the entire trick, and it is also where the risk lives.

How sub-cent settlement actually works

There are three ways to escape the per-transaction floor, and production stacks combine them.

Aggregation is what Circle ships and what most metered API billing needs: thousands of payers each making tiny payments, collapsed into one settlement transaction. Netting is the accounting move underneath it. If agent A owes B a cent across forty calls and B owes A eight tenths of a cent, you settle two tenths of a cent once, not forty-plus times. Netting shrinks both the number and the size of settlements, which is why it is the backbone of interbank and card settlement too. Payment channels (the Lightning-style model) suit a sustained one-to-one stream: two parties keep a signed balance that only touches the chain when the channel opens and closes.

The batch settlement flow is the same regardless of which model you run underneath:

If you are choosing between rails and protocols for this layer rather than the settlement mechanics, we mapped the landscape in agentic payments: what x402, AP2 and MPP mean for builders. The protocols decide how an agent authorizes and proves a payment. The mechanics above decide whether that payment can settle for less than it is worth.

The accounting problem: fractional cents

Decoupling authorization from settlement creates a ledger problem most fintech stacks are not built for. If your money column stores integer cents, a $0.003 payment is not representable. Round it and you either overcharge every call or leak value on every call. At a few thousand calls a minute, systematic rounding is not a rounding error. It is a revenue line.

The fix is the same discipline that underpins any correct money system: pick a base unit small enough that every amount you handle is an integer, and never store money as a float. USDC has six decimals, so the natural base unit is one micro-USDC (0.000001), and every nanopayment is an exact integer count of those units. Rounding, if it happens at all, happens once at a defined boundary with a documented rule, not implicitly on every arithmetic operation. This is the fractional-unit version of the invariants we cover in double-entry ledgers: the backbone of every fintech app: every authorization is a debit against the agent's prefunded balance and a credit to the seller's accrued balance, and the two sides must always tie out to the batch that eventually settles on-chain.

Reconciliation gets a new failure mode too. You are no longer matching one payment to one settlement. You are matching thousands of off-chain authorizations to one on-chain batch, and any authorization that was verified but excluded from the batch (dropped, expired, or disputed) is a break you have to detect. The matching engine is the same shape as the one in building a payment reconciliation engine that survives, except the "one" side is now a batch commitment and the "many" side is a stream of signatures.

What you have to get right

Three things separate a nanopayment system that holds from one that quietly loses money.

Idempotency. Agents retry, and a signed authorization is replayable. Treat the authorization signature (or its EIP-3009 nonce) as the idempotency key and deduplicate on it, with a cache window wider than your longest retry. A double-counted sub-cent payment is trivial once. Multiplied across a retry storm, it is a reconciliation break you will spend a day chasing.

Float and prefunding. Aggregation means the settlement layer holds authorized-but-unsettled value on your behalf between windows. That is float, and float is a custody decision. Who holds the prefunded balance, how is it topped up before it runs dry mid-stream, and what happens to accrued payments if settlement fails? These are the same custody trade-offs we worked through in shipping stablecoin rails without the pain, now with a real-time drawdown against the balance.

Trust between settlements. Between authorization and on-chain commitment, someone is holding your promises. A TEE-signed batch narrows that trust, but it does not remove it.

Where this leaves builders

Nanopayments are not a cheaper transaction. They are the admission that per-transaction pricing and sub-cent payments cannot coexist, so you settle in batches and keep an exact off-chain ledger in between. The pattern is old (netting predates blockchains by a century) but the trigger is new: software that pays software thousands of times a minute has finally made sub-cent settlement a load-bearing requirement rather than a novelty.

If you are designing the settlement, float, and accounting layer for an agent-native product and want a second opinion on the mechanics, that is the kind of problem we work through with teams building agentic payment infrastructure. Get in touch if you want to pressure-test the design before it meets production volume.