Como funcionam as faturas Lightning BOLT11 e BOLT12

As faturas da Lightning permitem fazer pagamentos nessa rede. Sempre que você escaneia um código QR para pagar pela Lightning, sua carteira obtém uma fatura. O código pode conter a própria fatura (BOLT11) ou ser reutilizável, como uma oferta BOLT12 ou um LNURL que a carteira usa para pedir uma fatura nova. A fatura traz tudo o que a carteira precisa para rotear o pagamento, como o destinatário, o valor, o hash de pagamento, a validade e as pistas de roteamento. Saber como funcionam as faturas e o que muda entre BOLT11 e BOLT12 ajuda a entender como os pagamentos circulam pela rede e por que o protocolo está evoluindo.

Você vai ver como usar os dois formatos de fatura, quais são as diferenças e o que o BOLT12 muda nos pagamentos Lightning.

O que é uma fatura Lightning?

Uma fatura Lightning é um pedido de pagamento. Para um endereço de Bitcoin na blockchain, você pode enviar o valor que quiser. Uma fatura Lightning normalmente especifica quanto pagar, para onde enviar e até quando o pedido é válido. Quem recebe gera a fatura e a compartilha com quem vai pagar. A carteira de quem paga lê os dados codificados para preparar e encaminhar o pagamento.

O nome “fatura” é preciso porque ela pede um pagamento específico. Depois de paga ou vencida, uma fatura Lightning padrão deixa de servir. Um endereço de Bitcoin na blockchain pode receber vários pagamentos sem prazo definido.

BOLT11: o padrão atual

O BOLT11 (especificação 11 de Basis of Lightning Technology) é o formato de fatura mais usado desde os primeiros anos da rede. Se você já usou a rede Lightning (em inglês), já usou faturas BOLT11, mesmo que só tenha visto os códigos QR.

Anatomia de uma fatura BOLT11

Uma fatura BOLT11 é uma sequência longa de caracteres alfanuméricos. Em geral, começa com lnbc (para a rede principal do Bitcoin), seguido dos dados de pagamento codificados. Estes são os campos:

Prefixo da rede: lnbc (rede principal), lntb (rede de testes) ou lnbcrt (regtest)
Valor: o valor do pagamento codificado na sequência. Por exemplo, lnbc500n equivale a 50 satoshis. Pode ficar de fora em faturas de valor livre.
Marca de tempo: indica quando a fatura foi criada.
Hash de pagamento: um hash de 256 bits que condiciona o pagamento. Quem recebe conhece a pré-imagem, o segredo que gera esse hash. Quem paga não a conhece. Isso garante que um pagamento com vários saltos seja concluído por inteiro ou devolvido.
Segredo de pagamento: um segundo valor aleatório, diferente da pré-imagem. Só quem tem a fatura o conhece, e o destinatário rejeita pagamentos sem esse valor. Assim, os nós da rota ficam impedidos de fazer testes para identificar quem recebe. Toda fatura BOLT11 precisa incluir esse segredo.
Destino (ID do nó de quem recebe): a chave pública do nó Lightning do destinatário. Em geral, ela fica implícita e a carteira a recupera a partir da assinatura.
Descrição: uma explicação legível do motivo do pagamento, como “Café na loja X”.
Validade: por quanto tempo a fatura vale. O padrão é 1 hora e pode ser alterado.
Dicas de roteamento: rotas sugeridas até o destino, úteis principalmente quando o nó de quem recebe tem poucas conexões no grafo público.
Assinatura: assinatura criptográfica de quem recebe, que prova que a pessoa criou a fatura.

