::: faq-entry # Is there a minimum receiving amount? No, but a mining fee will be required if you don't have a channel already. If the fee is too high, [the payment will be rejected](#incoming-payments-are-rejected-because-of-fees-what-can-i-do). ::: ::: faq-entry # What is inbound liquidity? It is the amount that you can receive within your existing channel, without incurring any fee. As an analogy, suppose that your wallet is a bucket, and your balance the amount of water in the bucket: - Receiving = adding more water - Spending = pouring water out If you keep adding water, the bucket will fill up. To receive more water, you will need a bigger bucket. When the bucket needs to be resized, that's an on-chain operation and mining fees need to be paid. In reality, the bucket is a Lightning channel, the bucket's size is the capacity of the channel. The amount of water that can be added to the bucket before overflowing is the inbound liquidity of the channel. You can visualize your current inbound liquidity in the channels screen. Depending on your use case, if you know you are going to receive more than spend, then it makes sense to request inbound liquidity in bulk ahead of time. It allows you to hit the chain less frequently and save mining fees. ::: ::: faq-entry # How is my current inbound liquidity computed? You may have a channel with a balance of 5 000 sat and a capacity of 25 000 sat. However that does not mean you can receive 20 000 sats on this channel: its incoming liquidity is less than that. Some of the channel's funds are "locked" as required by the Lightning protocol, for security reasons (mostly to pay the on-chain fees in case of a unilateral close and to maintain a channel reserve on the ACINQ side). The amount locked varies with the on-chain feerate and can be significant. In-flight Lightning payments also temporarily consume liquidity. ::: ::: faq-entry # What happens after a year of reserving liquidity? **Short answer:** After a year, the channel will simply revert to default behavior, which is that part or all of the unused liquidity may be claimed back anytime by your counterparty (ACINQ). Claiming back liquidity doesn't close the channel and doesn't change your balance. Note, just because ACINQ has the option to do so doesn't mean that we will exert it, and indeed we typically don't. In particular, we have no incentive to do so if mining fees are high or if the channel is actively used. **Longer answer:** Requesting liquidity means that you expect to be receiving funds in the future and request your counterparty to add funds to their side of the channel. When the expected payments arrive, funds are available and ready to be pushed to your side of the channel, with zero on-chain footprint (and zero mining fee). Or, according to [the metaphore used above](#what-is-inbound-liquidity), requesting liquidity means that you are ordering a large bucket, much larger than what is needed to contain your current balance, because you expect to receive more water in the future. Reserving liquidity doesn't mean that you are borrowing funds, that needs to somehow be repaid in the future lest something bad happens. It doesn't affect your balance. It affects the balance that belongs to your counterparty. When you reserve liquidity, your counterparty allocates a certain initial amount of funds to the channel, and promises to keep it in the channel, even if the channel stays idle because you are not actually receiving payments. After one year, the counterparty is free to dispose of their own funds again. ::: ::: faq-entry # An outgoing payment is stuck pending. What can I do? Lightning payments are routed between Lightning nodes before reaching their destination. If an intermediate node or the recipient node becomes unresponsive, the payment will remain pending. Eventually the payment will timeout and fail. This can take a few hours, or a few days, depending on the route taken by the payment, and which node on the route is unresponsive. Make sure to keep your phone turned on and connected during that time. To maximize the odds of a clean settlement, start Phoenix from time to time to check if the payment has timed out and get the funds back via Lightning. Our system will try to automatically wake up your app to properly settle the payment, but that may fail if your device restricts background processing, or is offline. If the payment cannot fail cleanly, then your Lightning channel will be force-closed, and you'll receive the funds on-chain. ::: ::: faq-entry # I've sent a payment, but the recipient claims they did not receive it? Proving a Lightning payment happened and settling disputes works differently on Lightning than with on-chain transactions, since Lightning is private. To prove that you've send a Lightning payment, you must have the payment's preimage. This preimage is a cryptographic secret that is disclosed by the recipient to the sender when he receives the funds. In other words, if you (the sender) have the preimage, then it proves that they (the recipient) received the funds. Phoenix displays that preimage in the technical section of successfully sent Lightning payments. If the payment has failed or is still pending, you won't see the preimage. You can provide that preimage and the invoice to the recipient as a proof of payment to settle the claim. To facilitate this process, there are third-party websites available, for example [this website](https://validate-payment.com) (not affiliated with ACINQ/Phoenix). ::: ::: faq-entry # Someone claims they've sent a payment to me, but I did not receive it? Proving a Lightning payment happened and settling disputes works differently on Lightning than with on-chain transactions, since Lightning is private. You cannot prove that you did not receive a Lightning payment. Instead, the sender proves that they've sent the payment. They do that by producing the payment's preimage. In other words, if they (the sender) don't have the preimage, then the payment has not been made. However, if they have it and it's valid, but you did not receive the funds, contact [Phoenix support](/support). Note that the dispute may be due to a delay before the service used by the sender notices the payment has failed and credits the funds back to the sender's account. On your end, to limit incoming payment failures, check that you have sufficient liquidity in Phoenix. Also, make sure to keep Phoenix online when you expect incoming payments. See this [FAQ entry for more](#receiving-or-sending-payments-keeps-failing-what-can-i-do). ::: ::: faq-entry # Incoming payments are rejected because of fees, what can I do? Phoenix is self-custodial, which means that sometimes on-chain operations are required to receive payments. When that happens, mining fees are due. Those are volatile and can be very high when the Bitcoin network is busy. By default, Phoenix will reject incoming payments if the fee is more than 5000 satoshi (or 50% of the amount). More precisely: - If the payment was sent over Lightning, funds will be returned to the sender. - If the payment was sent on-chain, funds will remain in your wallet, [waiting to be swapped](#i-sent-funds-on-chain-to-phoenix-why-are-they-displayed-as-sleeping-). If you are fine with paying more fees, you can change the max acceptable fee in Settings > Channel management to a higher value. ::: ::: faq-entry # Why was my channel closed? A Lightning channel may be automatically closed following a problem with a payment, or if the wallet has been inactive for a long time. The funds in the channel will end up on-chain, in your final wallet (Settings > Wallet Info > Final wallet). Once they've confirmed, you'll be able to send these funds to any on-chain address you want. :::