Bitcoin Lightning en x402: Block se sumó al estándar y la spec obliga al vendedor a operar un nodo

Qué anunció Block el 24 de septiembre de 2026

El jueves, Block —la empresa detrás de Square, Cash App, Afterpay y la wallet Bitkey— anunció que se había unido a la x402 Foundation, el organismo alojado en la Linux Foundation que gobierna x402, el estándar abierto que mete un pago dentro de una petición HTTP. El texto, firmado por Steve Reis, responsable de producto de Block Financial Platform, venía con una contribución debajo del brazo: pagos con Bitcoin Lightning en x402.

Block lo presentó como el siguiente paso de un trabajo abierto que ya venía haciendo: liberó goose, su agente de IA de código abierto; ayudó a lanzar la Agentic AI Foundation; y se sumó al Universal Commerce Protocol para llevar el comercio agéntico a pequeños negocios. El anuncio enumera tres beneficios: que los vendedores lleguen a "nuevos compradores y sus agentes", que los agentes paguen mediante un estándar y no con integraciones a medida, y "Bitcoin como dinero de todos los días".

Steve Lee, que dirige Spiral, el equipo de desarrollo de Bitcoin de código abierto de Block, defendió el riel: "Los agentes harán miles de millones de pagos pequeños, y esos pagos necesitan rieles instantáneos, baratos y abiertos a cualquiera. Para eso se construyó Lightning." Erik Reppel, creador de x402 y miembro del Comité Técnico de la Fundación, lo celebró como prueba del diseño: "x402 se diseñó para ser abierto y extensible. Cualquier red debería poder conectarse y cualquier desarrollador debería poder construir encima."

Lo que el anuncio no trae es una fecha para ningún producto de Block. La hoja de ruta ocupa tres líneas: seguir contribuyendo al soporte de Lightning, participar en los grupos de trabajo de la Fundación y seguir construyendo herramientas abiertas de comercio agéntico. No hay calendario para Square, Cash App ni Bitkey. Si vendes con Square y esperas que los agentes te paguen desde tu panel el mes que viene, nada en este anuncio lo promete.

Qué dice de verdad la spec de Bitcoin Lightning en x402

La contribución entró en el repositorio de x402 el 23 de septiembre como scheme_exact_lnbtc.md, una especificación de 760 líneas propuesta en julio. La prensa la resumió como "soporte para Lightning". Es en el documento donde el soporte se convierte en obligaciones, así que conviene leer el flujo tal cual:

1. El servidor del vendedor genera una factura BOLT11 nueva para cada cobro y la devuelve dentro de la respuesta 402. Una factura nunca puede reutilizarse entre clientes ni entre cobros.
2. La factura se compromete con un hash de la petición exacta —método, URL y cuerpo en HTTP, o la llamada a la herramienta en MCP—, de modo que el pago de una petición no sirve para otra.
3. El agente paga la factura por Lightning y devuelve la preimagen, el secreto de 32 bytes que solo aparece cuando el pago ya se liquidó.
4. Un facilitator verifica la prueba: que la preimagen corresponde al hash de pago de la factura, que la firmó la clave del nodo del vendedor y que ese hash no se usó antes. Lo registra en un almacén anti-repetición persistente. Nunca necesita acceso al nodo del vendedor.
5. Solo entonces el servidor ejecuta la petición.

Es criptografía elegante y no es terreno nuevo: el diseño hash-preimagen de Lightning lleva años usándose para cobros HTTP 402, sobre todo en el protocolo L402 de Lightning Labs. La versión de x402 hereda esa propiedad con limpieza. También hereda sus límites. El esquema solo admite precio exact con flujo upfront —sin pagos medidos upto, sin sesiones— y el activo tiene que ser BTC.

Cinco cosas que el esquema Lightning le pide al vendedor

