Título: X402 explicado: Micropagos nativos HTTP para agentes de IA

La especificación X402 reutiliza el estado estándar HTTP 402 Payment Required para convertir una llamada de API convencional en un micropago on-chain. Los agentes de IA ahora pueden liquidar tarifas por consultas de LLM o feeds de datos sin intervención humana, y los proveedores pueden cobrar por solicitud sin necesidad de construir un sistema de facturación personalizado.

Por qué los agentes de IA necesitan un protocolo de pago

Los agentes autónomos entrelazan modelos de lenguaje, herramientas de búsqueda web y fuentes de datos propietarias. Cada conexión tiene un coste: tarifas por token para un modelo o cargos por llamada para una API de datos de mercado. Los modelos de negocio actuales dependen de claves de API vinculadas a cuentas de suscripción, recargas manuales de crédito o facturación post-hoc. Estos métodos rompen la promesa de "cero intervención humana" de los agentes autónomos y añaden una carga operativa para los proveedores.

X402 ofrece un punto medio: un flujo de solicitud-respuesta que se parece a cualquier otra llamada HTTP, pero con un paso de pago integrado registrado en una blockchain pública. El único requisito es que el cliente pueda firmar y transmitir una transacción en la cadena que especifique el servidor.

El handshake de X402 en detalle

  1. Solicitud inicial – El agente envía un GET o POST normal a un endpoint de pago. No se necesitan encabezados especiales.
  2. El servidor responde con 402 – La respuesta incluye el estado 402 y un cuerpo JSON que enumera:
    • amount – la tarifa que el servidor espera, en la unidad de token más pequeña;
    • token – la dirección del contrato ERC-20 (o equivalente);
    • chain – el identificador de la blockchain donde debe registrarse el pago;
    • nonce opcional – un valor único que evita ataques de repetición (replay attacks).
  3. El cliente prepara el pago – El agente verifica la dirección del token y la cadena según su política (por ejemplo, solo cadenas de confianza). Luego crea una transacción que transfiere la cantidad requerida a la dirección proporcionada por el servidor, la firma con su clave privada y la transmite.
  4. Envío del hash de pago – Cuando el hash de la transacción está disponible, el cliente repite la solicitud original, esta vez añadiendo un encabezado X-Payment que contiene el hash. El payload permanece sin cambios.
  5. El servidor verifica on-chain – El servidor busca en la blockchain una transferencia confirmada que coincida con el monto, el token, la cadena y el nonce. Si encuentra una coincidencia, devuelve los datos solicitados con un estado 200 OK.

Cualquier librería de cliente HTTP que admita encabezados personalizados y pueda llamar a un SDK de blockchain puede realizar estos pasos. No se requiere un nuevo protocolo de transporte ni una capa de socket personalizada.

Aspectos a tener en cuenta

  • Latencia – La confirmación en una cadena pública añade retraso.
  • Costes de gas – Incluso las cadenas baratas cobran gas; los pagos inferiores a 0,001 $ pueden no ser rentables.
  • Complejidad – Los agentes deben gestionar transacciones fallidas y reorganizaciones de la cadena; una lógica de reintento robusta es imprescindible.
  • Seguridad – El nonce evita los ataques de repetición, pero los agentes aún deben proteger sus claves privadas y evitar reutilizarlas en servicios no relacionados.