Circle Nanopayments explicado: pagos en USDC sin gas desde 0,000001 $

Las blockchains tienen un precio mínimo. Cada transferencia on-chain paga gas, así que un pago más pequeño que su propio costo de gas no tiene ningún sentido económico: en la mayoría de las redes, cualquier cosa por debajo de un centavo nace muerta. Y justo ahí, en ese umbral, es donde quiere vivir la próxima ola del comercio. Los agentes de IA no compran como las personas: pagan por llamada a una API, por segundo de cómputo, por cada lectura de un conjunto de datos, y cada uno de esos eventos vale una fracción de centavo.

Circle Nanopayments elimina ese mínimo. Los pagos se firman off-chain sin costo de gas, se verifican en milisegundos y se liquidan on-chain en lotes de miles, de modo que el gas de una sola transacción se reparte entre todos los pagos que contiene. El resultado: pagos en USDC desde 0,000001 $, sin gas para el comprador ni para el vendedor, ya operativos en mainnet en 12 cadenas EVM.

En este artículo vamos a desmenuzar cómo funciona, lo compararemos con el flujo estándar de x402 que explicamos en nuestro tutorial anterior sobre x402 y después construiremos el circuito completo en Node.js: una API Express con un precio de 0,0001 $ por petición y un cliente comprador que deposita una sola vez y paga cada llamada con nada más que firmas.

¿Qué es Circle Nanopayments?

Nanopayments es un riel de pagos que Circle construyó sobre dos piezas ya existentes:

  • Circle Gateway, el saldo unificado de USDC de Circle. Depositas USDC en un contrato Gateway Wallet no custodio en cualquier cadena compatible, y ese depósito se convierte en un único saldo multicadena que puedes gastar o retirar en cualquier otra cadena compatible en menos de 500 ms.
  • El protocolo x402, el estándar abierto que pone a trabajar el código de estado HTTP 402 Payment Required: los servidores anuncian un precio en un formato legible por máquinas y los clientes lo pagan con una autorización de stablecoin firmada.

Nanopayments combina ambas: los compradores gastan su saldo de Gateway mediante autorizaciones firmadas al estilo x402, y Circle Gateway actúa como facilitador, verifica cada pago al instante y los liquida on-chain en bloque. Circle lo lanzó en mainnet en abril de 2026 como parte de su Agent Stack, con primeros usuarios como Alchemy, QuickNode, Goldsky y blockrun.ai, y compatibilidad con Ethereum, Base, Arbitrum, OP Mainnet, Polygon PoS, Avalanche, Unichain, Sonic, World Chain, Sei, HyperEVM y Arc.

La economía: por qué agrupar en lotes lo cambia todo

La idea central es sencilla. Si cada pago es su propia transacción on-chain, cada pago paga el gas completo, y el pago más pequeño viable ronda los 0,01 $ incluso en L2 baratas. Si diez mil pagos comparten una sola transacción de liquidación, el gas por pago se divide entre diez mil, y un pago de 0,000001 $ pasa de repente a tener un costo adicional insignificante.

Liquidación pago a pago frente a liquidación por lotes: cinco transacciones individuales que pagan gas cada una, frente a miles de pagos compensados por Circle Gateway en una única transacción on-chain
Agrupar en lotes amortiza el gas de una transacción entre todos los pagos que contiene, lo que baja el pago mínimo viable de unos 0,01 $ a 0,000001 $.

Gateway hace algo más que concatenar pagos: los compensa (netting). Recoge las autorizaciones firmadas off-chain, calcula la variación neta del saldo de cada cuenta en todo el lote y aplica on-chain solo esas variaciones netas. Un comprador que hizo 5000 llamadas al mismo vendedor se convierte en una única actualización de saldo, no en 5000 transferencias. Eso es lo que permite al sistema absorber flujos de pagos a velocidad de máquina sin que la cadena tenga que soportar una carga a ese mismo ritmo de máquina.

Liquidación pago a pagoNanopayments (por lotes)
Transacciones on-chain1 por pago1 por cada varios miles de pagos
Gas por pagogas completo, cada vezamortizado en el lote
Pago mínimo en la práctica~0,01 $0,000001 $
Latencia del pagosegundos (confirmación de bloque)milisegundos (verificación off-chain)
Quién paga el gasel comprador o el facilitador, en cada pagoGateway, una vez por lote

El ciclo de vida de un pago

