El protocolo x402 en 2026: historia, mecánica y lo que va a lanzar LLM4Agents encima

El código de estado HTTP 402 fue reservado en la especificación HTTP/1.0 de 1991 y etiquetado "Payment Required" — y después no pasó nada con él durante treinta y cuatro años. En mayo de 2025, Coinbase publicó un protocolo funcional detrás de ese status code. En abril de 2026, ese protocolo entró a la Linux Foundation con veintidós founding members entre los que están Google, AWS, Stripe, Visa, Mastercard, American Express, Microsoft, Shopify, Cloudflare, Polygon, la Solana Foundation y las redes de tarjetas mayores. El timing del 4/02 fue a propósito. Este post explica qué es exactamente x402, cómo funciona a nivel de bytes, por qué se convirtió en estándar en 2026, y la capa x402-nativa que LLM4Agents está por poner encima.

Qué es x402, exactamente

x402 es un protocolo de pago HTTP abierto. Un cliente envía una request HTTP normal. Si el servidor requiere pago, responde 402 Payment Required con un header que le dice al cliente cuánto pagar, a dónde, y en qué cadena. El cliente firma una autorización, reintenta la misma request con un header de pago, y el servidor entrega el recurso una vez que un facilitator confirma la transferencia on-chain. El intercambio completo corre sobre HTTP estándar, toma un round trip extra en el peor caso, y funciona igual sea quien sea el caller — un browser, un script curl, o un agente autónomo.

El protocolo es deliberadamente mínimo. No hay creación de cuenta, no hay API key, no hay factura mensual, no hay tier de suscripción. El pago es la credencial. La autorización firmada autentica al caller, mide el request y produce un recibo en la misma vuelta. Tres preocupaciones colapsadas en un round trip.

La spec vive en github.com/coinbase/x402. Los SDKs vienen en TypeScript, Python y Go, con middleware HTTP para Express, Hono, Next.js, axios y fetch.

De status code reservado a estándar de la Linux Foundation

HTTP 402 apareció por primera vez en RFC 1945 en mayo de 1996, formalizando lo que HTTP/1.0 había reservado en 1991. La intención siempre fueron pagos digitales. El mecanismo nunca se materializó. Se intentaron micropagos nativos en el browser dos veces (Flattr, el W3C Web Payments group) y ambas iniciativas se trabaron porque la capa de liquidación no existía — los raíles de tarjeta eran demasiado caros por llamada y demasiado lentos por liquidación para lo que 402 pretendía ser.

Las stablecoins cambiaron la aritmética. Para 2024, USDC y USDT liquidaban en múltiples cadenas en segundos por fracciones de céntimo, y EIP-3009 (desplegado nativamente en USDC y EURC) hizo posible que una wallet firmara una autorización de transferencia que cualquier tercero podía submitir on-chain. Las piezas estaban; alguien tenía que ensamblarlas.

Coinbase lo hizo, y lanzó x402 públicamente en mayo de 2025. La adopción durante el segundo semestre de 2025 fue desigual — una explosión de experimentación en noviembre y luego una caída medible en volumen on-chain durante el primer trimestre de 2026 — pero el movimiento institucional bajo la curva siguió creciendo. El 2 de abril de 2026 ("día 4/02", una fecha que la Linux Foundation eligió con pleno conocimiento del chiste), Coinbase donó x402 a la recién formada x402 Foundation, con intención de founding por parte de Adyen, AWS, American Express, Ampersend.ai, Base, Circle, Cloudflare, Coinbase, Fiserv, Google, KakaoPay, Mastercard, Merit Systems, Microsoft, Polygon Labs, PPRO, Shopify, Sierra, Solana Foundation, Stripe, thirdweb y Visa. Las redes de tarjetas y los cloud providers grandes en la misma sala es la parte que importa: x402 ya no es un proyecto de Coinbase.

A finales de abril de 2026 el protocolo había procesado 165 millones de transacciones a través de aproximadamente 69,000 agentes activos, totalizando alrededor de $50M en volumen acumulado. Solana movió aproximadamente el 65% del volumen de 2026. Los números on-chain están por debajo del pico de noviembre 2025; la adopción institucional no.

El flujo, en bytes

El intercambio x402 más simple tiene tres actores: cliente (a menudo un agente IA), servidor (el dueño del recurso), y facilitator (un tercero opcional pero recomendado que maneja la liquidación on-chain). El intercambio completo:

