Glossary / Lightning & layer 2
Inbound liquidity
Also known as Receive capacity.
- Definition
- Inbound liquidity is the amount someone can send you over Lightning right now, which equals the balance your channel partners hold on their side of your open channels.
Fresh Lightning wallets can spend and cannot be paid, and this is why. A channel you funded yourself starts with every satoshi on your side, leaving nothing on the other side to flow toward you. Until value moves out, or somebody commits capital pointing at you, incoming payments fail with a routing error rather than a bounce.
How it works
Inbound liquidity is not a setting; it is the mirror image of everyone else's balance in your channels.
Picture one channel of 1,000,000 satoshis that you funded entirely. Your outbound liquidity is close to the full million and your inbound is zero, because your peer holds nothing to pass back to you. Spend 300,000 satoshis and the peer now holds 300,000, which is exactly your new receive limit. Every payment you make increases what you can receive; every payment you receive decreases it. The total stays fixed until the channel changes size.
Because it is a mirror, there are only a few honest ways to create it. Someone can open a channel to you and fund it themselves, which is what a Lightning service provider does when it sells you a channel or opens one just in time to catch your first incoming payment. You can pay for a swap, sending Lightning satoshis out and getting on-chain satoshis back, which moves your own balance to the far side without spending it. You can dual fund a channel, where both peers contribute at opening. Or you can simply spend, which is the free option and the slow one.
The oldest packaged version of the swap route is Lightning Loop, released as an alpha by Lightning Labs on March 20, 2019, and marketed from day one as a way to get inbound capacity without closing channels. The mechanism underneath it is a submarine swap.
Where you see it
Inbound liquidity shows up as an unexplained failure long before anyone names it for you.
A new mobile wallet will happily let you buy and receive, because the wallet provider opened a channel toward you and is quietly carrying the cost. Then the receive limit appears: a wallet that says you can send 400,000 satoshis but receive only 12,000 has almost no remote balance left. Ask a friend to pay you 50,000 and it fails.
Merchants hit it hardest. A shop taking Lightning payments consumes inbound liquidity all day and produces outbound it does not need, so it eventually has channels full of money it cannot be paid into. The standard fix is to swap out periodically, converting Lightning balance to on-chain balance and refilling the receive side in the process, or to splice funds out of the channel without closing it.
The number worth checking before you commit is the price. A channel opened toward you costs the provider an on-chain transaction plus locked capital, and they pass both on, either as a visible fee or as a slice of your first deposit. That is a real cost of using Lightning for receiving, and it is the main reason small first-time deposits into self-custodial Lightning wallets can lose a surprising percentage before they arrive.