Semana agentic: sesenta fixes mergeados, ningún release

x402 mergeó 60 pull requests entre el 16 y el 23 de octubre. No publicó ninguno en un release. Entre los fixes hay un settlement override que podía superar el monto autorizado, un XSS reflejado en los paywalls HTML, un preflight CORS respondido con 402 y un canonicalizador que no coincidía con RFC 8785. La Linux Foundation también nombró a un director ejecutivo para la x402 Foundation.

Contamos los merges en x402-foundation/x402 por mergedAt desde el 16 de octubre 00:00 UTC. El resumen anterior contó ocho para su ventana, así que el ritmo cambió. El ritmo de releases no. @x402/core 2.28.0 en npm es del 29 de septiembre, Python x402 2.25.0 en PyPI del mismo día, y el tag más nuevo de Python es [email protected]. Todos los fixes de abajo están en main y en ninguno de esos artefactos al momento de escribir.

1. La fundación tiene director ejecutivo

La Linux Foundation nombró a Michael Hursta director ejecutivo de la x402 Foundation. El comunicado tiene fecha del 1 de octubre y el newsletter de octubre del 21 lo repite. Cita más de 50 organizaciones miembro y más de 20 años en pagos, incluida la aceptación de pagos para Norteamérica en Amazon, una práctica de pagos empresariales en PwC y una década en First Data.

La cita que vale la pena: "x402 gives the industry an opportunity to build that next layer as open infrastructure rather than another proprietary payment system." Nada del comunicado cambia el formato en el cable. Sí cambia quién responde cuando una propuesta se estanca, algo relevante para el proceso XP que cubrimos hoy.

2. Un techo, tres SDKs y un bot que cuenta la deriva

El issue #3876, "SDK drift detected", se abrió el 22 de octubre. Lista cinco cambios que entraron en TypeScript y faltan en Go y Python.

El más agudo es el settlement override. En TypeScript, resolveSettlementOverrideAmount() aceptaba overrides raw, porcentuales y en dólares sin compararlos con PaymentRequirements.amount, aunque su propio JSDoc dice que el monto resuelto debe ser como máximo el máximo autorizado. El PR #3338 agregó la verificación y se mergeó el 22 de octubre. El port a Python, #3877, muestra qué hacía el código viejo: un override de 500% sobre 1.000.000 de unidades atómicas devolvía 5.000.000, y un override de $1000000 con 7 decimales devolvía 10.000.000.000.000. El port a Go, #3881, ahora devuelve invalid_settlement_override. Ambos ports se mergearon el 23 de octubre.

Es la guarda de la que depende el scheme upto. El comprador firma un máximo y el vendedor liquida menos. El techo es la verificación del lado vendedor de que el monto liquidado nunca supere lo que firmó el comprador.

Otros tres ítems de la lista están en el mismo estado:

• Gramática CAIP-2. El NetworkSchemaV2 de TypeScript ahora exige la gramática de namespace y reference (#3285). Python aceptaba a:b, eip155: y eip155:84532:extra hasta #3878. Go no tiene una compuerta de schema equivalente, según el issue.
• Motivo del rechazo en el body del 402. El motivo vivía solo en el header PAYMENT-REQUIRED en base64 y el body JSON era {}. El PR #3795 devuelve { "error": ... }. Su autor describe clientes de agentes que leen el body y nunca decodifican el header, por lo que insufficient_funds e invalid_exact_evm_payload_signature les parecían iguales. El port de Python es #3883.
• Firmas high-s y método del Bazaar. Las otras dos entradas: rechazar firmas EIP-3009 high-s no canónicas, y hacer que el método anunciado en el Bazaar coincida con la forma del input declarado (Python: #3880).

PhilBot402 firmó ocho de los 60 merges, más que cualquier otra cuenta, y el texto de sus PRs incluye una línea de "AI disclosure" que nombra al maintainer que lo opera. El reporte de deriva y los ports forman un ciclo: una máquina encuentra la brecha, una máquina la cierra, una persona mergea. Funciona solo mientras el fix de TypeScript sea la referencia. Un bug que TypeScript nunca tuvo no recibe reporte.

3. El camino del navegador: un preflight y una página de paywall

Dos merges tocan navegadores, y ambos tocan lo que medimos en la auditoría de CORS y preflight.

OPTIONS ya no cuesta dinero. El PR #3738 (mergeado el 22 de octubre) corrige el matching de rutas. Una ruta definida sin método, o una config de ruta única, compila al verbo *, y eso coincidía con todos los métodos, incluido OPTIONS. El middleware respondía el preflight del navegador con un 402, el navegador fallaba el preflight y la request pagada nunca se enviaba. Las rutas definidas como "POST /api/data" no se veían afectadas. Ahora * omite OPTIONS en TypeScript, Python y Go, y una ruta explícita "OPTIONS /path" sigue exigiendo pago. Los paquetes legacy v1 conservan el bug a propósito, porque los maintainers los congelaron. El problema compañero, el issue #3722 sobre Access-Control-Expose-Headers, sigue abierto con 17 comentarios.

La página del paywall era inyectable. El issue #3852 reportó XSS reflejado en el paywall HTML: la configuración entraba en un script inline vía JSON.stringify con < intacto, de modo que valores derivados de la request, como el path de la URL o el header Host, podían cerrar el elemento script. El PR #3855 se mergeó tres días después y aplica serialización segura para scripts a los paywalls EVM, SVM, AVM y legacy v1. Su propia descripción dice que la regeneración "does not apply the serializer fix to the Go or Python generators". Esas plantillas se regeneraron desde el código fuente, no se parchearon.

4. Dos detalles de firma que rompen interoperabilidad

El PR #3822 corrige el settlement EIP-3009 para wallets que escriben v como 0 o 1. El parseSignature de viem devuelve yParity y ningún v cuando una firma de 65 bytes termina en 0x00 o 0x01, y el facilitator pasaba yParity como v. Los tokens que aceptan solo 27 o 28, como el FiatToken de USDC, rechazaban pagos válidos en la simulación o en el settlement. El fix pasa yParity + 27.

El PR #3700 hace que la función canonicalize de offer-receipt cumpla RFC 8785. Los caracteres de control se escapaban como \u00XX en lugar de \b \t \n \f \r, se aceptaban surrogates sueltos, un undefined de nivel superior pasaba a null y los huecos de arrays dispersos producían JSON inválido. Los bytes firmados podían diferir de cualquier otra implementación de RFC 8785 para un string con un tab. El PR aclara que la verificación no se ve afectada, porque revisa los bytes del JWS tal como se emitieron. La ruptura es para un segundo firmante o un verificador independiente, el caso que describimos en la auditoría de receipts.

Qué significa para LLM4Agents

La brecha de releases es el hallazgo. Cualquier gateway que fije @x402/core 2.28.0 corre el comportamiento previo al fix en todo lo anterior, y el proyecto que escribió los fixes no los ha publicado. Leer main nos dice qué viene. No cambia lo que ejecutamos.

Exposición por ítem. El techo de override importa donde liquidamos por debajo de un máximo firmado, como una llamada medida contra una cotización. El techo evita que un bug en nuestra contabilidad se convierta en un sobrecobro. El cambio del body 402 ayuda a agentes que leen JSON, porque obtienen un motivo sin decodificar un header. El fix de preflight elimina un modo de falla para compradores en navegador. El XSS importa solo si alguna ruta puede devolver el paywall HTML. Los fixes de v y RFC 8785 importan para la interoperabilidad con wallets y con verificadores de receipts independientes.

El issue de deriva muestra un segundo riesgo. Un stack multi-lenguaje se comporta distinto según el SDK durante días. Un comprador en Python y otro en TypeScript pueden recibir respuestas distintas ante el mismo string de network mal formado.

Cómo mantenerse en la frontera

Primero, hacer nuestro el techo. Aplicar "monto liquidado como máximo el máximo cotizado" en nuestro propio código de settlement, con un test que envíe 500% y un override en dólares. No esperar a que el release del SDK lo traiga.

Segundo, probar el artefacto publicado, no main. Agregar un job de CI que instale el release fijado y corra los casos de esta semana: OPTIONS en una ruta sin método, un v de 0 y de 1, un tab en el payload de un receipt, eip155:84532:extra como network. Cada caso que falle es una brecha conocida con número de PR.

Tercero, decidir la política de pin. Tres semanas y media sin tag alcanzan para elegir entre un release fijado y un SHA de commit revisado para los fixes que necesitamos. Escribir los criterios y revisar las fechas de npm y PyPI cada viernes.

Cuarto, devolver un motivo en nuestros propios bodies 402. Poner un código de error estable en el body JSON de cada rechazo, junto al header. Los agentes leen primero el body.

Quinto, auditar las respuestas HTML. Listar cada ruta que pueda devolver una página a un navegador y confirmar que ninguna incrusta datos derivados de la request en un script inline.