Circle Gateway Nanopayments: batched x402 down to $0.000001

A payment of one millionth of a dollar cannot pay for its own settlement. Circle's answer is to stop settling payments one at a time.

Nanopayments powered by Circle Gateway went live on mainnet on 29 April 2026. The claim is narrow and checkable: gas-free USDC payments as small as $0.000001, over the x402 protocol, on eleven blockchains, with verification in under half a second. We read the Gateway Nanopayments documentation end to end — the batching concept page, the EIP-3009 signing how-to, both quickstarts, the SDK reference, the fee table, the supported-chains table — and this is what the mechanism actually is.

The short version: it is not a new x402 scheme. The scheme identifier is still exact. What changes is the EIP-712 domain the buyer signs, the contract named as verifyingContract, and the moment the money moves on-chain. That last change is where all the interesting consequences live.

The gas floor is the whole problem

Every per-request payment rail runs into the same wall. Settling a USDC transfer costs gas, and gas does not scale down with the payment. Circle's own deep dive on Nanopayments puts numbers on it using 2025 average base fees: on Ethereum, at roughly $0.5370 per transfer, moving $0.000001 carries a 53,700,000% fee. On Base, at roughly $0.0045, it is 450,000%. On Solana, at roughly $0.0010, it is 100,000%.

Those percentages are absurd on purpose. The practical reading is that individual on-chain settlement puts a floor of roughly a cent under any payment, and everything below that floor is economically unreachable. That floor is why metered agent billing keeps collapsing into prepaid accounts and monthly invoices — the aggregation has to happen somewhere, and if the chain will not do it, a ledger will.

Circle's Gateway batching table states the trade directly. Individual settlement: full gas per transaction, viable minimum roughly $0.01 or more depending on chain. Batched settlement: gas divided by the number of payments in the batch, viable minimum $0.000001.

Gateway first, Nanopayments second

Nanopayments is a feature of Circle Gateway, and Gateway is worth understanding on its own because the payment path inherits its properties.

Gateway gives you a unified USDC balance across chains. You deposit USDC into a non-custodial Gateway Wallet contract on any supported source chain, and you can then mint USDC on any supported destination chain in under 500 milliseconds, through a single API call. It is permissionless — Circle's overview says you can integrate immediately with no sign-up. Custody stays with you through signature-based authorization, with a 7-day trustless withdrawal path if the Gateway API is ever unavailable.

Circle's own documentation contrasts it with CCTP, which we covered in July: CCTP is point-to-point burn-and-mint, with Fast Transfer at roughly 8 to 20 seconds and Standard Transfer at 15 to 19 minutes on Ethereum and its L2s. Gateway is a unified balance, instant after the balance exists. Both are non-custodial. They solve different problems: CCTP moves a specific amount from chain A to chain B; Gateway makes one balance spendable from anywhere.

The chain list matters for anyone planning an agent treasury. Gateway identifies chains by the same numeric domain identifiers CCTP uses. On mainnet it supports Arbitrum (domain 3), Avalanche (1), Base (6), Ethereum (0), HyperEVM (19), OP (2), Polygon PoS (7), Sei (16), Solana (5), Sonic (13), Unichain (10) and World Chain (14). Nanopayments is marked Yes for every one of those except Solana — hence eleven chains, not twelve. Arc appears in the testnet table (domain 26, EVM chain ID 5042002) and not in the mainnet one.

The five stages of a nanopayment

Circle's batched-settlement page describes a five-stage lifecycle. It maps cleanly onto the x402 request-response cycle we described in our first x402 walkthrough, with one stage bolted onto the end.

Stage 4 is the one that changes the economics for the seller. In the plain exact scheme, the seller waits for a chain. Here the seller gets a synchronous answer from an API and serves the response; the chain catches up later, in bulk. Circle's SDK reference is explicit that settle() is the recommended call in production because it is optimised for low latency and guarantees settlement, and that you should not run verify() followed by settle().

The signature is the specification

Everything distinctive about Nanopayments is visible in the object the buyer signs. Circle's EIP-3009 signing how-to spells it out, and it is worth reading carefully because the failure mode is silent.