A fatura de exemplo da especificação BOLT 11, lnbc2500u1pvjluez…fna3rh, separada em partes. lnbc é o prefixo da Lightning na rede principal do Bitcoin. 2500u é o valor, 0,0025 BTC ou 250.000 sats. 1 é o separador e pvjluez é a marca de tempo, 1º de junho de 2017. Depois vêm os campos. Cada um começa com uma letra que o identifica, seguida de dois caracteres que indicam o comprimento. s é o segredo de pagamento. Ele é diferente da pré-imagem e prova que quem paga tem a fatura. p é o hash de pagamento, o cadeado do pagamento. d é a descrição. O valor é “1 cup coffee” (uma xícara de café). x é a validade, 60 segundos ou 1 hora se esse campo ficar de fora. 9 indica os recursos que a carteira de quem recebe aceita. No fim vêm a assinatura, que prova quem criou a fatura e revela o ID do nó, e a soma de verificação, que detecta erros de digitação. O valor é escrito em bitcoins seguido de uma letra: m para mili, u para micro, n para nano e p para pico. Assim, 10n equivale a 1 sat. — **Uma fatura BOLT11 é uma única sequência dividida em campos.** Este exemplo da especificação cobra 0,0025 BTC por um café. Dos 271 caracteres, 104 são da assinatura e 55 são de cada um dos campos do segredo e do hash de pagamento. Por isso até uma fatura simples é longa. O exemplo deixa de fora os campos opcionais, como as dicas de roteamento.

Como funciona um pagamento BOLT11

Quem recebe gera um segredo aleatório de 32 bytes, a pré-imagem.
Quem recebe aplica uma função hash à pré-imagem para obter o hash de pagamento e codifica esse hash em uma fatura BOLT11.
Quem recebe compartilha a fatura com quem paga por código QR, texto, NFC ou outro meio.
A carteira de quem paga decodifica a fatura, lê o destino e o valor e procura uma rota pela rede.
O pagamento passa de um nó intermediário para outro. A cada salto, o nó retém os fundos até receber a pré-imagem por meio de um contrato com bloqueio por hash e tempo, ou HTLC.
Quem recebe revela a pré-imagem ao último nó da rota. O segredo percorre a rota no sentido inverso, cada nó resolve o próprio HTLC e o pagamento é liquidado.

Um pagamento BOLT11 em três passos. 1. Quem recebe guarda um segredo, a pré-imagem, e inclui apenas o hash na fatura que chega a você como código QR ou texto. O hash é um cadeado que só a pré-imagem abre. 2. O pagamento avança salto a salto, de você até quem recebe, passando por dois nós. Cada salto fica bloqueado pelo hash. Os fundos são liberados para quem apresentar a pré-imagem ou voltam após o prazo. 3. Para receber o pagamento, o destinatário revela a pré-imagem. Ela volta pela rota, abre todos os cadeados e libera o pagamento em cada salto. Uma fatura paga já foi usada e o pagamento seguinte precisa de outra. — **O hash de pagamento é o cadeado, e a pré-imagem, que só quem recebe conhece, é a chave.** A cada salto, um contrato com bloqueio por hash e tempo (HTLC) retém o pagamento até a pré-imagem voltar. Se o segredo não chegar, o bloqueio por tempo devolve o pagamento. O mesmo mecanismo vale para os pagamentos BOLT12.

Limitações do BOLT11

O BOLT11 tem sido útil para a rede Lightning, mas o formato tem algumas limitações:

Uso único. Cada fatura tem um hash de pagamento único. Depois de paga, não pode ser paga novamente. Uma loja que gera milhares de faturas para vendas pela internet precisa de um sistema que crie uma para cada cliente. Isso acrescenta complexidade.
Perda de privacidade de quem recebe. A fatura inclui a chave pública do nó de quem recebe. Qualquer pessoa que veja a fatura sabe qual nó recebe o pagamento e pode associá-lo a um endereço IP ou a uma identidade real.
Tamanho. As faturas BOLT11 têm uma assinatura criptográfica e podem ser bem longas, especialmente quando incluem dicas de roteamento. Isso dificulta colocá-las em códigos QR compactos e pode dificultar a leitura em câmeras de qualidade baixa.
Reutilização por protocolos adicionais. Soluções como o LNURL permitem reutilizar pontos de pagamento por meio de protocolos que complementam a especificação da Lightning.
Quem recebe precisa estar online. O destinatário precisa estar conectado para gerar a fatura. Se o nó de uma loja ficar temporariamente offline, a loja fica sem poder gerar faturas ou receber pagamentos.

BOLT12: a próxima geração

