Submarine Swap

Dans un swap normal, l’utilisateur verrouille du bitcoin on-chain et le service paie sa facture Lightning. Dans Reverse Submarine Swap, il fournit un paiement Lightning conditionnel et réclame une sortie on-chain. Il ne s’agit pas forcément d’un change vers une autre monnaie ou de la simple fermeture de son canal. [Boltz — Swap types and states]

Une preimage correspondant au hash SHA256 permet de régler le paiement lié et de réclamer la sortie verrouillée. Dans le sens inverse, le client crée la preimage et le service maintient le HTLC Lightning en attente avant sa révélation. Un claim on-chain peut révéler le secret ; un parcours coopératif peut le transmettre au service hors chaîne. Un paiement en attente n’est pas un règlement définitif. [Boltz — Swap types and states] [Lightning Loop — Architecture]

Avant financement, le client doit vérifier réseau, montants avec frais, hash, clés, délai et lien du script ou de l’arbre Taproot avec l’adresse cible. La facture doit correspondre au hash et au montant convenus. Une cryptographie correcte n’aide pas si l’application paie aveuglément une adresse arbitraire fournie par une API. [Boltz — Client verification]

Les swaps Taproot peuvent utiliser une signature MuSig2 key-path des deux parties, économisant de l’espace et cachant le script. Sans coopération de l’autre partie, le client doit prendre en charge le claim ou refund script-path adapté. Le remboursement coopératif rapide ajoute une option ; il ne supprime pas la condition de temps de la récupération unilatérale. [Boltz — Claims and refunds] [Lightning Loop — Architecture]

Pour un swap normal échoué avec des fonds on-chain déjà verrouillés, le client construit et diffuse activement une transaction refund ; la voie unilatérale attend le timelock. Pour un paiement Lightning inverse non réglé, le HTLC peut être annulé et les fonds libérés sans cette transaction utilisateur. Après révélation de la preimage, il ne faut toutefois pas supposer qu’un paiement déjà réglé revient automatiquement. [Boltz — Swap types and states] [Boltz — Claims and refunds]

Un swap entraîne des frais de service, de routage et on-chain ; un swap normal échoué peut ajouter des frais de remboursement. Révéler la preimage avant confirmation du claim crée une course avec le délai. Loop précise qu’augmenter les frais de sweep près du timeout peut dépasser la limite initiale. Une estimation ne plafonne donc pas inconditionnellement tous les risques. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]

Conservez la clé refund ou rescue key et les données du swap selon le client utilisé ; la seed ordinaire d’un autre portefeuille n’est pas une récupération universelle. Boltz restore dérive les clés et recherche les swaps, mais un xpub seul ne signe pas. Script, sortie et timeout comptent aussi, pas uniquement l’identifiant du service. [Boltz — Swap restore] [Boltz — Claims and refunds]

Dans le parcours inverse de Boltz, invoice.settled peut signifier que la facture Lightning a été réglée après révélation de la preimage, alors que Boltz ne suit pas la diffusion du claim par le client. Vérifiez votre sortie cible et les confirmations nécessaires avant de conclure ou de répéter le paiement. Taproot key-path réduit la visibilité du script, pas la connaissance des montants et du calendrier par le fournisseur. [Boltz — Swap types and states] [Boltz — Client verification]