Canais e roteamento Lightning: como os pagamentos encontram o caminho

Um canal Lightning é um saldo compartilhado entre dois nós: uma quantidade fixa de bitcoins que passa de um lado para o outro conforme os pagamentos fluem. Na aula 4.1, você viu como a rede Lightning funciona. Esta aula aprofunda os canais, a liquidez de entrada (por que uma carteira ou nó novo muitas vezes não consegue receber), como os pagamentos encontram caminho pela rede e as faturas BOLT11 que levam tudo de que o pagador precisa.

Entenda os canais Lightning em profundidade

Todo canal Lightning tem capacidade fixa, definida pela transação de financiamento. Se Alice abrir um canal com Bob e colocar 0,05 BTC, a capacidade será de 0,05 BTC. Fica assim até fechar ou mudar de tamanho com uma técnica mais nova chamada splicing.

Capacidade do canal

A capacidade é um limite rígido. Nenhum pagamento pelo canal pode ser maior que a capacidade: um canal de 500.000 sats não pode levar um pagamento de 600.000 sats, seja qual for a divisão do saldo.

Um canal pode ser financiado por um lado (financiamento individual) ou pelos dois (financiamento duplo). Um canal com financiamento duplo começa com dinheiro nos dois lados, então as duas partes podem enviar e receber desde o início.

Saldo local e remoto

Dentro de um canal, a capacidade se divide em dois saldos:

• Saldo local: o valor do seu lado. É o que você pode enviar.
• Saldo remoto: o valor do lado da outra parte. É aproximadamente o que você pode receber.

Os dois somam a capacidade, menos alguns valores que o protocolo reserva:

• A reserva do canal: cada lado precisa manter uma pequena parte do canal que não pode gastar. Assim, sempre tem algo a perder se tentar trapacear publicando um saldo antigo. A especificação da Lightning sugere 1% do canal (BOLT 2). A reserva não pode ser menor que o limite de poeira, que a BOLT 2 fixa em 354 sats ou mais. Por isso, em um canal pequeno, a reserva passa de 1%: pelo menos 354 sats em um canal de 25.000 sats, em que 1% seriam 250. Um lado que ainda não atingiu a reserva, como o lado da outra pessoa em um canal que você acabou de financiar, ainda pode receber, mas não pode enviar até ter mais que a reserva (BOLT 2).
• Dinheiro reservado para as taxas de fechamento, caso seja preciso forçar o fechamento do canal. Esse valor sobe e desce com as taxas on-chain e pode ser significativo. Na maioria dos tipos de canal, quem abriu o canal paga a taxa incluída na transação de fechamento forçado. Por isso, o dinheiro sai do saldo de quem abriu o canal (BOLT 2).
• Pagamentos em andamento, que prendem parte do saldo até terminar.

A documentação da Phoenix dá um exemplo: um canal com saldo de 5.000 sats e capacidade de 25.000 sats não consegue receber 20.000 sats de fato, porque parte do espaço restante fica bloqueada por esses motivos (perguntas frequentes da Phoenix). Por isso “o que você pode receber” é sempre um pouco menos do que parece.

Canais são bidirecionais

O dinheiro anda nos dois sentidos: se Alice pagar 10.000 sats para Bob e ele depois pagar 5.000 para Alice, parte volta. Um canal usado nos dois sentidos se mantém equilibrado.

Liquidez de entrada e de saída

A liquidez de entrada é o assunto que mais confunde iniciantes e o motivo mais comum para um pagamento destinado a eles falhar.

Imagine um canal como um fio com um número fixo de bolinhas, como um ábaco. O número de bolinhas é a capacidade. Cada pagamento desliza bolinhas pelo fio: pagar as move para a outra parte, receber as move para você. Você só pode deslizar bolinhas na sua direção se houver algumas na ponta da outra parte.

Liquidez de saída

