x402 en Solana: cómo liquida el scheme exact SVM sin EIP-3009

En cadenas EVM, x402 liquida con una firma EIP-3009: el agente firma un mensaje tipado y cualquiera puede llevarlo on-chain. Solana no tiene transferWithAuthorization. Así que el scheme exact SVM hace algo estructuralmente distinto: el agente firma una transacción real a la que le falta una firma, y el facilitator llena ese hueco.

Ya cubrimos el protocolo x402 en sí y el primitivo EIP-3009 que tiene debajo en cadenas EVM con detalle. Pero llm4agents liquida en más de una cadena, y la pregunta de cómo el mismo flujo HTTP 402 aterriza en Solana — un runtime sin EIP-712, sin ERC-20 y con un modelo de transacciones completamente distinto — merece el mismo tratamiento. La respuesta vive en un archivo de spec: scheme_exact_svm.md en el repositorio coinbase/x402.

La versión corta: en Solana, el payload de pago no es un objeto de autorización. Es una transacción de Solana completamente construida, parcialmente firmada, codificada en base64, esperando exactamente una firma más — la del facilitator, como fee payer. Esa única decisión de diseño arrastra todo lo demás en la spec: el layout estricto de instrucciones, las reglas de seguridad del fee payer, el nonce basado en memo y la ventana de replay medida en vida del blockhash en lugar de timestamps validBefore.

Un protocolo, dos primitivos de settlement

x402 v2 es deliberadamente agnóstico de cadena en la capa superior. Las redes se identifican con identificadores CAIP-2 — eip155:8453 para Base, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp para Solana mainnet, solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1 para devnet. La respuesta PaymentRequired, los endpoints /verify y /settle del facilitator y la forma del SettlementResponse son idénticos entre cadenas. Lo que cambia por cadena es la implementación del scheme: cómo el cliente prueba que autoriza el pago, y cómo el facilitator convierte esa prueba en una transferencia on-chain.

En EVM, el scheme exact envuelve EIP-3009: el cliente firma un mensaje EIP-712 off-chain (transferWithAuthorization) con un nonce aleatorio de 32 bytes y una ventana de validez, y el facilitator lo envía dentro de su propia transacción, pagando el gas. El cliente nunca construye una transacción. La firma es el pago.

En Solana ese primitivo no existe. Los tokens SPL no tienen una autorización de pull-payment basada en firma comparable a EIP-3009. Lo que Solana sí tiene — nativamente, desde el génesis — es un modelo de transacciones donde el fee payer es simplemente el primer firmante requerido, distinto de las cuentas que se debitan. Cualquier transacción puede nombrar a un tercero como fee payer, y la transacción solo es válida cuando todos los firmantes requeridos, fee payer incluido, han firmado. El scheme exact SVM se construye directamente sobre esto.

El flujo: una firma que falta

La spec define un flujo dirigido por el cliente. Condensado a sus pasos esenciales:

El cliente solicita un recurso. El servidor responde con PaymentRequired, y dentro del campo extra de los requirements incluye algo que los requirements EVM nunca llevan: feePayer, la clave pública de la cuenta que patrocinará la fee de la transacción — típicamente el facilitator.

{
  "scheme": "exact",
  "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "amount": "1000",
  "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "payTo": "2wKupLR9q6wXYppw8Gr2NvWxKBUqm4PPJKkQfoxHDBg4",
  "maxTimeoutSeconds": 60,
  "extra": {
    "feePayer": "EwWqGE4ZFKLofuestmU4LDdK7XM1N4ALgdZccwYugwGd",
    "memo": "pi_3abc123def456"  // opcional, definido por el seller, máx 256 bytes
  }
}

El asset es el mint del token — aquí, USDC de mainnet (EPjFW...Dt1v). El amount va en unidades atómicas, seis decimales para USDC, así que "1000" es $0.001. Hasta aquí replica la forma EVM. La divergencia empieza con lo que el cliente hace después.

