x402 batch-settlement por dentro: commit ahora, settlement después

x402 arrancó con una idea: pagar por request, liquidar por request. Su tercer scheme rompe esa simetría. Con batch-settlement, el cliente firma un commitment al momento del request, recibe el recurso de inmediato, y el dinero se mueve después — agregado, fuera de banda, por el rail que la red defina.

Ya cubrimos los otros dos schemes en esta serie. El scheme exact liquida el monto preciso on-chain antes de servir el recurso. El scheme upto autoriza un máximo y liquida el uso real. Ambos comparten un supuesto: cada request termina mapeando a una transferencia on-chain. batch-settlement abandona ese supuesto por completo. La verificación sigue ocurriendo por request. El settlement se convierte en un proceso contable.

Eso lo hace el scheme con forma más de finanzas tradicionales de toda la familia x402 — y, hoy, el rail debajo del pay-per-crawl de Cloudflare. Este post recorre la spec genérica, los dos modelos de confianza que permite, y el network binding de Cloudflare que convierte firmas HTTP Message Signatures (RFC 9421) en commitments de pago facturables.

Por qué el settlement por request deja de tener sentido

La economía es directa. Si un crawler descarga una página que cuesta una fracción de centavo, ejecutar una transferencia blockchain por cada descarga cuesta más — en fees, en latencia, en superficie operativa — que el contenido mismo. Incluso con primitivos gasless como EIP-3009 trasladando los fees a un facilitator, alguien sigue pagando por transacción, y la latencia del settlement queda dentro del request path.

Cloudflare planteó el requerimiento sin rodeos cuando anunció el soporte de x402 y la x402 Foundation en septiembre de 2025: los agentes y crawlers necesitan "settlement diferido para acomodar disputas; y un pago único agregado que simplifique su contabilidad". Los crawlers en la beta de pay-per-crawl "pueden crawlear una cantidad enorme de páginas con facilidad, generar audit logs, y recibir un cargo único vía una tarjeta de crédito o cuenta bancaria conectada al final de cada día".

Eso es un producto distinto a una transferencia de stablecoin por request. Es consumo medido con facturación al cierre del día — el modelo de billing que ya opera todo proveedor cloud — expresado a través del handshake de x402 para que el mismo código cliente pueda hablar con ambos mundos.

De la propuesta "deferred" a un scheme con spec

La idea entró al protocolo en dos pasos. El post de Cloudflare de septiembre de 2025 esbozó un scheme literalmente llamado deferred: la respuesta 402 llevaba una entrada en accepts con el scheme, un identificador de red, la URL del recurso, y un objeto extras con un id de transacción y un termsUrl apuntando al acuerdo que gobierna el pago diferido. En caso de éxito, el servidor respondía con un header Payment-Response — un recibo de un pago que todavía no había ocurrido:

# Propuesta deferred original — respuesta de éxito
Payment-Response: scheme="deferred", network="example-network-provider",
  id="abc123", timestamp=1730872968

Dos detalles de ese boceto sobrevivieron al diseño final. El termsUrl reconoce que un pago diferido es una relación legal antes que criptográfica — la firma te compromete con términos que viven en un documento, no en el payload. Y el id de la respuesta es el ancestro del commitment identifier de la spec: la referencia que ambas partes sostienen mientras el dinero sigue en vuelo.

