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 Arc, Arbitrum, Avalanche, Base, Ethereum, OP Mainnet, Polygon PoS, Unichain, and a growing set of further mainnets (Circle’s batching SDK also lists Arc, Sonic, Sei, World Chain, HyperEVM). 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). Both methods are gasless — the agent wallet’s transactions are gas-sponsored, so the choice is speed, not gas. --method direct (the default) deposits on the chain you fund from and settles in Gateway on that same chain, with no routing fee. --method eco uses Eco Fast Deposits from Base — a ~30-second credit for a small fixed routing fee — and always settles into Gateway on Polygon. 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. Every paid call is signed in the Gateway-batched shape against the SELAT Router’s quote; when the upstream itself advertises a Gateway-batched accept on the agent’s chain, the router settles it as a same-rail passthrough (currently quoted at par); 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, Monad, and more; the discovery skill’s deposit flow is the source of truth and rejects unsupported chains during the dry-run. The CLI defaults --chain to base. eco (Eco Fast Deposits — a ~30-second credit for a small fixed routing fee) sources from Base today and always lands on Polygon, which SELAT treats as the preferred consolidated deposit destination. Eco natively supports Optimism and Arbitrum as sources too; they return as Circle CLI coverage catches up, and both remain gasless direct sources meanwhile.

​
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). Gateway-batched is also the only shape the client ever signs: the SELAT Router’s own 402 quote is a GatewayWalletBatched accept, so the agent pays the router this way on every call and the router settles the upstream leg. When the upstream itself is Gateway-capable, the router uses a same-rail passthrough (routed-x402) — no cross-protocol translation, currently quoted at par (live operator behavior, not a guarantee; the per-call quote is authoritative). Earlier selat-pay versions paid such upstreams directly, bypassing the router; that mode was removed so every call is quoted and recorded. For upstreams without a Gateway accept, MPP wins by default on the outbound leg.

​
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 (routed on current versions; ledgers written before the router-bypassing direct mode was removed may carry direct rows), 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