Circle Gateway Nanopayments: x402 en lotes hasta $0.000001

Un pago de una millonésima de dólar no puede pagar su propio settlement. La respuesta de Circle es dejar de liquidar los pagos de a uno.

Nanopayments powered by Circle Gateway salió a mainnet el 29 de abril de 2026. La afirmación es acotada y verificable: pagos USDC sin gas desde $0.000001, sobre el protocolo x402, en once blockchains, con verificación en menos de medio segundo. Leímos la documentación de Gateway Nanopayments de punta a punta — la página de batching, el how-to de firma EIP-3009, los dos quickstarts, la referencia del SDK, la tabla de fees, la tabla de cadenas soportadas — y esto es lo que el mecanismo realmente es.

La versión corta: no es un scheme nuevo de x402. El identificador del scheme sigue siendo exact. Lo que cambia es el dominio EIP-712 que firma el comprador, el contrato que se nombra como verifyingContract, y el momento en que el dinero se mueve on-chain. Ese último cambio es donde viven todas las consecuencias interesantes.

El piso de gas es todo el problema

Todo rail de pago por request choca con la misma pared. Liquidar una transferencia de USDC cuesta gas, y el gas no escala hacia abajo con el pago. El propio deep dive de Circle sobre Nanopayments le pone números usando fees base promedio de 2025: en Ethereum, con unos $0.5370 por transferencia, mover $0.000001 implica una fee de 53,700,000%. En Base, con unos $0.0045, es 450,000%. En Solana, con unos $0.0010, es 100,000%.

Esos porcentajes son absurdos a propósito. La lectura práctica es que el settlement individual on-chain pone un piso de aproximadamente un centavo debajo de cualquier pago, y todo lo que está debajo de ese piso es económicamente inalcanzable. Ese piso es la razón por la que el billing medido de agentes termina colapsando en cuentas prepagas y facturas mensuales — la agregación tiene que pasar en algún lado, y si no la hace la cadena, la hace un ledger.

La tabla de batching de Gateway plantea el intercambio de forma directa. Settlement individual: gas completo por transacción, mínimo viable de aproximadamente $0.01 o más según la cadena. Settlement en lote: gas dividido por la cantidad de pagos del lote, mínimo viable $0.000001.

Primero Gateway, después Nanopayments

Nanopayments es una función de Circle Gateway, y Gateway merece entenderse por separado porque el camino de pago hereda sus propiedades.

Gateway te da un balance unificado de USDC entre cadenas. Depositas USDC en un contrato Gateway Wallet no custodial en cualquier cadena origen soportada, y después puedes mintear USDC en cualquier cadena destino soportada en menos de 500 milisegundos, con una sola llamada a la API. Es permissionless — el overview de Circle dice que puedes integrar de inmediato sin registro. La custodia queda contigo vía autorización por firma, con un camino de retiro trustless a 7 días si la API de Gateway alguna vez no está disponible.

La propia documentación de Circle lo contrasta con CCTP, que cubrimos en julio: CCTP es burn-and-mint punto a punto, con Fast Transfer en unos 8 a 20 segundos y Standard Transfer en 15 a 19 minutos en Ethereum y sus L2s. Gateway es un balance unificado, instantáneo una vez que el balance existe. Los dos son no custodiales. Resuelven problemas distintos: CCTP mueve un monto específico de la cadena A a la cadena B; Gateway hace que un balance sea gastable desde cualquier lado.

La lista de cadenas importa para cualquiera que planifique una tesorería de agentes. Gateway identifica cadenas con los mismos domain identifiers numéricos que usa CCTP. En mainnet soporta Arbitrum (domain 3), Avalanche (1), Base (6), Ethereum (0), HyperEVM (19), OP (2), Polygon PoS (7), Sei (16), Solana (5), Sonic (13), Unichain (10) y World Chain (14). Nanopayments está marcado Yes en todas menos Solana — de ahí las once cadenas, no doce. Arc aparece en la tabla de testnet (domain 26, EVM chain ID 5042002) y no en la de mainnet.

Las cinco etapas de un nanopayment

La página de batched settlement de Circle describe un ciclo de vida de cinco etapas. Mapea limpiamente sobre el ciclo request-response de x402 que describimos en nuestro primer recorrido de x402, con una etapa agregada al final.

La etapa 4 es la que cambia la economía del vendedor. En el scheme exact plano, el vendedor espera a una cadena. Acá el vendedor obtiene una respuesta síncrona de una API y sirve la respuesta; la cadena se pone al día después, en bloque. La referencia del SDK de Circle es explícita en que settle() es la llamada recomendada en producción porque está optimizada para baja latencia y garantiza el settlement, y en que no deberías correr verify() seguido de settle().

La firma es la especificación

