Semana agentic: ¿qué compró exactamente el pago?

Esta semana, un paywall de x402 dejó pasar gratis una ruta de pago porque leía el path distinto que el router, y un scheme nuevo de x402 metió el request en lo que se firma. Las dos cosas responden la misma pregunta: ¿qué compró exactamente el pago?

Entre el 18 y el 25 de septiembre se mergearon 17 pull requests en x402-foundation/x402, frente a 30 la semana anterior. phdargen fue autor de 4, CarsonRoscoe de 3 y PhilBot402 de 2. Los otros ocho vinieron de ocho cuentas distintas, uno cada una. La cifra es baja, pero la semana trajo un bypass de paywall, un rail de settlement nuevo, un miembro de la foundation con un negocio de pagos detrás y x402 citado en un paper de investigación de BlackRock.

El hilo común viene del roundup de la semana pasada. Ahí, el paywall y el handler leían requests distintos. Esta semana el hueco se movió en dos direcciones. Volvió a aparecer en la capa del path, y un scheme nuevo cerró parte de él por diseño.

1. /api%2Fpremium: el paywall que miraba otro path

El PR #3502, abierto por CarsonRoscoe el 16 de septiembre y mergeado el 21, corrige un acceso sin pago en el SDK de Python. El mecanismo cabe en dos frases. El middleware de FastAPI y Flask comparaba las rutas protegidas contra el path escapado del request (raw_path, RAW_URI o REQUEST_URI). Starlette y Werkzeug despachan las rutas literales sobre el path decodificado.

Entonces, para una ruta literal como GET /api/premium, un request a /api%2Fpremium no coincidía con ningún patrón protegido. requires_payment() devolvía false y el middleware dejaba pasar el request. Después el framework decodificaba el path y lo mandaba directo al handler de pago. No había header de pago, ni verificación, ni settlement. El PR lo reproduce contra un server Uvicorn real:

# antes del fix
curl http://localhost:8000/api/premium
# 402 Payment Required

curl --path-as-is http://localhost:8000/api%2Fpremium
# 200 OK, body de pago completo

Lo que vale la pena leer con cuidado es cómo llegó el código hasta aquí. En agosto, el #3044 movió el matching de rutas de Go al path escapado. El objetivo era impedir que un separador decodificado ensanchara un capture de wildcard, y el #3073 lo portó a Python. Fue la decisión correcta para los wildcards y la equivocada para las rutas literales. Un fix de manejo de paths preparó el siguiente agujero. Contando el #3036, el bypass por line terminator en wildcards del 4 de agosto, este es el cuarto fix de manejo de paths en los SDKs desde principios de agosto.

El fix no elige un ganador. Carga las dos representaciones. HTTPRequestContext suma un decoded_path tomado de la vista de routing de cada framework, y el lookup de rutas exige pago si coincide cualquiera de los dos, el path escapado o el decodificado. En requests sin encoding los dos strings son iguales, así que el chequeo extra no hace nada.

Un chequeo automático de drift abrió el issue #3541 el 21 de septiembre y calificó el hueco como "medium" para los otros SDKs. Señaló que los adapters de Go pasaban solo EscapedPath() y que @x402/fastify pasaba el request.url crudo. Los ports a TypeScript y Go, #3542 y #3543, se mergearon el 22 de septiembre y cubren Express, Hono, Fastify, Next, Gin, Echo y net/http. Los tres SDKs publicaron release ese mismo día: @x402/core 2.27.0 en npm, x402 2.24.0 en PyPI y Go v2.27.0.

2. Lightning llega a x402, y Block entra a la foundation

El 24 de septiembre Block anunció que se unió a la x402 Foundation y que "has contributed Bitcoin Lightning payments to the x402 protocol". La contribución en el repositorio es el PR #2861, mergeado el día anterior. Lo firmó benthecarman, cuyo perfil de GitHub indica Spiral, el grupo de desarrollo de Bitcoin de Block. El PR se abrió el 15 de julio y agrega una especificación de 760 líneas, scheme_exact_lnbtc.md. No es una implementación.

