Submarine Swap

In a normal swap the user locks on-chain bitcoin and the service pays their Lightning invoice. In a Reverse Submarine Swap the user supplies a conditional Lightning payment and claims an on-chain output. This is not necessarily an exchange into another currency or simply closing one’s own channel. [Boltz — Swap types and states]

A preimage matching a SHA256 hash enables the linked payment to settle and the locked output to be claimed. In the reverse flow the client creates the preimage and the service holds the Lightning HTLC pending before disclosure. An on-chain claim can reveal the secret; a cooperative path can give it to the service off-chain. A pending payment is not final settlement. [Boltz — Swap types and states] [Lightning Loop — Architecture]

Before funding, the client must verify network, amounts including fees, hash, keys, timeout and the binding of the script or Taproot tree to the destination address. The invoice must match the agreed hash and amount. Correct cryptography does not help if an application blindly pays an arbitrary address supplied by an API. [Boltz — Client verification]

Taproot swaps can use a MuSig2 key-path signature from both sides, saving space and hiding the script. If the other party does not cooperate, the client must support the applicable script-path claim or refund. Fast cooperative refunds add an option; they do not remove the time condition for unilateral recovery. [Boltz — Claims and refunds] [Lightning Loop — Architecture]

For a failed normal swap with on-chain funds already locked, the client actively constructs and broadcasts a refund transaction; the unilateral path waits for the timelock. For an unsettled reverse Lightning payment, the HTLC can be cancelled and funds released without such a user refund transaction. After revealing the preimage, however, do not assume an already settled payment automatically returns. [Boltz — Swap types and states] [Boltz — Claims and refunds]

A swap incurs service, routing and on-chain costs; a failed normal swap can add a refund fee. Revealing the preimage before claim confirmation creates a race with the timeout. Loop explicitly documents that raising the sweep fee near timeout can exceed the original limit. A price estimate is therefore not an unconditional cap on every risk. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]

Retain the refund key or rescue key and swap data according to the client used; an ordinary seed from a different wallet is not universal swap recovery. Boltz restore derives keys and looks up swaps, but an xpub alone cannot sign. The script, output and timeout matter too, not merely the service’s identifier. [Boltz — Swap restore] [Boltz — Claims and refunds]

In Boltz’s reverse flow, invoice.settled can mean the Lightning invoice settled after preimage disclosure while Boltz does not track whether the client broadcast the claim. Verify your destination output and required confirmations before marking completion or repeating payment. A Taproot key-path reduces script visibility, not the provider’s knowledge of amounts and timing. [Boltz — Swap types and states] [Boltz — Client verification]