// 1. El cliente hace una request normal.
GET /v1/chat/completions HTTP/1.1
Host: api.example.com

// 2. El servidor responde 402 con los términos de pago.
HTTP/1.1 402 Payment Required
Content-Type: application/json
X-PAYMENT-REQUIRED: {"scheme":"exact","network":"solana-mainnet","asset":"USDC","amount":"0.001","payTo":"<recipient>","resource":"/v1/chat/completions"}

// 3. El cliente construye la autorización, la firma, reintenta la misma request.
GET /v1/chat/completions HTTP/1.1
Host: api.example.com
X-PAYMENT-SIGNATURE: <autorización firmada en base64>

// 4. El servidor llama al facilitator: verifica + liquida.
// 5. El facilitator envía a la cadena, devuelve confirmación.
// 6. El servidor entrega el recurso.
HTTP/1.1 200 OK
Content-Type: application/json
X-PAYMENT-RECEIPT: <tx-hash>

{"choices":[...]}

Ese es el protocolo completo en el cable. El trabajo interesante está dentro del paso 3 (qué firma el cliente) y el paso 4 (qué hace el facilitator).

Los schemes de firma, en detalle

x402 separa el protocolo de cable del mecanismo on-chain a través de lo que llama "schemes". Tres importan hoy.

EIP-3009 (USDC, EURC en cadenas EVM). Ambos tokens implementan transferWithAuthorization nativamente en sus contratos. El cliente firma un payload de typed-data EIP-712 con siete campos: from, to, value, validAfter, validBefore, nonce, y la firma sobre el hash de typed-data EIP-712. El nonce es un valor aleatorio de 32 bytes, no un contador secuencial — esta es la decisión de diseño que permite que una wallet tenga muchas autorizaciones in-flight en paralelo sin colisión, que es exactamente lo que un agente haciendo requests concurrentes necesita. El facilitator (o cualquiera) envía la autorización al contrato del token; el contrato verifica la firma y transfiere los fondos. El cliente nunca ve gas, nunca tiene el token nativo, nunca broadcastea una transacción.

Permit2 (cualquier ERC-20). Para tokens que no implementan transferWithAuthorization nativamente, el contrato Permit2 de Uniswap provee funcionalidad equivalente por encima: el usuario otorga a Permit2 una aprobación única, luego firma mensajes de transferencia gas-free ruteados por Permit2. El trade-off es una transacción de aprobación inicial que el usuario paga una vez; después de eso, cada transferencia es gas-free para él. Esto es lo que el facilitator de Coinbase CDP usa para soportar USDT, DAI y cualquier otro ERC-20 que no soporte EIP-3009 nativamente.

Solana SPL (USDC, USDT en Solana). Solana no tiene EIP-3009 porque Solana no tiene EIP de nada. El scheme x402 de Solana usa una transacción parcial: el cliente construye una transferencia de token SPL, la firma como pagador del monto del token, y envía la transacción parcial al facilitator. El facilitator co-firma como fee payer y la submitea a un validator. Funcionalmente idéntico a EIP-3009 desde la perspectiva del cliente — sin SOL necesario, sin broadcast manual — pero la primitiva on-chain es distinta.

El desacoplamiento importa: cuando un endpoint x402 añade soporte para, digamos, Sui o Aptos, solo cambia el módulo de scheme. El protocolo a nivel HTTP queda exactamente igual.

Qué hace realmente el facilitator

El facilitator es el único componente de x402 que tiene complejidad real. Su trabajo es tomar una autorización firmada, verificarla criptográfica y económicamente, enviarla a la cadena apropiada, y reportar al servidor del recurso si la transferencia tuvo éxito. Específicamente:

Verificación. Recuperar el firmante de la firma, chequear que el nonce no se haya usado, chequear que validAfter y validBefore abracen el tiempo actual, chequear que el firmante tenga balance suficiente, chequear que la dirección del asset coincida con la que pidió el servidor. Nada de esto requiere tocar la cadena; todo previene submissions desperdiciados.

Liquidación. Para EIP-3009, llamar transferWithAuthorization en el contrato del token. Para Solana SPL, co-firmar como fee payer y submitear. Para Permit2, rutear por el contrato Permit2. El facilitator paga el gas; el servidor del recurso paga al facilitator un fee pequeño bundleado en el precio del protocolo.

Confirmación. Esperar la inclusión (1-2 slots en Solana, 1-2 bloques en la mayoría de EVMs), devolver el hash de transacción al servidor del recurso. El servidor entonces shipea el recurso.