Cada anuncio de x402 de este año se escribió pensando en quien construye al comprador. Si lo lees desde el otro lado de la petición —como el negocio que tiene que recibir el dinero— destacan cinco requisitos.

1. Pones precio en satoshis y tus ingresos flotan

El importe viaja como un número entero de milisatoshis. La spec va más lejos que la mayoría: los SDK de cara al usuario deben usar importes explícitos en satoshis por defecto, y precios escritos como $1 o 1 USD se rechazan salvo que la aplicación registre su propio parser de conversión. Un precio en dólares es, por tanto, problema tuyo: construirlo y mantenerlo. O fijas el precio en sats y aceptas que tu ingreso en dólares por llamada se mueva con Bitcoin, o recotizas cada factura con un feed de precios en el que confíes. Tu factura de nube y tu nómina siguen en dólares (o en pesos).

2. Necesitas un nodo Lightning desde el que solo tú puedas facturar

El campo payTo no es una dirección de wallet: es la clave pública del nodo receptor que firma tus facturas. La spec exige que el servidor del vendedor tenga autoridad exclusiva para emitir facturas con esa clave, y explica por qué: en un nodo custodial compartido, un inquilino podría pagar su propia factura y reutilizar la preimagen contra el cobro de otro inquilino. En palabras de la spec, "un nodo custodial compartido no es compatible".

O sea, una cuenta Lightning alojada y compartida con otros clientes no sirve. Necesitas tu propio nodo, o uno dedicado que alguien opere para ti. Lo anotamos con cierta satisfacción: el propio modelo de seguridad del estándar descarta la wallet custodial agrupada, la misma conclusión a la que llegamos para los pagos de comercios en general en por qué un procesador de pagos no debería guardar tu dinero.

3. Tu nodo tiene que estar en línea, con liquidez y protegido

Un nodo Lightning solo recibe si está en línea y tiene capacidad de entrada en sus canales, es decir, liquidez de otro apuntando hacia ti. Para un equipo que ya opera Lightning, ninguna de las dos cosas es un problema. Para un equipo que opera una API, ambas son trabajo operativo nuevo. La spec añade un tercer punto: las facturas nuevas "consumen recursos del nodo receptor", así que los servidores deberían limitar o autorizar su emisión. Una avalancha de peticiones sin autenticar a un endpoint de pago se convierte en carga sobre el nodo que guarda tu dinero.

4. No hay vía de reembolso

El esquema "no ofrece vía de reembolso; cualquier reembolso es un acuerdo aparte con el receptor", y un sobrepago no da crédito adicional. Para ser justos, lo mismo pasa con la liquidación en USDC: es la finalidad que hace imposibles los contracargos, y para nosotros es una ventaja. Pero significa que el caso "el agente pagó y luego falló mi servicio de origen" necesita una política por escrito, elijas el riel que elijas.

5. No sabrás quién te pagó

Este es el requisito que más vendedores van a pasar por alto. El enrutamiento de Lightning no da una identidad estable del pagador, así que la spec obliga a los facilitators a omitir al pagador en la respuesta de liquidación. En redes EVM, la respuesta de liquidación del núcleo de x402 incluye la dirección que pagó.

Esa dirección es cómo tú —y cualquiera que audite este mercado— separas la demanda real del ruido. Los estudios independientes de x402 publicados este mes distinguieron compradores agénticos genuinos de autopagos y de volumen de un solo pagador precisamente mirando direcciones de pagadores; repasamos uno en la primera auditoría de x402. En Lightning, ese análisis no sale de los datos de liquidación. La privacidad es un beneficio real para quien compra. Para un vendedor que intenta contar clientes distintos, es un punto ciego.

El estándar es agnóstico a la red. Los compradores no son agnósticos al activo.

