Payment Channels de Solana: los agentes IA ya pagan una vez y llaman un millón de veces — y el lado vendedor sigue siendo la mitad que falta

Qué lanzó Solana el 3 de septiembre — y qué es exactamente un payment channel

La Solana Foundation anunció los Payment Channels el 3 de septiembre de 2026 en un post de Rishin Sharma, su responsable de crecimiento en IA, bajo el titular "1 millón de pagos por segundo". La frase que merece la pena guardar es otra: "Cada llamada que hace un agente necesita una aprobación firmada y una liquidación … se complica cuando los agentes hacen cientos de pequeñas llamadas de pago en bucle." Ese es el problema que resuelven. No la velocidad por sí misma, sino el coste de pagar por llamada cuando las llamadas llegan en ráfagas.

Un payment channel es una idea vieja con traje nuevo. La mecánica, según la descripción de la propia Foundation y su documentación, tiene cuatro pasos:

1. Abrir. El comprador deposita un tope — digamos 20 USDC — en una cuenta de escrow on-chain controlada por un programa, no por el vendedor. La documentación es explícita: los fondos "los custodia un programa de canal on-chain, no el servidor", y "el comprador siempre puede recuperar el remanente no gastado".
2. Medir. Cada llamada a la API se autoriza con un mensaje firmado — un vale con un importe acumulado — en lugar de una transacción de blockchain. Sin fee, sin bloque, sin espera.
3. Liquidar. El vendedor envía una única transacción on-chain con el último vale. El programa comprueba que el importe acumulado supera lo ya liquidado y no excede el depósito, y lo registra.
4. Distribuir. Los fondos van a los destinatarios y lo no consumido vuelve a la wallet del comprador.

Encima hay dos modos. En el modo batch de x402, muchas entregas se liquidan juntas, y el esquema upto cubre una única llamada medida cuyo coste no se conoce hasta que termina. En el modo sesión de MPP, el comprador abre un canal, encadena muchas entregas medidas bajo un vale acumulado y liquida una vez cuando la sesión se cierra por inactividad. El método de sesión tiene su propio borrador de especificación, "Solana Session Intent for HTTP Payment Authentication", publicado el 9 de septiembre de 2026 por ingenieros de la Solana Foundation y Moonsong Labs. El programa, un kit llamado pay-kit y una plantilla de benchmark están en GitHub como código abierto.

Eso es todo. Es la cuenta abierta de un bar, para máquinas: dejas dinero, consumes, pagas una vez al salir. La novedad no es la cuenta abierta. Es que los dos estándares de pago para agentes — x402 y MPP — tienen ahora una forma común y no-custodial de llevarla en Solana.

El benchmark, leído con cuidado

La cifra que todos citaron es un millón de pagos por segundo. Esto es lo que hay detrás. La Foundation pasó 100.000 wallets únicas por un solo proxy de payment channels y midió más de 1.000.000 de pagos por segundo, que extrapoló a "más de 80.000 millones de pagos en 24 horas". Su documentación informa de un ciclo de liquidación de unos 203 segundos para los 100.000 canales y un coste de 0,0078 $ por millón de pagos; la cifra tan repetida de 0,000000000776 $ por pago es simplemente esa división.

Tres matices, ninguno ocultado por la Foundation. Primero, no se reveló el hardware, así que el rendimiento describe un proxy y un programa bajo condiciones elegidas, no la mainnet. Segundo, los pagos de la prueba eran vales off-chain; la cadena solo vio las transacciones de liquidación, que es justamente la idea del diseño y también la razón por la que no debería compararse con los 65.000 TPS de pico de Visa. Tercero, y más importante: capacidad no es demanda. El análisis de Forkast del 5 de septiembre lo dijo sin rodeos: la cifra es "una prueba de concepto, no una realidad de mercado". El mismo artículo citaba a Artemis Analytics estimando que aproximadamente la mitad de las transacciones x402 en Solana son artificiales — auto-operaciones o wash trading — sobre un acumulado de 35 millones de transacciones y unos 10 millones de dólares de volumen en la cadena, con un volumen diario real cercano a 28.000 $ en marzo.

Nada de eso resta importancia al lanzamiento. Lo deja en lo que es: infraestructura entregada antes que la carga. Vimos el mismo patrón hace una semana cuando Solana reconstruyó su formato de transacción: un raíl que se actualiza en público, con calendario y recibos publicados. Los Payment Channels pertenecen a esa tanda. La pregunta para un negocio no es si el millón por segundo es real. Es si alguna vez necesitarás mil por segundo, y qué deberías hacer mientras tanto.

Alibaba Cloud es la pista: el primer socio es un vendedor

Cada hito previo de pagos agénticos del que hemos escrito estaba del lado comprador: AWS dio una wallet a los agentes, Cloudflare les dio wallets e identidades, Binance y MoonPay dieron a los consumidores un agente capaz de pagar. El lado vendedor — la API que realmente devuelve un 402 y cobra — ha sido escaso: desarrolladores independientes y un puñado de proveedores de datos.

