Un 402, quince cadenas: dentro de los network bindings de x402

La spec de x402 que define qué significa "paga exactamente esta cantidad" tiene 519 palabras. Los quince documentos que explican cómo codificarla en una cadena concreta pasan de 31,000.

Esa proporción es la descripción más honesta que existe de x402. El protocolo se presenta como HTTP-native y agnóstico de cadena, y en la capa semántica eso es cierto. En la capa donde el dinero realmente se mueve, cada blockchain obliga a una respuesta distinta a las mismas cuatro preguntas, y esas respuestas no componen.

Clonamos x402-foundation/x402 el 2026-08-04 (HEAD db9dabd0) y leímos cada network binding de specs/schemes/exact/. Esto es lo que hay dentro, lo que cuesta soportarlo, y dónde el repositorio se contradice a sí mismo.

La spec compartida es media página

El documento raíz de exact dice que el scheme "transfiere una cantidad específica de fondos de un cliente a un resource server" y que el servidor debe conocer la cantidad de antemano. Sus casos de uso de ejemplo son pagar por ver un artículo, comprar créditos digitales, y "un LLM pagando por usar una tool". Ese es todo el contenido semántico.

Todo lo demás está delegado. Y la delegación es donde aparece la primera inconsistencia: el documento raíz cierra apuntando a seis archivos por red — SVM, Stellar, EVM, Sui, TON, Starknet — mientras que la carpeta de al lado contiene quince. Su apéndice "Critical Validation Requirements", lo más parecido a un resumen normativo de lo que un facilitator debe exigir, cubre cuatro de ellos.

Los otros once bindings llevan sus reglas en sus propios archivos, sin resumir. Quien escribe un facilitator leyendo de arriba hacia abajo obtiene el mapa de aproximadamente un cuarto del territorio.

Los cuatro invariantes que todo binding debe satisfacer

Si quitas el vocabulario específico de cada cadena, los quince documentos resuelven el mismo conjunto de problemas.

Primero, el pagador decide a dónde va el dinero. El facilitator transmite la transacción y debe ser estructuralmente incapaz de redirigirla. Segundo, el facilitator paga el gas y no puede quedar expuesto a que un cliente hostil lo drene. Tercero, exactitud: la cantidad transferida debe ser igual a requirements.amount, no aproximarse. Cuarto, protección de replay y expiración que no exija al facilitator guardar estado — porque el facilitator debe ser un servicio verify/settle sin estado, como cubrimos en el deep dive del API del facilitator.

En EVM existe un primitivo a nivel de token que resuelve los cuatro de una vez: EIP-3009 transferWithAuthorization. El pagador firma un mensaje tipado que nombra destinatario, monto, ventana de validez y nonce; el contrato del token lo verifica y mueve los fondos; cualquiera puede enviarlo y pagar el gas.

Fuera de EVM, ese primitivo casi nunca existe. Así que cada cadena recurre a lo que su máquina virtual ya le da, y los resultados se ordenan en cinco familias.

Familia uno: el contrato del token verifica una firma

Los análogos más cercanos a EIP-3009 son ports literales. El binding de Casper está construido sobre CEP-3009, descrito en la spec como "la adaptación de Casper de EIP-3009 para tokens CEP-18": un mensaje tipado EIP-712 que lleva destinatario, monto, ventana de validez y un nonce de 32 bytes, con el contrato del token recomputando el digest y exigiendo unicidad del nonce.

Starknet llega al mismo lugar por account abstraction en vez de por el token. El cliente firma una outside execution de SNIP-9 que autoriza exactamente una llamada transfer, codificada como typed data de SNIP-12, y el facilitator la dispara vía execute_from_outside_v2 sobre el propio account contract del cliente. La validez de la firma se delega al is_valid_signature de SNIP-6 de esa cuenta, así que multisig y cuentas respaldadas por hardware funcionan sin modificación. Los nonces de SNIP-9 son de un solo uso y se exigen on-chain, lo que significa que el facilitator no necesita ningún almacén de replay persistente.

Familia dos: una transacción con un slot de sponsor vacío

El patrón más común es una transacción parcialmente firmada. El cliente arma y firma todo, dejando un slot designado para quien pague el fee, y el facilitator lo llena en el settlement.

