Dentro del facilitator x402: verify, settle, supported

Todo pago x402 termina igual: un resource server le entrega un payload firmado a un facilitator y hace dos preguntas — ¿es válido? y ¿llegó on-chain? Tres endpoints HTTP las responden. Este es un recorrido por ese API, su modelo de confianza y el mercado de servicios que ya lo implementa.

En las últimas dos semanas diseccionamos los tres schemes de settlement de x402: exact en EVM vía EIP-3009, exact en Solana vía transacciones parcialmente firmadas, upto vía Permit2 y batch-settlement para redención diferida. Cada scheme define cómo luce un pago válido. Pero ninguno define quién lo comprueba. Ese trabajo le corresponde a un componente que los specs tratan casi como nota al pie y los sistemas en producción tratan como infraestructura crítica: el facilitator.

El API del facilitator es pequeño — dos endpoints POST y un GET — pero es la bisagra de todo el protocolo. Hazlo bien y un seller acepta pagos en stablecoins en cinco redes sin tocar un solo nodo RPC. Hazlo mal y habrás delegado el reconocimiento de tus ingresos a un tercero que nunca auditaste. La especificación v2 de x402, hoy mantenida bajo la x402 Foundation, por fin fija el contrato con precisión. Recorrámoslo.

El rol: acceso a la chain tercerizado, no custodia tercerizada

Un facilitator, según el spec, es "un servicio que maneja la verificación de pagos y el settlement en blockchain". Los resource servers pueden "delegar las operaciones de blockchain en terceros de confianza o alojar los endpoints ellos mismos". La documentación oficial agrega la frase estructural: el facilitator "no retiene fondos ni actúa como custodio".

Esa propiedad no-custodial no es una promesa de política. Se deriva del diseño de los schemes. En el scheme exact, el cliente firma una autorización EIP-3009 que fija el destinatario y el monto; un facilitator que altere cualquiera de los dos produce una firma inválida y el contrato del token rechaza la transferencia. En upto, el witness de Permit2 fija el destinatario y la dirección del facilitator. El facilitator es un mensajero con un sobre sellado: puede entregarlo, demorarlo o tirarlo — no puede reescribir lo que hay dentro.

Lo que el facilitator sí posee es el acceso a la chain. Mantiene wallets de gas fondeadas en cada red que soporta, envía las transacciones, absorbe reorgs y fallas de RPC, y reporta de vuelta por HTTP plano. Toda la huella blockchain del seller colapsa en dos llamadas JSON.

La superficie del API: dos POST y un GET

El spec v2 define exactamente tres endpoints. Ambos POST reciben el mismo body: la versión del protocolo, el pago que envió el cliente y los requirements que anunció el servidor.

// POST /verify y POST /settle comparten este request
{
  "x402Version": 2,
  "paymentPayload": { /* lo que firmó el cliente */ },
  "paymentRequirements": { /* lo que exigió el servidor */ }
}

El paymentPayload es el objeto que el cliente transmitió en el header PAYMENT-SIGNATURE (JSON codificado en base64, según el transport HTTP v2, que renombró el X-PAYMENT de v1). Lleva x402Version, un campo accepted que hace eco del PaymentRequirements exacto que el cliente eligió del array accepts del servidor, y un payload específico del scheme — la firma EIP-3009, la transacción de Solana parcialmente firmada, el permit de Permit2. El primer trabajo del facilitator es comprobar que accepted y paymentRequirements coincidan. Una discrepancia significa que el cliente intenta pagar contra términos que el servidor nunca ofreció.

POST /verify — el pre-vuelo gratuito

La verificación es todo lo que puede comprobarse sin gastar gas: validez de firma, ventanas de tiempo, montos, binding del destinatario, estado de replay y lecturas de balance on-chain. La respuesta es deliberadamente mínima.

// válido
{ "isValid": true, "payer": "0x857b...6b66" }

// inválido
{
  "isValid": false,
  "invalidReason": "insufficient_funds",
  "payer": "0x857b...6b66"
}

Cuatro campos en total: isValid (requerido), invalidReason (omitido cuando es válido), payer (la dirección de wallet resuelta) y un extra opcional específico del scheme. El campo payer importa más de lo que parece: es el facilitator haciendo signature recovery por ti. El servidor sabe qué dirección está pagando sin parsear un solo byte del payload del scheme — útil para rate limiting, allowlists y mapeo de cuentas.

