Lightning Inbound Capacity Calculator: How Much Can You Receive?

Why Inbound Capacity Limits What You Can Receive

On the Lightning Network, your ability to receive payments is not determined by your wallet balance. It is determined by your inbound liquidity: the amount of bitcoin sitting on the remote side of your payment channels. If you open a channel with 1,000,000 sats and push nothing to the other side, your inbound capacity is zero. You can send, but you cannot receive a single satoshi until someone routes a payment through you or you acquire inbound capacity through other means.

This constraint catches many new Lightning users and merchants off guard. A node operator expecting to receive 5,000,000 sats per month in customer payments needs at least that much inbound capacity spread across enough channels to handle peak payment sizes. Underestimating the requirement leads to failed payments, frustrated customers, and lost revenue.

Estimating Your Required Inbound Capacity

The amount of channel capacity you need on the inbound side depends on three variables: your expected monthly receive volume, your average payment size, and your peak payment frequency. Here is how to calculate each component.

Start with your expected monthly receive volume in sats. If you expect to receive 10,000,000 sats per month, that is your baseline. However, channels rebalance as payments flow through them: each incoming payment reduces your inbound capacity and increases your outbound capacity. If you also spend from the same channels, some capacity recycles naturally. A common rule of thumb is to provision inbound capacity at 1.5x to 2x your expected monthly inbound volume to absorb variance.

Channel Count Formula

Your maximum receivable payment size on any single channel is capped by that channel's inbound balance (minus the channel reserve, typically 1% of channel capacity). To receive a 500,000 sat payment in a single hop, you need at least one channel with 505,000+ sats of inbound capacity. For reliability, distribute inbound capacity across multiple channels so that multipath payments can split larger amounts across routes.

A practical formula for minimum channel count: channels = ceil(required_inbound / average_channel_size). For a merchant needing 15,000,000 sats of inbound capacity using 2,000,000 sat channels, that is 8 channels minimum. Add 2 to 3 extra channels for redundancy and routing diversity.

Sizing Reference Table

The following table maps common monthly receive volumes to recommended inbound capacity and channel counts, assuming 2,000,000 sat average channel size and a 1.5x buffer.

Note: Dollar equivalents are approximate at ~$100,000/BTC. Actual requirements depend on payment patterns, channel partner reliability, and how much outbound spending recycles capacity back to inbound.

Methods for Acquiring Inbound Capacity

There are five primary ways to get inbound capacity on Lightning, each with different cost structures, speed, and tradeoffs. The following comparison covers pricing as of mid-2026, but rates fluctuate with on-chain fee conditions and market demand for liquidity.

LSP Channel Purchases

Lightning Service Providers sell pre-funded channels directly to your node. This is the simplest option for wallets and merchants: you pay a fee, and the LSP opens a channel with the agreed-upon inbound capacity. Most mobile wallets (Phoenix, Breez, ZEUS) use LSPs behind the scenes to provision channels automatically.

Pricing varies by provider. Phoenix (ACINQ) charges approximately 1% of the added liquidity with a 3,000 sat minimum, plus on-chain mining fees for the splice transaction. Blocktank (Synonym) charges roughly 12,000 sats for a 1,000,000 sat channel. Olympus (ZEUS) charges around 10,000 sats flat for channels up to 1,000,000 sats, plus a 5,000 ppm routing fee on forwarded payments. Breez SDK charges approximately 4,500 sats for a 1,000,000 sat channel.

Magma Marketplace (Amboss)

Magma is a peer-to-peer liquidity lease marketplace operated by Amboss. Sellers set their own terms: channel size, lease duration, and fee rate. Buyers pay via Lightning invoice, and the payment is held (using HODL invoices) until the seller confirms the channel on-chain. If the seller fails to open, the buyer is refunded.

Typical Magma rates for large channels (1 BTC+) average around 2.6% APR, while smaller channels under 1,000,000 sats often exceed 4% APR because fixed costs take a larger share. Amboss charges a platform fee of 1% for standard users (0.75% for Node Runner tier, 0% for Builders tier) plus a fixed 500 PPM transaction fee on all orders.

Circular Rebalancing

If you already have outbound capacity, you can convert it to inbound by sending a circular payment from one of your channels back to yourself through a different channel. The outbound channel loses balance (gaining inbound), and the return channel gains balance. The cost is the sum of routing fees along the circular path.

Circular rebalancing costs are unpredictable because they depend on the fee policies of every intermediate node in the route. Experienced routing node operators report rebalancing costs between 100 and 600 PPM. At 500 PPM, rebalancing 1,000,000 sats costs about 500 sats in routing fees. However, finding a viable circular route is not guaranteed, especially during periods of network congestion or when channels along the path are depleted.

Loop In (Lightning Labs)

Loop In is a submarine swap service from Lightning Labs. You send on-chain bitcoin to a swap address, and Loop pushes the equivalent amount to you over Lightning, increasing your inbound capacity on the channel the payment arrives through. The service fee is quoted per swap and typically runs around 0.1% to 0.3%, plus on-chain mining fees for the swap transaction.

The main advantage is that Loop In does not require coordination with a specific channel partner. The disadvantage is the on-chain transaction cost (which can be significant during high-fee periods) and the fact that a failed swap requires an on-chain sweep to recover funds, adding more fees.

Liquidity Ads (CLN Protocol-Native)

Core Lightning supports liquidity ads, a protocol-level mechanism for buying inbound capacity directly through the Lightning gossip network. Nodes advertise their available liquidity, lease duration, and price. A worked example: a 1,000,000 sat lease at 50 basis points with a 500 sat base fee costs approximately 5,500 sats plus on-chain fees.