Solana lo hace con extra.feePayer, que desarmamos en el deep dive de exact SVM. Aptos usa sus fee payer transactions nativas, y la spec es explícita sobre por qué es seguro: "la firma del cliente cubre el payload de la transacción pero no la dirección del fee payer", así que el sponsor solo puede añadir. Hedera hace que el cliente ponga transactionId.accountId en la cuenta del facilitator y firme una TransferTransaction parcialmente firmada. Concordium hace lo mismo con un slot de firma de sponsor vacío, y luego espera la finalización de ConcordiumBFT, que la spec sitúa en unos diez segundos de finalidad determinista.

La carga de seguridad de esta familia cae sobre el precio del gas. Aptos lo formula como un MUST: verificar que gas_unit_price esté por debajo de un límite configurado, "para evitar que un cliente malicioso fije un precio de gas arbitrariamente alto que drene la cuenta del fee payer". Un slot de sponsor es una invitación abierta salvo que alguien acote el costo.

Familia tres: meta-transactions y relays

El binding de NEAR es el documento más riguroso de la carpeta. El cliente firma un SignedDelegateAction de NEP-366 que contiene exactamente una acción, que debe ser un FunctionCall a ft_transfer. La cuenta del relayer se elige desde configuración local del facilitator y nunca puede venir del input del cliente.

El detalle que vale la pena copiar es el mapeo de timeout. En vez de dejar maxTimeoutSeconds a interpretación, la spec fija estimatedBlockSeconds = 1 y exige que el facilitator rechace tanto una ventana expirada como una ventana más ancha que el presupuesto anunciado. También documenta que el RPC público de NEAR no tiene equivalente a eth_call o simulateTransaction para el camino del delegate, así que reemplaza la simulación con una lista de chequeos dirigidos de estado on-chain — que la cuenta exista, que la access key exista, que el nonce no esté consumido, que ft_balance_of alcance, que el destinatario esté registrado en storage NEP-145 — y exige que todos fallen en cerrado.

TON llega al mismo sitio por medio de un contrato de wallet. El cliente firma un mensaje de wallet W5 con el opcode internal_signed; el facilitator lo envuelve en un mensaje interno desde su propia wallet fondeada. La spec cuantifica el subsidio en aproximadamente 0.013 TON por transacción y afirma que no hay comisión de relay: "el facilitator absorbe los costos de gas como el costo de operar la red de pagos, de forma análoga a cómo los facilitators de EVM pagan gas por transferWithAuthorization".

Familia cuatro: firmar la autorización, no la transacción

Stellar parte la diferencia. El cliente firma authorization entries de Soroban en vez de una transacción, y el facilitator reconstruye y envía la transacción alrededor de ellas. El alcance es angosto por diseño: solo tokens Soroban compatibles con SEP-41, con los assets clásicos de Stellar excluidos explícitamente.

Los invariantes aparecen como restricciones estructurales. Exactamente una operación invokeHostFunction. Nombre de función transfer con exactamente tres argumentos, donde el argumento uno debe ser igual a payTo y el argumento dos debe ser igual a requirements.amount como i128. Las authorization entries deben usar solo sorobanCredentialsAddress y no pueden contener sub-invocaciones. Y la expiración es una fórmula, no una estimación: las entries no pueden exceder currentLedger + ceil(maxTimeoutSeconds / estimatedLedgerSeconds), con un fallback de cinco segundos.

Familia cinco: grupos atómicos y bloques firmados

Algorand no envía una transacción. Envía un paymentGroup — un array de transacciones base64 ejecutadas atómicamente — más un paymentIndex que apunta a la que efectivamente paga al resource server. Los grupos topan en 16 transacciones de primer nivel y los fees pueden agruparse, que es como la transacción de fee del facilitator viaja en el mismo grupo. Los otros slots pueden llevar swaps o movimientos de assets; el facilitator solo tiene que probar que la transacción indexada cumple los requirements.

Keeta envía un bloque firmado en ASN.1 DER codificado en base64 que contiene una operación SEND. El facilitator computa y firma un bloque de fee aparte, junta votos de los representantes de la red, y publica el vote staple combinado.

Las tres cadenas que rompen la promesa

Dos bindings no entregan lo que los agentes de verdad quieren, que es un pago que no requiera token de gas nativo.

Sui exige que el cliente arme y firme una transacción completa. La spec es directa sobre la consecuencia: el facilitator no tiene "ninguna capacidad de ajustar la transacción". El pago gasless solo es posible mediante un handshake interactivo con una gas station anunciada en extra.gasStation, donde el cliente manda una transacción parcial, recibe los campos de gas completados, y luego firma. El apéndice deposita su esperanza en una feature en desarrollo llamada "Address Balances", que eliminaría el costo de storage del objeto coin y con el tiempo podría habilitar autorizaciones al estilo EIP-3009.