La versión generalizada aterrizó en el repositorio de especificación de x402 como specs/schemes/batch-settlement, agregada junto a una especificación de red de Cloudflare (PR #1145) y fusionada al repo principal con la sincronización del repo de la foundation en abril de 2026. El renombre importa: "deferred" describía una demora; "batch-settlement" describe una arquitectura. El resumen de una línea que hace la spec de la divergencia con sus hermanos es preciso: la verificación confirma que el commitment es válido, pero el settlement lo almacena en lugar de ejecutar una transferencia.

El ciclo de vida: commit, accumulate, redeem

La spec genérica define tres fases, y solo la primera toca el request path.

Este es el mismo desacople que describimos en los internals de nuestro propio billing — reserve, proxy, settle — empujado un nivel más allá. Ahí, el settlement todavía ocurre por llamada contra un balance prefondeado. Acá, el settlement tiene permiso de abandonar el request path por completo.

Lo que un network binding debe clavar

Como la spec genérica deliberadamente no define estructuras de payload concretas, ni campos HTTP, ni códigos de error, todas las decisiones estructurales se mueven al network binding. La spec hace siete de ellas obligatorias. Todo binding debe definir su formato de commitment y su encoding; sus reglas de verificación (esquema de firma, chequeos de balance o crédito, prevención de replay, lógica de expiración); su comportamiento de almacenamiento y qué contiene el commitment identifier; su prevención de double-spend, para que un commitment se acepte y redima exactamente una vez; su semántica de expiración para commitments que nunca se redimen; su proceso de redención — quién lo dispara, cuándo, y por qué rail; y su modelo de confianza.

Ese último punto es donde el scheme se divide en dos familias.

Los bindings capital-backed mantienen los fondos del cliente como garantía: escrow prefondeado, payment channels con recibos firmados acumulados, o autorizaciones delegadas de wallet. Ningún intermediario asegura nada; si los commitments superan el escrow, la verificación falla. Esta es la forma crypto-nativa — los payment channels para micropagos en streaming son el ejemplo canónico.

Los bindings credit-backed reemplazan capital por identidad: el cliente es una entidad verificada con una cuenta de billing administrada por un intermediario de confianza, y el settlement corre por infraestructura off-chain en un calendario. Esta es la forma de toda factura a 30 días jamás emitida — y la forma que eligió Cloudflare.

El binding de Cloudflare: cloudflare:402

La especificación de red de Cloudflare es el primer binding concreto, y es credit-backed sin disculpas: Cloudflare actúa como Merchant of Record, "agregando los commitments de pago, facturando a la identidad asociada a cada signature agent, y distribuyendo el revenue a los dueños del contenido de forma periódica a través de rails financieros off-chain tradicionales".

El identificador de red es cloudflare:402 en formato CAIP-2 — un namespace que nombra un código de estado HTTP en lugar de una blockchain, lo que te dice todo sobre dónde vive el settlement. La entrada de accepts cotiza en la unidad mínima de una moneda ISO 4217 (centavos de USD, no unidades atómicas de USDC) y fija payTo en la constante "merchant", porque el ruteo real del payout es asunto de Cloudflare, no del protocolo:

{
  "scheme": "batch-settlement",
  "network": "cloudflare:402",
  "amount": "5",          // unidad mínima — centavos para USD
  "asset": "USD",         // ISO 4217, no una dirección de token
  "payTo": "merchant",    // constante — el ruteo es off-protocol
  "extra": { "version": "..." }
}

El cliente acepta la oferta adjuntando un header PAYMENT-SIGNATURE: un payload JSON codificado en base64 con x402Version: 2, el amount y asset comprometidos, y un objeto accepted que replica la entrada de requirements con la que está de acuerdo. Devolver la oferta como eco importa — evita el desajuste donde el servidor verifica una firma contra términos distintos a los que el cliente creyó firmar.

RFC 9421 como formato de commitment

Lo que hace vinculante al commitment no es el header en sí sino la HTTP Message Signature que lo envuelve. El binding de Cloudflare exige una firma RFC 9421 que cubra tres componentes: @authority (el host contra el que se cobra, lo que bloquea el replay cross-origin), signature-agent, y payment-signature — de modo que el payload de pago queda dentro del sobre firmado, no al lado.

# El commitment es un request firmado
Signature-Agent: https://crawler.example.com
Signature-Input: sig1=("@authority" "signature-agent" "payment-signature");\
  created=...;expires=...;keyid=...;tag="web-bot-auth"
Signature: sig1=:...:
PAYMENT-SIGNATURE: <payload x402 en base64>

Si esto te resulta familiar, debería: es el stack de Web Bot Auth reutilizado como primitivo de pago. El único algoritmo soportado es ed25519. Los tags soportados son web-bot-auth y agent-browser-auth. El cliente publica sus claves públicas en un endpoint /.well-known/http-message-signatures-directory, identificadas por el keyid de thumbprint JWK, y registra esa URL de directorio con Cloudflare para asociar la identidad firmante a una cuenta de billing. La verificación corre entonces en cinco pasos: reconocer al signature agent y traer su clave, verificar la firma, chequear el monto y asset comprometidos contra la oferta, chequear la frescura del timestamp (la spec sugiere una ventana de unos 30 segundos), y confirmar que el objeto accepted coincide con lo ofrecido.

La consecuencia es elegante: identidad y pago colapsan en una sola firma. Un crawler que puede probar quién es puede, con la misma clave y el mismo RFC, probar qué aceptó pagar. Cada request firmado se vuelve una entrada en un audit log que ambas partes pueden verificar, y el cargo al cierre del día es la suma de las entradas. Las disputas obtienen un rastro criptográfico en lugar de un log de servidor.

El vocabulario de errores del binding refleja el modelo de crédito. Junto a los esperables invalid_signature, invalid_payment_signature y price_not_acceptable, está signature_agent_unknown — tu directorio de claves no está registrado en la red — y blocked, porque un Merchant of Record puede simplemente negarse a extender crédito. payment_failed, origin_error y unknown completan el set.

Dónde queda realmente el riesgo

Diferir el settlement mueve el riesgo; no lo elimina. Los componentes obligatorios de la spec genérica se leen como un checklist de las formas en que un rail diferido falla, y cada uno mapea a un ataque o escenario de pérdida concreto.

El replay es el más filoso. En el scheme exact, la protección contra replay se hereda de la chain — un nonce de EIP-3009 se consume una vez, punto. En batch-settlement, la prevención de replay es lo que el binding diga que es. El binding de Cloudflare se apoya en tres capas: el componente firmado @authority (un commitment para un host no puede reproducirse contra otro), la ventana created/expires con un chequeo de frescura de unos 30 segundos, y el almacenamiento de la propia red marcando cada commitment como aceptado exactamente una vez. Un binding que escatime en cualquiera de las capas convierte un request firmado en varios facturados — y a diferencia de un double-spend on-chain, el cliente quizás solo lo descubra en la factura.

La expiración es la falla más silenciosa. Un commitment aceptado pero nunca redimido es un pasivo sentado en un store: el vendedor ya sirvió el recurso y sostiene una promesa que envejece hacia la nada. Por eso la spec obliga a los bindings a definir tanto cuándo los commitments no aceptados se invalidan como qué pasa con los aceptados-pero-no-redimidos. En los bindings credit-backed este es el problema del intermediario — Cloudflare factura en su propia cadencia y absorbe el riesgo de cobro como Merchant of Record. En los capital-backed se vuelve un problema de dimensionamiento del escrow: los fondos bloqueados del cliente deben cubrir la ventana de peor caso entre commit y redeem, que es exactamente el costo de eficiencia de capital que el modelo de crédito existe para evitar.

Tres schemes, una decisión

Con batch-settlement especificado, la familia de schemes de x402 ahora cubre tres posiciones distintas en el eje del timing de settlement. exact: el monto se conoce de antemano y se liquida on-chain antes del acceso; confianza mínima, una transacción por request. upto: el tope se autoriza de antemano, el uso real se liquida después; sigue habiendo un settlement on-chain por interacción, dimensionado a la realidad. batch-settlement: una promesa firmada por request, cero transacciones on-chain en el request path, redención en una cadencia — con capital o crédito respaldando la promesa.

La decisión entre ellos es la que mapeamos en el árbol de decisión Bearer vs x402 walk-up, extendida un nodo: ¿cuánta confianza de contraparte tiene ya tu interacción? El tráfico walk-up anónimo quiere exact — sin relación, sin crédito. Las sesiones medidas con techo conocido quieren upto. El tráfico de alta frecuencia, bajo valor y relación repetida — el crawling es el arquetipo — quiere batch-settlement, porque la relación misma es el colateral.

Hacia dónde va esto ya es visible. El 1 de julio de 2026, Cloudflare anunció el Monetization Gateway — extendiendo el modelo de pay-per-crawl de "cobrar a los crawlers de IA por páginas" a "cobrar a cualquier caller por cualquier recurso": APIs, datasets, llamadas a tools MCP, con verificación de pago en el edge. En el lanzamiento liquida en stablecoins sobre x402 estándar (USDC entre ellas), con waitlist abierta. Los dos rails ahora corren lado a lado bajo un mismo techo: settlement en stablecoin para callers walk-up, commitments batch credit-backed para crawlers registrados. Un vendedor detrás de Cloudflare no elige un rail; publica un precio, y la negociación de schemes elige el rail por caller.

Qué significa para LLM4Agents

LLM4Agents opera un modelo prefondeado con settlement por llamada: los agentes depositan stablecoins, y nuestro pipeline reserve-proxy-settle debita el uso real por request. batch-settlement nos es relevante de ambos lados del mostrador.

Como preocupación del lado comprador: nuestros agentes consumen recursos externos, y una porción creciente de la superficie machine-readable de la web está quedando detrás del pricing de Cloudflare — pay-per-crawl hoy, recursos arbitrarios vía el Monetization Gateway después. Un gateway de agentes cuyo stack saliente solo habla exact podrá pagar el rail de stablecoins pero no el rail de commitments. Soportar el binding de Cloudflare como cliente implica sostener una identidad firmante ed25519, publicar un directorio de claves, registrarlo contra una cuenta de billing, y firmar los requests salientes según RFC 9421 — maquinaria que ya describimos en parte para Web Bot Auth. El trabajo de identidad y el de pago convergieron en la misma ceremonia de claves.

Como lección de arquitectura del lado vendedor: el scheme valida un patrón que ya corremos internamente. Nuestro pipeline de billing verifica por llamada pero agrupa la contabilidad; la spec generaliza exactamente esa separación y le da un formato de wire. Un futuro binding capital-backed — commitments girados contra el balance depositado de un agente, redimidos en agregado — nos dejaría recortar el overhead de settlement por request en tool calls de alta frecuencia sin asumir riesgo de crédito, porque el escrow ya está con nosotros. Ese es el modelo de confianza capital-backed aplicado a un balance que ya sostenemos.

La advertencia estratégica es la concentración. El único binding en producción hace de Cloudflare el Merchant of Record, el registro de identidad y el rail de settlement a la vez. Es el mismo trade de centralización que señalamos para x402 Bazaar: el protocolo abierto es real, pero la primera red operativa es el edge de una sola empresa.

Cómo mantenerse en la frontera

Secuencia concreta, en orden de prioridad. Primero, agregar firma de requests RFC 9421 a nuestro stack HTTP saliente — una identidad firmante por cuenta de operador, claves en el key manager y nunca en el contexto del LLM, directorio servido en /.well-known/http-message-signatures-directory. Esto desbloquea con una sola inversión tanto la verificación de Web Bot Auth como el binding de pago de Cloudflare. Segundo, registrar la identidad firmante en el flujo de verificación de crawlers de Cloudflare y probar contra orígenes con pay-per-crawl activo, para que los agentes puedan consumir contenido con pricing por commitment el día que un workload lo necesite. Tercero, extender nuestro cliente x402 para parsear entradas batch-settlement en arrays accepts y seleccionar schemes por política: preferir exact para one-shots anónimos, upto para sesiones medidas, batch-settlement donde exista una relación registrada y el settlement por request sea desperdicio. Cuarto, prototipar un binding capital-backed sobre nuestros propios depósitos — commitments firmados por llamada contra balance reservado, redención en batch hacia el ledger del operador — y medir el overhead de settlement que elimina en workloads MCP conversadores. Quinto, vigilar el repo de la spec: la capa genérica del scheme es deliberadamente delgada, y los próximos network bindings (payment channels, contratos de escrow) definirán si el batch settlement queda como un producto de Cloudflare o se convierte en un rail abierto.