El cliente construye una transacción de Solana real: un TransferChecked del token SPL desde su propia token account hacia la del seller, más instrucciones de compute budget, con extra.feePayer declarado como fee payer de la transacción. Firma con su propia clave. El resultado es una transacción parcialmente firmada — válida en todo excepto que el slot de firma del fee payer está vacío. El cliente la codifica en base64 y la envía como payload de pago:

{
  "x402Version": 2,
  "accepted": { /* los PaymentRequirements que está cumpliendo */ },
  "payload": {
    "transaction": "AAAAAAAAAAAAA...AAAAAAAAAAAAA="  // base64, parcialmente firmada
  }
}

El resource server reenvía esto al endpoint /verify del facilitator. El facilitator decodifica la transacción, la inspecciona instrucción por instrucción contra una checklist estricta (siguiente sección) y devuelve {"isValid": true} o un fallo tipado. En /settle, el facilitator agrega su propia firma como fee payer, envía la transacción ya completamente firmada a Solana y devuelve un SettlementResponse con success: true, la firma de transacción en base58, la red y la dirección del fee payer. El servidor libera el recurso.

Nota lo que no pasó: el facilitator nunca construyó una transacción propia. En EVM, el facilitator envuelve la autorización del cliente en una transacción del facilitator. En Solana, el cliente fue el autor de toda la transacción y el facilitator apenas la co-firmó. La pregunta de confianza se invierte — y por eso las reglas de verificación son tan estrictas.

La checklist de verificación del facilitator

Co-firmar una transacción arbitraria como fee payer es peligroso. La transacción que el cliente armó podría, en principio, hacer cualquier cosa: drenar una cuenta que el facilitator controla, invocar un programa malicioso o quemar el SOL del facilitator en compute. La respuesta de la spec es hacer que la forma de la transacción sea innegociable. Antes de firmar, un facilitator MUST verificar, entre otras cosas:

Layout de instrucciones. La transacción debe contener entre tres y seis instrucciones, en orden: un Compute Budget set compute unit limit, un Compute Budget set compute unit price, un TransferChecked del programa SPL Token o Token-2022, y luego opcionalmente hasta dos instrucciones de aserción de Lighthouse y/o una instrucción SPL Memo. Solo esos programas están permitidos — Lighthouse (L2TEx...A3S95) y Memo (MemoS...fcHr) son los únicos extras opcionales. Cualquier otra cosa en la lista de instrucciones es un rechazo.

Aislamiento del fee payer. La dirección del fee payer no debe aparecer en las cuentas de ninguna instrucción. No debe ser el authority del TransferChecked, y no debe ser el source de los fondos. La clave del facilitator paga la fee y no hace nada más. Esta es la regla que hace seguro co-firmar: una transacción que toca las cuentas del fee payer en cualquier capacidad nunca recibe la segunda firma.

Límites de compute. Las dos instrucciones de compute budget deben ser llamadas genuinas al programa ComputeBudget con los discriminadores correctos, y el compute unit price debe estar acotado — la implementación de referencia lo limita a 5 lamports por compute unit. Sin esto, un cliente hostil podría fijar una priority fee enorme y drenar al sponsor solo con fees.

Destino y monto. El destino del TransferChecked debe ser igual a la Associated Token Account derivada de (owner = payTo, mint = asset) bajo el token program seleccionado — no cualquier cuenta que el cliente diga que pertenece al seller. El monto de la transferencia debe ser exactamente igual a PaymentRequirements.amount. La token account de origen debe existir; la ATA de destino debe existir salvo que la transacción incluya una instrucción de creación de ATA para ella.

Protección de replay sin validAfter ni validBefore

EIP-3009 lleva su protección de replay dentro del mensaje firmado: un nonce aleatorio que el contrato del token marca como usado, más timestamps validAfter/validBefore. Una transacción de Solana no necesita nada de eso agregado, porque el runtime ya lo provee: toda transacción embebe un blockhash reciente, y Solana rechaza cualquier transacción cuyo blockhash haya expirado — una ventana de aproximadamente 60 a 90 segundos — así como cualquier transacción ya procesada. La transacción parcialmente firmada es, por lo tanto, auto-expirante y auto-deduplicante a nivel de cadena.

