El scheme upto de x402: billing medido de agentes con Permit2

El scheme exact responde una sola pregunta: paga este monto preciso, recibe el recurso. Pero el costo de una llamada LLM no se conoce hasta que se genera el último token. El scheme upto es la respuesta de x402 al billing medido — el agente autoriza un máximo, el servidor liquida el monto real, y Permit2 hace cumplir el tope on-chain.

Cerramos el deep dive del exact SVM con una predicción: la primera cadena que entregue un scheme medido usable se convierte en el rail de settlement más interesante para un gateway que factura por token. El scheme existe hoy, y vive donde vive el resto del protocolo — dos archivos de spec en el repositorio coinbase/x402, scheme_upto.md para el contrato agnóstico de cadena y scheme_upto_evm.md para la implementación EVM. El primer caso de uso de la propia spec, textual: "Paying for LLM token generation (charge per token generated)". Es un scheme escrito exactamente para la carga de trabajo que lleva un gateway de inferencia.

Y ya está en producción. Apify lo corre sobre más de 20,000 Actors, cobrando el uso real contra un allowance firmado por el cliente. Antes de llegar ahí, la mecánica.

El problema que exact no puede tarifar

El scheme exact — EIP-3009 en EVM, transacciones parcialmente firmadas en Solana — liquida un monto fijo que ambas partes conocen antes de que corra el request. Eso encaja con un paywall por artículo o una API de precio plano por llamada. No encaja con pricing por uso, y la spec de upto nombra las formas para las que fue escrita: generación de tokens LLM, metering de bandwidth cobrado por byte transferido en un solo request, y cómputo dinámico tarifado por recursos realmente consumidos.

Sin upto, un vendedor de trabajo medido tiene dos malas opciones. Cobrar el peor caso por adelantado y reembolsar la diferencia — lo que significa que cada request sobre-bloquea los fondos del cliente y el vendedor carga con la plomería de refunds. O ejecutar el trabajo primero y facturar después — lo que significa extender crédito a una wallet anónima. El scheme upto parte la diferencia criptográficamente: en la verificación, la firma del cliente cubre un máximo; en el settlement, el servidor nombra el monto real, y la cadena rechaza cualquier cosa por encima del tope.

Esa lectura del mismo campo según la fase es el corazón del scheme. El amount de PaymentRequirements significa "máximo que el cliente autoriza" durante la verificación y "monto real a cobrar" durante el settlement. En palabras de la spec, el monto liquidado "es comunicado por el resource server al facilitator vía el campo amount del PaymentRequirements del momento de settlement" — y el facilitator DEBE verificar que no exceda el máximo autorizado por la firma del cliente.

Cinco invariantes

La spec agnóstica de cadena es corta porque es sobre todo una lista de MUSTs. Cinco de ellos definen el scheme.

Un solo uso. Cada autorización se liquida a lo sumo una vez. Una vez liquidada — por cualquier monto — queda consumida. La spec justifica la decisión sin rodeos: un audit trail claro, un modelo mental más simple, y un calce con el patrón request-response de x402. No hay cuenta corriente; una autorización mapea a un request.

Acotada en el tiempo. Toda autorización lleva una ventana de validez explícita: un validAfter antes del cual es inválida y un deadline tras el cual expira. Esto limita la ventana de exposición de autorizaciones sin usar y fuerza un settlement oportuno.

Ligada al destinatario. La autorización liga criptográficamente la dirección del destinatario, lo que impide que un facilitator malicioso redirija fondos. En EVM ese es el trabajo del patrón witness de Permit2 — más abajo.

Con tope. El monto liquidado DEBE ser menor o igual al máximo autorizado — y PUEDE ser cero. El cero importa: si no hubo uso, no hay cobro, y en EVM un settlement en cero no requiere transacción on-chain en absoluto.

Protegida contra replay. En EVM, el mecanismo de nonces de Permit2 hace cumplir la regla de un solo uso; la spec exige que cualquier otra red implemente protección de replay equivalente antes de que pueda existir una implementación de upto allí.

Por qué Permit2 y no EIP-3009

EIP-3009 no puede cargar este scheme. Una firma de transferWithAuthorization hornea el value exacto dentro del mensaje firmado — el contrato del token mueve ese monto o nada. No hay forma de liquidar menos de lo firmado. Un máximo-con-settlement-variable necesita otro primitivo, y la spec EVM toma uno que lleva en producción desde 2022: Permit2 de Uniswap, desplegado en la misma dirección canónica (0x000000000022D473030F116dDEE9F6B43aC78BA3) a través de cadenas.