XRPL es el caso duro. El ledger cobra el fee a la Account de la transacción, punto. La spec afirma que este scheme "no soporta fees de red patrocinados por el facilitator" y que soportarlos "requeriría un modelo de pago distinto, no solo un cambio de implementación del facilitator". Y luego vuelve la limitación legible por máquina: extra.areFeesSponsored MUST estar presente y MUST ser false.

XRPL además hereda un problema de secuenciación. El método por defecto sequence serializa la cuenta del pagador entre verify y settle — cualquier otra transacción que consuma el mismo número de secuencia invalida el pago permanentemente con tefPAST_SEQ, después de que el handler del recurso ya corrió. La alternativa, ticketSequence, permite pagos pendientes concurrentes pero necesita inventario de tickets y una reserva. La spec llama a la mitigación cooperativa, "no una reserva a nivel de protocolo".

Cardano es el tercer outlier, en otra dirección: su binding define tres asset transfer methods, uno de los cuales rutea los pagos por el protocolo Masumi para mecánica de reembolsos y logging de decisiones, y otro que paga a scripts con parámetros aplicados al construir la transacción. Es el único binding donde "pagarle al merchant" no es la única forma posible.

Dónde vive la abstracción en el código

El repositorio resuelve quince cadenas en tres interfaces de TypeScript. Un network binding es un paquete que las implementa.

// typescript/packages/core/src/types/mechanisms.ts

export interface SchemeNetworkFacilitator {
  readonly scheme: string;

  // "eip155:*" | "solana:*" — agrupa signers por familia de cadena
  readonly caipFamily: string;

  // SVM devuelve { feePayer }, EVM devuelve undefined
  getExtra(network: Network): Record<string, unknown> | undefined;

  // array, para load balancing y rotación de llaves
  getSigners(network: string): string[];

  verify(payload, requirements, context?): Promise<VerifyResponse>;
  settle(payload, requirements, context?): Promise<SettleResponse>;
}

El lado del cliente es un solo método, createPaymentPayload. El lado del servidor convierte un string de precio en el asset y el monto de la cadena. Ese es todo el contrato del plug-in, y por eso getExtra importa más de lo que parece: es el canal por el que una cadena le dice al comprador que existe un fee payer.

Qué salió de la auditoría

Leer la carpeta contra el código produjo cinco discrepancias, todas verificadas el 2026-08-04.

Hallazgo 2. El archivo que una cadena nueva copia para arrancar su binding, specs/scheme_impl_template.md, todavía documenta el header X-Payment. Eso es v1. Todo binding escrito en 2026 es solo v2 y usa PAYMENT-SIGNATURE. La puerta de entrada para nuevos contribuidores apunta al transporte deprecado.

Hallazgo 3. Los bindings dicen usar identificadores de red CAIP-2, y la mayoría se lo gana. Tres no: near:mainnet, keeta:* y cardano:mainnet usan namespaces sin directorio en el registro de namespaces de ChainAgnostic, mientras que algorand, aptos, casper, ccd, hedera, solana, starknet, stellar, sui, tvm, xrpl y eip155 sí resuelven. El código de routing que trate el string de red como identificador registrado se equivocará en tres cadenas.

Hallazgo 4. La carrera de duplicate settlement está documentada exactamente en dos lugares — la spec de SVM y la de NEAR, que la referencia explícitamente y adapta la mitigación a max_block_height. La misma carrera existe en toda cadena donde /settle pueda llamarse dos veces antes de que el primer envío aterrice. Trece bindings no la mencionan.

Hallazgo 5. La expansión es reciente y se acelera. El binding de EVM data del 2025-02-21, en un commit titulado "Start refactor", unos tres meses antes del lanzamiento público de x402. Sui siguió en junio de 2025, Solana en agosto de 2025. Los otros doce aterrizaron todos en 2026 — Aptos, Algorand y Stellar en enero, Hedera en febrero, Keeta y Cardano en abril, TON y NEAR en mayo, Concordium a fines de mayo, y luego XRPL, Casper y Starknet en tres semanas de julio.

Qué significa para LLM4Agents

Nosotros vendemos inferencia. Los compradores llegan con la wallet que ya tienen, y el network binding decide cuánto nos cuesta aceptarla.

