Coinbase x402 vs Google A2A: Dos Órdenes de Pago Opuestos para Pagos entre Agentes

Un desarrollador que construye un agente de investigación que asigna trabajo a otros tres (búsqueda, resumidor, traductor) necesitaba pagos máquina a máquina de menos de un centavo. El mínimo de $0.30 de Stripe en una llamada de $0.001 es un 300x de sobrecosto; el gas en L1 es similar; las suscripciones requieren prenegociación humana. Encontraron x402, la implementación de Coinbase del HTTP 402 "Pago Requerido" — un facilitador sin estado para pagos de menos de un centavo en Base, liquidando en ~2s por ~$0.0001 mediante autorizaciones pre-firmadas EIP-3009 pasadas como cabeceras.

La cuestión central: orden de pago

Cuando tienes verificar (rápido, fuera de cadena), liquidar (lento, en cadena), y trabajo real (llamada LLM), son posibles tres órdenes:

• A: verificar → ejecutar → liquidar
• B: verificar → liquidar → ejecutar
• C: verificar → reservar → ejecutar → capturar (patrón de retención de tarjeta de crédito — no posible con el diseño de un solo uso de EIP-3009)

El middleware de Coinbase usa A; la extensión x402 de Google A2A usa B. La diferencia depende de la duración del trabajo: el llamante de Coinbase es un endpoint API rápido (sub-500ms), por lo que la brecha verificar-liquidar es insignificante. Para un agente que llama a otros agentes, la ventana se extiende a segundos o minutos — suficiente para que el pagador vacíe su cartera después de verificar pero antes de liquidar, regalando cómputo gratuito.

Liquidar primero gana para cargas agentivas

El desarrollador eligió B (verificar → liquidar → ejecutar) porque el trabajo del agente cuesta dinero real ($0.30+ por llamada) y es lento. Con liquidar primero, un pago fallido nunca ejecuta el LLM. Probaron bajo estrés cuatro escenarios:

• Firma válida, cartera drenada antes de que se liquide → liquidación revierte, sin cómputo desperdiciado (pérdida $0).
• Dos solicitudes paralelas de la misma cartera con diferentes nonces, mismo saldo → una liquidación tiene éxito, la otra falla por carrera en la cadena, nunca llega al modelo.
• Cabecera de pago repetida → detectada en la verificación de nonce antes de verificar, devuelve 402.
• TimeOut del facilitador a los 10s pero la cadena confirma a los 25s → pago huérfano (pagador debitado, tarea fallida). Esto es una propiedad de la cadena bajo carga, no reparable con el orden.

Un modo de fallo de liquidar primero: el pago se realiza, pero el trabajo falla (error 500, bug). El proveedor lo maneja con metadatos de nonce/autorización persistidos y reembolsos manuales.

El flujo completo es de código abierto con pruebas e2e que ejecutan los cuatro escenarios en un portátil. github.com/GetBindu/Bindu