Skip to main content
Nanopayments are the very-small payments agentic workloads generate — often sub-cent, at high frequency. Settling each one as an individual on-chain transfer would cost more in fees and latency than the payment itself: a single USDC transfer pays gas that can exceed the value being sent, so per-transaction settlement of high-frequency micro-charges is uneconomic. SELAT settles them through Circle Gateway.

​
What Circle Gateway provides

Circle Gateway is a USDC primitive that gives an account a single unified balance usable across chains, instead of separate balances stranded on each network. You deposit USDC into a Gateway Wallet contract to fund the unified balance; to spend, you submit a signed intent and Gateway returns a signed attestation, which mints USDC on the destination. Funds stay under the depositor’s control — moving them requires both the user’s signature and a Gateway attestation.
  • A unified USDC balance across supported chains — deposit once, spend where SELAT settles.
  • Instant, low-cost transfers suited to high-frequency micropayments (Circle advertises crosschain transfers in under ~500ms).
  • Batched settlement (“Gateway-batched”): payers sign off-chain EIP-3009 authorizations, and Gateway settles net positions on-chain in bulk rather than one transfer per payment. That removes per-transaction gas from the payer’s path and is what makes sub-cent payments viable.
Circle ships a dedicated Nanopayments product built on Gateway, aimed at pay-per-call APIs, usage-based billing, and machine-to-machine marketplaces, with payments as small as $0.000001 USDC. SELAT’s Gateway-batched rail is the same mechanism applied to agent 402 payments.
Circle Gateway is available on Arbitrum, Avalanche, Base, Ethereum, OP Mainnet, Polygon PoS, and Unichain, with more chains coming soon (including Arc). These overlap with the chains SELAT can sign on through Circle Agent Wallets.

​
How it works in SELAT

1

Fund a Gateway balance

Use selat fund (or deposit to Circle Gateway directly). --method direct (the default) deposits on the chain you fund from and settles in Gateway on that same chain. --method eco performs a gasless deposit sourced from Base, Optimism, or Arbitrum and always settles into Gateway on Polygon — no native gas needed in the wallet. selat fund shows the plan locally and requires explicit confirmation before depositing.
2

Pay per request

Each HTTP 402 paid request draws from the Gateway balance. When an upstream 402 advertises a Gateway-batched accept on the agent’s chain, SELAT pays it directly (no router markup); see below.
3

Track spend

Every submitted payment is recorded to a local JSONL ledger. Surface it with selat history.

​
Funding chains

direct deposits work on the Circle-supported chains SELAT can sign on: Base, Optimism, Arbitrum, Ethereum, Avalanche, Polygon, Unichain, and Monad. The CLI defaults --chain to base. eco (gasless) is limited to Base, Optimism, and Arbitrum as sources and always lands on Polygon, which SELAT treats as the preferred consolidated deposit destination.
Arc is a special case. Eco is not supported on Arc, and Arc mainnet cannot use the Circle Agent Wallet, so Arc deposits use a raw EOA key (SELAT_PRIVATE_KEY) and a private Arc RPC (ARC_RPC_URL).

​
How Gateway-batched composes with x402

A Gateway-batched payment is carried inside an x402 challenge: it appears as an accepts entry where scheme: "exact", the network matches the agent’s chain, and extra.name: "GatewayWalletBatched". SELAT builds the payment with the SDK’s batch scheme and submits it as a base64 Payment-Signature; the EIP-712 signing domain name is GatewayWalletBatched, and the Gateway Wallet contract is the domain’s verifyingContract (the same address on every EVM mainnet). This is the direct, lowest-cost settlement variant. When a Gateway-batched accept is present, SELAT pays the upstream directly and bypasses the SELAT Router entirely — direct Gateway-batched outranks every routed alternative unless you override the choice. Among routed alternatives, MPP wins by default.

​
Signing the draw

By default SELAT signs through the Circle smart-contract account (SCA): it resolves the SCA’s owner EOA so the authorization’s from is the address the signature recovers to. The --raw-key path signs locally with SELAT_PRIVATE_KEY (dev only; bypasses Circle MPC), in which case the signing EOA is the account whose Gateway balance funds the call.

​
What the ledger records

SELAT records every submitted payment — settled or failed — because the signed Payment-Signature is sent before the outcome is known, so the USDC may settle even on a non-2xx response. Each gateway-micropayment record carries the wallet and signer address, chain/network, rail (direct vs routed), protocol, amountUsd, amountBaseUnits, payTo, httpStatus, ok, and outcome. The ledger lives at $XDG_STATE_HOME/selat-pay/gateway-history.jsonl by default. selat history reads it (--address, --chain, --limit default 20, --json).
SELAT writes a local ledger; it does not query a live Gateway balance, and there is no balance-read command in the CLI. Per-deposit minimums, balance limits, and reconciliation are Circle-side Gateway details — consult Circle’s Gateway documentation for exact figures.

​
Next