x402 se muda al edge: AWS WAF, Cloudflare y el CDN como paywall

Durante un año, adoptar x402 significaba instalar algo: middleware en Express, un decorador en FastAPI, un wrapper sobre una tool de MCP. En junio de 2026 AWS lo convirtió en un checkbox de una regla de firewall. El paywall ahora vive un hop antes de tu servidor, y eso cambia la forma del protocolo.

Dos de las redes más grandes de internet ahora terminan el HTTP 402 en su propio edge. AWS anunció AI traffic monetization el 15 de junio de 2026 como capacidad de WAF Bot Control, generalmente disponible con Amazon CloudFront sin cargo adicional más allá del pricing estándar de WAF. Dos semanas después, el 1 de julio, Cloudflare anunció el Monetization Gateway — la misma idea para cualquier cosa detrás de su red — y abrió una lista de espera. El 4 de agosto anunció Cloudflare Wallets, la mitad compradora de la misma máquina.

Cubrimos el seller stack y el buyer stack como librerías que instalas y controlas. La enforcement en el edge es una arquitectura distinta con el mismo formato de cable. Esto es lo que la documentación realmente dice, lo que pudimos verificar contra el repositorio del protocolo, y lo que se rompe.

La acción Monetize, con precisión

En AWS WAF, la monetización no es una superficie de producto propia. Es una sexta acción disponible en una regla, junto a Allow, Block, Count, Captcha y Challenge. Monetize es una acción terminante: cuando matchea una regla que la lleva, WAF deja de evaluar reglas siguientes, y un request sin autorización de pago válida recibe un HTTP 402 desde el edge.

La economía vive en un MonetizationConfig adjunto al web ACL, no en la regla. La guía de getting started documenta la estructura:

{
  "MonetizationConfig": {
    "CryptoConfig": {
      "PaymentNetworks": [
        {
          "Chain": "BASE",
          "WalletAddress": "0x1234...5678",
          "Prices": [{ "Amount": "0.001", "Currency": "USDC" }]
        },
        {
          "Chain": "SOLANA",
          "WalletAddress": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
          "Prices": [{ "Amount": "0.001", "Currency": "USDC" }]
        }
      ]
    }
  }
}

Se soportan cuatro cadenas: BASE y SOLANA para producción, BASE_SEPOLIA y SOLANA_DEVNET cuando CurrencyMode es TEST. Solo USDC. El monto es un string decimal en USD con máximo tres decimales, y el piso es $0.001 por request. La variación por regla viene de un PriceMultiplier en la acción: precio base por multiplicador da el precio efectivo, así que una regla con multiplicador "3" sobre una base de "0.001" cobra $0.003.

Ese es todo el modelo de pricing. Un precio base por cadena por web ACL, escalado por multiplicadores por regla. No hay noción de uso medido, ni settlement upto del consumo real, ni acumulación batch — las tres direcciones en las que el protocolo mismo se ha estado extendiendo, que recorrimos en el deep dive del scheme upto. El edge cobra un precio fijo por un request que todavía no le hizo a tu origin, porque en el momento del 402 no sabe qué va a devolver el origin ni cuán caro fue producirlo.

Settlement dentro del request path

El lifecycle de la página de how it works es donde la arquitectura diverge de todo despliegue con SDK que hayamos visto.

El agente pide un path monetizado. WAF matchea una regla Monetize y devuelve un 402 que lleva el precio en USDC, las redes aceptadas, la wallet del publisher como payTo, un timeout máximo y el scheme de pago. El cliente firma una autorización y reenvía el request original con un header payment-signature. WAF verifica — "this occurs synchronously in the request path", según los docs. Si la verificación pasa, el request va al origin. Si el origin devuelve 2xx, el pago se liquida on-chain a través del facilitator x402 de Coinbase Developer Platform, y recién entonces se sirve el contenido, con un header payment-response que lleva la confirmación del settlement.

El middleware de referencia no hace esto. En los SDK del seller, verify corre antes del handler y settle corre después de producida la respuesta; el seller absorbe una ventana en la que el trabajo ya se hizo y el settlement todavía puede fallar. AWS invierte el riesgo: el comprador absorbe la espera, y el seller nunca queda expuesto a trabajo impago. Es un trade defendible para un publisher. Es un trade áspero para un agente, y AWS lo dice en la página de configuración de pricing: la feature "adds several seconds of additional latency to requests that require payment processing", y "the exact latency depends on blockchain network conditions at the time of settlement".

Varios segundos, para un recurso con precio de una décima de centavo. El camino sin pago queda intacto — solo los requests que llevan firma de pago pagan el impuesto — pero cualquier loop de agente que recorra un edge pago ahora hace una escritura on-chain por fetch, in-band. Cloudflare, describiendo un producto que todavía no salió, dice que apunta a settlement sub-segundo. Nadie mostró ese número en producción todavía.