Cualquiera puede correr un facilitator. El CDP de Coinbase corre el más grande hoy, soportando USDC y EURC vía EIP-3009 en Base, Polygon, Arbitrum, World y Solana, más ERC-20s arbitrarios vía Permit2 y tokens SPL en Solana, con un free tier de 1,000 transacciones por mes. Second State corre un facilitator open-source. El registry Pay.sh de la Solana Foundation cataloga facilitators de la comunidad. El protocolo es uno-a-muchos en esta dimensión por diseño.

El mapa del ecosistema 2026

El estado de x402 en mayo de 2026 se lee mejor como un pequeño número de puntos grandes:

Coinbase CDP — facilitator de primera parte, la implementación de referencia, el catálogo más grande de cadenas y tokens soportados. Free tier con 1,000 tx/mes y después usage-based.

Pay.sh (Solana Foundation + Google Cloud, lanzado el 5 de mayo de 2026) — un API gateway construido sobre x402 que pone delante servicios de Google Cloud (BigQuery, Gemini, Vertex AI) más 50+ APIs de la comunidad. Pay.sh es el primer deployment a gran escala del patrón "muchos servicios detrás de un gateway x402" y el proof point del patrón de marketplace del protocolo. Lo cubrimos la semana pasada.

Bankr x402 Cloud (lanzado en el día 4/02) — un deployment x402 hosted llave en mano para negocios que quieren monetizar APIs sin levantar su propia infraestructura.

Circle Nanopayments (en mainnet el 11 de mayo de 2026) — no es x402-nativo pero está al lado: transferencias USDC gas-free hasta $0.000001, en once blockchains. El modelo económico que x402 hace posible en la capa per-request, Nanopayments lo hace posible en la capa wallet-a-wallet.

Cloudflare — founding member de la x402 Foundation; la compañía que construyó la infraestructura edge global desde la que x402 va a servirse para la gran mayoría de usuarios.

Los números de volumen on-chain cuentan una historia más honesta que el comunicado institucional. Noviembre 2025 vio una explosión — algunos early adopters fanáticos, algo de tráfico bot, una cantidad considerable de demo-ware. El primer trimestre de 2026 vio una caída medible mientras ese entusiasmo inicial se asentaba. Lo que no cayó es la lista de founding members, la cadencia de releases de SDK o el conteo de facilitators. La categoría está en el gap entre "novedad" e "infraestructura", y es el mismo gap que SSL pasó en 1996-1997 antes de volverse inevitable.

Por qué x402 es el big think de 2026

Cuatro razones por las que apostamos por él como target primario de integración en lugar de un experimento lateral.

El pago es la credencial. Toda alternativa a x402 — API keys, tokens OAuth, JWT, mTLS, signed URLs — resuelve autenticación y metering por separado y factura mensualmente. Para un agente autónomo que llama a 500 endpoints en un workflow, eso son 500 flujos de onboarding, 500 tablas de cuota, 500 facturas. x402 colapsa todo en el mismo round trip que el request. El ahorro compone no-linealmente con el número de servicios con los que un agente habla.

HTTP-nativo, sin primitives nuevas. x402 no introduce un transporte nuevo, un esquema de direccionamiento nuevo, una capa de identidad nueva ni una superficie de API de cliente nueva. Cualquier cliente HTTP lo habla; cualquier servidor HTTP puede adoptarlo incrementalmente. No hay un internet paralelo que bootstrap. Compáralo con WebPayments, Lightning Network para HTTP, o los varios SDKs de pago específicos por L2 — todos esos requieren que ambos extremos del cable salgan del stack HTTP estándar. x402 no.

Multi-cadena por diseño. La separación de schemes significa que un agente puede pagar en USDC sobre Solana a un endpoint, USDT sobre Polygon a otro, y EURC sobre Base a un tercero, con el mismo SDK, en el mismo loop, contra el mismo facilitator. La cadena es un detalle de capa de presentación, no un compromiso arquitectónico.

Gravedad institucional. Visa, Mastercard, American Express, AWS, Google, Stripe, Microsoft, Shopify y Cloudflare no son founding members de cuerpos de estándares para protocolos que piensan que van a fallar. La curva de volumen on-chain es ruidosa; la curva de adopción institucional no.

El gap que LLM4Agents está cerrando