O BOLT12, também chamado de “Offers”, muda o fluxo de pagamento para superar as limitações do BOLT11. Rusty Russell, desenvolvedor do Core Lightning, propôs para o BOLT12 o modelo de pedido e resposta em duas etapas. Ele permite códigos de pagamento reutilizáveis, protege a privacidade de quem recebe e dá mais flexibilidade aos pagamentos.

Como funcionam as ofertas BOLT12

Em vez de gerar uma fatura de uso único, quem recebe cria uma oferta, um código de pagamento reutilizável. Funciona assim:

Quem recebe cria uma oferta BOLT12 e a publica, por exemplo no site, nas redes sociais ou em um cartão impresso. A sequência da oferta começa com lno.
Quem vai pagar escaneia ou cola a oferta.
A carteira de quem paga envia um pedido de fatura ao nó de quem recebe por uma mensagem com roteamento cebola.
O nó de quem recebe gera automaticamente uma fatura única e a devolve a quem vai pagar.
A carteira de quem paga quita a fatura com o mecanismo padrão de HTLC.

A oferta indica qual nó consultar para pedir uma fatura. Ela não contém hash de pagamento, e o valor é opcional. A cada pagamento, o nó gera uma fatura única sob demanda.

Como funciona uma oferta BOLT12. A oferta é uma sequência que começa com lno1 e indica como chegar ao nó de quem recebe. Pode incluir uma descrição e um valor. Ela não contém hash de pagamento e é publicada uma vez, em um site, perfil ou cartão impresso. 1. Você escaneia a oferta. 2. A carteira envia um pedido de fatura ao nó de quem recebe por Lightning em uma mensagem cebola. 3. O nó devolve uma fatura feita para esse pagamento, com um hash de pagamento próprio. Os passos 2 e 3 acrescentam uma ida e volta. 4. Você paga a fatura sob a condição desse hash, assim como no BOLT11. No próximo pagamento, você usa a mesma oferta e volta ao passo 2 para pedir outra fatura. — **Uma oferta indica à carteira onde pedir uma fatura.** A carteira pede uma fatura nova pela Lightning a cada pagamento. Assim, você pode usar a mesma oferta quantas vezes quiser.

Principais melhorias do BOLT12