Liquidez de saída são as bolinhas na sua ponta: seu saldo local em todos os canais e o máximo que pode enviar. Quando você abre e financia um canal por conta própria, o valor inteiro é de saída. Conseguir é fácil: financie um canal e, depois da confirmação da transação de financiamento, você pode enviar.

Liquidez de entrada

A liquidez de entrada são as bolinhas nas pontas das outras partes: o saldo remoto nos canais e aproximadamente o máximo que você pode receber.

A armadilha é esta: abra um canal com 100.000 sats seus e todas as 100.000 bolinhas ficam na sua ponta. Você pode enviar, mas ninguém pode pagar para você por esse canal, porque não há nada na outra ponta para deslizar na sua direção.

Como conseguir liquidez de entrada

1. Gaste primeiro: cada pagamento que você envia move bolinhas para a outra ponta, que depois você pode receber de volta. Só usar a Lightning já cria liquidez de entrada.
2. Peça que alguém abra um canal com você: quando outro nó abre e financia um canal com você, o saldo inteiro fica do lado dele, então tudo é liquidez de entrada para você. Comerciantes costumam pedir isso.
3. Faça um swap para on-chain: um swap submarino é uma troca entre Lightning e bitcoins on-chain, bloqueados em conjunto para que nenhum lado possa trapacear. Enviar sats Lightning para um serviço de swaps e receber bitcoins on-chain de volta (um “Loop Out”, nome da ferramenta da Lightning Labs para nós LND. A Boltz, que oferecia swaps parecidos de qualquer carteira, está fora do ar desde 3 de agosto de 2026) move bolinhas para a outra ponta do canal. A aula 4.4 explica os swaps.
4. Compre de um provedor de serviços Lightning (LSP): uma empresa que abre canais com você por uma taxa. Carteiras como a Phoenix fazem isso automaticamente nos bastidores.
5. Canais com financiamento duplo: as duas partes colocam dinheiro na abertura, então cada uma começa com liquidez de entrada e de saída.

A Phoenix, por exemplo, cuida da liquidez de entrada. Quando chega um pagamento que não cabe, muda o tamanho do canal e cobra 1% mais a taxa de mineração. Criar seu primeiro canal custa 1.000 sats (tabela de taxas da Phoenix). Se você roda seu próprio nó, gerenciar a liquidez de entrada é seu trabalho.

Como o roteamento Lightning funciona

Quando você paga para alguém com quem não compartilha um canal, sua carteira precisa encontrar um caminho de canais conectados até essa pessoa. Isso é roteamento.

Pagamentos com vários saltos

A maioria dos pagamentos passa por um ou mais nós intermediários. Sua carteira avalia rotas possíveis por:

• Capacidade: todo canal na rota é grande o bastante?
• Saldo: o dinheiro está do lado certo de cada canal? Os nós publicam a capacidade dos canais, mas não a divisão, então a carteira precisa estimá-la.
• Taxas: quanto todos os saltos cobram juntos?
• Confiabilidade: essa rota já funcionou antes?
• Número de saltos: menos saltos costumam ser mais baratos e confiáveis.

Softwares de nó como LND e Core Lightning (CLN) lembram quais pagamentos deram certo e falharam e usam isso para escolher rotas melhores na próxima vez.

Roteamento cebola

A Lightning usa roteamento cebola para privacidade. Sua carteira envolve as instruções da rota em camadas de criptografia, como uma cebola. Cada nó tira uma camada e descobre de onde veio o pagamento (o salto anterior), para onde enviá-lo e quanto repassar. Nada mais da rota está escrito naquela camada.

Um nó no meio da rota geralmente não consegue saber:

• quem iniciou o pagamento
• quem o recebe no fim
• qual é o comprimento da rota

