Lightning No Route Despite a Balance: Diagnose the Payment

A Lightning payment can report no route while your wallet still contains bitcoin because the displayed balance is not a promise of a usable path to this recipient. The spending side, intermediate channels, recipient access and the payment’s own constraints all matter. First establish that the previous attempt has failed rather than remaining unresolved; then inspect those constraints instead of immediately adding funds.

Start with the rejected payment, not the headline balance

Write down the exact error and whether the app calls the whole payment failed, pending or successful. A routing attempt is narrower than a complete payment: the software can try several paths. If the interface disconnected, an old notification alone does not establish the final outcome. Keep the original record and ask the wallet to refresh its status before considering a fresh payment request.

Next identify what the balance actually represents. A Bitcoin account in the same application might be an on-chain wallet rather than money currently spendable through Lightning. A custodial app may expose an available balance and its own service restrictions without showing channels. A wallet managing your channels may distinguish local balance from the amount it can spend. Do not apply node-management instructions to an account whose channels you do not control.

This article deals with the diagnostic branch after a route-related failure. For the underlying directional balances, use the separate channel-liquidity explanation. Knowing the vocabulary helps, but the immediate task is to determine which condition blocked this particular payment and who can change it.

Use this evidence table before changing a setting

Treat the middle column as a lead, not a diagnosis proved by a screenshot. For example, a valid invoice does not prove that the recipient is online. A larger fee allowance does not establish that a channel has the necessary directional funds. Record one observation at a time so that a later successful attempt does not leave you guessing which change mattered.

Outgoing funds must have somewhere to go

The Lightning Labs liquidity guide separates local spending capacity from inbound capacity. A channel’s other side being well funded is useful for receiving through that channel, not a replacement for funds on your spending side. Reserves and existing commitments can also make a headline channel balance larger than the amount available for a new payment. Check the wallet’s spendable figure rather than subtracting an assumed universal reserve.

Your first channel is only the beginning. Its peer must be reachable, and the remaining path must work in the required direction. Moving more money into your own wallet cannot by itself repair an unavailable receiving node or supply a remote channel. If only one recipient fails, ask that recipient to check their receiving wallet before treating the whole Lightning network as unavailable.

Distribution can matter as well as totals. Lightning Labs describes multipath payments, where compatible software divides one payment across routes. That helps some distribution problems; it does not turn arbitrary balances into a guaranteed path. Wallet support and the invoice’s advertised features still matter. Do not imitate this mechanism by independently paying pieces of a merchant’s fixed invoice without their agreement.

Read the invoice as a constraint on the payment

For a BOLT11 request, check the network, amount and expiry in the wallet’s decoded preview. The BOLT11 specification defines these payment-request fields and allows routing hints. Hints can supply information about reaching the recipient; they are not proof that every referenced channel remains usable. A screenshot of an older QR code is therefore a poor substitute for a current request from the recipient.

Ask for a fresh invoice if it has expired, and compare the displayed recipient context and amount with the original agreement. Do not edit encoded characters to change an expiry or make the amount fit your available balance. For an amountless request, independently confirm the amount you enter. Other request formats have their own rules, so these BOLT11 checks should not be presented as a universal description of every Lightning offer or address.

If the confusion is whether the destination is an invoice or a Bitcoin address at all, stop here and read invoice versus on-chain address. A routing adjustment cannot make an unsupported destination format compatible with the sending form.

A fee limit is a budget, not a liquidity control

A wallet may decline a route because its routing charges exceed the amount you approved. Lightning Labs explains channel routing fees as base and proportional components. They differ from the miner fee for an on-chain transaction. Compare the actual fee preview with your intended maximum; there is no reason to remove the limit simply because a payment failed.

Protocol errors can be more specific than a wallet’s short message. BOLT4 distinguishes a temporary channel failure from insufficient forwarding fees, among other conditions. The distinction is useful when support can inspect the real error. It does not justify assuming that every no-route banner means low fees, or that the recipient must have rejected you. Increasing a cap changes your spending permission, not the liquidity held elsewhere.

A bounded retry and a useful support request

1. Refresh the existing payment record and confirm a terminal failure before creating a new independent payment.
2. Confirm the selected account is capable of this Lightning payment, with enough available outgoing funds for the amount and permitted fees.
3. Check the recipient’s current request, network, amount and expiry without modifying its encoded contents.
4. If the error identifies a fee constraint, review a specific proposed fee within your budget; otherwise avoid treating a higher cap as a cure.
5. After an identifiable condition changes, make a deliberate retry. If the same failure remains, preserve the evidence and ask the responsible wallet or recipient for help.

Consider a fictional user, Mina. Her app shows bitcoin in two places, but the failed payment selected the Lightning account with insufficient spendable outbound funds. She resolves that account-selection issue using her wallet’s supported process. Another user with the same balance display could instead have an unreachable recipient. The matching symptom is why buying liquidity, rebalancing or closing channels should not be the default first response; each can introduce costs without addressing the actual obstacle.

For support, provide the wallet version, network, time, exact error, amount and existing payment identifier through the official private channel. Include the invoice only if it is needed, since it can reveal payment context. Explain which account was selected and whether the recipient checked their end. Never send recovery words, wallet files or node access credentials to prove the balance.

If you decide to use a different transfer method, agree on it with the recipient after resolving the original attempt. A no-account swap is a separate operation with its own supported asset, network and destination requirements. Check those requirements on the actual order; a failed Lightning route is not evidence that another service accepts the invoice or can complete it on your behalf.