« Back to Glossary Index

Bolt 11 (Formato de Factura Lightning)

⚡ Definición Rápida

Bolt 11 es la especificación técnica (definida en el BOLT #11) que establece el formato estándar y universal para las «facturas» o «invoices» de pago en la Lightning Network. Es una cadena de caracteres codificada en Bech32 (comienza con ‘lnbc…’) que contiene toda la información necesaria para realizar un pago Lightning de forma segura y precisa: el monto a pagar, el destino (nodo receptor), una descripción, una marca de tiempo, un hash criptográfico que actúa como identificador único de pago y otras condiciones opcionales. Bolt 11 es el lenguaje común que permite a cualquier wallet o nodo Lightning generar solicitudes de pago y a cualquier otra wallet interpretarlas y cumplirlas, garantizando la interoperabilidad en toda la red.

Términos relacionados: Lightning Networksha-256nodewallet


❓ ¿Por qué Bolt 11 es el estándar de facto para pagar en Lightning?

Imagina que cada tienda online usara un formato de factura completamente distinto: algunas con códigos QR, otras con enlaces web, otras que requieren que introduzcas datos manualmente. Sería caótico. Bolt 11 resuelve este problema para la Lightning Network al ser el «formato de factura digital» universalmente aceptado. Antes de su estandarización, era difícil que una wallet como Phoenix pudiera pagar una factura generada por un nodo que usara software de BlueWallet o viceversa.

Este estándar no solo facilita la interoperabilidad, sino que también introduce mecanismos de seguridad críticos. El hash de pago (payment hash) dentro de la factura es la pieza central que hace posibles los Hash Time-Locked Contracts (HTLCs), el mecanismo que garantiza que el pago es atómico y que el receptor solo puede cobrarlo revelando un secreto, lo que a su vez permite el routing a través de múltiples nodos. Sin un formato estandarizado como Bolt 11, la Lightning Network sería una colección de sistemas incompatibles en lugar de una red global unificada de pagos.

📖 Definición Técnica

Una factura Bolt 11 es un string codificado en Bech32 que encapsula un mensaje firmado digitalmente. Técnicamente, el formato sigue la estructura definida en el BOLT #11 del repositorio de especificaciones de Lightning Network. El mensaje contiene campos obligatorios como el monto (en mili, micro o picobitcoins), un timestamp Unix, el payment hash (hash SHA-256 de un preimage secreto), una descripción (o su hash) y la clave pública del nodo receptor. Opcionalmente, puede incluir route hints, expiración, y otros campos. El mensaje completo se firma con la clave privada del nodo emisor, garantizando autenticidad e integridad. La codificación Bech32 es resistente a errores de transcripción y soporta checksums, lo que la hace ideal para su uso en códigos QR.


⚙️ Anatomía de una factura Bolt 11: Campos y funciones clave

Una factura Bolt 11 es mucho más que una simple dirección. Es un paquete de datos estructurado. La siguiente tabla desglosa sus componentes principales:

Campo (Etiqueta)DescripciónPropósito/FunciónEjemplo / Notas
Prefijo (‘lnbc’)Identifica el string como una factura Lightning para Bitcoin (Mainnet).Permite a las wallets detectar e interpretar correctamente el código.‘lnbc’ (mainnet), ‘lntb’ (testnet), ‘lnbcrt’ (regtest).
Monto (Amount)La cantidad a pagar, en una unidad específica.Especifica el valor de la factura de forma inequívoca para evitar errores.‘1000m’ = 1000 millibits (0.001 BTC). ‘2500u’ = 2500 microbits (0.0025 BTC). ‘1000000000p’ = 1,000,000,000 picobits (0.001 BTC).
Timestamp (Fecha)La fecha y hora de creación de la factura (en segundos desde el epoch).Permite verificar la validez temporal y establecer expiración.Una factura suele expirar a las 3600 segundos (1 hora) de su creación.
Payment Hash (Hash de Pago)Un hash SHA-256 (de 32 bytes) generado a partir de un secreto aleatorio (preimage).Es el corazón de seguridad. El pago solo se completa cuando el receptor revela el preimage que genera este hash. Permite el routing seguro.Campo crítico. Sin el preimage correcto, es imposible cobrar la factura.
Descripción (Description)Un texto legible que describe el pago.Informa al pagador sobre el propósito de la factura. Se incluye su hash (desc_hash) para integridad.«Café doble en Café Satoshi» o «Pago por el libro ‘Mastering Lightning'».
Node PubKey (Clave del Nodo)La clave pública del nodo destinatario final.Identifica al receptor. Es necesaria para establecer la ruta final del pago.Es la dirección de red del receptor, no una dirección on-chain.
Route Hints (Pistas de Ruta)Información opcional sobre canales privados o rutas hacia el receptor.Ayuda al pagador a encontrar una ruta hacia nodos que no son públicamente accesibles, mejorando la tasa de éxito.Esencial para wallets móviles o nodos detrás de NAT/firewalls.
Expiración (Expiry)Tiempo (en segundos) que la factura es válida.Previene el reuso de facturas y protege al vendedor de fluctuaciones de precio si la factura no tiene monto fijo.Por defecto es 3600 (1 hora). Puede ser mayor o menor.
Firma (Signature)Firma digital creada con la clave privada del nodo emisor.Autentica la factura. Prueba que fue generada por el dueño de la Node PubKey y que no ha sido alterada.Garantía de autenticidad e integridad, similar a una firma en un cheque.

🏗️ Cómo funciona el ciclo de vida de un pago con Bolt 11

Desde la creación hasta la liquidación, una factura Bolt 11 guía un proceso criptográfico seguro y automatizado.

1. Generación por el Vendedor/Receptor (Bob):

Bob, dueño de una tienda, quiere cobrar 15,000 satoshis (0.00015 BTC) por un producto. Su wallet o punto de venta:

  1. Genera un secreto aleatorio (preimage) R.
  2. Calcula el payment hash H = SHA-256(R). Este H se incluirá en la factura, pero R se guarda en secreto.
  3. Compila todos los campos: monto (15000n, donde ‘n’ = nanobitcoins o satoshis), timestamp, su Node PubKey, una descripción («Producto XYZ»), etc.
  4. Firma toda esta información con su clave privada.
  5. Codifica el paquete firmado en una string Bech32: lnbc15000n1p3qzyc5pp5q9twd9r... [string largo].
  6. Muestra esta string como un código QR o la envía por texto al comprador.

2. Escaneo/Decodificación por el Comprador (Alice):

Alice abre su wallet Lightning, escanea el código QR. Su wallet:

  • Reconoce el prefijo ‘lnbc’.
  • Decodifica la string Bech32 y verifica el checksum para detectar errores.
  • Valida la firma usando la Node PubKey incluida, asegurándose de que la factura es auténtica y no fue manipulada.
  • Muestra a Alice el monto (15,000 sats), la descripción («Producto XYZ») y la identidad del receptor (el alias de Bob).

3. Construcción y Envío del Pago:

Cuando Alice confirma el pago, su wallet:

  • Usa el payment hash H (de la factura) y el monto para construir un HTLC (Hash Time-Locked Contract).
  • Usa la Node PubKey de Bob (y las route hints si existen) para encontrar una ruta a través de la red Lightning hacia el nodo de Bob.
  • Envía el pago, que salta de nodo en nodo. Cada nodo intermedio crea un HTLC hacia el siguiente, todos bloqueados con el mismo hash H. El contrato dice esencialmente: «Paga a quien te revele el secreto R que produce el hash H».
  • El pago llega al nodo final de Bob.

4. Liquidación y Revelación del Secreto:

El nodo de Bob recibe el HTLC. Como Bob es el único que conoce el secreto R original (el preimage), su wallet lo revela automáticamente para cobrar el pago. Este secreto R se propaga hacia atrás por la ruta, permitiendo que cada nodo cobre el HTLC del nodo anterior. En milisegundos, los fondos se liquidan y Bob recibe sus 15,000 satoshis. La revelación de R es la prueba criptográfica de que el pago se completó con éxito.

Ejemplo concreto de una factura (simplificada):


🎯 Bolt 11 vs. Otras Formas de Solicitar Pagos (On-Chain, Bolt 12)

Bolt 11 es el rey actual, pero entender sus alternativas ayuda a ver su lugar en el ecosistema.

Método/FormatoBolt 11 (Factura Lightning)Dirección On-Chain BitcoinBolt 12 (Facturas Ofrecidas / Offers)
PropósitoSolicitar un pago Lightning específico e inmediato.Solicitar un pago en la cadena base de Bitcoin (L1).Solicitar un pago Lightning de forma reutilizable y sin monto prefijado.
InteractividadUnidireccional. El vendedor genera, el comprador paga.Unidireccional.Bidireccional. Permite «tirar» de un pago del comprador.
ReutilizabilidadNO. Una factura es de un solo uso por diseño (para privacidad/seguridad).Sí, pero no es recomendable por privacidad.. Una misma «oferta» puede usarse para múltiples pagos.
Información IncluidaMonto fijo, destino, hash, descripción, expiración.Solo el destino (script).Destino y condiciones, pero sin monto o descripción fija. El comprador los elige.
Ventaja PrincipalEstándar universal, seguro, ampliamente soportado. Ideal para pagos puntuales de comercio.Funciona siempre, sin necesidad de canales Lightning. Para transacciones grandes o definitivas.Mejor para suscripciones, donaciones, propinas o pagos recurrentes donde el monto lo decide el pagador.
Desventaja PrincipalSe necesita generar una factura nueva para cada transacción, incluso para el mismo monto al mismo vendedor.Lentitud (confirmaciones), alto costo (tarifas on-chain), no es para micropagos.Es una propuesta más nueva, con soporte en wallets aún en desarrollo y menos extendido que Bolt 11.

⚖️ Ventajas, limitaciones y mejores prácticas

✅ Ventajas y Fortalezas de Bolt 11:

  • Interoperabilidad Absoluta: Es el «lingua franca» de Lightning. Cualquier wallet moderna lo soporta, lo que facilita el onboarding de usuarios y la adopción comercial.
  • Seguridad Robusta: La combinación de payment hash, firmas digitales y expiración previene el fraude, el reuso no autorizado y los ataques de repetición.
  • Experiencia de Usuario (UX) Fluida: El escaneo de un código QR es rápido y familiar. La descripción integrada da contexto al pagador, reduciendo errores.
  • Privacidad para el Pagador: Una factura Bolt 11 no revela la identidad del pagador (Alice) al receptor (Bob) hasta que el pago se inicia, y ni siquiera entonces de forma directa.

❌ Limitaciones y Desafíos:

  • Unicidad (No Reutilizable): La mayor queja. Para un comercio con un precio fijo, debe generar una factura nueva para cada cliente, lo que puede ser una carga para su servidor y para mostrar (ej. en una web estática).
  • Monto Fijo: No es ideal para casos donde el monto lo decide el pagador (donaciones, propinas). Se necesitan soluciones aparte (como facturas sin monto, que luego son menos comunes).
  • Dependencia de Route Hints: Para nodos no bien conectados (como wallets móviles), la factura debe incluir «route hints», lo que aumenta su longitud y complejidad.
  • Falta de Metadatos Avanzados: Es difícil incluir información estructurada adicional (como un ID de pedido, factura fiscal, etc.) de forma estandarizada.

🔮 El futuro: Bolt 12 y la evolución de las facturas

Bolt 11 es el presente, pero la comunidad ya está trabajando en su sucesor evolutivo, Bolt 12 («Offers» u Ofertas), diseñado para superar sus limitaciones más importantes:

  • Reutilizabilidad y «Pull Payments»: Una «Offer» Bolt 12 puede publicarse una vez (en un sitio web, perfil social) y usarse para recibir múltiples pagos. Es el comprador quien, al escanearla, «jala» (pull) una factura específica de tu nodo, especificando el monto que quiere pagar. Es ideal para donaciones, propinas en redes sociales o suscripciones.
  • Interactividad y Menos Dependencia del Vendedor: El vendedor no necesita estar online en el momento exacto del pago para generar una factura. La Offer contiene las claves para que el comprador interactúe con el nodo del vendedor y obtenga una factura bajo demanda.
  • Blinded Paths para Mayor Privacidad: Bolt 12 integra mejoras de privacidad que dificultan que terceros correlacionen la oferta con los pagos posteriores.
  • Transición Gradual: Bolt 12 no reemplazará a Bolt 11 de la noche a la mañana. Es probable que coexistan durante años, con Bolt 11 siendo el estándar para el comercio electrónico tradicional (pago único, monto fijo) y Bolt 12 ganando terreno en casos de uso más sociales y recurrentes. Las wallets más avanzadas, como Core Lightning, ya tienen soporte experimental.

🎯 Conclusión: El puente esencial entre usuarios y la red

Bolt 11 es mucho más que un código extraño que escaneas con tu wallet. Es el protocolo de capa de aplicación que hace que los pagos Lightning sean usables, seguros e interoperables. Es el contrato digital mínimo que alinea los incentivos criptográficos de todas las partes: garantiza que el vendedor solo cobra si se ha realizado el pago correcto, y que el comprador solo paga si el vendedor puede demostrar la recepción.

Su diseño, aunque con limitaciones, ha sido fundamental para el crecimiento de Lightning. Comprender Bolt 11 es comprender cómo se solicita y se ejecuta un pago en esta nueva capa financiera. Para un usuario, significa confianza al escanear un código. Para un desarrollador, es un conjunto de reglas claras para implementar. Y para la red, es el pegamento que mantiene unido el ecosistema, mientras evoluciona hacia estándares aún más potentes y flexibles como Bolt 12.

❓ Preguntas Frecuentes sobre Bolt 11


📚 ¿Quieres profundizar en Lightning Network?

Explora más recursos de La Cryptoguía sobre la Lightning Network y sus estándares:

Lightning Network – La red de pagos de segunda capa.

🔐 ¿Qué son los Layer 2? – El contexto general de las soluciones de escalabilidad.

📜 Cómo comprar Bitcoin – El primer paso para usar la Lightning Network.


🚀 ¿Empezando en Crypto?

Si eres nuevo, empieza con nuestra guía completa para principiantes para entender los fundamentos antes de adentrarte en la Lightning Network.


📋 ¿Por qué confiar en esta definición? Cada término de la Cryptopedia sigue una metodología de verificación con fuentes primarias, whitepapers y legislación oficial. Conoce nuestro proceso →


⚠️ Disclaimer: Este artículo es informativo y educativo. No constituye asesoramiento financiero ni técnico. Siempre verifica los detalles de una factura Lightning (monto, destinatario) antes de pagar. El reuso de una factura Bolt 11 puede llevar a la pérdida de fondos. Las tecnologías como Bolt 12 están en desarrollo y su adopción no es universal. Utiliza software actualizado de fuentes confiables para interactuar con la Lightning Network.

📅 Actualizado: Marzo 2026
📖 Categoría: Infraestructura Blockchain / Interoperabilidad y Bridges

« Volver al Glosario
Scroll al inicio