La propiedad crítica de /verify es que no tiene efectos secundarios y es barato. Un resource server lo llama antes de hacer cualquier trabajo: verify, luego servir, luego settle. Si la verificación falla, el request muere con un 402 fresco y nadie gastó nada.

POST /settle — donde el dinero realmente se mueve

El settlement es la mitad irreversible. El facilitator emite la transacción, espera la confirmación dentro del maxTimeoutSeconds del requirement y reporta el resultado.

{
  "success": true,
  "payer": "0x857b...6b66",
  "transaction": "0x1234...cdef",
  "network": "eip155:84532"
}

El schema de SettleResponse tiene dos campos requeridos además de success: transaction (el hash, o string vacío si falla) y network en formato CAIP-2. Dos campos opcionales cargan los schemes más nuevos. amount — "el monto real liquidado en unidades atómicas" — existe por upto: el techo autorizado y el monto liquidado divergen por diseño, y el servidor necesita el número real para su contabilidad. extensions transporta datos de extensiones del protocolo, el canal por el que viajan batch-settlement y la metadata de discovery. En caso de fallo, errorReason reemplaza al hash y el servidor decide si reintenta, re-verifica o anula el request.

El servidor reenvía este objeto al cliente codificado en base64 en el header PAYMENT-RESPONSE. Eso cierra el ciclo: el cliente ahora tiene un recibo atestado por el facilitator con el hash de transacción que puede confirmar on-chain por su cuenta.

GET /supported — discovery de capacidades

El endpoint menos discutido es el que hace viable un x402 multi-scheme y multi-chain. /supported devuelve tres cosas:

{
  "kinds": [
    { "x402Version": 2, "scheme": "exact", "network": "eip155:84532" }
  ],
  "extensions": [],
  "signers": {
    "eip155:*": ["0x1234...5678"],
    "solana:*": ["CKPK...WYp5"]
  }
}

El array kinds es el menú del facilitator: cada tripla (versión, scheme, red) que puede verificar y liquidar. Un resource server debería intersectar ese menú con sus propias preferencias antes de anunciar un array accepts a los clientes — ofrecer un tipo de pago que tu facilitator no puede liquidar es una caída autoinfligida.

El mapa signers — patrones CAIP-2 hacia direcciones públicas — es silenciosamente importante para la seguridad. En Solana, el scheme exact SVM exige que el cliente construya una transacción cuyo fee payer sea la llave del facilitator, nombrada en extra.feePayer. La lista signers es cómo cualquiera puede comprobar que la llave en la que confía como fee payer pertenece de verdad al facilitator, y no a un atacante que deslizó su propia dirección en una respuesta 402. Publicar los signers también permite a los sellers fijar identidades de facilitator en el tiempo.

La taxonomía de errores lleva namespace por scheme

El spec v2 enumera los valores que pueden aparecer en invalidReason y errorReason. Algunos son genéricos: insufficient_funds, invalid_scheme, unsupported_scheme, invalid_network, invalid_payload, invalid_payment_requirements, invalid_x402_version, invalid_transaction_state, y los comodines unexpected_verify_error y unexpected_settle_error.

El resto lleva namespace por scheme, en el patrón que vimos por primera vez en el deep dive de EIP-3009: invalid_exact_evm_payload_authorization_valid_after, invalid_exact_evm_payload_authorization_valid_before, invalid_exact_evm_payload_authorization_value_mismatch, invalid_exact_evm_payload_signature, invalid_exact_evm_payload_recipient_mismatch. Cada uno mapea a un invariante específico del scheme — ventana de tiempo, monto, firma, binding del destinatario. Para un operador, esta taxonomía es tu diccionario de alertas. Un pico de errores _signature significa tooling de cliente roto. Un pico de insufficient_funds significa que las wallets de los agentes compradores se vacían más rápido de lo que se recargan. Un pico de invalid_transaction_state apunta a intentos de replay o carreras entre settlements concurrentes.

Qué puede y qué no puede hacerte un facilitator

El modelo de confianza merece precisión, porque "non-custodial" se agita como si significara "trustless". No es así.

Lo que un facilitator no puede hacer: robar o redirigir fondos. La firma del cliente fija destinatario, monto (o techo de monto) y ventana de validez. Los contratos de token imponen esos bindings on-chain sin importar quién envíe la transacción.

Lo que un facilitator sí puede hacer: negarse a liquidar, liquidar tarde y verlo todo. La censura y la latencia son palancas reales — el facilitator controla el envío de transacciones, así que controla cuándo y si tus ingresos confirman. Y observa el stream completo de metadata: qué compradores le pagan a qué sellers, con qué frecuencia, por cuánto. Para una economía de agentes, eso es un grafo comercial completo.