A exceção é o nó ao seu lado. Uma carteira de celular costuma ter um canal só, com o LSP, e não encaminha pagamentos de outras pessoas. Então, quando um pagamento sai desse canal, o LSP sabe que veio de você. Da mesma forma, se o destinatário recebe por um canal privado (não anunciado para o resto da rede, como a maioria dos canais de carteiras de celular), o nó anterior sabe quem recebe. A Phoenix vai além: entrega cada pagamento para o nó da ACINQ encontrar a rota, então a ACINQ também vê para onde vai (a aula 4.3 explica essa limitação).

Cada nó da rota vê aproximadamente quanto está sendo pago. Cada salto recebe a informação do valor a repassar, o pagamento mais as taxas ainda devidas para os saltos seguintes (BOLT 4), que fica perto do valor inteiro. Dividir um pagamento em partes por rotas diferentes (pagamentos por múltiplas rotas) esconde o total de um salto que só leva algumas partes.

On-chain, por outro lado, o endereço de envio, o endereço de recebimento e o valor ficam visíveis para qualquer pessoa que leia a blockchain.

Taxas de roteamento como incentivo

Os nós no meio cobram uma taxa para encaminhar. Ela remunera manter bitcoins bloqueados nos canais e ficar conectado e direciona as carteiras para rotas mais baratas. Cada nó define uma taxa base por pagamento e uma taxa proporcional em partes por milhão (ppm) do valor. A taxa de um salto é:

fee = base fee + amount × rate ÷ 1,000,000

A aula 4.1 calcula uma rota de dois saltos com as taxas medianas da rede: cerca de 3 sats para 10.000 sats e uns 21 sats para 100.000. A aula 4.8 explica como definir suas taxas como nó de roteamento, e nosso guia de taxas da rede Lightning vai além.

Como funcionam as faturas Lightning

Para receber pela Lightning, o destinatário cria uma fatura Lightning: um pedido de pagamento que carrega tudo de que a carteira do pagador precisa para montar o pagamento.

Faturas BOLT11

BOLT11 é o formato de fatura mais usado. Uma fatura é uma sequência longa, começando com lnbc na rede principal do Bitcoin, que contém:

• Hash do pagamento: a impressão digital do segredo que o destinatário vai revelar quando receber. Isso faz os HTLCs funcionarem (a aula 4.1 explica).
• Valor: opcional. Uma fatura de “valor zero” deixa o pagador escolher.
• Validade: por quanto tempo a fatura continua válida. O padrão da especificação, usado quando a fatura não informa, é de uma hora (BOLT 11), mas carteiras definem o próprio. O LND, por exemplo, cria faturas válidas por 24 horas, a menos que receba outra instrução.
• Descrição: uma nota como “Coffee at Bitcoin Café”.
• Dicas de rota: últimos saltos sugeridos, necessários quando os canais do destinatário são privados.
• Identidade do nó do destinatário: a chave pública dele, que diz para o pagador para onde enviar. Também revela para quem vê a fatura qual nó está recebendo.

As faturas costumam aparecer como códigos QR. Escaneie uma com sua carteira Lightning, que lê tudo isso e monta o pagamento.

Uma fatura BOLT11 só pode ser paga uma vez. Se uma segunda pessoa tentar pagar a mesma fatura, o pagamento falha.

Ofertas BOLT12

BOLT12 é um formato mais novo que resolve várias limitações do BOLT11:

• Reutilizável: uma oferta pode ser paga muitas vezes, o que combina com uma página de doações ou um pote de gorjetas. Nos bastidores, a carteira de cada pagador pede uma fatura nova para o destinatário.
• Valor escolhido depois: o pagador pode definir o valor na hora de pagar.
• Mais privacidade: uma oferta pode esconder o nó do destinatário atrás de “caminhos cegados” em vez de nomeá-lo. Com um caminho cegado, o destinatário escolhe os últimos saltos da rota e os criptografa, então o pagador só descobre o nó em que o trecho oculto começa.
• Reembolsos: o formato inclui um jeito de um comerciante pagar para um usuário, por exemplo para reembolsá-lo.
• Provas do pagador: o pagador pode provar que foi quem pediu a fatura, não só que alguém a pagou.