// The domain is NOT the standard USDC domain
const domain = {
  name: "GatewayWalletBatched",
  version: "1",
  chainId: 5042002,                // EVM chain ID, not the Gateway domain id
  verifyingContract: "0x0077777d7EBA4688BDeF3E311b846F25870A19B9",
};

// The type is standard EIP-3009
const types = {
  TransferWithAuthorization: [
    { name: "from",        type: "address" },
    { name: "to",          type: "address" },
    { name: "value",       type: "uint256" },
    { name: "validAfter",  type: "uint256" },
    { name: "validBefore", type: "uint256" },
    { name: "nonce",       type: "bytes32" },
  ],
};

Three details carry weight. First, verifyingContract is the Gateway Wallet contract, not the USDC token and not the Gateway Minter — the authorization moves balance inside Gateway, not ERC-20 balance directly. Second, chainId is the standard EVM chain ID, not the Gateway domain identifier; Circle warns that using the wrong one makes the signature fail silently. Third, the domain name is a literal string constant, exported by the SDK as CIRCLE_BATCHING_NAME, and the same package exports CIRCLE_BATCHING_SCHEME with the value 'exact'. Circle did not fork the scheme. It forked the domain.

This is the same primitive we walked through in the EIP-3009 deep dive: a signed, transferable authorization that a third party can execute. What is different is who executes it and when.

Three days is a long time to hold a signed instrument

The constraint that deserves the most attention is a validity floor, not a ceiling. Circle rejects any authorization whose validBefore is less than three days in the future, with the error code authorization_validity_too_short. The server-side GatewayEvmScheme correspondingly sets maxTimeoutSeconds to 604900 — seven days plus a small buffer.

The reason is operational: Gateway needs enough time to fit the authorization into a settlement batch. The consequence is a risk profile. A signed TransferWithAuthorization is a bearer instrument. In the plain exact scheme it typically lives for seconds before being burned on-chain. Here it lives for days, held by the seller or the facilitator, and the only replay defence is the uniqueness of the 32-byte nonce — reusing one returns nonce_already_used, but the buyer has no cancellation path once the signature is out.

For an agent making thousands of sub-cent payments per minute, this means thousands of live authorizations outstanding at any moment. The exposure is bounded by the Gateway balance, which is the point of depositing rather than granting an allowance. But the accounting is not the same as the plain scheme, and treating a nanopayment as "settled" the moment the API returns is a credit decision, not a cryptographic fact. We made the same argument about deferred settlement in the batch-settlement scheme deep dive: the commitment and the money are separated in time, and someone owns that gap.

What the seller actually writes

The seller integration is small enough to read in full. Circle publishes an Express middleware in @circle-fin/x402-batching.

import express from "express";
import { createGatewayMiddleware } from "@circle-fin/x402-batching/server";

const gateway = createGatewayMiddleware({
  sellerAddress: "0xYOUR_WALLET_ADDRESS",
  facilitatorUrl: "https://gateway-api-testnet.circle.com",
});

// One line turns a route into a paid resource
app.get("/premium-data", gateway.require("$0.01"), (req, res) => {
  const { payer, amount, network } = req.payment;
  res.json({ secret: "...", paid_by: payer });
});

Underneath, gateway.require() returns 402 when there is no valid payment and calls the Settle x402 Payment endpoint when there is. For non-Express stacks there is BatchFacilitatorClient, with verify(), settle() and getSupported() — the same three-verb facilitator surface we mapped in our facilitator deep dive, which is why Gateway slots into existing x402 servers without a rewrite.

One subtlety in the SDK reference is telling. The base ExactEvmScheme from the standard x402 packages discards the extra field when building payment requirements. Gateway clients need extra.verifyingContract to build a valid EIP-712 signature, so Circle ships GatewayEvmScheme, which preserves it. A seller wiring Gateway into x402ResourceServer without that subclass will emit 402 responses that Gateway buyers cannot sign against.

