Submarine Swap

Anna holds bitcoin in an ordinary wallet, while a shop gives her a Lightning invoice, a request for payment. A normal swap lets her lock on-chain bitcoin under agreed conditions and have a service pay the invoice in return. To move a Lightning balance to an on-chain address, she needs the opposite direction: a Reverse Submarine Swap, such as Loop Out. She need not close her payment channels. The exchange creates no money, however, and the Lightning payment still needs an available route. [1] [4]

Imagine a secret whose digital fingerprint can be checked, without practically being able to work backward from the fingerprint to the secret. The secret value is called the preimage. Its digital fingerprint is a hash, calculated using SHA256. Conditional payments called HTLCs combine that fingerprint with a deadline. In a reverse swap, Anna’s client creates the secret. The service holds her Lightning payment pending and locks corresponding bitcoin on-chain. When Anna claims those funds, an operation called claim, she reveals the secret on-chain or shares it with the service through cooperation. The service can then settle the linked payment. Pending is not paid. [1] [4]

A service notification is different from funds in the destination wallet. Boltz documents that invoice.settled in a reverse swap can follow disclosure of the preimage and settlement of the Lightning invoice. The service does not track whether Anna’s client actually broadcasts the claim transaction. She therefore needs to verify the destination output, the specific bitcoin assigned to her wallet, and the necessary block confirmations. A block is a group of transactions added to the blockchain. Including a transaction in a block gives it its first confirmation; each subsequent block adds another. An unclear status is not a good reason to send the same payment again immediately. [1] [2]

In a normal swap, Anna’s bitcoin may already be locked on-chain while the invoice remains unpaid. A refund then needs a transaction prepared and broadcast by her client. Without the service’s cooperation, it must wait for the timelock, the agreed time condition. An unsettled Lightning payment in the reverse direction can instead have its pending HTLCs cancelled, releasing the balance without an on-chain refund transaction from Anna. That does not mean an already settled payment will reverse itself after the preimage is revealed. Direction and stage matter. [1] [3]

Anna compares what she sends with what actually arrives. Service fees, Lightning routing fees and on-chain transaction fees can account for the difference. A failed normal swap can add a refund transaction fee. Timing also matters: publishing a claim can reveal the preimage before a block confirms it. Loop documentation notes that near a timeout the client may raise the fee for its sweep, the transaction collecting the funds, beyond the original limit. The cryptographic link is therefore no promise of an instant, free or risk-free exchange. [5] [6]

Recovery words from another wallet may not restore a pending swap. Depending on the client, recovery needs a refund key or rescue key and the particular swap data, including the locked output and deadline. Boltz Swap Restore derives keys from its own backup and locates the associated swaps. It searches with an xpub, an extended public key: this can expose history but cannot sign or spend by itself. A private key is a secret value the app uses to sign a transaction under the relevant conditions. These keys remain on the device. What the backup restores and where it is kept should be clear before money is sent. [7] [3]

Users should not have to calculate cryptographic conditions by hand, but their client must check them. Trusting an address returned by an API, the interface through which programs exchange data, is insufficient. The client checks the network, amounts and fees, hash, keys and time conditions. It must also verify the script, the spending rules, or the tree of rules in Taproot, and the address derived from them. The Lightning invoice must match the agreed fingerprint and amount. A sound mechanism cannot rescue software that sends funds elsewhere. [2]

With Taproot, cooperating parties can use MuSig2 to create a joint signature. This key-path spend can cost less and need not reveal the swap conditions publicly. The client also needs the script-path route, directly enforcing the relevant conditions when the peer will not cooperate: for a claim or refund, depending on direction. For a failed normal swap, a jointly signed refund can return the funds sooner. If Anna wants to recover them without the service’s cooperation, however, she must wait until the agreed timelock permits the refund. Revealing less on-chain also does not make the exchange anonymous to the service that arranged it. [3] [4]