Fixedfloat uses Lightning invoices for Bitcoin swaps

Fixedfloat delivers Bitcoin over Lightning by paying an invoice from the receiving wallet after processing the swap's funding payment. The invoice supplies the destination and payment details. Its expiry and the wallet's receiving capacity affect delivery, while any required confirmations on the incoming cryptocurrency affect the waiting time.

In short: A Lightning wallet needs receiving capacity as well as an unexpired invoice to accept the Bitcoin payout.

Lightning delivery and on-chain Bitcoin destinations

Lightning delivery fits a destination that can issue a Bitcoin Lightning invoice and accept the resulting payment. An ordinary Bitcoin blockchain address belongs to the on-chain receiving option. Both carry Bitcoin, but they use different payment instructions and settlement mechanisms. Selecting Bitcoin alone does not establish that a wallet supports Lightning. A wallet that offers both methods can display separate receiving details, so the chosen exchange output must match the receiving method. An invoice also has its own lifetime, which an ordinary on-chain address does not have.

The selected direction's live quote supplies availability and amount limits. Lightning delivery does not remove the funding network's processing requirements.

The invoice's recipient and receiving amount

A Lightning invoice is a payment request that the recipient creates for the sender to pay. In this payout direction, your receiving wallet issues the request and the exchange pays it. The invoice contains payment information, including the receiving node and expiry. Its signature protects the request's integrity. The BOLT11 format also permits an amount in the request. That amount concerns the Bitcoin payment to the recipient, not the quantity of cryptocurrency that funds the exchange.

When the wallet requests an amount, use the Bitcoin receiving amount that the exchange accepts for the order. Keep the denomination consistent between the quote and wallet, which may display satoshis instead of BTC. One BTC equals 100,000,000 satoshis. A floating rate can change the quoted payout; confirm that the exchange accepts that rate type for your invoice before funding. If the invoice specifies a minimum amount, a lower payout can fail. A fixed quote preserves the receiving amount only if the order's funding amount, timing and market-rate conditions are met. Neither setting changes the invoice's expiration rule. Changing the funding amount or receiving request therefore calls for a fresh compatibility check before payment.

Open full-size image

How long must the invoice remain valid?

The invoice needs to remain valid for the receiving node to accept the payout after the exchange processes your funding payment. A BOLT11 invoice's payment deadline is its creation timestamp plus its expiry duration. The receiving wallet's settings determine the request's lifetime, subject to the format's default when no duration is specified. An invoice that the exchange accepts during preparation can expire while the funding transaction awaits confirmation. The remaining lifetime needs to accommodate that wait and subsequent processing, rather than only the time that copying the request takes.

The exchange order's payment window and the receiving invoice's expiry are separate deadlines.

An order timer governs the exchange's handling of funding and quote conditions. The invoice timer governs the receiving payment request. One deadline does not extend the other. Creating a fresh invoice produces a new request; it does not automatically alter the destination already stored in an exchange order.

Receiving capacity and payment routes

A receiving Lightning node needs inbound capacity: channel liquidity that allows funds to move toward it. Its existing Bitcoin balance describes a different property. A node can hold spendable funds yet lack enough capacity for an incoming payment. Capacity also changes as payments move channel balances. An available exchange quote consequently says little about the receiving node's ability to accept that payout.

Payment routes connect the exchange's node to the recipient through usable channels. Intermediate nodes need connectivity and enough liquidity to forward the payment. A direct channel between the exchange and recipient is one possible connection; the network can also route through other nodes. An error about a missing route can reflect unavailable liquidity or connectivity, even when the invoice itself remains valid.

Regenerating an invoice changes the request, but it does not replenish a channel's receiving capacity.

Wallet design determines who manages that capacity. A wallet connected to a user-controlled node may expose channel management. Other wallets automate it or rely on a provider. Private channels can require routing hints in the invoice so the payer can reach the recipient. A valid request therefore needs a workable receiving setup as well as correct payment details.

Invoice preparation and funded-order recovery

Replacing an expired invoice addresses the request during preparation, before you create and fund an order. Once funds have left the sending wallet, keep the existing order as the subject of any recovery request. A fresh invoice changes neither the original deposit nor the destination stored in that order.

• Before creating an order, replace an expired invoice with a fresh request from the intended receiving wallet.
• Match its Bitcoin amount to the accepted quote and check that the wallet can receive that payment.
• Complete the exchange's invoice validation before funding. If routing still fails, check the receiving node's connectivity and inbound capacity or try a different receiving wallet before creating the order.
• If you have already sent funds, retain the order ID and contact support about that order. Avoid a second funding transfer while its outcome remains unresolved.
• Confirm the payout through the receiving wallet's settled invoice record before treating Lightning delivery as complete.

The service can refuse changes to a funded order. Its procedure for suspending an order to change the destination requires an email supplied at creation or an exchange from a registered account. The request must come from the associated email address.

Open full-size image

How can I confirm that the Lightning payout arrived?

The receiving wallet's settled invoice record confirms the Lightning receipt, alongside the exchange's order status. A payment hash identifies the request; displaying that identifier alone does not establish settlement. The wallet's received amount and invoice status provide the relevant confirmation. For a wallet connected to your own node, invoice monitoring distinguishes a newly created request from one that has settled. A custodial wallet presents its operator's record of the credit.

If the exchange shows a completed order but the wallet lacks the payout, contact support with the order ID.

A payment in flight has not yet reached its final outcome. Invoice expiry applies to new payment attempts and recipient acceptance; channel contract timeouts govern outstanding payment commitments. An expiry notice alone does not prove that an already-started attempt has failed. Keep a pending payment distinct from a confirmed failure or receipt when asking support to investigate.

Routing fees and wallet dependencies

Lightning forwarding fees compensate the nodes that route a payment, and their policies affect the sender's cost. For an invoice payout, the exchange is the Lightning payer. Its receiving quote already incorporates the service's exchange and applicable network costs. The funding wallet may charge separately for sending the input cryptocurrency.

Opening a Lightning channel can introduce a Bitcoin blockchain transaction and its miner fee. An existing receiving channel may avoid that setup, provided it has usable inbound capacity. A custodial wallet shifts channel management to its operator and adds reliance on that operator's custody arrangements. The exchange's custody model does not determine the receiving wallet's custody model. Lightning delivery reduces reliance on blockchain confirmation for the payout itself, but its suitability still depends on the destination's capacity and operating model.

Open full-size image

Fixedfloat: the short answers