O suporte ao BOLT12 ainda está se espalhando por carteiras e softwares de nó. O Core Lightning (CLN) liderou o desenvolvimento. Nosso guia sobre BOLT11 e BOLT12 compara os dois em mais detalhes.

Boas práticas de gerenciamento de canais Lightning

Se você usa uma carteira como a Phoenix, ela gerencia os canais para você. Se você roda seu próprio nó, o trabalho é seu e se resume a três hábitos: manter canais úteis nos dois sentidos (reequilíbrio), fechar canais parados e abrir canais com pares confiáveis e bem conectados. A aula 4.8 explica cada um para operadores de nós, incluindo o custo do reequilíbrio, e nosso guia avançado de gerenciamento de canais aprofunda o assunto.

Problemas comuns de roteamento

Mesmo canais bem operados às vezes falham em entregar um pagamento. Conhecer as causas comuns ajuda você a resolver os problemas rápido.

Nenhuma rota encontrada

Sua carteira não conseguiu encontrar caminho até o destinatário. As causas incluem:

• o nó do destinatário está desconectado ou não tem canais públicos
• não há caminho conectado entre seu nó e o dele
• toda rota possível tem capacidade insuficiente

Solução: abra canais com nós bem conectados ou peça ao destinatário uma fatura nova com dicas de rota.

Liquidez insuficiente

Existe rota, mas um ou mais canais não têm dinheiro suficiente do lado certo. Isso é comum com pagamentos maiores.

Solução: tente um valor menor, use pagamentos por múltiplas rotas (MPP) para dividi-lo entre rotas ou tente mais tarde, quando os saldos tiverem mudado.

Capacidade do canal excedida

O pagamento é maior do que um canal da rota consegue levar, seja qual for o saldo.

Solução: divida o pagamento com MPP ou encontre rotas por canais maiores.

Tempo do pagamento esgotado

Sua carteira tentou rotas por um tempo e parou de iniciar tentativas novas. Isso geralmente significa nós lentos ou sem resposta nas rotas testadas. Mas uma tentativa que já saiu da carteira ainda pode estar a caminho: softwares como LND não cancelam um pagamento enquanto parte dele estiver em andamento (documentação do roteador do LND).

Solução: espere o pagamento deixar de aparecer como pendente e tente de novo. Sua carteira geralmente vai evitar o nó problemático na próxima vez. Se continuar pendente, é o próximo caso.

Um pagamento preso até o HTLC expirar

Esse é um problema diferente e mais raro. Às vezes um pagamento sai da carteira, mas um nó adiante para de responder, e o pagamento fica “pending”. O HTLC de cada salto tem prazo em blocos, e seus fundos ficam bloqueados até o pagamento terminar ou chegar ao prazo. Pode levar horas ou dias: o LND aceita encaminhamentos bloqueados por até 2.016 blocos, cerca de duas semanas (configuração de exemplo do LND). Se o prazo chegar e o HTLC ainda não puder ser resolvido normalmente, o protocolo exige fechar on-chain o canal que o contém (BOLT 2): um fechamento forçado, com taxas on-chain.

Solução: tentar de novo não adianta aqui. Mantenha a carteira ou nó conectado e espere. A Phoenix, por exemplo, pede para deixar o celular ligado e abrir o aplicativo de vez em quando até o pagamento terminar com falha (perguntas frequentes da Phoenix).

Nosso guia para resolver transações Lightning que falham traz mais casos e soluções passo a passo.

Perguntas frequentes

Qual é a diferença entre liquidez de entrada e de saída?

Liquidez de saída são os bitcoins do seu lado dos canais, o máximo que pode enviar. A liquidez de entrada são os bitcoins do outro lado, aproximadamente o máximo que pode receber. Um canal que você abre e financia começa com toda a liquidez de saída e nenhuma de entrada. Conforme gasta, a de saída vira de entrada. Por isso nós novos muitas vezes não conseguem receber até gastar ou comprar capacidade de entrada.