Todo lo distintivo de Nanopayments está a la vista en el objeto que firma el comprador. El how-to de firma EIP-3009 de Circle lo detalla, y conviene leerlo con cuidado porque el modo de falla es silencioso.

// El dominio NO es el dominio estándar de USDC
const domain = {
  name: "GatewayWalletBatched",
  version: "1",
  chainId: 5042002,                // EVM chain ID, no el domain id de Gateway
  verifyingContract: "0x0077777d7EBA4688BDeF3E311b846F25870A19B9",
};

// El tipo es EIP-3009 estándar
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" },
  ],
};

Tres detalles pesan. Primero, verifyingContract es el contrato Gateway Wallet, no el token USDC ni el Gateway Minter — la autorización mueve balance dentro de Gateway, no balance ERC-20 directamente. Segundo, chainId es el EVM chain ID estándar, no el domain identifier de Gateway; Circle advierte que usar el equivocado hace que la firma falle en silencio. Tercero, el nombre del dominio es una constante literal, exportada por el SDK como CIRCLE_BATCHING_NAME, y el mismo paquete exporta CIRCLE_BATCHING_SCHEME con el valor 'exact'. Circle no forkeó el scheme. Forkeó el dominio.

Es la misma primitiva que recorrimos en el deep dive de EIP-3009: una autorización firmada y transferible que un tercero puede ejecutar. Lo distinto es quién la ejecuta y cuándo.

Tres días es mucho tiempo para sostener un instrumento firmado

La restricción que más atención merece es un piso de validez, no un techo. Circle rechaza cualquier autorización cuyo validBefore esté a menos de tres días en el futuro, con el código de error authorization_validity_too_short. El GatewayEvmScheme del lado servidor, en correspondencia, fija maxTimeoutSeconds en 604900 — siete días más un pequeño colchón.

La razón es operativa: Gateway necesita tiempo suficiente para meter la autorización en un lote de settlement. La consecuencia es un perfil de riesgo. Un TransferWithAuthorization firmado es un instrumento al portador. En el scheme exact plano típicamente vive segundos antes de quemarse on-chain. Acá vive días, en manos del vendedor o del facilitator, y la única defensa contra replay es la unicidad del nonce de 32 bytes — reusar uno devuelve nonce_already_used, pero el comprador no tiene camino de cancelación una vez que la firma salió.

Para un agente que hace miles de pagos sub-centavo por minuto, esto significa miles de autorizaciones vivas en cualquier momento. La exposición está acotada por el balance de Gateway, que es justamente el punto de depositar en vez de otorgar un allowance. Pero la contabilidad no es la misma que en el scheme plano, y tratar un nanopayment como "liquidado" en el momento en que la API responde es una decisión de crédito, no un hecho criptográfico. Hicimos el mismo argumento sobre settlement diferido en el deep dive del scheme batch-settlement: el compromiso y el dinero quedan separados en el tiempo, y alguien es dueño de ese hueco.

Lo que el vendedor realmente escribe

La integración del vendedor es lo bastante chica como para leerla completa. Circle publica un middleware de Express en @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",
});

// Una línea convierte una ruta en recurso pago
app.get("/premium-data", gateway.require("$0.01"), (req, res) => {
  const { payer, amount, network } = req.payment;
  res.json({ secret: "...", paid_by: payer });
});

Por debajo, gateway.require() devuelve 402 cuando no hay pago válido y llama al endpoint Settle x402 Payment cuando lo hay. Para stacks que no son Express existe BatchFacilitatorClient, con verify(), settle() y getSupported() — la misma superficie de tres verbos del facilitator que mapeamos en nuestro deep dive del facilitator, y por eso Gateway encaja en servidores x402 existentes sin reescritura.

Una sutileza de la referencia del SDK es reveladora. El ExactEvmScheme base de los paquetes x402 estándar descarta el campo extra al construir los payment requirements. Los clientes de Gateway necesitan extra.verifyingContract para armar una firma EIP-712 válida, así que Circle publica GatewayEvmScheme, que lo preserva. Un vendedor que cablee Gateway dentro de x402ResourceServer sin esa subclase va a emitir respuestas 402 que los compradores de Gateway no pueden firmar.

Del lado comprador, CompositeEvmScheme es la pieza que mantiene honesto al ecosistema: rutea al scheme de lote cuando los requirements llevan extra.name === "GatewayWalletBatched", y cae al scheme exact on-chain estándar en cualquier otro caso. El batching es una opción del array accepts, no un reemplazo.

El ancla de confianza es un AWS Nitro Enclave

Los balances off-chain necesitan una razón para ser creídos. La respuesta de Circle es atestación por hardware.