Característica	BOLT11	BOLT12
Reutilização	Uso único	Reutilizável (vários pagamentos com a mesma oferta)
Privacidade de quem recebe	A fatura revela o ID do nó	Rotas cegadas ocultam a identidade de quem recebe
Tamanho do código QR	Grande (fatura assinada com todos os dados)	Pequeno quando a oferta identifica o nó de quem recebe (a partir de 60 caracteres). Cada rota cegada acrescenta cerca de 250 caracteres ou mais, então uma oferta privada pode ser tão longa quanto uma fatura BOLT11.
Criação offline	Não (quem recebe precisa estar online)	A oferta pode ser criada offline. Quem recebe precisa estar online quando o pagamento chegar
Pagamentos recorrentes	Sem suporte nativo	Ficaram fora da especificação aprovada. Estavam nos primeiros rascunhos e agora são objeto de uma proposta em aberto (bolts PR #1240)
Prova de pagamento	A pré-imagem prova o pagamento	A pré-imagem prova o pagamento. Desde julho de 2026, a especificação também define provas do pagador (prefixo `lnp`), que permitem a quem pagou provar que quitou uma fatura específica (bolts PR #1346, incorporado em 27 de julho de 2026)
Reembolsos	Sem mecanismo padrão	Protocolo de reembolso integrado

Rotas cegas para ocultar o destinatário

As rotas cegadas são um dos recursos mais importantes do BOLT12. A oferta pode conter uma rota cegada no lugar do ID do nó de quem recebe. Os saltos intermediários são criptografados de modo que cada nó só saiba o próximo passo. Quem paga consegue encaminhar o pagamento sem descobrir qual é o nó de quem recebe.

Duas rotas de você até quem recebe. Com uma fatura BOLT11, a carteira vê todos os nós até o destinatário. A fatura revela o ID do nó de quem recebe, aqui 03e715…, do exemplo da especificação. Com uma rota cegada BOLT12, a carteira só vê o caminho até um nó de introdução, um nó público escolhido por quem recebe. Os saltos depois dele só mostram IDs que parecem aleatórios. Um deles é o destinatário, mas você não consegue saber qual. O destinatário pode incluir saltos fictícios no fim para esconder a distância até ele. O pagamento chega porque cada nó da rota cegada só consegue ler para onde deve encaminhá-lo a seguir. — **Uma rota cegada permite pagar alguém sem descobrir qual é o nó dessa pessoa.** Quem recebe monta a rota e criptografa as instruções de cada salto. Depois do nó de introdução, você só vê IDs que parecem aleatórios. Com o BOLT11, cada fatura identifica o nó de quem recebe.

Isso melhora a privacidade. Toda fatura BOLT11 revela a chave pública do nó de quem recebe, permitindo que empresas de análise de blockchain e vigilância mapeiem quais nós recebem pagamentos. As rotas cegadas rompem esse vínculo e dão mais privacidade aos pagamentos Lightning no próprio protocolo.

Pagamentos recorrentes e assinaturas

Os pagamentos recorrentes ficaram fora da versão aprovada do BOLT 12. A recorrência aparecia nos primeiros rascunhos das ofertas, mas ficou de fora da versão incorporada à especificação em setembro de 2024 (bolts PR #798). A especificação lista “Re-add recurrence” como uma possível extensão. A proposta de reincluir o recurso, bolts PR #1240, segue em aberto em 3 de novembro de 2026.

Se a proposta for incorporada e as carteiras adotarem o recurso, uma oferta de assinatura indicaria um calendário de pagamentos, por exemplo mensal, e a carteira de quem paga poderia enviar o pagamento em cada data. Assim, os desenvolvedores poderiam dispensar os sistemas de assinatura que criam para a Lightning hoje. Por enquanto, cabe a cada aplicativo gerenciar as assinaturas pagas pela Lightning.

Adoção em 2026

O suporte ao BOLT12 varia conforme a implementação:

Core Lightning (CLN): suporte completo ao BOLT12. O CLN foi a primeira grande implementação a oferecer suporte nativo a ofertas.
Eclair (e Phoenix Wallet): oferece suporte ao BOLT12. A Phoenix pode enviar e receber pagamentos por meio de ofertas BOLT12.
LND: o LND 0.21 (junho de 2026) acrescentou encaminhamento de mensagens cebola e busca de rotas para essas mensagens, o transporte de que o BOLT 12 precisa. Ainda não há suporte nativo a ofertas (notas da versão 0.21, versão mais recente v0.21.6, de 30 de outubro de 2026). Os formatos de mensagem do BOLT 12 estão entrando na ramificação principal do LND para a próxima versão principal. Em 3 de novembro de 2026, ela ainda não está disponível. Até lá, o LNDK (v0.3.0, de setembro de 2025) acrescenta ofertas ao LND como processo separado.
LDK: oferece suporte ao BOLT12 para carteiras desenvolvidas com o Lightning Dev Kit.
Pool de mineração OCEAN: aceita ofertas BOLT12 para que os mineradores possam receber pagamentos pequenos e regulares na carteira Lightning por meio de uma oferta reutilizável.

A adoção avança, mas ainda não é universal. Em 2026, a maioria dos usuários continua usando principalmente faturas BOLT11. O BOLT12 ganha espaço à medida que as implementações amadurecem e as carteiras incluem o recurso na interface. Graças à compatibilidade com versões anteriores do protocolo Lightning, a carteira pode oferecer suporte ao BOLT11 e ao BOLT12 ao mesmo tempo.

LNURL: o protocolo de ligação

Entre o BOLT11 e o BOLT12, a comunidade desenvolveu o LNURL, um conjunto de protocolos que amplia o BOLT11 sem mudar a especificação principal. O LNURL-pay permite links de pagamento reutilizáveis. O LNURL-withdraw permite pedir o resgate de fundos. O LNURL-auth permite fazer login com a Lightning. Os endereços Lightning, no formato usuario@dominio.com, usam o LNURL-pay.

O LNURL resolveu várias limitações do BOLT11 antes de o BOLT12 ficar pronto. O LNURL precisa de um servidor web que intermedeie a interação. Isso cria um ponto central de falha e pode comprometer a privacidade. O BOLT12 oferece recursos parecidos no próprio protocolo, sem infraestrutura externa.

Duas formas de obter uma fatura nova com um código de pagamento reutilizável. Com um endereço Lightning como nome@dominio.com, baseado em LNURL, a carteira consulta por HTTPS um servidor web do domínio de quem recebe. O nó de quem recebe cria a fatura, e o servidor devolve uma fatura BOLT11. O servidor atua como intermediário, precisa estar online e vê cada pedido. Com uma oferta BOLT12, lno1…, a carteira consulta o nó de quem recebe pela Lightning em uma mensagem cebola. O próprio nó devolve a fatura BOLT12 sem passar por um servidor web. Nos dois casos, você paga a fatura pela Lightning. — **Um endereço Lightning e uma oferta BOLT12 dão acesso a uma fatura nova a cada pagamento.** Com o endereço, um servidor web responde. Com a oferta, responde o próprio nó de quem recebe.

A expectativa a longo prazo é que o BOLT12 assuma aos poucos muitos dos usos do LNURL. O LNURL vai continuar disponível para compatibilidade com versões anteriores e para algumas integrações com a web.

O que muda para quem usa Lightning

O que isso significa no dia a dia de quem usa a Lightning?

Para pagar faturas: a carteira cuida dos detalhes técnicos. Ao escanear uma fatura BOLT11 ou uma oferta BOLT12, o processo é parecido: escanear, confirmar o valor e pagar. Carteiras atuais como a Phoenix (em inglês) lidam com os dois formatos sem que você precise escolher.
Para receber pagamentos: com uma oferta BOLT12, você pode publicar um único código de pagamento no site ou no perfil. Qualquer pessoa pode pagar várias vezes com o mesmo código, sem que você precise gerar uma fatura para cada transação.
Para proteger a privacidade: se a privacidade for importante, prefira carteiras e serviços com suporte ao BOLT12 com rotas cegadas. Assim, cada pedido de pagamento deixa de revelar a identidade do nó.
Para assinaturas: os pagamentos recorrentes ainda são uma proposta em aberto para o BOLT 12. Se forem incorporados e as carteiras oferecerem suporte, seria possível assinar conteúdo ou serviços pagos pela Lightning sem infraestrutura especial.

Perguntas frequentes

Posso usar BOLT11 e BOLT12 ao mesmo tempo?

Sim. Carteiras com suporte aos dois formatos podem enviar e receber pagamentos com qualquer um deles. O BOLT11 continua sendo a opção para interagir com carteiras e serviços que ainda não adotaram o BOLT12. Os dois formatos convivem na mesma rede Lightning.

Preciso fazer alguma coisa para passar para o BOLT12?

Você pode continuar usando a carteira como antes. Quando a carteira for atualizada com suporte ao BOLT12, você vai poder criar e pagar ofertas além de usar faturas tradicionais. Consulte as notas de versão da carteira para saber se ela já oferece suporte ao BOLT12.

Os pagamentos BOLT12 são mais rápidos que os BOLT11?

O pagamento percorre a rota na mesma velocidade, porque os dois formatos usam o mesmo roteamento por HTLC. O BOLT12 acrescenta uma ida e volta antes do envio do pagamento. A carteira pede uma fatura e o nó de quem recebe a envia. O pedido e a fatura viajam pela Lightning em mensagens cebola curtas.

O que é um endereço Lightning?

Um endereço Lightning parece um endereço de e-mail (usuario@dominio.com) e usa o LNURL-pay. Quando alguém paga para um endereço Lightning, a carteira consulta um servidor web do domínio para obter uma fatura BOLT11. É prático, mas exige um servidor web e não oferece os benefícios de privacidade das rotas cegadas do BOLT12.

O BOLT11 vai parar de funcionar?

Não. O BOLT11 está bem integrado ao ecossistema Lightning e deve continuar funcionando. O BOLT12 se soma aos recursos existentes. A especificação da Lightning é compatível com versões anteriores, então os recursos novos convivem com os anteriores.

Parte do nosso curso gratuito de Bitcoin: aprofunde o tema em Canais e roteamento na Lightning: como os pagamentos encontram o caminho, do curso Rede Lightning e nós Bitcoin.