Liquidity Management

a node backed deployment must maintain enough lightning liquidity for the payment sizes, direction, and volume the application expects treat liquidity as an operating requirement that connects product forecasts, node balances, channels, payment performance, and treasury controls liquidity concepts on chain wallet balance is not automatically available for lightning payments outbound liquidity is the local balance available in channels the node needs outbound liquidity to send lightning payments inbound liquidity is the remote balance available in channels the node needs inbound liquidity to receive lightning payments channel reserves, commitment requirements, pending transactions, and fees can make part of a displayed balance unavailable for immediate use before production estimate expected send and receive volume, payment size distribution, peak periods, and the acceptable failure rate confirm how the production node will obtain initial outbound and inbound liquidity test representative sends and receives before customer traffic begins define the minimum operating reserve, maximum approved node balance, replenishment trigger, excess funds policy, and the people authorized to move funds or change channels record the monitoring, alert, reconciliation, and escalation workflow before launch outbound liquidity outbound liquidity is created when bitcoin is allocated to the local side of lightning channels before depending on outbound capacity, verify channel state, local balance, payment amount, fee limit, route constraints, and any reserve that reduces spendable balance use only the current supported product or direct lnd workflow for channel operations thunderhub and terminal web are optional operator interfaces when they are enabled they are not required application dependencies inbound liquidity inbound liquidity is created when peers have balance available on the remote side of channels inbound capacity can change as the node sends and receives additional inbound liquidity may require coordinated channel planning, payment flow, or a supported swap or liquidity workflow do not assume that total channel capacity equals current receive capacity verify remote balance and test representative invoices channel and fee constraints channel capacity is fixed when a channel opens changing the allocation normally requires payment flow, a supported liquidity operation, or a channel lifecycle action on chain fees affect channel open and channel close transactions routing fee limits affect lightning send cost and can affect route availability avoid force closing unless current operational guidance requires it a force close can delay access to funds and increase operational complexity investigating payment failures for a failed send, capture the payment request, amount, timestamp, sanitized error, fee limit, current outbound liquidity, and relevant channel state for a failed receive, capture the invoice, amount, timestamp, settlement state, current inbound liquidity, and sender details when available distinguish application errors, authentication or connection failures, invoice problems, local liquidity, route availability, fee limits, and remote node failures before changing channels or credentials treasury controls reconcile the node on chain wallet, lightning channel balances, pending operations, payments records, and the application ledger use approval controls for material fund movements and channel changes keep operational credentials separate from application credentials and use the narrowest available access do not treat every displayed balance as withdrawable account for pending transactions, reserves, channel state, and the liquidity needed for expected customer activity monitoring monitor on chain balance, local and remote channel balance, pending channels, inactive channels, payment success rate, failure reasons, fee spend, and the age of the last successful reconciliation alert before liquidity reaches the point where expected payments fail review thresholds when product volume, payment direction, or payment size distribution changes continue use tools and integrations for thunderhub and terminal web scope and credential guidance use configuration, rest, and grpc for direct lnd access use node security and macaroons for access controls and incident handling