On the buyer side, CompositeEvmScheme is the piece that keeps the ecosystem honest: it routes to the batched scheme when the requirements carry extra.name === "GatewayWalletBatched", and falls back to the standard on-chain exact scheme otherwise. Batching is an option in the accepts array, not a replacement for it.

The trust anchor is an AWS Nitro Enclave

Off-chain balances need a reason to be believed. Circle's answer is hardware attestation.

Gateway runs the batching logic inside an AWS Nitro Enclave, which verifies every EIP-3009 signature before including it in a batch, computes the net balance changes across all payments, and signs the batch result with the enclave's private key. That key is protected by AWS KMS under attestation-based access policies, so only the audited enclave image can use it — Circle states that its own operators cannot extract it. The Gateway Wallet contract then verifies the enclave's signature on-chain before applying any batch, and reverts if the signature is invalid or comes from an unauthorised signer. Nitro Enclaves also produce attestation documents that can be verified independently.

This is a coherent design, and it is worth naming precisely what it does and does not give you. It gives you unforgeability: payments can only be processed from authorizations signed by the buyer's private key, so Circle cannot invent a debit. It does not give you censorship resistance or ordering guarantees — Gateway decides when a batch is cut and what nets against what. The escape hatch is the 7-day trustless withdrawal, which is a liveness backstop, not a real-time one.

Balance state is tracked through the pipeline, and the SDK exposes it as total, available, withdrawing and withdrawable. Individual transfers move through received, batched, confirmed, completed and failed, queryable by UUID through getTransferById() or in bulk through searchTransfers() with cursor pagination. If you are going to run revenue through this, those two endpoints are your reconciliation.

The constraints Circle does not lead with

Four of them, all documented, all load-bearing.

Externally owned accounts only. Nanopayments and x402 batch settlement require EOA signatures and do not support ERC-1271. The reason is mechanical: the batched path verifies EIP-3009 authorizations off-chain using ecrecover, which contract signatures do not satisfy. Standard Gateway transfers do support ERC-1271. This is the sharpest tension in the whole design, because the agent wallet architecture the industry has converged on — smart accounts with session keys and scoped permissions, which we covered in the account abstraction deep dive — is exactly the architecture excluded here. To use Nanopayments today, your agent holds a raw private key.

Solana is out. Gateway supports Solana at the balance layer, but the Nanopayments column reads No. Any multi-rail buyer that treats SVM settlement as a first-class path needs a separate mechanism there.

Funding latency is real. Thirteen to nineteen minutes to credit a deposit on Ethereum-anchored chains is a poor experience for an agent that just ran out of balance mid-task. Circle points at third-party fast-deposit services, naming Eco as an example, while explicitly stating it does not endorse, maintain or audit them. That is a candid disclaimer and also an admission that the on-ramp is unsolved.

Nanopayment pricing is not published. Circle's fee reference covers Gateway transfers: 0.005% (0.5 basis points) on crosschain transfers, plus a per-source-chain gas fee — $1.00 on Ethereum, $0.15 on Solana, $0.05 on HyperEVM, $0.02 on Avalanche, $0.01 on Arbitrum, Base, Sonic and World Chain, $0.0015 on OP and Polygon PoS, $0.001 on Sei and Unichain — plus a flat $0.05 forwarding service fee if you use Circle's Forwarding Service for the destination mint. Same-chain withdrawals carry no transfer fee. What the documentation does not state is a per-nanopayment charge. "Gas-free" is a claim about gas, and the batching page frames costs as "near zero" rather than zero. Model the withdrawal, not just the payment: the difference between withdrawing to Unichain and withdrawing to Ethereum is three orders of magnitude.

Where this sits in the stack

Nanopayments is the second serious attempt to break the gas floor for x402, and the two attempts have opposite trust models. The batch-settlement scheme in the x402 specification, which grew out of Cloudflare's deferred proposal, is credit-backed by default: the seller accepts an identity-bound commitment and redeems later. Circle's is capital-backed: the buyer's money is already inside a Gateway Wallet contract before the first request, and the authorization draws against it.