La forma es simple. El resource server devuelve un invoice BOLT11 nuevo en extra.invoice. El cliente lo paga y devuelve el preimage de 32 bytes. El facilitator verifica SHA-256(preimage) == payment_hash, verifica que la clave que firmó el invoice sea igual a payTo (una clave secp256k1 comprimida de 33 bytes) y registra de forma atómica network:payment_hash en un replay store. Las redes usan un namespace nuevo, lnbtc, anclado al hash del bloque génesis de Bitcoin según la convención CAIP-2 de BIP-122: lnbtc:000000000019d6689c085ae165831e93 para mainnet. Los montos van en millisatoshis. Solo se permite el flow upfront, y el server "MUST NOT call /verify".

Varias consecuencias quedan escritas. "Settlement does not move funds": el dinero se movió antes de que existiera el preimage. Un replay store en memoria queda explícitamente fuera de norma, porque un reinicio permitiría reclamar otra vez un preimage ya usado. SettlementResponse.payer debe omitirse, porque Lightning no tiene una dirección de pagador estable. Pagar de más no compra nada extra, y no hay camino de reembolso. Un nodo custodial compartido queda descartado: un tenant que puede emitir invoices con la misma clave de nodo podría pagarse su propio invoice y usar el preimage contra el requirement de otro tenant.

La parte importante es el request binding. El description hash firmado del invoice tiene que ser igual a un requestHash calculado como SHA-256 sobre un objeto canonicalizado con JCS (RFC 8785). El perfil http:1 cubre el método, la URL destino según las reglas de RFC 9421, un hash de los bytes del body y una lista de headers configurada por el server. El perfil mcp:1 cubre la URI del server, tools/call, el nombre de la tool, los argumentos y miembros elegidos de _meta. Un preimage para /article/A falla con invalid_exact_lnbtc_request_mismatch si se presenta para /article/B al mismo precio. El exact de EVM funciona distinto: la autorización EIP-3009 firma from, to, value, una ventana de validez y un nonce, y nada sobre el request. En lnbtc, lo que se compró es parte de lo que se firmó. Eso no frenaría a un middleware que nunca pide el pago, como en el ítem 1. Sí significa que una prueba no se puede mover de un request a otro.

Dos salvedades. Primera, todavía nada lo implementa. Siguen abiertos dos PRs de implementación de Lightning, #1873 (Python, desde marzo) y #2262 (TypeScript, desde mayo, todavía con el nombre bip122). PRs de Lightning anteriores, desde noviembre de 2025, se cerraron sin mergear. Segunda, este es el segundo hogar de Lightning en el mundo 402. Cuando auditamos L402 en agosto, el método Lightning de las specs de MPP de Tempo lo había escrito Lightspark. El método de x402 viene ahora de Block. Lightning Labs, que inventó L402, no escribió ninguno de los dos.

3. Coinbase for Agents paga desde un saldo de exchange

Coinbase sumó acciones de EE.UU. y pagos x402 a Coinbase for Agents esta semana (cobertura fechada el 22 de septiembre). El post de lanzamiento en coinbase.com devolvió 403 a nuestros fetch, pero el texto operativo está en el skill de Coinbase for Agents. Ese texto describe otro tipo de buyer de x402. El agente paga "directly from your Coinbase USDC balance": un saldo de exchange, al que se llega con OAuth en el server MCP remoto o con una API key de CDP en el CLI.

El server MCP remoto en agents.coinbase.com/mcp expone tres tools de x402. coinbase_x402_resources busca gratis en un catálogo curado. coinbase_x402_fetch paga y trae el recurso en una sola llamada. coinbase_x402_pay autoriza y devuelve un header. Fetch solo funciona con URLs del catálogo curado y con x402 v2. Los proveedores listados son Nansen, Arkham, Glassnode, Dripstack, Exa, You.com y Massive. Los pagos son "USDC on Base only, with a 5 USDC per-payment cap". El max_amount de quien llama puede bajar el techo del catálogo pero no subirlo. El documento es directo: "A prompt budget is not a server-enforced session or daily limit." Los reintentos se identifican con un idempotency_key, y "omitting or changing it can create another hold". El documento pide no declarar soporte nativo de SIWX, y la integración de trading para ChatGPT deja x402 afuera.