Gateway corre la lógica de batching dentro de un AWS Nitro Enclave, que verifica cada firma EIP-3009 antes de incluirla en un lote, computa los cambios netos de balance entre todos los pagos, y firma el resultado del lote con la clave privada del enclave. Esa clave está protegida por AWS KMS bajo políticas de acceso basadas en atestación, de modo que solo la imagen auditada del enclave puede usarla — Circle afirma que ni sus propios operadores pueden extraerla. El contrato Gateway Wallet después verifica la firma del enclave on-chain antes de aplicar cualquier lote, y revierte si la firma es inválida o viene de un firmante no autorizado. Los Nitro Enclaves además producen documentos de atestación verificables de forma independiente.

Es un diseño coherente, y vale la pena nombrar con precisión qué da y qué no. Da infalsificabilidad: los pagos solo se procesan desde autorizaciones firmadas con la clave privada del comprador, así que Circle no puede inventar un débito. No da resistencia a la censura ni garantías de ordenamiento — Gateway decide cuándo se corta un lote y qué netea contra qué. La salida de emergencia es el retiro trustless a 7 días, que es un backstop de liveness, no un mecanismo de tiempo real.

El estado del balance se rastrea a lo largo del pipeline, y el SDK lo expone como total, available, withdrawing y withdrawable. Las transferencias individuales pasan por received, batched, confirmed, completed y failed, consultables por UUID con getTransferById() o en bloque con searchTransfers() con paginación por cursor. Si vas a pasar ingresos por aquí, esos dos endpoints son tu conciliación.

Las restricciones que Circle no lidera

Cuatro, todas documentadas, todas estructurales.

Solo cuentas externas (EOA). Nanopayments y el batch settlement de x402 requieren firmas de EOA y no soportan ERC-1271. La razón es mecánica: el camino de lote verifica las autorizaciones EIP-3009 off-chain usando ecrecover, que las firmas de contrato no satisfacen. Las transferencias estándar de Gateway sí soportan ERC-1271. Esta es la tensión más filosa de todo el diseño, porque la arquitectura de wallet de agente hacia la que convergió la industria — smart accounts con session keys y permisos acotados, que cubrimos en el deep dive de account abstraction — es exactamente la arquitectura excluida acá. Para usar Nanopayments hoy, tu agente sostiene una clave privada cruda.

Solana queda afuera. Gateway soporta Solana en la capa de balance, pero la columna de Nanopayments dice No. Cualquier comprador multi-rail que trate el settlement en SVM como camino de primera clase necesita un mecanismo aparte ahí.

La latencia de fondeo es real. Trece a diecinueve minutos para acreditar un depósito en cadenas ancladas a Ethereum es una mala experiencia para un agente que se quedó sin balance a mitad de una tarea. Circle apunta a servicios de depósito rápido de terceros, nombrando a Eco como ejemplo, mientras aclara explícitamente que no los endosa, mantiene ni audita. Es un disclaimer honesto y también una admisión de que el on-ramp está sin resolver.

El pricing de los nanopayments no está publicado. La referencia de fees de Circle cubre las transferencias de Gateway: 0.005% (0.5 basis points) en transferencias crosschain, más una fee de gas por cadena origen — $1.00 en Ethereum, $0.15 en Solana, $0.05 en HyperEVM, $0.02 en Avalanche, $0.01 en Arbitrum, Base, Sonic y World Chain, $0.0015 en OP y Polygon PoS, $0.001 en Sei y Unichain — más una fee plana de $0.05 del Forwarding Service si usas el servicio de Circle para el mint de destino. Los retiros en la misma cadena no pagan fee de transferencia. Lo que la documentación no declara es un cargo por nanopayment. "Gas-free" es una afirmación sobre el gas, y la página de batching describe los costos como "near zero" en lugar de cero. Modela el retiro, no solo el pago: la diferencia entre retirar a Unichain y retirar a Ethereum son tres órdenes de magnitud.

Dónde encaja esto en el stack

Nanopayments es el segundo intento serio de romper el piso de gas para x402, y los dos intentos tienen modelos de confianza opuestos. El scheme batch-settlement de la especificación de x402, que nació de la propuesta deferred de Cloudflare, es credit-backed por defecto: el vendedor acepta un compromiso ligado a identidad y lo redime después. El de Circle es capital-backed: el dinero del comprador ya está dentro de un contrato Gateway Wallet antes del primer request, y la autorización gira contra eso.

Capital-backed es la posición más fuerte para el vendedor y la más exigente para el comprador. Requiere prefondeo, que es exactamente la fricción que el walk-up de x402 fue diseñado para eliminar. No es una contradicción — es una segmentación. Walk-up con exact para el primer contacto con una contraparte desconocida, giro contra balance para la relación ya establecida. Trazamos esa línea en nuestro árbol de decisión Bearer versus walk-up, y Gateway se ubica del lado fondeado.