Este es el recorrido completo de un nanopago, desde que se aportan los fondos hasta la liquidación final:

Diagrama de secuencia de Nanopayments: depósito único, negociación 402, firma EIP-3009 off-chain, liquidación instantánea a través de Circle Gateway y liquidación on-chain periódica por lotes
El ciclo de vida de Nanopayments. Los pasos 1 a 8 se repiten en cada petición sin gas; los pasos 0 y 9 son las únicas transacciones on-chain.
  1. Depósito (una sola vez). El comprador deposita USDC en el contrato Gateway Wallet. Es la única transacción por la que el comprador paga gas.
  2. Petición y negociación. El comprador solicita un recurso de pago; el vendedor responde 402 Payment Required con una cabecera PAYMENT-REQUIRED que describe el precio, la red y el destino.
  3. Firma. El comprador firma off-chain un mensaje EIP-3009 TransferWithAuthorization que autoriza a Gateway a mover exactamente el importe anunciado de su saldo al vendedor. Cero gas.
  4. Liquidación y entrega. El comprador reintenta la petición con la cabecera PAYMENT-SIGNATURE. El vendedor reenvía la autorización al endpoint settle de Gateway; Gateway verifica la firma, bloquea los fondos del comprador, abona el saldo del vendedor y responde en unos cientos de milisegundos. El vendedor entrega el recurso de inmediato.
  5. Lote on-chain. Periódicamente, Gateway compensa todas las autorizaciones pendientes y envía una única transacción on-chain. Una vez confirmada, los vendedores pueden retirar su saldo a cualquier cadena compatible.

La propiedad clave: en el paso 4 el pago del vendedor ya está garantizado y su saldo abonado, aunque todavía no se haya tocado la cadena. La latencia de verificación y la finalidad de la liquidación están desacopladas, y eso es lo que hace viable cobrar por petición dentro de una ruta crítica del código.

Nanopayments frente a x402 estándar

Si leíste nuestro tutorial sobre cómo proteger una API con un pago x402, el flujo anterior te resultará familiar: el mismo código de estado, las mismas cabeceras, las mismas firmas EIP-3009. Todas las diferencias están en dónde se guarda el dinero y en cómo se liquida:

x402 estándar (esquema exact)Nanopayments
Fondos del compradorUSDC en la wallet del compradorUSDC depositados en un saldo de Gateway
Liquidaciónuna tx on-chain por pago, justo después de la verificaciónabono off-chain instantáneo, lote on-chain más tarde
Facilitadorel que elijas (x402.org, Coinbase CDP, ...)Circle Gateway
Rango de precios razonabledesde 0,001 $desde 0,000001 $
Qué recibe el vendedorUSDC en su wallet, en cada pagosaldo de Gateway, retirable en cualquier cadena compatible
Tipo de wallet del compradorcualquier EOAsolo EOA (sin smart accounts)

Las dos opciones son complementarias. Un informe de 5 $ que se vende unos cientos de veces al día está perfectamente cubierto con x402 estándar y llega directo a tu wallet. Una llamada de inferencia de 0,0001 $ que se sirve un millón de veces al día solo funciona por lotes. Como ambas hablan x402, un vendedor puede exponer las dos y dejar que cada comprador elija la que admita su cliente. Para saber de qué lado de esa línea cae tu API, introduce tu costo y tu volumen en nuestra calculadora de precios x402 gratuita.

Arquitectura y modelo de confianza

Arquitectura de Nanopayments: comprador con wallet EOA y GatewayClient, API Express del vendedor con middleware de Gateway, facilitador Circle Gateway con verificación en TEE y la capa de liquidación de las 12 cadenas compatibles
Las piezas en movimiento. El comprador habla HTTP con el vendedor; solo Gateway y el depósito único llegan a tocar una cadena.

La pregunta obvia sobre los lotes: mientras los pagos esperan en un lote, ¿qué impide que Circle los manipule? La respuesta del diseño es un Trusted Execution Environment (entorno de ejecución de confianza). Cada firma se verifica y cada lote se calcula dentro de un AWS Nitro Enclave, y el enclave firma el resultado del lote con una clave a la que solo puede acceder la imagen auditada del enclave; ni siquiera los operadores de Circle pueden extraerla. El smart contract Gateway Wallet verifica la firma del enclave antes de ejecutar un lote y revierte cualquier cosa no autorizada, y el enclave genera atestaciones criptográficas que cualquiera puede verificar de forma independiente.