Sondeamos el endpoint el 25 de septiembre. Un POST /mcp sin autenticar devuelve 401 con WWW-Authenticate: Bearer resource_metadata="https://agents.coinbase.com/.well-known/oauth-protected-resource" y una lista de scopes. El documento de metadata devuelve 200 y nombra a login.coinbase.com como authorization server. Eso es RFC 9728 bien hecho. Ese mismo día, el Wallet MCP de Coinbase en mcp.base.org seguía respondiendo Bearer realm="mcp" sin puntero a metadata, y su ruta de metadata seguía devolviendo 404, igual que en nuestra auditoría del 21 de septiembre.

Los diez scopes anunciados cubren portfolios, cuentas, productos, órdenes, trades y transferencias. Ninguno nombra pagos, y el documento no dice qué scope requieren las tools de x402. Un usuario que otorga acceso para "operar" puede haber otorgado también acceso para "pagar por datos" sin verlo. Como operador no puedes arreglar eso desde el lado del seller, pero conviene saberlo cuando leas esos permisos.

4. BlackRock mete x402 en la tesis

"The Machine-Native Economy" de BlackRock es un paper de 11 páginas firmado por Will Su, Robert Mitchnick, Jay Jacobs y William Helm. La cobertura de prensa empezó esta semana. Su frase de encuadre es "AI represents machine-native intelligence, while digital assets represent machine-native money." Sobre pagos, nombra a x402 y dice que al "providing 24/7, near-real-time, verifiable settlement, x402 can reduce the resource provider's counterparty exposure and enable the immediate release of requested data or services upon payment confirmation." Ubica la capitalización de mercado de las stablecoins por encima de los $300 mil millones a septiembre de 2026. Y nombra a Ethereum y a Arc de Circle, "where USDC is designed to serve as the native gas asset", como venues de settlement.

Dos detalles importan más que el titular. La conclusión del paper es prudente: "The ecosystem remains nascent, with agentic payment activity and compute-market liquidity still limited." Y su sección de cómputo cita el acuerdo de Stripe del 19 de agosto para adquirir OpenRouter, un gateway de modelos que enruta entre más de 400 modelos de más de 80 proveedores. El paper lee esa operación como "an early strategic signal that model routing and compute-usage optimization are becoming part of the financial infrastructure surrounding AI."

El lado on-chain se movió la misma semana. El PR #3523 (mergeado el 23 de septiembre) registra el proxy Upto Permit2 de x402 en su dirección canónica en Arc Mainnet, con Exact y Upto en Arc Testnet. El proxy Exact "is not currently deployed at its canonical address" en mainnet. Como referencia de escala, la home de x402.org mostraba el 25 de septiembre 75,41 millones de transacciones y $24,24 millones en los últimos 30 días, de 94,06 mil buyers y 22 mil sellers. Eso da unos 32 centavos por transacción. El sitio no publica metodología, así que las cifras no son comparables con los totales filtrados de TRM de la semana pasada.

5. Fixes más chicos, misma pregunta

El PR #3521 (mergeado el 21 de septiembre, publicado en @x402/evm 2.27.0) reemplazó un parseInt en el getEvmChainId de TypeScript. parseInt se detiene en el primer carácter que no es dígito, así que eip155:8453abc se volvía la chain 8453, eip155:0x2105 se volvía 0 y eip155:1e3 se volvía 1. Ese valor se firma dentro del dominio EIP-712 de Permit2, EIP-3009 y batch settlement. El schema de red solo exige dos puntos. Go y Python ya rechazaban esos inputs. Revisamos los identificadores de red de x402 en la auditoría de ERC-7930, y este es el mismo problema una capa más abajo.

El PR #3126 corrige la spec exact de Starknet. El texto anterior le decía a un facilitator que, si encontraba el nonce de un payload ya consumido, buscara la transacción que lo consumió y reportara éxito. El PR explica el problema: "A settled payload is public, so anyone who replayed it would be given a second success, and every success releases a resource." Un nonce consumido ahora es terminal.

