Inbound Liquidity est la capacité d’un nœud Lightning à recevoir par les côtés distants de ses canaux. Elle repose sur le remote balance du pair, mais réserves, paiements en cours, règles du canal et route disponible limitent la réception utilisable.
Le remote balance appartient au pair et représente une marge potentielle de réception ; le local balance est votre côté. Un paiement reçu déplace la valeur du côté distant vers le côté local. Acheter la capacité de recevoir n’est donc ni un don de bitcoins ni un revenu déjà acquis. [Lightning Labs — Managing liquidity]
Dans un canal simplifié de 1000000 sat avec un local balance de 800000 sat et un remote balance de 200000 sat, la marge brute de réception est de 200000 sat, pas un million. Cet exemple omet réserves, frais et HTLC en attente. Financer seul sans transfert initial procure surtout une marge sortante ; confirmer l’ouverture n’inverse pas la direction. [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]
BOLT 2 limite l’ajout de HTLC par les réserves, les montants minimaux, le nombre de HTLC simultanés et leur valeur totale en cours. Des paiements en attente peuvent immobiliser des fonds temporairement. Examinez le montant disponible et les limites de chaque canal ; ne soustrayez pas une réserve universelle de la somme des soldes. [BOLT 2 — Channel management]
BOLT 7 publie des paramètres directionnels channel_update, notamment les frais et htlc_maximum_msat, pas un solde actuel garanti de toute la route. Un pair hors ligne ou un goulet d’étranglement antérieur peut arrêter le paiement. La somme des soldes distants ne garantit donc pas de recevoir ce montant d’un expéditeur précis. [BOLT 7 — Routing gossip]
Un paiement Lightning sortant réduit le local balance et augmente le remote balance des canaux utilisés. Loop Out déplace la valeur Lightning vers une sortie on-chain et peut libérer de la marge entrante ; Loop In recharge au contraire les fonds sortants. Aucun bitcoin n’est créé : comptez les frais de routage, de swap et on-chain ainsi que le résultat de l’opération. [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]
Un pair peut financer un canal vers vous ; sur Lightning Pool, un bid achète de la liquidité pour une durée limitée et un ask la propose. La durée de location s’exprime en blocs. Payer la prime et les autres frais ne vous transfère pas la propriété de tout le solde distant et ne garantit pas une disponibilité permanente après l’accord. [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]
Circular rebalancing envoie par un de vos canaux et reçoit par un autre via le réseau. Le canal sortant gagne de la marge entrante, tandis que le canal récepteur en consomme. Cela ne crée aucun capital et coûte des frais de routage ; une route utilisable est nécessaire, et cela ne suffit pas pour un nœud sans fonds sur tous ses côtés distants. [Lightning Labs — Managing liquidity]
Les recettes convertissent continuellement les soldes distants en soldes locaux et peuvent épuiser la marge pour recevoir davantage. Surveillez les canaux utilisables, paiements en cours, coûts de recharge et montants attendus. Une tentative échouée peut rester invisible au nœud récepteur ; une facture émise ou une ancienne mesure de capacité ne confirme pas le paiement. [Lightning Labs — Merchant liquidity]
Pour une vision complète, lisez aussi Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. Cette entrée est également citée par Liquidité Lightning, Lightning Routing, Lightning Address, Submarine Swap.