El contexto de distribución es Circle Agent Stack, anunciado el 11 de mayo de 2026, que empaqueta Agent Wallets con controles de política, un Agent Marketplace para descubrimiento de servicios, Circle CLI como plano de control, Circle Skills, y Nanopayments como el rail. En ese anuncio Circle reportó $24.24 millones procesados vía x402 en los 30 días previos al 29 de abril, con 99.8% del valor transaccionado liquidado en USDC. Ese segundo número es el que hay que retener: el volumen de pagos agénticos que existe hoy es efectivamente todo USDC, y por eso que el emisor construya la capa de batching no es un evento neutral.

Qué significa para LLM4Agents

Nuestro problema de billing es el piso de gas, reformulado. Una fracción grande de las llamadas de inferencia por el gateway cuesta menos de un centavo — completions cortas en modelos chicos, embeddings, pasadas de clasificación. Lo resolvimos internamente con reserve, proxy y settle, agregando el consumo contra un balance fondeado y conciliando después, como describimos en el post de internals de facturación. Circle ahora construyó la misma forma como infraestructura pública: fondeás una vez, autorizás off-chain por request, liquidás en bloque.

Qué habilita: un balance del lado comprador que no tenemos que custodiar. Un agente que sostiene USDC en un Gateway Wallet puede pagar por request sin una cuenta prepaga de nuestro lado y sin gas por llamada, y la autorización que firma es verificable por nosotros antes de servir un token. Para los patrones de billing medido que describimos con el scheme upto, donde el monto final solo se conoce después de la completion, el batching es complementario y no competidor: la autorización se firma por el máximo, y la llamada de settlement lleva el número real.

Qué amenaza: la fragmentación del stack comprador. Si una porción significativa de los agentes se estandariza sobre un balance de Gateway, los vendedores que solo publiquen la opción exact plana se vuelven inalcanzables para ellos, y el array accepts pasa a ser la superficie real de interoperabilidad. Es manejable — CompositeEvmScheme existe precisamente para eso — pero significa que nuestras respuestas 402 necesitan llevar más de una opción y nuestra capa de settlement más de un camino. También significa que un solo emisor se sienta entre una porción creciente de los pagos de agentes y la cadena, con discreción sobre el timing de los lotes. Es una dependencia que conviene medir antes de que convenga adoptarla.

Dónde encaja: una entrada adicional en accepts y un camino adicional de settlement en billing. No un reemplazo del walk-up de x402, y no una razón para dejar de agregar internamente.

Cómo mantenerse en la frontera

Pasos concretos, en el orden en que creemos que deberían darse.

1. Agregar la opción, mantener el default. Emitir una segunda entrada en el array accepts con extra.name = "GatewayWalletBatched" y el verifyingContract correcto por red, detrás de un flag, con la entrada exact on-chain existente listada primero. Del lado servidor esto implica GatewayEvmScheme en lugar del scheme base, para que el bloque extra sobreviva hasta la respuesta 402.

2. Medir antes de confiar. Registrar el identificador de transferencia de cada respuesta de settle y consultar searchTransfers() para construir una distribución de latencia de received a completed y una tabla de frecuencia de códigos de error. La cadencia de los lotes no está documentada; es descubrible. Hasta tener dos semanas de esos datos, los pagos en lote deberían tratarse como ingreso pendiente, no como ingreso contabilizado.

3. Precificar la ventana de autorización como crédito. Una validez mínima de tres días significa que las autorizaciones pendientes se acumulan. Poner un tope de exposición por agente por ventana de settlement, alertar sobre la brecha entre autorizado y liquidado, y conciliar diariamente contra el balance de Gateway en lugar de contra nuestro propio ledger.

4. Mantener separadas las clases de wallet. Los agentes que usan smart accounts no pueden pagar por esta vía. No migrarlos, y no construir un flujo que degrade silenciosamente un agente a EOA cruda para desbloquear el batching. Seguir el soporte de ERC-1271 en el camino de lote como la señal de que las dos clases pueden fusionarse.

5. Retirar de forma deliberada. Los balances del vendedor deberían barrerse de forma programada hacia un destino de gas bajo — las fees publicadas ponen a Sei y Unichain en $0.001 contra Ethereum en $1.00 — y el umbral de barrido debería salir del volumen medido, no de una estimación.

6. Documentar la cobertura. Qué endpoints nuestros aceptan batching, en qué redes, y con qué fallback, publicado donde un agente comprador pueda leerlo. El problema de descubrimiento no se resuelve agregando una opción de pago que nadie puede encontrar.

El piso de gas nunca fue una ley de la naturaleza. Fue un artefacto de liquidar cada pago por separado, y dos grupos distintos ya lo removieron de dos maneras distintas. Lo que queda es la parte que el batching no puede remover: alguien sostiene el hueco entre la promesa y el dinero, y la pregunta de ingeniería es siempre solo quién, por cuánto tiempo, y contra qué colateral.