> ## Documentation Index
> Fetch the complete documentation index at: https://selat.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Nanopayments powered by Circle Gateway

> How SELAT uses Circle Gateway to settle batched, very-low-value payments.

**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.

<Note>
  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.
</Note>

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

<Steps>
  <Step title="Fund a Gateway balance">
    Use [`selat fund`](/docs/selat-cli) (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.
  </Step>

  <Step title="Pay per request">
    Each [HTTP 402](/docs/primers/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.
  </Step>

  <Step title="Track spend">
    Every submitted payment is recorded to a local JSONL ledger. Surface it with [`selat history`](/docs/selat-cli).
  </Step>
</Steps>

### 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](/docs/primers/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](/docs/primers/mpp-tempo) 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`](/docs/selat-cli) reads it (`--address`, `--chain`, `--limit` default 20, `--json`).

<Note>
  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.
</Note>

## Next

* [SELAT CLI](/docs/selat-cli)
* [x402](/docs/primers/x402)
* [HTTP 402 primer](/docs/primers/http-402)