58 / 691LIQ

Liquidez Lightning

A liquidez Lightning é o valor que um canal consegue enviar ou receber agora em uma direção, não sua capacidade total anunciada.

Um canal Lightning tem dois saldos cuja soma é limitada pela capacidade do canal. O saldo local utilizável forma a liquidez de saída; o saldo remoto utilizável forma a liquidez de entrada. Reservas, taxas da transação commitment, HTLC pendentes, regras dos canais e capacidade utilizável em cada salto determinam se um valor específico consegue realmente percorrer uma rota.

A capacidade do canal é o bitcoin bloqueado na saída de financiamento. Liquidez é apenas a parte utilizável agora em uma direção; um canal com capacidade de 1.000.000 sats pode, portanto, ter quase tudo de um lado e não transportar um pagamento grande no sentido oposto. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Liquidez de saída é o valor que o nó local pode enviar pelo canal após descontar reservas do protocolo, obrigações de taxa da transação commitment e HTLC pendentes. Ela diminui ao pagar ou encaminhar para fora e aumenta quando chega valor do par. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Liquidez de entrada é o valor que o par pode enviar ao nó local. É necessária para receber por esse canal, mas mudar uma solicitação de pagamento não a cria: ela deve existir no saldo remoto ou vir de uma operação de gestão de liquidez. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Um pagamento roteado só funciona se cada salto escolhido tiver liquidez utilizável suficiente na direção correta e aceitar o HTLC conforme suas regras de taxas, valores mínimo e máximo e limite de tempo CLTV. Um canal esgotado pode bloquear uma rota que, de resto, tem boas conexões. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]

channel_reserve_satoshis, taxas da transação commitment, anchor outputs, regras de dust, max_htlc_value_in_flight_msat, max_accepted_htlcs e HTLC já pendentes podem reduzir o valor disponível para um novo pagamento. Saldo da carteira, capacidade do canal e valor imediatamente roteável são, portanto, três números diferentes. [BOLT #2 — Peer Protocol for Channel Management]

BOLT #7 permite anunciar um canal e suas regras de encaminhamento. Sua capacidade pode ser obtida da saída de financiamento identificada na cadeia; isso não revela a divisão privada dos saldos. O remetente estima uma rota com informações próprias, resultados anteriores e tentativas de pagamento. Um explorador público não pode confirmar que uma rota escolhida transportará um valor específico neste momento. [BOLT #7 — P2P Node and Channel Discovery]

Um pagamento liquidado desloca o saldo em cada canal utilizado: a liquidez de saída cai e a de entrada aumenta no lado remetente, com a mudança inversa na outra ponta. O pagamento redistribui a capacidade existente sem aumentar a capacidade total. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Um nó de encaminhamento precisa de liquidez de entrada em um canal e de saída no seguinte para o mesmo HTLC. Um total elevado de sats não basta se estiverem nos canais ou nos lados errados. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Pagamentos recebidos, rebalanceamento circular, abertura ou fechamento de canais, swaps e splicing podem deslocar liquidez. Eles diferem em taxas, pegada na cadeia, tempo, confiança na contraparte e risco de falha; nenhum método cria liquidez gratuita. Um pagamento em múltiplas partes pode combinar rotas, mas ainda exige capacidade direcional agregada suficiente. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]

No próprio nó, confira os saldos local e remoto de cada canal, reservas, HTLC pendentes e margem para taxas; depois teste o valor pretendido. Registre direção, tamanho, momento e implementação: a liquidez muda após cada pagamento e não é uma pontuação permanente de toda a rede. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]

Para ter uma visão mais completa, leia este verbete junto com Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. Também há referências a este verbete em Payment Channel, Lightning Routing, Volatilidade, Capitalização de mercado.

DOC · 001BOLT #2 — Peer Protocol for Channel ManagementEspecificação ↗DOC · 002BOLT #7 — P2P Node and Channel DiscoveryEspecificação ↗DOC · 003Lightning Labs — Understanding LiquidityDocumentação ↗DOC · 004Lightning Labs — Managing LiquidityDocumentação ↗
Revisado em 1º de agosto de 2026Fontes em primeiro lugar · Não é recomendação de investimento