Además, los depósitos siguen siendo no custodios: los fondos están en el contrato Gateway Wallet, no en manos de Circle, y el contrato incluye una vía de retiro de 7 días que no exige confiar en nadie (trustless), así que puedes salir con tus fondos incluso si Gateway deja de funcionar. Por eso mismo las autorizaciones de pago deben seguir siendo válidas durante al menos 7 días más un margen: la firma tiene que sobrevivir al peor escenario de liquidación.

Tutorial: acepta y envía nanopagos en Node.js

Construyamos ambos lados en testnet. El vendedor es una API Express que vende /premium-data a 0,0001 $ por petición; el comprador es un script que deposita una vez y luego paga cada llamada solo con firmas. Todo usa el SDK @circle-fin/x402-batching de Circle.

Requisitos previos

  • Node.js 22.6+ (ejecuta TypeScript directamente mediante type stripping, así que no hay paso de compilación)
  • Dos direcciones EOA: una para recibir fondos (el vendedor, basta con la dirección) y otra para pagar (el comprador, se necesita la clave privada)
  • USDC de testnet para el comprador desde el faucet de Circle, más un poco del token nativo de gas para la única transacción de depósito
  • Una advertencia desde el principio: el comprador debe ser una EOA simple. Las cuentas de smart contract no son compatibles, porque Gateway verifica las firmas off-chain con ecrecover, que es incompatible con las firmas de contrato EIP-1271.

Parte 1: el vendedor

Crea el proyecto del servidor:

mkdir nano-seller && cd nano-seller npm init -y && npm pkg set type=module npm pkg set scripts.start="node --env-file=.env server.ts" npm install @circle-fin/x402-batching @x402/core @x402/evm viem express typescript npm install --save-dev @types/node @types/express

Configura la dirección de recepción mediante el entorno:

.env
SELLER_ADDRESS=0xYourSellerAddress

Y después, el servidor completo:

server.ts
import express from 'express'
import { formatUnits } from 'viem'
import { createGatewayMiddleware } from '@circle-fin/x402-batching/server'

type PaidRequest = express.Request & {
  payment?: {
    verified: boolean
    payer: string
    amount: string
    network: string
    transaction?: string
  }
}

const sellerAddress = process.env.SELLER_ADDRESS as `0x${string}` | undefined
if (!sellerAddress) throw new Error('SELLER_ADDRESS not configured')

const gateway = createGatewayMiddleware({
  sellerAddress,
  facilitatorUrl: 'https://gateway-api-testnet.circle.com',
})

const app = express()

app.get('/premium-data', gateway.require('$0.0001'), (req: PaidRequest, res) => {
  const { payer, amount, network } = req.payment!
  console.error(`Paid ${formatUnits(BigInt(amount), 6)} USDC by ${payer} on ${network}`)

  res.json({
    signal: 'Funding rates flipped negative on three venues.',
    paid_by: payer,
  })
})

app.get('/free', (_req, res) => {
  res.json({ status: 'ok' }) // Routes without gateway.require() stay free.
})

app.listen(3000, () => console.error('Listening on http://localhost:3000'))

Esa es toda la integración del vendedor: un middleware y un precio como cadena en dólares. gateway.require('$0.0001') responde a las peticiones no pagadas con un 402 y una oferta codificada en base64 en la cabecera PAYMENT-REQUIRED; cuando llega una petición con un PAYMENT-SIGNATURE válido, el middleware llama al endpoint settle de Gateway, obtiene el pago garantizado en unos cientos de milisegundos, adjunta los detalles a req.payment y deja que se ejecute tu handler. El código de tu handler nunca toca una blockchain.

Por defecto, el middleware acepta pagos de todas las redes compatibles con Gateway; puedes restringirlo con la opción networks: ['eip155:5042002'] si quieres fijar cadenas concretas. Fíjate en el precio: 0,0001 $ es una décima parte del mínimo práctico de x402 estándar, y podrías bajar cuatro órdenes de magnitud más.

Arráncalo y pruébalo sin pagar:

npm start curl -i http://localhost:3000/premium-data
respuesta 402
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6Mi...

Parte 2: el comprador

En un proyecto aparte:

mkdir nano-buyer && cd nano-buyer npm init -y && npm pkg set type=module npm pkg set scripts.pay="node --env-file=.env pay.ts" npm install @circle-fin/x402-batching viem typescript npm install --save-dev @types/node
.env
PRIVATE_KEY=0xYourBuyerPrivateKey

Todo el comprador cabe en un solo script: consulta los saldos, deposita una vez si hace falta y luego paga.

pay.ts
import { GatewayClient } from '@circle-fin/x402-batching/client'

const privateKey = process.env.PRIVATE_KEY as `0x${string}` | undefined
if (!privateKey) throw new Error('PRIVATE_KEY not configured')

const client = new GatewayClient({
  chain: 'arcTestnet',
  privateKey,
})

// 1. Where do we stand?
const balances = await client.getBalances()
console.log(`Wallet USDC:  ${balances.wallet.formatted}`)
console.log(`Gateway USDC: ${balances.gateway.formattedAvailable}`)

// 2. One-time top-up of the Gateway balance (USDC has 6 decimals).
if (balances.gateway.available < 1_000_000n) {
  console.log('Depositing 1 USDC into the Gateway Wallet...')
  const deposit = await client.deposit('1')
  console.log(`Deposit tx: ${deposit.depositTxHash}`)
}

// 3. Pay for the resource. No gas, no transaction: just a signature.
const { data, status } = await client.pay('http://localhost:3000/premium-data')
console.log(`Status: ${status}`)
console.log('Response:', data)

// 4. The balance moved by exactly $0.0001.
const updated = await client.getBalances()
console.log(`Gateway USDC after: ${updated.gateway.formattedAvailable}`)

Ejecútalo contra tu servidor local:

npm run pay
Wallet USDC: 10.0 Gateway USDC: 0.0 Depositing 1 USDC into the Gateway Wallet... Deposit tx: 0x83f2...9a1c Status: 200 Response: { signal: 'Funding rates flipped negative on three venues.', paid_by: '0xYourBuyerAddress' } Gateway USDC after: 0.9999

Detrás de client.pay(), el SDK hizo la primera petición, interpretó la oferta del 402, firmó la autorización EIP-3009 contra el dominio GatewayWalletBatched, reintentó con la cabecera PAYMENT-SIGNATURE y devolvió la respuesta pagada. Llámalo en un bucle y verás que el saldo baja 0,0001 en cada llamada sin gastar nada de gas; el depósito del paso 2 no vuelve a ejecutarse. Si quieres comprobar si una URL cualquiera acepta pagos de Gateway antes de pagar, client.supports(url) hace exactamente eso.

Retira tus ingresos

Las dos partes guardan el valor como saldo de Gateway, y Gateway es multicadena por diseño. Retira en la misma cadena o en cualquier otra compatible:

withdraw.ts
// Same chain as the client: immediate.
const sameChain = await client.withdraw('5')
console.log(`Withdrew ${sameChain.formattedAmount} USDC - tx: ${sameChain.mintTxHash}`)

// Or receive on a different chain entirely.
const crossChain = await client.withdraw('5', { chain: 'baseSepolia' })
console.log(`Withdrew to ${crossChain.destinationChain}`)

Es un detalle discreto pero muy potente para los vendedores: puedes aceptar nanopagos de compradores en una docena de cadenas y retirar el total acumulado en la única cadena donde vive tu tesorería.

Paso a mainnet

Tres cambios llevan el tutorial a producción:

  1. URL del facilitador: apunta facilitatorUrl a https://gateway-api.circle.com en lugar del endpoint de testnet.
  2. Cadena: cambia la cadena del GatewayClient a una red mainnet (por ejemplo Base; consulta la lista de cadenas compatibles de Circle para ver los identificadores exactos) y aporta USDC reales al comprador.
  3. Gestión de claves: ahora la clave privada del comprador autoriza gastos reales. Guárdala en un gestor de secretos, dale a la wallet un saldo operativo pequeño en lugar de fondos de tesorería y limita el precio máximo por petición en la lógica de tu cliente. El vendedor sigue sin guardar ningún secreto, solo una dirección pública de recepción.

Casos de uso: lo que hacen posible los pagos de menos de un centavo