Hay una pieza de buen diseño en el ordenamiento: no hay pago por origins fallidos. Si el origin responde 4xx o 5xx, el settlement se salta y al cliente no se le cobra. El registro de settlement de ese request queda logueado con estado SKIPPED_ORIGIN_ERROR, junto a SETTLED, PENDING, FAILED y SERVICE_ERROR. Esta es la corrección al reclamo más viejo contra pagar antes de saber qué recibís, y solo funciona porque el edge se sienta entre el pago y el contenido.

Qué pasa cuando la capa de dinero se cae

Como el settlement es in-band, cada dependencia del settlement se vuelve dependencia de la entrega de contenido. AWS las enumera: indisponibilidad temporal del facilitator de Coinbase, congestión de la blockchain, errores transitorios on-chain. En los tres casos, "content is not served to the client. The client receives a response indicating the failure and can retry the request." Además, AWS se reserva el derecho de throttlear "excessively high volumes of payment traffic", con la indicación de hacer backoff y reintentar.

El reintento carga con mucho peso en esa frase. Un retry después de un settlement fallido es una segunda autorización firmada contra un recurso que quizá ya fue pagado. La respuesta del protocolo es la extensión payment-identifier, una idempotency key que se refleja en el payload de pago, y AWS la señala: los clientes "can retry requests without double-payment for up to 15 minutes, as long as the extension is used by the client".

Lo contrastamos contra la fuente. En el repositorio de x402 en HEAD db9dabd0 (4 de agosto de 2026), specs/extensions/payment_identifier.md define un id de 16 a 128 caracteres, una tabla de comportamiento (id nuevo, procesar; mismo id y mismo payload, devolver la respuesta cacheada; mismo id y payload distinto, 409 Conflict; required: true sin id, 400), y guía para atar cada id a un fingerprint normalizado del request que cubra scheme, network, asset, monto, payTo, path y método. Lo que no define es una ventana de retención. No hay quince minutos en la spec, ni un MUST o SHOULD en todo el documento — los resource servers y facilitators "may" usar el id. La ventana es un detalle de implementación de AWS descrito en prosa de AWS como si fuera protocolo.

La consecuencia práctica para quien escribe un agente: la idempotencia es opt-in del lado comprador, su duración es por despliegue, y la misma key contra un fingerprint distinto es un 409, no un reembolso. Si tu cliente no manda un id, una tormenta de retries durante congestión del facilitator es una tormenta de doble gasto. Es exactamente la clase de falla contra la que advertía el modelo de confianza del facilitator, ahora con un CDN global adelante.

La pregunta de caching que nadie respondió

Un CDN es un cache. Esa es su razón de existir. Las respuestas de x402 son, por construcción, los objetos menos cacheables de la web: un 402 es una cotización atada a un nonce, y un 200 pago lleva un header payment-response que describe el settlement de un comprador.

Así que grepeamos la especificación. En el mismo checkout del repositorio de x402, specs/ tiene cero ocurrencias de Cache-Control o no-store — ni en x402-specification-v2.md, ni en el documento del transporte HTTP. El texto normativo calla sobre caching.

Las implementaciones no. El 30 de julio de 2026 el mismo comportamiento aterrizó en tres SDK: PAYMENT_REQUIRED_CACHE_CONTROL = "no-store" en el core de TypeScript y en Python (PR #2990, que además mergea private en los 200 exitosos que llevan PAYMENT-RESPONSE "so shared caches cannot store user-specific settlement metadata"), y PaymentRequiredCacheControl en el servidor HTTP de Go (PR #2956). Marcamos el lado TypeScript y Python de esto en el roundup del 31 de julio cuando el cambio de Go seguía abierto; desde entonces mergeó.

El hueco es la parte interesante. El comportamiento correcto de caching para respuestas pagas existe solo como implementación convergente, en código de librería, en el origin — mientras los dos despliegues con mayor alcance son caches compartidos que hacen enforcement del protocolo ellos mismos. Ni AWS ni Cloudflare documentan qué hace su cache con un challenge 402 o con un 200 pago. AWS sí documenta un comportamiento adyacente que muestra la costura: su guía para adjuntar términos de licencia legibles por máquina usa una Response Header Policy de CloudFront para inyectar un header Link, y luego aclara que las response header policies aplican a respuestas del origin, así que "the 402 Payment Required Challenge served by the Monetize action will not include this header". El challenge y el contenido viajan por caminos distintos dentro del edge. Nada de lo que razones sobre uno vale automáticamente para el otro.

Dos edges, dos teorías de identidad

La discriminación de precios es el producto real acá, y requiere saber quién pregunta. Los dos edges responden distinto.

AWS responde con la clasificación de Bot Control: más de 650 tipos de bots y agentes, cada uno etiquetado y ordenado en un tier verificado (identidad confirmada criptográficamente) o no verificado (matching de user-agent y comportamiento). El patrón recomendado es condicionar la acción Monetize a un match de label, para que los humanos nunca vean un 402:

{
  "Name": "MonetizeBotTrafficOnly",
  "Priority": 5,
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "LABEL",
      "Key": "awswaf:managed:aws:bot-control:bot"
    }
  },
  "Action": { "Monetize": {} }
}