La spec aun así agrega dos capas encima. Primero, la instrucción Memo funciona además como identificador a nivel de aplicación: cuando el seller define extra.memo (hasta 256 bytes UTF-8 — piensa en IDs de orden o factura como pi_3abc123def456), el cliente MUST incluir exactamente una instrucción Memo con ese string exacto, y el facilitator MUST verificarlo. Cuando no hay memo del seller, el cliente MUST incluir en el Memo un nonce aleatorio de al menos 16 bytes, codificado en hex — garantizando que dos pagos por lo demás idénticos produzcan transacciones distintas.

Segundo, el duplicate settlement. Entre el envío y la confirmación hay una ventana en la que el mismo payload podría liquidarse dos veces por un facilitator ingenuo, produciendo dos respuestas de éxito para un solo pago. La spec recomienda un cache in-process con clave en el string base64 de la transacción: rechazar un settlement cuya clave ya está en cache con un error duplicate_settlement, y desalojar entradas después de 120 segundos — holgadamente por encima de la vida del blockhash, tras la cual la transacción ya no puede aterrizar on-chain de ninguna manera. Sin base de datos; la propia cadena es la capa durable de dedup.

Trade-offs frente a la ruta EVM

Ningún modelo es estrictamente mejor; cortan el problema de formas distintas.

La autorización EVM/EIP-3009 es independiente del transporte y de vida larga: un agente puede firmarla offline, entregarla a cualquier parte y fijar una ventana de validez de horas. Esa flexibilidad es también su superficie de riesgo — cubrimos la trampa de front-running que obliga a usar receiveWithAuthorization en el deep dive de EIP-3009. La transacción SVM es lo opuesto: atada a un fee payer específico elegido por el seller, muerta en cerca de un minuto, e imposible de front-runear hacia otro contexto porque la transacción entera — cuentas, montos, programas — es lo que el cliente firmó. No existe un objeto de autorización separado que se pueda usar mal.

Los costos corren en la dirección contraria también. La ventana ajustada del blockhash implica que un payload de pago SVM no puede pre-firmarse con mucha anticipación ni encolarse para liquidar más tarde — la clave del agente debe estar online en el momento del pago. El seller debe publicar un feePayer antes de que el cliente pueda siquiera construir la transacción, acoplando la respuesta 402 a un facilitator específico de una forma que el flujo EVM evita. Y el facilitator carga con una verificación más pesada: parsear y validar estructura cruda de transacción en lugar de chequear una firma tipada contra parámetros conocidos. El layout rígido de tres a seis instrucciones de la spec es lo que mantiene esa carga manejable.

Lo que Solana compra a cambio es finalidad rápida y barata — la propia guía de x402 de Solana vende la cadena con settlement casi instantáneo a fees lo bastante bajas para micropagos reales — y soporte nativo de Token-2022, ya que TransferChecked existe en ambos token programs. Para el patrón walk-up de pago por llamada que mapeamos en el árbol de decisión Bearer vs x402, donde un agente descubre un recurso, paga una vez y sigue, una vida de payload de sesenta segundos no es una limitación. Es la forma natural de la interacción.

Estado del ecosistema, julio 2026

El tooling está al día. Coinbase publica @x402/svm, el paquete Apache-2.0 del mecanismo SVM para x402 — su último release, 2.19.0, salió el 17 de julio de 2026, tres días antes de este post. El portal de desarrolladores de Solana mantiene una guía first-party de inicio que cubre tanto integraciones con SDK (el @faremeter/payment-solana de Faremeter) como una implementación nativa sin dependencias, y lista facilitators activos en Solana incluyendo PayAI — que por ahora cubre él mismo las fees de transacción — y Corbits. El USDC de devnet (4zMMC...ncDU) permite probar el flujo completo sin fondos de mainnet.

