Inbound Liquidity 是 Lightning 节点通过自身通道的远端接收付款的能力。其基础是对端的 remote balance，但准备金、待处理付款、通道规则和可用路径会限制实际可收金额。
Remote balance 属于对端，代表潜在收款空间；local balance 是你的一侧。收款会把价值从远端转到本地。因此，购买收款能力既不是获赠比特币，也不是已经取得的营业收入。 [Lightning Labs — Managing liquidity]
在简化的 1000000 sat 通道中，若 local balance 为 800000 sat、remote balance 为 200000 sat，毛收款空间就是 200000 sat，而非一百万。此例忽略准备金、费用和待处理 HTLC。没有初始转账的单方注资主要提供出站空间；开户确认不会使方向反转。 [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]
BOLT 2 通过准备金、最低金额、同时存在的 HTLC 数量及其未结总额限制新增 HTLC。待处理付款可能暂时占用资金。应查看各通道的可用金额与限制，不能从所有余额之和中统一减去一个通用准备金。 [BOLT 2 — Channel management]
BOLT 7 发布有方向的 channel_update 参数，例如费用和 htlc_maximum_msat，而不是整条路径有保证的实时余额。离线对端或路径前段的瓶颈可能阻止付款。因此，远端余额之和不保证能从特定发送方收到等额款项。 [BOLT 7 — Routing gossip]
发出 Lightning 付款会降低所用通道的 local balance，并提高 remote balance。Loop Out 将 Lightning 价值转为链上输出，可腾出入站空间；Loop In 则补充出站资金。这不会创造比特币：应计入路由、交换和链上成本，并核实操作结果。 [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]
对端可向你注资开设通道；在 Lightning Pool，bid 购买限时流动性，ask 提供流动性。租期以区块表示。支付溢价及其他费用，既不会使全部远端余额归你所有，也不保证协议结束后的永久可用性。 [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]
Circular rebalancing 从一个自有通道发送，经网络从另一个自有通道接收。发出通道增加收款空间，接收通道消耗收款空间。再平衡不创造新资本，还需路由费；它需要可用路径，也不能独自解决节点所有远端都没有资金的问题。 [Lightning Labs — Managing liquidity]
收取营业收入会不断将远端余额转为本地余额，可能耗尽后续收款空间。应监测可用通道、待处理付款、补充成本和预期金额。失败尝试可能根本不会出现在收款节点上；已签发发票或旧容量读数都不是付款证明。 [Lightning Labs — Merchant liquidity]
要获得更完整的理解，请将本词条与以下词条结合阅读： Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. 反向关联还来自： Lightning流动性, Lightning Routing, Lightning Address, Submarine Swap.