Liquidity ads are standardized and do not require a third-party marketplace, but adoption remains limited compared to LSPs and Magma. Not all Lightning implementations support the protocol.

Cost Comparison by Acquisition Method

The following table compares the cost of acquiring 1,000,000 sats and 10,000,000 sats of inbound capacity across all five methods, assuming moderate on-chain fees (approximately 15 sat/vB). All figures are approximate.

Note: Costs fluctuate with on-chain fee rates and market demand for liquidity. During fee spikes above 50 sat/vB, any method requiring an on-chain transaction becomes significantly more expensive. Circular rebalancing is the cheapest per-sat option but requires existing outbound capacity and a viable route.

For a deeper analysis of channel opening economics, see our Lightning channel cost calculator.

When Each Method Makes Sense

New node with no channels: start with an LSP channel purchase or Magma lease. These are the only options that do not require existing channels. LSPs are faster and simpler; Magma offers more control over terms and often lower rates for larger channels.

Existing routing node rebalancing: circular rebalancing is the cheapest option if you have sufficient outbound capacity and can find viable routes. Use Balance of Satoshis or similar tools to automate circular rebalances with cost limits.

Merchant expecting steady inbound volume: combine an initial LSP or Magma channel with Loop In for ongoing maintenance. As customers pay you, your inbound capacity depletes. Loop In lets you replenish it from on-chain funds without opening new channels.

For a broader view of how these liquidity options fit into the Lightning scaling landscape, see our research on the Bitcoin second layer scaling landscape.

The Inbound Capacity Problem and How Spark Solves It

The inbound liquidity constraint is a fundamental design tradeoff of payment channel networks. Every sat of receivable capacity must be pre-committed in a channel, and acquiring that capacity costs money, time, and operational complexity. For merchants processing high volumes, the ongoing cost of maintaining inbound capacity can become a significant operational expense.

Spark eliminates this problem entirely. Spark is a Bitcoin Layer 2 that does not use payment channels at all. Instead, it uses a statechains-based architecture where users hold virtual transaction outputs (VTXOs) that can be transferred instantly without channel capacity constraints. There is no concept of inbound or outbound liquidity: if you own bitcoin on Spark, you can receive any amount up to the protocol's limits without pre-provisioning capacity from anyone.

This architectural difference means merchants on Spark do not need to budget for LSP fees, manage channel balances, or run rebalancing automation. For businesses evaluating Lightning versus Spark for payment acceptance, the total cost of ownership should include not just per-transaction fees but the ongoing cost of maintaining receivable capacity. See our Lightning vs Spark comparison for a detailed breakdown.

Frequently Asked Questions

How much inbound capacity do I need on Lightning?

Provision at least 1.5x your expected monthly receive volume. If you expect to receive 5,000,000 sats per month, target 7,500,000 sats of inbound capacity. Distribute this across multiple channels (minimum 2 to 3) so that large payments can split via multipath routing. If your payment patterns are bursty (for example, a merchant with weekend peaks), increase the buffer to 2x.

What is the cheapest way to get inbound liquidity?

Circular rebalancing is the cheapest per-sat method, costing 200 to 600 sats per 1,000,000 sats moved, but it requires existing outbound capacity and a viable route. For nodes without existing channels, Magma leases and liquidity ads offer the best rates for larger channels. LSP channel purchases (Phoenix, Breez, ZEUS) are the simplest but tend to cost more per sat, especially for small amounts where minimum fees dominate.

Can I receive Lightning payments without inbound capacity?

Not on the traditional Lightning Network. Without inbound capacity, incoming payments have nowhere to land. Mobile wallets like Phoenix and Breez work around this by using LSPs that open just-in-time channels when you receive your first payment: the LSP fronts the inbound capacity and deducts a fee from the received amount. On Spark, inbound capacity is not required at all because the protocol does not use payment channels.

How long does purchased inbound capacity last?

It depends on the provider. LSP channels typically remain open for at least 3 to 6 months, though the provider reserves the right to close earlier. Magma leases have explicit durations ranging from 1 week to 12 months, set by the seller. Liquidity ads on CLN also have configurable lease periods. Once a channel is open, the inbound capacity depletes as you receive payments. Ongoing maintenance (via Loop In, circular rebalancing, or new channel purchases) is needed to sustain receivable capacity over time.

Why does inbound capacity cost money?

Providing inbound capacity requires the counterparty to lock their bitcoin in a payment channel with you. That capital has an opportunity cost: those sats could be earning routing fees elsewhere, deployed in DeFi, or simply held. LSPs and marketplace sellers charge fees to compensate for this locked capital, the on-chain transaction cost of opening the channel, and the risk that you close the channel before the lease period ends.

What happens when my inbound capacity runs out?

When your inbound capacity is depleted, incoming payments to your node will fail. The sender's wallet will attempt to find alternative routes, but if all paths to your node lack sufficient inbound balance, the payment cannot be completed. Monitoring your channel balances and replenishing inbound capacity before it fully depletes is critical for merchants and services that need reliable payment reception. Tools like Lightning Terminal's Liquidity Report and Autoloop can help automate this process.

Is inbound capacity needed for Spark or USDB payments?

No. Spark does not use payment channels, so the concept of inbound and outbound capacity does not apply. Users holding bitcoin or USDB on Spark can receive any amount instantly without pre-provisioning liquidity. This is one of the key architectural advantages of Spark over channel-based Layer 2 networks for payment acceptance.

This tool is for informational purposes only and does not constitute financial advice. Pricing data is approximate, based on publicly available information as of mid-2026, and fluctuates with on-chain fee conditions and market demand. Always verify current rates directly with the provider before purchasing inbound capacity.