El PR #3205 agrega un método transferExecutor a la spec de Hedera, por ahora solo spec, para pagadores cuyos fondos controla un contrato, incluidas las delegaciones por allowance HIP-336. El PR incluye los contratos de agent wallets entre ellos, y otras chains ya cubren el caso en exact. Una corrección a nuestro propio registro: @x402/cardano y @x402/casper, que reportamos como 404 en npm, se publicaron por primera vez la noche del 18 de septiembre como 2.26.0 y ya van en 2.27.0. En otra parte, A2A mergeó un timeline coherente de historial de tasks en el #2129. Reutiliza a propósito un evento de stream existente porque los SDKs de Go, Java y Rust fallan con error ante eventos desconocidos.

Qué significa para LLM4Agents

El bypass de path es el ítem con peso operativo inmediato. Un gateway compatible con OpenAI tiene una tabla de rutas chica y literal: chat completions, embeddings, models. Es exactamente el caso de ruta literal que tocó el bug. Si la capa que mide una llamada y la capa que la despacha normalizan el path distinto, algunas llamadas quedan sin cobrar. En rutas donde el modelo viaja en el body, ningún cliente legítimo necesita un separador codificado en el path. Rechazarlos no cuesta nada y elimina la clase entera.

El binding de lnbtc importa más que el rail. Es el primer scheme de x402 en el que el pago se compromete con el request, y la construcción no depende de Lightning: un objeto JCS sobre método, URL, hash del body y headers elegidos, hasheado y firmado. Para un gateway, el objeto equivalente es el endpoint, el modelo y el body del prompt. Un recibo que lleve ese hash le permite a un agente, o a su auditor, probar qué llamada cubrió un pago. Hoy, en EVM, la firma del pagador cubre la transferencia y nada sobre la llamada que pagó.

El buyer de Coinbase suma una población de agentes que pagan desde saldos custodiales, llegan a los sellers solo a través de un catálogo curado y reintentan con idempotency keys. Los precios típicos por llamada de un LLM quedan muy por debajo de un techo de 5 USDC. Las restricciones que importan son estar en el catálogo y tratar un pago repetido para la misma llamada lógica como duplicado, no como una segunda venta.

El paper de BlackRock sirve por lo que cita. BlackRock cita la compra de un router de modelos por parte de Stripe como evidencia de que el routing se está volviendo infraestructura financiera. Esa es nuestra categoría. Confirma la tesis de demanda, y también nombra a un competidor con un stack de billing mucho más profundo que el nuestro. La diferencia que podemos defender es el settlement por llamada, nativo en stablecoins, sobre un protocolo abierto que el mismo paper nombra primero.

Cómo mantenerse en la frontera

Cinco pasos, en orden.

Primero, cerrar la clase de path esta semana. Actualizar cualquier SDK de x402 en el camino del request a @x402/* 2.27.0, Python 2.24.0 o Go v2.27.0. Rechazar separadores codificados con porcentaje en las rutas de la API desde el edge. Agregar un test por ruta de pago que envíe la variante codificada con --path-as-is y espere un 402 o un 400, nunca un 200.

Segundo, poner un request hash en cada recibo. Reutilizar la estructura del objeto de binding http:1 de lnbtc con nuestro propio domain tag: método, URI destino, hash del body y headers configurados, canonicalizados con JCS. Devolver su digest junto con la respuesta de settlement. Tomar una construcción publicada es mejor que inventar una, y queda lista para el día en que un scheme sobre nuestros rails la necesite.

Tercero, dejar el endpoint listo para catálogos. Los buyers custodiales encuentran sellers a través de listas curadas. URLs de recurso estables, un input schema y precios que coincidan con el 402 en vivo son el boleto de entrada. Los pagos duplicados para una misma llamada lógica deben resolverse en una sola entrega.

Cuarto, probar upto en Arc Testnet. Las llamadas a LLM medidas por tokens son el caso natural del scheme upto, y upto es el proxy que ya está vivo en su dirección canónica en Arc Mainnet. Una corrida en testnet ahora es un seguro barato si Arc termina siendo el venue al que apunta la tesis institucional.

Quinto, prepararse para Lightning, pero no construirlo todavía. Esperar un SDK que implemente lnbtc. Mientras tanto, dejar por escrito los requisitos que impone la spec: una clave de nodo receptor usada solo para este servicio, un replay store que sobreviva reinicios con insert atómico por network:payment_hash, y una conciliación que funcione sin dirección de pagador.