Es el mismo argumento estructural que hicimos sobre el riesgo de centralización de x402 Bazaar: el protocolo es abierto, pero los cuellos de botella operativos se concentran. El facilitator es el mayor de todos.

El mercado de facilitators, julio 2026

La buena noticia es que el mercado dejó de ser un monocultivo. El directorio oficial de facilitators ya lista una docena de opciones en producción: el facilitator de CDP de Coinbase; Corbits y Dexter cubriendo EVM más Solana; Mogami en Base; PayAI multi-red; el facilitator propio de Polygon para Polygon mainnet y Amoy; Solvador abarcando EVM, Solana y NEAR; T54 en el XRP Ledger; y un facilitator de Stellar construido sobre el OpenZeppelin Relayer. El facilitator público de x402.org sigue siendo explícitamente un servicio de desarrollo y testnet, no un default de producción.

La oferta comercial de referencia es el facilitator de CDP: Base, Polygon, Arbitrum, World y Solana, liquidando tokens EIP-3009 como USDC y EURC de forma nativa y cualquier ERC-20 vía Permit2, con 1,000 transacciones al mes gratis y $0.001 por transacción después. A escala de micropagos ese fee no es decorativo: en una llamada de API de un centavo, una décima de centavo de fee de settlement es un take rate del 10%. En una llamada de un dólar es ruido. El pricing del facilitator determina en silencio el precio mínimo viable de un API machine-to-machine.

La ruta de self-host también maduró. x402-rs es una implementación open source en Rust del rol completo de facilitator que puedes correr en tu propia infraestructura; su instancia hosteada en facilitator.x402.rs expone una docena de testnets, de Base Sepolia y Polygon Amoy a Solana Devnet, como sandbox público gratuito. Entre hosted-con-fees y self-hosted-con-ops, la decisión es la clásica: por debajo de un volumen serio, alquila; por encima, o cuando el propio grafo de metadata es sensible, sé dueño.

Qué significa para LLM4Agents

LLM4Agents está del lado resource server de este API. Nuestro pipeline reserve → proxy → settle es estructuralmente el flujo del facilitator con una llamada de inferencia en el medio: verificar la autorización de pago, hacer el trabajo medido, liquidar por lo consumido. Eso convierte al facilitator en la única dependencia externa sin la cual nuestra ruta de ingresos x402 no funciona.

Lo que habilita: amplitud de redes sin operaciones de chain. Soportar settlement en Solana y Polygon junto a Base nos cuesta una entrada en un archivo de configuración, no tres infraestructuras RPC, porque el menú /supported del facilitator es la superficie de integración. El campo amount del SettleResponse es exactamente lo que nuestro billing medido con upto necesita para conciliar techos autorizados contra uso real.

Lo que amenaza: concentración y margen. Un único facilitator hosteado es un único punto de censura, un único esquema de fees aplicado a cada settlement que hacemos y un único observador de todo nuestro grafo comprador-vendedor. Y un success falso del facilitator — por bug o por compromiso — se convierte en ingresos incobrables en nuestros libros salvo que confirmemos los hashes de forma independiente.

Cómo mantenerse en la frontera

Pasos concretos, en orden. Primero, abstraer el facilitator detrás de una interfaz interna basada en el contrato de /supported, e integrar un segundo facilitator de producción con failover automático — la misma disciplina que aplicamos a las cadenas de fallback de modelos, una capa más abajo del stack. Segundo, agregar verificación async de settlement: muestrear respuestas de /settle y confirmar los hashes devueltos contra RPCs independientes, alertando ante divergencias. Tercero, levantar una instancia self-hosted de x402-rs contra testnets ahora, para que el playbook operativo exista antes de que la economía del volumen fuerce la migración. Cuarto, hacer polling de /supported a nuestros facilitators con cadencia fija y tratar cada nuevo kind (scheme, red) como trigger de producto — el soporte de upto y batch-settlement llegará facilitator por facilitator, y las plataformas que lo habiliten primero fijarán los precios en esos nichos. Quinto, cablear la taxonomía de errores a la observabilidad de billing como métricas de primera clase, por razón y por scheme.

El API del facilitator son tres endpoints y quizá dos páginas de spec. También es el lugar donde el protocolo abierto se encuentra con la realidad operativa. Lee el spec una vez; audita a tu facilitator para siempre.