Esa guarda es necesaria porque, como dice AWS, "standard web browsers and human users cannot interpret or complete this payment flow — the 402 response will effectively block access for non-automated clients". Una regla mal configurada no degrada a una página de paywall. Degrada a un muro.

Y la clasificación de abajo es, en palabras de AWS, "probabilistic and might not correctly identify or categorize all bot traffic in all cases". Cobrar por identidad sobre una señal de identidad probabilística significa que una fracción de compradores paga el tier equivocado y una fracción de humanos paga. El test mode existe precisamente para eso: CurrencyMode: TEST corre el flujo completo — verificación, fetch al origin, settlement — sobre Base Sepolia y Solana Devnet con fondos de faucet, y etiqueta cada evento y cada query de analytics con el modo.

Cloudflare responde a la identidad con criptografía: el Monetization Gateway está documentado como integrado con Web Bot Auth, el perfil de HTTP message signatures que desarmamos en identidad de agentes sobre HTTP. Un request firmado es una afirmación que podés verificar en vez de inferir. También sube el piso: los agentes que no firman reciben el precio anónimo, que es el mismo tiering que AWS construye desde labels, llegando desde la dirección opuesta.

Ninguno de los dos edges cierra el tercer hueco. Precio no es permiso. AWS lo dice directo — la monetización "tells agents how much to pay but not what they're allowed to do with the content" — y apunta a RSL, Really Simple Licensing, descubrible vía robots.txt, un header Link, un link rel="license" en HTML, o un módulo RSS. El agente que paga una décima de centavo por una página todavía tiene que ir a buscar un XML aparte para saber si puede entrenar con ella y, según la nota de arriba, el 402 que acaba de recibir no traía el puntero.

La otra mitad de Cloudflare: el comprador se vuelve producto

El Monetization Gateway es un producto de seller con superficie más amplia que el de AWS: cobrar por "web pages, datasets, APIs, or MCP tools", con reglas escritas como expresiones en el dashboard, la API o Terraform, aplicadas en 330+ ciudades. Los ejemplos van más allá del precio fijo por request — un centavo por GET a un path premium, montos variables hasta $2, un fee base más un cargo por megabyte para uploads — y un patrón destaca: interceptar un 401 y exigir pago en su lugar. Esa es la conversión walk-up que mapeamos en bearer contra x402, convertida en regla de edge. El settlement es en stablecoins, Open USD y USDC.

Después, el 4 de agosto, la otra mitad. Cloudflare Wallets se parte en Account Wallets, "designed for humans who are owners and users of Cloudflare accounts", que guardan fondos y delegan gasto, y Virtual Wallets, "designed for agents", que "operate via API keys" y gastan dentro de los permisos que fija el dueño de la cuenta. Los guardrails nombrados son un allowance, una allow list y un tamaño máximo de transacción, con detección de anomalías que escala a revisión humana. La identidad recibe forma legible: Web Bot Auth "already allows agents to register their identity via a keypair", y un handle de wallet como research.example.cloudflare.pay vuelve direccionable ese keypair. Los handles se pueden reclamar ya; pagar con ellos es "soon".

Leé la lista de guardrails de nuevo — allowance, allow list, techo de transacción. Es el mismo trío que los execution permissions de ERC-7715, las Spend Permissions de Coinbase, el objeto allowance de ACP y el techo del scheme upto, que rastreamos en account abstraction para wallets de agentes. La industria convergió en la forma de un spend mandate. Lo que difiere es la custodia, y el anuncio no dice quién tiene las llaves detrás de una Virtual Wallet, ni sobre qué cadenas o activos liquida. Un agente que gasta con una API key contra un balance que administra una plataforma no está haciendo settlement no custodial, sea cual sea el protocolo de cable debajo. La propiedad fundacional de x402 era que el pago es la credencial y no hace falta cuenta con el seller. Una wallet a la que entrás con una API key reintroduce exactamente una cuenta — con el edge.

Qué significa para LLM4Agents

