Lightning Network: o que é e para que serve
Como a Lightning Network move pagamentos em bitcoin fora da blockchain, o que são canais, roteamento e liquidez, e quais os riscos de cada modelo de custódia.
Em revisão editorial. Este texto foi elaborado a partir de fontes públicas e passa por revisão técnica e jurídica; pode ser atualizado. Confira as fontes ao final antes de qualquer decisão.
Quer conversar sobre Bitcoin no contexto do seu patrimônio? Entrar em contato →
A Lightning Network é uma rede de pagamentos construída sobre o Bitcoin que permite enviar valores fora da blockchain principal. Dois participantes travam bitcoin em um canal compartilhado, trocam atualizações de saldo entre si e só registram o resultado final na rede principal quando fecham o canal. Quando há canais encadeados, um pagamento pode passar por intermediários sem que eles possam se apropriar dele. Serve, sobretudo, para pagamentos pequenos e frequentes. Não elimina riscos: a rede tem limites de liquidez, exige atenção à custódia das chaves e depende de transações na rede principal para abrir e fechar canais.
Por que ela existe
A rede principal do Bitcoin registra cada transação em blocos, e a capacidade por bloco é limitada. O Banco de Compensações Internacionais (BIS), em seu relatório de 2018, observou que, com a capacidade limitada, as taxas “disparam” quando a demanda atinge o teto, e que transações chegaram a ficar horas em fila. O texto técnico de Joseph Poon e Thaddeus Dryja, divulgado como rascunho em janeiro de 2016, parte desse problema: propõe uma rede de canais de pagamento em que a transferência de valor ocorre fora da blockchain, com a execução das regras na própria blockchain em caso de disputa.
A ideia, portanto, é aliviar a rede principal e permitir valores pequenos com custo baixo. Trata-se de uma “camada 2”: um protocolo que usa o Bitcoin como base de liquidação, não uma moeda diferente.
Como funciona
Canais de pagamento
Um canal é um contrato de múltipla assinatura entre dois pares. A documentação da Lightning Labs descreve cada canal como correspondente a uma única saída não gasta (UTXO) na blockchain do Bitcoin, controlada em conjunto pelas duas partes. Os passos básicos são:
- Abertura: as partes registram na rede principal uma transação que trava os fundos no canal. A especificação (BOLT #2) prevê que quem aceita o canal indique um número mínimo de confirmações da transação de abertura (
minimum_depth) antes de o canal ser usado, salvo em canais sem confirmação (zero-conf), que exigem confiança no provedor. - Uso: as partes trocam, entre si, versões assinadas e atualizadas da divisão do saldo, quantas vezes quiserem, sem registrar cada uma na blockchain.
- Fechamento: em acordo, as partes publicam o saldo final (fechamento cooperativo). Se uma delas some ou age de má-fé, a outra pode publicar o último estado assinado (fechamento unilateral).
Para desencorajar trapaças, o protocolo usa um mecanismo de revogação: quem tentar publicar um estado antigo pode perder o saldo do canal para a outra parte. A especificação também prevê uma reserva mínima por lado (sugere-se 1% do total do canal), para que cada parte tenha algo a perder caso tente fraudar.
Roteamento
Nem todo pagamento ocorre entre pares com canal direto. Nesse caso, ele percorre uma cadeia de canais. O mecanismo é o contrato com bloqueio por hash e tempo (HTLC, na sigla em inglês): um pagamento condicional que só se completa se o destinatário revelar um segredo e que expira e retorna ao remetente se isso não ocorrer. Segundo o resumo do texto original, o desenho permite transferências entre partes que não confiam umas nas outras ao longo da rota, com as regras executadas na blockchain caso algum participante não coopere.
A especificação BOLT #4 descreve o roteamento em cebola: o remetente monta um pacote em camadas, e cada intermediário só descobre o próximo salto, não a rota inteira nem a posição que ocupa nela. A mesma especificação ressalta que a análise de tráfego ainda pode relacionar pacotes. Cada intermediário pode cobrar uma taxa de encaminhamento, conforme a tabela que ele anuncia (composta, em geral, de uma parcela fixa e outra proporcional). Na API pública do mempool.space (fonte secundária), cujo último registro disponível em 16/10/2026 era de 20/08/2026, a mediana era de 100 partes por milhão (proporcional) e 500 milissatoshis (fixa), o que daria, em um pagamento de 10.000 satoshis, cerca de 1,5 satoshi por salto (exemplo hipotético, calculado pelo site com a mediana; as taxas reais variam por nó e o dado é de fonte secundária).
Liquidez de canal
Cada canal tem um saldo de cada lado. A capacidade de enviar depende do saldo que a pessoa tem em seu lado (liquidez de saída), e a de receber depende do saldo do outro lado (liquidez de entrada). A documentação da Lightning Labs define a liquidez de entrada como a capacidade de receber pagamentos e lembra que um nó de roteamento precisa ter os dois tipos, em valores suficientes para pagamentos relevantes.
Consequências práticas:
- Quem acabou de abrir um canal pode enviar, mas ainda não consegue receber, pois todo o saldo está do seu lado.
- Um pagamento maior do que o saldo disponível em algum canal da rota falha, ainda que a soma dos saldos da rede seja grande.
- Operadores de nós rebalanceiam canais e compram liquidez de entrada, o que tem custo.
Segundo o último registro da API pública do mempool.space (20/08/2026; fonte secundária, e não um dado em tempo real), a rede divulgada tinha cerca de 33,1 mil canais, 16,4 mil nós e capacidade total de aproximadamente 3.750 bitcoins (375 bilhões de satoshis). O mesmo serviço registrava cerca de 39 mil canais e 4.400 bitcoins em julho de 2026, de modo que os números oscilam bastante. São números de canais públicos, e canais privados não aparecem. Um estudo do Federal Reserve Bank of Cleveland (2022) encontrou associação significativa entre a adoção da Lightning e menor congestionamento da rede principal, com evidência mista sobre se a maior centralização da rede melhorou sua eficiência.
Custódia: carteiras custodiais e não custodiais
A experiência de uso pode ser muito diferente conforme quem controla as chaves.
| Aspecto | Carteira custodial | Carteira não custodial |
|---|---|---|
| Quem controla as chaves | O provedor | A própria pessoa |
| Canais e liquidez | Geridos pelo provedor | Geridos pela pessoa, em geral com ajuda de um provedor de serviço Lightning (LSP) |
| Principal risco | Risco de contraparte: bloqueio, falha ou insolvência do provedor | Erros de operação, perda de chaves ou de backups, falhas de software |
| Disponibilidade | Em geral, o provedor mantém o serviço online | Para receber, a carteira precisa estar online |
O Guia de Design do Bitcoin (comunidade aberta) afirma que carteiras Lightning não custodiais precisam estar online para receber pagamentos, que um provedor de carteira (LWS) pode reter um pagamento para um usuário offline sem assumir custódia, e que as “torres de vigia” monitoram canais de usuários offline. Também alerta que provedores de liquidez podem trazer concessões de confiança ou de privacidade e que canais com zero confirmação exigem confiar que o provedor não cancelará a transação de abertura.
O modelo é o mesmo debatido em custódia de criptoativos e em autocustódia. No Brasil, a Resolução BCB 520/2025 descreve a custódia de ativos virtuais como a guarda e o controle de instrumentos que afetam o exercício dos direitos sobre o ativo, a exemplo das chaves privadas (art. 9º, I). O enquadramento de um serviço Lightning específico na regulação brasileira depende do modelo e exige análise jurídica própria; este texto não o avalia.
Riscos e limites
- Dependência da rede principal: abrir e fechar canais exige transações com taxa de rede principal. Em período de congestionamento, fechar um canal pode ficar caro e lento, e os prazos dos HTLCs correm.
- Monitoramento: a especificação BOLT #5 diz que um nó deve monitorar a blockchain até que as saídas estejam resolvidas e ressalta que não há risco de perda nos três casos de fechamento, desde que a situação seja tratada adequadamente. Isso significa que o risco existe quando a situação não é tratada, por exemplo por falhas de software ou de disponibilidade.
- Falhas de roteamento: pagamentos podem não encontrar rota ou liquidez. Segundo o BOLT #4, as mensagens de erro de roteamento não são confiáveis, pois não ficam registradas na blockchain.
- Chaves em dispositivo conectado: o saldo de canais fica em carteiras “quentes”, mais expostas a falhas de segurança.
- Valores limitados: a especificação impõe parâmetros como o número máximo de pagamentos pendentes por canal (483, no padrão sem taxa zero) e o valor mínimo de saída (limite de poeira). O uso típico é de valores pequenos.
- Volatilidade e regulação: o saldo continua em bitcoin e oscila de valor; regras fiscais e regulatórias seguem aplicáveis.
O que não é verdade
- A Lightning não é “outro Bitcoin”: usa o mesmo ativo e depende da rede principal.
- Não é gratuita: há taxas de rota e de rede principal.
- Não é instantânea em qualquer circunstância: depende de rota, liquidez e conectividade.
- Não é anônima: a especificação reconhece que a análise de tráfego pode vincular pacotes.
- “Não custodial” não significa “sem confiança”: há provedores de liquidez, de backup e de torres de vigia.
O que observar
- Quem controla as chaves da carteira e o que acontece se o provedor sair do ar.
- Como o serviço lida com liquidez de entrada e quanto cobra por ela.
- Taxas de rota e de abertura e fechamento de canal.
- Política de backup e de recuperação do saldo.
- Valores envolvidos: para quantias grandes, o pagamento na rede principal pode ser mais adequado.
- Tratamento regulatório e tributário do serviço usado.
Fechamento
A Lightning Network é uma solução de escala para pagamentos pequenos com bitcoin, com ganhos reais de velocidade e custo em certas condições e com novos riscos operacionais. Entender canais, liquidez e custódia ajuda a avaliar o que está sendo oferecido. Este conteúdo é informativo e não constitui recomendação de investimento nem aconselhamento jurídico ou tributário. Para analisar um caso concreto, é possível falar com Rogers Garcia.
Fontes
- The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (draft 0.5.9.2, 14/01/2016) · Joseph Poon e Thaddeus Dryja / lightning.network · acesso em 16/10/2026
- BOLT #0: Introduction and Index · Lightning Network specifications (repositório lightning/bolts) · acesso em 16/10/2026
- BOLT #2: Peer Protocol for Channel Management · Lightning Network specifications (repositório lightning/bolts) · acesso em 16/10/2026
- BOLT #4: Onion Routing Protocol · Lightning Network specifications (repositório lightning/bolts) · acesso em 16/10/2026
- BOLT #5: Recommendations for On-chain Transaction Handling · Lightning Network specifications (repositório lightning/bolts) · acesso em 16/10/2026
- Understanding Liquidity · Lightning Labs (documentação oficial do software LND) · acesso em 16/10/2026
- Payment Channels · Lightning Labs (documentação oficial do software LND) · acesso em 16/10/2026
- Lightning services (Bitcoin Design Guide) · Bitcoin Design Community (guia de design aberto) · acesso em 16/10/2026
- The Lightning Network: Turning Bitcoin into Money (Working Paper 22-19) · Federal Reserve Bank of Cleveland · acesso em 16/10/2026
- Cryptocurrencies: looking beyond the hype (Annual Economic Report 2018, cap. V) · Bank for International Settlements (BIS) · acesso em 16/10/2026
- Estatísticas da Lightning Network (API pública, registro de 20/08/2026) · mempool.space (dados públicos de rede; fonte secundária) · acesso em 16/10/2026
- Resolução BCB nº 520, de 10 de novembro de 2025 · Banco Central do Brasil · acesso em 16/10/2026
Conteúdo informativo, sem caráter de recomendação de investimento, jurídico ou tributário. Ativos digitais envolvem riscos, inclusive de perda total. Veja os avisos legais.