La mitad SignatureTransfer de Permit2 hace precisamente lo que upto necesita. El cliente firma un PermitTransferFrom que nombra un token y un monto permitido; el spender puede entonces ejecutar una transferencia de hasta ese monto, una vez, antes del deadline. Los nonces son desordenados — un bitmap en vez de un contador — así que un agente puede sostener muchas autorizaciones abiertas en paralelo sin secuenciarlas. Y la variante witness, permitWitnessTransferFrom, pliega datos tipados extra dentro del digest EIP-712 que el cliente firma, de modo que restricciones arbitrarias del scheme pasan a ser parte de la firma misma.

La spec EVM de upto usa ese slot de witness para tres campos: to (el destinatario, cerrando el ataque de redirección), facilitator (la dirección autorizada a ejecutar el settlement) y validAfter (el inicio de la ventana de validez — Permit2 nativamente solo lleva el deadline). El payload de pago que envía el cliente es la firma más la autorización completa que cubre:

{
  "x402Version": 2,
  "payload": {
    "signature": "0x…",  // EIP-712, permitWitnessTransferFrom
    "permit2Authorization": {
      "permitted": {
        "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",  // USDC en Base
        "amount": "250000"  // el MÁXIMO: $0.25
      },
      "from": "0x…",       // wallet del cliente
      "spender": "0x…",    // el proxy Permit2 de x402
      "nonce": "0x…",      // desordenado, un solo uso
      "deadline": "1753142400",
      "witness": {
        "to": "0x…",          // destinatario, ligado en la firma
        "facilitator": "0x…", // del extra de /supported del facilitator
        "validAfter": "1753138800"
      }
    }
  }
}

Un prerequisito queda fuera del flujo: la wallet del cliente debe haber aprobado el contrato canónico de Permit2 como spender del token, una vez por token. La spec ofrece tres rutas — una transacción approve directa donde el cliente paga gas, un ERC-20 approval patrocinado donde el facilitator lo cubre, o un permit EIP-2612 si el token lo soporta. Es setup de una sola vez, pero es el único lugar donde el scheme upto pierde la propiedad pura de "la firma es el pago, sin gas nunca" que hace tan limpios los pagos walk-up con EIP-3009 para wallets recién creadas.

El proxy y la checklist del verificador

Permit2 solo no hace cumplir la vinculación al facilitator, así que la spec introduce un contrato delgado entre el facilitator y Permit2: x402UptoPermit2Proxy, desplegado en 0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002 — una dirección vanity que abre y cierra con 402. El proxy lleva el campo facilitator en su struct de witness para control de acceso, y su función settle es donde el monto variable se vuelve concreto:

x402Permit2Proxy.settle(permit, actualAmount, owner, witness, signature)
// requiere: actualAmount <= permit.permitted.amount

Intentar liquidar por encima del tope falla con el error dedicado del scheme, invalid_upto_evm_payload_settlement_exceeds_amount. Liquidar cero se salta la cadena por completo — la respuesta de settlement devuelve success: true con un hash de transacción vacío. Y toda respuesta de settlement lleva un campo amount obligatorio que reporta lo realmente cobrado, en unidades atómicas, de modo que el cliente conoce el costo real en el momento en que el recurso regresa.

La verificación es más pesada que la de exact, y la spec guía al facilitator por los chequeos: recuperar el firmante de la firma EIP-712 y cotejarlo contra permit2Authorization.from; confirmar que el allowance ERC-20 del cliente hacia Permit2 cubre el máximo — y si no lo cubre, devolver 412 Precondition Failed con PERMIT2_ALLOWANCE_REQUIRED en vez de un fallo genérico, para que los clientes puedan disparar el approval de una sola vez; confirmar balance; confirmar que el monto permitido iguala el amount de los requirements; chequear deadline y validAfter; cotejar token y red; y finalmente simular el peor caso — una llamada a settle por el monto completo — antes de responder que el pago es válido. La simulación importa porque la verificación ocurre antes de conocer el uso: el único monto que vale la pena simular es el tope.

Prueba en producción: 20,000 Actors

Esto no es una spec de papel. El 30 de junio de 2026, Apify puso más de 20,000 Actors en x402, liquidando USDC en Base, con upto como scheme primario para runs de costo variable y exact a su lado. El flujo es la spec al pie de la letra: el cliente envía un allowance firmado, Apify arranca el run del Actor, y el cobro final es el uso real — desde cero hasta el tope aprobado. Sus anclas de precio publicadas le dan textura concreta al scheme: un dólar compra aproximadamente 380 perfiles de Instagram, 250 lugares de Google Maps, 165 productos de Amazon o 2,500 posts de X, con la cifra exacta dependiendo de lo que cada run consumió.

