TL;DR
x402 es un protocolo abierto de Coinbase que revive el código HTTP 402 Payment Required como base para pagos machine-to-machine. Un servidor puede requerir pago para cualquier endpoint API respondiendo con HTTP 402 y un desafío de pago estructurado; el cliente — típicamente un agente IA — firma una autorización de pago en stablecoin y reintenta la petición con el pago adjunto como header HTTP. Diseñado para settlement sub-céntimo en Base (USDC Layer-2), usa firmas EIP-3009 para autorización gasless, y crecientemente adoptado por proveedores de API sirviendo tráfico de agentes IA.
Por qué HTTP 402 necesitaba revivir
HTTP 402 ha estado reservado en la especificación HTTP desde 1997, con la descripción “reserved for future use.” Por casi tres décadas no hubo significado a nivel de protocolo ampliamente acordado, y los pocos intentos de usarlo (iAP de Apple, micropayments browser-based) fallaron a nivel de estándares — usualmente porque requerían un intermediario centralizado en el que nadie confiaba para operar.
Las condiciones que previnieron la adopción han cambiado. Las stablecoins existen como activo de settlement que no requiere confianza en intermediario específico; los agentes IA existen como caso de uso donde el pago machine-to-machine es necesario más que opcional; el pago HTTP-nativo es genuinamente más eficiente que facturación out-of-band para comercio sub-segundo; y los rollups L2 con comisiones sub-céntimo hacen económicamente racionales los micropagos.
El flujo del protocolo
Una transacción x402 completa se ve así:
Paso 1: el cliente hace una petición HTTP estándar a un recurso protegido. Por ejemplo, un agente IA llama a una API paywalled de generación de imágenes.
Paso 2: el servidor responde con HTTP/1.1 402 Payment Required e incluye un body JSON especificando el precio, la dirección receptora, el chain ID, los esquemas de pago soportados, y un nonce único. Una respuesta típica especifica "scheme": "exact", "network": "base", "asset": "USDC", y un monto en la unidad más pequeña (ej., "amount": "1000" para 0.001 USDC).
Paso 3: el cliente construye una firma EIP-3009 TransferWithAuthorization, que es una firma de typed-data autorizando al servidor a transferir el monto USDC especificado desde la wallet del cliente al receptor. Críticamente, el cliente no broadcasta una tx — solo firma. La firma incluye el nonce único del servidor, previniendo replay.
Paso 4: el cliente reintenta la petición original, esta vez incluyendo la firma en un header HTTP X-PAYMENT.
Paso 5: el servidor verifica la firma, opcionalmente llama a un servicio facilitator para liquidar el pago on-chain (o lo batchea con otros), y sirve la respuesta.
Por qué EIP-3009 específicamente
La elección de EIP-3009 sobre alternativas como EIP-2612 (permit) o transfer directo refleja tres prioridades de diseño. Primero, el cliente no paga gas: el receptor paga el costo on-chain, lo que significa que un agente con balance USDC mínimo puede transaccionar sin tener ETH para gas. Segundo, autorización off-chain: la firma misma es barata (sin operación on-chain), así que patrones de pago de alta frecuencia son económicamente viables. Tercero, monto y receptor explícitos: a diferencia de flujos basados en permit, que autorizan a un spender a transferir cualquier monto hasta un cap, EIP-3009 ata la firma a un monto y receptor específicos, reduciendo dramáticamente las consecuencias de un servidor mal comportado.
El rol del facilitator
Un facilitator es un servicio opcional que maneja el paso de settlement on-chain en nombre del servidor. El facilitator de referencia de Coinbase acepta el pago firmado, batchea múltiples pagos juntos, los envía a la chain, y retorna confirmaciones. Este patrón es económicamente necesario porque cada pago individual frecuentemente es más pequeño que el costo de gas de liquidarlo individualmente; el batching restaura eficiencia.
Importantemente, el facilitator no se le confían fondos — la firma EIP-3009 ya especifica el receptor. El único rol del facilitator es ser la parte que paga gas y envía la tx. Existen múltiples implementaciones, y el protocolo no asume que deba usarse un facilitator específico.
Cuándo usar x402 vs alternativas
x402 tiene sentido cuando los pagos son frecuentes, pequeños, e HTTP-nativos. Agentes IA llamando a APIs pagas, acceso a contenido financiado por micropagos, llamadas servicio-a-servicio entre agentes en workflows autónomos. El protocolo es menos compelling para transacciones de valor alto (donde el overhead del protocolo es negligible relativo al tamaño y flujos convencionales funcionan bien), para transacciones que requieren flujos complejos de compliance (KYC, AML), o para casos donde la relación buyer-seller es lo suficientemente durable para justificar una suscripción account-based.
Para agentes que necesitan abarcar chains más allá de Base, frameworks intent-based como la competencia de solvers de Halliday encajan mejor. Para agentes que necesitan flujos de aprobación humano-en-el-loop, los controles operativos de Payman añaden valor. Para agentes que necesitan identidad verificable para política merchant-side, la capa de pasaporte KYA de Skyfire extiende lo que x402 provee a nivel de pago.
Preguntas abiertas
Tres preguntas de estandarización quedan no resueltas. Primero, identidad de agente: x402 mismo no especifica cómo el servidor debería saber qué agente (o qué owner de agente) está pagando. La capa KYA de Skyfire intenta llenar esto, pero no existe consenso sobre la interfaz estándar. Segundo, resolución de disputas: los pagos HTTP-nativos son finales. No hay mecanismo de chargeback built-in. Para comercio de agentes de valor alto, esto es un gap real. Tercero, chain abstraction: aunque el protocolo es chain-agnostic en principio, la economía de red funciona mejor en un subset pequeño de chains. Estandarizar cómo un cliente y servidor negocian qué chain usar, en presencia de USDC puenteado, es discusión en curso en el working group x402.