Lightning no es una excepción. El esquema exact de x402 ya tiene especificaciones para 17 familias de redes —cadenas EVM, Solana, Stellar, XRP Ledger, Cardano, Sui, Aptos, NEAR, TON, Hedera, Algorand, Starknet, Casper, Canton, Concordium, Keeta y ahora Lightning—, además de esquemas aparte para pagos medidos, autorización-captura y liquidación por lotes. La Fundación hace exactamente lo que describía Reppel: dejar que cualquier red se conecte.

Las cadenas que mueven el tráfico cambian rápido. El 22 de septiembre, la cuenta oficial de Solana dijo que había procesado el 76% de todas las transacciones x402 de las cuatro semanas anteriores —23,2 millones, frente a 3,39 millones de la siguiente red—, después de superar a Base en conteo diario a finales de agosto. Un día antes, la Cardano Foundation anunció que Cardano se había sumado al SDK oficial de x402, por ahora con una sola transacción de prueba.

El activo no cambia. Los resultados del segundo trimestre de 2026 de Circle lo dicen sin adornos: el 99,3% del volumen de pagos de agentes en x402 se liquida en USDC. A los agentes los operan empresas que presupuestan en dólares; los vendedores ponen precios en dólares; una stablecoin convierte el precio por llamada en un número que cabe en una planilla sin nota al pie. Hasta el anuncio de Block habla de "invertir en pagos con stablecoins y con Bitcoin", no de uno en lugar del otro.

Ese es el marco para leer el 24 de septiembre. Una opción de activo nueva amplía el estándar. No cambia el valor por defecto, y un vendedor solo debería adoptar un riel que no es el por defecto cuando tiene una razón propia de su negocio.

Quién debería probar Lightning en x402

Para algunos vendedores este anuncio es una buena noticia de verdad:

• Ya operas un nodo Lightning en tu negocio, con liquidez de entrada y alguien que lo cuida. Sumar x402 es trabajo incremental, no una disciplina nueva.
• Quieres BTC en tu balance y te sientes cómodo con que tu ingreso en dólares por llamada flote con el precio.
• Tus compradores son nativos de Bitcoin —agentes construidos sobre wallets y herramientas Lightning— o la privacidad del pagador es parte de lo que vendes.

Para todos los demás —la mayoría de APIs de datos, servidores MCP, endpoints de inferencia y servicios B2B de nicho—, Lightning en x402 añade un nodo, una decisión de tesorería y un punto ciego de medición para alcanzar a los compradores que pagan con algo distinto de USDC: el 0,7% del volumen x402 en el conteo del segundo trimestre de Circle. Puede crecer. Vale la pena seguirlo. No es por donde empezar.

Dónde encaja Payzum, y dónde no

El producto x402 de Payzum está hecho para el caso por defecto, y queremos ser exactos con el rol. Payzum es el middleware: un proxy delante de tu API existente. Payzum no es el facilitator. La liquidación pasa por un facilitator externo (hoy, el de Coinbase).

• Configuras tres cosas en un panel: la URL de tu endpoint actual, tu API key o bearer token y un precio. Sin SDK, sin manejar el 402, sin librerías de wallet en tu código.
• Payzum publica una URL x402, devuelve el 402 con los requisitos de pago, liquida a través del facilitator externo y luego hace de proxy de la llamada pagada hacia tu endpoint real con tu key.
• Cobras en USDC en Base, en una wallet que controlas. Sin custodia: no hay saldo en Payzum ni calendario de pagos. El pago es la liquidación, con confirmación típica de unos dos segundos.
• Tu precio está en dólares, porque el activo es un dólar. Cada pago es una transferencia on-chain de USDC en Base, así que la dirección que paga queda en el registro público: la materia prima para contar compradores distintos.
• Precio: aproximadamente las primeras 1.000 transacciones al mes son gratis; después, unos $0,001 por transacción más gas.

El límite honesto:

• Payzum no soporta x402 sobre Lightning. Nuestro producto agéntico es x402 por llamada, en USDC sobre Base.
• Payzum no es un facilitator de x402. Serlo es un objetivo a futuro, no una afirmación sobre hoy.
• Sin pagos medidos upto, sesiones ni canales. Una petición, un precio, una liquidación.
• Solo cripto. Aceptamos cripto y liquidamos en cripto, con autoconversión opcional a USDC o USDT. No liquidamos a cuentas bancarias.
• Bitcoin sí está soportado para pagos normales. Si quieres cobrar BTC a clientes humanos —links de pago, checkout alojado, facturas o el punto de venta—, Payzum acepta Bitcoin on-chain hoy, junto con Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain y Avalanche.
• No tenemos relación comercial con Block ni con Circle. Escribimos sobre sus anuncios porque importan a los vendedores con los que trabajamos.

Cómo hacer que los agentes te paguen esta semana, paso a paso

1. Elige un endpoint. El que tenga una unidad de valor clara: una consulta, un scrape, un score, una generación. Ponle precio en una frase, en dólares.
2. Sé dueño de la wallet de destino. Crea o conecta la dirección donde debe llegar el USDC en Base y activa el 2FA. Esa dirección es tu cuenta; todo lo que viene después hereda su modelo de custodia.
3. Configura el proxy. En el panel de Payzum: endpoint, API key o bearer y precio por llamada. Payzum publica la URL x402; mira cómo funciona en la página de x402.
4. Pruébalo como lo haría un agente. Llama a la URL, recibe el 402, paga, reintenta y comprueba que la respuesta del proxy coincide con tu origen. Los webhooks firmados conectan cada pago con los sistemas que ya usas.
5. Mide durante un mes. Sigue las direcciones pagadoras distintas y el ingreso por pagador. Si esos números se mueven y tus compradores resultan ser nativos de Bitcoin, ese es el momento de presupuestar un nodo Lightning, con datos en vez de un comunicado de prensa.

Para quién es esto, en concreto

• Una API de datos o de scraping cuyos usuarios humanos se registran, queman el free tier y se van. Los agentes pagan por llamada sin registro y sin tarjeta; los números están en x402 vs facturación con API key.
• Un servidor MCP al que ya llaman asistentes y que no gana nada. Cobrar por llamada a herramienta es la misma configuración que cobrar por llamada a API; lo vimos en monetizar un servidor MCP con x402.
• Un servicio nativo de Bitcoin que ya opera Lightning. Puede que sumes Lightning en x402, y aun así te convenga un endpoint en USDC para el 99% del volumen agéntico que llega en dólares.

x402 sobre Lightning vs x402 en USDC con Payzum: qué elige un vendedor

Objeciones frecuentes

"Bitcoin es la red más abierta. ¿No debería soportarla por principio?"

La apertura a nivel de protocolo es real, y x402 es mejor con Lightning dentro. Pero la pregunta de un vendedor es más concreta: ¿cuánto me cuesta recibir por este riel y quién me va a pagar por él? Hoy el costo es un nodo y un precio que flota, y los pagadores están abrumadoramente en USDC. Súmalo cuando tus compradores lo pidan: el estándar seguirá abierto.

"Las comisiones de Lightning son mínimas."

Lo son, y con esta spec el pagador cubre las comisiones de enrutamiento aparte del importe de la factura. Pero las comisiones nunca fueron el problema del vendedor en ninguno de los dos rieles: al tamaño de una llamada de API, liquidar USDC en Base también cuesta fracciones de centavo. El costo que importa del lado del vendedor es operativo —mantener el nodo— y financiero —tener el activo—. Ninguno de los dos aparece en una comparativa de comisiones.

"¿Square no terminará llevando esto a todos sus vendedores?"

Es posible: Block tiene la base de comercios para que eso importe. Pero no se ha anunciado nada, y cuando se anuncie, lee el modelo de custodia antes que la tabla de comisiones: dónde caen los sats, quién los tiene y cuándo puedes moverlos. La propia regla de la spec contra los nodos custodiales compartidos sugiere que la respuesta importa.