Hoy, los facilitators de x402 están separados de la capa de LLM y tools. Un agente que quiere usar x402 tiene que ensamblar: un SDK de cliente x402, un keypair de wallet, un proveedor de LLM (probablemente con su propia API key y balance pre-pagado), un servidor MCP (probablemente con otra API key), y el pegamento entre ellos. Cinco integraciones para hacer una cosa. La wallet del agente no paga al LLM; el LLM no sabe qué pagó el agente al tool; el tool no sabe qué pagó el agente al siguiente tool.

Creemos que la forma correcta es la inversa: una wallet, un SDK, un facilitator, x402 en todas partes. El agente fondea una sola wallet non-custodial en Solana o Polygon. Esa misma wallet paga inferencia LLM, tool calls de MCP, endpoints x402 de terceros, y cualquier servicio x402 futuro que el agente descubra, con el mismo camino de firma y la misma economía per-request. Esa es la capa que LLM4Agents está lanzando.

Qué vamos a lanzar, específicamente

Tres adiciones concretas a la plataforma, todas alineadas con la spec x402 estándar para que todo lo que lancemos sea interoperable con el resto del ecosistema.

1. Inferencia LLM x402-nativa

El endpoint OpenAI-compatible existente ya acepta requests autenticados por un balance de agente pre-fondeado. El nuevo modo acepta el mismo endpoint con un header X-PAYMENT-SIGNATURE en lugar. El agente (o el SDK en su nombre) firma una autorización EIP-3009 o SPL por el coste exacto de la completion — cotizado en la respuesta 402 — y reintenta. Sin balance pre-cargado, sin API key, sin cuenta.

Los dos caminos coexisten: un agente con wallet registrada y balance recargado sigue usando el camino de balance, más barato y de menor latencia; un agente no registrado que llama en frío puede pagar estrictamente per-completion vía x402. La escalera de fallback es automática — agotar balance, caer a x402, caer a error — y el SDK la maneja transparentemente.

2. MCP tools x402-nativos

El servidor MCP en mcp.llm4agents.com/mcp expone browser, search, generación de imágenes y el resto del catálogo de tools. Desde la siguiente release, cada tool call devuelve 402 por defecto si el request no está autenticado, con el precio cotizado por llamada. Un agente puede pagar $0.0002 por una búsqueda, $0.005 por un scrape, $0.04 por una imagen 1024×1024, sin cuenta upstream ni contrato. El mismo flujo de firma que paga inferencia paga los tools.

La combinación MCP-sobre-x402 es lo que hace posible una economía agéntica completamente componible. Un servidor MCP de tercero puede cobrar por llamada; un agente puede descubrir el servidor, leer su catálogo y empezar a pagar — todo sin un humano en el loop y todo ruteado por el facilitator de LLM4Agents.

3. SDK con cliente x402 de primera clase

El @llmforagents/sdk (TypeScript) y llm4agents-sdk (Python) ganan un módulo x402 a nivel raíz que el agente puede usar para pagar cualquier endpoint x402, no solo los nuestros:

import { LLM4AgentsClient } from '@llmforagents/sdk';

const client = new LLM4AgentsClient({
  walletPrivateKey: process.env.AGENT_KEY!,
  chain: 'solana',                    // o 'polygon', 'base'
});

// Paga cualquier endpoint x402, en cualquier parte del internet.
// El SDK maneja detección de 402, firma, retry y parseo de recibo.
const response = await client.x402.fetch(
  'https://some-third-party-api.example/v1/data',
  { method: 'POST', body: JSON.stringify({ query: '…' }) }
);

// O usa los helpers de alto nivel para nuestros propios endpoints.
const completion = await client.chat.completions.create({
  model: 'anthropic/claude-sonnet-4',
  messages: [{ role: 'user', content: '…' }],
  paymentMode: 'x402',                  // paga per-call, sin balance
});

Por debajo, el SDK construye el payload typed-data EIP-712 (EVM) o la transacción parcial SPL (Solana), firma con la clave del agente, attacha X-PAYMENT-SIGNATURE, reintenta, surface el recibo, y expone el tx hash en la respuesta. El facilitator en el lado de liquidación es el nuestro por defecto — multi-cadena Solana, Polygon y Base, soportando USDC y USDT — pero se puede configurar a cualquier facilitator x402 compliant, incluido Coinbase CDP. El SDK es el cliente x402 estándar, no un fork propietario.

4. LLM4Agents como facilitator

