AWS ha lanzado discretamente una integración que permite a los editores establecer precios por solicitud para agentes de IA y recibir el pago en USDC a través del protocolo x402, con liquidación en Solana o Base. Este movimiento lleva a x402 de una especificación que hemos cubierto ampliamente —más recientemente en el contexto de Coinbase y AWS implementándolo en el WAF de CloudFront— a un producto real que cualquier editor en la infraestructura de AWS puede activar. La arquitectura es sencilla: un editor define un precio para acceder al contenido, un agente de IA que realiza una solicitud recibe una respuesta HTTP 402 con una demanda de pago, el agente paga en USDC en la cadena y el editor sirve el contenido. La liquidación ocurre en Solana o Base, no en un sistema tradicional, lo que significa que todo el ciclo —solicitud, pago, entrega— puede completarse en segundos sin tarjeta de crédito, suscripción ni intervención humana.
Cómo funciona el ciclo de pago x402 en AWS
El protocolo x402 se basa en el código de estado HTTP 402, reservado hace décadas para pagos digitales pero nunca implementado. Cuando un agente de IA solicita un recurso a un editor que ha habilitado x402, el servidor devuelve una respuesta 402 en lugar del contenido. Esa respuesta incluye una dirección de pago, una cantidad en USDC y un identificador de cadena —ya sea Solana o Base. El software de la billetera del agente construye y firma una transacción en la cadena especificada, envía el USDC y luego vuelve a solicitar el recurso con la prueba de pago. El editor verifica la transacción en la cadena y sirve el contenido.
La integración con AWS significa que los editores no necesitan ejecutar su propia infraestructura de verificación de pagos. La lógica de aplicación se sitúa en el perímetro, probablemente en CloudFront o una capa similar, y el editor simplemente configura un precio y una dirección de recepción. Esta es la misma arquitectura que describimos cuando Coinbase y AWS pusieron x402 en el WAF, pero la novedad es que ahora está disponible para los editores como un producto, no solo como una demostración. Las cadenas de liquidación —Solana y Base— fueron elegidas por sus bajas comisiones y tiempos de bloque inferiores a un segundo, algo crucial cuando un agente puede realizar cientos de solicitudes por minuto y cada pago es una fracción de centavo.
Por qué Solana y Base, y no la red principal de Ethereum
La elección de Solana y Base como capas de liquidación es práctica. La red principal de Ethereum sería inutilizable para este caso de uso: una sola solicitud podría costar una fracción de centavo en valor de contenido, pero incurrir en dólares en comisiones de gas. Solana ofrece finalidad en menos de un segundo y comisiones medidas en fracciones de centavo, lo que la hace viable para microtransacciones de alta frecuencia. Base, como capa 2 de Ethereum, ofrece una economía similar con el beneficio adicional de la infraestructura de Coinbase y la liquidez de USDC.
El soporte de doble cadena también revela una filosofía de diseño: x402 es agnóstico a la cadena a nivel de protocolo, y la cadena de liquidación es un parámetro en la respuesta 402. Un editor podría, en teoría, especificar cualquier cadena que admita USDC, aunque el producto actual solo muestra Solana y Base. Esta flexibilidad es importante porque significa que la vía de pago puede evolucionar sin cambiar el protocolo. Si surge una cadena más rápida o barata, los editores pueden adoptarla actualizando una configuración, no reescribiendo su integración.
La economía de la fijación de precios por solicitud para agentes de IA
La fijación de precios por solicitud supone un alejamiento de los modelos de suscripción y clave API que dominan la web actual. Un usuario humano podría pagar 10 $ al mes por acceder a un sitio de noticias y realizar unas pocas docenas de solicitudes. Un agente de IA podría realizar miles de solicitudes al día al mismo sitio, cada una para un solo artículo o dato. El modelo de suscripción se rompe para los agentes porque el patrón de uso es muy diferente: el agente no necesita acceso “ilimitado”, necesita acceso granular de pago por uso.
x402 permite un modelo en el que el editor establece un precio por solicitud —digamos, 0,001 $— y el agente paga exactamente por lo que consume. Esto alinea los incentivos: el editor obtiene ingresos proporcionales al valor extraído y el agente no paga de más por un acceso que no utiliza. El desafío es que el agente debe gestionar un saldo de USDC y tomar una decisión de pago para cada solicitud, lo que introduce una nueva capa de lógica: ¿cómo decide el agente si un contenido vale su precio? Esa pregunta no la responde el protocolo en sí, pero es el próximo problema que los desarrolladores de agentes deberán resolver.
La cuestión abierta: gestión de billeteras de agentes y responsabilidad
El protocolo x402 asume que el agente controla una billetera con un saldo en USDC y puede firmar transacciones de forma autónoma. Esto plantea las mismas cuestiones de custodia y responsabilidad que hemos estado siguiendo en el espacio de pagos de agentes de IA. Si un agente realiza miles de micropagos al día, ¿quién financia la billetera? ¿Quién es responsable si el agente gasta de más, paga por contenido de baja calidad o es víctima de una respuesta 402 falsificada que dirige el pago a un atacante?
La integración de AWS no resuelve estas cuestiones; proporciona la vía de pago. La arquitectura de la billetera del agente —ya sea una billetera MPC controlada por el código del agente, un par de claves tradicional o una billetera custodiada gestionada por una plataforma— determina el modelo de seguridad y responsabilidad. Hemos escrito sobre esta tensión en el contexto del Agent SDK de Coinbase y Locus Founder, y x402 en AWS muestra el mismo problema desde el lado del editor. El editor recibe USDC y no necesita saber ni preocuparse por cómo gestiona el agente sus claves, pero el desarrollador del agente sí debe hacerlo.