Los runs de scraping y las llamadas de inferencia tienen la misma forma económica — trabajo variable, costo conocido solo al completarse, demasiado pequeño para facturar. Un despliegue en producción a esta escala, alcanzable a través del Agentic Wallet CLI de Coinbase y un cliente MCP con soporte x402, es la señal más fuerte hasta ahora de que el metering con autorización con tope se está volviendo la forma default en que los agentes compran trabajo de costo variable.

El patrón allowance está convergiendo

Da un paso atrás y upto se ve familiar. El delegated payment del Agentic Commerce Protocol adjunta un allowance — max_amount, expires_at, un solo uso — a un token de tarjeta en vault. Los permisos ERC-7715 y las session keys otorgan al agente un presupuesto de gasto acotado y con tope en la capa de wallet. Y upto liga un tope por request dentro de una firma Permit2. Tres rails — tarjeta custodial, smart account, transferencia de stablecoin — aterrizaron de forma independiente en el mismo primitivo: nunca darle a un agente autoridad de gasto abierta; darle un techo criptográficamente exigible y cobrar reales por debajo.

Las diferencias son alcance y granularidad. Una session key es un presupuesto permanente a través de muchos requests; un allowance de ACP cubre un checkout; una autorización upto cubre exactamente un request-response de x402. Para trabajo medido machine-to-machine, el tope por request es el más estrecho de los tres — el radio de daño de un agente comprometido o confundido es el máximo de un request, no el presupuesto de un día.

Qué significa para LLM4Agents

El billing por token es la unidad nativa de esta plataforma, y upto es el primer scheme de x402 cuya semántica le calza exacto. Nuestro pipeline reserve → proxy → settle ya implementa internamente el ciclo de vida de upto: reservar un monto de peor caso contra el balance depositado del agente, correr la inferencia, liquidar el costo real en tokens, liberar la diferencia. El scheme upto es esa misma máquina de estados empujada hasta el rail de settlement — permitted.amount es la reserva, el amount del momento de settlement es el real medido, y la regla de settlement en cero cubre la ruta de refund del request fallido sin transacción alguna.

Esa correspondencia corta en ambas direcciones. Significa que el gateway podría ofrecer un tier medido de walk-up verdadero: un agente sin depósito firma una autorización upto con tope en, digamos, max_tokens por el precio por token, y paga solo por los tokens realmente generados — sin cuenta, sin balance prepago, sin flujo de refunds. También significa que el modelo de depósito conserva una ventaja real: sin prerequisito de approval de Permit2, sin firma por request, sin latencia de settlement on-chain en la ruta del request. Las plataformas que ganen ofrecerán ambos y dejarán que la postura de wallet del agente decida.

La lectura competitiva es igual de directa. Apify probó el scheme a escala para scraping; la inferencia es el mercado más grande con la misma estructura de costos. Un gateway que puede cotizar un 402 con un requirement upto, medir la generación y liquidar reales tiene una historia estrictamente mejor para tráfico de agentes one-shot que cualquier competidor solo-prepago.

Cómo mantenerse en la frontera

Pasos concretos, en orden. Primero, prototipar el lado seller en testnet de Base: exponer un endpoint del gateway cuya respuesta 402 ofrezca scheme: "upto" con un tope derivado del max_tokens del request, verificar contra un facilitator que implemente la checklist de arriba, y liquidar el real medido desde el pipeline de billing existente. La maquinaria interna de reservas ya computa cada número que el scheme necesita.

Segundo, tratar el prerequisito de approval como onboarding, no como un fallo a mitad de request. Detectar PERMIT2_ALLOWANCE_REQUIRED y devolver guía accionable — incluida la ruta de approval patrocinado para wallets que tienen USDC pero no gas, que es la condición normal de una wallet de agente.

Tercero, publicar evidencia de metering por settlement. El delta de confianza del scheme es carga del vendedor; una respuesta de settlement cuyo amount viene acompañado de un desglose de conteo de tokens que el cliente puede cotejar contra el cuerpo de la respuesta convierte el "confía en nosotros dentro del tope" en algo auditable — y en un argumento de venta.

Cuarto, vigilar el directorio de specs. Hoy upto tiene un contrato agnóstico de cadena y una implementación concreta, EVM vía Permit2. No hay variante SVM todavía — el modelo de transacciones de Solana no tiene equivalente de Permit2, así que un scheme medido ahí necesitará otro primitivo, exactamente el tipo de divergencia que los schemes exact ya mostraron. Quien siga esa brecha, la cierra primero.