Tres efectos, en orden de qué tan pronto muerden.

Primero, ahora somos compradores, lo hayamos planeado o no. Documentación, feeds de datos y tools de MCP que nuestros agentes consultan se están mudando detrás de edges que responden 402. Nuestro camino HTTP saliente tiene que tratar un 402 como una rama normal y presupuestada: parsear los requirements, chequear el precio contra un techo por dominio, firmar, reintentar, registrar el recibo. Dos detalles no son negociables dados los que leímos. Mandar un payment-identifier en cada request pago — es opt-in, la ventana de retención del seller no está documentada y depende del despliegue, y sin él una caída del facilitator convierte los retries en pagos duplicados. Y presupuestar la latencia: un edge que liquida in-band puede tener un request abierto por segundos, así que los fetches pagos necesitan su propia clase de timeout, separada de las tool calls comunes, o una URL con paywall traba un loop de agente entero.

Segundo, nuestro propio modelo de billing es el opuesto, y ese es el lado correcto. El gateway reserva contra un balance, proxea la llamada al modelo, y después liquida lo que realmente se consumió — el ciclo reserve, proxy, settle. El edge cobra un precio fijo antes de saber qué va a producir el origin, lo cual está bien para un artículo estático y está mal para una completion de LLM cuyo costo depende de los tokens generados. Nadie factura inferencia correctamente con un precio plano por request en un firewall. Donde el modelo del edge sí es mejor es en su regla de error de origin: sin settlement en 4xx/5xx. Deberíamos sostener el mismo estándar y hacerlo explícito — una falla del upstream no liquida nada.

Tercero, la identidad en el edge se vuelve un input de costo. Ambas redes cobran según quién pregunta. En AWS eso es un label probabilístico; en Cloudflare es una firma Web Bot Auth. Si nuestro tráfico de egress no está firmado ni clasificado, cae por defecto en el tier no verificado y paga el precio más alto en cada edge que discrimina. Firmar los requests salientes deja de ser un proyecto de reputación y pasa a ser una línea de costo.

Cómo mantenerse en la frontera

Concreto, ordenado por apalancamiento.

1. Shippear la idempotency key del lado comprador. Generar un id con prefijo pay_ por operación lógica saliente, atarlo al fingerprint del request que describe la spec (scheme, network, asset, monto, payTo, path, método), y reusarlo en cada retry de esa operación. Tratar un 409 Conflict como bug de nuestro fingerprinting, no como falla de pago.

2. Dar a los fetches pagos su propia clase de timeout y presupuesto. Un techo de precio por dominio, un tope de gasto por corrida, y un timeout que tolere settlement in-band sin dejar que bloquee el resto del trabajo del agente. Loguear cada 402 que aceptamos y cada uno que rechazamos por precio — rechazar es un resultado válido y debe ser visible.

3. Firmar nuestro egress. Adoptar Web Bot Auth para los requests salientes del gateway: una llave Ed25519, un JWKS en /.well-known/http-message-signatures-directory, Signature-Agent en cada fetch. Eso nos califica para tiers de precio verificado en los edges que los ofrecen y les da a los sellers a los que compramos algo mejor que un string de user-agent.

4. Imponer disciplina de cache en ambos lados. Nuestras respuestas que llevan metadata de pago van con no-store en el 402 y private en el 200 pago, igual que lo que convergieron los SDK en julio, y ningún proxy nuestro cachea ninguna de las dos. Vale la pena escribirlo como regla precisamente porque la especificación no lo dice.

5. Correr paridad de testnet en CI. El test mode de AWS existe porque los modos de falla son fallas de configuración. El equivalente para nosotros es un test de integración que ejercite el camino pago completo contra Base Sepolia y Solana Devnet en cada cambio al código de pagos — la misma disciplina que aplicamos a la evaluación de tools en CI.

6. Publicar términos legibles por máquina. Un documento de licencia RSL para todo lo que exponemos, referenciado desde robots.txt y un header Link. Cuesta una tarde, y es la diferencia entre un precio y un contrato.

7. Tratar las wallets custodiales como rail de fondeo, no de ejecución. Si las Virtual Wallets o un equivalente se vuelven la forma fácil de fondear un agente, usarlas en el borde — cargar saldo, y después ejecutar de forma no custodial con llaves que tenemos nosotros. En el momento en que una API key puede mover fondos, el modelo de seguridad es de la plataforma, no nuestro.

El edge no cambió el protocolo. Cambió quién lo corre, y movió el punto de enforcement al único lugar de internet cuyo trabajo es responder antes que el origin. Eso es cómodo para los publishers y caro, en latencia y en identidad, para los agentes que compran. Construir el comprador que lo maneje bien es la mitad más interesante.