Un canal Lightning tiene dos saldos cuya suma está limitada por la capacidad del canal. El saldo local utilizable forma la liquidez saliente; el remoto, la entrante. Las reservas, las comisiones de la transacción commitment, los HTLC pendientes, las reglas de los canales y la capacidad utilizable en cada salto determinan si una cantidad concreta puede recorrer una ruta.
La capacidad del canal es el bitcoin bloqueado en la salida de financiación. La liquidez es solo la parte utilizable ahora en una dirección; un canal de 1.000.000 sats puede tener casi todo en un lado y no transportar un pago grande en sentido contrario. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
La liquidez saliente es la cantidad que el nodo local puede enviar por un canal tras descontar reservas del protocolo, obligaciones de comisión de la transacción commitment y HTLC pendientes. Disminuye al pagar o reenviar hacia fuera y aumenta cuando llega valor del par. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
La liquidez entrante es la cantidad que el par puede enviar hacia el nodo local. Es necesaria para recibir por ese canal, pero modificar una solicitud de pago no la crea; debe existir en el saldo remoto o proceder de una operación de gestión de liquidez. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Un pago enrutado solo tiene éxito si cada salto elegido dispone de suficiente liquidez utilizable en la dirección correcta y acepta el HTLC según sus reglas de comisiones, importes mínimo y máximo y límite temporal CLTV. Un canal agotado puede bloquear una ruta por lo demás bien conectada. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, las comisiones de la transacción commitment, anchor outputs, las reglas de dust, max_htlc_value_in_flight_msat, max_accepted_htlcs y los HTLC ya pendientes pueden reducir la cantidad disponible para un nuevo pago. El saldo de la cartera, la capacidad del canal y la cantidad enrutable de inmediato son, por tanto, tres cifras distintas. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 permite anunciar un canal y sus reglas de reenvío. Su capacidad puede obtenerse de la salida de financiación identificada en la cadena; esto no revela el reparto privado de los saldos. El emisor estima una ruta con información propia, resultados anteriores e intentos de pago. Un explorador público no puede confirmar que una ruta elegida transportará una cantidad concreta ahora mismo. [BOLT #7 — P2P Node and Channel Discovery]
Un pago liquidado desplaza el saldo en cada canal que utiliza: la liquidez saliente baja y la entrante sube en el lado emisor, con el cambio contrario en el otro extremo. El pago redistribuye la capacidad existente sin aumentar la capacidad total. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Un nodo que reenvía necesita liquidez entrante en un canal y saliente en el siguiente para el mismo HTLC. Una suma elevada de sats no basta si están en los canales o lados equivocados. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Los pagos recibidos, el reequilibrio circular, la apertura o cierre de canales, los swaps y el splicing pueden desplazar liquidez. Difieren en comisiones, huella en la cadena, tiempo, confianza en la contraparte y riesgo de fallo; ningún método crea liquidez gratis. Un pago multiparte puede combinar rutas, pero sigue necesitando suficiente capacidad direccional agregada. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
Compruebe en su propio nodo los saldos local y remoto de cada canal, las reservas, los HTLC pendientes y el margen para comisiones; después pruebe el importe previsto. Registre dirección, tamaño, momento e implementación: la liquidez cambia tras cada pago y no es una puntuación permanente de toda la red. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. También enlazan con esta entrada Payment Channel, Lightning Routing, Volatilidad, Capitalización de mercado.