Los Payment Channels se lanzaron con Alibaba Cloud como primer socio en producción, y la alianza tiene forma de vendedor: sus endpoints de API de inferencia se podían pagar por canal desde el primer día. Un agente aprueba un límite de gasto una vez y después puede llamar a esos modelos repetidamente sin abrir cuenta, sin guardar una API key y sin aprobar cada petición. La inferencia es la primera carga de trabajo perfecta para un canal: se factura por token, el precio de una llamada no se conoce hasta que termina, y una sola tarea de un agente puede abrirse en cientos de llamadas en segundos. Es exactamente el bucle que describía la Foundation.

Es el primer hiperescalador que pone endpoints de pago, y no solo wallets, delante de agentes en una cadena pública. Responde a la objeción de que "nadie serio vende a agentes". Alguien serio ya lo hace. Y fija la conducta de referencia: los agentes que aprendan a comprar inferencia así esperarán que cualquier otra API sea alcanzable igual: un precio en la respuesta, una stablecoin, sin registro.

Los canales resuelven el bucle, no la llamada: quién necesita uno de verdad

Conviene ser preciso sobre qué elimina un canal. Con x402 por llamada, cada petición de pago lleva una autorización firmada que un facilitator verifica y liquida on-chain. En Base cuesta una fracción de centavo y tarda unos dos segundos; en Solana, menos de medio segundo. Para un agente que hace diez llamadas de pago en una sesión, ese sobrecoste es invisible. Para un agente que hace quinientas llamadas medidas en diez segundos — un bucle de inferencia, un enriquecimiento fila a fila, un feed en streaming — es el coste dominante y la latencia dominante. Ese es el caso para el que se construyeron los canales.

El mapa honesto de quién necesita qué queda así:

• Servicios medidos por uso con bucles a ráfagas — inferencia por token, cómputo por segundo, datos de mercado o telemetría en streaming — se benefician de los canales. El esquema upto o un vale de sesión permiten descubrir el precio después de la llamada.
• Servicios con precio por llamada — una consulta, una conversión, el parseo de un documento, una búsqueda, un informe — ya están bien servidos por x402 por llamada. Un precio fijo, una autorización, una liquidación.
• Todos los que aún no venden a agentes — es decir, la mayor parte de la economía de APIs — tienen un problema previo: no existe una URL de pago que un agente pueda encontrar.

Ese tercer grupo es con diferencia el más grande, y los datos lo confirman. La primera auditoría completa de los pagos x402 de 2026, publicada el 6 de septiembre por Bitquery, encontró que la mayor parte del dinero era un puente y que el vendedor mediano había ganado unos 2,50 $. Los vendedores que se quedaron eran los que tenían un endpoint real, un precio sensato y un motivo para que el agente volviera. A ninguno lo limitaba el rendimiento de liquidación. Los limitaba ser localizables y cobrables.

Qué tiene que operar un vendedor para aceptar pagos por canal

Si lees la documentación y el borrador de la spec con ojos de vendedor, el trabajo se hace visible. Para cobrar por canal necesitas:

• Desplegar o apuntar al programa de canal on-chain y publicar su dirección, un blockhash y un slot recientes, un periodo de gracia y repartos opcionales de distribución en los detalles de método de tu respuesta 402.
• Correr un verificador que compruebe la firma y el importe acumulado de cada vale entrante contra el canal abierto antes de servir la petición.
• Medir con honestidad: en modo upto el operador firma el importe real tras la llamada, así que tu medición forma parte del modelo de confianza.
• Enviar liquidaciones con la instrucción settle, cerrar de forma cooperativa con settleAndSeal y ejecutar distribute; el borrador además espera que el servidor actúe como rentPayer, patrocinando las fees para que el comprador solo necesite stablecoin.
• Gestionar los casos límite: el tiempo de cierre por inactividad, un comprador que deja de responder a mitad de sesión, un vale que llega después de liquidar.

Todo esto es código abierto y está bien documentado, y para un equipo que ya vende inferencia a escala es una semana razonable. Para una empresa de APIs de cinco personas es un proyecto, contra una spec publicada el 9 de septiembre que caduca como borrador en marzo de 2027. Es la misma forma de todos los lanzamientos de pagos agénticos de este año: el protocolo está terminado, los SDK existen, y la pieza que falta es un vendedor con tiempo para cablearlo.

Cómo encaja Payzum: el lado vendedor sin código, disponible hoy

Payzum no opera payment channels de Solana. Lo que sí opera es la parte que casi todo vendedor de APIs no tiene: una URL x402 de pago delante de un endpoint que ya existe, sin código y sin protocolo que implementar. Configuras una ruta, la URL HTTPS de tu endpoint actual, un precio por llamada en USDC y la dirección que debe recibir el dinero. Payzum publica la URL x402, devuelve el 402 con tu precio, verifica el pago firmado del agente a través de un facilitator externo — hoy el de Coinbase — y hace de proxy reenviando la petición pagada a tu origen con tu propia API key. Tu servicio sigue respondiendo peticiones normales exactamente igual que antes.