Capital-backed is the stronger position for a seller and the more demanding one for a buyer. It requires pre-funding, which is exactly the friction x402 walk-up was designed to remove. That is not a contradiction — it is a segmentation. Walk-up exact for the first contact with an unknown counterparty, batched drawdown for the relationship you have already established. We drew that line in our Bearer versus walk-up decision tree, and Gateway sits neatly on the funded side of it.

The distribution context is Circle Agent Stack, announced on 11 May 2026, bundling Agent Wallets with policy controls, an Agent Marketplace for service discovery, Circle CLI as the control plane, Circle Skills, and Nanopayments as the rail. In that announcement Circle reported $24.24 million processed via x402 in the preceding 30 days as of 29 April, with 99.8% of transaction value settled in USDC. That second number is the one to keep: the agentic payment volume that exists today is effectively all USDC, which is why the issuer building the batching layer is not a neutral event.

What it means for LLM4Agents

Our billing problem is the gas floor, restated. A large fraction of inference calls through the gateway cost less than a cent — short completions on small models, embeddings, classification passes. We solved it internally with reserve, proxy and settle, aggregating usage against a funded balance and reconciling afterwards, as described in the billing internals post. Circle has now built the same shape as public infrastructure: fund once, authorize off-chain per request, settle in bulk.

What it enables: a buyer-side balance we do not have to custody. An agent that holds USDC in a Gateway Wallet can pay per request without a prepaid account on our side and without per-call gas, and the authorization it signs is verifiable by us before we serve a token. For the metered-billing patterns we described in the upto scheme, where the final amount is only known after the completion, batching is complementary rather than competing: the authorization is signed for the maximum, and the settlement call carries the real number.

What it threatens: fragmentation of the buyer stack. If a meaningful share of agents standardize on a Gateway balance, sellers who advertise only the plain exact option become unreachable to them, and the accepts array becomes the real interoperability surface. That is manageable — CompositeEvmScheme exists precisely for it — but it means our 402 responses need to carry more than one option and our settlement layer needs more than one path. It also means a single issuer sits between a growing share of agent payments and the chain, with discretion over batch timing. That is a dependency worth measuring before it is worth adopting.

Where it fits: an additional entry in accepts and an additional settlement path in billing. Not a replacement for walk-up x402, and not a reason to stop aggregating internally.

Staying on the frontier

Concrete steps, in the order we think they should happen.

1. Add the option, keep the default. Emit a second entry in the accepts array carrying extra.name = "GatewayWalletBatched" and the correct verifyingContract per network, behind a flag, with the existing on-chain exact entry listed first. Server-side this means GatewayEvmScheme rather than the base scheme, so the extra block survives into the 402 response.

2. Measure before trusting. Record the transfer identifier from every settle response and poll searchTransfers() to build a distribution of received to completed latency and a frequency table of error codes. Batch cadence is not documented; it is discoverable. Until we have two weeks of that data, batched payments should be treated as pending revenue, not booked revenue.

3. Price the authorization window as credit. A minimum three-day validity means outstanding authorizations accumulate. Cap per-agent exposure per settlement window, alert on the gap between authorized and settled, and reconcile daily against the Gateway balance rather than against our own ledger.

4. Keep the wallet classes separate. Agents using smart accounts cannot pay this way. Do not migrate them, and do not build a flow that silently downgrades an agent to a raw EOA to unlock batching. Track ERC-1271 support for the batched path as the signal that the two classes can merge.

5. Withdraw deliberately. Seller balances should be swept on a schedule to a low-gas destination — the published gas fees put Sei and Unichain at $0.001 against Ethereum at $1.00 — and the sweep threshold should be set from measured volume, not guessed.

6. Write down the coverage. Which of our endpoints accept batching, on which networks, and with which fallback, published where a buyer agent can read it. The discovery problem is not solved by adding a payment option nobody can find.

The gas floor was never a law of nature. It was an artefact of settling every payment individually, and two different groups have now removed it in two different ways. What remains is the part that batching cannot remove: someone holds the gap between the promise and the money, and the engineering question is only ever who, for how long, and against what collateral.