Posso aumentar a capacidade de um canal sem fechar?

Sim, com splicing, que adiciona ou retira fundos de um canal existente com uma transação on-chain. O canal continua funcionando durante a confirmação do splice. A Phoenix usa splicing para mudar o tamanho do canal automaticamente. Nem toda implementação Lightning já tem suporte a splicing.

Como decodifico uma fatura Lightning para ver o que há dentro?

A maioria das carteiras mostra os detalhes quando você escaneia uma fatura. No seu nó, lncli decodepayreq <invoice> (LND) ou lightning-cli decode <invoice> (CLN) mostra cada campo. Também existem decodificadores online, mas evite colar faturas com dados de pagamento reais em sites de terceiros: a fatura revela o nó que recebe e o valor.

Por que alguns pagamentos Lightning meus falham?

As causas comuns são liquidez insuficiente na rota, destinatário desconectado, fatura expirada ou pagamento maior que os canais do caminho. As carteiras tentam outras rotas automaticamente. Se as falhas continuarem, abrir canais com nós mais bem conectados ou usar uma carteira com LSP integrado costuma ajudar.

O que acontece com meus fundos se um nó de roteamento no meio desconectar?

Você não os perde, mas pode precisar esperar: algumas horas a alguns dias, e até cerca de duas semanas no pior caso, até o pagamento se completar ou o prazo do HTLC passar. A maioria dos pagamentos presos depois termina com falha, e o dinheiro volta pela Lightning. Se não puder, um canal da rota é fechado à força. Geralmente é o canal ao lado do nó sem resposta. O seu só fecha se esse nó for a outra parte direta do seu canal ou sua própria carteira estiver desconectada no prazo, e então seus fundos voltam on-chain, menos as taxas on-chain. Mantenha a carteira conectada enquanto isso. A seção “Um pagamento preso até o HTLC expirar”, acima, explica por quê.

Teste o que você entendeu

1. Você abre um canal de 200.000 sats e o financia por conta própria. Um amigo tenta pagar 10.000 sats para você por ele. O que acontece, e o que poderia fazer antes?

Resposta

O pagamento falha: todos os 200.000 sats estão do seu lado, então não há liquidez de entrada nesse canal. Você poderia gastar alguns sats por ele primeiro, fazer swap de alguns para on-chain, pedir a outro nó para abrir um canal com você ou comprar liquidez de entrada de um LSP.

2. Um nó de roteamento encaminha seu pagamento. O que pode ver: quem você é, quem recebe o pagamento, aproximadamente quanto está sendo pago?

Resposta

Sempre vê o valor que encaminha, que para um pagamento enviado inteiro fica perto do total: cada salto recebe a informação do valor a repassar, o pagamento mais as taxas ainda devidas para os saltos seguintes. Se consegue identificar você ou o destinatário depende da posição dele. Um nó no meio da rota geralmente não consegue, porque o roteamento cebola esconde os dois. Mas se for o LSP da carteira e seu único canal, sabe que o pagamento veio de você e, com Phoenix, a ACINQ também vê o destino. Da mesma forma, o nó antes de um destinatário com um único canal privado sabe quem recebe.

3. Sua carteira diz “payment timed out”. Uma semana atrás, outro pagamento ficou “pending” por dias. Por que tratar os dois de formas diferentes?

Resposta

Tempo esgotado significa que sua carteira parou de tentar rotas novas. Depois que o pagamento deixa de aparecer como pendente, nada está bloqueado e você pode tentar de novo. Um que continua pendente fica bloqueado em HTLCs ao longo de uma rota. Tentar de novo não ajuda: você mantém a carteira conectada e espera até que o pagamento se complete ou o prazo passe. Se não puder terminar com falha normalmente, um canal da rota, possivelmente o seu, é fechado à força, e seus fundos naquele canal voltam on-chain.