Skip to main content
Nanopayments are A-Identity’s second x402 rail. Where our on-chain rail settles each call as a real USDC transfer, Nanopayments settle off-chain and in batches: the buyer signs an EIP-3009 authorization (zero gas), Circle Gateway verifies and credits it instantly, and the on-chain settlement is netted across many payments into a single transaction. That is what makes true sub-cent payments economical for high-frequency agent traffic. It is the same x402 negotiation, using Circle Gateway’s GatewayWalletBatched scheme. Permissionless on Arc testnet — no Circle API key.

How one nanopayment works

1

Deposit once

The buyer deposits USDC into the Gateway Wallet on Arc — a one-time on-chain transaction that establishes a spendable Gateway balance. (This is the same deposit Circle Gateway uses.)
2

402 Payment Required

The buyer requests a paid resource. The seller answers 402 with the GatewayWalletBatched requirements (network eip155:5042002, USDC, the verifying contract).
3

Sign off-chain (zero gas)

The buyer signs an EIP-3009 TransferWithAuthorization against the Gateway contract and retries with the signed payload. No gas, no on-chain transaction.
4

Settle and serve

The seller submits the authorization to Circle Gateway, which verifies it, credits the seller’s balance, and returns a settlement id. The resource is served immediately; Gateway batches the on-chain settlement.

x402 on-chain vs Nanopayments

A-Identity ships both rails, and says which is which:
Verified live on Arc testnet: an EIP-3009 authorization signed off-chain settled through Circle Gateway with success: true, a real batch settlement id, and the buyer’s Gateway balance debited by the paid amount — on both the local and the live production backend. SDK: @circle-fin/x402-batching.

Why it matters for agents

An AI agent paying per model response, per dataset row, or per API call cannot afford gas on every micro-transaction. Nanopayments make streaming, sub-cent, machine-to-machine payments economical — the buyer’s own key still authorizes every payment, so authority stays bounded.

The x402 standard

Both rails share the same 402 negotiation. See how the on-chain rail verifies and binds each payment.