También vale ubicar esto en el stack de settlement que venimos mapeando. El scheme exact SVM es cómo el valor aterriza en Solana; CCTP V2 es cómo el USDC se mueve entre Solana y cadenas EVM cuando el balance de un agente vive en una cadena y su contraparte liquida en otra. x402 le da a los agentes un solo protocolo de pago; las redes CAIP-2 y los schemes por cadena le dan múltiples rieles de settlement debajo.

Qué significa para LLM4Agents

llm4agents anuncia Solana como cadena de billing de primera clase junto a las redes EVM, y esta spec es la pieza que hace concreta esa promesa para la ruta walk-up de x402. El settlement EVM del gateway viaja sobre EIP-3009; una ruta de settlement en Solana viaja sobre el scheme exact SVM, y las dos exponen superficies idénticas al agente — misma forma de respuesta 402, mismo contrato /verify y /settle del facilitator, mismo SettlementResponse. Un agente cuya tesorería tiene USDC SPL puede pagar por inferencia igual que un agente en Base, y la diferencia queda enteramente debajo de la capa de scheme.

La checklist de verificación nos importa en ambas direcciones. Como seller, la plataforma solo debería confiar en facilitators que demuestren que aplican la lista completa de MUST — un facilitator laxo que co-firma transacciones malformadas es una disputa de reembolso en espera. Si la plataforma algún día corre su propio facilitator para settlement en Solana, la checklist es la spec de implementación: layout de instrucciones, aislamiento del fee payer, límites de compute price, derivación de ATA, monto exacto. Y el campo extra.memo mapea limpio sobre nuestros internals de billing — un memo definido por el seller con el ID de reserva ataría cada transferencia on-chain a un request medido específico en el pipeline reserve → proxy → settle, dándole a la reconciliación una clave de join nativa de la cadena.

La vida corta del payload es la única restricción operativa a diseñar. Una ventana de sesenta segundos entre construir el pago y liquidarlo es generosa para una llamada de API, pero implica que los pagos del lado Solana no pueden batchearse, encolarse ni pre-autorizarse como sí pueden las autorizaciones EIP-3009. Para billing por request está bien. Para cualquier cosa parecida a un presupuesto de gasto delegado por adelantado, la respuesta en Solana no es este scheme — es delegación estilo session keys en la capa de wallet, la misma conclusión a la que llegamos para EVM en el post de account abstraction.

Cómo mantenerse en la frontera

Pasos concretos, en orden. Primero, levantar el scheme exact SVM end-to-end en devnet: @x402/svm del lado cliente, USDC de devnet, un facilitator de la lista de la guía de Solana, y verificar el loop completo 402 → transacción parcialmente firmada → settle contra un endpoint de staging del gateway. El paquete se versiona en lockstep con el resto del SDK de x402, así que esto también ejercita las superficies CAIP-2 de v2 que ya soportamos en EVM.

Segundo, adoptar extra.memo en los payment requirements de Solana desde el día uno, con el ID de reserva interno. No cuesta nada, la spec ya obliga a los clientes a repetirlo y a los facilitators a verificarlo, y convierte el ledger de Solana en un registro auto-auditable de cada request liquidado.

Tercero, incorporar due diligence de facilitators a la integración: antes de confiar en cualquier facilitator de terceros en Solana, probarlo con payloads deliberadamente malformados — instrucciones extra, un fee payer insertado como authority de la transferencia, un compute unit price inflado, un destino que no es la ATA del payTo — y exigir rechazos en todos. La lista de MUST solo es una garantía si el facilitator de verdad la implementa.

Cuarto, seguir la evolución de schemes en el repo coinbase/x402 ahora que la x402 Foundation es steward del protocolo. El scheme exact cubre llamadas de precio fijo; schemes propuestos como upto cubrirían uso medido — que es exactamente la forma del billing de LLM por token. La cadena que primero publique un scheme medido usable se convierte en el riel de settlement más interesante para un gateway que factura por token, y el modelo de transacciones de SVM, donde el payload es una transacción real con expiración real a nivel de cadena, hará que ese scheme se vea distinto en Solana que en EVM. Llegar temprano a esa diferencia es la ventaja.