Estamos también corriendo nuestro propio facilitator y lo estamos registrando con Pay.sh y con el registry de facilitators de la Linux Foundation. Esta es la dimensión donde ser protocol-native paga: un agente construido sobre nuestro SDK puede pagar a un endpoint listado en Pay.sh, a un endpoint frontado por Coinbase CDP, o a uno nuestro con código idéntico. No estamos construyendo un walled garden; estamos construyendo un nodo en una mesh abierta.

Casos de uso que esta combinación habilita

Inferencia para agentes anónimos. Un agente desechable — un scraper one-shot, un bot de CI, un proceso de research levantado por un agente long-running — llama al endpoint LLM con x402 y sin registro previo. Paga per-completion, obtiene la respuesta, muere. Sin latencia de signup, sin housekeeping de cuenta, sin rotación de claves.

Economía per-request componible. Un agente responde una sola query de usuario que requiere cuatro tool calls (search, scrape, summarize, image) y una completion. Cada paso liquida independientemente en stablecoin. La wallet del agente se debita cinco veces en la misma conversación, cada monto cotizado exacto. El operador obtiene un rastro de recibos en lugar de una factura agregada.

Pagos agente-a-agente. El Agente A ofrece un servicio (un pipeline de research, una traducción, una rutina de data-cleaning) y lo expone como endpoint x402. El Agente B lo descubre, paga por él desde su propia wallet, consume el resultado. Ambos extremos usan el SDK de LLM4Agents. No hay una plataforma de pago en el medio — el protocolo es la plataforma.

Monetización de servidores MCP de terceros. Cualquiera con una herramienta útil puede exponerla como endpoint MCP asegurado por x402, registrar la URL en el registry de LLM4Agents (o en cualquier otro registry), y empezar a cobrar revenue per-call. Los agentes sobre nuestro SDK le pagan nativamente. La barrera para volverse vendedor en la economía agéntica baja a escribir el código.

Servicios continuos con economía por segundo. Un agente que se suscribe a una fuente de datos en streaming, una transcripción en vivo o un job de cómputo de larga duración puede extender su autorización x402 periódicamente en lugar de comprometerse a un tier. Combinado con cómputo snapshotted por Firecracker y Circle Nanopayments en la capa de wallet, la granularidad de "qué renta un agente del internet" cae al segundo.

Tradeoffs honestos

x402 es la primitiva correcta para la economía per-request que los agentes autónomos demandan. No es la primitiva correcta para todo workload. Algunas advertencias que queremos decir claras.

Latencia. Un 402-y-retry en frío añade un round trip extra más el paso de verificación del facilitator. Para una llamada de inferencia que ya toma 500ms, el overhead se pierde en el ruido. Para un tool call que vuelve en 30ms, el overhead del protocolo es el coste. Recomendamos balance pre-fondeado para workloads de alta frecuencia y muy baja latencia, y x402 para todo donde el precio per-call importa más que los milisegundos marginales.

Centralización del facilitator. Un facilitator es un intermediario confiable (pero verificable). El protocolo es uno-a-muchos en esta dimensión — cualquiera puede correr uno y los clientes pueden elegir — pero en la práctica hoy la mayoría del volumen pasa por un puñado. La respuesta correcta es mantener la spec del protocolo genuinamente abierta, correr múltiples facilitators, y dejar que el mercado los mantenga honestos. Corremos el nuestro; te animamos a correr el tuyo.

Volatilidad del volumen on-chain. Los números de 2026 están por debajo del pico de noviembre 2025. No creemos que esto invalide el protocolo; creemos que refleja la ausencia de las piezas de plataforma — SDKs grado-gateway, identidades de wallet firmadas, tools agente-nativas — que este anuncio empieza a entregar. Vamos a publicar el volumen sobre nuestro facilitator de forma transparente.

Timeline

El endpoint LLM x402-nativo y el módulo x402 del SDK entran a closed beta con operadores de agentes seleccionados en las próximas dos semanas. El modo per-call x402 del MCP y el registro público del facilitator caen dentro del mes. La general availability completa y el listado en Pay.sh apuntan a principios de Q3 2026. Si quieres acceso temprano — particularmente si estás corriendo un agente que habla con diez o más servicios externos y estás cansado de gestionar diez API keys — contáctanos por el endpoint de registro abajo.

x402 pasó treinta y cuatro años como status code reservado. Los próximos doce meses son los que deciden si se vuelve parte del toolbox HTTP por defecto o se queda como curiosidad. Estamos apostando a que se vuelve el default, y estamos construyendo la capa agéntica que esa apuesta implica.