La primera consecuencia es que "gasless" es una propiedad por cadena, no del protocolo. En EVM, Solana, Stellar, TON, NEAR, Aptos, Hedera, Concordium, Algorand, Keeta, Casper y Starknet, el binding prevé que el facilitator pague el fee, así que un agente puede pagar con saldo en stablecoin y sin token nativo. En XRPL no puede, por construcción. En Sui solo puede con un round trip extra a una gas station. Anunciar una única promesa de "pago por llamada, sin gas" para todas sería falso, y el campo que te lo dice es extra.areFeesSponsored o la presencia de extra.feePayer — ambos llegan en la respuesta /supported del facilitator antes de que aparezca ningún comprador.

La segunda consecuencia cae sobre el billing. Nuestro camino de reserve-then-settle, descrito en el post de internals de facturación, asume que la verificación da una lectura confiable de si el settlement va a funcionar. Esa suposición se sostiene de forma desigual. NEAR exige esperar el receipt interno de ft_transfer porque la transacción externa del relayer puede tener éxito sin que la transferencia se haya ejecutado. XRPL puede invalidar un pago ya verificado entre verify y settle con solo que el pagador envíe otra transacción. Concordium tarda unos diez segundos en finalizar. Un gateway que libera tokens solo con la verificación queda expuesto de forma distinta en cada rail.

La tercera es más angosta y más accionable: la carrera de duplicate settlement es real y está mayormente sin documentar, así que la defensa tiene que ser nuestra. Llevar un registro de idempotencia con clave en el hash de los bytes del payload — el patrón que recomiendan tanto la spec de SVM como la de NEAR — es agnóstico de cadena y barato. Va en el gateway, no en un adaptador por cadena.

Y la cuarta es un problema de lenguaje antes que de cadena. Nuestro stack no es TypeScript en todas partes. Cualquier binding fuera de EVM y SVM hoy significa o correr los paquetes de mechanism de TypeScript o escribir el camino de verificación nosotros mismos contra la spec, que es exactamente el trabajo que el scheme upto ya nos enseñó a no subestimar.

Cómo mantenerse en la frontera

Pasos concretos, en el orden en que rinden.

Publicar una matriz de soporte, no una lista. La unidad es (scheme, network, modelo de fee payer), y el comprador necesita ver el tercer elemento. Una página que diga "x402 aceptado en Base, Polygon, Solana y Stellar; gas patrocinado en las cuatro" es mejor superficie de producto que una tira de logos de cadenas, y nos obliga a ser honestos cuando un rail como XRPL exige que el agente tenga token nativo.

Secuenciar los rails por madurez de sponsorship, no por market cap. EVM y SVM ya cargan peso. Stellar es el siguiente: el binding es estricto, el ecosistema de facilitators existe, y el modelo de auth entries da la garantía estructural más fuerte de que un sponsor no puede redirigir fondos. TON y NEAR siguen, porque ambos tienen caminos nativos de meta-transaction y specs que ya expresan las obligaciones del facilitator como MUSTs. Sui y XRPL deberían quedar diferidos explícitamente y con razón documentada, no ambiguos.

Hacer el gateway idempotente a nivel de payload. Un registro con clave en el hash de los bytes del payload recibido, insertado antes de intentar el settlement, desalojado con el primitivo de expiración de la propia cadena — vida del blockhash en Solana, max_block_height en NEAR, ventana de ledger en Stellar. Eso cierra la carrera en los quince rails con una sola pieza de código.

Leer /supported en el arranque y negarse a anunciar lo que no podemos liquidar. El facilitator ya devuelve kinds y direcciones de signers por red. Tratar esa respuesta como fuente de verdad para nuestra propia página de precios elimina una clase entera de mentiras hacia el comprador.

Contribuir los arreglos baratos aguas arriba. El template que apunta a X-Payment y el documento raíz de exact que lista seis de quince bindings son ambos pull requests de un párrafo. La reputación en un repositorio de fundación se gana antes de necesitarla, y la vamos a necesitar cuando propongamos extensiones del lado del gateway — el mismo argumento que hicimos sobre publicar en el MCP Registry.

Vigilar dos cosas concretas. La feature Address Balances de Sui, que su propio binding dice que podría habilitar autorizaciones al estilo EIP-3009 y eliminar la gas station interactiva. Y si el modelo SNIP-9 de Starknet — autorización validada por el propio account contract del comprador, nonces de un solo uso exigidos on-chain, cero estado en el facilitator — se convierte en la plantilla que copian las demás cadenas con account abstraction. Si lo hace, el trabajo del facilitator se achica y la superficie de confianza mejora, que es la dirección en la que todo este protocolo debería moverse.