Un pago de 0,000001 $ que funciona es una primitiva nueva, y los productos interesantes son justo los que el antiguo mínimo de 0,01 $ hacía imposibles:

  • Pagos agénticos. Un agente de IA con saldo en Gateway puede comprar datos, herramientas y cómputo de forma autónoma, pagando por llamada sin una persona de por medio, sin formulario de tarjeta y sin clave de API. Es el caso de uso estrella: x402 procesó más de 100 millones de dólares en pagos pocos meses después de su lanzamiento, y Circle presenta Nanopayments como el riel nativo para máquinas que lo sustenta.
  • Facturación de verdad por uso. Pon a tu API el precio de su costo marginal: 0,0001 $ por petición, 0,000005 $ por fila, por token, por milisegundo de GPU. Sin suscripciones, sin sistemas de créditos prepagados, sin infraestructura de facturación mensual.
  • Marketplaces máquina a máquina. Servicios que compran a otros servicios: un scraper que paga a un proxy por petición, un agente que paga a otro agente por una subtarea, un oráculo que vende datos sueltos. A frecuencia de máquina, solo la liquidación por lotes aguanta el ritmo.
  • Dinero en streaming. Contenido de pago por segundo, alquiler de cómputo por minuto, entrega de archivos por fragmento: cualquier recurso medido puede liquidarse de forma continua con pagos demasiado pequeños para notarlos uno a uno.

Límites y trampas habituales

  • Solo wallets EOA. La verificación off-chain de Gateway con ecrecover descarta las smart accounts y las firmas EIP-1271. Si hoy tus agentes viven en smart wallets, necesitarán una clave de gasto EOA para los nanopagos.
  • Los compradores aportan fondos por adelantado. El modelo de depósito implica que los fondos del comprador se quedan en el saldo de Gateway antes de gastarse. Es no custodio y tiene una salida trustless de 7 días, pero sigue siendo un saldo inmovilizado que hay que gestionar, a diferencia del x402 normal, donde los fondos se quedan en la wallet hasta cada pago.
  • Las autorizaciones deben tener una validez larga. Las firmas de pago necesitan una validez de al menos 7 días más un margen (maxTimeoutSeconds alrededor de 604.900), consecuencia directa de la ventana de retiro trustless. No implementes a mano expiraciones más cortas: el endpoint settle las rechazará.
  • Solana es la excepción. El saldo unificado de Gateway incluye Solana, pero Nanopayments hoy funciona solo en EVM; las 12 cadenas con nanopagos habilitados son todas EVM.
  • No es para transferencias grandes. Por encima de un centavo por pago, aproximadamente, el x402 estándar con liquidación pago a pago es más simple y le da al vendedor finalidad on-chain inmediata. Agrupar en lotes solo compensa su complejidad por debajo de esa línea.

Preguntas frecuentes

¿Circle Nanopayments es custodio? No. Los depósitos están en el smart contract Gateway Wallet, los lotes se calculan y se firman dentro de un TEE con atestación al que ni siquiera los operadores de Circle tienen acceso, y existe una vía de retiro trustless de 7 días que no depende de la disponibilidad de Circle.

¿El comprador o el vendedor pagan gas en algún momento? Solo el depósito único del comprador (y cualquier retiro) es una transacción on-chain. Todos los pagos intermedios son firmas off-chain; Gateway paga el gas de la liquidación por lotes.

¿Cuál es el pago más pequeño posible? 0,000001 $, una millonésima de dólar, que además es una unidad base de USDC.

¿Necesito claves de API de Circle? No. El endpoint settle no exige autenticación y el sistema no requiere permisos (permissionless): al vendedor le basta con una dirección de recepción y al comprador, con una EOA con fondos.

Dónde encaja

Nanopayments completa un stack que llevamos todo el año construyendo con nuestros clientes: x402 le pone una etiqueta de precio a HTTP, y la liquidación por lotes de Gateway le añade cuatro decimales más a esa etiqueta. Juntos convierten "cobrar exactamente lo que cuesta una petición" en un modelo de facturación real para APIs, agentes y productos de datos, sin tener que construir un sistema de facturación.

En Etherwave Labs integramos toda la familia x402 de principio a fin: definimos el precio de tu API y la protegemos con pagos, conectamos Gateway u otro facilitador y equipamos a los agentes con wallets de gasto seguras. Explicamos el protocolo en general en nuestra página del servicio x402, y si quieres ingresos en USDC por petición en producción, contáctanos.

Más artículos

¿Quieres llevar tu proyecto al siguiente nivel?

Contáctanos hoy para ver cómo podemos ayudarte a alcanzar tus objetivos en el sector blockchain.