El activo de liquidación es USDC en Base, y se liquida de forma no-custodial a la dirección que configures. Payzum es el middleware, no el facilitator, y nunca retiene los fondos. También puedes marcar un endpoint como descubrible para que aparezca en el catálogo y, a través del facilitator de Coinbase, en el x402 Bazaar, donde los constructores de agentes buscan servicios. El coste está pensado para la realidad que describe la auditoría — la mayoría empieza pequeño: una franquicia gratuita de unas mil llamadas al mes y después una tarifa fija por llamada más gas .

Dos cosas que conviene dejar claras. Primera: esto es x402 por llamada, el esquema exacto, la herramienta adecuada para servicios con precio por llamada, que son el grueso del mercado, y suficiente para ser alcanzable por cualquier stack de agentes que hable x402: AWS AgentCore, Cloudflare Wallets, Coinbase for Agents, la Agentic Wallet de Binance. Segunda: si tu carga es un caso de canal genuino — inferencia por token, datos en streaming — Payzum hoy te permite cobrar por llamada mientras el tooling de canales madura, y nuestra hoja de ruta sigue a los estándares, no al revés. En la aceptación ordinaria de stablecoins, Solana es una de las nueve cadenas en las que Payzum liquida, con confirmaciones de unos 0,4 segundos, así que una base de clientes nativa de Solana no es un problema.

Cómo funciona, paso a paso

1. Crea el mapeo. En el panel de Payzum, añade una ruta, la URL HTTPS de tu endpoint actual, un precio por llamada en USDC y la dirección de Base que recibe los pagos. Opcionalmente, márcalo como descubrible.
2. Publica la URL x402. Payzum te devuelve una dirección para la versión de pago de tu endpoint. Compártela, lístala en el catálogo o añádela a tu documentación. Tu origen no se toca.
3. Un agente llama, recibe un 402 y paga. La primera petición recibe el precio y los datos de pago; el agente firma una autorización de USDC en Base y reintenta. Payzum la verifica a través del facilitator.
4. La llamada pagada se reenvía y el USDC aterriza en tu wallet. Payzum manda la petición a tu origen con tu key, devuelve la respuesta y el pago se liquida en tu dirección: sin custodia, sin calendario de payouts. Los webhooks firmados avisan a tus sistemas.

Tres tipos de negocio de APIs, y qué cambia para cada uno

El lanzamiento se lee distinto según lo que vendas.

• Una API de datos o consulta (enriquecimiento de empresas, geocodificación, tipos impositivos, parseo de documentos). Tus llamadas tienen precio, no se miden. El x402 por llamada es el encaje correcto hoy; un canal añadiría complejidad sin ahorrarte nada. Expón los dos o tres endpoints que los agentes realmente quieren, a un precio por debajo del suelo de las comisiones de tarjeta, y sé localizable.
• Un host de modelos o cómputo (modelos ajustados, embeddings, trabajos en GPU). Tú eres el caso de uso del canal, y Alibaba Cloud acaba de mostrar la forma de la demanda. Empieza con precio por llamada sobre una unidad gruesa — por petición, por mil tokens redondeados hacia arriba — para ser alcanzable ya, y planifica la integración del canal para cuando el bucle de un comprador justifique la ingeniería.
• Un SaaS con una API que nadie compra por separado. Los agentes son un segmento de cliente nuevo que jamás rellenará tu formulario de alta. Una URL x402 de pago sobre un endpoint útil es una forma de bajo riesgo de descubrir qué pagará un agente, con el dinero en tu propia wallet y una franquicia mensual gratuita mientras aprendes.

x402 por llamada vs Payment Channels de Solana vs API keys con facturación por tarjeta

Objeciones razonables

"Si los canales son el futuro, ¿el x402 por llamada no es un callejón sin salida?"

No: los canales se construyen sobre x402 y MPP, no en su lugar. El handshake 402, el precio en la respuesta y la liquidación en stablecoin son los mismos; un canal cambia cuántas llamadas cubre una autorización. Un vendedor alcanzable por llamada hoy es alcanzable por cualquier stack de agentes que hable el protocolo, y añade un canal cuando el bucle de un comprador concreto lo justifique. Nada de la URL, el precio o la wallet cambia.

"La mitad del volumen es wash trading. ¿Para qué vender a agentes?"

Porque el volumen artificial te dice dónde está la especulación, no dónde están los compradores. La auditoría de Bitquery y los datos de Artemis apuntan a la misma conclusión: los vendedores que ganaron dinero real tenían un endpoint real, un precio sensato y un motivo para llamadas repetidas. El coste de averiguar si tu API es una de ellas es un mapeo en un panel y una franquicia mensual gratuita, con el dinero en tu propia wallet en lugar del saldo de un procesador.

"Alibaba Cloud puede pagarse la ingeniería. Yo no."

Esa es precisamente la brecha que este lanzamiento deja al descubierto, y la razón por la que el lado vendedor sigue escaso. No necesitas el programa de canal para ser cobrable por agentes. Necesitas una URL de pago, un precio y una dirección. Eso es una configuración, no un proyecto.